xfce4-terminal を xfce4 以外で美しく使う。

7月 102014
 

X11 で利用するためのターミナルソフトというのは /usr/ports/ の下を探すと色々あるんですけども、僕なんかは KDE4 を利用していて『konsole あるじゃん。』となるんですが、どーも konsole は使いにくい。その中で色々と試して自分に良い感じのモノを利用したいモノです。

過去にもこのブログでは gtkterm2 のエントリを書いたりもしましたが、今回はそれに続く第二弾。と、いう感じでしょうかねぇ。

今回取り上げるのは xfce4-terminal です。 ports 的には x11/xfce4-terminal/ になります。もともとはウィンドマネージャである xfce4 (ports 的には x11-wm/xfce4)のターミナルソフトとしての役割があるのですが KDE4 を利用している場合においても x11/xfce4-terminal を make install することはできます。

xfce4 本体は利用せずともターミナルだけをインストールすると以下と、それに関連するプログラムがインストールされます。

libxfce4menu-4.10.0
libxfce4util-4.10.1
xfce4-conf-4.10.0
xfce4-terminal-0.6.3

まぁ、これくらいなら許せるかねぇ。って気がしないでもないので僕は使い続けているんですけどもね;-)。

で、xfce4-terminal のインストールが無事に完了し KDE4 で起動するとこんな感じになります。あ。上部のメニューの部分だけのキャプチャです。

xfce4-terminal_1

xfce4 をウィンドマネージャとして利用していると、ツールバーは 文字・アイコン・両方が選択できるのですが、 KDE4 上で利用するとその選択ができずに”両方”しか選択の余地が無いんですね。ちなみに xfce4 でウィンド装飾を設定するには xfce4-appearance-settings というプログラムを利用します。 ports 的には sysutils/xfce4-settings に含まれているのでいつを追加でインストールし xfce4-appearance-settings を起動してツールバーを”アイコンのみ”にしても KDE4 上で起動した場合には”両方”でしか表示できないんですね。

で、しばらくはツールバー無しで利用していたのですが、せっかくある機能、使わずしてどうする？などと、ザラ議長のような発想になってしまい、あちこち調べて格闘してみた。と、いうネタが今回のエントリーです;-)。

 
ウィンドマネージャである xfce4 の各種設定情報は $HOME/.config/xfce4/ に色々保存されます。ウィンド装飾の設定は $HOME/.config/xfce4/xfconf/xfce-perchannel-xml/xsettings.xml というファイルに保存されますが xfce4-terminal を単体で起動した場合にはこの設定ファイルを読み込まずにそのまま起動してしまうようです。 xfce4 のセッションを管理している何かしらの管理デーモンが画面全体を制御しているのでしょうなぁ。

では、 xfce4-terminal のソースを書きなおして default が BOTH なのを ICON に変えれば良いじゃないか。とか思い、ソースコードを見たのですが、うーむ。この辺りは GTK2 が管理しているようで GTK2 について詳しくない僕にとっては中々手強いのでありましたf(^^;;。

と、いうことで色々調べた結果、 KDE4 利用時に xfce4-terminal を起動しても無事にアイコンのみを表示できるようになりました。

xfce4-terminal_2

xfce4-terminal と xfce4-appearance-settings を同時に起動しました。

 
xfce4 は設定情報を全て管理していて、 xfce4 のアプリが起動したときに保存してある設定情報をアプリに渡すためのデーモンが存在しているようです。 KDE4 から xfce4-terminal を起動した場合、そのデーモンが起動していないために設定情報を xfce4-terminal に渡すことができなくて xfce4-terminal は default の設定で起動するんですね。

なるほど。では xfce4 の設定情報を渡すためデーモンを KDE4 利用時に起動して上げれば良いんだ。と、いうことになります。ちなみにそのデーモンは xfsettingsd というプログラムで sysutils/xfce4-settings に含まれています。

KDE4 でログイン後に xfsettingsd を起動してあげると xfce4 の各種設定が利用できるようになります。

まぁ、余計だとか CPU の無駄遣いとかイロイロあるとは思うのですが、最近はマシンパワーも余っていることですし、見てくれやツールバーの機能も重要なので今回はこれでヨシとしましょう。

あ。ツールバーが表示されたんだけど、「新規タブ」と「新規窓」のアイコンが表示されません。追加で x11-themes/icons-tango などをインストールしてあげてください。

これであなた好みのツールバーアイコンが利用できるようになるとか思われます。

ちなみに僕は非力なマシンとか仮想環境で X が必要なマシンでは KDE4 ではなく xfce4 を利用しています。機能的にも十分だし軽量なので重宝しております;-)。

 
さてさて。これだけではなんなんで、一個パッチを公開します。

xfce4-terminal ってのはショートカットとかキーバインドなどはソースにハードコーディングしているので変更できないんですね。
一番困ったのがタブの移動で default では Ctrl+Page_Up とか Ctrl+Page_Down なので不便でしょーがない。僕はタブの移動は Shift+Left もしくは Shift+Right にしているので、その部分を変更するパッチになります。

http://icmpv6.org/Prog/FreeBSD_ports/patch-terminal-terminal-window.c

自分のキーバインドにしたい場合には terminal/terminal-window.c の 210 行辺りを変更すれば良いと思います。
上記パッチは files/ の中にほーりこんで make すれば大丈夫なようにしています。

 
と、いうことで今回は xfce4-terminal について書いてみました。皆さんも機会があったら試してみてくださいー;-)。

IPv6 Path MTU Discovery にどっぷりとハマる。

6月 242014
 

今回は IPv4 のお話ではなく IPv6 のお話です。でもって Path MTU Discovery のお話です。

僕は IPv6 は Hurricane Electric の IPv6 Tunnel Broker を利用しています。以前からここの IPv6 トンネルを利用させてもらっているのですが、とあるタイミングで IPv6 の http や ftp が通らなくなりました。あらま。 ping や ssh は通るので、仕事柄の経験上「あぁ。 Path MTU Discovery にハマったな。」というのはすぐに解りました。

『ハマった』というのは『送受信の二点間において MTU の最小値を決定することができなかった。』と、いうことかな。
どうして『決定できなかった』のかと言えば『Path MTU を探査できなかったから。』と、いうことになると思います。
Path MTU が Discovery できないとパケットのフラグメントが発生しないので MTU サイズ以降のパケットは捨てられてしまうために通信が行えなくなります。

 
しかし、Hurricane Electric の IPv6 トンネルは今まで利用できていたのにどうしてある日突然 Path MTU Discovery ができなくなってパケットサイズの大きい通信が止まるのだぁ？ などと不思議に思うのであります。

まず、どうして Path MTU Discovery に失敗するのか？

1). 自分が設定したファイアーウォールで ICMPv6 の Type2 (Packet Too Big)を止めてしまった
2). ISP がある日突然 ICMPv6 の Type2 に ACL をかけた
3). Hurricane Electric で仕様が変わった

