NetBSDのパッケージ管理情報が/usr/pkg/pkgdbと/var/db/pkgで混乱していた

NetBSD/i386にxnp2を入れようとしたら、共有ライブラリのトラブルが発生したので、pkginを使ってfull-upgradeを試みました。そうしたら、MATEが消えてしまい、ログインできなくなりました。あらためてpkginでMATEをインストールしようとしたら、多くのエラーメッセージが出て、インストールできません。

 

以前であれば、問題解決のためにGoogleで検索して似たような事例を探していたのですが、最近はGeminiに相談するようになりました。MATEのパッケージがインストールできないので解決したいというのが、Geminiに相談したことなのですが、Geminiがアドバイスしてくれたコマンドを叩くとエラーが発生します。それをGeminiに伝えると、また別のアドバイスをくれるので、対話を繰り返していると、次第に深みにはまってきました。

 

トラブルの根本原因は、NetBSDのパッケージ管理情報が/usr/pkg/pkgdbと/var/db/pkgの2か所に存在していることが判明しました。このように2か所に存在しているので、双方の情報が重複したりしていて、不整合も発生しているようです。こうなってしまうと、MATEがどうこうという問題よりも、この不整合を如何に解決するかという方が、重大な問題になりました。

 

Geminiのアドバイスを貰いながら対処を試みましたが、深刻な障害が解消しません。多少強引ですが、最後の奥の手として、インストール済みのパッケージをリストしておき、インストール済み全パッケージを削除し、あらためてインストールしなおすことにしました。

 

今は、インストール済のパッケージを削除しているところです。1,000以上ものパッケージがインストールされていたので、削除するだけでも長時間かかります。削除が終わったら、再インストールしますが、それも長時間かかるでしょう。 

NetBSDにバイナリパッケージxnp2を入れたらMATEが動かない

NetBSDのパッケージにはPC98エミュレータxnp2が含まれていることがわかったので、バイナリパッケージを入れてみました。バイナリパッケージを入れるのに「pkgin」を利用しています。OSがNetBSD/i386 9.0なので、パッケージ2025Q4のNetBSD/i386の9.0用を参照しました。

 

xnp2に依存関係のあるパッケージが有るのか無いのか不明ですが、最近1年以上もパッケージを更新していなかったので、追加更新に60個弱のパッケージが必要になりました。各々のパッケージが本当に必要なのか厳密に確かめることができるかもしれませんが、それをするなら「pkgin」を使う意味がないと思い、それらのパッケージを全てインストールしました。

 

インストール自体には問題がありませんでしたが、ログインできなくなりました。正確には、XDMでログインしたあとで、MATEを動かしているのですが、共有ライブラリが見つからないとのことで、XDMログイン画面に戻ってしまいます。rootは、MATEではなく,TWMのままなので、問題ありませんでした。「~/.xsession-errors」を確認すると、共有ライブラリが見つからないとあります。確かにその通りでしたが、シンボリックリンクを張れば解決できそうなので、対処しました。そして再度ログインしてもXDMに戻ってしまいます。別の共有ライブラリが見つからないようです。これを繰り返したら、最終的に共有ライブラリに定義されていないものがあるというエラーになりました。

 

もうお手上げなので、Geminiに相談したら、libxkbcommonという共有ライブラリを再インストールすることを勧められました。やってみましたが、解決しませんでした。それをGeminiに訴えると「pkgin full-upgrade」を試してみるように言われました。これなら解決できそうですが、作業時間が長いですし、xnp2とは関係ないところで、別な不具合が出てくるかもしれません。

 

しかし、これ以外に対処方法はないと思うので、もう後戻りはできない状態になっています。何か別の問題がでたら、また解決方法を模索するしかないでしょう。 

NetBSDでPC98エミュレータ

Windows 10を使っていたころに、T98-NEXTというPC98エミュレータを使ってWizardryを遊んでいました。「PC-9800シリーズエミュレータの現況」という記事によると、PC98エミュレータは他にもあるようです。しかしMicrosoft Windowsなら選択肢は多いかもしれませんが、非Windowsでは選択肢が限られると思います。

 

ちょっと検索したら、次のような記事が見つかりました。これらの記事では、NP2kai（Neko Project II 0.86 kai）を使って、ソースからビルドしているようです。OSにはUbuntuを使っているようなのですが、私はNetBSD/i386を使いたいのです。

• 令和の時代にLinuxにPC-98x1エミュレータを入れる
• Ubuntu 22.04で98エミュレータを動かす

 

