-O3化本当に終わり

SRPMを取り出すツールを作ったので、ついでとばかりに全体の-o3化にとりかかり、なんとか終了しました。

-o3化できたのが1834ファイルで、失敗が123ファイル。失敗の中にはどうにもならない依存関係のある物も含まれていますので、純粋に謎のrebuildエラーで出来上がらなかったのは7割くらいじゃないでしょうか。

それにしてもPythonからみでファイルやディレクトリが見つからないというエラーがたくさんあって、どうもPythonは具合悪いですね。いろいろな依存関係からから多数のバージョンが同居している状態は気持ち悪いです。

ところで-o3化したことで、全体の感じに変化があったのかなんですが、これが少しずついじっていったこともあってよくわからないというのが実態。rebuild時間の短縮とか、ちょっとしたレスポンスの向上などがあるはずなんですが、一気に入れ替えてみないと実感できないなぁというのが正直な感想です。
でも自力でrebuildしたシステムを使用しているわけで、たぶんこれが本来のLinuxの使いたかだよなと自己満足しています。

SRPMの取り出し

と言うわけで早速半自動取り出しスクリプトを作成

#
# エラーリストなどから自動で.srpmを取り出すためのスクリプト
# getsrc.sh

#! /bin/sh
cat $1 | gawk '{ print $1 }'|grep "[0-9A-Za-z]"|grep -v '^setting' > ./temp.txt
cmd=""
spc=" "

for fn in $(cat ./temp.txt); do
        if [ $fn == "RPM" ]; then
                break
        fi
        cmd=$cmd$spc$fn$spc
done

rm temp.txt -f
echo $cmd
dnf download --source --destdir ./SRPMS $cmd

楽ですね。さらに楽だなぁと思ったのは重複している場合やすでにダウンロードしている場合には自動でスキップしてくれる点です。なので、何も考えずにリストを作成してこのスクリプトに食わせてやればOK。
dnfの直前のecho $cmdは確認用でもあるので、無くても問題はないですね。

例えばlist1.txtなるファイルに

tcpdump-4.99.4-1.fc38.x86_64
tigervnc-server-minimal-1.13.1-3.fc38.x86_64
time-1.9-20.fc38.x86_64
tmux-3.3a-3.fc38.x86_64

と言った感じで羅列してやり、あとは

$ ./getsrc.sh list1.txt

これだけで、このディレクトリ内の./SRPMS内に.srpmがダウンロードされます。リストにはバージョン情報は無くてもよいので、単に

tcpdump
tigervnc-server-minimal
time
tmux

でもOKです。
いや、もっと早く気づいていれば楽できたのにな…

-O3化ようやく終わり

Fedora38の三度目のインストール騒ぎ。その際にgroupinstallなど手動でインストールでモジュール類が明確に分かった各種ツール類の-O3化がようやく終わりました。

生成済みrpmの確認用のツールも作ったので、ついでだと言う訳で現在システム内に入っているrpmどもの内どの程度が-O3化されているのか確認してみることに。
その結果インストール済みが6,185モジュールでその内処理済みは3,212モジュールとだいたい半分。

最初から入っていた分でまだupdateが来ていないものがこれだけ有るということになります。もちろん依存関係やどうしても解決できないrebuid時のエラーによって-O3化できない物もあるので未処理分の全部が取り掛かっていないと言う訳ではありませんが、まだ結構残っている感じ。

rebuildエラーになったsrpmから生成されるrpmモジュールを取り出すツールを用意して、この際だからできる分は全部片づけてみますかね。

KiCAD V6その4

どうにか時間が取れたので、本体のbuild開始。30分くらいで終わった気がします。

今回、VSでProjectを開くのにドキュメントと違う方法試したところドはまり。cmakesettings.jsonにswig.exeとpython.exeのありかを書いておけば、特に何も追加指定せずに実行できるはずと、あれこれやりましたがエラーが取れなくて一旦中止。cmakesettings.jsonの書式を勉強しないとだめですね…

今度はドキュメント通りにprojectを開き、ドキュメントにある通りにswig.exeとpython.exeの在処を書き込んでビルド開始。ビルドオプションは生成するオブジェクト毎に分かれています。x86-debug,x86-release,x64-debug,x64-release,MSYS2-x64-debugとあるのですが、x86とMSYS2は使用しないのでx86の2つにだけ追加。