が考えられると思います。 1). については自分が設定したファイアーウォールを flush して確認できると思います。
2). の場合、僕は ISP を二つ契約している(自宅でマルチホームっ!!;-)ので両方の ISP で Hurricane Electric のサービスにトンネルを掘って確認してみましたが、どちらも http が止まります。
すると、残りは 3). が原因か、もしかして 2). の二つの ISP の両方が ICMPv6 Type2 に ACL を設定しているか。ですね。

まぁ、どっちにしても通信はできません。orz

 
次に、本当に IPv6 Path MTU Discovery ができていないのかの確認方法です。

1). IPv4 は ping・ssh・http の通信ができることを確認
2). IPv6 で ping・ssh・http の通信ができることを確認
3). ping6 -s 1434 au.kddi.com もしくは ping -s 1280 au.kddi.com

1). の確認において IPv4 で上記プロトコルが全て利用できるようであれば、問題は IPv6 のみに特定できます。
2). では Path MTU Discovery にハマると http の通信のみできなくなります。まぁ、ftp ででかいデータを持ってくるときとか、パケットサイズが 1,500 バイトに近くなる通信では止まってしまいます。
3). は、じゃぁ実際に何バイトのバケットサイズであれば通るのだ？という確認のために ping でパケットサイズを指定します。 1,434 もしくは 1,280 バイトで ping してみて、通る、通らないでサイズを変更して色々確認してみるのが良いかと思われます。

さてさて。これらで確認することにより IPv6 Path MTU Discovery な地雷を踏んだか確認できますが、次にその対応について考えてみたいと思います。

 
まずはネットワーク構成図などを。

Tunnel_NetWork_01

真ん中の黄色いのがトンネルルータで Hurricane Electric に対して gif0 でトンネルを掘っております。 em0 のインターフェースは一個目の IPv6 セグメントです。
また、トンネルルータでは dtcps を起動していて gif10 と gif10 で更に二つのセグメントとトンネルを掘っております。

このネットワークでの IPv6 Path MTU Discovery の状態は・・。

1). 同一セグメント内では通信ができる
2). セグメント 1,2,3 の間ではで通信ができる
3). セグメント 1,2,3 から gif0 を抜けて Hurricane Electric の先にある IPv6 サイトと通信ができない

と、いうことが解りました。 どうやら MTU もしくは MSS の調整は re0 か gif0 で行う必要がありそうです。

 
が、その前に、クライアント PC 側で何か対応する手立ては無いか調べてみました。

1). クライアント PC の MTU を 1434 にする
2). IPv6 より IPv4 を先に利用するようにする

1). の場合は UNIX 系 OS だと比較的容易にできます。以下は FreeBSD で MTU を変更する場合のコマンドです。

# ifconfig re0 mtu 1434

 
IPv6 Path MTU Discovery でハマった時には MTU を1434 にしてあげると通信が復活します。セグメント内にいる全ての UNIX 系 OS で上記コマンドを叩く必要があります。

2). のほうは WindowsOS で有効な手段です。 DOS のプロンプトをアドミン権限で起動し、以下のコマンドを打ちます。

c:\ netsh interface ipv6 show prefixpolicies
c:\
c:\ netsh interface ipv6 set prefixpolicy ::ffff:0:0/96 50 0
c:\ netsh interface ipv6 set prefixpolicy ::1/128 40 1
c:\ netsh interface ipv6 set prefixpolicy ::/0 30 2
c:\ netsh interface ipv6 set prefixpolicy 2002::/16 20 3
c:\ netsh interface ipv6 set prefixpolicy ::/96 10 4

 

一行目のコマンドはステータスの確認です。これを見ると IPv6 のほうが先に利用されるように設定されているので IPv4 を先に利用するようにその後のコマンドでプライオリティを変更してあけます。

もとに戻すときにはこちらのコマンドで。

c:\ netsh interface ipv6 set prefixpolicy ::1/128 50 0
c:\ netsh interface ipv6 set prefixpolicy ::/0 40 1
c:\ netsh interface ipv6 set prefixpolicy ::ffff:0:0/96 35 4
c:\ netsh interface ipv6 set prefixpolicy 2002::/16 30 2
c:\ netsh interface ipv6 set prefixpolicy ::/96 1 3

 

これで WindowsOS もなんとか IPv6 Path MTU Discovery を回避できたのではないかと思われます。ちょっと弱い問題解決ですが・・。

しかし、IPv6 に対応しているスマートフォン(iOS や Windows Phone OS など)は IPv6 サイトが見られないんですよねぇ・・。

さてさて。こんなことばっかりしていても根本的な問題解決にならないので次に根本的な解決をしてみたいと思います。

 
IPv6 Path MTU Discovery ができないときの原因としては ICMPv6 の Type2 (Packet Too Big) パケットのやりとりができず、通信するための最小 MTU サイズが特定できないために発生します。それならばパケットを送信する側でパケットの最小サイズを明示的に指定して送信すれば良い(それはつまりは TCP SYN パケットの MSS オプション値を書き換えてあげる。と、いうことです)わけなんですけども FreeBSD にその機能があるのか？

今回利用しているトンネルルータは FreeBSD 9.1-RELEASE です。こいつには pf(4) があるのでそれを利用することにします。と、いうか、現状では pf(4) でしか制御できないようです。
他にもports に net/tcpmssd があるようなのですが、今回は pf(4) を利用することにします。

ちなみにトンネルルータのファイアーウォールは ipfw で設定しているのですが MSS のサイズは pf で設定することにします。
今回は ipfw の設定は省きます。以下は /etc/pf.conf の設定です。

scrub in  on re0  from any to any max-mss 1280
scrub out on re0  from any to any max-mss 1280
scrub in  on gif0 from any to any max-mss 1280
scrub out on gif0 from any to any max-mss 1280
pass all

 
FreeBSD の MSS サイズを固定に設定するためには max-mss を利用します。サイズは 1280 にします。上記構成図では re0 から抜けるパケットのみが 1,280 バイトになります。通常 IPv4 パケットは別の BB ルータから抜けていく(構成図には書かれていない)のでまぁ、問題は無いでしょ。

re0 と gif0 の両方の MSS サイズを小さくしている設定をしていますが、試した結果 gif0 のみの MSS を1280 に設定するだけで十分でした。

設定が完了したら以下のコマンドを打ちます。

# kldload pf
# kldload pflog
# kldstat
        :
33    2 0xffffffff8104b000 2a4a5    pf.ko
34    1 0xffffffff81076000 9c9      pflog.ko
#
# /etc/rc.d/pf onestart
# pfctl -sr
        :
# pfctl -sa
        :
#

 
カーネルモジュールをロードし、無事にロードできたか確認します。次に /etc/rc.d/pf を onestart で実行します。無事に実行できたかは pfctl の二行で確認(オプション -sr と -sa)しましょう。出力結果は省略します;-)。
無事に動作することができたら /etc/rc.conf などに pf_enable=”YES” などと書きましょう。

 
最後に確認方法ですが、簡単です;-)。セグメント 1,2,3 の各クライアント PC から IPv6 サイトが無事に見えるかどうか。だけです;-)。

