4月 052017
 

FreeBSD の ports CURRENT を追いかけていると svn update したあとに portmaster -D -a するクセが付いているのでそれをやってバシバシ最新の ports/pkg を利用しているんだけど・・。

だいたい、時期を同じくして portmaster -D -a してのバージョンアップと Xming の利用が一緒になり、前のエントリの中で『Xming では mozc で日本語入力ができない。』などと書いていたのですが、なんとっ!! よくよく調べてみると GTK-3.0 を利用しているアプリの日本語入力ができなくなっていることがわかった。

KDE 系のアプリは Xming 経由や、素の Xorg 上では日本語入力ができるけど GTK-3.0 なアプリが日本語入力できなくなっていた。

最近は GTK-2.0 から 3.0 への過渡期で、僕の場合は GNOME3 は使ってないんだけど emacs や firefox は GTK-3.0 を明示的に指定して ports のコンパイルをしているし xfce4-terminal も default で GTK-3.0 を利用するようになっている。

と、いうことで今更ながら GTK-2.0 の IM 周りの設定を見直してもショウガない。 xfce4-terminal などは ldd で確認すると libgtk-3.so.0 を利用しているしね。
と、いうことで GTK-3.0 の日本語入力の設定の見直しです。

あ。 GTK-3.0 のアプリで日本語が入力できなくなったのは 03/31 に svn update して portmaster -D -a してからですね。その前まではちゃんと日本語が打てていました。

 
GTK-3.0 の設定はインストールすると、以下のディレクトリに散りばめられます。

・/usr/local/lib/gtk-3.0/3.0.0/
・/usr/local/etc/gtk-3.0/
・$HOME/.config/gtk-3.0/

この中に IM に関する設定ファイルが必要なります。

ちなみに GTK-2.0 の場合には日本語入力するためのファイルは以下になります。

・/usr/local/etc/gtk-2.0/gtk.immodules

このフアイルのおかげで、環境変数に以下を設定した場合に GTK アプリで日本語入力ができるようになります。

export QT_IM_MODULE=xim
export GTK_IM_MODULE=xim
export XMODIFIERS=@im=fcitx

exec mozc start
exec fcitx

 
僕の場合は QT_IM_MODULE を設定して KDE アプリで xim を利用し、 GTK_IM_MODULE も同様で、日本語入力には fcitx を mozc 経由で利用しています。

今回は GTK-3.0 のアプリについてですが、 GTK-2.0 の頃には /usr/local/etc/gtk-2.0/gtk.immodules があったのですが /usr/local/etc/gtk-3.0/ の下にはそんなファイルがありません。

なので作ってあげる必要があります。その場合、以下のコマンドを打ちます。

# cd /usr/local/etc/gtk-3.0/
# gtk-query-immodules-3.0 > gtk.immodules

 
さてと。準備完了。では xfce4-terminal を起動して Shift+SPACE を押してと。あれま。ダメだ・・。
と、いうことで上記の設定ファイルを用意してもダメなようです。

しょーがないので GTK-3.0 のドキュメントを読んでみることにしましょう。

https://developer.gnome.org/gtk3/unstable/gtk-running.html

上記の URL に書かれている説明では immodules の設定ファイルは immodules.cache という名になっているようです。では先程作成したファイルを mv して名前を変更して再度トライ。

しかし、ダメなようです。あれま・・。

上記のドキュメントを読むと直接ほーりむようなことが書いてあるので ports がフアイルをインストールしたディレクトリに直接用意してみることにします。

# cd /usr/local/lib/gtk-3.0/3.0.0/
# gtk-query-immodules-3.0 > immodules.cache

 
これで再度 xfce4-terminal を起動して Shift+SPACE を押してみます。おぉっ!! 今度は無事に fcitx の画面が表示されて日本語が打てるようになりました。メデタシメデタシ。

