「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には不具合が残っているのか、それとも僕の環境に怪しい箇所が残っているのか、わかりません。これからも調査を続けていくつもりです。

NetBSDのLinuxエミュレーションは何故openSUSE 13.1なのか

NetBSDのLinuxエミュレーションのために利用できるディストリビューションとしてpkgsrcにあるのは、openSUSE 13.1です。

% cat /usr/pkg/emul/linux/etc/os-release
NAME=openSUSE
VERSION="13.1 (Bottle)"
VERSION_ID="13.1"
PRETTY_NAME="openSUSE 13.1 (Bottle) (i586)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:13.1"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://opensuse.org/"
ID_LIKE="suse"

何故SUSEなのか、という疑問もありますが、（それは良いとしても）何故openSUSE 13.1なのかという疑問があります。openSUSEの最新版は15.2であり、13.1のサポートは2016年に終了しています。そのためなのか、公式サイトからは既に13.1が消えています。NetBSDのLinuxエミュレーションで不具合が起きた場合に、本物のopenSUSE 13.1の環境を準備して比較することは、問題解決のために役立つ手法です。ところがopenSUSE 13.1が入手できなくなっているので、この手法が使えません。

NetBSD のLinuxエミュレーション環境は、Linuxカーネル3.11.6に相当するようです。pkgsrcに用意されているopenSUSE 13.1は、ユーザの利便性のために提供されているだけであり、自分で環境を整えていけるのであれば、FedoraでもUbuntuでも何でも好きなディストリビューションを入れることが可能ということなのでしょうか。

% uname -r
8.99.43
% sysctl -a | grep linux
emul.linux.kern.ostype = Linux
emul.linux.kern.osrelease = 3.11.6
emul.linux.kern.osversion = #1 SMP PREEMPT Thu Oct 24 16:23:02 UTC 2013
emul.linux.enabled = 1

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

MATEでストップ環境でアプリケーションの動きがおかしくなった（が、不具合が解消されたところもある）

dynabook SS SX/15AのOSをNetBSD/i386に置き換えて、MATEデスクトップ環境を利用しています。pkgsrcから入れていたアプリケーションの全更新に失敗し、既存の環境が崩壊したので、再構築をしています。今日になって（何故か）昨日まで動いていたアプリケーションの挙動がおかしくなりました。全てを確認している訳ではありませんが、次のような挙動が確認されています。それらは、いずれも昨日までは普通に出来ていたのですが、何故いきなり駄目になったのか分かりません。

1. MATE端末のウィンドウが開かない。
2. LibreOfficeのスプラッシュ画面は出てくるのに、そこで止まってしまう。
3. 画面上部のメニューバーから「システム」→「furusawaのログアウト...」を選んでも、ウィンドウが出てこなくなった。
4. 画面上部のメニューバーから「システム」の下にあったシャットダウン用のメニューが消えた。
5. Emacsを立ち上げると、何かキーを押さないとウィンドウが出ない。

バイナリが落ちて（コアを吐いて）動かないのであれば、（それはそれで困りますが）理解できなくもありません。しかしコアは出来ていないのに、アプリケーションが動かないのです。 何が悪いのか見当もつきませんが、唸っていたところで解決するわけではありません。こういう時には何処かにエラー情報が残っていないか探してみるのが、問題解決の第一歩になります。

そこでホームディレクトリで直近の書き込みがあるファイルを探してみると~/.xsession-errorsがありました。ファイル内を確認すると、いろいろな情報が書き込まれていましたが、アプリケーションが利用している共有ライブラリが見つからないというメッセージが2件ありました。まずは、この問題を解決すべきでしょう。

エラーの原因となっている共有ライブラリが属しているパッケージが何かを突き止める必要があります。ちょっと強引な方法ですが/var/db/pkgの下にある+CONTENTSファイルを検索してパッケージを特定しました。特定されたパッケージを削除し、あらためて導入し直しました。これは要するにバージョンの不一致による不整合が起きていたと思われます。今月上旬にはCVSで取得したカレントのpkgsrcを利用してパッケージを更新していましたが、今月下旬になって2019Q1のpkgsrcでビルドされたパッケージを利用することに方針変更しています。このため、一部のパッケージにおいてバージョンの不一致が発生してしまったのだろうと想像しています。