au.kddi.com とか running-dog.net とか icmpv6.org などが無事に見えると pf で設定した max-mss 1280 が有効になっている。と、いうことですね。

 
とまぁ、ある日突然 IPv6 Path MTU Discovery が通信できない問題が降ってきたわけですけども、その対応策などをツラツラと書いてみました。皆さん、是非とも IPv6 Path MTU Discovery にハマらないようにしたいと思うわけですけども、もしハマったら pf で回避してみてください。

ふぅ。それにしても復活だぁ・・。

QtWeb というブラウザの ports 作ってみました。

6月 192014
 

GNOME 方面の人にはまるで興味が無いとは思うのですが、 KDE というか Qt を利用している人にとっては、ご存知な方もいるのではないかなぁ？

世の中には超軽量ブラウザというのが存在しています。 rekonq も konqueror に比べると軽量かなぁ。arora も軽量ですね。 rekonq よりも軽量なのが QtWeb というブラウザです。 arora と同じくらい軽量かなぁ。

以下が QtWeb のサイトですね。

http://qtweb.net/

ここを見ると Windows・OS X・Linux と世界の三大ウィンドを制覇しているんですけどもね;-)。で、それぞれバイナリがあるのですが、ソースコードもあるので、それを FreeBSD に持ってきてコンパイルすると FreeBSD 上でも動作するんですけども。

キャプチャはこんな感じです。

Qtweb_1

で、せっかくなので今回は QtWeb の ports を作ってみました。 arora が ports になっているのに QtWeb が ports になってないのは悲しいことですし;-)。
以下の URL にあるのでもしも「僕も私もちょっと FreeBSD 上で QtWeb を使ってみようかなぁ。」などと思った人は試してみてください。

http://icmpv6.org/Prog/FreeBSD_ports/ports-qtweb-20140619.tgz

あ。コミットするつもりはありません。あくまでノラ ports ということで;-)。

QtWeb の ports の仕様やインストール方法などをちょっと書いてみます。

o. QtWeb をコンパイルするには Qt 4.8.6 のソースコードが必要
FreeBSD の ports 的には qt4-* で色々インストールされているのですが、 QtWeb は Qt ライブラリを static link するので FreeBSD の ports 的な Qt ライブラリは必要としません。
GNOME や xfce4 な人も Qt や KDE のコンポーネントをインストールすることなく Qt コテコテなブラウザを楽しむことがてできます。

しかし、裏を返すと Qt ライブラリ部分もコンパイルするのでコンパイル時間が随分と長いです。orz

僕が作成した ports では /usr/ports/distfiles/KDE/ に Qt 4.8.6 のソースがあればそれを利用し、なければとある日本のサイトからダウンロードしてきます。詳細は files/patch-qt-src.sh を見てください。

o. ports がインストールするもの
QtWeb のサイトからバイナリをダウンロードすると、本当に QtWeb 本体のみしかパッケージングされてないのですが、僕の作った ports では QtWeb バイナリの他に icon として QtWeb.png と QtWeb.desktop をインストールするようにしています。インストール直後から KDE のインターネットメニューに表示されるようにしました。

o. QtWeb の起動
ports からインストールすると /usr/local/bin/QtWeb ができるのでそれを実行するのですが、実行後にできるディレクトリが美しくないです。以下の三つのディレクトリができます。

・$HOME/.QtWeb Internet Browser/
・QtWebCache/
・QtWebSettings/

一番上の .QtWeb Internet Browser/ は $HOME にできるので良いのですが、 QtWebCache/ と QtWebSettings/ はどこにできるかわかりません。実行したときにいるカレントディレクトリにできたりとか、ヘタするとあちこちに QtWebCache/ と QtWebSettings/ ができてしまうような感じです。orz
なお、メニューから QtWeb の設定を変更するとその内容は QtWebSettings/ に保存されます。

が、しかし、それにしてもこの二つのファイルはどこにできるのか解らない・・。orz
ソースコードを書き換えてやろうかと思ったほどですが・・。
なのでしょうがない。起動用にスクリプトを一個書きました。

#!/bin/sh

cd $HOME/.QtWeb\ Internet\ Browser
QtWeb > /dev/null 2>&1
#/usr/local/bin/QtWeb > /dev/null 2>&1
#cd  $HOME

 
$HOME/.QtWeb Internet Browser/ 配下に QtWebCache/ と QtWebSettings/ が作成されるようにするためのスクリプトです。
不便やのぉ・・。って感じなのですが、ソースコード的には browserapplication.cpp の数カ所を直せばちゃんとコントロールできるんじゃね？ って感じはします。

 
こんな感じの QtWeb というブラウザなのですが、もしよければ皆さんもコンパイルして使ってみてください;-)。

 
あ。最後にですが、 Qt-Webkit は x-sjis と x-euc-jp には対応してないので文字化けします。 rekonq も konqueror も Qt-WebKit を利用しているのでやはり x-* な文字コードは表示できません。最近は少なくなってきましたが、今では僕が知っている有名ドコロは VECTOR が x-sjis を利用しているので表示できません。

この件については以前 KDE 方面で(その昔は) Nokia の Qt のコードを書いている人に聞いたことがあるのですが、非対応だそうです。するっていと同じ KHTML から派生の Apple-WebKit は独自に x-* な文字コードに対応した。と、いうことなのでしょうなぁ。

 
PC に色々ブラウザが入っていると楽しいですよ;-)。 是非、試してみてください。;-)

mozc.el を最新版に対応させます。

4月 042014
 

最近は IME に関するエントリが多いですが、もう一回書いてしまおう。でもって、最近の連続する一連のネタは多分これが最後でしょうかねぇ;-)。

いきなり手前味噌で大変申し訳ありませんが、そもそも mozc.el な(ノラ) ports は僕が一番最初に作成して NakataMaho さん がコミットしてくださり、その後 mozc-server のメンテナの方が取り込んでくださった。と、いう経緯があります(japanese/mozc-el/Makefile の一番上見てね;-)。

mozc 自体には当初から emacs 対応の mozc.el がバンドルされていたけど mozc-server の作者が「僕、emacs 使ってないしぃ。」と、いうとこで mozc.el が ports にならなかったし、インストールされなかったんですけども。

で、現在は mozc の最新版は mozc-1.13.1651.102 ですが、 FreeBSD の ports 的には 1.11.1502.102 のままです。まぁ、 mozc を FreeBSD に対応させるためには随分たくさんの改修を行いパッチを作成しなければ make が通らないという、その苦労はよぉーく知っているので現行バージョンである 1.11.1502.102 でも一応、問題はありません。

が、しかし、 mozc-1.11.1502.102 な mozc.el には以下のようなバグがあって困っていたんですね。

 
X11 の emacs 上 (emacs -nw ではない状態) で mozc.el 経由で日本語を入力しているときに mozc のサジェストがウィンドから飛び出ると入力した文字が消えてしまう。
確定前の文字が消えるだけなら良いのですが、それ以前に入力した文字まで消えてしまう。

 
結構悲惨な状態で、それがいやでしばらくの間は ibus.el (ports 的には textproc/ibus-el です)経由で mozc を利用していました。

