ラベル pkgsrc の投稿を表示しています。 すべての投稿を表示
ラベル pkgsrc の投稿を表示しています。 すべての投稿を表示

2026-02-23

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以上ものパッケージがインストールされていたので、削除するだけでも長時間かかります。削除が終わったら、再インストールしますが、それも長時間かかるでしょう。 

2019-12-18

Maxima、xmaxima、wxMaxima

スマホのアプリで「Maxima on Android」を知り、『スマホで数学!』という書籍が出版されていることを知りました。Maxima自体は以前から知っていましたが、それほど使いこなしている訳でもありません。数式処理ではWolframAlphaを使うことの方が多かったのですが、せっかくなので今後はMaximaを使おうかと思っています。

NetBSD/i386にもpackageにMaximaがあるので、インストールしてみました。ベースとなるMaximaは同じものですが、ユーザインタフェースが異なる3種類がインストールできました。
  1. 端末で使うシンプルなMaxima
  2. 端末版MaximaがX上で動くxmaxima
  3. 数式が綺麗に出るwxMaxima
これらはユーザインタフェースの違いに過ぎず、Maximaの処理結果が変わる訳ではありません。

数式が綺麗なwxMaximaを使いたいところですが、なんだか動きが変です。最も肝心な数式を入出力するウィンドウが出ず、外枠やメニューバーばかりが表示されます。メニューは日本語化もされていて、ちゃんと動いてくれれば文句なしなのですが、これでは使いものになりません。デスクトップ環境にMATEを使っているのがマズいのでしょうか。

xmaximaは、wxMaximaのように美しい数式が表示される訳はありません。端末でmaximaを動かしているのと、見かけは変わらない感じです。ただしグラフを表示させようとすると、自動的に別ウィンドウが開くので、便利と言えば便利です。

端末でmaximaを使うよりはxmaximaの方がマシかなと思っているところです。

今回は試していませんが、Emacs上でMaximaを扱うためのimaximaというものがあるようです。Emacsの中で何でもするような使い方をしている人には向いているのかもしれませんが、僕はそうではありません。Emacsは使いますが、viも使うし、Emacsだけで何でもしたい訳ではありません。でも後日imaximaも試してみようと思います。

2019-11-24

2019Q2でMATEデスクトップ環境を更新

dynabook SS SX/15AにNetBSD/i386を入れて利用しています。最近パッケージ2019Q2を入れたら、MATEデスクトップ環境の動作が変になりました。パッケージ2019Q2は、pkginを使ってバイナリ版を入れたのですが、i386版はamd64版に比べて提供されているパッケージが少ないことが分かりました。中途半端に更新されたので、動作がおかしくなったのではないかと思います。

VirtualBoxでNetBSD/i386とpkgsrc 2019Q2の環境を作り、/usr/pkgsrc/meta-pkgs/mateを使って自前でビルドしました。依存関係にある大物パッケージはpkginでインストールさせておいて、ビルド時間の短縮を図ります。

出来上がったMATE関係パッケージを使って、dynabook SS SX/15AのNetBSD/i386のパッケージを入れ替えます。強引な方法かもしれませんが、pkg_delete -fで既存のMATE関係パッケージを強制的に削除しました。その後でpkg_addで自前でビルドしたMATE関係パッケージをインストールしました。これで、ひとまずうまくいっています。

動作しなくなっていた時計アプレットが動くようになったので、不具合が解消しました。

念のために~/.xsession-errosを確認すると、何やら共有ライブラリが見つからないというエラーが出ています。しかしこのエラーを出しているコマンドがわからないので、/usr/pkg/binだろうとあたりをつけて、lddで調べてみました。するとMATEデスクトップ関係のパッケージが引っ掛かりました。パッケージの名前がmate-で見落としていました。

現状のMATEデスクトップ環境はバージョン1.22なので、pkg_infoの出力から「1.22」が含まれるパッケージを探してみると、名前がmate-で始まっていないMATEデスクトップ環境関連パッケージがあるようなので、それらも更新しておきました。

これで2019Q1から2019Q2への更新は完了だと思います。今後も、MATEデスクトップ環境とfirefoxの更新は自前でビルドする必要がありそうです。

2019-11-21

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版とで揃っていないのは不便です。なんとかならないかなと思います。

2019-07-10

「ブラウザー統合」を有効にしたKeePassXCとFirefoxが接続できない

dynabook SS SX/15AにNetBSDを入れて、利用環境を整えようとしています。ブラウザとしてFirefoxを使うので、パスワード管理ソフトとしてKeePassXCを使ってみようと考えています。pkginを使って入れた出来合いのバイナリパッケージは、「ブラウザー統合」が有効になっていませんでした。仕方ないので、「ブラウザー統合」が有効になるように定義して、自前でビルドしました。

自前ビルド版KeePassXC 2.4.0を立ち上げると、設定画面に「ブラウザー統合」が現れました。そこでFirefoxを選択したのですが、設定が記憶されません。立ち上げるたびに、Firefoxの設定が外れているので、毎回設定する必要がありますが、何が悪いのか分かりません。

ブラウザ(Firefox)側にはKeePassXCと連携するためのアドオンを入れる必要があります。入れたのですが、エラーが出てしまいます。
Cannot connect to KeePassXC.  Check that browser
integration is enabled in KeePassXC settings.

KeePassXCとブラウザが連携すると使い勝手が良いようなのですが、連携しなくてもKeePassXCは利用できる筈です。ひとまず非連携モードで使ってみました。

試しにエントリを準備してみました。使い勝手は、Microsoft WIndowsで利用ているIDMと似ている気がします。そのような使い勝手であることには納得しましたが、なぜか入力文字列が化けてしまいます。文字が全て化けるのではなく、メールアドレスに使われている「@」が「"」に変化してしまいます。どうしてこうなるのでしょう。これが解決しない事には、KeePassXCを本格的に利用するわけにはいきません。なんとかしたいと思います。

ちなみに、自前でビルドして「ブラウザー統合」が有効になりました。しかしブラウザ側と繋がらないし、なくても良さそうなので、 pkginから導入する出来合いのバイナリパッケージを使うことにしようと思います。

「ブラウザー統合」を有効にしたKeePassXCがビルドできた

dynabook SS SX/15AにNetBSDを入れて利用しています。このマシンには元々はMicrosoft Windows Vistaが入っていました。その頃に利用していたIDMというパスワード管理ソフトの代替を探していましたが、KeePassXCが良さそうなので使ってみることにしました。手間暇を惜しむためにpkginを利用して出来合いのバイナリパッケージを使うことにしています。

KeePassXCを起動してみると、なぜか設定画面に「ブラウザー統合」がありません。調べてみたところ、どうやらpkgsrcから作成すると「ブラウザー統合」が無効になっていることが分かりました。そこで「ブラウザー統合」を有効にしたものをpkgsrcから自前でビルドしてみようと思います。

ところがビルドしようとしたらエラーが出ました。
[  5%] Built target keepassxcbrowser_autogen
[  5%] Building CXX object src/browser/CMakeFiles/keepassxcbrowser.dir/NativeMessagingBase.cpp.o
In file included from /usr/include/stddef.h:37:0,
                 from /usr/include/g++/cstddef:50,
                 from /usr/pkg/qt5/include/QtCore/qglobal.h:46,
                 from /usr/pkg/qt5/include/QtCore/qatomic.h:41,
                 from /usr/pkg/qt5/include/QtCore/QAtomicInteger:1,
                 from /usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/src/browser/NativeMessagingBase.h:22,
                 from /usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/src/browser/NativeMessagingBase.cpp:19:
/usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/src/browser/NativeMessagingBase.cpp: In member function 'void NativeMessagingBase::newNativeMessage()':
/usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/src/browser/NativeMessagingBase.cpp:65:5: error: invalid static_cast from type 'std::nullptr_t' to type 'intptr_t {aka int}'
     EV_SET(ev, fileno(stdin), EVFILT_READ, EV_ADD, 0, 0, nullptr);
     ^
