読者です 読者をやめる 読者になる 読者になる

テクニカルプア

備忘録と若干の補足

pacman 4.2で吐かれるpacaur関連のエラーへの対処法

Arch Linux

 pacmanのバージョンが4.2になったが、この状態でpacaurを使うと

cower: error while loading shared libraries: libalpm.so.8: cannot open shared object file: No such file or directory

とか

expac: error while loading shared libraries: libalpm.so.8: cannot open shared object file: No such file or directory

というエラーが出て、AURのパッケージに関する操作が出来なくなる。
 pacman 4.2に際してpacmanのライブラリ(libalpm)が更新された為、あたらしいlibalpmを使ってcowerもexpacもコンパイルされないといけない様子。
 というわけなので、AUR (en) - pacaurAUR (en) - cowerで触れられているように、pacmanのバージョンを4.2に上げた状態でcowerを再ビルドしてインストールする必要がある。
expacについてもエラーが出る場合も同じくpacmanのバージョンを上げて再ビルドすればよい。cowerとは異なりexpacはextraレポジトリにあるArch公式のパッケージなので、こういうとことかからパッケージ作るのに必要なやつを持ってくる必要がある。

KMSのearly modeでブート時にTuxを鎮座させる

Arch Linux 雑記

(2015-03-05 追記:以下に示す方法であっても、特に私自身の環境ではTuxが出てこなくなってしまった。原因はいまだわからない)

 Linuxカーネルコンパイルを知って以来、ずっとブートシーケンス中にTuxを鎮座させる事を夢見ていた。Arch Linuxが配布するカーネルではブートロゴが表示される設定になっていないので、Tuxは鎮座しない。
f:id:aaodsn:20141128225921j:plain
 基本的には Gentoo Forums :: View topic - Tux at top of screen during boot? に従えばいいんだけど、KMSを利用する環境でearly modeになっている場合*1カーネルパラメータをいじくる手間がいらなくなるかわりにもう一手間増えて、グラフィックスに関するドライバをビルトインにしないといけなくなる。つまり、Intel製のグラフィックスの場合、

CONFIG_DRM_I915=y
CONFIG_DRM_I915_KMS=y
CONFIG_DRM_I915_FBDEV=y

という設定にしなければならない。上のリンクに沿って言えば、

Device Drivers --> Graphics support --> Direct Rendering Manager --> Intel 8xx/9xx/G3x/G4x/HD Graphics

の箇所をモジュール("M")ではなくビルトイン("*")にする必要がある。

理屈

 正しい理解をしている確証もなく、一次資料に目を通したわけでもないので参考情報として解釈してほしい。

KMSとは

 kernel mode settingの頭字語。Linuxカーネルからグラフィックスあたりを操作する為の仕組み。

initramfsとKMS
  • Arch Linuxでmkinitcpioはinitramfs(カーネルイメージとかいわれる)を生成するためのスクリプト
  • mkinitcpioは /etc/mkinitcpio.conf の内容を読み込む
  • KMSがearly modeになっている場合、KMSに必要なモジュールはシステム起動時の早い段階でカーネルに読み込まれる
  • 早い段階でモジュールが読み込まれるとはいうものの、その際あるいはその前にドライバが読み込まれるとは限らない
    • 実際、ドライバをビルトインにしなかった時はTux鎮座しなかった
  • カーネルにグラフィックスのドライバを組み込んでおけばモジュール読み込み後すぐグラフィックスが利用できる

おまけ

 /proc/config.gz をzcatしたやつを晒す。AUR (en) - linux-ckThinkPad X201sで利用することを前提としている。4000行くらいあって、ページを無駄に重くするだけだと思われるので、晒すとは書いたがリンクを貼るにとどめておくことにする:zcat /proc/config.gz
 configの行数がかさむのは修行が足らない証だ。

*1:/etc/mkinitcpio 内の"MODULES"にグラフィック関連のモジュールを加えている場合が該当する。MODULES=i915 みたいな記述があるなど。

MeCabをpython3で使うためのパッチ書いた