ところが、ibus-1.5.5 になって ibus.el が ibus-daemon と通信できなくなったので、いよいよ mozc.el を利用しなければならなくなった。

mozc.el を利用しいるとき emacs のウィンドの上のほうで文字入力をしている分には問題ないのですが、下のほうに来るとサジェストがウィンドの下を突き破るようになるので入力した文字が消えてしまうんですけどね。

 
何か回避策はないものかいのぉ。とかと思い、mozc の最新版のソースコードを持ってきて mozc.el を /usr/local/share/emacs/24.3/site-lisp/mozc/ にほーりこんでみましたよ。そしたらあーたっ!!

いやー。最新版の mozc に付属の mozc.el もしっかり更新されていて日本語入力中のサジェストは、ウィンドの下辺りで入力している場合にはカーソルのある入力行の上に表示されるようになり文字が消えてしまうというバグが改修されているんですね。これを利用しない手はないっ!!

 
ってんで、やっとここからが本題です。

mozc-server 自体は現行バージョンで良いし mozc.el インストール時に mozc_emacs_helper (バイナリ)が一緒にインストールされるのですが、これも現行バージョンのモノで良い。ただ単に mozc.el のみ最新になってくれると随分と幸せになれます。

と、いうことでパッチを作成しました。以下の URL に置いておきます。

http://icmpv6.org/Prog/FreeBSD_ports/patch-unix_emacs_mozc.el-20140402

このパッチを以下の要領で japanese/mozc-server/files/ の中に入れてください。

# cd /usr/ports/japanese/mozc-server/
# cp ~/patch-unix_emacs_mozc.el-20140402 files/patch-unix_emacs_mozc.el
# cd ../mozc-el/
# make && make deinstall && make reinstall
#

 

既存の mozc.el のパッチのみを置き換えるとこによって 1.13.1651.102 の mozc.el が利用できるようになります。ダウンロードしたパッチは 1.11.1502.102 と 1.13.1651.102 の mozc.el を diff しただけです。

非常にお気楽に、そして簡単に emacs の mozc 入力が最新になります;-)。

FreeBSD の ports の現行バージョンの mozc.el で困っている方いましたら是非ともトライしてみてください。

コミッタの方、どなたかこのパッチを吸収してくれないかなぁ。まぁ、パッチは差分だけなので簡単に作成できると思うのですけどね;-)。

fcitx-mozc な ports を復活させてみました。

4月 022014
 

以前のエントリで FreeBSD で利用する ibus-1.5.5。 というのを書きました。
要は ibus が 1.4.2 から 1.5.5 になったら随分と使い勝手が悪くなったねぇ。と、いうことで、どうしたらちゃんと利用できるようになるか？ ってネタなんですけどもね。

そのエントリには僕自身がコメントしたのですが、この際 fcitx-mozc でも試してみるかねぇ。って書いていて、早速試してみました。が、実際には以下の通りの動作で、実質的にしゅーりょー。な状態だったのであります。

 
fcitx をインストールして japanese/fcitx-mozc のコンパイルを通しても正常に動作しないのですが、考えられる原因としては mozc-1.11.1502.102 に対応する japansese/fcitx-mozc のパッチは多分 fcitx-4.2.8 用で、 FreeBSD の ports は fcitx-4.2.6 となっており chinese/fcitx 本体と japanese/fcitx-mozc のバージョンに差異が発生しているため、上手に通信が行なえように思われます。

 
試してみるとまさしくその通りで、そのエントリのコメントを読んでくださった Hiroto Kagotani さん が chinese/fcitx を最新のハージョンである fcitx-4.2.8.3 にしてくださいました。

それならば fcitx-mozc は動くべー。とか思い、試してみました。

結論から書くと fcitx-mozc は fcitx を最新版にすることにより、サクっと動作しました;-)。以下その顛末を書いてみたいと思います。

 
1. fcitx-4.2.8.3 のインストール
ports の chinese/fcitx は古いバージョンなので Hiroto Kagotani さん が作成してくださった最新版の ports を以下から拾ってきます。

https://github.com/HirotoKagotani/freebsd-fcitx/tree/master/chinese/fcitx

git clone で取ってくるのが良いでしょうかねぇ。 git についてはここには書きませんが、僕は mew のソースツリーを持ってきているので git はそこそこ使っています;-)。それとほぼ同じやり方で一式を持ってきました。

あとは ports の chinese/fcitx を置き換えて make install しておしまいです。

ちなみに Hiroto Kagotani さん は、作成した ports はメンテナの方に連絡するそうなのでもうしばらくすると fcitx-4.2.8.3 が ports-current に降ってくるのではないでしょうか。

 
2. japanese/fcitx-mozc/Makefile の改修
これは簡単。 IGNORE= の行をコメントアウトします。

 
3. japanese/mozc-server を更新
japanese/fcitx-mozc を make すると japanese/mozc-server の Makefile の中が走るのでその部分を一部改修します。
既に改修した ports を以下の URL に置いたのでご利用ください;-)。

http://icmpv6.org/Prog/FreeBSD_ports/ports-mozc-server_add_fcitx-4.2.8.3_fcitx-mozc-20140402.tgz

既存の ports からの変更点は fcitx_mozc で BUILD するときに持ってくるパッチ先とパッチを変更しています。
ダウンロードするパッチは fcitx-4.2.8.3 に対応するパッチです。パッチ本体は以下の URL からダウンロード可能です。

http://icmpv6.org/Prog/FreeBSD_ports/fcitx-mozc-1.11.1502.102.1_fcitx-4.2.8.3.patch

fcitx-mozc は mozc のバージョンが 1.11.1502.102 でも fcitx のほうは最新版である 4.2.8.3 を利用する必要があります。 mozc-1.11.1502.102 に対応する 4.2.6 用のパッチがない (mozc-1.11.1502.102 に対応する 4.2.8.3 のパッチはある) ので japanese/fcitx-mozc は IGNORE= 状態になるんですね。

なので今回の場合は japanese/fcitx-mozc が悪いワケではなく、中々バージョンが上がらなかった chinese/fcitx のおかげで IGNORE= になった。と、考えるべきでしょう。

さてさて。ダウンロードした ports で japanese/fcitx-mozc を make するとサクっとインストールしてくれると思います;-)。

あとは、表示される pkg-message の内容に設定して、一旦ログアウトしてからログインし直します;-)。

 
4. KDE4 利用時の GUI について
インストールが無事に完了して、ログインしたら動作確認です。僕の場合は KDE4 を利用しているのですが、fcitx を起動するとパネルに何やら表示されます。 mozc をオンにするにはデフォルトでは 全角/半角 キーを押します。すると日本語入力が可能になります。
GNOME は利用してないのでわかりません。ごめんなさい。

