NetBSD/i386 9.4でxnp2 0.86が動作した

NetBSD/i386 9.4環境で、パッケージからnxp2をインストールしようとしました。そうしたら共有ライブラリの不整合が発生し、pkgin full-upgradeを実行しました。するとエラーが出て、Geminiに相談しながら調査したら、パッケージ管理ディレクトリが/var/db/pkgと/usr/pkg/pkgdbの2箇所に見つかり、これが原因で深刻な不整合が起きていることが発覚しました。Geminiのアドバイスを受けながら、インストール済みの全パッケージを削除し、入れ直しました。しかし欠けているパッケージがあるので、確認しながら、追加インストールして、ようやくMATEデスクトップ環境が復活しました。

 

あらためて、本来の目的だったxnp2をインストールしました。何も問題がなくインストールできました。

 

動かしてみたのですが、PC-9801の起動時画面が出るはずですが、文字がかすれて読めません。フォントを別途入手する必要があるようです。Neko Project 21/Wのサイトから「font.bmp」を入手して「~/.np2/font.bmp」に置きました。これで起動時画面の文字が読めるようになり、一歩前進です。

 

次は、Wizardryが動くか確認しようと思います。 

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/i386 9.1でパッケージを9.0_2020Q4に更新

dynabook SS SX/15AにNetBSD/i386を入れて使っています。OS本体やパッケージを更新する作業を時々おこなっています。OS自体は昨年末に9.1にしたので、今度はパッケージを9.0_2020Q4で更新しました。

パッケージはpkginを使って、バイナリで更新します。いきなり更新作業を始めると、必要なパッケージをダウンロードしようとして、何故かストールしてしまうので、事前に別のマシンで必要なパッケージを入手しておきます。必要なパッケージは576もありました。これを/var/db/pkgin/cacheに置いておきます。 

pkgin full-upgradeで、全て更新してくれるはずなのです。しかし途中で何やらエラーが発生したようで、2時間半たって処理が完了した時点では、必要なパッケージがゴッソリ消えて、不完全な状態になっていました。エラーログを見て、問題がありそうなファイルを見つけて、個別に対処しました。まったくエラーのない状態には出来ませんでしたが、なんとか復旧できたと思います。

エラーログを確認していると、パッケージ構成スクリプトのバグではないか？と思わせるような記録も残っています。もしかすると気付かないところで、問題が残っている可能性もあると思います。

いろいろと苦労しますが、そのような問題を解決していく過程も、技術力を磨くには良いのかもしれません。

NetBSD/i386のパッケージ2019Q2

dynabook SS SX/15AにNetBSD/i386を入れて使っています。つい先日パッケージを2019Q1から2019Q2に更新しました。更新したら、動かなくなったものがあります。気がついているのは以下の3点ですが、もしかしたら気付いていないものがあるかもしれません。

1. 2019Q1の頃に自前でビルドしたfirefoxが起動しない。
2. MATEの時計パネルが起動しない。
3. 一般ユーザのメニューに「シャットダウン」が現れない。

なぜ動かないのか詳しく調べていかなければなりませんが、まずfirefoxが起動しない原因を調べました。すると2019Q2に更新したことで、共有ライブラリのバージョンが変わってしまって「file not found」になっているのが問題でした。恐らく他の不具合も、同様の原因でしょう。

そもそも2019Q2への更新はpkginを利用しましたが、その参照先には必要なパッケージが揃っていないようです。i386版とamd64版とでは、（理由は不明ですが）準備されているパッケージの数が異なっています。

例えばMATEデスクトップ環境に関するパッケージは、amd64版では26ファイルありますが、i386版では10ファイルしかありません。i386版では16ファイル少ないわけですが、その不足するファイルがMATEデスクトップ環境を調える上で不要というわけでもありません。バイナリ版が用意されていないならば、pkgsrcから自前でビルドする必要があります。

i386版そのものが時代遅れとなりつつあるのだろうと思いますが、ビルド済みのパッケージがamd64版とi386版とで揃っていないのは不便です。なんとかならないかなと思います。

pkgin full-upgradeは何をしようとしているんだろうか

dynabook SS SX/15AにNetBSD/i386を入れて使用しています。パッケージの2019Q1を入れていましたが、2019Q2が出ているのでpkginで更新しようと考えています。

