Gentoo: qtwebengine build fails

仮想化した,第2workstation (WS)の元第1OSであったGentooをup-to-dateに保つルーチンですが,qtwebengineのemerge (build)に失敗するというトラブルに見舞われ早くも頓挫していました.

“qtwebengine build fails” でネット検索すると多数ヒットします.もう,10数年前から同じトラブルに見舞われた初心者がフォーラムに質問しては,エキスパートが答えるということが,何度も繰り返されているようです.

ですが,その割にはズバッと解決って言うのは多くないようです.ヒットした検索結果を1つずつ追っかけて,4, 5件目くらいだったでしょうか,エキスパートが,「メモリー不足」と回答していました.

エラーメッセージには1つもメモリーに関したことはないのですが,そのエキスパートは,

Usaually “Killed signal terminated program cc1plus” means a out of memory error.

fedeliallalinea

と明快です.

そこで,書いてある対策や,自分で考えた対策を試行し,build (emerge)に成功しました.

あくまで,当社調べですが,-jumbo-buildは効果が確認できなかったですが,仮想マシンに割り与えるメモリーを増やした(24GB)ことと,make.confの,MAKEOPTSの-jのタスク数を減らすこととが有効だったようです.

なお,SWAPを増やすことは本件に関しては効果がないそうです.

Gentoo VMを飼い続けるのはきびしいかも

実マシンの第2OSとしてGentooを維持するという当初のプランでは,システムをup to dateにするためには,第2OSであるGentooで起動させて,長い時間emerge (Gentooの自動buildシステム)を動かしておく必要があるので,第1OSを使いたいときに使える状況ではなくなりました.

Gentooを第1OSにしたとしても,updateで平気で一晩かかるとかあるので,システムのON/OFF/Rebootの自由度がなくなり扱いづらいです.

それと,当初期待したほど〝守備範囲〟が広くなくて,第1OSとしては厳しいんです😓

そこで,Gentoo以外の扱いやすく守備範囲の広いdistroを第1OSとして(ManjaroかDebian),Gentooをその仮想マシンとすることで,update中は第1OSの電源断やリブートはできませんが,第1OSにマシンパワーをある程度リザーブできますし,普通の作業(ってなんだ😓)は可能です.

しかし,それでも平気で何時間もかかるようなupdateはありますので(しかも,実マシンの時よりも何割か余計に時間がかかる),飼っている第1OSの自由度は制限されます.

といって,Gentooを放置すると,並みやたいていの方法では二度とup-to-dateにできなくなります😓

ということで,持て余しているというか,振り回されているのが現状です.

仮想マシンであるGentoo AMD64が,qtwebengineを激しくemergeしている様子

Yakuake

一体全体どういう意味なんでしょう.響きや,音節が必ず母音で終わるところは,ハワイ語とか,ニュージーランドのマオリ語な感じがします.あるいは,海外の人が日本語に似せて考えた造語だったり.そのへんは後で調べますが,なんとも,便利なツールです.

Plasma (KDE)で何かしているときに,ふとターミナルが必要になることがよくありますが,そんなときのために,いつもKonsoleを立ち上げて使用しているアプリ(大抵はFirefox)の裏にしておいたり,最小化しておきます.

ところが,このYakuakeは,必要なときに,F12キーを押すと,上から降りてきます.

→ フルサイズのイメージ

基本は,気に入っているKonsoleのようで,Konsoleのデフォルトプロファイルを変更するとYakuakeもそれに応じて変わります.

何年も前からあるようなのですが,これが標準で有効化されていたManjaro AMD64を使って初めて知りました.とても便利なので,Debian AMD64, Manjaro ARM64でもログイン時に起動するようにしました.

→ フルサイズのイメージ

元実マシンのGentoo VMへそを曲げる

実マシン(第2Workstation=第2WS)の第1OSだったGentooを仮想マシン化して,新たに第1OSに就任したManjaro AMD64の元で動かして維持していこうとしましたが,先程updateのために起動しようとしたら,仮想ディスクがパーティションマップがなくなるほどの致命的な破損を受けていて,起動はおろか,インストールディスクイメージによる修復さえもできませんでした.

大幅な降格でへそを曲げたようです.気持ちはわかります😥

仕方がないので,保存してある実Gentooからクローニングしたときのイメージを上書きすることにします.また仮想化のための多少の手続きが必要になります.今度は仮想マシンとして起動した時点で,そのイメージをバックアップしておきます.

古いGentooのupdateができん

いろんなファイルのタイムスタンプを見ると2016年頃にインストールしたと思われるx86 (32bit)仮想マシンの Gentooのupdateができないで困っています.

emerge なんとかかんとか @worldとすると,EAPI 7に対応したportageを使えと文句をいいますから,portageのupdateを試みますが,そうするとPythonが古くてだめだと文句を言われます(たぶんそう言われている😓).

そこで,たぶんどれかが必要だとしているうちのpython3.6のインストールを試みますが,EAPI 7じゃないとだめだと文句を言われます.

そう,循環依存状態です.

仮想マシンなんで消してしまえばおしまいなんですが,なんか難しいパズルのようで,しばらく何か思いついたら試してみることにします.