これらを解決したところ、MATEデスクトップ環境の不具合の一部が解決しました。特にCaja（MATE固有のファイルマネージャー）が動くようになりました。しかし相変わらず、MATE端末やLibreOfficeは起動しません。（ディスク不良か何かで）バイナリが壊れたのかと思って、各パッケージを入れ直してみたのですが、問題は解決しませんでした。ところがrootアカウント（MATEデスクトップ環境を利用しておらず、twmを利用した原始的なX11環境です）では、MATE端末もLibreOfficeも動くのです。

他にもエラー情報がないかと思って/var/log/messagesを確認すると、次のようなエラーが出ていました。

Jun 29 20:06:26 dbss dbus-daemon[779]: [system] Activating service name='org.freedesktop.ConsoleKit' requested by ':1.0' (uid=0 pid=829 comm="/usr/pkg/sbin/hald ") (using servicehelper)
Jun 29 20:06:29 dbss dbus-daemon[779]: [system] Activating service name='org.freedesktop.PolicyKit1' requested by ':1.1' (uid=0 pid=290 comm="/usr/pkg/sbin/console-kit-daemon ") (using servicehelper)
Jun 29 20:06:30 dbss dbus-daemon[779]: [system] Activated service 'org.freedesktop.PolicyKit1' failed: Launch helper exited with unknown return code 1
Jun 29 20:06:30 dbss dbus-daemon[779]: [system] Successfully activated service 'org.freedesktop.ConsoleKit'

PolicyKitで起動に失敗しているようなのですが、これを解決する方法が分かりません。しかしPolicyKitは権限に関する機能を担っているはずですから、rootアカウントなら動くのに、一般アカウントでは駄目というのも、関連していそうな気がします。

まだ問題は解決していませんが、解決の方向性は間違っていないような気がしています。

『セキュリティはなぜやぶられたのか』を読んで

Webを見ていたら『セキュリティはなぜやぶられたのか』を知りました。近所の図書館にあったので、借りて読んでみました。何か（セキュリティとか）に直ちに役立つハウツー本ではないと思いますが、自分なりの物の見方を形作るうえで有効な書籍だと感じました。

「セキュリティ」というと、コンピュータ・セキュリティとか（ウィルス対策ソフト絡みの話題がよく出てきます）、ホーム・セキュリティ（民間会社との契約を結んでいることもあるでしょう）などが思いつきますが、もっと広い概念です。ですからコンピュータを念頭においたセキュリティ問題を意識して読むと、期待外れと感じるでしょう。

近年は社会の中でコンピュータの果たす役割が増大しているので、「セキュリティ」というとコンピュータ・セキュリティ、「システム」というとコンピュータ・システム、「プロジェクト」というコンピュータ・システムを開発するプロジェクトと考えがちな風潮があります。しかしセキュリティにしろ、システムやプロジェクトにしろ、いずれにしても「コンピュータ」に限定されるわけではなく、もっと大きな視点から全体を見た上で、その一部に「コンピュータ」が果たしている役割もあると考えるべきでしょう。

本書は、そういう意味での「セキュリティ」について論じています。何か守りたいものがあって、それを守る方法があるとき、それで本当に守れているのかということを、突き詰めて論じます。例えば財宝を金庫に入れておくとして、その金庫にに扉がついていなければ、盗まれる心配はありません。それでは財宝を利用することも出来ないので、扉をつけざるを得ませんが、そうすると盗まれないわけにはいきません。極論なのかもしませんが、その点をどう考えるのかということを、考えるきっかけとなる書籍だと思います。

類似したタイトルの書籍は他にもたくさん出版されていると思いますが、パラパラっとページをめくると1時間もしないうちに読めてしまうような「お手軽」な書籍も少なくありません。それに比べると、本書は読むのに時間がかかりますが、得るものも少なくないと思います。

IBus入力メソッド

dynabook SS SX/15AのOSをNetBSD/i386に入れ換え、デスクトップ環境としてMATEを利用しています。アプリケーションはpkgsrcから入れていますが、今月上旬からpkg_rolling-replaceを使って全更新をしたところ、うまくいかず、動作環境が崩壊してしまいました。アプリケーションに必要なパッケージを入れ直しても、動作が思わしくないのは、NetBSDのパッケージの出来が良くないせいなのか、まだ気づいていないところに不整合のあるパッケージが残っているせいなのか、よくわかりません。

まだ完璧とは言えませんがMATEデスクトップ環境が修復できたので、次に入力メソッドを復旧させます。環境が崩壊する前まではMozcで日本語入力をしていましたが、MATEやIBusを修復しても、Mozcが動作しません。偶々試してみたKKCが問題なく動いているので、Mozcの問題なのではないかとおもっています。