上述した記事を参考にすれば、NetBSD/i386環境であっても、ソースからビルドできるのではないかと思います。ビルド環境を整えたり、ビルドしてみてエラーが出るかもしれませんし、何かと手間がかかるだろうとは思います。もしかしたら何の苦労もなくビルドできてしまう可能性もありますが、そう簡単ではないだろうと予想しています。

 

自前でビルドする前に、ちょっとパッケージを確認したら、なんと「emulators/xnp2」がありました。これは「Xnp2 is a port for UNIX with X11 of "Neko Project II" PC-9801 emulator.」だそうです。自前でビルドしなくても、既にパッケージが用意されていました。

 

このパッケージをインストールしてみようと思います。このPC98エミュレータでWizardryを動かしてみようと考えていますが、問題なく無事に動いてくれるか心配です。もしトラブルようであれば、デバッグすることになるかもしれませんので、自前でビルドできる環境を整えておく必要が出てくるかもしれません。 

モバイルSuicaを使ってみる

スマホにモバイルSuicaの設定を済ませたので、実際に利用してみました。何かトラブルが発生するのではないかと戦々恐々だったのですが、何事もなく、あっさりと利用できました。あまりにも何も問題がないので、驚いています（問題がなくて、あたりまえだとは思いますが）。

 

強いて言えば、スマホケースにストラップを付け、胸に下げているのですが、そのため改札を通る際に、多少腰をかがむ必要があるくらいでしょうか。

この調子なら、Smart ICOCAのクイックチャージのサービスが終了しても、モバイルSuicaに移行出来そうです。

/var/spool/clientmqueue

FreeBSD/amd64を使用して自宅のメール環境を構築しています。fetchmailで取り込み、procmailで振分け、GNUSでメールを読んでいます。メールを送る時はmewを使うか、場合によってはMicrosoft Windows上のThunderbirdを使用しています。数日前、procmailを呼び出すのに、.forwardで指定するのを止めて、.fetchmailrcに変更したところでした。

 

procmailの呼び出し方法を変えただけなので、これまでと同様にメールが振り分けられるはずです。実際その通りなのですが、FreeBSD/amd64自身のrootが送信したメールが見当たらないことに気づきました。root宛のメールは、aliasesでローカルユーザに渡しています。

 

まず最初に確認するのはログファイルです。/var/log/maillogを除くと、エラーが記録されています。同じようなエラーが何度も出力されているようです。目視した限りでは、次のエラーでした。

1. alias database /etc/mail/aliases.db out of date
2. get_error=error:0A000126:SSL routines::unexpected eof while reading
3. info=Bare carriage return (CR) not allowed

 

1番目のエラーは、Webを検索すると「FreeBSD: サーバーOS更新 12.3 → 12.4」という情報が見つかりました。newaliasesすれば良さそうです。

 

2番目と3番目は手強そうなので、Geminiに助けを求めました。Geminiは、「その問題なら、こうすれば解決しますよ」とか気軽に応答するのですが、なかなか解決に至りません。しかも提示された解決策を試みるとエラーが出るので、それを報告すると、「すいません、間違っていました。本当は、この方法です」と別な方法を示してきます。生成AIの回答らしいと言えば、そのとおりです。その分野のエキスパートに尋ねても、やっぱりこうなるかもしれません。生成AIなら、現実の人間と違って、何度訊き返しても嫌がったり怒り出したりする心配がないのは、メリットのような気がします。

 

Geminiとの対話を2時間ほど費やしたあげく、なんとか解決に至りました。いろいろ試したし、試行した内容を取り消したりもしたので、混乱しましたが、次のような対策を講じました。