*** Error code 1

Stop.
make[2]: stopped in /usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/build
*** Error code 1

このエラーを見るとEV_SET()に問題がありそうです。調べてみると、EV_SET()が使われているのは、どうやらここだけのようです。
% find work/keepassxc-2.4.0/src -type f | xargs grep EV_SET
work/keepassxc-2.4.0/src/browser/NativeMessagingBase.cpp:    EV_SET(ev, fileno(stdin), EVFILT_READ, EV_ADD, 0, 0, nullptr);

しかも、この箇所はLINUX以外のUNIX系OSにしか影響がないようです。ソースの変更状況を確認するとKeePassXC 2.3.0-betaの頃に入ったコードのようです。
    53  void NativeMessagingBase::newNativeMessage()
    54  {
    55  #if defined(Q_OS_UNIX) && !defined(Q_OS_LINUX)
    56      struct kevent ev[1];
    57      struct timespec ts = {5, 0};
    58
    59      int fd = kqueue();
    60      if (fd == -1) {
    61          m_notifier->setEnabled(false);
    62          return;
    63      }
    64
    65      EV_SET(ev, fileno(stdin), EVFILT_READ, EV_ADD, 0, 0, NULL);
    66      if (kevent(fd, ev, 1, nullptr, 0, &ts) == -1) {
    67          m_notifier->setEnabled(false);
    68          ::close(fd);
    69          return;
    70      }
    71
    72      int ret = kevent(fd, NULL, 0, ev, 1, &ts);
    73      if (ret < 1) {
    74          m_notifier->setEnabled(false);
    75          ::close(fd);
    76          return;
    77      }
    78  #elif defined(Q_OS_LINUX)
    79      int fd = epoll_create(5);
    80      struct epoll_event event;
    81      event.events = EPOLLIN;
    82      event.data.fd = 0;
    83      if (epoll_ctl(fd, EPOLL_CTL_ADD, 0, &event) != 0) {
    84          m_notifier->setEnabled(false);
    85          ::close(fd);
    86          return;
    87      }
    88
    89      if (epoll_wait(fd, &event, 1, 5000) < 1) {
    90          m_notifier->setEnabled(false);
    91          ::close(fd);
    92          return;
    93      }
    94  #endif
    95      readLength();
    96  #ifndef Q_OS_WIN
    97      ::close(fd);
    98  #endif
    99  }

EV_SET()に問題がありそうだという事、またLINUX系ディストリビューションには影響がない(から、そちらからのフィードバックで修正される)事は分かりましたが、どのように直したら良いのかわかりません。ただしエラーメッセージを見る分にはキャスト絡みのようです。Webを検索したら「*BSD で kqueue・kevent を使ってみよう」というページが見つかりました。それを見ると、EV_SET()の最後のパラメータはNULLが指定されています。これが問題の原因なのでしょうか。

試しにnullptrNULLに書き換えてみたところ、エラーが消えてビルドに成功しました。ただし、このような変更が正しいのかは、確信がありません。nullptrというのはC++11で導入されたようですが、次のような情報も見つかりました。
  1. NULLとnullptrの違い 
  2. C NULLがC 11 nullptrと等しいか 

ビルド出来ましたが、keepassxc-proxyというのも出来ていました。このためPLISTを変更する必要がありました。
--- PLIST.org   2019-03-23 00:56:41.000000000 +0900
+++ PLIST.new   2019-07-10 09:31:09.155023065 +0900
@@ -1,5 +1,6 @@
 @comment $NetBSD: PLIST,v 1.4 2019/03/22 15:56:41 ryoon Exp $
 bin/keepassxc
+bin/keepassxc-proxy
 bin/keepassxc-cli
 lib/keepassxc/libkeepassx-autotype-xcb.so
 man/man1/keepassxc-cli.1

ちなみにMakefileは次のように変更しました。
--- Makefile.org        2019-03-23 00:56:41.000000000 +0900
+++ Makefile.new        2019-07-10 15:29:19.274685074 +0900
@@ -18,7 +18,7 @@
 USE_CMAKE=     yes
 USE_LANGUAGES= c c++
 CMAKE_ARG_PATH=        ..
-CMAKE_ARGS+=   -DKEEPASSXC_BUILD_TYPE=Release
+CMAKE_ARGS+=   -DKEEPASSXC_BUILD_TYPE=Release -DWITH_XC_BROWSER=ON -DWITH_XC_NETWORKING=ON
 CONFIGURE_DIRS=        build
 
 NOT_PAX_MPROTECT_SAFE+=        bin/keepassxc
@@ -36,6 +36,7 @@
 .include "../../devel/zlib/buildlink3.mk"
 .include "../../graphics/hicolor-icon-theme/buildlink3.mk"
 .include "../../security/libgcrypt/buildlink3.mk"
+.include "../../security/libsodium/buildlink3.mk"
 .include "../../security/argon2/buildlink3.mk"
 .include "../../sysutils/desktop-file-utils/desktopdb.mk"
 .include "../../x11/qt5-qtbase/buildlink3.mk"

2019-07-09

KeePassXCの「ブラウザー統合」は有効に出来そうだけど、ビルド失敗

dynabook SS SX/15AにNetBSDを入れて利用しています。パスワード管理にKeePassXCを使おうと思いましたが、pkgsrcからビルドされるバイナリには拡張機能「ブラウザー統合」が有効になっていないことが分かりました。

この問題を解決するために、pkgsrcの枠組みに沿って変更するためには、どのようにするのが正しい方法なのか不明です。それは追々調べるとして、まずは「ブラウザー統合」を有効にしたバイナリをビルドしてみようと思います。

まずsecurity/keepassxc/Makefileを以下のように変更してみました。またlibsodiumが必要になるようなので、依存関係の定義を追加しました。libsodiumのパッケージ自体も入れておきます。
--- Makefile.org        2019-03-23 00:56:41.000000000 +0900
+++ Makefile    2019-07-09 20:05:49.976935366 +0900
@@ -18,7 +18,7 @@
 USE_CMAKE=     yes
 USE_LANGUAGES= c c++
 CMAKE_ARG_PATH=        ..
-CMAKE_ARGS+=   -DKEEPASSXC_BUILD_TYPE=Release
+CMAKE_ARGS+=   -DKEEPASSXC_BUILD_TYPE=Release -DWITH_XC_BROWSER=ON -DWITH_XC_NETWORKING=ON
 CONFIGURE_DIRS=        build

 NOT_PAX_MPROTECT_SAFE+=        bin/keepassxc
@@ -36,6 +36,7 @@
 .include "../../devel/zlib/buildlink3.mk"
 .include "../../graphics/hicolor-icon-theme/buildlink3.mk"
 .include "../../security/libgcrypt/buildlink3.mk"
+.include "../../security/libsodium/buildlink3.mk"
 .include "../../security/argon2/buildlink3.mk"
 .include "../../sysutils/desktop-file-utils/desktopdb.mk"
 .include "../../x11/qt5-qtbase/buildlink3.mk"

この状態でビルドさせてみると「ブラウザー統合」が有効になっていることが確認できます。
===> Configuring for keepassxc-2.4.0 keepassxc-2.4.0
*SNIP*
-- Enabled features:
 * Auto-Type, Automatic password typing
 * Networking, Compile KeePassXC with network access code (e.g. for downloading website icons)
 * KeePassXC-Browser, Browser integration with KeePassXC-Browser

-- Disabled features:
 * 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