次に、以前は無かったのですが、ハングルの入力メソッドも導入しておくことにしました。まずはibus-hangulを入れてみました。導入はできたし、使おうとして（Mozcのように）落ちることもないのですが、肝心のハングル入力が出来ません。おそらく（勘ですが）日本語変換のように、ハングル入力モードとASCII入力モードを切り替えるのではないかと思っているのですが、どのキーなのか分かりません。Webに情報が無いかと調べていたら、ハングル入力にはibus-m17nという入力メソッドもあるようです。そこでこちらを使ってみることにしました。当初はibus-hangul同様にハングル入力が出来なかったのですが、画面右上にある「한」をクリックしてみると、ハングルの入力方式を選択する画面が開いたので「2ボル式」を選びました。

これで日本語とハングルの入力が可能になりました。

MATEデスクトップ環境では、画面上部のメニューから「システム」→「設定」→「IBusの設定」を選び、「入力メソッド」タブを開くと、登録済みの入力メソッドの一覧が表示されます。その右側には「設定」ボタンがあるのですが、KKCではグレー表示となり押せないようになっています。ところが、画面右上でクリックすると現れるメニュには「設定」という項目があり、それを選ぶと「かな漢字変換の設定」という画面が出てきます。どうしてこういうことになるのか、パッケージ自体が不完全なのか、それとも環境が復旧できていないのか、謎です。これは些細な問題であり、もっと深刻な不具合もあるので、順番に解決していこうと思います。

最終的に導入したIBus関連のパッケージは次のようになりました。

1. ibus-1.5.20nb1      Intelligent Input Bus
2. ibus-m17n-1.3.4nb26 M17N engine for IBus platform
3. ibus-kkc-1.5.21nb9  Japanese KKC input method for ibus

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を入れようかと考えています。

Mozcが動かないのでKKCに移行した

dynabook SS SX/15AでNetBSD/i386を利用しています。アプリケーションはpkgsrcから入れていましたが、もう1年以上更新していませんでした。今月上旬からpkg_rolling-replaceで全更新を始めたのですが、トラブルが続き、いつになっても終わりません。これでは先が思いやられるので、pkginを使って出来合いのバイナリをインストールして済ませることにしました。自前でビルドしないので、必要なパッケージをネットワーク越しに拾ってきて展開するだけですから、圧倒的に処理が速く、パッケージの全更新は、とりあえず完了しました。

ところがpkg_rolling-replaceの処理中に依存関係の処理で消してしまったのか、インストールされているべきパッケージが中途半端に無くなり、虫喰い状態になってしまっています。MATEデスクトップ環境は動作が変でした。pkgin search mateで必要なパッケージを見つけて、ひとつひとつインストールしていきました。その結果、動作が幾分まともになりましたが、それでも良く分からないエラーが出ます。NetBSDのpkgsrcにあるMATEは不完全なのか、僕のマシン環境に何か問題が残っているのか、わかりません。

さらに困るのか、日本語変換が動かないことです。これまではIBus-Mozcを使っていて、普通に変換出来ていたのですが、まったく動作しなくなりました。/usr/pkg/bin/ibus-daemonが頻繁に落ちるし、MATEが駄目なのか、IBusが駄目なのか、それともMozcが駄目なのか、まったくわからない状態になりました。

pkgin search ibusで関連パッケージを見ていたら、Mozc以外にもKKCという日本語変換を見つけました。試しにインストールしてみたら、ちゃんと動きます。もちろん日本語変換もできます（普通は出来て当然なのですが）。Webを見ても、日本語変換というとMozcを使う場合が多く、KKCの情報はあまり見つかりません。しかしMozcでなければならない理由があるわけでもないので、これからはKKCを使っていこうと思います。

現状では次のようなパッケージが入っています。日本語以外の入力メソッドもあったので、ハングル入力用メソッドを入れていました。この入力メソッドに切り替えることはできるのですが、入力方法がわからず、利用できていません。そのうち調べようと思っています。

1. ibus-1.5.20nb1 Intelligent Input Bus
2. ibus-hangul-1.5.0 Hangul engine for IBus input platform
3. ibus-kkc-1.5.21nb9 Japanese KKC input method for ibus
4. ibus-mozc-2.20.2673.102nb12 Japanese inputmethod Mozc engine

IO DATA WN-G150UMKの謎

