Debian lenny (以降) で Wnn7 を使う

Debian, コメントを残す
ハードディスクが飛んでしまい、これを機会に Debian の新しいバージョンをすっかりはじめからインストールした。随分楽になったものだ。さてここでシステムの locale を最近の流行りにしたがって ja_JP.UTF-8 にしたのだが、これが後で問題となった。 sid (unstable) に入れ替えつつ、さらに必要なものを少しづつインストールして、クラッシュ直前の使い勝手に近づいてきたのだが、常用していた debian 外の日本語入力システム Wnn7 はライブラリの依存の問題でインストールすることができなかった[1] 。商用ソフトでしかも2001年発表というものなので、しかたないかもしれない。Wnn8 ならインストールできるかもしれないが、これですら2005年発表なので今さら買う気にもなれない。 1ヵ月ほど Anthy を使ってみたものの、20年近くも Wnn を使い続けてきた感覚のためか、どうにもストレスを感じて仕方がない。特に Wnn7 の「異体字変換」機能に相当するものを Anthy に見つけることができなかったところで、とうとう我慢ができなくなった。 というわけで、Wnn7 を2009年1月現在の debian sid にインストールしてみることにした。アップデートセンター から(当時の debian に対応した) deb パッケージが手にはいる。

dpkey7

そのままではインストールはできるが libc6 のバージョンが合わず起動しない。ここでは強引な方法で解決した。上記のアップデートセンターの「ライセンスサーバー」の項を見ると「glibc2.3 対応版」が出ていることがわかる(ただし rpm のみ)。この中から実行ファイルのみ(2つ)を取り出して、これに差し換えた deb を作り直してインストールすることにした。 ネットで検索すると、chroot 環境に古い libc6 (libc6_2.3.2.ds1-22_i386.deb) を飼うという解決法が見つかる。さらに将来を考えるとこのほうがいいのかもしれない。

wnn7-utils、辞書

wnn7-utils, maindic, optiondic は特に問題なくインストールできる。

wnn7-server

# dpkg-deb -x wnn7-server_1.01-1_i386.deb wnn7-server
# dpkg-deb -e wnn7-server_1.01-1_i386.deb wnn7-server/DEBIAN
で開梱し、DEBIAN/control の Depends の行にある古いライブラリを現在のものに書き換える。 libglib1.2 は libglib1.2ldbl に、またxlib6g はなくなってしまったので、個々のライブラリにする。したがって depand の行は 
 Depends: libc6 (>= 2.1.2), libglib1.2 (>= 1.2.0)|libglib1.2ldbl, libgtk1.2 (>= 1.2.7-1), libXi6, libxext6, libx11-6, libxau6, libxcb-xlib0, libxcb1, libxdmcp6
とした。libgtk1.2 は辛うじて現在の debian にも残っているのでよかった。 開梱したものを 
# dpkg-deb -b  wnn7-server wnn7-server_1.01-1p1_i386.deb
のようにして再びパッケージ化して、インストールした。

wnn7-elisp