またlibsodiumなどの依存関係も大丈夫そうです。
=> Tool dependency glib2-tools-[0-9]*: found glib2-tools-2.60.3
=> Tool dependency cmake>=2.8.1nb1: found cmake-3.14.5
=> Build dependency x11-links>=1.13: found x11-links-1.15
=> Build dependency cwrappers>=20150314: found cwrappers-20180325
=> Full dependency qrencode>=4.0.2: found qrencode-4.0.2
=> Full dependency hicolor-icon-theme>=0.9nb1: found hicolor-icon-theme-0.17
=> Full dependency libgcrypt>=1.6.0: found libgcrypt-1.8.4
=> Full dependency libsodium>=0.3: found libsodium-1.0.17
=> Full dependency argon2>=20161029nb1: found argon2-20171227
=> Full dependency desktop-file-utils>=0.10nb1: found desktop-file-utils-0.23nb1
=> Full dependency qt5-qtbase>=5.11.2nb3: found qt5-qtbase-5.12.2nb1
=> Full dependency qt5-qtsvg>=5.11.2nb2: found qt5-qtsvg-5.12.2
=> Full dependency qt5-qttools>=5.11.2nb2: found qt5-qttools-5.12.2
=> Full dependency qt5-qtx11extras>=5.11.2nb2: found qt5-qtx11extras-5.12.2

これでビルド出来るかと思いきや、なにやらエラーが出てしまいました。
[  5%] Built target keepassxcbrowser_autogen
[  5%] Building CXX object src/browser/CMakeFiles/keepassxcbrowser.dir/NativeMessagingBase.cpp.o
In file included from /usr/include/stddef.h:37:0,
                 from /usr/include/g++/cstddef:50,
                 from /usr/pkg/qt5/include/QtCore/qglobal.h:46,
                 from /usr/pkg/qt5/include/QtCore/qatomic.h:41,
                 from /usr/pkg/qt5/include/QtCore/QAtomicInteger:1,
                 from /usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/src/browser/NativeMessagingBase.h:22,
                 from /usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/src/browser/NativeMessagingBase.cpp:19:
/usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/src/browser/NativeMessagingBase.cpp: In member function 'void NativeMessagingBase::newNativeMessage()':
/usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/src/browser/NativeMessagingBase.cpp:65:5: error: invalid static_cast from type 'std::nullptr_t' to type 'intptr_t {aka int}'
     EV_SET(ev, fileno(stdin), EVFILT_READ, EV_ADD, 0, 0, nullptr);
     ^
*** Error code 1

Stop.
make[2]: stopped in /usr/pkgsrc/security/keepassxc/work/keepassxc-2.4.0/build
*** Error code 1

なかなか一筋縄ではいきません。この問題を解決する方法を探ってみます。

2019-07-08

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などで出来合いのバイナリパッケージを利用しては駄目だということです。自分でソースからビルドさせる必要があるでしょう。

2019-07-05

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

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

このままでは何時になったら全更新が完了するのか不安になってきたので、ソースから自前でビルドsるのを止めて、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でコマンドに渡すのが定番です。しかしsedshを組み合わせてコマンドを動かしています。当初はxargsを使おうと思っていたのですが、Microsoft Windows由来のファイルがあり、ファイル名の中に空白文字が含まれるため、findxargsの組み合わせでは、処理できなかったのです。

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

2019-07-04

2019Q1のpkgsrcにあるmail/thunderbirdがビルド出来なかった

dynabook SS SX/15AにNetBSD/i386を入れて利用しています。2019Q1のpkgsrcからアプリケーションを入れていますが、firefoxやthunderbirdが見当たりません。見当たらなければ自前でビルドすれば良いのですが、このマシンでビルドするのは躊躇します(トラブルを抱えているので)。そこでWindows10のデスクトップPCに入れてあるVirtualBoxでNetBSD/i386の環境を用意して、そこでビルドさせ、出来上がったパッケージをdynabookにインストールさせることにしようと思います。

時間はかかりましたが、firefoxはビルド完了しました。つぎにthunderbirdをビルドしようとしたら、途中でエラーになります。ビルドを行っているVirutalBoxでのNetBSD/i386環境は、このビルドのために新規に準備したので、何かに使っていたものを流用した訳ではありません。何か悪さをするような設定が紛れ込んでいるとも思えません。

何かする度に、いちいちトラブルが起きると、正直なところブルーになります。しかしあまり目くじらを立てず、回避策を探りながら、前に進んでいこうと思います。今回のthunderbirdのトラブルであれば、pkgsrcに入っているmail/thunderbirdのビルドを諦め、mail/thunderbird52にしておくつもりです。将来的にビルド出来るようになった時点で入れ換えれば良いでしょう。

ちなみにエラーは以下のようになりました。rustでコンパイルしていてエラーが出たようですが、どこに問題があるのか、よく分かりません。
gmake[3]: Entering directory '/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/rust'
force-cargo-library-build
env   RUSTFLAGS='-C opt-level=2 -C debuginfo=2 '  CARGO_TARGET_DIR=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library RUSTC=/usr/pkg/bin/rustc MOZ_SRC=/usr/pkgsrc/mail/thunderbird/work/thunderbird-60.6.0 MOZ_DIST=/usr/pkgsrc/mail/thunderbird/work/build/dist LIBCLANG_PATH="/usr/pkg/lib" CLANG_PATH="/usr/pkg/bin/clang" PKG_CONFIG_ALLOW_CROSS=1 RUST_BACKTRACE=full MOZ_TOPOBJDIR=/usr/pkgsrc/mail/thunderbird/work/build  MOZ_CARGO_WRAP_LDFLAGS="-lpthread -Wl,-R/usr/pkg/lib/thunderbird -L/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib -Wl,-R/usr/pkg/lib -L/usr/pkg/lib/nspr -Wl,-R/usr/pkg/lib/nspr -L/usr/pkg/lib/nss -Wl,-R/usr/pkg/lib/nss -L/usr/X11R7/lib -Wl,-R/usr/X11R7/lib -L/usr/pkg/lib/ffmpeg3 -Wl,-R/usr/pkg/lib/ffmpeg3 -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,--build-id -Wl,-rpath-link,/usr/pkgsrc/mail/thunderbird/work/build/dist/bin -Wl,-rpath-link,/usr/pkg/lib" MOZ_CARGO_WRAP_LD=" /usr/pkgsrc/mail/thunderbird/work/.cwrapper/bin/gcc" CARGO_TARGET_I686_UNKNOWN_NETBSD_LINKER=/usr/pkgsrc/mail/thunderbird/work/thunderbird-60.6.0/build/cargo-linker /usr/pkg/bin/cargo rustc  --release --frozen --manifest-path /usr/pkgsrc/mail/thunderbird/work/thunderbird-60.6.0/toolkit/library/rust/Cargo.toml --lib --target=i686-unknown-netbsd --features "servo bindgen no-static-ideograph-encoder-tables" --  -C lto
   Compiling style v0.0.1 (/usr/pkgsrc/mail/thunderbird/work/thunderbird-60.6.0/servo/components/style)
*SNIP*
error: Could not compile `style`.