dynabook SS SX/15AのOSをNetBSD/i386に入れ換えて利用しています。購入時にはMicrosoft WIndows Vista Businessが入っていましたが、OSのフェーズアウト後にNetBSDに入れ換えましたので、もう数年たちます。以前にはなかったのですが、ここ4月以降（時期は特定できませんが）、深夜（であることが多いが、それ以外の時間帯もあります）にカーネルが落ちるようになりました。/var/crashにできるファイルを確認すると、落ちる場所は決まっていて、無線LANドライバが怪しい感じです。

もしかすると無線LANインターフェイスが故障したのかもしれないと考えました。何分にもノートPCなので、デスクトップPCのように自在に構成変更できるわけではありません。しかし無線LANであれば、USBポートに挿す無線LAN子機がありますから、それを使ってみようと思いました。そこでIO DATAのWN-G150UMKを買ってきました。

USBポートに挿してみたところ、デバイスは認識されています。

Jun 26 18:17:12 dbss /netbsd: [ 183.1100427] urtwn0 at uhub4 port 1
Jun 26 18:17:12 dbss /netbsd: [ 183.1100427] urtwn0: I-O DATA DEVICE, INC. (0x4bb) WN-G150UM (0x94c), rev 2.00/2.00, addr 2
Jun 26 18:17:12 dbss /netbsd: [ 183.2701411] urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R, address XX:YY:ZZ:b3:cb:3b
Jun 26 18:17:12 dbss /netbsd: [ 183.2701411] urtwn0: 1 rx pipe, 2 tx pipes
Jun 26 18:17:12 dbss /netbsd: [ 183.2701411] urtwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
Jun 26 18:17:12 dbss /netbsd: [ 183.2701411] urtwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps

urtwn0として認識され、IPアドレスも割り当てられています。

urtwn0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        ssid FURUSAWA nwkey 65536:"",0x0123456789,"",""
        powersave off
        bssid AA:BB:CC:DD:EE:FF chan 12
        address: XX:YY:ZZ:b3:cb:3b
        media: IEEE802.11 autoselect (OFDM54 mode 11g)
        status: active
        inet 192.168.1.17/24 broadcast 192.168.1.255 flags 0x0
        inet6 fe80::8563:7777:8888:9999%urtwn0/64 flags 0x0 scopeid 0x5
        inet6 240b:11:c000:200:2320:84f:2222:3333/64 flags 0x0

ところがpingが通りません。外からも中からも、全パケットが失われます。どうしてこういうことになるのでしょうか。親機と接続できないというのであれば、それはそれで問題ですが、少なくとも親機との通信はできているし、DHCPでアドレスが貰えているわけです。それなのに、何故にpingが通らないのでしょうか。

解決すべき問題が、またしても増えてしまいました。

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

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_chkやpkginなどのツールもあるようですし、そもそもソースから自前でビルドしなくても、出来合いのバイナリを使う方法もあるようです。どうすれば良いのか、もう一度考えてみようと思います。

「科学出版の彼我の差」を読んで

東京大学出版会の広報紙「UP」の2019年6月号に「科学出版の彼我の差」（塚谷裕一） が掲載されていました。これを読んで、出版における著者と編集担当者との関係について考えてみました。

出版するのが科学啓蒙書だろうが、文学作品だろうが、出版社から発行する場合には、出版社には編集担当者がついているはずだと思っています。しかし編集担当者の役割における著者との関係がどうなっているのかは、実はよくわかりません。理想的にどうあるべきなのかも、現実としてどうなっているのかも、よくわかりません。

最近では著者から電子媒体で原稿をもらうことが殆どなのではないかと思います。昔のように原稿用紙に書かれた原稿を受け取って、読みにくい字を解読しつつ活字に組んで、印刷にこぎつける、というのは、もはや昔話にすぎないのではないかと思います。そういう昔のやり方をしていた時代であれば、編集者の役割は、著者から受け取った原稿を印刷し製本できるように「変換」する作業担当者だと考えてもいいかもしれません。編集担当者の役割が「変換作業員」でしかないならば、電子媒体で原稿が入稿される昨今では、その役割と意義が無くなりつつあると、自他とも思っていてもおかしくないかもしれません。

これに対して、上述した文章でも次のように表現しているような行為が行われていれば、編集担当者の役割は、原稿用紙の時代だろうが、電子入稿されようが、変わりようがないはずです。

 いずれも編集者、あるいはエージェントが内容を精査し、相当突っ込んだレベルで著者にだめ出しをして、磨きに磨き上げた本である。場合によっては、一から書き直しということも少なくない。逆に言えば、著者と編集者が二人三脚で良いものを目指すという姿勢が明確である。編集者は文字通り、編集という仕事をきちんとやり遂げているのだ。彼らには、本というものは、筆者自身が持つ素材と筆力に、編集者が持つプロのノウハウが組み合わさって、初めて完成する製品だ、という意識がある。