pkgin full-upgradeで一括して入れ換えてしまおうと思っていますが、ファイル転送でstallしてしまいます。pkginにはオプション「-d」を指定することで、ファイル転送だけをおこなうことができるようです。ところがファイル転送で頻繁にstallするので、なかなかインストールまで辿りつきません。

pkginは、更新を始める前に対象となるファイル名（.tgzファイル） を表示します。その情報を加工して、pkginを使わず、ftpコマンドでファイルをダウンロードしておくことにしました。必要なファイルが/var/db/pkgin/cacheに存在すれば、pkginとしてはインストールしてくれるようです。

それは良いのですが、更新対象となるファイルが異常に多すぎる気がします。例えば、今までTeXはインストールしていなかったのに、更新対象にしています。細かくは確認していませんが、他にも謎の更新対象があるのではないかと思います。

どうしてこういうことになるんでしょう。

NetBSDのpkginでstallする

dynabook SS SX/15AにNetBSD/i386を入れて使用しています。以前は、OS本体もパッケージもcurrentのソースから自前でビルドしていました。しかしビルド時間がかかりすぎる（1週間以上かかります）し、それだけならまだしも、無線LANの接続が切れたり、カーネルパニックが発生したりして、何度もリブートし再開するはめに陥るので、ビルド済みのバイナリを入れるだけに方針を転換しました。

数か月前にpkgを入れた時は2019Q1だったのですが、2019Q2が出ているので、更新することにしました。pkginを使って更新することにしているので「pkgin full-upgrade」 をおこないました。更新対象のパッケージ（.tgzファイル）をダウンロードしてからインストールが始まる筈なのですが、ファイル転送中にstall状態になります。たまに発生するなら我慢もできますが、10分もしないうちに発生するので、とても困ります。

stallしてファイル転送できなかったファイルは、再度pkginを実行すると再転送しようとするのですが、そこでまたstallします。勘弁してくれという気持ちになります。しかしそのファイルを、本家またはミラーサイトからftpでダウンロードする分には、何も問題なく転送できます。うまくいって結構なことなのですが、なぜpkginではstallするのに、ftpなら問題ないのでしょうか。

 ハードウェアが旧いので、あちこちにガタがきている可能性は否定できません。はっきり確認する手段がないので憶測ですが、ハードウェアが旧いことだけが原因ではないような気がします。

KeePassXCの拡張機能「ブラウザー統合」が無効

dynabook SS SX/15AにNetBSD/i386を入れ、MATEデスクトップ環境を利用しています。パスワードを管理するために、以前はKeePassを使おうとしていましたが不安定（すぐに落ちてコアを吐く）だし、pkgsrcにあるソースからビルドしようとしても、依存関係にあるMonoがビルド出来なかったりで、散々でした。KeePassを使い出した頃は選択肢が他になかったのですが、今ではKeePassXCがpkgsrcに入っているので、こちらを使用することにしました。

KeePassXCはブラウザ側にアドオンを入れることで連携できるようになるそうです。連携できると何か便利になるのか、それとも無くても構わないものなのか、体験してみないことには判断できません。ブラウザにはFirefoxを使っているので、アドオン「KeePassXC-Browser」を入れて、どんなものなのか動作を確認してみようとしました。ブラウザ側のアドオンを使うには、KeePassXC側の設定「ブラウザー統合」で利用するブラウザを選んでおく必要があるそうです。そこでKeePassXCの設定画面を開いたのですが、「ブラウザー統合」という項目がありません。

Webで情報をあつめてみても、「ブラウザー統合」 という設定項目は存在しているもののようです。事前に何かの設定を有効しておく必要があるとか、前準備が要るというものではないようです。しかしNetBSD/i386のpkgsrc 2019Q1にあるKeePassXCには「ブラウザー統合」がありません。どういうことでしょう？

この現象が起きているのは、僕のマシンが不良なのか、NetBSDの問題なのか、KeePassXCの特定のバージョンに起因する障害なのか、原因を絞り込まなければなりません。Webを検索して直ちに解決策が見いだせれば良いのですが、「ブラウザー統合がメニューに出てこないのは何故？」というような質問をしている人は見つかりませんでした。