1. /etc/mail/ホスト名.submit.mcに「FEATURE(`msp', `[127.0.0.1]', `MSA', `E')」を追加した。
2. /etc/mail/ホスト名.mcに「DAEMON_OPTIONS(`Name=IPv4, Family=inet, Modifiers=b')」と変更した。IPv6の方も同様に変更した。

 

このように変更してsendmailサービスを再起動すると、溜まっていたメールが流れる「はず」だったのですが、溜まったままでした。Geminiも半ばお手上げ状態で、スプールにあるメールを「tr -d '\r'」しながら、senmailに渡し、強制的に配送しました。これが成功したので、スプールにあるファイルは物理的に削除しました。

 

そもそも、何故このような事態に陥ってしまったのか、その原因は不明です。前回と今回の問題解決において、Gemini（というか生成AI）の威力を実感しました。それと同時に、間違い（勘違い？）を含む回答もしてくるので、Geminiの回答を鵜呑みにするわけにはいかないだろうと思います。そういう意味で、Geminiの指示に淡々と従うわけにはいかないでしょう。生成AIがあれば、何も勉強しなくても万々歳とはならないと思います。 

BIMI-Indicator

自宅では、FreeBSD/amd64を使用してメール環境を構築しています。fetchmailで取り込み、procmailで振分け、GNUSで読んでいます。つい最近になって、ふと気づくと/var/spool/mqueueに配送できなかったメールが溜まっていることに気づきました。

 

溜まっているファイルを確認したら「SMTP error: 552 5.6.0 Headers too large (32768 max)」というエラーが記録されています。他のファイルも同様でした。このメッセージを手掛かりにWebを検索してみたのですが、解決に至る情報がみつかりませんでした。そこでGeminiに助けを求めてみました。

 

Geminiとの対話では、このメッセージを提示するところから始めました。これだけの情報では、一般論しか返ってこないので、対話を繰り返しながら、問題が解決できるような方向に話を進めました。解決策は幾つかあるようです。これまでは、上述したように、fetchmailで取り込み、.forward経由でprocmailを呼び出して振分けていました。.forwardを利用することでsendmailが介入することになりますが、問題となっているメールには「BIMI-Indicator」という巨大なヘッダがついていて、これが根本的な問題だろうと思います。

 

メッセージが指摘するように「Headers too large」なので、sendmailが「32768 max」という制限をかけているのを緩和するのも一つの方法です。他の方法として、fetchmailから直接procmailを呼び出すこともできて、そうすれば.forwardを使わないので、sendmailが介入することもありません。こちらの方法を採用することとして、.fetchmailrcに設定を追加しました。

 

対策を講じたことで、問題は解決したようです。

 

本来であれば、巨大な「BIMI-Indicator」というヘッダをつけている送信元が対処して欲しいところです。サイトのメールサーバの設定によっては、32kで制限をかけているところがあるでしょうから、そこでも問題が発生しているのではないかと思います。

Windows11のメディアプレイヤーでCD情報が表示されないのはspecificationなのかundocumented featureなのか

2025年12月初め頃から、Windows11のメディアプレイヤーにおいてCD情報が表示されなくなっているという報告がありました。Microsoftからは公式アナウンスが出ていないようなので、偶々何かの調子が悪いだけなのか判断できませんでした。2026年に入ってからは、Web上に次のような情報があります。あいかわらずMicrosoftから公式発表がないので、憶測でしかありません。

• 仕様が変わった？ Windows Media Playerやメディアプレーヤー、CDの楽曲情報取得が不可能に 
• Windowsメディアプレイヤーに異変→まさかの機能終了に惜しむ声「やっぱり不便」「乗り換えですかね…」 

 

なぜMicrosoftが公式に何も発表しないのかわかりませんが、そもそも「仕様」だったのだろうかという疑問をもちます。MicrosoftがWindowsを開発するにあたり、社内的には何らかの仕様書が存在する（はずだと思いますが、さすがに）のでしょうけれども、それが外部に伝わることはありません。私自身としては、Microsoft Windowsの一人のユーザとして、「Windows仕様書」というものは、これまでに見たことがありません。「ウィンドウズの使い方」のような文書なら見たことがありますが、それは「仕様書」というほどのものではなくて、「このような使い方がありますよ」という簡単な説明でしかありません。

 

メディアプレイヤーを使うとCD情報が表示されるということは、昔から気付いていましたが、それが「仕様に基づく」のか「偶々そうなっているだけ（実は何かのバグ？）」なのか、はっきりした説明を受けたことはありません。暗黙のうちに、CD情報が表示されるのが「仕様ではないか」と思い込んでいただけなのかもしれません。むしろ「undocumented feature」だったのかもしれません。

 

「仕様」だったのであれば、Microsoftに対して正式に説明を求めることができるとおもいます。しかし「undocumented feature」なのであれば、Microsoftに問い合わせても「そのような挙動が過去にあったとしても、メディアプレイヤーの機能の一部ではありません」と回答されて終わりになってしまうでしょう。

 

遥か昔にTK-85で8085を学んでいたころ、16x16のマトリクスで示されている命令一覧において、空白（未定義）となっているところにも、面白い動作をする「未定義命令」が隠してありました。しかし正式な命令として仕様書に記載されていたわけではありませんから、正式に問い合わせても（そんなことをした経験はありませんが）、正式に「知りません」と回答されるのがオチでしょう。

 

閑話休題。メディアプレイヤーが、今後もCD情報を表示しないのか、突然復旧するのか、皆目見当もつきません。僕個人の対策としては、Apple iTunesをインストールすることにしました。Windows10の頃には使用していましたが、Windows11に移行するにあたり不要かと考えていました。手持ちの音楽CDをメディアプレイヤーで再生できないわけではありませんが、CD情報が出ないのは、多少気になります。そのためだけにiTunesを利用するつもりです。