やばいやばい

-O3化が一段落して、日常に復旧しました。で、いつものようにupdateモジュールどものrebuild。ところがまたしても途中でPCが気絶する事態に陥ってしまいました。何をしてもキーボードからは反応がありません。メニューからrebootを選びますが先に進まない… デスクトップのウィジェットはちゃんと反応しているのがなんとも悔しい状態。

しかたがないので強制電源断。このまま再起動すると前回同様怪しいことになりそうだったので、一旦36のBootable Mediaで起動です。しかしKDE spinなので例によって停止します。

毎回ビデオカードの脱着は面倒なので、ここで新しいDesktop環境のBootable Mediaを作ることにします。とりあえず38のCinamonを作成してBoot。見事に起動せず… UEFI未対応PCだとBootable Meidaからも起動できないとは… トホホ と言う訳でアーカイブを漁って36のCinamon DesktopのBootable Mediaを作成して起動します。

lsblkで対象ドライブを確認してxfs_repairを実行。当該デバイスのlogが変だから一旦mountしろやと出ましたので適当にディレクトリを作ってmountしてからumount。
その後再度xfs_repairを実行。いくつか「注意」は出ましたが、さほど大事にならずに修復終了。
あとはシステムを再起動してどこからも苦情が出ないことを確認します。

いやはやびっくりしたな。

-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化の作業で.srpmを引っ張ってくるのにいちいち手動でftpを利用するのは面倒です。さらに.srpm自体がupdate側にあるのかそうでないかまで判断しなくてはなりません。

なんとかならんかと考えていたところ、なんとdnfに.srpmをダウンロードする機能が存在することが判明。
しかもupdate側かどうかまで自動で判別してコマンド発行時点での最新を引っ張ってくれます。ファイル名は厳密にチェックされますが、バージョンまでは指定する必要がないのでとても便利。

dnf download --source file名1 file名2...

インストール済みやdnf check-updateで示されるrpmモジュール名からバージョン情報を取りのぞくスクリプトはgawkかpython+正規表現を使えば簡単に書けますから、.srpmの取り出しも半自動化できます。

早く気付けば良かったな。これでftpは必要無くなった?

-O3化ようやく終わり

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

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

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

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