NetBSDでMATEデスクトップ環境を利用する上で、何かの調査に役立つかと思って、Microsoft WIndows10上のVirtualBoxでUbuntu MATEの環境を作ってありました。ここにKeePassXCを入れてみて、NetBSDとの違いを確認してみます。すると驚いたことに、設定画面には「ブラウザー統合」が最初からありました。やはり存在するのが当たり前ということなのでしょう。

UbuntuのKeePassXCには設定「ブラウザー統合」があり、NetBSDのKeePassXCには設定「ブラウザー統合」がありません。その事実は確認できましたが、もっと情報を集められないでしょうか。KeePassXCのメニューの中に「デバッグ情報」という画面がありました。

まずNetBSDでは以下にようになっています。

KeePassXC - Version 2.4.0

Libraries:
- Qt 5.12.2
- libgcrypt 1.8.4

Operation system: NetBSD 8.99.43
CPU architecture: i386
Kernel: netbsd 8.99.43

Enabled extensions:
- Auto-Type

次にUbuntuでは以下のようでした。

KeePassXC - Version 2.4.3
Revision: 5d6ef0c

Qt 5.9.5
Debugging mode is disabled.

Operation System: Ubuntu 18.04.2 LTS
CPU architecutre: i386
Kernel: linux 4.18.0-15-generic

Enabled extension:
- Auto-Type
- ブラウザー統合
- SSHエージェント
- KeeShare (signed and unsigned sharing)
- YubiKey

Cryptographi libraries:
libgcrypt 1.8.1

どうやら拡張機能「ブラウザー統合」が利用できない状態になっているようです。それは確認できましたが、なぜ利用できないのか、その原因は不明のままです。NetBSDにある共有ライブラリの何かに問題があるのかもしれませんし、拡張機能「ブラウザー統合」が利用できるのはLinuxとかWindowsなどに限定されているのかもしれません。

GitHubにあるKeePassXCの「Build and Install KeePassXC」を見ると、衝撃的な記述がありました。

cmake accepts the following options:

-DWITH_XC_AUTOTYPE=[ON|OFF] Enable/Disable Auto-Type (default: ON)
-DWITH_XC_YUBIKEY=[ON|OFF] Enable/Disable YubiKey HMAC-SHA1 authentication support (default: OFF)
-DWITH_XC_BROWSER=[ON|OFF] Enable/Disable KeePassXC-Browser extension support (default: OFF)
-DWITH_XC_NETWORKING=[ON|OFF] Enable/Disable Networking support (e.g., favicon downloading) (default: OFF)
-DWITH_XC_SSHAGENT=[ON|OFF] Enable/Disable SSHAgent support (default: OFF)
-DWITH_XC_TOUCHID=[ON|OFF] (macOS Only) Enable/Disable Touch ID unlock (default:OFF)
-DWITH_XC_FDOSECRETS=[ON|OFF] (Linux Only) Enable/Disable Freedesktop.org Secrets Service support (default:OFF)
-DWITH_XC_KEESHARE=[ON|OFF] Enable/Disable KeeShare group synchronization extension (default: OFF)
-DWITH_XC_KEESHARE_SECURE=[ON|OFF] Enable/Disable KeeShare signed containers, requires libquazip5 (default: OFF)
-DWITH_XC_ALL=[ON|OFF] Enable/Disable compiling all plugins above (default: OFF)

拡張機能「ブラウザー統合」を利用するためにはビルド時に「-DWITH_XC_BROWSER」を指定しなければなりませんが、デフォルトは「OFF」なので、あえて指定してビルドしない限り「ブラウザー統合」が無効になっているKeePassXCが出来上がってしまうのです。

pkginが拾ってくる2019Q1の出来合いのバイナリは、拡張機能が無効になったままでビルドされたのでしょう。デフォルトが「ON」になっている拡張機能は「Auto-Type」だけのようですから、上述したデバッグ情報に出ているものと一致します。

ここまで確認したところで、pkgsrc「security/keepassxc」をビルドさせてみました。コンパイルが始まる前の環境設定情報収集フェーズのログを見ると、案の定、ほとんどの拡張機能が無効になったままでした。

-- Enabled features:
 * Auto-Type, Automatic password typing

