Window Maker 0.50.2 (1999/01/11)
Window Maker は今年に入って、いきなり 0.50.x にバージョンアップしました。大きくバージョン番号が変わったのでいったい何事かと思いましたが、どうやら KDE, GNOME にフル対応したとのこと。私は、どちらも使ったことがないのでどういうメリットがあるのかわかりませんが、一応、デフォルトの Window Manager として追っかけることにしてるわけだし、その他バグFIXもされているだろうと思い、さっそく GET してパッケージを作ることにしました。
まず、日本語メッセージがどうなっているか ja.po をチェックしました。私がパッケージした 0.20.3 は TurboLinux 3.0 に入ってる ja.po を参考に作り直したものでした。デフォルトで入っているものだと日本語メッセージが不十分だったからです。ところが、0.50.2 の ja.po を見ますと、かなり日本語化が進んでいまして、特に作り直す必要もなさそうです。ということで、今回のパッケージはデフォルトで入ってるものをそのまま使用することにしました。
次に、ChangeLog や News をザッと見て何が変わったかをチェックした後、とりあえず make してみることにしました。しかし、ここからがちょっとハマりましたね。（笑） なんと「LIBTOOL@ がない」とエラーで止まってしまいます。エラーで止まった wrlib の Makefile を見ると、確かに LIBTOOL@ となってます。たぶん Makefile を作る時に LIBTOOL なるものを展開できなかったようです。こいつはいったい何なんだ？と、初心に戻って INSTALL ドキュメントをもう一度読みなおしました。すると、どうやら automake のバージョンが古いことが判明。さっそく RedHat 5.2 の automake-1.3-2.rpm を GET してインストールしました。再度 configure して、先ほど止まった wrlib を make してみますとＯＫ。よし、いけると踏んだ私は、最初から make しなおしてみました。ところが今度は別のところでエラー。（トホホ） INSTALL をもう一度じっくり読んでみましたら、「RedHat 5.x は libtool-1.2 を使え、1.2b じゃダメよ」という記述を発見。なんだかよくわかりませんが必要というなら仕方ありません。libtool-1.2 を GET してインストールしました。
こうして、ようやく make に成功しました。いやはや、とんだ苦労を強いられました。（笑） 今回は日本語環境の設定を行ってパッケージしましたので、新規インストールの場合は、各 rpm をインストール後に wmaker.inst すれば即使えます。「プライベートパッケージ」に置いておきますね。
glibc + libwcsmbs へ (1999/01/12)
日本語環境を構築する時に避けて通れないのが LOCALE の問題です。libc5 以前の環境では、まともな LOCALE が実装されてなかったため、X が LOCALE をエミュレーションしてくれてました。しかし glibc2 (libc6) では、LOCALE が実装されたため、X の LOCALE は使われなくなりました。というよりも、使えなくなったというのが正解でしょうね。RedHat 5.x 等の glibc2 ベースのものは、X がX_LOCALE なしでビルドされてます。（当然、X_LOCALE ありで X をリビルドすれば使えるようになります） LOCALE は glibc2 に任せてしまったわけです。本来の姿になったというべきなんでしょう。
ところが、日本の場合これが困ったことになったんです。X の LOCALE がなくても、glibc2 の LOCALE が使えれば問題ないのですけど、オリジナルの glibc2 は、悲しいかな日本語 LOCALE が扱えないんです。X の LOCALE エミュレーションを使えない、glibc2 の LOCALE も使えない状況で、解決できる選択肢は２つです。１つは X_LOCALE 付きで X を作り直す方法。２つ目は、glibc2 に日本語 LOCALE を実装する方法。こちらは正攻法ですね。 この方法をとっていくことが正しい道であろうということで、現在は glibc2 に日本語 LOCALE を実装する方法が主流です。今後リリースされる glibc で日本語 LOCALE が正しく実装されれば、wcsmbs がどうのこうのと言わなくとも大丈夫になるでしょう。
さて、 gclib2 の日本語 LOCALE 実装には、現在２つの方法があります。glibc2 自身にパッチをあてて、LOCALE の wcsmbs.so をロードする方法（glibc+wcsmbs）。もうひとつは、本体の glibc2 にはそのままで、libwcsmbs を追加して、LOCALE の wcsmbs.so をロードする方法（glibc と libwcsmbs）です。前者は、glibc 自身にパッチをあてるため、バージョンアップする度にパッチをあてて入れ替えないといけません。後者の方法だと、glibc2 自身には手をつけないので、glibc2 がバージョンアップしても glibc2 だけ入れ替えれば済みます。このように２つの方法があるわけですが、どちらの方法をとるにしても、日本語 LOCALE 定義が必要です。これが wcsmbs-locale と呼ばれているものです。
TurboLinux 3.0 の glibc は Debian の glibc+wcsmbs をベースにしたもののようです。glibc2 自身にパッチをあててて wcsmbs.so をロードしています。PJE-0.3alpha で配布されている glibc+wcsmbs と比べてみると、パッケージングやディレクトリ構成が若干違います。TurboLinux は、単に glibc としてパッケージされてますが、中身は glibc+wcsmbs と 日本語 LOCALE 定義の wcsmbs-locale の両方が含まれています。一方、PJE で配布されているものは、wcsmbs-locale が切り離されてパッケージされてます。また、wcsmbs.so がインストールされるディレクトリが違います。TurboLinux は、/usr/share/locale 配下の各 LOCALE の下に入りますが、PJE のほうは、/usr/lib/wcsmbs 配下の各 LOCALE の下になってます。
TurboLinux 3.0 の glibc は日本語 LOCALE を扱えるようにできてます。ですから、不都合を感じない限りは PJE の glibc+wcsmbs を入れたり wcsmbs-locale を入れたりする必要はありません。glibc を入れ替えるというのは結構勇気がいるものですからね。とは言うものの、私は glibc + libwcsmbs へ移行しました。理由は２つです。Netscape Communicator 4.07 の glibc 版を入れたら色んな不具合に遭遇したこと。それと、TurboLinux 3.0 の glibc + wcsmbs はパッチレベルがちょっと古いんじゃないかと思ったからです。
glibc + libwcsmbs を選択したのは、オリジナルの glibc2 に手を加えないですむことが魅力だからです。このほうが何かと楽でしょう。オリジナルの glibc2 のリリースが上がった時は入れ替えてやるだけですみます。私は PJE-0.3alpha から libwcsmbs のソースパッケージを GET して、それを TurboLinux 3.0 用に調整してパッケージを作成しました。PJE は元来、RedHat 5.x に日本語環境を構築することが目的です。RedHat は libc5 関連のライブラリを /usr/i486-linux-libc5/lib に入れるようになっているみたいですね。TurboLinux にはそんなディレクトリがありません。/usr/lib/libc5 か /usr/X11R6/lib/libc5 に入れるのが流儀と思われます。libwcsmbs.so.0 のインストール場所として妥当な線は /usr/lib/libc5 ということになりますが、ld.so.conf には、このディレクトリが記述されてません。また runlibc5 スクリプトには /usr/X11R6/lib/libc5 しか LD_LIBRARY_PATH されてません。どうしようかと悩みましたが紆余曲折の末、ld.so.conf に /usr/lib/libc5 を追加することにしました。
wcsmbs.so の位置が違う点については、TurboLinux が /usr/share/locale に入っていること自体に違和感がありましたから、素直に /usr/lib/wcsmbs に入れることにしました。となると、あとはオリジナルの glibc の最新版を RedHat 5.2 から GET し、PJE の wcsmbs-locale を GET すれば準備はＯＫです。私の glibc 環境は以下のパッケージの組み合わせです。
- glibc-2.0.7-28.i386.rpm (from RedHat 5.2)
- glibc-debug-2.0.7-29.i386.rpm (from RedHat 5.2)
- glibc-devel-2.0.7-29.i386.rpm (from RedHat 5.2)
- glibc-profile-2.0.7-29.i386.rpm (from RedHat 5.2)
- libwcsmbs-0.0.5-2TL.i386 (PJE-0.3alpha のものを TurboLinux 3.0 用に調整したパッケージ)
- wcsmbs-locale-0.4.6-1.i386.rpm (from PJE-0.3alpha)
で、libwcsmbs を「プライベートパッケージ」に置こうかと思いましたが、glibc でトラブルと大変なことになりますのでやめときます。（笑） PJE-0.3alpha の libwcsmbs をそのまま使っても動かないことはありません。その場合は、/etc/ld.so.conf に /usr/i486-linux-libc5/lib を追加して ldconfig すれば大丈夫だと思います。実は、この方法が一番簡単だったりして。。。
製品版 Wnn6 Ver.2.0 がダメ２ (1999/01/16)
Wnn6 の xwnmo が使えないので 1999/01/06 にオムロンソフトにメールを出しましたら、1999/01/14 付けで返事がきました。「現在調査中」とのことで、まだ解決にはいたってないようです。今のところ xwnmo 目当てに製品版を購入するのは控えたほうが良いでしょう。
Kernel 2.2 は1999/01/25 (1999/01/23)
特に問題が発生しなければ、2.2 が来週月曜にリリースされるそうです。去年のクリスマス前後と言われてましたが、ようやくリリースにこじつけたようですね。めでたい。めでたい。
Kernel 2.2 リリース (1999/01/26)
Kernel 2.2 がリリースされました。RingServer から GET できます。
Laser5 RedHat 5.2 + Informix (1999/01/28)
Laser5 が発売する、日本語 RedHat 5.2 には INFORMIX-SE for Linux がバンドルされるようですね。一方、Oracle が出す Oracle8 Workgroup Server for Linux は、この日本語 RedHat 5.2 と TurboLinux 3.0 をサポート対象とするとのことです。面白いのは、Oracle がサポート対象とするどちらのディストリビューションにも、別の DB がバンドルされていることです。TurboLinux のほうは Sybase ですね。どちらも試用版ですが、必要となった時点で費用を支払えばいいので気軽に使い始めることができます。それに比べると Oracle のほうは最初から購入しなければならないので気軽にというわけにはいきません。
私には Informix や Sybase のやり方のほうが受け入れられやすいと思います。SQL Server ばかり目の敵にしてると、思わぬところで足下をすくわれるかもしれないですよね。
Kernel 2.2.0 を導入 (1999/01/28)
どうも我慢ならずに（爆） Kernel 2.2.0 を導入してみました。今まで、カーネルのバージョンアップは全て手動でやっちまってましたが、今回はパッケージを作ってインストールしてみました。パッケージをどのように作成したのか？という興味を持たれると思いますが、これについては、またの機会に書きたいと思います。別にパッケージ化しなくても Kernel の導入はできますから、わざわざパッケージすることもないという話もありますしね。
さて、カーネル導入の一番の難関は、Configure です。2.2.0 で make xconfig するとこんな画面が出ます。私はこれ見ただけでうんざりしました。（笑） そこで、「できるだけモジュール化する」という方針のもとに Configure を行いました。自分の環境に関係ないものもモジュール化して置いておこうという試みです。ただ、QoS and/or fair queueing が何のことかわからなかったのと、Amateur Radio と ISDN subsystem は絶対に使わないので組み込みませんでした。私が使った .config はこれです。こいつをカーネルをビルドするディレクトリに .config として置いてやるなり、make xconfnig して読み込んでやれば使えると思います。
TurboLinux は egcs なんで、コンパイルが通るのか心配してましたが、特に問題なく終わりました。パッケージが作成できたところで、まずは、現在の 2.0.36 を念のため待避しておいて 2.2.0 をインストール。その後、/etc/lilo.conf を書き換えて、2.0.36 でも起動できるようにしておいてから再起動かけました。（おお、久しぶりのリブートだ）
2.2.0 のブートにはびっくりしました。画面右上にペンギンマークが！！思わず「オオッ！！」と叫んでしまいました。なかなか凝ったことをするもんですね。さっそくログインして lsmod で読み込まれているモジュールをチェックしました。SCSI とネットワークカードはＯＫでしたが、サウンドがダメ。conf.modules は前のままだったので当たり前かと思いつつ、/usr/src/linux-2.2.0/Documentation/sound から、SoundBlaster16 のドキュメントを探して、conf.modules のオプションを設定してやりました。どうやら、dma の指定が違うようです。前は dma=1,5 と指定していたのが dma=1 dma16=5 というふうに指定してやらないといけないみたいです。それと mpu_io の指定も必要なようでしたので mpu_io=0x330 としてやりました。modprobe sound してやって再度 lsmod してみるとモジュールは読み込まれたようです。試しに音を鳴らしてみるとＯＫでした。ということで、mkinitrd -f /boot/initrd 2.2.0 して lilo 後、再度リブートしてやってチェック。今度は全てＯＫとなりました。
新しいカーネルで、まず実感するのが動作の軽快さです。今のところ恩恵を感じたのはこれだけです。（爆笑） じゃあ手間かけて 2.2.0 にする意味はあまりないんじゃない？と言われても仕方ないんですが、「どうも我慢ならずに」は解決したわけです。
Kernel 2.2.0 でのプリンタ出力 (1999/01/29)
Kernel 2.2.0 を導入して、プリンタ出力ができないことに気づきました。「これはいったい？！」と、ドキュメントをあたってみると、やっぱりありました。（笑） parport.txt というのがそれです。パラレルポートの扱いが変わったんですね。このドキュメントにはいくつかやり方が示されてますが、私はプリンタさえ普通に使えればよいので、一番簡単で確実だと思われる方法をとりました。conf.modules で設定して、initrd 段階で parport_pc を I/O アドレスや IRQ を指定してロードしてやります。lp モジュールは、元々、/etc/rc.d/rc.modules で modprobe してますから、その前にパラレルポートを使えるようにしておこうという作戦です。設定を追加した conf.modules はこれです。conf.modules を追加修正したら、mkinitrd -f /boot/initrd 2.2.0; lilo してやります。後、必要となるのは /etc/printcap の修正です。以前は lp1 へ出力するようになっていましたが、これを lp0 に変更してやります。以上の作業で出力可能になりました。
Kernel 2.2.0 で重大なバグ (1999/01/31)
Kernel 2.2.0 にセキュリティ上の問題をはらんだ重大なバグが見つかったそうです。問題を修正した Kernel 2.2.1 がリリースされているようです。既に RingServer にはミラーされてます。