雑記

 CaboChaをpython3で使うためのパッチ書いた - テクニカルプアの続きっぽい感じ。

 パッチは以下の通り。CaboChaの場合と変更点に違いはない。

 以下個人用メモ。自然言語処理をやってる人にしてみれば常識なんだろうけど私は自然言語処理をやっていないので。

  • MeCabMeCab用辞書があって初めて動く
    • 辞書が無いとRuntimeErrorとか言われる
  • CaboChaはMeCabがきちんと動く事ではじめてちゃんと動作する
    • MeCabがグズってるとpython周辺を飛び越えてC++辺りのコードからエラーが飛んでくる

ThinkPad X201s買った

機械

f:id:aaodsn:20141007214600j:plain

 物欲が爆発して頭が真っ白になり、気がついたら注文を完了していた。送料込54000円也。型番は5397-FUJ。
 程度の良いX201(s)が2万円代で手に入る未来をずっと待っていたけれど、ThinkPadの凋落が悲鳴に近い形で叫ばれ始めたときにそんな未来は来ないだろうと見通しを立てるべきだったと思った。
 これで当分物欲に苦しめられることはなくなるだろう。

Qtでの動作を念頭に置いて設定等をしたFcitxがGTK+なアプリ上で動かなくて困った時に確認すると嬉しいかもしれない事項一覧

雑記 KDE

 いろいろあってTox*1シンパになった。
 しかし困ったことに、慣れ親しんだuimはToxのQtフロントエンドであるqTox*2で必要となるQt5に公式には対応しておらず、結果日本語が使用できない。
 githubにあるuimのレポジトリなどから入手できる最新の不安定版では一応Qt5に対応しているようだが*3、それを使うとqToxがSegmentation Faultという断末魔を上げて死んでしまう*4。日本語話者なのでToxでも日本語を使いたくて困っていたけれど、これまたいろいろあってuimをやめてQt5に対応済みのFcitxに移行すれば良いのだと気がついた。
 ここでタイトルの登場となる。つまりはそうなったのだ。

前提

Qtでの動作を念頭に置いて

というのはつまりFcitxを導入するときに以下のようにインストールした場合という意味:

$ sudo pacman -S fcitx-im fcitx-im-qt5 kcm-fcitx kdeplasma-addons-applets-kimpanel

その他Fcitxのインストールや設定に関する情報は全てFcitx (日本語) - ArchWikiを参照した。

確認事項

プロファイル系の設定ファイル

 .xprofileとか.xinitrcとかを意味する。ここに追記するFcitxに関しての内容が

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

となっているかをみる。以上の内容で駄目な場合は一行加わって

export GTK_IM_MODULE="fcitx"
export QT_IM_MODULE="fcitx"
export XMODIFIERS="@im=fcitx"
export DefaultIMModule="fcitx"

となることもある。

ロケール

 LC_CTYPEが"ja_JP.UTF-8"ではない場合、GTK+なアプリでIMEが有効にならない場合がある。
 ArchWikiによれば(GTK+アプリではないものの)これはEmacsのバグでEmacs上で生じるみたいなことが書いてあった。だがGTK+を使用しているはずのChromiumやmikutter上でもIMEが有効にならないことがあった。
 これについては/etc/locale.confや${HOME}/.xinitrcなどの適当な設定ファイルへ

export LC_CTYPE="ja_JP.UTF-8"

と書けばよい。

GTK IM Module

 GTK+のIM関連の設定を更新するといい感じになることがある。これは以下のようにする。

# gtk-query-immodules-{x}.0 --update-cache

{x}は2か3で置き換えるGTK+ 2系を対象にする場合は"2"で、GTK+ 3系を対象にする場合は"3"でそれぞれ置き換えて実行する。
 詳細はFcitx (日本語) - ArchWikiを参照。

GTK+の外観設定ファイル

 .gtkrc-2.0や.gtkrc-2.0-kde4のようなファイルがホームディレクトリ直下に存在する場合、これをリネームするか削除するかすると良い感じになる事がある。GTK+ - ArchWikiによれば、これらのファイルはGTK+アプリで外観周りの設定を記述するための設定ファイルであるようだ。

*1:https://tox.im/

*2:https://wiki.tox.im/QTox

*3:こういうのがAURにもある:AUR (en) - uim-qt5

*4:qToxの問題かと思ったけれど、fcitxでもvi-cooperative modeもどき | とさいぬの隠し部屋によればQt5のアプリであればqToxに関わらず全部死ぬようだ

コマンドの終了をYoで知らせるシェルスクリプト書いた

書いた
2014-09-27 追記