Caused by:
  process didn't exit successfully: `/usr/pkg/bin/rustc --crate-name style servo/components/style/lib.rs --color always --crate-type lib --emit=dep-info,link -C opt-level=2 -C panic=abort -C codegen-units=1 --cfg 'feature="bindgen"' --cfg 'feature="fallible"' --cfg 'feature="gecko"' --cfg 'feature="nsstring"' --cfg 'feature="num_cpus"' --cfg 'feature="regex"' --cfg 'feature="style_traits"' --cfg 'feature="toml"' --cfg 'feature="use_bindgen"' -C metadata=3dd65ce82fc4dde6 -C extra-filename=-3dd65ce82fc4dde6 --out-dir /usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps --target i686-unknown-netbsd -C linker=/usr/pkgsrc/mail/thunderbird/work/thunderbird-60.6.0/build/cargo-linker -L dependency=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps -L dependency=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/release/deps --extern app_units=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libapp_units-da574cb12c28d9cd.rlib --extern arrayvec=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libarrayvec-3f0ae2a1cbb8b928.rlib --extern atomic_refcell=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libatomic_refcell-2c02c83fd56d72be.rlib --extern bitflags=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libbitflags-e30e2e63b9a0396a.rlib --extern byteorder=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libbyteorder-d963b5ade0afeea3.rlib --extern cfg_if=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libcfg_if-f04f8382a089c533.rlib --extern cssparser=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libcssparser-1d1d460599be87ea.rlib --extern debug_unreachable=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libdebug_unreachable-9c6bb40bc842974f.rlib --extern euclid=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libeuclid-c4447169ee09badf.rlib --extern fallible=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libfallible-ec595b9f4d32a4fa.rlib --extern fnv=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libfnv-3f989a49edc433f0.rlib --extern hashglobe=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libhashglobe-c285347a04132acc.rlib --extern itertools=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libitertools-8eb8b117a5b27f08.rlib --extern itoa=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libitoa-ac44e7b9828c2cfe.rlib --extern lazy_static=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/liblazy_static-4c69850d0fd93cdd.rlib --extern log=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/liblog-e1d7af40a5fcd3a1.rlib --extern malloc_size_of=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libmalloc_size_of-a638ddfd05e3ac38.rlib --extern malloc_size_of_derive=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/release/deps/libmalloc_size_of_derive-8090b337720cdb8a.so --extern matches=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libmatches-dc9cee8466d7a354.rlib --extern nsstring=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libnsstring-7d9f06a91bb14003.rlib --extern num_integer=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libnum_integer-f7fbda8d8f37adfe.rlib --extern num_traits=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libnum_traits-1fce81085741a140.rlib --extern num_cpus=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libnum_cpus-7f75b9b0a3e8cea3.rlib --extern ordered_float=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libordered_float-72bb28fb42dd7eac.rlib --extern owning_ref=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libowning_ref-191d7e2d9d89ed5f.rlib --extern parking_lot=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libparking_lot-f9ca691333475cf8.rlib --extern precomputed_hash=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libprecomputed_hash-b1f62c54e141bc6c.rlib --extern rayon=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/librayon-f0328a9a16dbfb4e.rlib --extern selectors=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libselectors-b3f6cbe84f95a451.rlib --extern servo_arc=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libservo_arc-b5bf77ee0d81f7da.rlib --extern smallbitvec=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libsmallbitvec-1ef4cf7dd3ee1cfc.rlib --extern smallvec=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libsmallvec-987ea7aad8e4fd03.rlib --extern style_derive=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/release/deps/libstyle_derive-f921523a66ebcc9e.so --extern style_traits=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libstyle_traits-731f77275c5dc178.rlib --extern time=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libtime-42d9c60476bf39e7.rlib --extern uluru=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libuluru-b831f88c4c673a8c.rlib --extern unicode_bidi=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libunicode_bidi-797219c7deb9a8f1.rlib --extern unicode_segmentation=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libunicode_segmentation-ff9ac4948ee07429.rlib --extern void=/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/i686-unknown-netbsd/release/deps/libvoid-c7677eeb3cc69e94.rlib -C opt-level=2 -C debuginfo=2` (signal: 9, SIGKILL: kill)
gmake[3]: *** [/usr/pkgsrc/mail/thunderbird/work/thunderbird-60.6.0/config/rules.mk:979: force-cargo-library-build] Error 101
gmake[3]: Leaving directory '/usr/pkgsrc/mail/thunderbird/work/build/toolkit/library/rust'

2019-06-30

「Activated service 'org.freedesktop.PolicyKit1' failed: Launch helper exited with unknown return code 1」が解決

dynabook SS SX/15AをNetBSD/i386にして、MATEデスクトップ環境を入れて利用しています。アプリケーションはpkgsrcから入れていますが、CVSでpkgsrcを最新にして、今月上旬からpkg_rolling-replaceで全更新をするつもりでした。しかしトラブルが続き、今月下旬になっても完了しないので、2019Q1のpkgsrcでビルドされたバイナリを利用したpkginで全更新を完了させました。

MATEデスクトップ環境は動いているようだし、ときどき不調なアプリケーションもあるものの、全般的に動いているように見えるので、大筋でうまくいっているものと思っていました。ところが昨日になって、動いていた筈の「MATE端末」や「LibreOffice6」などが立ち上がらなくなりました。他にも不具合がありますが、根本的に問題を抱えているようなので、調査してみます。できれば復旧もさせたいところです。

トラブルに見舞われたら、冷静に情報を集めるのが問題解決の第一歩です。昨日は~/.xsession-errorsを参照し、怪しい現象は対処しましたが、まだ解決に至りません。そこで今日は/var/log/messagesにある問題に対処します。該当箇所を以下に示しますが、怪しいのはorg.freedesktop.PolicyKit1が不明なエラーで落ちている点です。
 Jun 30 13:03:54 dbss dbus-daemon[907]: [system] Activating service name='org.freedesktop.ConsoleKit' requested by ':1.0' (uid=0 pid=289 comm="/usr/pkg/sbin/hald ") (using servicehelper)
Jun 30 13:03:58 dbss dbus-daemon[907]: [system] Activating service name='org.freedesktop.PolicyKit1' requested by ':1.1' (uid=0 pid=1055 comm="/usr/pkg/sbin/console-kit-daemon ") (using servicehelper)
Jun 30 13:03:58 dbss dbus-daemon[907]: [system] Activated service 'org.freedesktop.PolicyKit1' failed: Launch helper exited with unknown return code 1
Jun 30 13:03:59 dbss dbus-daemon[907]: [system] Successfully activated service 'org.freedesktop.ConsoleKit'
Jun 30 13:57:17 dbss dbus-daemon[907]: [system] Activating service name='org.freedesktop.PolicyKit1' requested by ':1.12' (uid=0 pid=1529 comm="pkcheck --list-temp ") (using servicehelper)
Jun 30 13:57:17 dbss dbus-daemon[907]: [system] Activated service 'org.freedesktop.PolicyKit1' failed: Launch helper exited with unknown return code 1

エラーメッセージを手掛かりにWebを検索してみましたが、有用な情報に辿りつけません。そこでPolicyKitよりも検索対象を広げて調べてみたところ「dbus-daemon のログについて」という情報に辿りつきました。ここに書かれているのは、僕が対処しようとしている問題とは関係ありませんが、調査手順が具体的に書かれているので、とても参考になります。

その手順に従い「org.freedesktop.PolicyKit1」というファイルを探したら、以下のようになりました。
# locate org.freedesktop.PolicyKit1
/usr/pkg/etc/dbus-1/system.d/org.freedesktop.PolicyKit1.conf
/usr/pkg/share/dbus-1/system-services/org.freedesktop.PolicyKit1.service
/usr/pkg/share/examples/polkit/dbus-1/system.d/org.freedesktop.PolicyKit1.conf
/var/db/pkg.refcount/files/usr/pkg/etc/dbus-1/system.d/org.freedesktop.PolicyKit1.conf
/var/db/pkg.refcount/files/usr/pkg/etc/dbus-1/system.d/org.freedesktop.PolicyKit1.conf/+PERMISSIONS
/var/db/pkg.refcount/files/usr/pkg/etc/dbus-1/system.d/org.freedesktop.PolicyKit1.conf/polkit-0.113nb3
次に手順に書かれているように、ファイルの中身を確認します。
# cat -n /usr/pkg/share/dbus-1/system-services/org.freedesktop.PolicyKit1.service
     1  [D-BUS Service]
     2  Name=org.freedesktop.PolicyKit1
     3  Exec=/usr/pkg/lib/polkit-1/polkitd --no-debug
     4  User=root
     5  SystemdService=polkit.service
Eexc=」で指定されているファイルを実行したところ、共有ライブラリが見つからず落ちてしまいました。
 # /usr/pkg/lib/polkit-1/polkitd --help