と、いうことは ports のバグっぽいので、今後バージョンアップされたときには直ることでしようなぁ。 ちなみに 03/31 の ports でインストールされた GTK-3.0 のバージョンは gtk3-3.18.8_4 です。
次にバージョンアップするとしたら gtk3-3.18.8_5 かな? 😉

 
GTK-3.0 のアプリで日本語が今まで打てていたのに急に打てなくなった。と、いう方は上記のように試してみてください。

2月 202016
 

いやぁ。一月は全くエントリがなかったのに二月はドドドと連チャンになってしまいました;-)。

と、いうことで本題。

FreeBSD で Thunderbird を利用していると、一緒にカレンダーアプリである Lightning を make config の時に指定することができます。あ。ports で make するときのお話です。
しかし、ports から Thunderbird と一緒にインストールした Lightning は日本語化されてないんですね。 Windows 版などはインストール後に Lightning も日本語表示できるのに・・。

と、いうことで以前「Lightning の自動日本語化。」と、いうエントリを書いてしばらくは対応できていたのですが thunderbird-38 系になって、このスクリプトを動かしても日本語化してくれなくなりました。モロモロ状況が変わったのでしょうなぁ。

と、いうことで久しぶりに Thunderbird と Lightning を調査した結果、以下のことが解りました。

  • FreeBSD の ports からインストールした Thunderbird は Lightning が以下のディレクトリにインストールされる。

    /usr/local/lib/xpi/lightning@thunderbird.mozilla.org/

  • この中の chrome.manifest をいじって chrome/ ディレクトリの中に locale ファイルをほーりこんでも日本語化されない。
  • FreeBSD の ports からインストールした Thunderbird は Lightning が上記ディレクトリにインストールされる他に、以下のディレクトリにも合わせてインストールされる。

    $HOME/.thunderbird/乱数.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/

以上の調査結果から、日本語 locale ファイルをインストールするのは ~/.thunderbird/ の中の Lightning エクステンションの中にインストールして上げなければならない。と、いうことが解りました。

いやぁ。ハマりますなぁ。これは・・。まさか二箇所にインストールされている(もしくは、バージョンアップした Thunderbird の最初の起動時に $HOME 配下にコピーする)とは思っていなかった。

 
と、いうことでサクっと日本語するスクリプトを更新したので、必要な方は以下の URI からダウンロードして試してみてください。

http://icmpv6.org/Prog/lightning-ja-20160219.tgz

簡単なスクリプトなので、詳しい説明はしません。中を覗いてください;-)。

スクリプトの lightningversion=’4.0.3.1′ は狙い撃ちしています。 install.rdf のバージョンを確認すると 4.0.6 になっているのですが、そのディレクトリが ftp.mozilla.org のサイトに見当たらないんですよね。
なので、新しいバージョンが出たら lightningversion=’4.0.3.1′ を変更してください。

 
と、いうことでカレンダーの日本語化、復活です;-)。

10月 162015
 

FreebSD の ports-CURRENT を追いかけていると、時々はまります。今回は graphics/dri のコンパイルが通らないので、その回避策について書いておきます。

まぁ、こーいうネタは時間が経つと解決するので、エントリを書いてもあまり意味は無いとは思うのですけどね。

今どきですと /usr/ports/ 辺りで svn update を実行すると dri 周りは 10.6.9 になります。 libGL 周りなど mesa-10.6.9 を利用する ports は全部で六個くらいでしょうかね。

FreeBSD/amd64 ではコンパイルの途中で止まってしまいます。 FreeBSD/arm ではとあるライブラリがねーぜ。とか言われて configure 辺りで止まってしまいます。今回は両方のアーキテクチャの回避策について書いてみたいと思います。

 
o. FreeBSD/amd64
mesa-10.6.9 からなる dri 系の ports は llvm36+clan36 が必要になりました。関連性で devel/llvm36 と lang/clang36 がインストールされるのですが、こいつらのインストールがちゃんとできていても失敗しているような感じでコンパイルが途中で止まるようです。

以下のエントリで話し合われていて、既にクローズになっているようですね。

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203192

手順としては

