2020年2月にNetBSD 9.0がリリースされたので、dynabook SS SX/15AにインストールされているNetBSD/i386を8.1から9.0に更新しました。アプリケーションはpkgsrcからバイナリでインストールしていますが、この更新は後日おこなおうと考えています。
更新は恙なく終わりました。まず最初にカーネルだけを更新して起動できることを確認しておきます。そこで問題なければ（実際に問題ありませんでしたが）それ以外のセット（.tgzファイル）も更新します。更にX関係のセット（.tgzファイル）も更新しました。
この状態で、ログインしてMATEデスクトップ環境が動作しているかを確認しておきました。特に問題はありませんでしたが、メニューに「シャットダウン」の項目が復活していました。
そもそも「シャットダウン」はメニュー項目に存在していたのですが、昨年MATEを更新したら、無くなってしまいました。何かの設定に不備でもあるのかと調べてみましたが、不明のままでした。ところがOSを更新しただけ復活するのは、利用できて有り難いのですが、原因が不明なだけに、いつ再び利用できなくなるかと思うと不安でもあります。
2019-12-18
Maxima、xmaxima、wxMaxima
スマホのアプリで「Maxima on Android」を知り、『スマホで数学！』という書籍が出版されていることを知りました。Maxima自体は以前から知っていましたが、それほど使いこなしている訳でもありません。数式処理ではWolframAlphaを使うことの方が多かったのですが、せっかくなので今後はMaximaを使おうかと思っています。
NetBSD/i386にもpackageにMaximaがあるので、インストールしてみました。ベースとなるMaximaは同じものですが、ユーザインタフェースが異なる3種類がインストールできました。
数式が綺麗なwxMaximaを使いたいところですが、なんだか動きが変です。最も肝心な数式を入出力するウィンドウが出ず、外枠やメニューバーばかりが表示されます。メニューは日本語化もされていて、ちゃんと動いてくれれば文句なしなのですが、これでは使いものになりません。デスクトップ環境にMATEを使っているのがマズいのでしょうか。
xmaximaは、wxMaximaのように美しい数式が表示される訳はありません。端末でmaximaを動かしているのと、見かけは変わらない感じです。ただしグラフを表示させようとすると、自動的に別ウィンドウが開くので、便利と言えば便利です。
端末でmaximaを使うよりはxmaximaの方がマシかなと思っているところです。
今回は試していませんが、Emacs上でMaximaを扱うためのimaximaというものがあるようです。Emacsの中で何でもするような使い方をしている人には向いているのかもしれませんが、僕はそうではありません。Emacsは使いますが、viも使うし、Emacsだけで何でもしたい訳ではありません。でも後日imaximaも試してみようと思います。
NetBSD/i386にもpackageにMaximaがあるので、インストールしてみました。ベースとなるMaximaは同じものですが、ユーザインタフェースが異なる3種類がインストールできました。
- 端末で使うシンプルなMaxima
- 端末版MaximaがX上で動くxmaxima
- 数式が綺麗に出るwxMaxima
数式が綺麗なwxMaximaを使いたいところですが、なんだか動きが変です。最も肝心な数式を入出力するウィンドウが出ず、外枠やメニューバーばかりが表示されます。メニューは日本語化もされていて、ちゃんと動いてくれれば文句なしなのですが、これでは使いものになりません。デスクトップ環境にMATEを使っているのがマズいのでしょうか。
xmaximaは、wxMaximaのように美しい数式が表示される訳はありません。端末でmaximaを動かしているのと、見かけは変わらない感じです。ただしグラフを表示させようとすると、自動的に別ウィンドウが開くので、便利と言えば便利です。
端末でmaximaを使うよりはxmaximaの方がマシかなと思っているところです。
今回は試していませんが、Emacs上でMaximaを扱うためのimaximaというものがあるようです。Emacsの中で何でもするような使い方をしている人には向いているのかもしれませんが、僕はそうではありません。Emacsは使いますが、viも使うし、Emacsだけで何でもしたい訳ではありません。でも後日imaximaも試してみようと思います。
2019-11-29
ハングルフォント：baekmuk-ttf
dynabook SS SX/15AにNetBSD/i386をインストールして利用しています。GUIとしてMATEデスクトップ環境（1.22.1）を入れて、日本語環境を整えてあります。追加してハングルの入出力も出来るようにしたくて、iBus用の入力メソッド（ibus-m17n-1.3.4nb26）を入れることで、入力は出来るようになっています。
これまではGNU Emacs（26.1） で動作確認を行っていました。iBus入力メソッドを切り替えるだけで、ハングル入力ができますし、表示も出来ていましたので、環境構築はできていると思っていました。ところがNightly（67.0.4）ではハングルが表示できなかったので、これはNightly単独の問題かと思っていました。
本当にNightlyの問題なのか確認しておこうと思い、MATE端末やLibreOffice（6.2.3.2）でもハングルが表示できるか確認したところ、実は表示できないことが発覚しました。入力自体は出来ているようです。
おそらくフォントが入っていないのが原因だろうと推測しました。きっとWebを検索すればフォントが見つかるだろうとは思いましたが、何が標準的なフォントなのかは、どうやって確認すれば良いのでしょうか。つまり日本語であればIPAex明朝やゴシックを入れている訳なのですが、このように標準的なハングルのフォントの名前が分からないのです。
pkgsrcのfontsカテゴリにある各ディレクトリにあるDESCRファイルを調べてみると、どうやらBAEKMUKというの名前のフォントが一般的のように思えます。そこでpkginでインストールできるパッケージを調べると、次のようになりました。
TeX用フォントは今回無関係だと思うので、X11フォントとTrueTypeフォントのどちらかを入れれば良さそうです。どちらにしようかと思ったのですが、TrueTypeフォントの方が綺麗だろうと思い、こちらをインストールしました。これでNightlyで確認したら、無事にハングルが表示されるようになりました。
以上でハングル入出力が出来るようになって、一安心です。しかし何故Emacsでは当初から表示出来ていたのか、謎です。
これまではGNU Emacs（26.1） で動作確認を行っていました。iBus入力メソッドを切り替えるだけで、ハングル入力ができますし、表示も出来ていましたので、環境構築はできていると思っていました。ところがNightly（67.0.4）ではハングルが表示できなかったので、これはNightly単独の問題かと思っていました。
本当にNightlyの問題なのか確認しておこうと思い、MATE端末やLibreOffice（6.2.3.2）でもハングルが表示できるか確認したところ、実は表示できないことが発覚しました。入力自体は出来ているようです。
おそらくフォントが入っていないのが原因だろうと推測しました。きっとWebを検索すればフォントが見つかるだろうとは思いましたが、何が標準的なフォントなのかは、どうやって確認すれば良いのでしょうか。つまり日本語であればIPAex明朝やゴシックを入れている訳なのですが、このように標準的なハングルのフォントの名前が分からないのです。
pkgsrcのfontsカテゴリにある各ディレクトリにあるDESCRファイルを調べてみると、どうやらBAEKMUKというの名前のフォントが一般的のように思えます。そこでpkginでインストールできるパッケージを調べると、次のようになりました。
# pkgin search baekmuk
tex-baekmuk-doc-2.2 Documentation for tex-baekmuk
tex-baekmuk-2.2 Baekmuk Korean TrueType fonts
ko-baekmuk-2.1nb1 X11 fonts for KSX 1001 Korean standard (baekmuk foundry)
baekmuk-ttf-2.2nb3 = Baekmuk family Korean TrueType fonts
=: package is installed and up-to-date
<: package is installed but newer version is available
>: installed package has a greater version than available package
TeX用フォントは今回無関係だと思うので、X11フォントとTrueTypeフォントのどちらかを入れれば良さそうです。どちらにしようかと思ったのですが、TrueTypeフォントの方が綺麗だろうと思い、こちらをインストールしました。これでNightlyで確認したら、無事にハングルが表示されるようになりました。
以上でハングル入出力が出来るようになって、一安心です。しかし何故Emacsでは当初から表示出来ていたのか、謎です。
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の更新は自前でビルドする必要がありそうです。
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-14
NetBSDのMATEデスクトップ環境で「シャットダウン」メニューが無くなった気がする
dynabook SS SX/15AのOSをNetBSD/i386に入れ換えて使っています。以前はOSもpkgもカレントのソースコードを取得してきて自前でビルドしていました。しかし今年6月頃にpkgを入れ替えようとして、ハードウェアのディスク不足や不調などの原因により、かなり苦労したため、ビルド済みのバイナリを取得してインストールする方針に転換しました。
さらにOS本体もカレントのソースコードを自前でビルドしていたのを止めようと考えていたので、NetBSD 8.1の公式リリース版を使うことにしました。インストールされていたOSがNetBSD 8.1よりは微妙に新しいカレントだったので、バージョンが戻ることになりまる。トラブルが発生しないか心配だったのですが、無事にNetBSD 8.1になったようです。
普段使っているアプリケーションの動作確認をしてみましたが、問題なさそうです。
ただし1つだけ、これまでとは動きが異なる箇所があります。MATEデスクトップ環境を利用していて、メニューに「シャットダウンする」というのがあったはずなのですが、見当たりません。メニューからシャットダウンできなくても、他に方法はいくらでもあるので実害はないのですが、気になります。
MATEデスクトップ環境に限らず、今どきのデスクトップ環境はDbusやらPolicyKitやらを使っていて、問題解決のために何から手をつけたら良いのか、よく分かりません。
さらにOS本体もカレントのソースコードを自前でビルドしていたのを止めようと考えていたので、NetBSD 8.1の公式リリース版を使うことにしました。インストールされていたOSがNetBSD 8.1よりは微妙に新しいカレントだったので、バージョンが戻ることになりまる。トラブルが発生しないか心配だったのですが、無事にNetBSD 8.1になったようです。
普段使っているアプリケーションの動作確認をしてみましたが、問題なさそうです。
ただし1つだけ、これまでとは動きが異なる箇所があります。MATEデスクトップ環境を利用していて、メニューに「シャットダウンする」というのがあったはずなのですが、見当たりません。メニューからシャットダウンできなくても、他に方法はいくらでもあるので実害はないのですが、気になります。
MATEデスクトップ環境に限らず、今どきのデスクトップ環境はDbusやらPolicyKitやらを使っていて、問題解決のために何から手をつけたら良いのか、よく分かりません。
2019-06-29
MATEでストップ環境でアプリケーションの動きがおかしくなった（が、不具合が解消されたところもある）
dynabook SS SX/15AのOSをNetBSD/i386に置き換えて、MATEデスクトップ環境を利用しています。pkgsrcから入れていたアプリケーションの全更新に失敗し、既存の環境が崩壊したので、再構築をしています。今日になって（何故か）昨日まで動いていたアプリケーションの挙動がおかしくなりました。全てを確認している訳ではありませんが、次のような挙動が確認されています。それらは、いずれも昨日までは普通に出来ていたのですが、何故いきなり駄目になったのか分かりません。
バイナリが落ちて（コアを吐いて）動かないのであれば、（それはそれで困りますが）理解できなくもありません。しかしコアは出来ていないのに、アプリケーションが動かないのです。 何が悪いのか見当もつきませんが、唸っていたところで解決するわけではありません。こういう時には何処かにエラー情報が残っていないか探してみるのが、問題解決の第一歩になります。
そこでホームディレクトリで直近の書き込みがあるファイルを探してみると~/.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を確認すると、次のようなエラーが出ていました。
PolicyKitで起動に失敗しているようなのですが、これを解決する方法が分かりません。しかしPolicyKitは権限に関する機能を担っているはずですから、rootアカウントなら動くのに、一般アカウントでは駄目というのも、関連していそうな気がします。
まだ問題は解決していませんが、解決の方向性は間違っていないような気がしています。
- MATE端末のウィンドウが開かない。
- LibreOfficeのスプラッシュ画面は出てくるのに、そこで止まってしまう。
- 画面上部のメニューバーから「システム」→「furusawaのログアウト...」を選んでも、ウィンドウが出てこなくなった。
- 画面上部のメニューバーから「システム」の下にあったシャットダウン用のメニューが消えた。
- 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アカウントなら動くのに、一般アカウントでは駄目というのも、関連していそうな気がします。
まだ問題は解決していませんが、解決の方向性は間違っていないような気がしています。
2019-06-28
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関連のパッケージは次のようになりました。
まだ完璧とは言えませんがMATEデスクトップ環境が修復できたので、次に入力メソッドを復旧させます。環境が崩壊する前まではMozcで日本語入力をしていましたが、MATEやIBusを修復しても、Mozcが動作しません。偶々試してみたKKCが問題なく動いているので、Mozcの問題なのではないかとおもっています。
次に、以前は無かったのですが、ハングルの入力メソッドも導入しておくことにしました。まずはibus-hangulを入れてみました。導入はできたし、使おうとして（Mozcのように）落ちることもないのですが、肝心のハングル入力が出来ません。おそらく（勘ですが）日本語変換のように、ハングル入力モードとASCII入力モードを切り替えるのではないかと思っているのですが、どのキーなのか分かりません。Webに情報が無いかと調べていたら、ハングル入力にはibus-m17nという入力メソッドもあるようです。そこでこちらを使ってみることにしました。当初はibus-hangul同様にハングル入力が出来なかったのですが、画面右上にある「한」をクリックしてみると、ハングルの入力方式を選択する画面が開いたので「2ボル式」を選びました。
これで日本語とハングルの入力が可能になりました。
MATEデスクトップ環境では、画面上部のメニューから「システム」→「設定」→「IBusの設定」を選び、「入力メソッド」タブを開くと、登録済みの入力メソッドの一覧が表示されます。その右側には「設定」ボタンがあるのですが、KKCではグレー表示となり押せないようになっています。ところが、画面右上でクリックすると現れるメニュには「設定」という項目があり、それを選ぶと「かな漢字変換の設定」という画面が出てきます。どうしてこういうことになるのか、パッケージ自体が不完全なのか、それとも環境が復旧できていないのか、謎です。これは些細な問題であり、もっと深刻な不具合もあるので、順番に解決していこうと思います。
最終的に導入したIBus関連のパッケージは次のようになりました。
- ibus-1.5.20nb1 Intelligent Input Bus
- ibus-m17n-1.3.4nb26 M17N engine for IBus platform
- ibus-kkc-1.5.21nb9 Japanese KKC input method for ibus
2019-06-27
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を使っていこうと思います。
現状では次のようなパッケージが入っています。日本語以外の入力メソッドもあったので、ハングル入力用メソッドを入れていました。この入力メソッドに切り替えることはできるのですが、入力方法がわからず、利用できていません。そのうち調べようと思っています。
ところが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を使っていこうと思います。
現状では次のようなパッケージが入っています。日本語以外の入力メソッドもあったので、ハングル入力用メソッドを入れていました。この入力メソッドに切り替えることはできるのですが、入力方法がわからず、利用できていません。そのうち調べようと思っています。
- ibus-1.5.20nb1 Intelligent Input Bus
- ibus-hangul-1.5.0 Hangul engine for IBus input platform
- ibus-kkc-1.5.21nb9 Japanese KKC input method for ibus
- ibus-mozc-2.20.2673.102nb12 Japanese inputmethod Mozc engine
2017-01-17
XDM authorization key matches an existing client
dynabook SS SX/15Aに搭載されているWindows Vistaのサポート終了が目前に迫ってきました。去年末までに外付けHDDを利用して、NetBSD/i386やMATEなどの動作検証をおこなってきました。問題がないわけではなく、荒削りな個所がいろいろとあるのですが、移行してもなんとかなるだろうと見込んでいます。
昨年のうちにマシン起動後にxdmでログインできるように設定したのですが、何故かログインできたり、できなかったりする症状に悩まされていました。xdmはマシンを利用するときの入り口になるものです。これから個々のアプリケーションの動作検証を進めていく前に、xdmで差し障りなくログインできるようにしておこうと思います。
xdmでログインできないというのは具体的にどのような状況になるのか説明しておきます。xdmのダイアログウィンドウにユーザー名とパスワードを入力すると、MATEが起動しそうに見えるのですが、一瞬間をおいて、再びxdmに戻ってログインを求める画面になってしまうのです。なにかエラーが出ているのでしょう。ホームディレクトリの.xsession-errorsを確認すると「XDM authorization key matches an existing client」というエラーが記録されていました。
このメッセージが何を訴えているのか分からないので、Webで検索してみました。すると2014年にFreeBSDのメーリングリストに流れたメールが見つかりました。xdm-configに次の設定を追加すれば解決するそうです。
問題が解決したのは結構なことですが、どうしてこれで問題が解決したのか理解できていないのは気持ちの悪い状態です。X関係は他にも仕組みを掴み切れていないところが多々あるので、全体像をしっかり把握しておきたいと思います。これは将来的な課題です。
昨年のうちにマシン起動後にxdmでログインできるように設定したのですが、何故かログインできたり、できなかったりする症状に悩まされていました。xdmはマシンを利用するときの入り口になるものです。これから個々のアプリケーションの動作検証を進めていく前に、xdmで差し障りなくログインできるようにしておこうと思います。
xdmでログインできないというのは具体的にどのような状況になるのか説明しておきます。xdmのダイアログウィンドウにユーザー名とパスワードを入力すると、MATEが起動しそうに見えるのですが、一瞬間をおいて、再びxdmに戻ってログインを求める画面になってしまうのです。なにかエラーが出ているのでしょう。ホームディレクトリの.xsession-errorsを確認すると「XDM authorization key matches an existing client」というエラーが記録されていました。
このメッセージが何を訴えているのか分からないので、Webで検索してみました。すると2014年にFreeBSDのメーリングリストに流れたメールが見つかりました。xdm-configに次の設定を追加すれば解決するそうです。
DisplayManager*authName: MIT-MAGIC-COOKIE-1xdm-configはNetBSD/i386では/etc/X11/xdm/xdm-configです。設定を追加して様子をみると、問題は解決しているようです。ログインに失敗することは無くなった気がします。
問題が解決したのは結構なことですが、どうしてこれで問題が解決したのか理解できていないのは気持ちの悪い状態です。X関係は他にも仕組みを掴み切れていないところが多々あるので、全体像をしっかり把握しておきたいと思います。これは将来的な課題です。
登録:
投稿 (Atom)