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

Fedora38三度…

再インストール後順調に進んでいた-O3 rebuildなんですが、QT系の大物の処理で全体が固まるという事態になってしまいました。どうにも反応がないので仕方なく強制リセット。その結果はというと、ファイルシステムの不整合発生で起動不能に。
ファイル自体もいくつか読めないものが出てきました。まぁXFSを使用しているので正しくShutdownしないとこうなるのは分かってはいましたが、実際に起きてみると実に困りもの。

前回のトラブルからさほど時間も経っていないこともあって、データーバックアップは無視して再インストール。36がEOLになっているのでドキドキものでしたが、無事に36->38のupgrade完了です。

各種データーを戻してrebuildのやり直しから開始です。web処理系の大物ってrebuildとの相性が良くないようで、固まらないまでも処理していたプロセスを立ち上げたconsole自体がすっとんだりするので冷や冷やです。

それにしても37までは問題なく処理できていたfirefoxやlibreofficeがrebuild不能となったのは納得行かないな。

それよりも39の話が出てきているので真剣にこの10年落ちPCをどうにかすることを考えなくては…

Fedora38再び

Fedoraが38になってしばらくした時のこと、ツールバーに表示されるDiscoverなるアプリケーションからの「Update有ります」につられて全部を更新したのでした。

普段通りの個別のアップデートの他に「Fedora Coreサポート」と言う見慣れない項目が有ります。37→38はUpgrade更新したので、なにか抜けたものでもあるのかと思い特に気にするわけでもなく更新開始。
その結果いつもやっているrpmのrebuildがことごとく謎のエラーで止まるようになってしまったのでした。

曰くgtk3パッケージが無いだの”xxxxx.h”が見当たらないだのと繰り返されます。もちろん物はあるんですけど、見に行くところが変わった模様。

Discoverでの更新作業の良くないところは何をやったのかさっぱりわからないこと。更新前にリストが表示されれば「なにか変」と気付けるのですが、その情報が出ないのでやってしまったときは正に「後の祭り」…

結局は再インストールを実行。どうにかインストールできる36を入れて、直接36→38のUpgrade実行で、どうにか復旧です。当たり前ですが、-o3化も最初から…
それにしても今使っているPCはUEFI対応では無いので37以降を直接インストールできません。今回は36からのアップグレードで対処しましたが、36がEOLになると関係パッケージに触れなくなることが予想されます。
どうしたものかなぁと思案中。

とりあえずFedoraのパーティションをISOイメージ化して保存するしか無い気がしますが、あとはPCの買い替え? 今使っているPCも10年選手なんで頃合いと言えばそうなんですがね。中古PCだと頃合いのモノもあるのですが、はっきりとUEFIだと分からないのでちょっとしたバクチとなります。どうしたものかなぁ。

方針変更

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の更新が怖いな…

写真整理

年末の大掃除と言う訳でもないのですが、今回のFedora騒ぎで写真データーがかなりの混乱状態にあることが分かりました。
バックアップが5世代分くらいありそうな気配です。だからSSDの容量を圧迫してるわけで…

手動だと面倒なので一旦全画像データーをWindowsでも読める形に移してFileManyという重複検索ソフトで整理。一気にやると大変なので少しずつですが、それでも1回の検索で重複3000ファイルとか出てきて目が回ります。

さて今年中に整理がつくかな。現在480Gほど食ってますが、どこまでスリムにできるか(笑)

またやっちまった…

またしてもgrub2でトラブル。起動不能になってしまいました。
こんな時のための忘備録というわけで、作業をしたのですが、どうも新規インストール扱いとなってしまったようで、「オマエのPCはUEFIでないから起動設定不可!」とメッセージが出てオシマイ…

さて方法は3つ。

  • 1. とりあえず36まで戻って(36のBootable Mediaを作って)、36の環境を作成してupgradeをかける
  • 2. Fedoraをあきらめて他のDistributionに移行する
  • 3. 新しいPCを購入する

選択肢2の他のディストリですが、現在元気なのはUbuntuなんですが、ベースがDebianなのが大いに問題。どうもUbuntuの世界では自前でパッケージを最適化rebuildすることは無いようで、ほとんど情報が出てきません。
やはり使い慣れたRedHat系がいいなと思うと、CentOSとなるのですが、こちらもかなり混乱していてCentOS7より8の方が先にEOLが来るというカオス。

UEFIの他にx86のv2以降でないと使えなくなるディストリが増えそうな気配もあるので、そうなると10年目が見えてきたこのPCを廃棄して新しいPCもしくは8世代目あたりのCPUを積んだ中古PCを購入ということなります。価格見てみましたが第8世代あたりはまだ高いですね。i7-8700搭載機だとi5-12400辺りの新品と価格が変わりません。
現状のPCはグラフィックボードが非常に高価になっているので内蔵グラフィック以外だと結構な金額となってしまいますので、悩みも深い。

と言う訳で、とりあえず1の一旦36に戻してからUpgradeを実施。37になってまだ日が浅いのでさほどの大ごとにもならずに37に戻れました。rpmのrebuild環境はこれからなんですが、ぼちぼちやっていきましょう。まぁこちらは道楽なんで焦る必要も無いし。