-- Disabled features:
 * Networking, Compile KeePassXC with network access code (e.g. for downloading website icons)
 * KeePassXC-Browser, Browser integration with KeePassXC-Browser
 * SSHAgent, SSH agent integration compatible with KeeAgent
 * KeeShare, Sharing integration with KeeShare
 * KeeShare-Secure, Sharing integration with KeeShare with secure sources
 * YubiKey, YubiKey HMAC-SHA1 challenge-response

-- Configuring done
-- Generating done
-- Build files have been written to: /usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/build
=> Rewrite cmake Dependencies files
===> Building for keepassxc-2.4.0

これで原因が判明しました。pkgsrcをビルドすると、拡張機能「ブラウザー統合」が無効になったKeePassXCが出来てしまうのです。これを有効にしたければ、pkginなどで出来合いのバイナリパッケージを利用しては駄目だということです。自分でソースからビルドさせる必要があるでしょう。

共有ライブラリの参照状況を確認

dynabook SS SX/15AにNetBSD/i386を入れ、アプリケーションはpkgsrcから入れています。もう1年以上もアプリケーションを更新していなかったので、6月上旬にpkgsrcをCVSでカレントの最新にしてpkg_rolling-replaceで作りなおし始めました。しかし導入済みのアプリケーションが多く、もとより数日で終わるとは思っていませんでしたが、ディスクが溢れたり、毎晩カーネルが落ちて日中の作業が無駄になったりして、6月下旬になっても全更新作業が終わりませんでした。

このままでは何時になったら全更新が完了するのか不安になってきたので、ソースから自前でビルドｓるのを止めて、pkginを使って出来合いのバイナリ（2019Q1のpkgsrcからビルドされたもの）をインストールして済ませることにしました。流石にバイナリを入れるだけなので、ソースからビルドするのに比べると圧倒的に速く全更新が完了しました。

しかしpkgsrcのカレントからビルドしたパッケージと、2019Q1のpkgsrcからビルドされたパッケージが混在し、共有ライブラリの参照に不整合が生じてしまいました。不整合に気づくたびに対処していく事で、復旧できるのは確かですが、全体的に不整合が残っているのか解消したのか、判断できず不安が残ります。なんとかしたいので、対処してみました。

実現方法の詳細はともかくとして、やろうとすることは単純です。すなわち/usr/bin/lddで検査して異常がないことを確認するだけです。例えば以下に示す例ではlibclang.so.7が見つからずに「not found」となっています。参照できない状態がなければ問題ないと判断します。

/usr/pkg/qt5/bin/qdoc:
        -lexecinfo.0 => /usr/lib/libexecinfo.so.0
        -lelf.2 => /usr/lib/libelf.so.2
        -lgcc_s.1 => /usr/lib/libgcc_s.so.1
        -lc.12 => /usr/lib/libc.so.12
        -lclang.7 => not found
        -lQt5Core.5 => /usr/pkg/qt5/lib/libQt5Core.so.5
        -lz.1 => /usr/lib/libz.so.1
        -licui18n.63 => /usr/pkg/lib/libicui18n.so.63
        -licuuc.63 => /usr/pkg/lib/libicuuc.so.63
        -licudata.63 => /usr/pkg/lib/libicudata.so.63
        -lpthread.1 => /usr/lib/libpthread.so.1
        -lstdc++.8 => /usr/lib/libstdc++.so.8
        -lm.0 => /usr/lib/libm.so.0
        -lpcre2-16.0 => /usr/pkg/lib/libpcre2-16.so.0
        -lgthread-2.0.0 => /usr/pkg/lib/libgthread-2.0.so.0
        -lglib-2.0.0 => /usr/pkg/lib/libglib-2.0.so.0
        -lpcre.1 => /usr/pkg/lib/libpcre.so.1
        -lintl.1 => /usr/lib/libintl.so.1

/usr/bin/lddの出力から「not found」を見つけるために、簡単なawkスクリプトを準備しました。文字列を検索するだけならgrepでも出来ますが、見つかった文字列の属しているファイル（この例であれば/usr/pkg/qt5/bin/gdoc）が何なのか記録できません。awkスクリプトは次のようなもので、単独のコマンドとして使えるように、実行ビットを立てておきます。