右クリックでメニューが表示されますが [設定] をクリックするとエディタが立ち上がります。あたたた。
KDE4 で GUI な設定ウィンドを表示するには kcm-fcitx というのが必要なようです。 FreeBSD の ports にはなってないようなので、僕が ports を作り、以下の URL に置きました。必要な方はダウンロードしてください。

http://icmpv6.org/Prog/FreeBSD_ports/ports-kcm-fcitx-20140402.tgz

どこに展開して良いかわかりませんが、 textproc/ 辺りに展開して make && make install してください。 LIB_DEPENDS= などかぁなりいい加減であやすぃーです。本当は KDE とか Qt 辺りも書かなければダメなのだろうと思うのですが、僕の環境では既にインストールされているので・・f(^^;;。

正しく書きなおして、コミットしてくれる方、絶賛募集中です;-)。

で、インストールした kcm-fcitx は起動するとこんな感じで GUI で fcitx を設定できるようになります。

kcm-fcitx

色々設定変更してみてください。

あ。ちなみにエディタで設定ファイルを編集する場合には $HOME/.config/fcitx/config というファイルになります。

 
5. 利用してみた感想
では、実際に fcitx-mozc を利用してみた感想ですが、まず一番驚くのがカーソルに日本語を随時表示してくれない。と、いう点でしょうか。以前ちょっとだけ Windows 上で利用したことがある「Baidu IME」みたいな雰囲気で、日本語入力専用窓が出てそこでベコベコ打って、確定したらカーソルに反映される。と、いう感じです。
これが好きか嫌いかについては意見の別れるところではありますね。

あと、mozc のサジェストの「意味の機能」(だっけか？)が利用できないです。”語” 対する説明文が表示されません。

スクリーンセーバにパスワードロックがかかっている場合に日本語入力状態になってしまいます。

状態パネルを表示すると怪しいところに出たりとか;-)。

文字入力時の UI 部分に違和感が多少あるのみで、文字の入力自体は特に問題なく一応は行える。と、いう感じでしょうかね。

 
と、いうことで(僕が初めて利用する)新しい日本語入力である fcitx と、そこからエンジンとして利用する fcitx-mozc について、今回は書いてみました。

ports の chinese/fcitx が最新版にアップデートされると、多分追随して japanese/fcitx-mozc と japanese/mozc-server も対応していくと思われます。そー考えるとこの記事の内容というのは先が短い記事である。と、いうことですねぇ・・f(^^;;。

まぁ、それはちょっと置いといたとして、人よりもちょっと早く新しいかな漢字入力の動作確認ができるぜい。って感じですね;-)。

このエントリを読んで今すぐに試してみたい。と、いう人はいるんかなぁ？ f(^^;;。

KDE4 で VirtualBox を動かしたしたときに ISO がマウントできない件。

4月 012014
 

いやね。もう随分と前から KDE4 で VirtualBox を起動して、仮想マシンを作成するときに、インストール用の ISO イメージがマウントできない。と、いう状態が続いているんですね。以下のようなダイアログが表示されるんです。

klauncher_dbus_err

原因としては VirtualBox を起動した(もしくは VirtualBox から起動された(原因は特定していない状態f(^^;;)) KLauncher が D-Bus と接続できないぜぃ。って話らしいんですね。

色々調べたのですが ubuntu 方面では dbus のバージョンを 1.4.8 辺りに落とせば良い。ってのがあったのですが、今の FreeBSD では dbus-1.6.18 になっているのでそれはちょっと考えられなしいし、その話題が出ていたのは dbus が 1.5 系のころで、さすがに 1.6 系になっても dbus がおかしい。なんてのはちょっと考えられない。

と、いうことでその案はしゅーりょー。まぁ、実際にバージョンを落として試してみたことはあるのですがダメだったですね。

 
そもそも上記のエラーが出るのは仮想マシンに ISO イメージをマウントするときだけです。ただ、 ISO イメージがマウントできないと OS のインスールができないわけでして・・。
OS のインストールが完了した仮想マシンがある場合には一般ユーザ権限でも VirtualBox はガシガシ動作してくれるのであります。

と、いうことで今回は “Could not start process Cannot talk to klauncher: Not connected to D-Bus server.” と、いうメッセージが出た時の回避策を書いてみたいと思います。そのためにはまず前提条件からですね。

 
1. 前提条件
o. KDE4 を利用していて VirtualBox を起動しようとする
o. 今回のバージョンは kde-4.12.3 と virtualbox-ose- 4.3.10 にしましょう
o. 普段は一般権限のユーザで VirtualBox を起動する

この状態で VirtualBox から ISO イメージをマウントすると一番上のエラーが出るんですね。あたたた。

 
2. root で起動
一般ユーザ権限で上記のエラーが出るので root 権限で起動するとどうなるのー？と、いうことで root で起動する準備を整えます。

まず、一般ユーザ権限のディレクトリを root のホームディレクトリに symlink します。

$ sudo -s
# cd /root/
# ln -s /home/takachan/.VirtualBox
#

 

次に root で ssh ログインできるように /etc/ssh/sshd_config を変更します。

#PermitRootLogin no
PermitRootLogin yes

 

パスフレーズでログインする場合にはこの設定は必要ありません。また、セキュリティがことごとく低下するので自己責任でお願いします。
あとは /etc/rc.d/sshd restart して準備は完了です。

続いて、ローカルホストの root に対して一般ユーザから ssh して VirtualBox を起動します。

$ ssh -CY -2 root@localhost
Password for fqdn:
# setenv LC_TIME C
# setenv LANG ja_JP.UTF-8
# setenv LC_CTYPE ja_JP.UTF-8
# VirtualBox
        :

 
VirtualBox を起動したときに言語が英語になっている場合には LANG で自分で利用している文字コードを setenv してあげます。
VirtualBox を起動したら仮想マシンの設定を開いてすかさず ISO イメージをマウントします。あぁら不思議。と、いうかさすがは root 権限ですね。特に問題もなくスルっと ISO イメージがマウントできました。

ISO イメージがマウントできたら root 権限での VirtualBox はサクっと終了して ssh も抜けてしまって大丈夫。 /etc/ssh/sshd_config の設定をもとに戻して完了。ってところでしょうか。

 
3. 一般ユーザの環境をもとに戻す
/root/ に symlink した $HOME/.VirtualBox/ は root が情報を書き込んでいるので一般ユーザでただちに VirtualBox を起動すると無事に動作してくれません。環境を整える必要があります。

$ sudo -s
# cd /home/takachan
# chown -R takachan:user .VirtualBox/
# chown -R takachan:user /data/VMs/
#

 

$HOME/.VirtualBox/ の他にも仮想マシンのディスクイメージが入っているディレクトリのオーナ・グループも変更する必要があります。僕の場合は /data/VMs/ に仮想マシンのディスクがありますのでそのオーナ・グループも変更します。

これで準備は完了。あとは一般ユーザで VirtualBox を起動して ISO イメージからブートして OS をインストールすれば良いでしょう。

 
それにしてもどーして root でしか dbus にアクセスできないのでしょうか？ dbus-daemon は通常 messagebus ユーザ messagebus グループで動作しているようです。と、いうことは /etc/group の messagebus に一般ユーザ名もしくは VirtualBox のユーザである vboxusers を書いたら良いんじゃね？ とか思えるのですが、それを試してもダメだったのでありました。あたた。

と、いうことで現状、僕の知る限りでは ISO のマウントのみ root 権限で実行するしか手はないのかなぁ・・。などと思った次第であります。

ちゃんとした解決法をご存知の方いましたら教えて頂ければと思います。

FreeBSD で利用する ibus-1.5.5。

3月 182014
 

ports current を追いかけている人なら解ると思いますが、ibus という日本語入力なアプリケーションが 1.4.2 から 1.5.5 になりました。このバージョンアップにより日本語の入力がかぁなり複雑になったようですね。

ibus 1.4.2 と 1.5.5 の簡単な違いについて書いてみると、

o. 日本語入力状態は絶えずオン状態
o. キーボードを変更することにより全角と半角を切り分ける

と、なったようです。ある意味「日本語入力用キーボード」と「英字専用キーボード」の二つを使い分ける。と、いう状態になったようですね。おかげで ibus-setup の設定画面からは IME のオン/オフ のメニューが消えております。

さてさて。僕は今回 ibus-1.5.5 のインストールからつまずいたのでそこから書いて行きたいと思います。色々試行錯誤を繰り返し、今は日本語入力ができるようになっております。ふぅ。

あ、ちなみに僕の環境は FreeBSD/amd64 9.2-RELEASE-p3 で X での日本語入力の環境は ibus+ibus-mozc で KDE4 を利用しております。当然、オンプレミスな環境です;-)。

emacs では mozc+mozc.el を利用していますが、この場合の mozc は ibus 経由ではありません。しかし、それとは別に ibus+ibus.el+mozc というパターンもあり、その場合には ibus-el-0.3.2 が ibus-1.5 系に対応していないので動作しません。と、いうことで ibus-1.5 系にした人はサクっと ibus-el-0.3.2 を pkg delete しても問題はまるでありません。

と、いうことで、まずは ibus-1.5.5 のインストールから見ていくことにしましょう。

 
1). ibus-1.5.5 のインストール
FreeBSD だと ports では textproc/ibus/ になるので make && make install と打てばインストールが完了すると思いますが make config のオプションで悩みます。 ibus-1.5.5 をインストールすると GTK2 と GTK3 の両方が必要になる(インストールされる)のは非常に納得行かないですね。しかし、悔しいですが、以下のキャプチャの通り DOC と GCONF もしくは DCONF 以外は全てチェックを付けたほうが良いと思われます。