Depends に Emacs のバージョンが固定的に書かれているので、新しいEmacs でも大丈夫なように、先ほどと同様に、emacsen と書き加える。 また、usr/lib/emacsen-common/packages/*/wnn7-elisp の中の case 文にもバージョンが固定的に書かれているので、ここに新しいバージョンを加える。 ここまでで、dpkeystat で ライセンスサーバが起動していることを確認でき、wnnstat で変換サーバが起動していることを確認できる。そして Emacs をクライアントとして正しく日本語入力と変換ができることを確認できる。

wnn7-xclients

最後に、xwnmo の含まれるこのパッケージも、同様に Depends の行を書き換える。 
 Depends: debhelper, debconf, libc6 (>= 2.2.4-4), libglib1.2 (>= 1.2.0)|libglib1.2ldbl, libgtk1.2 (>= 1.2.10-4), libXi6, libxext6, libx11-6, libxau6, libxcb-xlib0, libxcb1, libxdmcp6, libXmu6, libXt6, libsm6, libice6
とした。

設定

はじめに書いたようにシステムの locale を UTF-8 にしたのだが、これが原因で xwnmo が機能しなかった。ユーザーの .bash_profile で、LANG=ja_JP.eucJP と設定することにした。他のアプリケーションでそのうち困ることが出てくるかもしれないが。 そのほかの環境変数は、Wnn7 をインストールするより前に Anthy を入れた関係で im-switch もインストールしていたので、この際その流儀に合わせることにした。/etc/X11/xinit/xinput.d/ の default-xim を xim-wnn7 という名前でコピーして 
XIM=_XWNMO
XIM_PROGRAM="/usr/bin/xwnmo"
XIM_ARGS="-map -g 1x1-0-0"

GTK_IM_MODULE=xim
QT_IM_MODULE=xim
とした(XIM_ARGSはご自由に)。あとは im-switch -s xim-wnn7 で切り替えておく。
  1. ハードディスクが壊れる直前はその時点でほぼ最新の sid だったのだが、ずっと以前にインストールした Wnn7 に依存される形で古いライブラリが残っていて、 Wnn7 は正常に動いていた。↑

WordPress 2.7beta3-ja

WordPressコメントを残す
相当長いこと間があいてしまった。 いきなり、出たばかりの(しかもbetaの)WordPress 2.7beta3-jaに入れ替えてみた。今回はまったくお手伝いできなかった。 特に問題はなさそう。しかし管理画面のデザインは以前のバージョンから変わりすぎ。複数の著者で使っている某所をこれに入れ替えたら、ついてこれない人が出そうだ。

PostgreSQL を 8.3 に

Debian, ソフトウェア, , コメントを残す

バックエンドに PostgreSQL を使っているのは、自前のデータベースのほかに Trac と MediaWiki だ。バージョン 8.3 が出てから1ヵ月以上経つし、MediaWiki の 1.12.0rc1 で PostgreSQL 8.3 対応の文字が見えてきたのでそろそろ大丈夫だろうとバージョンアップしてみた。

debian の場合 pg_upgradecluster で簡単にデータの移行ができる……はずだったのだが一筋縄ではいかなかったのだった。きっと数ヵ月後には根本的に解決されていて役に立たない情報になるだろうが、記録しておく。

自前のデータベース

PostgreSQL の contrib に含まれている isn.sql[1]を利用している。この isn.sql も 8.2 と 8.3 で若干違っているようで、pg_dump したものを読み込ませてもうまくいかなかった。

しかたがないので、pg_dump したものを isn.sql 関連の定義前の部分、isn.sql による部分、その後の部分の3つに分け、前の部分を読み込ませた後、contrib の isn.sql を読み込ませ、それから後の部分を読み込ませることで、ようやくデータの移行ができた。

自前で書いていたフロントエンドは特に問題なしと思ったら、

互換性のない変更点
文字でない型 (日付型など) を自動的に text 型に変換しないようにしました。
今までは text 型入力を受けとる演算子や関数に文字でない値が渡されると、自動的に text 型にキャストしていました。 これからは text 型でないデータを渡したい場合には text 型への明示的なキャストが必要になります。
に引っかかるところが数ヵ所見つかった。演算子 ~ はテキスト型にしか使えないとのこと。暗黙のルールは使わないようにしているつもりでもうっかり使っているのものだなと思った。

Trac

データの移行はすんなりとできた。が、使ってみるとエラーが出る。上と同様、キャストに関わる問題のようだ。検索して、6416と6512の変更を加えて、うまく動くようになった。

MediaWiki

MediaWiki で使っている tsearch2 は PostgreSQL 8.2 では contrib だったのが 8.3 では本体に組み込まれた。と言っても関数名等の互換性を取るために 8.3 でも contrib の tsearch2.sql を読み込ませる必要がある。上述したのと同じように dump を分割してデータを移行した。

これで大丈夫と思ったら、記事を書き換えようとした際にエラーが出た。ts2_page_text() で tsvectorの引数の ‘default’ は存在しないというもの(すみません、メッセージを正確に記録していませんでした)。

maintenance/postgres/tables.sql の 当該関数の定義箇所を見てみると 

-- Tsearch2 2 stuff. Will fail if we don't have proper access to the tsearch2 tables
-- Note: if version 8.3 or higher, we remove the 'default' arg
とのコメントがある。1.12.0rc1 ではまだ対応されていないのだった。新しい版を見るとコメントがつけ加えられていて、patch-tsearch2funcs.sqlの存在を教えてくれた。これを適用して、問題なく動くようになった。

  1. 書籍コードの ISBN をひとつの変数型として扱うためのもの。↑

kernel 2.6.24

Debianコメントを残す
随分長いこと間があいてしまった。この間いろいろなことがあったのだが、今日はとにかくどこかにメモしておくべきことをメモしておく。 カーネルをバージョンアップ。Debian なのでそれ自体はいたって簡単。いつのまにか -k7 パッケージはなくなっていて、-686 に統合されたらしい。 メモしておくべきなのは、独自にいれているモジュールなど。nvidia は module-assistant のおかげでいまや特筆すべきことはない。shfs は前もひどく苦労したのだが今回もうまくいかず、と思ったらパッケージそのものが Debian から消えつつある。というわけで sshfs に乗り換えることにした。こちらはあっさり入れることができた。 そして VMWare (VMware-server-1.0.4-56528)でも一苦労。検索して Running VMWare Workstation on Ubuntu Hardy Herronという情報にたどり着き、ようやく動いた。カーネル 2.6.22 では any-any パッチすら不要だったので、じきにすんなりはいるようになるとは思うが。

gdm でのシャットダウンの禁止

Debian, ソフトウェア, , コメントを残す

特に設定しないと gdm のグリーティング画面で、「アクション」から誰でもシャットダウンや再起動ができてしまう。これではコンソールの前を通りかかった人は誰でも実行できてしまうので困ったものだと思うのだが、GNOME の考え方なのだろう、以前からこれがデフォルトだ。

また、いったんログインすれば、メインメニュー「シャットダウン」の項目があり、一般ユーザーがシャットダウンできてしまう。意図的でなくてもメニューで「ログアウト」と隣合っているので、うっかり間違えてシャットダウンしてしまうことがある。別のユーザーがリモートからそのマシンを使っていると困ったことになる。

シャットダウンを禁止するには、GNOME 2.18 では、gdm の設定ファイル /etc/gdm/gdm.conf[1] の [deamon] セクションに 

[daemon]
HaltCommand=
RebootCommand=
と書き加えればよかった。シャットダウンと再起動用のコマンドに空を指定することで、自動的にグリーティング画面の「アクション」メニューから「シャットダウン」「再起動」の項目が消え、ログインした一般ユーザーのメインメニューからも「シャットダウン」が消えていた。

ところが、gdm 2.20 になると、グリーティング画面の「アクション」からは消えるが一般ユーザーのメインメニューには「シャットダウン」が出るようになってしまった[2]。

gdm の設定の [daemon] セクションを見ると、 AllowLogoutActions という項目が 2.20 から増えていた。これに空の値を指定する、つまり先ほどの2行に加えて 

AllowLogoutActions=
と書くことで、一般ユーザーのメインメニューから「シャットダウン」を消すことができた。

【2011年6月29日追記】 GNOME でのシャットダウンの禁止—最近の流儀 を書きました。

  1. gdm のマニュアルを見ると /etc/gdm/custom.conf という名前のようだが、Debian では古い名前 /etc/gdm/gdm.conf が使われ続けているようだ。↑
  2. ロックダウン・エディタ pessulus を使うことも考えたが、これで「ログアウトを無効にする」と「シャットダウン」も「ログアウト」も一緒にできなくなってしまう。これらを別々に設定することはできない。↑

ブラザーのレーザー複合機

ソフトウェア, コメントを残す
レーザープリンタのドラムが汚れて縦に黒線が入るようになってどうしようかなと思っていたところに Fax付電話機が故障したので、ここは複合機を買うことにした。 Postscript(互換)、Linux用のドライバが用意されているということでブラザーのレーザー複合機を購入した。

ほしい機能

Fax機能で、受信時は複合機のメモリに保持しておき(これは当然できる)、必要なときに PCからファイルとして見えると助かる[1]のだが、結局、紙に印刷するしかない。スキャナ機能ではデータをFTPでPCに送ることもできるのだから、Fax機能でも受信データを同じように送ることができてもよさそうなものだが、その機能はないらしい。

brpcfax

オンラインでマニュアルを読めばだいたいの設定はできたのだが、「PC-FAX 送信 CUPS Wrapper ドライバのインストール方法」はちょっと不親切だ。インストールまではできるが使い方がわかりにくい[2]。 そこで検索してみると英語版のInstalling a Brother Linux PC-FAX send driver into a CUPS based Linux Systemが見つかり、こちらの方がはるかにわかりやすい[3]。もっとも使用頻度の高いと思われる OpenOffice.org から直接印刷するようにFaxを送る方法が載っている。ここにかいつまんで訳すと[4]
  1. OpenOfficeの設定ユーティリティである spadmin を起動する。(注: このプログラムを探すには find / | grep spadmin )
  2. 「新しいプリンタ」ボタンをクリック
  3. 「Fax 機の設定」を選択して、「次へ」ボタンをクリック
  4. 「標準ドライバ」を選択して、「次へ」ボタンをクリック
  5. 次のコマンド行を入力[5]
    brpcfax -o fax-number=(PHONE)
    そして「次へ」ボタンをクリック
  6. Faxプリンタの名前を入力。例えば Brother fax
  7. 「完了」ボタンをクリック
OOo で作成した文書を送るには、「印刷」で上記で名づけたFaxプリンタ名を選択して「OK」すると、Fax番号を入れる小さなウィンドウが開くのでそれを入力して「OK」する。 英語版マニュアルにはこの下に Mozilla の場合の設定方法があるが、firefoxでは「PostScript/default」以外のプリンタでは印刷コマンド指定ができないようだ。
  1. Windows なら附属のソフトでできるらしい。↑
  2. さらに誤りもある。「ファクス送信を実行する」の章の最初のコマンド例「単一宛先にファクス送信する場合：」は dpkg -i brmfcfaxcups-1.0.0-1.i386.deb と書かれているが、いくらなんでもそんな訳はない。英語版を見れば brpcfax -o fax-number=0566-55-12345 psfile.ps である。↑
  3. 検索中に見つけたブログの記事も参考になる。↑
  4. 実はStarSuite 8 管理ガイドにほぼ同じ記述がある。↑
  5. StarSuite 8 管理ガイドやブログの記事によると (TMP)をつけたほうがよさそうだ。↑

WordPress 2.3

WordPressコメントを残す
WordPress 2.3 が出たので、入れ換え。プラグインの挙動についてはしばらく様子を見たい。このサイトで使っているものはいまのところ特に問題はなさそうだ。

日本語リソース

日本語リソース案内の記述は着々とよくなっている。 ここで私なりの補足。「日本語リソース」とは、WordPress の主要なメッセージの日本語訳をひとつのファイルにまとめたもの。詳しい説明はLocalization Technologyにある。 オリジナル版をダウンロードし、上記の「日本語リソース」を入れれば、主要な部分は日本語になり、これでも使える。 ところが、この方法ではカバーできないメッセージがどうしても残る。そこでそれらのメッセージはプログラム本体の中を直接書き換えなければならない。それは既に「オリジナル版ダウンロード」では得られないので、この書きかえられたものに上記の「日本語リソース」を合わせてパックしたものが「 日本語リソース入り WordPress」となる。この「日本語リソース入り WordPress」パックには、オリジナル版で日本語を扱う際の不都合を補うプラグインも同梱されている。 そこでユーザはどれを選べばいいか、ということになる。
「日本語リソース入りWordPress」
主要なメッセージのほかインストーラやエラー時の表示も日本語化。補助的プラグインも付いてくる。初めて WordPress をインストールするときや、完全日本語版でいう方はこの方法。
オリジナル版に「日本語リソース」のみ
主要なメッセージは日本語化される。インストーラやエラー時の表示は英語のまま。もう WordPress に慣れていて、バージョンアップだからインストーラは不要とか、プラグインは既に入手済または別途入手するから、「日本語リソース入りWordPress」が出るまで待てないという方はこの方法。
オリジナル版のみ
それでも構わない。あちこちのメッセージが英語のままというだけで、日本語を使うこと自体はできる。事情がわかっている方向き。
公開の順番は、オリジナル版のバージョンがまず発表され、それを受けて「日本語リソース」が出され、最後にそれらを受けて「日本語リソース入りWordPress」が発表されることになる。 今回の私の場合は、バージョンアップ、プラグイン導入済、エラーメッセージくらい英語でもかまわない、という状況のため、二番めの「オリジナル版に「日本語リソース」のみ」の方法をとった。