#!/usr/bin/awk -f
/:$/ {
        filename = $0;
}
/not found/ {
        print filename, $0;
}
# [EOF]

共有ライブラリの参照に問題があるのは、動的リンクされた実行ファイルや共有ライブラリだけです。静的リンクされた実行ファイルとかテキストファイルなどは検証する必要がありません。当初は検証対象を限定しようと思っていたのですが、対象ファイルを見つける方法を考えるのが面倒になってきたので、強引ですが、マシン内の全てのファイルを対象とすることにしました。処理に無駄が出ますが、単純な処理で済みますし、結果をファイルに落としておいて最終的に確認すれば良いだけのことです。結局2時間ほどで全ファイルの検証が終わりました。

この検証をおこなったコマンドは以下の通りです。上述したawkスクリプトは「notfound.awk」というコマンドにしています。

find / -type f | sed -e 's/^/ldd "/' -e 's/$/"/' | sh 2>&1 | notfound.awk > notfound.log

findで対象を見つけた場合には、xargsでコマンドに渡すのが定番です。しかしsedとshを組み合わせてコマンドを動かしています。当初はxargsを使おうと思っていたのですが、Microsoft Windows由来のファイルがあり、ファイル名の中に空白文字が含まれるため、findとxargsの組み合わせでは、処理できなかったのです。

結果を記録されたファイルには、予想していたよりも相当多いファイル名が記録されていました。しかし/usr/pkg/optや/usr/pkg/emul/linuxなどにあるLinux版ファイルが大多数を占めており、本当に問題があったのは数ファイルだけでした。それらは対処したので、不整合の問題は解決した（それ以外に起因する問題は残りますが）と思います。

pkg_rolling-replaceを捨て、pkginに乗り換え、アプリケーションの全更新が（ひとまず）完了

dynabook SS SX/15AのOSをNetBSD/i386に入れ換えて使用しています。アプリケーションはpkgsrcから自前でビルドして入れています。もう1年以上も更新していなかったので、全更新をおこなうことにしました。今月上旬からpkg_rolling-replaceを使って更新していましたが、ビルド中にエラーが出たり、ディスクが溢れて処理が止まったり、毎晩深夜にカーネルがパニックして日中の作業が無駄になったりして、七転八倒していました。このまま作業を続けても、いつになったら完了するのが先が見えないので、別の手段を検討することにしました。

U*IXの伝統に則り、アプリケーションはソースからコンパイルして使うのが当然だと考えていたので、pkgsrcを自前でビルドしていたのですが、ビルド済みの出来合いのパッケージをネットワーク越しに取ってきてインストールするだけにするのが、ビルド時間も節約できるし、今風のやり方なのかもしれません。pkg_rolling-replaceを使わなくても、pkg_chkやpkginなどを使えば良さそうです。

そこでpkginを使ってみました。 まずpkgtools/pkginから導入します。/usr/pkg/etc/pkgin/repositories.confの設定は、導入直後は次のようになっていました。

ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/$arch/8.99.43/All

このままではOSのバージョンが不適切なので、エディタで以下のように修正しました。

ftp://ftp7.jp.netbsd.org/pub/pkgsrc/packages/NetBSD/$arch/8.0_2019Q1/All
ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/$arch/8.0_2019Q1/All
ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/$arch/8.0/All

ファイルには複数のリポジトリを記述できるようですが、先頭から順番に使われると考えて良いのでしょうか。そうであると仮定して、先頭に日本のミラーサイトを指定しました。念のためにマスターサイトも書いておきました。

この状態で`pkgin full-upgrade`をおこなうと、次のようになりました。

285 to refresh, 30 to upgrade, 21 to install
338M to download, 471M to install
the following packages have unmet requirements:

一部のパッケージがインストールできませんでした。出力されているメッセージを確認すると、次のようなエラーが多数出ています。

/usr/X11R7/lib/libfreetype.so.18, needed by atril-1.22.0nb3 is not present in this system.

このメッセージの意図するところは、atril-1.22.0nb3というパッケージが必要とする/usr/X11R7/lib/libfreetype.so.18が存在しないということですね。ディレクトリを確認すると、確かに存在しません。しかし/usr/X11R7/lib/libfreetype.so.17なら存在するのです。 

