Fedora40

有難いことに本業が繁盛で、なかなか遊んでいる時間も取れません。でモタモタしていたら40がリリースされていました。

本当はBootable Mediaから入れ直すのが古いrpmを削除できるので本筋なんですが、UEFI対応ではないこのPCだとBootable Mediaからの起動ができないので、いつものようにdnfの system upgradeを実行。

最初にfc37時代のモジュールが引っかかったので削除。38,39と無事に過ごしていたのがすごいな…
さらにAkonadi-Serverの絡みでkde側のモジュールと競合するとか言ってきたので–best –allowerasingを追加。あとrustのモジュールでもトラブルが出てましたね。

rustとpythonはいつもモジュール類のバージョンで引っかかって面倒を起こしてくれます。rpmのrebuildに必要となるので入れてますが、本当に迷惑。特にrustのcrateはバージョン0.1とか0.2なんて奴が平気で公開されていて、しかもそいつに依存するアプリケーションが少なからず存在します。なのでrebuildするには複数を入れて置かなければなりません。例えば、

    rust-rand0.7+libc-devel-0.7.3-8.fc39.noarch
    rust-rand0.7+std-devel-0.7.3-8.fc39.noarch
    rust-rand+libc-devel-0.8.5-5.fc39.noarch
    rust-rand+std-devel-0.8.5-5.fc39.noarch

    てな具合。

    C++に比べて堅牢ってことですが、こんなバージョン管理がまかり通っていて本当なんですかねぇ。

    トータルで9100余りのrpmが入れ替えになりました。これでまたしばらくrebuild祭りで遊べそう。

    FC39その2

    Windows側での作業が一段落したのでLinux側での作業開始。時間はかかったようですが、無事に39にUpgradeができました。

    相変わらずなにがどうなったことやら(苦笑)。Consoleのプロンプトの形が少し変わったのは気が付きましたが、他はさっぱり…
    思い返せばFedoraCore2からの付き合いですからね。調べたらFC2の登場が2004年5月ですから18年半ほどが経過したことになります。で、使う側の技量がそれだけ上がったのかというと… ですねぇ(苦笑)

    Desktopも最初はGnomeでしたが、GNOME3になったときにどうにも違和感だらけだったのでKDEにスイッチして以来KDEとの付き合いです。KDEも5になりたての時はトラブルが多かったのですが、以後だいぶ安定するようになりましたね。そろそろ6って噂も聞こえてきますがどうなりますやら。

    さあ、恒例の-O3化。ツールは揃えたのであとはソースを用意するだけ。手始めにめちゃくちゃ時間のかかるgccから行きますか。

    やばいやばい

    -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モジュールを取り出すツールを用意して、この際だからできる分は全部片づけてみますかね。

    方針変更

    Fedoraだけでは無いと思うのですが、各種のパッケージの中には相互依存が強い場合か有って、パッケージAの更新分をRebuildするにはパッケージBの更新文が必要。だけどパッケージBの更新にはパッケージAが… となってしまうことが度々発生します。

    またKDEのシステム系によく見られるのですが、最終的には全部Rebuildできるのですが、そのためには数十回のrebuildと出来上がりパッケージの更新インストールの繰り返しが必要となって非常に時間がかかります。

    で、方針転換。先にdnf updateで全部一旦更新してしまって、あとからrebuild済みのパッケージを入れ直すことにしました。結果はてきめんで、あの面倒だったKDE関係の更新も1passで終わってしまい、随分と時間の節約になったのでした。

    もっと早く気がついていれば良かったな…

    gpgエラー

    -O3ビルドをやっていると、時々変なエラーが出てrpmが作成できないことがあります。
    大体は単純にファイルが多いと文句を言われるので、specファイルに削除を追加してrpmを作成していきます。

    今回はgpgmeの生成でディレクトリ構造が違うぞとの苦情が出たので直して生成、インストールしたら、まさかのdnfが使えなくなりました。gpgモジュールをimportできないとか。

    標準のgpgmeを入れ直してみましたが解決せず… 弱ったなぁと思いつつもソフトリンクを貼ることでなんとか治りましたが、正月そうそうちょっとびっくりです。

    Traceback (most recent call last):
     File "/usr/lib/python3.11/site-packages/dnf/crypto.py", line 35, in <module>
       from gpg import Context
    ModuleNotFoundError: No module named 'gpg'

    なので、/usr/lib64/python3.11/site-packagesに行って

    [root@fedora site-packages]# ln -s gpg-1.17.0-py3.11-linux-x86_64.egg/gpg gpg

    でなんとか解決した模様。とりあえずdnfは苦情が出なくなりました。次のgpgmeの更新が怖いな…