ところが日本ではこうなっていないと論じ、次のように書かれています。

作家と編集者の間の関係が対等ではなく、編集者側はありがたく作品をいただくのみ、という強い上下関係があると、こういうことが起きかねない。この伝統が、科学啓蒙書の出版の世界にも持ち込まれてしまったのではないだろうか。

著者側の意識として、（自分が書いた）原稿に対して編集者（ごとき）が口を出すなどとは何様のつもりであるか、という側面があるのかもしれません。著者と編集者は上下関係ではなく、対等であるはず（べき）ですが、見かけ上において編集者は著者に対して「先生」とか「玉稿」いう呼び方をしますので、勘違いする著者が出現してもおかしくありません。

「お客様は神様です」という言葉が独り歩きをしている現象とも類似性を感じます。そもそも客商売をしている側の心の持ちようと考えられていた言葉だったはずなのに、客の側が自分を「神様」と見なしてクレームをつけるという使い方をしてしまうような状況もあるやに聞き及びます。

話を戻すと、著者と編集者は対等な関係です。しかしそこには編集者にプロ意識を持っていることが要求されるでしょう。弱気な編集者であれば、上下関係に逃げた方が、ある意味で楽なのです。プロ意識を持っているからと言って、別に偉そうに振舞う必要はないし、そうすべきではないのですが、「プロ意識を持つ」とは口で言うほど簡単でもないとは思います。しかしそういう方向を目指したいものだとは思います。

「AIは「人を真似る」のか」を読んで

東京大学出版会の広報誌「UP」の2019年5月号に「AIは「人を真似る」のか」（松崎拓也、東中竜一郎）が掲載されていました。これを読んで、ふと近年のAIによる対話について考えてみました。

はるか昔には「人工無能」 と呼ばれた会話もどきがありましたが、当時の計算機資源の限界を考えればどうしようもなかったでしょう。最近では、計算機の高性能化や、その背後の研究理論の進展もあり、下手をすれば人間が相手をしていると勘違いしてしまうようなレベルもあるようです。その一方で、どうしようもなく頓珍漢な対話を繰り広げてしまうこともありますが、将来的にはまともになっていくのだろうとは思います。

上述した文章には次のようなことが書かれていました。

会話分析の研究者が言うには「人間の会話は破綻しません。会話が破綻するときは関係が壊れたときです。」

人間は（当然ながら機械ではないので） 言い間違いはするし、おかしな発言が多々あっても、人間同士の対話はそんなに簡単に破綻していないようです。それは何故か、ということを研究するのは、その分野の研究者が日々考えていることですから、素人がどうこういうことはないでしょう。しかしAIによる対話は、（人間が無意識におこなっている）そのような対話を目指すのでしょうか。

人間同士が対話するときには、発話に現れる技術的側面（つまり、なにがしかの知識を持っているか否かや、日本人なら日本語の文法に即して発話を組み立てたり、理解したりできるか、のような）よりも重要なのは、その上位にある当人の意思ではないかと考えるのです。自分の言い間違いや勘違いとか、対話している相手から投げかけられた発話に飛びついて、発話ごとに対話の行方が次々とかわっていくのではなく、当人の意思が対話の方向性を握っていて、発話に振り回された方向性が、あっちにいったり、こっちにいったりしないのではないかと思うのです。

AIによる対話が、小手先の技術を超えた意思を持って行うことができるようになる日が、はたして来るのかわかりません。計算機が意思を持つというのは、いったいどんな未来なのでしょうか。

「鬼に金棒」が使える状況

「鬼に金棒」という諺は一般によく知られていると思います。手持ちの辞書（『明鏡国語辞典』携帯版、初版）には以下のように説明しています。

それを手に入れることによって、強いものがますます強くなることのたとえ。

諺の意味はその通りだと思いますが、その使い方には何らかの制約があるのでしょうか。例えば良い意味で使うとすれば、次のようになると思います。

彼は一流大学を優秀な成績で卒業した上に、超難関の国家資格も取得した。まさに鬼に金棒だ。

しかし悪い意味にも使っても構わないのか、気になっています。例えば悪い意味で使うとすれば、次のような例（安直なSFみたいですが）はどうでしょうか。