# pkg delete -f llvm36-3.6.2_2
# pkg delete -f clang36-3.6.2
# rm -r /usr/local/llvm36/

 
してから再度インストールして、それから graphics/dri をコンパイルすると無事に通るようです。

どーしてこうなるんだろうなぁ? と、思うのですが、思い当たる点としては llvm35 既にインストールされている状態で llvm36 がインストールされて、『二個もいらねーじゃん。』とか思い llvm36 は残して llvm35 だけ削除したのですが、もしかしたらそれが原因かもしれません。

と、いうことで llvm* の痕跡を全て削除してから再インストールすると mesa-10.6.9 系の ports 一式がインストールされるようになります。

めでたしめでたしですね。

 
o. FreeBSD/arm
こちらのほうは、まず、上記の問題を解決し、llvm36+clang36 をサラな状態でインストールしてあっても、 make が通りません。

以下は graphics/dri を make したときのログですが、

# cd /usr/ports/graphics/dri/
# make
        :
checking for RADEON... no
configure: error: Package requirements (libdrm_radeon >= 2.4.56) were not met:

Package libdrm_radeon was not found in the pkg-config search path.
Perhaps you should add the directory containing `libdrm_radeon.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libdrm_radeon', required by 'world', not found
        :

 
こちらについても以下の URL で既に問題提起されているのでその内に解決されるかと思いますが、どーしても最新版を使ってみたい方はコンパイルを通した packages を作ったのでダウンロードしてみてください。

https://www.mail-archive.com/freebsd-pkg-fallout@freebsd.org/msg247413.html

この件の問題点としては FreeBSD/arm においては lib/libdrm_radeon.so がインストールされない点にあります。
では、そもそも lib/libdrm_radeon.so はどの ports がインストールするのだ? と、うことになるのですが、 graphics/libdrm でインストールされます。 Makefile を見てみると以下の部分になります。

.if ${ARCH} == amd64 || ${ARCH} == i386
PLIST_SUB+=     INTEL_DRIVER=""
PLIST_SUB+=     RADEON_DRIVERS=""
.elif ${ARCH} == ia64 || ${ARCH} == powerpc || ${ARCH} == powerpc64
PLIST_SUB+=     INTEL_DRIVER="@comment "
PLIST_SUB+=     RADEON_DRIVERS=""
.else
PLIST_SUB+=     INTEL_DRIVER="@comment "
PLIST_SUB+=     RADEON_DRIVERS="@comment "
.endif

 
FreeBSD/arm のアーキテクチャは armv6 なので .else のロジックを走り pkg-pllist を見ると INTEL 系と RADEON 系がインストールされないんですね。たけど、 FreeBSD/arm 上で graphics/dri をコンパイルしようとすると libdrm_radeon.pc がねーよ。って言われます。

なので上記の Makefile の部分を変更してあげる必要があります。雰囲気的には ia64 や powerpc などと同じ処理をして上げる必要があります。

.elif ${ARCH} == ia64 || ${ARCH} == powerpc || ${ARCH} == powerpc64 || ${ARCH} == armv6

 
この一行だけ直してあげると libdrm_radeon 絡みのファイルが一式インストールされるようになります。

http://distfiles.icmpv6.org/distfiles/packages/All.armv6/libdrm-2.4.60,1_add_radeon.tbz

に上記の改修を入れて libdrm_radeon* がインストールされる packages を用意しておきました。最新版を利用してみたい方はご利用ください。

 
とわ言いつ、 FreeBSD/arm に radeon は必要ないので ports のメンテナは libdrm の ports を直すのか mesa-10.6.9 系の ports 一式を直すのか、わかりませんね。 mesa 系 ports を直すのは大変そうなので、多分 libdrm 系を直して libdrm_radeon 周りをドドドとインストールするようにするかもしれませんが。

実際に OpenCL とか利用できない Raspberry Pi 2 の FreeBSD/arm なのに、なんか冗長ぎみなインストールのような気がしないでもありませんが・・。

 
以上、今回は FreeBSD の ports-CURRENT で dri 周りの ports のコンパイルが通らない人用のてっぷすでした;-)。

3月 012015
 

最近はほとんどの NotePC にカメラが付いていて Windows とかだと Skype しよう。 Mac だと FaceTime しよう。などと言っていますが、普段はほとんど使わない(と、僕は思う)んだけど、実際にはどうなんでしょうか?

そんな感じの標準装備のカメラですが OS に FreeBSD を利用していた場合にどのような目的でどう使う? ってか、その前に「ここに付いているカメラは FreeBSD で動くの?」などと思ってしまうのですが、今回は実際に NotePC に付いているカメラを FreeBSD で利用してみるとこにしましょう。

 
今回登場する NotePC は僕の持っている ThinkPad Edge e145 です。このブログには何回か登場しているのですが FreeBSD がバリバリ動作しています;-)。この ThinkPad Edge e145 も最近の NotePC のトレンドを追いかけているようで、ディスプレーの上にカメラが付いています。

今回はこのカメラを利用して色々やってみたいと思います。もしかしたら、ネタ的にはもう既に枯れているかも・・f(^^;;。

 
1). カメラを認識させる
最近の NotePC に付属のカメラはほとんどが USB に接続されているようですね。 pciconf -lv とか usbconfig list コマンドを叩き、デバイス的に、どこにカメラが接続されているか確認しましょう。

 # usbconfig list
    :
ugen4.2: <Integrated Camera Vimicro corp.> at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (256mA)
    :

 
ThinkPad Edge e145 の場合は USB の ugen4.2 として認識されているようですね。と、いうことでこいつを正しいデバイスとして認識させてみましょう。

 
2). デバイスドライバのインストール
FreeBSD の純正デバイスドライバというのは存在してないのですが、 Linux 方面で開発されたキャラクタデバイスを読み込むドライバを FreeBSD に対応させた Cuse4BSD を利用します。 ports 的には multimedia/cuse4bsd-kmod になります。
まず、これをインストールし、続いてキャラクタデバイスをビデオデバイスとして認識させる webcamd をインストールします。 ports 的には multimedia/webcamd になります。まぁ、 webcamd を make install すると関連性で cuse4bsd-kmod もインストールされますが;-)。

そして multimedia/cuse4bsd-kmod を make install したときにインストールされた cuse4bsd.ko を kldload します。

# kldload /boot/modules/cuse4bsd.ko

 
カーネルモジュールをロードしたあとに wbecamd を起動し /dev/video0 として USB カメラを認識させます。オプションに USB 接続のカメラの USB のデバイス名を指定します。

# webcamd -d ugen4.2
Attached to ugen4.2[0]
Creating /dev/video0
^Z
中断
# bg
# ls -l /dev/video0
crw-rw---  1 webcamd  webcamd  0x82 Feb 28 26:14 /dev/video0
# chmod 666 /dev/video0

 
webcamd を起動すると正しく動作する USB カメラであれば /dev/video0 が生えてきます。
その後、一旦バックグラウンドにほーり投げてパーミッションを確認します。今回は一般ユーザでも利用したいので 666 に変更しています。デバイス生成時にバーミッションを変更したい場合には /etc/devd.conf におまじないを書いてください。ここでは割愛します;-)。

以上で準備は完了です。

 
3). まずはローカルでカメラを利用してみる
/dev/video0 が生えてきたので、実際にカメラに写るモノを表示させてみたいですね。そんな時は pwcview を利用します。 ports 的には multimedia/pwcview になります。
こいつを make install したあとに特にオプションも付けずに起動すると X11 上にウィンドが現れてカメラから映る景色が表示されると思います。

しかし、ローカルな FreeBSD の X11 の画面にカメラから映る景色が表示されても「だから何?」で終わってしまいますよねf(^^;;。
僕自身もまさしくそのとおりでして。ただ単に「あ。 cuse4bsd.ko と webcamd でデバイスを認識したのね。ふーん。すごいね。いじょ。」みたいな・・f(^^;;。

この写真はまさしくそんな感じで、 ThinkPad Edge e145 上の FreeBSD で KDE4 が動いていて、そこで pwcview を起動させた状態です。

IMG_0968_NotePC_Cam_1

ディスプレーの上にカメラがあるのですが、その横にある黄緑色の LED が光っております。カメラが Ready 状態ですねぇ;-)。

と、いうことで何か別の利用方法を考えてみることにしましょう。

あ。 chmod 666 /dev/video0 しましたが、これしないと一般ユーザで起動する pwcview では 画像が読み込めない状態になります。

 
4). リモートからカメラの映像を確認する
ローカルな FreeBSD の X11 に画面が出力されたので、リモートの FreeBSD から ssh -CY し、手元の X11 に pwcview を表示させればいんじゃね? えぇ。まさしくそのとおりですね。それだとリモートの X11 にカメラに映された映像が表示されます。それもひとつの案ですね;-)。

今回は http で画像を転送してみましょう。 ports から mjpg-streamer をインストールします。 ports 的には multimedia/mjpg-streamer になります。 make config は default の設定で良いです。まぁ、強いて言えば “Linux-UVC V4L2 plugin” を有効にしてインストールしましょう。

インストールしたものの中で重要なのはプラグインがインストールされた場所でしょうか。 /usr/local/lib/mjpg-streamer/ の中を覗くと .so なファイルが入っていますが mjpg-streamer を起動するときに利用するプラグインになります。

では実際に起動してみましょう。

$ mjpg_streamer -i 'input_uvc.so -d /dev/video0 -y' -o 'output_http.so -w /usr/local/www/mjpg-streamer'

 
/dev/video0 は chmod 666 しているので一般ユーザ権限で起動できます。

-i でカメラ側のオプションを指定します。 input_uvc.so プラグインを利用し、デバイスは /dev/video0 から入力します。
-o で出力側のオプションを指定します。 output_http.so プラグインを利用しコンテンツは /usr/local/www/mjpg-streamer にあることを指定します。
-o に output_file.so を指定するとカメラに写ったモノはファイルに出力してくれるのでしょうなぁ。僕は試していませんがf(^^;;。

ちなみに /usr/local/etc/rc.d/mjpg_streamer という起動スクリプトがインストールされるのですが、こいつは -i のオプションを指定する部分が無いんですよね。 rc.conf.local には以下のように書くと良いかな。

mjpg_streamer_enable="YES"
mjpg_streamer_flags="-i 'input_uvc.so -d /dev/video0 -y' -o 'output_http.so -w /usr/local/www/mjpg-streamer'"

 
さてさて。あとはウェブブラウザで http://localhost:8080 とかリモートのマシンからアクセスしてみるとそれらしいウェブサイトが表示されると思います。

ちなみにポート番号を変えたい場合には以下のように設定するが良いです。

mjpg_streamer_enable="YES"
mjpg_streamer_flags="-i 'input_uvc.so -d /dev/video0 -y' -o 'output_http.so -p 8081 -w /usr/local/www/mjpg-streamer'"

 
こんな感じで任意のポートに変更できたりします。

ただ、悲しいかな・・。 mjpg_streamer は IPv6 には対応していないようですねぇ。ソースコードの plugins/output_http/httpd.c の socket(PF_INET, …); の部分を書き換えると IPv6 対応になるかなぁ?暇なときにいじってみよう。

さてと。実際に表示される動画ですが、皆さんの目で確認してみてください;-)。
左のメニューから Static を選択すると写真が、 Stream を選択すると動画が流れ始めます。
僕の ThinkPad Edge e145 のカメラは pwcview ではまぁ、そこそこ綺麗に見えるのですが mjpg_streamer で見ると多少ちらつきますね。あと、ブラウザ側の PC の負荷が高くなるかな。

 
と、いう感じで NotePC に付いていたカメラが FreeBSD からでも利用できることが確認できました。しかもそのカメラがリモートからアクセスできて閲覧もできることが確認できたので、これで利用頻度がいっきにアップするのでは無いかと思われます。嬉しいことですね。

ただ、音を飛ばす時にはもっと別の技が必要になりそうな気がしますが、それはまた別の機会にでも:-|。

あと、カメラが付いてない FreeBSD がインストールされた PC には手元にある USB カメラを色々付けてみて cuse4bsd-kmod と webcamd で動作するか確認して見るのもよいかと思います。
もし動作する USB カメラだった場合、フツーの自作 PC にインストールした FreeBSD でも今回の組み合わせでカメラが利用できるようになるかと思われます。

ちなみに、僕は以下の二つの USB カメラを持っているのですが、こいつらをデスクトップの FreeBSD で利用してみました。

IMG_2228_NotePC_Cam_2

左側の白いのは FreeBSD というか webcamd で認識してくれませんでした。以下のようなメッセージが出力されます。

# webcamd -d ugen0.2
webcamd: Cannot find USB device

 
右側の黒いのは赤外線付きで暗いところでも良く見えるカメラなのですが、こいつは pwcview では動きましたが mjpg_streamer では動きませんでした(砂の嵐が表示されます)。
カメラによって動作が多少違うようですね。

 
と、いうことで、今回は NotePC に標準で付いているカメラで遊んでみました。 mjpg_streamer がちゃんと動いてくれると、利用価値は上がりそうですね。 また、 mjpg_streamer に変わる何か別のアプリを見つけてきて、それを試してみるのも良さそうですね。何か良い ports をご存じの方いましたら教えて下さい;-)。

また、最近流行の Raspberry Pi を FreeBSD/ARM で起動して USB カメラを接続し今回の組み合わせを利用すると、IoT な監視カメラができるかもしれません。

バッテリ運用で Raspberry Pi+USB Camera+FreeBSD+cuse4bsd-kmod+webcamd+mjpg_streamer+Wi-Fi な状態のヤツをラジコンカーに積んで走らせたら、録画ではなく、リアルタイムで動画が堪能できるような気がします。

面白そうだ・・;-)。

12月 182014
 

デスクトップとして FreeBSD を利用するとなると色々な ports がドドドと入るのですが、その中に coretutils というのがインストールされることに気がついた。 ports 的には sysutils/coreutils になるんですが、こいつは何かというと Linux で利用されているような GNU のコマンド一式なんですね。 FreeBSD 的には /usr/bin/ 配下にあるコマンドの先頭に g が付いて /usr/local/bin/ に大量にインストールされます。別に新規に GNU のコマンドを入れなくて良いよー。と、なるのでありますが・・。

そもそも coreutils はどの ports に関連付いてインストールされるのか調べてみると kdepim4 がインストールしているみたい。うひっ!! すると KDE4 をインストールしていない人にはまるで関係の無い ports と、いうことになるじゃん・・。orz

今回は、既に /usr/bin/ などにコマンドがあるのに、新たに GNU のコマンドを入れてしまう coreutils をインストールしないように kdepim4 の ports を書き換えてみたいと思います。
環境は FreeBSD 10.0-RELEASE で ports-current 、 kdepim4 のバージョンは kdepim-4.14.2_1 で coreutils のバージョンは coreutils-8.23 になります。

1). kdepim4 の Makefile 参照
まず、 kdepim4 が coreutils-8.23 をインストールしていることが解ったので deskutils/kdepim4/Makefile を覗いてみます。すると、以下の行ですね。

 20  RUN_DEPENDS= ${KDE4_PREFIX}/bin/accountwizard:${PORTSDIR}/deskutils/kdepim4-runtime \
 21               ${LOCALBASE}/bin/gmd5sum:${PORTSDIR}/sysutils/coreutils

 
20 行目で RUN_DEPENDS が設定してあって 21 行目で gmd5sum を利用するために coreutils-8.23 をインストールするようです。
では、実際にソースコードはどこで gmd5sum を使うのか確認してみましょう。

 
2). 設定ファイルで利用されている?
kdepim-4.14.2_1 の中では libkleo/libkleopatrarc.desktop というファイルの中でのみ gmd5sum が利用されているようです。ついでに gsha1sum も利用されているようです。他のソースコードでは全く利用されていないようですし、また、他の g シリーズのコマンドも利用されないようです。

これだけのために g シリーズのコマンド一式インストールするんかい!? となるので、是非ともなんとかしたいモノです。

 
3). md5sum と sha?sum のみインストールする ports を作る
coreutils の他のコマンドは要らないので md5sum と sha?sum のみインストールする ports を作りました。
実は FreeBSD の md5 や sha1 で代用できるんかな? とか思ったのですが md5sum や sha1sum には -c (–check) オプションがあって kdepim4 の kleopatra (これについては後で詳しく説明します;-) の中ではまさしく -c オプションを利用しているので FreeBSD に標準で付いているコマンドではダメなんですね。
あと、 openssl md5 オプションでも -c に相当するオプションはありませんでした。
なので、しょーがない。 md5sum と sha?sum のみをインストールする ports を作成しました。

http://icmpv6.org/Prog/FreeBSD_ports/ports-md5sum-20141216.tgz

ちなみに FreeBSD の md5 に -c 相当のオプションないんかい? などと思いウェブを色々調べたのですが、 BSD 系の人は、この -c オプションが無いためにスクリプト書いたりと色々ナンギしているようですね。

上記 ports は、もとは sysutils/coreutils を利用していますが、先頭の “g” を取って必要最小限なモノしかインストールしないように pkg-plist を書き換えました。
Makefile 中の CONFLICTS で coreutils-* も指定してあるので md5sum と coreutils の両方インストールすることはできません。

ダウンロードしたファイルは /usr/ports/sysutils/ に展開してください。

 
3). kdeppim4 の Makefile の編集と files/ の下のファイルを一個消す
上に掲載した kdepim4 の Makefile の 21 行目を以下のように直します。

 20  RUN_DEPENDS= ${KDE4_PREFIX}/bin/accountwizard:${PORTSDIR}/deskutils/kdepim4-runtime \
 21               ${LOCALBASE}/bin/md5sum:${PORTSDIR}/sysutils/md5sum

 
そして、不要となったファイルである deskutils/kdepim4/files/patch-libkleo__libkleopatrarc.desktop を削除します。

あとは kdepim4 を make && make deinstall && make reinstall し直せば OK。ノラ ports である md5sum も合わせてインストールされます。

 
4). kleopatra をちょっと説明
そもそも libkleopatrarc ってのは KDE の中で何をしているモノなのか?
コマンド的には kleopatra というのがあります。では kleopatra とはなんなのか? 基本的には証明書マネージャーの GUI 版で、ヘルプを見てみると「証明書マネージャと統合された暗号 GUI」とのことで PGP キーなどを管理するソフトウェアになります。

普段 PGP などはコマンドラインで利用しているかと思いますが、 kleopatra を利用すると GUI で鍵の作成・サイン・エクスポート・管理などが行えます。実際に利用してみると中々便利ですね;-)。

ちょっと kleopatra をコンソールから起動してみます。するとまず最初に「kleopatra セルフテストの結果」が起動し、そのときにコンソールにはログとして以下が表示されます。

    :
ChecksumDefinition[ "sha1sum" ] ("xargs", "-0", "sha1sum", "--") 
ChecksumDefinition[ "sha1sum" ] find -print0 |  "/usr/bin/xargs" ("-0", "sha1sum", "--") 
ChecksumDefinition[ "sha1sum" ] ("sha1sum", "-c", "--") 
ChecksumDefinition[ "sha1sum" ] "/usr/local/bin/sha1sum" ("-c", "--") "%f" () 
ChecksumDefinition[ "md5sum" ] ("xargs", "-0", "md5sum", "--") 
ChecksumDefinition[ "md5sum" ] find -print0 |  "/usr/bin/xargs" ("-0", "md5sum", "--") 
ChecksumDefinition[ "md5sum" ] ("md5sum", "-c", "--") 
ChecksumDefinition[ "md5sum" ] "/usr/local/bin/md5sum" ("-c", "--") "%f" () 
    :

 
セルフテストの結果に赤い NG のがあるのであれば、問題を取り除き、全部緑色にしたほうが良いでしょうね。
キャプチャはありませんが、例えば security/gnupg をインストールするときに make config のオプションで [x] SCDAEMON としてから再インストールする必要があったりします。

が、しかし、ログを確認すると今回の目的である md5sum と sha1sum のみのインストールができたので今回はよしとしましょう。

ちなみに md5sum と sha1sum が記載されているファイルは /usr/local/share/config/libkleopatrarc としてインストールされます。すると kleopatra は起動時のセルフテストにおいてはこのファイルを参照して動作しているようですね。

libkleopatrarc はインストールしたものを利用しても良いし、以下のように自分の設定として保存し、それを手で編集しても良いです。

$ cp /usr/local/share/config/libkleopatrarc $HOME/.kde4/share/config/

 
上記のコマンド実行後に自分の $HOME に置いた設定ファイルを手で編集し、 ports を利用せずに個別にインストールした md5dum と sha1sum を利用するように変更したりもできるようになります。

 
それにしても、どうして coreutils-8.23 を使うのがイヤかというと、とあるプログラムをインストールしようとして configure を走らせたのですが、これがなんと /usr/bin/install ではなく /usr/local/bin/ginstall を利用したりと FreeBSD 由来のコマンドではなく ports からインストールした GNU のコマンドを利用しているんですね。

そんなのはイヤだー。純粋な FreeBSD の /usr/bin/* なコマンドを利用したいよー。などと思ったのが今回のコトの発端なのであります。人によっては「そんなんどっちでもいーじゃん。」ってのがあるかもしれませんけどねぇ。

 
しかし、今回作成したノラ ports である md5sum は coreutils の中から一部のコマンドを切り出しただけの ports なので、似たようなのが色々できそうですね。例えば Linux の ls(1) を利用したい場合には ls のみをインストールする ports である gls とか簡単に作れそう;-)。

しかし、そんなことは、多分、僕しかしないだろうなぁf(^^;;。

12月 162014
 

以前のエントリで「KDE4 で VirtualBox を動かしたしたときに ISO がマウントできない件。」と、いうエントリを書きました。FreeBSD 上で動作する VirtualBox でゲスト OS はISO イメージを mount できない。 dbus が悪さしているようだ。って感じなんですけども。

で、そのエントリに対してコメントを頂きました。なるほど。 issetugid を undef すれば良いのですね。コメントくださった方、ありがとうございました。

で、 make configure 走らせて config.h 編集してから make && make deinstall && make reinstall するのは大変なので、 ports で選択できるようにしました。

dbus_VirtualBox_1

make config に ISSETUGID オプションを [x] にすると Support VirtualBox ISO image mount が有効になります。

gnome@freebsd.org に連絡する必要があるような気がするんだけど、きっとノラ ports のままにしておくと思いますf(^^;;。
コミットしてくださる方がいると非常に嬉しいですが VirtualBox を利用していて ISO イメージをマウントできないのは KDE4 を利用している人だけなのかな?

FreeBSD で VirtualBox 使ってて ISO イメージがマウントできない。と、お嘆きの方は以下の ports を利用してみてください。
あ。変更したのは dbus/Makefile のみです。

http://icmpv6.org/Prog/FreeBSD_ports/ports-dbus-VirtualBox_ISO_image_mount-20141215.tgz

ISSETUGID オプションを有効にすると configure ファイルの ac_func から issetugid を削除します。すると config.h では #undef HAVE_ISSETUGID になります。それで make すると VirtualBox のゲスト OS で ISO ファイルがマウントできるようになります。

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 で困っている方いましたら是非ともトライしてみてください。

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

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(^^;;。

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 に移行していくかもー。

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 の構成的な説明と、ブラウザのユーザエージェント偽装のためのネタでした。