このファイルの出所を探るために/var/db/pkgで「grep libfreetype.so.17 */+CONTENTS」としたら、x11-linksに含まれていることがわかりました。

このようなエラーになっているファイルは他にもあって、いずれも共有ライブラリのバージョン番号が違っているだけです。

1. /usr/X11R7/lib/libGL.so.3
2. /usr/X11R7/lib/libGLU.so.3
3. /usr/X11R7/lib/libfreetype.so.18
4. /usr/X11R7/lib/libglapi.so.1
5. /usr/X11R7/lib/libXpresent.so.1

そもそも何故バージョンがずれているのでしょうか？「pkgin pkg-build-defs atril | grep libfreetype」として確認すると、以下のようになりました。リポジトリに置かれているファイルが、既にそのようになっているのでしょう。

REQUIRES=/usr/X11R7/lib/libfreetype.so.18
REQUIRES=/usr/pkg/lib/libfreetype.so.6

この問題を解決するには、どうしたら良いでしょう。エラーになっているパッケージだけは、自前でビルドすれば良いかもしれませんが、駄目かもしれません。問題のファイルが原因で導入できないパッケージは100弱ほどあるので、自前でビルドしていては、またしても時間がかかってしまいます。

そこでちょっと荒業ですが、既存のファイルに向けてシンボリックリンクを張り、見かけ上ファイルがあるように見せかけることにしました。

lrwxr-xr-x  1 root  wheel      12 May 23  2016 libGL.so -> libGL.so.2.0
lrwxr-xr-x  1 root  wheel      12 May 23  2016 libGL.so.2 -> libGL.so.2.0
-r--r--r--  1 root  wheel  770372 May 23  2016 libGL.so.2.0
lrwxrwxr-x  1 root  wheel      12 Jun 26 14:20 libGL.so.3 -> libGL.so.2.0
lrwxr-xr-x  1 root  wheel      13 May 23  2016 libGLU.so -> libGLU.so.2.0
lrwxr-xr-x  1 root  wheel      13 May 23  2016 libGLU.so.2 -> libGLU.so.2.0
-r--r--r--  1 root  wheel  510338 May 23  2016 libGLU.so.2.0
lrwxrwxr-x  1 root  wheel      13 Jun 26 14:21 libGLU.so.3 -> libGLU.so.2.0
lrwxrwxr-x  1 root  wheel      33 Jun 26 14:24 libXpresent.so.1 -> /usr/pkg/lib/libXpresent.so.1.0.0
lrwxr-xr-x  1 root  wheel      22 May 23  2016 libfreetype.so -> libfreetype.so.17.4.11
lrwxr-xr-x  1 root  wheel      22 May 23  2016 libfreetype.so.17 -> libfreetype.so.17.4.11
-r--r--r--  1 root  wheel  589796 May 23  2016 libfreetype.so.17.4.11
lrwxrwxr-x  1 root  wheel      22 Jun 26 14:22 libfreetype.so.18 -> libfreetype.so.17.4.11
lrwxr-xr-x  1 root  wheel      15 May 23  2016 libglapi.so -> libglapi.so.0.0
lrwxr-xr-x  1 root  wheel      15 May 23  2016 libglapi.so.0 -> libglapi.so.0.0
-r--r--r--  1 root  wheel  281835 May 23  2016 libglapi.so.0.0
lrwxrwxr-x  1 root  wheel      15 Jun 26 14:22 libglapi.so.1 -> libglapi.so.0.0

この状態で、あらためて「pkgin full-upgrade」したところ、ひとまず全ての更新に成功しました。今月上旬にpkg_rolling-replaceで始めたアプリケーションの全更新が、とりあえず完了したことになります。しかし、ディスク不足を解消するためにFirefoxやLibreOfficeを削除してしまっていますから、あらためてインストールしておかなければなりません。

さらに個人アカウントでMateデスクトップにログインしてみると、画面がすっかり初期化されていて、以前の状態が消えてしまっています。しかも、一部の機能にエラーがあり、以前と同じ環境を取り戻すには、まだ調査と作業が必要のようです。

問題は残っていますが、約1か月間に亘りビルドを続けていましたが、一区切りをつけることはできたと思います。