世界征服を狙う秘密結社を率いる彼が、ついに世界を破滅に陥れることができる最終兵器の開発に成功した。これで彼は鬼に金棒だ。

もし「鬼に金棒」という諺が良い意味にしか使えないとすれば、悪い意味を表現したいときに使える諺としては何かあるのでしょうか。ふと気になりました。

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以外の類似ツールを検討してみようかと考えています。

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年4月にノートルダム大聖堂が火災で被害を受けたことを契機に、2011年春にNHKで放映されていた「ダークエイジ・ロマン 大聖堂」を録画しておいたDVDで視ています。毎週1話ずつ視るようにしていて、第7話「奇跡を呼ぶ像」まできました。いちど最後まで視た作品ですから、結末まで分かっているのですが、久しぶりに視たこともあり、また作品自体も気に入っているので、ストーリに引き込まれています。

第7話には、キングズブリッジ修道院の院長を追われたフィリップ修道士と、仲間に引き込もうとするウェイルラン司教との駆け引きのシーンがあります。フィリップはウェイルランの誘いを拒否し、次のようなセリフを吐きます。

あなたの道徳を支える壁は腐っている。

言わんとすることは理解できますが、日本なら別な表現をとるでしょう。日本の建築は柱を建てることが基本ですが、この作品の舞台であるイングランド（など西洋諸国）では壁を作ることが建築の基本になっています。

日本の伝統的な建築物では、柱を建てることが大切で、壁はおまけ（と言っては言い過ぎかもしれませんが）です。だからこそ「大黒柱」 のような表現もあります。これに対してイングランドなどでは、壁を作ることが大切で、ついでに屋根を掛けると建物が完成します。

もし日本の作品で同様の表現を必要とする場面があれば、「あなたの道徳を支える柱は腐っている」となるでしょう。これは文化の違いです。ドラマを楽しむ時に、台詞の隅々にまで注意を払うことはないかもしれませんし、「道徳を支え」ているのが壁だろうが柱だろうが、ストーリの流れとは関係ないでしょう。とは言え、些細と思われる事柄にまで意識を向けることで、作品をさらに楽しめるようになると思うのです。

kidnapとabductの和訳

The Japan Times Alphaで連載されているJames Tschudy氏のエッセイ「Odds & Ends」の2019年6月の月間テーマは「Idioms」です。2019年6月7日号に掲載された第1回のタイトルは「Go」でした。ここでは「go」が使われているイディオムが語られていますが、「go missing」を例示するために次のように書かれています。

I saw some statistics from the U.K. that said a person went missing every 90 seconds in 2018.  On average, 1 out of every 200 children will go missing.  The reason is not clear.  They might have run away from home or been kidnapped or abducted.

ここで考えたいのは、最後の文にある「kidnap」と「abduct」です。手持ちの辞書（『ウィズダム英和辞典』三省堂、第4版）では、kidnapを「誘拐」、abductを「誘拐、拉致」と示しています。誘拐と拉致は、結果的には「連れ去ること」ですが、拉致の方には「強制的な」という含意があります。

英文を和訳して理解すると原文の意図を曲げる恐れがありますから、手持ちの英英辞書（『Collins COBUILD New Student's Dictionary』）で確認してみました。

まず「kidnap」 には次のように書かれています。

Someone is to take them away illegally and by force, and usually to hold them prisoner in order to demand something from their family, employer, or government.

また「abduct」は以下の通りです。

If someone is abducted, he or she is taken away illegally.

 英語圏の感覚では、どちらも「take away illegally」ということなので、エッセイでは同じ類の語を重ねて書いているようにも受け取れます。

さらに手持ちの類語辞書（『Oxford Learner's THESAURUS』） を確認したところ、「abduct」には以下のような情報が記されていました。

Abduct is the term used in law for this act.  Abduct is usually used to talk about taking away woman and children by force, especially when the motive (= reason) is sexual, not political or for money.

このように調べてみると、「kidnap = 誘拐」や「abduct = 拉致」と単純に日本語に置き換えるわけにはいかないのではないかと思います。このエッセイが、その類の分野の専門であるなら、kidnapとabductを使い分けるような和訳をすべきだと思いますが、このエッセイの本旨は「単語goを用いた慣用句」なので、「been kidnapped or abducted」を「誘拐や拉致」と和訳した方がよいのかは迷うところです。大雑把にまとめて「連れ去られる」としてしまうのも、ひとつの方法ではないかとも思います。

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を入れ直したら、問題は解決しました。

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を削除してしまうことにしました。