ibus_20140318_1

GINTRO (銀トロ？ なに？ それ？) をオフにすると IBus.py がインストールされずに ibus-setup が起動しない状態になる(動かないなら最初から ibus-setup インストールするのやめろよーX-(し GTK3 要らんもんねー。などと思っていると、やはり ibus-setup が起動しなかったりと、そこはかとなくとんでもない ibus がインストールされるので、ちゃんとフルオプションを付けてあげましょう。

と、いうことで ibus のインストールは完了しました。

ibus がインストールされたのですが、一応、ibus-mozc も再度コンパイルしてあげましょう。念のために ibus-1.5.5 インストール後に japanese/ibus-mozc/ で make && make deinstall && make reinstall して、一応は準備完了。と、いうことで。

 
2). ibus の起動と設定
ibus の起動は ibus をインストールしたときに pkg-message が表示されるのでその内容で設定しましょう。
まぁ、素早く試したい場合には ibus-daemon_restart とか ibus-daemon_start コマンドを実行します。無事に起動したら ibus-setup コマンドを叩いて GUI で設定します。

「キーボードショートカット」の [次のインプットメソッド] メニューでインプットメソッドの切り替えを設定します。一番上に書いたように簡単に「キーボード切り替えのためのショートカットキー。」と、いう認識でいるのが良いかと思われます。

ibus_20140318_2

ちなみに default では “Super+Space” になっていると思いますが “Super” キーというのは Win キー であったり Mac の command キー に相当するらしいです。なので、 default では「Win+Space キーでキーボード切り替え。」ってことですね。

 
さてさて。他のタブを見て行きましょう。
[インプットメソッド] のタブでは「インプットメソッドの選択」で「日本語」のキーボードアイコンと mozc を選択します。二つの項目が登録されている状態ですね。

ibus_20140318_5

[詳細] タブでは「キーボードレイアウト」で [システムキーボードレイアウトを利用する] にチェックしておいたほうが良いかもしれないです。僕の場合は ibus-setup を起動した途端に 101 キーボード列になってしまいました。普段は 106 キーボード列を利用しているのに・・。

と、いうことで ibus の設定は完了。あとは日本語をベコベコ打てば良いですね。

 
3). mozc 側で設定
が・・。上記の「キーボードショートカット」で設定したもの(僕の場合は “Shift+Space” にしました)をベコベコ押しても一向に日本語が打てる気配はありません。画面中央に切り替え画面が表示されるのですが、日本語が打てません。あいや・・。orz

しょーがねぇなぁ。となるのですが、今度は mozc の設定を行います。 mozc_tool_config コマンドを叩いて mozc の設定画面を表示させます。 [一般] タブの下のほうに「キー設定」というのがありますが、そこにある [編集] ボタンを押します。表示されたウィンドの真ん中の列が「入力キー」で、そこが “shift space” というところに、コマンドを「IME の有効化」を選択し保存します。

あとは mozc_server_restart と ibus-daemon_restart を実行して、そのあとにキーボードが変わってくれるかを確認します。

 
だいたいこんな感じで ibus+mozc の場合には日本語が打てるようになるでしょうかねぇ。mozc ではない、他の IME を利用している方、申し訳ありませんが設定方法は解らないので自力で頑張ってください;-)。

しばらく使ってみた感想ですが、

o. 新しいウインドを開いた時に日本語キーボードが選択されている
o. スクリーンセーバのパスワード入力も日本語になる
o. 文字を打ち始めると最初の文字が化ける(日本語にならない場合がある)
o. 画面に ibus の設定とかがチロッと出る場合がある(これは何？)

などでしょうかねぇ。けっこう痛いですかね・・。

 
けどもまぁ、なんとか ibus-1.5.5 に移行できたのでヨシとしておきましょう。もう少し使い込んで色々な設定を出していきたいとは思っていますが。

もしくは fcitx に移行していくかもー。

KDE4 のユーザエージェントをバージョンアップ。

2月 242014
 

本題に入る前、一点。
FreeBSD の ports の KDE4 が kde-4.12.2 になりましたなぁ。今までは /usr/local/kde4/ にインストールされていたのですが、このバージョンからは /usr/local/ にインストールされるようになりました。僕の環境では 130 個弱の ports の再インストールが発生しまた。けど、これでようやっと、独自ディレクトリから開放されるぞぉー。って感じです。

と、いうことで本題。

KDE4 をインストールすると default のブラウザに konqueror がインストールされます。それとは別に他のブラウザをインストール、例えば rekonq をインストールするとします。