/usr/pkg/lib/libmozjs-52.so: Shared object "libicui18n.so.64" not found
おそらく、これが原因でしょう。共有ライブラリの参照状況と、ディレクトリに存在しているファイルを確認すると、不整合がありました。
# ldd /usr/pkg/lib/libmozjs-52.so
/usr/pkg/lib/libmozjs-52.so:
        -lpthread.1 => /usr/lib/libpthread.so.1
        -lc.12 => /usr/lib/libc.so.12
        -licui18n.64 => not found
        -licuuc.64 => not found
        -licudata.64 => not found
        -lplds4 => /usr/pkg/lib/nspr/libplds4.so
        -lnspr4 => /usr/pkg/lib/nspr/libnspr4.so
        -lgcc_s.1 => /usr/lib/libgcc_s.so.1
        -lplc4 => /usr/pkg/lib/nspr/libplc4.so
        -lz.1 => /usr/lib/libz.so.1
        -lm.0 => /usr/lib/libm.so.0
        -lstdc++.9 => /usr/lib/libstdc++.so.9
# ls -l /usr/pkg/lib/libicuuc.so.*
lrwxr-xr-x  1 root  wheel       16 Apr  6 22:59 /usr/pkg/lib/libicuuc.so.63 -> libicuuc.so.63.1
-rwxr-xr-x  1 root  wheel  1874408 Apr  6 22:59 /usr/pkg/lib/libicuuc.so.63.1
最新のpkgsrcが使われたものと、2019Q1のpkgsrcが使われたものが混在しており、このような不整合が起きたと思われます。これを解決するには共有ライブラリ「libmozjs-52.so」を担っているパッケージを見つけ、入れ換える必要があります。/var/db/pkgの下にあるファイル「+CONTENTS」を検索したところ、パッケージ「spidermonkey52」であることがわかりました。インストールされていたのは「spidermonkey52-52.7.4nb9」だったのですが、2019Q1では「spidermonkey52-52.7.4nb6」と僅かにバージョンが低いことが分かりました。

問題となるパッケージを入れ替えたところ、共有ライブラリの不整合がなくなり、実行できるようになりました。
# ldd /usr/pkg/lib/libmozjs-52.so
/usr/pkg/lib/libmozjs-52.so:
        -lpthread.1 => /usr/lib/libpthread.so.1
        -lc.12 => /usr/lib/libc.so.12
        -licui18n.63 => /usr/pkg/lib/libicui18n.so.63
        -licuuc.63 => /usr/pkg/lib/libicuuc.so.63
        -licudata.63 => /usr/pkg/lib/libicudata.so.63
        -lstdc++.8 => /usr/lib/libstdc++.so.8
        -lm.0 => /usr/lib/libm.so.0
        -lgcc_s.1 => /usr/lib/libgcc_s.so.1
        -lplds4 => /usr/pkg/lib/nspr/libplds4.so
        -lnspr4 => /usr/pkg/lib/nspr/libnspr4.so
        -lplc4 => /usr/pkg/lib/nspr/libplc4.so
        -lz.1 => /usr/lib/libz.so.1
# /usr/pkg/lib/polkit-1/polkitd --help
Usage:
  polkitd [OPTION?] polkit system daemon

Help Options:
  -h, --help         Show help options

Application Options:
  -r, --replace      Replace existing daemon
  -n, --no-debug     Don't print debug information
ここでマシンをリブートし、あらためて/var/log/messagesを確認すると、不具合が解消していることが確認できました。
Jun 30 14:27:10 dbss dbus-daemon[96]: [system] Activating service name='org.freedesktop.ConsoleKit' requested by ':1.0' (uid=0 pid=105 comm="/usr/pkg/sbin/hald ") (using servicehelper)
Jun 30 14:27:14 dbss dbus-daemon[96]: [system] Activating service name='org.freedesktop.PolicyKit1' requested by ':1.1' (uid=0 pid=619 comm="/usr/pkg/sbin/console-kit-daemon ") (using servicehelper)
Jun 30 14:27:15 dbss dbus-daemon[96]: [system] Successfully activated service 'org.freedesktop.ConsoleKit'
Jun 30 14:27:35 dbss dbus-daemon[96]: [system] Successfully activated service 'org.freedesktop.PolicyKit1'
Jun 30 14:29:18 dbss dbus-daemon[792]: [session uid=1000 pid=437] Activating service name='org.freedesktop.portal.IBus' requested by ':1.0' (uid=1000 pid=205 comm="/usr/pkg/bin/ibus-daemon ")
Jun 30 14:29:18 dbss dbus-daemon[792]: [session uid=1000 pid=437] Successfully activated service 'org.freedesktop.portal.IBus'
Jun 30 14:29:21 dbss dbus-daemon[792]: [session uid=1000 pid=437] Activating service name='org.a11y.Bus' requested by ':1.3' (uid=1000 pid=835 comm="/usr/pkg/libexec/ibus-x11 --kill-daemon ")
Jun 30 14:29:21 dbss dbus-daemon[264]: [session uid=1000 pid=1305] Activating service name='org.a11y.Bus' requested by ':1.0' (uid=1000 pid=1007 comm="mate-session ")
Jun 30 14:29:21 dbss dbus-daemon[264]: [session uid=1000 pid=1305] Successfully activated service 'org.a11y.Bus'
Jun 30 14:29:21 dbss dbus-daemon[792]: [session uid=1000 pid=437] Successfully activated service 'org.a11y.Bus'
Jun 30 14:29:22 dbss dbus-daemon[264]: [session uid=1000 pid=1305] Activating service name='ca.desrt.dconf' requested by ':1.3' (uid=1000 pid=1007 comm="mate-session ")
Jun 30 14:29:22 dbss dbus-daemon[264]: [session uid=1000 pid=1305] Successfully activated service 'ca.desrt.dconf'
Jun 30 14:29:38 dbss dbus-daemon[96]: [system] Activating service name='org.freedesktop.UPower' requested by ':1.9' (uid=1000 pid=1187 comm="mate-power-manager ") (using servicehelper)
Jun 30 14:29:39 dbss dbus-daemon[96]: [system] Successfully activated service 'org.freedesktop.UPower'
Jun 30 14:29:42 dbss dbus-daemon[264]: [session uid=1000 pid=1305] Activating service name='org.mate.panel.applet.SensorsAppletFactory' requested by ':1.10' (uid=1000 pid=933 comm="mate-panel ")
Jun 30 14:29:42 dbss dbus-daemon[264]: [session uid=1000 pid=1305] Activating service name='org.mate.panel.applet.MultiLoadAppletFactory' requested by ':1.10' (uid=1000 pid=933 comm="mate-panel ")
Jun 30 14:29:42 dbss dbus-daemon[264]: [session uid=1000 pid=1305] Successfully activated service 'org.mate.panel.applet.MultiLoadAppletFactory'
Jun 30 14:29:42 dbss dbus-daemon[264]: [session uid=1000 pid=1305] Successfully activated service 'org.mate.panel.applet.SensorsAppletFactory'
Jun 30 14:29:45 dbss dbus-daemon[96]: [system] Activating service name='org.mate.SettingsDaemon.DateTimeMechanism' requested by ':1.11' (uid=1000 pid=933 comm="mate-panel ") (using servicehelper)
Jun 30 14:29:45 dbss dbus-daemon[96]: [system] Successfully activated service 'org.mate.SettingsDaemon.DateTimeMechanism'
個人アカウントでログインし、MATEデスクトップ環境を利用してみたところ、問題となっていた不具合が解消しているのを確認できました。MATE端末もLibreOfficeも動きますし、Emacsも問題ありません。

以上で、重大な不具合は解決しましたが、まだ完全な状態とも言えない状況です。NetBSDのpkgsrcにあるMATEには不具合が残っているのか、それとも僕の環境に怪しい箇所が残っているのか、わかりません。これからも調査を続けていくつもりです。

2019-06-29

NetBSDでLinux版Firefox 67.0.4を使いたい

dynabook SS SX/15AにNetBSD/i386を入れて、MATEデスクトップ環境を構築しようとしています。WebブラウザはFirefoxを利用したいのですが、出来れば自前でビルドしないで済ませたいところです。