出来上がったのはよいのだけど、何このバージョン表記。またnightlyからソースを引っ張ってきてしまったようだ… 進歩無いな。もう一度6.01のソースをとってくるところからやり直さなきゃ。

Fedora35その4

大量のKDE5のアップデートが来ました。5.89->5.90なのですが、rebuildで問題発生。

当初kf5-kconfigのrebuildで余計なファイルであるlibKF5ConfigQml.so.なんとかが邪魔と怒られます。なのでspecファイルに余計な奴らを削除するように指示を追加して問題解決。
ところがその後、少なくないファイルのrebuildがfailで止まります。5.89のときは無かった現象なので何が起きたのかBuild Logを読んでみます。
すると…

CMake Error at /usr/lib64/cmake/KF5Config/KF5ConfigTargets.cmake:89 (message):
The imported target "KF5::ConfigQml" references the file
"/usr/lib64/libKF5ConfigQml.so.5.90.0"
but this file does not exist. Possible reasons include:

まさしく先程のkf5-kconfigのrebuildで消したファイルが無いと怒られています。
再びkf5-kconfigのspecファイルを変更してlibKF5ConfigQml.soとかなんとかをcoreファイルとdevelファイルに入るようにしてrebuildして再インストール。
そうしたら問題が解決したのでした。

  • kf5-kcompletion-5.90.0-1.fc35.src.rpm
  • kf5-kconfigwidgets-5.90.0-1.fc35.src.rpm
  • kf5-kcontacts-5.90.0-1.fc35.src.rpm
  • kf5-kfilemetadata-5.90.0-1.fc35.src.rpm
  • kf5-kglobalaccel-5.90.0-1.fc35.src.rpm
  • kf5-knotifications-5.90.0-1.fc35.src.rpm
  • kf5-kservice-5.90.0-1.fc35.src.rpm
  • kscreen-5.23.5-1.fc35.src.rpm
  • plasma-systemmonitor-5.23.5-1.fc35.src.rpm
  • plasma-workspace-5.23.5-1.fc35.src.rpm

以上がこの問題に引っかかっていたファイル。結構大物が含まれています。

おそらくはrebuildなんて酔狂なことをしなければ問題にはならなかったのでしょうけど、検証ってどうなっているのやら。Bugzillaに報告を上げたほうがよいのだろうか?

Fedora35その3

bootの問題が解決したし、日本語入力の問題もほぼ解決したようなので、-o3化を進めていきます。
その過程で出てきた新しい問題が、

doxygen: symbol lookup error: /lib64/libclang-cpp.so.13: undefined symbol: _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE8_M_eraseEmm, version LLVM_13

なにやらわけのわからない名前のシンボルが見当たらないと苦情が出ます。
この問題は結構な数のモジュールで発生している模様なので解決しないとなりません。調べてみると2017年頃にGCCのバージョンが変わったことで一時発生していたようですが、ここ最近は話題になっていない模様。

もう一度エラーログを見直すと、libclang-cpp.so.13に有るはずのものが見当たらないのが問題だと言われてます。そう言えばclang自体も早々に-o3化を済ませていたのでしたが、もしかしてと思いdnfを利用してclang-libs.x86_64をインストールし直したところ問題解決!。

結局のところこの問題のシンボルは空のエントリかなにかで、-o3の時に「無駄だから削除」となったのでしょう。-o3の意外な副作用でびっくりさせられましたが、他にも起きているかもしれません。改めて問題が起きたらその時に考えましょう。

この問題が解決した後はスムーズに進行。CPUが同じ第4世代とは言え、i5からi7になったことと、メモリーが8Gから16Gになったことでリビルドにかかる時間も25%ほど短縮されたようです。
firefoxが2.5時間、thunderbirdが1.5時間、Kicadも1.5時間くらいですから、このくらいなら待てますね。ちなみに33時代のfirefoxはリビルドに8時間かかってましたが、あれは何だったのかな。

残る常用する大物はlibreofficeだけど、関係モジュールが多数なので準備が面倒。まぁこの週末に退治しますか。

rebuild時間

普段使いのFedora、まぁ実験的ディストリビューションなので頻繁に各モジュールの更新がかかります。で、最適化オプションを変更してできるだけ自前でrebuildするわけですが、昨日は大物が沢山来て大騒ぎ。firefox,libreoffice,thunderbirdとどれもソースrpmが500MB級で、ダウンロードだけでも時間がかかります。