konqueror も rekonq もユーザエージェントを偽装できる機能を持っています。例えば FreeBSD のこれらのブラウザでアクセスすると「あんたのブラウザでは全部の機能が動作しない。」とか「最新のブラウザではないので利用できない。」などと蹴られる場合があり、以降の表示を止めてしまうウェブサイトがあったりします。

まぁ、仮に表示されたとしても確かに正しく動作しない場合なんかもあったりするんですけどねf(^^;;。

https://profile.microsoft.com なんかは UserAgent を IE11 に偽装したとしても正しく表示できなかったりしますが、それは konqueror や rekonq などのブラウザが対応していないので正常動作しない。と、いうことですね。

 
さてさて。それにしもブラウザでユーザエージェントが選べるのに表示される情報がどれもこれも古いバージョンで困ってしまいます。

konqueror_ua_1

これを最新のバージョンに変更できないのかなぁ？ とか思いソースコードを眺めるのですが、ふむ。ブラウザは KDE コンポーネントを見ているようで、ブラウザのソースコードには無いようです。

KDE 的には konqueror も rekonq はコテコテの KDE・Qt アプリなので、共通な機能については共通コンポーネントを使うようになっており、一個のパーツを色々なアプリで利用するってが仕様のようです。例えば Proxy とか キャッシュなども KDE4 の複数のアプリで共有するコンポーネントです。

ブラウザの UserAgent 偽装機能も一緒で konqueror も rekonq もユーザエージェントの設定はコンポーネントが一緒です。
では、その場合ソースコードがどこにあるのか？ ですが、見つけました。 FreeBSD の ports 的には以下になります。

x11/kde4-baseapps/work/kde-baseapps-4.10.5/konqueror/settings/kio/uasproviders/

ここに *.desktop というファイルがたくさんあり、ブラウザのバージョンごとの情報を持っているフアイルが複数あります。
これらはインストールすると以下のディレクトリにインストールされることが解りました。

/usr/local/share/kde4/services/useragentstrings/

ここに最新のブラウザに対応した .desktop ファイルを置いてあげると次回起動時にはそのファイルを読み込んで最新のバージョンのユーザエージェントが利用できるようになります。

せっかくですので firefox-24.0 と MSIE-11.0 の .desktop ファイルを作成したので、利用してみたいと思う方は以下の URL から持って行ってください。

http://icmpv6.org/Prog/KDE/firefox240oncurrent.desktop
http://icmpv6.org/Prog/KDE/ie110onwinnt61.desktop

これで konqueror や rekonq では最新の他のブラウザとして動作することができるようになりました。パチパチパチ。ただ、ユーザエージェントの情報が変わっただけで、上にも書いている通り、正しく表示・機能しないウェブサイトがたくさんあることに違いが無いのでご注意ください;-)。

 
さてさて。ここからは付録に近いのですが、 Qt 系ブラウザとして arora というブラウザがあります。 ports 的には www/arora になるんですけども。こいつのユーザエージェントが更新されてないのでソースコードも眺めてみました。すると arora の場合は独自にソースコード中に書いているようですね。以下の xml なファイルで定義しているようです。

arora-0.11.0/src/useragent/useragents.xml

もし、 arora を利用している人でユーザエージェントを最新のブラウザに偽装したい場合には上記のファイルを編集してコンパイルし直せば良いと思われます。

arora は Qt を利用しているけど、 KDE にベッタリ。ってことは無い独自路線のウェブブラウザ。ってことなんですねぇ。

今回はちろっと KDE4 の構成的な説明と、ブラウザのユーザエージェント偽装のためのネタでした。

l10n の po ファイルの更新。

2月 062014
 

僕はデスクトップに KDE4 を利用しているのですが、 JKUG の日本語化チームとは別に自分で利用する KDE アプリで、日本語化されていないものをコツコツと個別に翻訳しています。

例えば rekonq という konqueror を再定義し直した KDE・Qt ライクなブラウザがあるのですが、こいつはソースに日本語 po ファイルが付いてこないのでメニューなどが英語で表示されます。

まぁ、 konqueror を再定義しただけのことはあって konqueror よりは rekonq のほうが使いやすいかなぁ。とは思う点が多々あるので僕は利用しているんですけども、いかんせん日本語化されてないので、しょーがねぇなぁ。自分で po ファイル書くかぁ。などと思いコツコツと日本語化しているのであります。

僕が今まで日本語化した po ファイルは以下の URL に置いてあるので良かったら持って行ってください。

http://icmpv6.org/Prog/ja.po/

rekonq-2.4.2 に対応した po ファイルの最新版は rekonq-2.4.2-20140205_1.po になります。

 
さてさて。翻訳していて一番大変なのはバージョンアップした時ですね。
新規に po ファイルの翻訳をするのであれば、とある言語の po フアイルを引っ張ってきて Language: とか を ja に変更して、翻訳を開始していけば良いのですが、バージョンアップが発生したときはどうするの？とかになるわけです。

以下、作業手順。あ。僕が個別にどの翻訳グループにも属していないのでこのような手順を踏んているだけで、もしかしたらちゃんとしたもっと効率の良いやり方というのがあるのかもしれませんが・・。その場合は、教えて頂ければ幸いです。

1). 新しいバージョンの po ファイルを取得
2). 以前に翻訳した po ファイルをエディタで開く
3). 新しいバージョンの po ファイルをエディタで開く
4). 新しいバージョンの po ファイルの msgid に以前翻訳した msgstr をペースト
5). 新規に出てきた未翻訳の msgid を翻訳
6). やっと完成。ふぅ・・

なんていう、クラクラするような作業をしなければならずほんとにイヤになる・・。もっと効率的なやり方は無いんかな？

 
と、いうことで考えた技は以下の通り。 UNIX コマンド使いまくりだぁ;-)。 効率よく po ファイルをバージョンアップする技を考えてみました。

・新しい po ファイル: rekonq-2.4.2.po
・古い po ファイル: rekonq-2.3.2.po

ソースコードに日本語の po ファイルが無い場合には他の言語の po ファイルを日本語として使いまわします。 rekonq の場合は po/sv/rekonq.po を利用して rekonq-2.4.2.po としました。

1). msgid の抜き出し

$ cat rekonq-2.3.2.po | grep ^msgid > rekonq-2.3.2.po_msgid
$ cat rekonq-2.4.2.po | grep ^msgid > rekonq-2.4.2.po_msgid
$ diff -ur rekonq-2.3.2.po_msgid rekonq-2.4.2.po_msgid > msgid.diff

 
これで新規に追加になったメッセージと削除されたメッセージの差分が出てきます。
diff ファイルで “+” の部分は新しく登録された msgid で “-” の部分は削除された msgid です。

 
2). diff 結果の取り込み