pkginを利用して出来合いのバイナリパッケージを使おうと思ったのですが、中途半端なファイルしか利用できません。Language packsがあっても本体がなければ意味がありません。
  1. firefox-l10n-66.0.1  Language packs for www/firefox (version 66)
  2. firefox36-l10n-3.6.28  Language packs for www/firefox36 (version 3.6.x)
  3. firefox45-45.9.0nb18  Web browser with support for extensions (version 45)
  4. firefox45-l10n-45.9.0  Language packs for www/firefox (version 45)
  5. firefox52-52.9.0nb12  Web browser with support for extensions (version 52)
  6. firefox52-l10n-52.9.0  Language packs for www/firefox (version 52)
  7. firefox60-l10n-60.6.1  Language packs for www/firefox60 (version 60)

Firefoxを自前でビルドしようとすると、rustが必要になります。rustはFirefox並(以上?)に大きなパッケージなので、ビルドに時間もかかりますし、ディスクが溢れる懸念もあります。なんとかバイナリを入れて終わりにできないでしょうか。

ふと考えてみると、LibreOfficeは(原理的には)ソースから自前でビルドすることも出来るはずなのに、NetBSDのLinuxエミュレーションを利用し、Linux版LibreOfficeのRPMを利用して済ませています。同じことがFirefox(やThunderbird)でも出来ないでしょうか。

Mozillaの公式サイトには、RPMを使わずに導入するためのファイルが置いてあります。使うためには、必要な動作条件を満たすように環境を整えなければなりませんが、これが利用できないでしょうか。

詳しい動作確認はMATEデスクトップ環境のトラブルを解決してからにしようと思いますが、試しに展開して動かしてみました。

まず共有ライブラリの状況をみると、問題はなさそうです。
# /usr/pkg/emul/linux/usr/bin/ldd /usr/pkg/opt/firefox-67.0.4/firefox
        libpthread.so.0 => /lib/libpthread.so.0 (0xbbab9000)
        libdl.so.2 => /lib/libdl.so.2 (0xbbab4000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xbb9c7000)
        libm.so.6 => /lib/libm.so.6 (0xbb982000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xbb965000)
        libc.so.6 => /lib/libc.so.6 (0xbb7ee000)
        /lib/ld-linux.so.2 (0xbbadd000)

もしかしたら動くかもしれないと期待しましたが、駄目でした。まだ不足する共有ライブラリがあるようです。
# /usr/pkg/opt/firefox-67.0.4/firefox
/usr/pkg/opt/firefox-67.0.4/firefox: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory

2019-06-27

misc/libreoffice6-bin-6.2.2

dynabook SS SX/15上でNetBSD/i386を利用しています。pkg_rolling-replaceによるパッケージの全更新に失敗してしまい、利用環境が崩壊したので、復旧しています。ひとまずMATEデスクトップ環境が回復し、日本語入力には(Mozcを捨て)KKCで出来るようになりました。次はLibreOfficeを復旧させます。

pkgsrcにはLinuxエミュレーション環境で動作するLibreOfficeがあります。以前はLibreOffice5系だけでした。pkgsrcでインストールされるバージョンがLibreOfficeのバージョンアップに追いつかないので、小細工をして最新(の一歩手前)をインストールして利用していました。

ところが現在はLibreOffice5系の他にLibreOffice6系もあるようです。今回はLibreOffice6系を、pkginで導入しました。
libreoffice6-bin-6.2.2 Integrated office productivity suite (binary pkg)

pkgsrcから自前でビルドしたところで、ここにあるのはLinuxエミュレーション環境用のバイナリなのでコンパイルが始まるわけではありません。しかし若干のビルド処理はあります。それに比べればpkginならば、展開するだけで終わりのバイナリパッケージになっているので、より一層素早く導入作業が完了します。

導入後に起動してみたところ、問題もなく使えるようになりました。以前には日本語入力が出来ずに苦労しましたが、その問題もありませんでした。これは、以前苦労して設定した環境が残っているせいなのか、既に今は問題が無いようになっているのか、理由は分かりません。また日本語入力がKKCです。問題もなく、日本語入力ができることを確認しました。

次はFirefoxやThunderbirdを入れようかと考えています。

2019-06-26

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

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

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

そこで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か月間に亘りビルドを続けていましたが、一区切りをつけることはできたと思います。

2019-06-25

pkgsrcにあるlang/rustのビルド

dynabook SS SX/15Aで利用しているNetBSD/i386のパッケージを更新するためpkg_rolling-replaceを使って作業中です。今月上旬から始めましたが、いろいろな問題があり、まだ終わっていません。何かのパッケージの依存関係に含まれていたlang/rustは、大物なので自前でビルド出来ず、難儀しました。パッケージを消去することで、システムに存在しないことになったので、ビルド対象から外れていたのですが、何かのパッケージの依存関係に含まれていたらしく、またしてもビルドが始まろうとしてしまいました。

lang/rustをビルドしているとディスクが溢れてしまうのが、自前でビルドできない理由です。ビルド済みのパッケージを入手して済まそうと思ったのですが、The NetBSD Packages Collection: lang/rustにはx86_64版とsparc64版しか置いてありません。

必要なのはi386版のビルド済みパッケージです。それがあれば、pkg_addするだけで済むはずです。そこで、Windows10上のVirtualBoxでNetBSD/i386の環境を作り、そこでlang/rustのビルドをおこなうことにしました。途中でWindows10のマシンの電源を落としたりしたので、24時間動かしていたわけではありませんが、2日間強ほどかかりましたが、無事にビルド出来ました。

