C#とSQLite

 MP3データーのTAGを整理してファイル名に反映させるプログラムを作成中。TAGのデーターにある人名から肩書を追加するのに最初はべた書きしてましたが、ファイル数が膨大になってきたので、対応しきれません。まぁ最初から分かってはいたんですがね。

 ならば「DBを用意して、そこから引っ張ってくれば簡単♪」とプログラムを書き始めます。ちなみに最近は脳力減退を補うためにC#で書きますが、なかなか… OOPの場合、classの中身が謎であることが多くて検索ばかりでなかなか進みません。
余談ですが、最近のVSはAI化が進んでいて先回りしてコード例を提示してくるのでちょっと気味が悪かったりします。バリバリコードを書くような場合には便利かもしれませんけどね。

 さてDBには使い捨てプログラムと言うことも有って一々インストールしなくて済むSQLiteを選択。別途用意したデーターを書き込んでDBを準備します。そして本番プログラムから検索させるのだけど、全然ヒットしない。アルファベットだけの場合はうまくいくので、文字コードからみだとは思うのだけどいろいろゃっても改善されず。

 ならばとC#からデーターを書き込んでやれば良いのではと気が付いて新しいプログラムを作成。ちょっとトラブルはありましたが、無事にDBに書き込みできました。

さぁ、これでどう改善されるのかな。

cmake QT6の謎

Fedora40にUpgradeしたのですが、各モジュールのrebuildで問題多発。QT6のcmake定義がないとかなんとか。kf6(KDE 6)のメインモジュールやplasma関係のrpmがかなり引っかかります。
いろいろ調べて処置してみるのですがまったく改善されません。

しばらくもやもやしていたのですが、VMに新規インストールしたらどうなるのかと気付きました。
VM player ProがVer.17から個人利用であれば使用できるようになったので早速セットアップ。そしてFedora40をISOイメージからインストールしてあれこれ準備。
ちなみにVMへだと、UEFIでなければインストール不能となっているFedora40が若干の問題だけでインストールができます。

さっそくrebuildしたところ問題なく進行していきます。ならばと思い、/usr/lib64/qt6/cmakeの中身を全部取り出して、VMでない方にコピーします。本来は一つずつどこがどう違うか調べるべきでしたが、一気に上書きしたので何がNGだったのかは不明ですが、rebuildは本番環境でも問題なく進むようになりました。あとはネット関係が引っかかるのを解決できれば問題解決なんだけど、どこから調べていきますかね。現状ではVM上のFedoraの方がスムーズに動きますので。

だからと言って全面的にVM環境下へ移行することも検討しましたが、どうしたってパフォーマンスは落ちますから、正しい選択とも思えません。

さてもう一息頑張りましょうか。

Fedora40

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

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

最初にFedora37時代のモジュールが引っかかったので削除。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祭りで遊べそう。

KiCAD winbuild

PCのOSがWindows11になりました。なのでと言う訳でもないのですがbuildシステムがpowershellのshell scriptベースとなったので、改めて挑戦。

説明ページ(https://gitlab.com/kicad/packaging/kicad-win-builder)によればgitを入れとけばOKとのことだったので、一式をgitリポジトリから持ってきて実行開始。

いきなり「powershellではスクリプト実行できません」攻撃を喰らい撃沈。セキュリティ上の仕様によりスクリプトは実行できない状態にしてあるとかなんとか。いきなり丸腰ってもどうかと思ったので制限付き実行可状態として再度挑戦。

あれやこれやをダウンロードしているようで順調です。が、「cmakeが無い」と苦情。こんなことも有ろうかと思ってcmakeを最新版を入れてPathも通しておいたのですがダメ。よくエラーメッセージを見るとパス決め打ちでそこにcmakeが無いと。しかもバージョンまで決め打ちされているのでcmakeのアーカイブから当該バージョンを引っ張ってきて、再挑戦。

が、結果的には最後のあたりでエラーになって結局は自前buildには失敗です。

本家ではどうやってパッケージを作成してんでしょうね。毎度のことながら謎だ。

FC39その2

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

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

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

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

FC39

ラジオ放送の整理で時間がとられている間に39がリリースされていました。
Fedoraは半年ごとに更新なのでお約束ではありますが、見た感じ大きく変わったところが無いので更新しがいが…

もたもたしていると40が出てしまうので早めに更新しないとね。
クリーンインストールはできないので祈るようにして実行するdnf upgrade….
さて今回はどうなることやら。

やばいやばい

-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です。
いや、もっと早く気づいていれば楽できたのにな…