$ cp rekonq-2.3.2.po rekonq-2.4.2_New.po
$ mule rekonq-2.4.2_New.po

 
rekonq-2.3.2.po は以前に翻訳したファイルなのでそれを最新版にします。そのために msgid.diff の差分を新しく用意した rekonq-2.4.2_New.po に反映して行きます。
“+” で表示されている msgid とその関連する部分は追加し “-” の部分の関連する情報は削除していきます。ガシガシしていきます;-)。 po ファイルには「ソースコードの何行目」なんていうコメント行がありますが、とりあえずそんなのは無視していきます;-)。

以上はエディタで編集する必要がありますが、これで新旧の情報がマージされた po ファイルが完成です。ちっこいバージョンアップだと差分が少ないので po ファイルの更新も楽ちんです;-)。

 
3). 翻訳者支援アプリ
テキストエディタで直接 po ファイルを更新しても良いとは思うのですが、何か支援 AI ではなく、支援ソフトは無いんかなぁ？ とか思って調べてみると ports に editors/poedit というのがありますね。 GTK アプリで GUI で利用できそうです。こいつをインストールして起動してみます。

起動したら rekonq-2.4.2_New.po ファイルを読み込みます。すると翻訳可能な状態になります。キャプチャはありませんが、左側が msgid で、右側が msgstr です。 msgstr が空白な部分が翻訳されていない文字列になるのでそれをベコベコ打ち込んでいけば良いかと思われます。
日本語文字入力時に emacs キーバインドが利用できないのが痛いんだけど、GTK2 の emacs キーバインドの設定すれば良いんかなぁ？今度試してみよう。

 
GUI 的なモノで msgid を google 翻訳で翻訳してその結果を msgstr に表示するヤツとかあるんかなぁ？ google の textproc/translate-toolkit なんかはその類なのかな？ python のコマンドラインツールなんてのは使いたく無いんだけど;-P。

 
poedit は Windows 版 Mac 版もあるようです。編集した po ファイルを保存すると msgfmt も実行してくれるのでいきなり mo ファイルが生成されます。あとはそれを share/locale/ja/LC_MESSAGES/ 辺りにほーりこんで rekonq を再起動すると確認ができます。

 
翻訳用の po ファイルに対する新旧二つの情報のマージって、もっと他に何か画期的な方法・手段ってあるのかなぁ？ google で探したけど見当たらなくて、結局 diff してその差分を古いバージョンの po フアイルにマージって方法にしたんだけど・・。

もしかして、本家にマージされた po ファイルは既に差分が吸収された状態でリリースされるとか？そんな便利な世の中ならドンドン本家にマージしたほうが良いなぁ。

それにしても翻訳の方法はこれで良いのかな？

FreeBSD 9.2-RELEASE になったら wifimgr が正しく動作しなくなった

2月 012014
 

このブログのとあるエントリにコメントを頂きました。 URL 的にはこれになるんですけども。

http://running-dog.net/2013/11/post_829.html#comment-36710

たまたま偶然なのかもしれませんが、以前私が日本語 po フアイルを書いた wifimgr が FreeBSD 9.2-RELEASE では動作しなくなったのだけど原因解りますか？ と、いうモノです。
ちなみに今回は全然関係ありませんが、日本語 po ファイルは wifimgr の作者送り、採用されています;-)。

 
まず最初に wifimgr のソースコード眺めてみましたが、こいつは小さいプログラムなので簡単でしたね。ただ GTK の部分は全くわかりませんが、今回は GTK の部分はとりあえず置いておくことができそうです。そんな感じでソースコードを眺めたのですが wifimgr は GUI のボタンを押すと system() で ifconfig とか /etc/rc.d/ の下のスクリプトを実行していることが解りました。

 
そして wifimgr のソースコードを眺めてみるとだいたいが /etc/rc.d/netif を起動して、その戻り値でエラーをはいて停止してしまうことが解りました。

次に 9.1-R と 9.2-R の /etc/rc.d/netif を diff してみましたが、大きな相違点としては、 9.2-R では /etc/rc.d/routing を呼ぶようになった部分が怪しいです。実際に 9.1-R の /etc/rc.d/netif を 9.2-R に持ってきて wifimgr を起動すると無事に動作しました。あいや。するっていと原因は本当に /etc/rc.d/routing だねぇ。と、更に特定できました。

 
あとは IRC で教えてもらった以下の設定を /etc/rc.conf に仕込んで /etc/rc.d/routing の動作確認です。

rc_debug="YES"

 
そして /etc/rc.d/routing のあちこちに logger コマンドを仕込んで変数の値を /var/log/messages に出力させます(他にも /etc/rc.subr や /etc/network.subr も見る必要がありますが)。

/etc/rc.d/routing は以下のコマンドオプションで実行されているようですね。

# /etc/rc.d/routing start any wlan0

 
さてさて。原因の特定ですが、以下の行にあることが解りました。

    43          ""|[Aa][Ll][Ll]|[Aa][Nn][Yy])
    44                  for _a in inet inet6 ipx atm; do
    45                          afexists $_a && setroutes $_cmd $_a $_if
    46                  done
    47                  ;;

 
44 行目で inet inet6 ipx atm を定義して 45 行目で static_hoge として呼び出しているのですが inet6 を実行すると戻り値がおかしくなるらしく、その戻り値が /etc/rc.d/routing の戻り値として wifimgr に戻ってエラーになって終了するようです。
実際に

・44 行目の inet6 を消すと無事に動作する。
・45 行目の下に logger コマンドを入れると無事に動作する。
・routing_start() の終了時に return 0 を追加すると無事に動作する。

となりました。
このことをとある方にご連絡したところ、以下のパッチを書いてくださいました。多分次のリリース及び STABLE や freebsd-update では更新されるのではないかと思われます。

以下、頂いたパッチを先行して公開します。 FreeBSD 9.2-RELEASE で wifimgr を使っているが正常に動作しなくて困っている方は適用してみてください。

Index: etc/rc.d/routing
===================================================================
--- etc/rc.d/routing    (revision 255154)
+++ etc/rc.d/routing    (working copy)
@@ -42,7 +42,8 @@
                ;;
        ""|[Aa][Ll][Ll]|[Aa][Nn][Yy])
                for _a in inet inet6 ipx atm; do
-                       afexists $_a && setroutes $_cmd $_a $_if
+                       afexists $_a || continue
+                       setroutes $_cmd $_a $_if
                done
                ;;
        *)

 
これで無事に動作するようになると思われます。 wifimgr のほうもソース修正しなくとも良い(バージョンを見て実行するコマンドオプションを変えるのもつらいべ)のではないかと思われるので一安心です;-)。

あとで wifimgr の作者にメールしようと思います;-)。

あ。最後にですけど、 static_inet6() の戻り値がぶっ壊れる(っぽい)原因は詳しくは調べていません。もしかしたら FreeBSD の rc スクリプトが原因ではなく、僕が設定した /etc/rc.conf の IPv6 の設定がおかしくてそれが原因で正しく処理されずに戻り値が壊れて、結果的に /etc/rc.d/routing の戻り値がエラーになるのかもしれません。その場合、原因は僕にありそうですねf(^^;;。

 以前のエントリー  新しいエントリー