ビルド出来たパッケージをpkg_addすると、警告が出ましたが、無事にインストールされました。
# pkg_add /usr/local/pkgsrc/packages/All/rust-1.35.0nb1.tgz
pkg_add: Warning: package `rust-1.35.0nb1' was built for a platform:
pkg_add: NetBSD/i386 8.0 (pkg) vs. NetBSD/i386 8.99.43 (this host)
# pkg_info  | grep rust
rust-1.35.0nb1      Safe, concurrent, practical language

これで一安心かと思いきや、pkg_rolling-replaceではlang/rustの再作成が始まろうとしてしまいます。
rr> inputmethod/ibus-mozc - ibus-mozc-2.17.2313.102nb2 < ibus-mozc-2.17.2313.102nb13
rr> lang/py-six - py37-six-1.12.0 missing
rr> lang/rust - rust-1.35.0nb1 > rust-1.35.0 - ignoring
rr> lang/vala - vala-0.38.4 < vala-0.44.3

pkg_rolling-replaceは内部でpkg_chkを呼び出すことで、パッケージを再ビルドする必要の有無を判断しているようです。ここに出ているメッセージはpkg_chkを単独で実行したものと同じでした。

せっかくVirualBox上のNetBSD/i386でビルドしたのに、これでは意味がありません。どうしようかと思ったのですが、pkg_rolling-replaceにはオプション「-X」で再作成対象から除外できる機能があるので、「-X rust」 を指定して再作成対象外としました。

これでlang/rustの問題は解決したと考えています。しかしながらpkg_rolling-replaceでパッケージを全更新するのは、あまり得策ではないような気がしてきました。pkg_rolling-replace以外にも、pkg_chkpkginなどのツールもあるようですし、そもそもソースから自前でビルドしなくても、出来合いのバイナリを使う方法もあるようです。どうすれば良いのか、もう一度考えてみようと思います。

2019-06-21

lang/mono2がビルドできない

dynabook SS SX/15Aに入れたNetBSD/i386のアプリケーションを更新するためにpkg_rolling-replaceを実行しています。lang/rustの更新が上手くいかず手間取りました。しかし未解決のまま、先にすすめています。順調に処理が進んだかと思ったら、lang/mono2でエラーになりました。このパッケージは以前にも失敗しており、同じ現象が出ています。

失敗した時点のログは以下のようになっています。
gmake[7]: Entering directory '/usr/pkgsrc/lang/mono2/work/mono-2.10.9/mcs/tools/gacutil'
/usr/pkg/bin/gmake all-local
gmake[8]: Entering directory '/usr/pkgsrc/lang/mono2/work/mono-2.10.9/mcs/tools/gacutil'
MCS     [basic] gacutil.exe
mv gacutil.exe ./../../class/lib/basic/gacutil.exe
mv: rename gacutil.exe to ./../../class/lib/basic/gacutil.exe: No such file or directory
gmake[8]: *** [../../build/executable.make:106: ../../class/lib/basic/gacutil.exe] Error 1
gmake[8]: Leaving directory '/usr/pkgsrc/lang/mono2/work/mono-2.10.9/mcs/tools/gacutil'

ビルドに失敗した直接の原因は、ログにもあるように、gacutil.exeが存在しないため、mvに失敗したことです。なぜファイルが存在しないのかを探ってみると、コアファイルが残っていました。
# ls -l /usr/pkgsrc/lang/mono2/work/mono-2.10.9/mcs/tools/gacutil
total 718
-rw-rw-r--  1 furusawa  furusawa   12419 Feb  4  2012 ChangeLog
-rw-rw-r--  1 furusawa  furusawa     198 Jan 31  2012 Makefile
-rw-rw-r--  1 furusawa  furusawa   28150 Jan 31  2012 driver.cs
-rw-rw-r--  1 furusawa  furusawa      43 Nov 16  2011 gacutil.exe.sources
-rw-------  1 root      furusawa  668188 Jun 20 17:50 mono.core

このディレクトリで処理が正常に行われればgacutil.exeが作られるはずなのでしょう。ところがコアを吐いているところをみると、何か問題があるようです。折角コアが出来ているので、念のために状況を確認してみました。
# gdb  ../../../mono/mini/mono mono.core
GNU gdb (GDB) 8.0.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486--netbsdelf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../../../mono/mini/mono...done.
[New process 1]
Core was generated by `mono'.
Program terminated with signal SIGABRT, Aborted.
#0  0xad063df7 in _lwp_kill () from /usr/lib/libc.so.12
(gdb) where
#0  0xad063df7 in _lwp_kill () from /usr/lib/libc.so.12
#1  0xad063d81 in raise () from /usr/lib/libc.so.12
#2  0xad063a57 in abort () from /usr/lib/libc.so.12
#3  0x080e0617 in mono_handle_native_sigsegv (signal=signal@entry=11, ctx=ctx@entry=0xbfb6eba4) at mini-exceptions.c:2223
#4  0x08061228 in mono_sigsegv_signal_handler (_dummy=11, info=0xbfb6eb24, context=0xbfb6eba4) at mini.c:5875
#5  <signal handler called>
#6  GC_push_all_eager (bottom=bottom@entry=0x0, top=top@entry=0xbfb6ef6c "") at mark.c:1468
#7  0x0820cdab in GC_push_current_stack (cold_gc_frame=cold_gc_frame@entry=0xbfb6ef6c "") at mark_rts.c:491
#8  0x08220e5c in GC_with_callee_saves_pushed (arg=0xbfb6ef6c "", fn=<optimized out>) at mach_dep.c:476
#9  GC_generic_push_regs (cold_gc_frame=cold_gc_frame@entry=0xbfb6ef6c "") at mach_dep.c:487
#10 0x0820ce81 in GC_push_roots (all=all@entry=1, cold_gc_frame=cold_gc_frame@entry=0xbfb6ef6c "") at mark_rts.c:631
#11 0x0820c37f in GC_mark_some (cold_gc_frame=cold_gc_frame@entry=0xbfb6ef6c "") at mark.c:391
#12 0x08205d75 in GC_stopped_mark (stop_func=stop_func@entry=0x8205ac0 <GC_never_stop_func>) at alloc.c:543
#13 0x0820637d in GC_try_to_collect_inner (stop_func=0x8205ac0 <GC_never_stop_func>) at alloc.c:382
#14 0x0820dd0b in GC_init_inner () at misc.c:820
#15 0x0820ddd2 in GC_init_inner () at misc.c:603
#16 GC_init () at misc.c:517
#17 0x08127676 in mono_gc_base_init () at boehm-gc.c:126
#18 0x081423c0 in mono_init_internal (filename=filename@entry=0xbfb6f8d8 "./../../class/lib/basic/mcs.exe", exe_filename=exe_filename@entry=0xbfb6f8d8 "./../../class/lib/basic/mcs.exe", runtime_version=runtime_version@entry=0x0) at domain.c:1303
#19 0x081437ae in mono_init_from_assembly (domain_name=domain_name@entry=0xbfb6f8d8 "./../../class/lib/basic/mcs.exe", filename=filename@entry=0xbfb6f8d8 "./../../class/lib/basic/mcs.exe") at domain.c:1688
#20 0x0806225f in mini_init (filename=0xbfb6f8d8 "./../../class/lib/basic/mcs.exe", runtime_version=runtime_version@entry=0x0) at mini.c:6348
#21 0x080ba9d4 in mono_main (argc=14, argv=0xbfb6f1b8) at driver.c:1746
#22 0x080576f6 in ___start ()
#23 0x08057427 in _start ()
(gdb)

コアが吐かれた原因は分かりません。何かの不整合があるのかもしれないし、もしかするとハードウェアのどこかに問題を抱えているのかもしれません。

この状況をどのようにして打開すればよいのか考えてみました。もしビルドしている環境(ハードウェアの何らかの故障や、OSの些細な不整合)が問題の原因であるなら、他のマシンでビルドすれば成功するかもしれません。そこでWindows10上のVirtualBoxを利用して、NetBSD/i386の環境を作ってみました。新規にOSをインストールし、そこでlang/mono2をビルドしてみました。これでうまくいくと思ったのですが、なんと同様のエラーが出て、やはりビルドできませんでした。そもそもlang/mono2は正常にビルド出来る状態にあるのか、不信感が生じてきました。

根本に立ち返ると、mono2が必要な理由は、security/KeePassが必要としているからです。KeePassを利用しようと思った理由は、dynabook SS SX/15Aに当初インストールされていたWindows VistaでID Managerという管理ソフトを利用しており、その移行先として利用してみようと思ったからです。移行先はKeePassに限定されるわけではないので、mono2にこれほど手間取るのであれば、KeePass以外の類似ツールを検討してみようかと考えています。

2019-06-19

ifconfig wpi0 downでカーネルが落ちるのを回避する

dynabook SS SX/15Aで利用しているNetBSD/i386のアプリケーションを更新するためにpkg_rolling-replaceを実行しています。今月上旬から初めて10日間を過ぎましたら、まだ続いています。なかなか終わらない理由は、主として次の2つです。
  1. 毎晩必ずカーネルが落ちるので、折角途中まで実行した結果が無駄になってしまう。
  2. マシンのリソース(CPU速度やHDD容量など)が見劣りする。

ビルドに長時間を要するような大物パッケージが幾つかあります。まさに現在処理中なのがlang/rustです。このパッケージをビルドするにはCPU性能の限界により、1日以上かかりそうです。また中間ファイルを生成している最中にディスクが溢れたりします。

さらに悲惨なのが、毎晩カーネルが落ちることです。pkg_rolling-replaceを使用すると、カネールが落ちる直前までのコンパイル結果は全て削除されてしまい、あらためて最初からコンパイルが始まるので、全然作業がはかどりません。

 このままでは永遠にビルドが完了しないので、何とか対処方法を見つけなければなりません。

まずlang/rustを自前でビルドするのを諦めて、ビルド済みの出来合いのパッケージを拾ってきてインストールするだけで済ませようかと思いました。ところがamd64版は見つかりましたが、i386版が見当たりません。やはり自分でビルドするしかないようです。

ビルド中にカーネルが落ちると折角の作業が水の泡なので、 なんとか落ちないようにしておきたいところです。クラッシュダンプを確認すると、カーネルが落ちる場所は決まっていて、無線LANインターフェイスwpiが怪しい感じです。ちょっと乱暴ですが、ifconfig wpi0 downで機能を止めてみました。今のところ、この対処をしてからはカーネルが落ちることはないようです。