デスクトップ環境の機能を利用してYoしたことを通知する機能をつけた。Xが起動してない場合は標準出力へ通知内容と同様の文言を表示する。変更点は一目瞭然なので注釈は省略。つかうアイコン画像にYoっぽい感じのものを選ぶと通知がおしゃれになって嬉しくなる。

Yo*1について




本題

前フリ

 mozcやLinuxカーネルといった長大なプログラムのコンパイルをルーチンワークとしている人々にとって、それらをコンパイルしている間に何をすべきかというのが問題になることが多いと思う。
 長大なプログラムのコンパイル時にはコンピュータのリソースがコンパイルに持っていかれてしまってパフォーマンスが急激に低下するためにコンピュータを使う作業が捗らなくなる。非コンピュータな作業をすれば解決するのだけど、コンパイルがいつ終わるのか気になってどうしようもなくなってしまう私のようなせっかちな人間は、コンパイルが終わるまで標準出力とかに吐き出される進捗をずっと見続けてしまい、結果時間を浪費することになってしまう。
 ところで、Yoはただ単純にYoと飛ばし飛ばされるだけの単純明快なコミュニケーションツールである。コミュニケーション上ではYo以外の冗長な情報は必要とされない。となれば、前述したコンパイルやあるいはその他のコンピュータ上で行われる長大な作業の終了を通知するのに、Yoは最適なツールなのではなかろうか。かつてはメールで通知されたものはYoという現代的なツールに置き換わるのだ。

本題

 Yo API*2を使用して、コマンドの終了を所望のYoユーザへYoして知らせるシェルスクリプトを書いた。

 使用するのに必要なものは以下の通り。

  • Yoのアカウント(通知を受ける)
  • YoのAPIトークン(Yoするのに必要。http://yoapi.justyo.co/ から取得できる)

 APIトークンの取得方法はブログにYoボタンを設置した | SOTAをみるとよい。APIトークンを取得したら、上述したスクリプト内の'<YOUR_API_TOKEN>'を取得したAPIトークンで、'<DESIRED_USERNAME>'をYoしたいユーザ名で書き換えればよい。これで、API登録時に指定したYoユーザから、DESIRED_USERNAMEを置き換えたYoユーザへYoが飛んでくる。

凡例
$ yotify <command> <options>

 別にyotifyじゃなくてもよい。前述のシェルスクリプトを適当な名前で保存して実行権限を与え、パスが通ってるディレクトリへ配置すれば使用できるようになる。
 これでコンピュータに長大な作業させている間も進捗を気にして画面を注視する必要がなくなり、Yoを待つだけになる。有意義な時間が増える。

Elecom WDC-433SU2Mで802.11acな通信を実現したのかわからないけどとりあえず動いた

雑記
2015-03-08 追記

x86-64でも動くという情報をいただいた(x86_64 Linux上でELECOM WDC-433SU2Mを用いて802.11acな通信を実現する)。リンク先記事で紹介される方法で利用が可能となる。
ただし、Arch Linuxの場合はlinux-headersによるファイル群が /lib/modules/`uname -r`/ に配置されるので、Makefileにおける変数 "LINUX_SRC" は "/lib/modules/$(shell uname -r)/build" のままである必要がある。
また make install 後 modprobe を忘れずに(さもないとハマることになる。本記事コメント欄参照)。
id:grafiさん、有難うございました。

2015-03-11 追記

動作が確認できたカーネルは3.18系のもので、3.19.1では(少なくとも私の環境では)コンパイルに失敗した。


 Elecom WDC-433SU2Mで802.11acな通信を実現したかった - テクニカルプアの続き。
 以前の記事と同様の手順をx86-64な環境ではなくx86(Archでいうi686)な環境で実行し、そのままx86な環境で使用してみたところ、WDC-433SU2Mの動作に成功した。ただ、思ったような速度が出ず、802.11acとして接続されているのか不安になっている。でもまあいい感じに通信してもカーネルパニックは起こさないので、動いたとしてよいと思う。
 というわけでドライバはx86向けに書かれていたようだ。

 一応環境を以下に示す。同じバージョンでx86-64な環境ではカーネルパニックを引き起こした。

$ uname -r
3.14.6-1-ARCH
$ gcc --version
gcc (GCC) 4.9.0 20140521 (prerelease)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.