NetBSD/i386 8.99.41 kernel panic at /usr/src/sys/kern/kern_condvar.c line 170

dynabook SS SX/15Aで利用しているNetBSD/i386のパッケージを更新するためにpkg_rolling-replaceを実行しています。ビルドに時間がかかりますが、エラーが出ないのであれば、待っていれば終わるので、1週間くらいは待つつもりでいます。しかし何故か毎晩深夜にカーネルが落ちてしまい、処理が中断してしまうのです。

何分にも旧いマシンなので、ハードウェアに何か故障があっても不思議ではありません。ちなみに/var/carshにはメモリイメージが残っているのですが、カーネルの解析は難しいので、見ても判らないので放置していました。

毎晩カーネルが落ちて処理が中断するので、クラッシュした場所くらいは確認しておこうと思うようになりました。その結果を見ると、どうも同じ場所で落ちています。

# gunzip netbsd.15.core.gz
# gunzip netbsd.15.gz
# crash -M netbsd.15.core -N netbsd.15
Crash version 8.99.41, image version 8.99.41.
System panicked: kernel diagnostic assertion "(l->l_pflag & LP_INTR) == 0 || panicstr != NULL" failed: file "/usr/src/sys/kern/kern_condvar.c", line 170
Backtrace from time of crash is available.
crash> bt
_KERNEL_OPT_NARCNET(0,104,c011b026,8,c06f21c3,c1137ded,0,104,c10a6888,dc6bdee8) at 0
_KERNEL_OPT_BEEP_ONHALT_COUNT(104,0,c10a6888,dc6bdee8,c4d142e0,c516abe8,c516abe4,dc6bdedc,c0db688e,c10a6888) at _KERNEL_OPT_BEEP_ONHALT_COUNT+0x1
vpanic(c10a6888,dc6bdee8,dc6bdf0c,c090b6a0,c10a6888,c10a67ef,c115b35c,c115b338,aa,c5169000) at vpanic+0x13d
kern_assert(c10a6888,c10a67ef,c115b35c,c115b338,aa,c5169000,c4d142e0,c5169000,c516abe4,c516abe8) at kern_assert+0x23
cv_wait(c516abe8,c516abe4,ffffffff,c4d11140,20000000,c4d142e0,c5169000,dc6bdf94,c02cc8e8,c5169004) at cv_wait+0x1a8
wpi_stop(c5169004,1,8,20000000,2,0,dc9c7810,c5422940,c0920e86,6) at wpi_stop+0x80
wpi_softintr(c5169000,0,c0100400,1673000,1670010,30,c0100010,10,0,1d14020) at wpi_softintr+0x2cb
softint_dispatch(c51d70a0,4,37bbaff2,a1a6dfbe,36bef7da,27b6dfdb,dc6c0ff0,dc6c0e14,dc6c0e68,80050033) at softint_dispatch+0xc1
Bad frame pointer: 0xc4fdbe48
crash>

ハードウェアの故障でクラッシュしているなら、落ちる場所がランダムに変わるのではないかと思います。それなのにクラッシュしている場所がいつも同じという事は、カーネルの何処かにバグがあるのかもしれません。

gawk: Shared object "libreadline.so.7" not found

dynabook SS SX/15AにインストールしているNetBSD/i386のアプリケーションはpkgsrcから入れています。もう1年以上更新していないのでpkg_rolling-replaceを使って入れ換えることにしました。この処理は何日もかかりますし、たいてい途中でエラーがでて何かしらの対処をおこなう必要があります。

案の定さっそくエラーが出ました。

checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating libguile/gen-scmconfig.h
gawk: Shared object "libreadline.so.7" not found
config.status: error: could not create libguile/gen-scmconfig.h
*** Error code 1

Stop.
make[1]: stopped in /usr/pkgsrc/lang/guile20
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/lang/guile20
*** 'make replace' failed for package guile20.

lang/guile20をビルドしようとして失敗しています。/usr/pkgsrcの不整合でもあったのかと思ったので、CVSで最新化してみましたが、やはり同じエラーになります。

gawkがエラーを出しているので、とりあえずgawkを動かそうとしてみたらエラーが出ます。まさにログに現れていたのと同じエラーです。何故かgawkが動かなくなってしまっていて、それが原因だったようです。