pkg_rolling-replaceを使わずに、/usr/pkgsrc/lang/rustで直接makeする方法を試してみました。これなら仮にカーネルが落ちて処理が中断したとしても、途中までの結果が無駄になることはないはずです。ないはずなのですが、処理を再開したら、原因のよくわからないエラーが出て中断から再開できなかったこともあるので、絶対安心というわけではないのですが、pkg_rolling-replaceよりはマシだと思っています。

2019-06-14

config.status: error: cannot find input file: `Makefile.in'

dynabook SS SX/15AのNetBSD/i386でpkg_rolling-replaceを続けています。graphics/jbig2decをビルドしようとして、次のようなエラーが出て中断されました。
checking for getopt_long... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: error: cannot find input file: `Makefile.in'
pkgsrcのパッケージ構成ミスかと思って、pkgsrcのCVSを確認してみましたが、最近変更を加えた形跡はないようでした。

このパッケージはautomakeを利用しているようです。手動でコマンドを打ち込んでみたら、次のようなエラーが出ていました。
configure.ac:22: installing './compile'
configure.ac:24: installing './config.guess'
configure.ac:24: installing './config.sub'
configure.ac:7: installing './install-sh'
configure.ac:25: error: required file './ltmain.sh' not found
configure.ac:7: installing './missing'
/usr/pkg/share/automake-1.15/am/ltlibrary.am: warning: 'libjbig2dec.la': linking libtool libraries using a non-POSIX
/usr/pkg/share/automake-1.15/am/ltlibrary.am: archiver requires 'AM_PROG_AR' in 'configure.ac'
Makefile.am:6:   while processing Libtool library 'libjbig2dec.la'
Makefile.am: installing './depcomp'
Makefile.am:9: warning: 'CFLAGS' is a user variable, you should not override it;
Makefile.am:9: use 'AM_CFLAGS' instead
parallel-tests: installing './test-driver'
  autoconf
I am going to run ./configure with no arguments - if you wish to pass any to it, please specify them on the ./autogen.sh command line.
ここでエラーになっているのは「required file './ltmain.sh' not found」です。ワーニングも気になりますが、まずはエラーを先に見ていきます。見つからないと訴えているファイルが何者なのかをWebで確認すると、/usr/pkg/bin/libtoolizeでコピーされるはずだという情報が見つかりました。試しに手作業でコマンドを打ち込んでみましたが、コピーされません。試しに問題となっているコマンドをlsで確認してみたところ、何故かファイルサイズが0になっていました。

いったい何故このようになったのか不明ですが、最近カーネルパニックが多いので、運悪くファイルの中身を失ってしまったのかもしれません。

pkgsrcから改めてlibtoolsを入れ直したら、問題は解決しました。

2019-06-13

No package directory 'lang/spidermonkey17' for spidermonkey17

dynabook SS SX/15Aで使用しているNetBSD/i386のアプリケーションをpkg_rolling-replaceで入れ換える作業を続けています。前回入れ換えてから1年以上経っているので、更新対象が多く、時間がかかっています。

処理中に、次のようなメッセージが出て中断してしまいました。
RR> Tsorting dependency graph
RR> Selecting spidermonkey17 (lang/spidermonkey17) as next package to replace
*** No package directory 'lang/spidermonkey17' for spidermonkey17.
*** Please read the errors listed above, fix the problem,
*** then re-run pkg_rolling-replace to continue.
- spidermonkey17
そもそもspidermonkey17が何なのか知りませんでしたが、ウィキペディアによると「世界初のJavaScriptエンジンで、現在はMozilla Foundationが保守している」そうです。/usr/pkgsrcを確認してみると、確かに問題となっているディレクトリはありませんでした。
drwxr-xr-x  5 root  wheel  512 Oct 30  2017 /usr/pkgsrc/lang/spidermonkey
drwxr-xr-x  4 root  wheel  512 Jun  8 18:27 /usr/pkgsrc/lang/spidermonkey185
drwxrwxr-x  4 root  wheel  512 Jun  8 18:27 /usr/pkgsrc/lang/spidermonkey52
pkgsrcにある何かのパッケージが依存関係としてspidermonkey17を参照しているのでしょうから、そのパッケージを突き止めるのが問題解決に繋がるかと思いました。しかしNetBSDのpkgsrcで依存関係を調べる方法がわかりません。

あるパッケージが依存しているものを探すなら「make show-depends」で判明するようなのですが、あるパッケージを参照している相手を探すには、どうすればよいのでしょうか?

考えてみると、spidermonkey17を参照している相手が見つかったところで、いずれにせよspidermonkey17を削除して、より新しいバージョンを導入することになるはずです。依存関係を探す手段をみつけるという課題は後回しにして、強制的にspidermonkey17を削除してしまうことにしました。

2018-10-15

NetBSDのpkgsrcにあるmisc/libreoffice5-binのバージョンを5.1.0.3から5.4.6.2に変更成功

NetBSD/i386でpkgsrcからmisc/libreoffice5-binをインストールしています。このパッケージではLibreOffice 5.1.0.3のLinux用RPMが展開されるので、なんとかしてバージョンを上げたいと思っていました。ちょっとだけ小細工が必要でしたが、LibreOffice 5.4.6.2をインストールすることに成功しました。

基本的な方針は「RPMFILES」を使ってLibreOffice 5.4.6.2のRPMを指定することです。/usr/pkgsrc/misc/libreoffice5-binmakeすると途中で次のようなメッセージが出てきます。

==========================================================================
The following variables will affect the build process of this package,
libreoffice5-bin-5.1.0.  Their current value is shown below:

        * RPMFILES = /usr/pkgsrc/misc/libreoffice5-bin/work/LibreOffice_5.1.0.3_Linux_x86_rpm/RPMS/*.rpm

You may want to abort the process now with CTRL-C and change their value
before continuing.  Be sure to run `/usr/bin/make clean' after
the changes.
==========================================================================
「RPMFILES」という変数でRPMのファイルを指定することができるようです。それは分かりましたが、具体的にどのようにして指定するのでしょうか。まず環境変数として指定してみましたが、うまくいきませんでした。つぎにコマンドラインで指定してみたところ、分かってくれたようです。
# cd /usr/pkgsrc/misc/libreoffice5-bin
# make 'RPMFILES=/path/to/LibreOffice_5.4.6.2_Linux_x86_rpm/RPMS/*.rpm'
*snip*
==========================================================================
The following variables will affect the build process of this package,
libreoffice5-bin-5.1.0.  Their current value is shown below:

        * RPMFILES = /path/to/LibreOffice_5.4.6.2_Linux_x86_rpm/RPMS/*.rpm

You may want to abort the process now with CTRL-C and change their value
before continuing.  Be sure to run `/usr/bin/make clean' after
the changes.
==========================================================================
エラーも出ずにインストールが完了したのですが、試しにLibreOffice Calcを起動してみましたが、駄目でした。

 そこで調べてみると/usr/pkg/bin/scalc/usr/pkg/opt/libreoffice5.1/program/scalcへのシンボリックリンクになっています。pkgsrcが想定しているのはLibreOffice 5.1.0.3ですから、RPMだけLibreOffice 5.4.6.2のものを使っても、このあたりはうまくいかないのでしょう。

安直な対処方法として、libreoffice5.1という名前のシンボリックリンクを作成し、libreoffice5.4を指すようにしてみました。こんな感じです。
# cd /usr/pkg/opt
# ls -l
total 8
drwxrwxr-x  2 root  wheel  512 Oct 15 07:37 libreoffice
lrwxrwxr-x  1 root  wheel   14 Oct 15 13:28 libreoffice5.1 -> libreoffice5.4
drwxrwxr-x  7 root  wheel  512 Oct 15 07:37 libreoffice5.4
この状態で改めてLibreOffice Calcを起動させてみたところ、無事に起動しました。バージョンを確認すると、ちゃんと5.4.6.2になっています。

こういう対応方法でよかったのか疑問が残りますが、良しとしましょう。