実際のrebuildに要した時間はログによれば、
firefox-85.0-5.fc33 started at 2021年  1月 30日 土曜日 18:43:49 JST
libreoffice-7.0.4.2-7.fc33 started at 2021年  1月 31日 日曜日 03:18:44 JST
ninja-build-1.10.2-1.fc33 started at 2021年  1月 31日 日曜日 06:31:32 JST
p11-kit-0.23.22-2.fc33 started at 2021年  1月 31日 日曜日 06:32:15 JST
qpid-proton-0.33.0-1.fc33 started at 2021年  1月 31日 日曜日 06:32:55 JST
samba-4.13.4-0.fc33 started at 2021年  1月 31日 日曜日 06:39:57 JST
sddm-0.19.0-5.fc33 started at 2021年  1月 31日 日曜日 06:51:52 JST
thunderbird-78.7.0-1.fc33 started at 2021年  1月 31日 日曜日 06:52:38 JST
zziplib-0.13.71-1.fc33 started at 2021年  1月 31日 日曜日 08:59:44 JST
ざっとこんな塩梅。
以前はlibreofficeを処理するのに12時間くらいかかっていたので随分早くなったものですが、firefoxが異様に時間がかかるようになってきました。

今回の記録でも18:43に始まって03:18に終了なので8.5時間… Thunderbirdが2時間、Libreofficeでも2.5時間なのでなんともはや。何がそんなに難しいのかな。

KiCAD 5.1.4日本語フォント対応その4

あれこれ継ぎ接ぎして出来上がったパッケージ。インストールしなおしましたが特に前の時と挙動が違うようには見えません。インストール自体も特に変わったことも起きなかったので、やはり気のせいってことで良かったのかな。

2019/9/6追記:
PCBエディターで自動配置を試みたら落ちました。本家からインストールパッケージを取ってきて試してみなくては…

KiCADはPythonを全面的に利用しているけど、PythonはVer2とVer3とでせめぎあいになっていて、各種ライブラリなんかもPython2-xxxとPython3-xxxと有る始末でとても困る。
もっともこの問題はFedoraでも今だにPython2を捨てられていないので、他所では当分の間Python2が使われ続けるのだろうな。

それはともかくとして、フォント自体をハードコーディングせずに別付けファイルの形にしてくれれば、なんの苦労もないのだけど、開発者グループにはそうする気が無いようなので当分はこの騒ぎが続きそうだな。

そもそもKiCADは基板を設計したいから始まったプロジェクトなので基本はPCB Editor。で、ここでストローク系 Font以外からガーバーデーターに変換するのが面倒だってのがどうも開発者グループの共通認識のようで、他フォントを使いたければInkscapeあたりでベクトルデーターに変換してくれって意見と共にInkscapeからデーターを持ってくるドライバまで提供されています。基板上のロゴだとか注意書き(?)なら、そんな方法でもいいでしょうけど、回路図ではそんなんじゃやってられません。あっ、図面に関わる人全部が英語に堪能なら問題は起きませんがね。

KiCAD 5.1.4日本語フォント対応その2

もう一度こちらのページを参照して作業再開。その結果いくつかエラーが出てましたが、無事にパッケージまで作成完了しました。
エラーが気になるけどインストールもできるし、インストールした物もそれなりに動いているので気にしないことにします(汗)。ただ、DLL関係で見つからないってのは地雷になる可能性が有るので、ログを再度チェックしておきましょう。
改めて有用な情報を公開してくださっている皆様に感謝します。

今回は元のページにある記述を元にPKGBUILDとcopydlls.shを変更したのと、install.nsiの9行目にある作者のお名前が文字化けして最後の最後で引っかかるので、文字化け分を削除しただけで、他の操作はしなくてOKでした。

多分にPCBエディターで使用する3Dパーツライブラリが巨大と見えて、できあがりのパッケージも巨大。1.12GBだなんて… ダウンロードするだけでも結構かかるよな。
また私製ビルドなので仕方が無いけど、バージョンにdirtyって入るのは嬉しくないぞ。
ところで、私製パッケージって需要があるのかな? 公開しても良いのだけど、置く場所が無いな。

8月30日追記:
logであるmkpkgをチェックしたところ、妙なエラーは出ていないので作成できたパッケージは問題ない模様。これで一安心。