pkgsrcでlang/gawkを入れ直しました。これまではgawk-4.1.4nb1でしたがgawk-5.0.0になりました。この状態で改めてpkg_rolling-replaceを動かしたところ、guile20で止まることもなく、処理を続けています。

「Windowsファイアウォールとマカフィーファイアウォールの両方が無効になっています」というメッセージが起動時に出る

デスクトップPCでWindows10を利用しています。このマシンを購入した時点ではWindows8でしたが、Windows10に更新し、その後も最新を保っています。またセキュリティは、数年前からBIGLOBEが提供するマカフィー・スイートを利用しています。

これらを利用していて、これまで問題なかったのですが、先月頃よりWindows10を起動してログインすると次のようなメッセージが毎回出るようになりました。

 Windowsファイアウォールとマカフィーファイアウォールの両方が無効になっています。タップまたはクリックして利用可能なオプションを表示してください。

しかしマカフィーの設定を確認しても、ファイアウォールは「有効」になっています。何故このようなメッセージが出るようになったのか不審です。

「Notre-Dame - les Plus Grands Airs de la Musique Sacrée」のCDを購入

2019年4月に火災で被害を受けたノートルダム大聖堂の再建を支援するために発売された「Notre-Dame - les Plus Grands Airs de la Musique Sacrée 」を購入しました。

UNIVERSAL MUSIC JAPANの公式サイトではCDの日本発売は未定となっていますが、輸入盤を購入することは可能です。GW連休の頃にタワーレコードで予約を受け付けていたので、さっそく予約しました。予定よりも発売が多少延期になりましたが、5月下旬に入手できました。

スヌーピーミュージアム展

梅田のグランフロント大阪北館で開催されている「スヌーピーミュージアム展」に行ってみました。美術館や博物館の特別展などに行くと、いつも出口にミュージアムショップがありますが、この展示会も例外ではありませんでした。買ってみたいグッズはいろいろとありましたが、考えた挙句、図録を買いました。図録には「THE BEST OF PEANUTS」もついています。

PEANUTSは谷川俊太郎の翻訳です。ずいぶん昔に持っていたコミックとは微妙に訳が違うような気がするのです。もしかすると気のせいかもしれないし、かなり昔の記憶なので勘違いかもしれません。

確かめてみると、一部で和訳を変えているところがあるようです。「THE BEST OF PEANUTS」の42頁には、1965年2月12日付の4コマ漫画が掲載されています。この1コマ目の台詞は次のようになっています。

恋におちるなんてまともじゃなかったとしか思えないよ！

これと同じ作品が、手元に残っていたコミックに掲載されていました。『失恋しちゃった スヌーピー』というタイトルでツル・コミック社が発行したもので、新書版です。290円とありますが、発行日は見当たりませんでした。この15頁に同じ作品が掲載されており、そこでは1コマ目の台詞が次のようになっていました。

恋におちるなんて気でもちがったとしか思えないよ！

この本では欄外に英語も併記されていて、それは次のようになっていました。

I must have been crazy to have fallen in love!

この後に続く3コマの台詞は、いずれも同一でした。

「～がなかったか」対「～があったか」

ニュースを聞いていると、「～がなかったか」という表現をよく耳にしますが、これは意図的に選択されているのだろうかと疑問に思うことがあります。

例えばNHKのWebサイトには「 電車逆走事故 14人重軽傷 “無人運転”に不具合か解明へ」（2019年6月2日 5時11分）という報道の中に次のような表現があります。

警察は無人運転のシステムに不具合がなかったかなどを調べて事故の原因を解明することにしています。

逆走事故が現実に起きているわけですから、不具合が「なかったか」などを調べるのではなくて、不具合が「あったか」などを調べるのではないのかと疑問に思います。もちろん捜査にあたって予断を持つことなく調べることは必要だと思いますが、不具合が「なかったか」であっても、不具合が「あったか」であっても、どちらかの方向に「予断を持っている」のは同じことではないかと感じます。

このような問題意識をもって報道に接していると、「～があったかを調べている」という表現を耳にすることは殆どない印象があります。これが事故ではなく、何らかの事件であり、関与を疑われた人物についての報道であれば、推定無罪の原則からも、「～がなかったを調べている」という表現が使われたとしても、わからないではありません。

もしかすると報道原稿を書く立場にとっては、「～がなかったか」と「～があったか」とは同等であり違いは無いということなのでしょうか。もしそうであれば驚くべき事です。表現の選択にあたり、厳密には意味の異なる表現でありながら、実質的な意味に違いがないということになるからです。