Midnight Floating Thought

長年 Gentoo Prefix を使ってきたが、bootstrap が上手く行かないことが続いたりして限界を感じていた。 ということで、Homebrew に乗り換える。 まあ、基本的に Emacs で wanderlust さえ動けば移行に支障は無い。 Emacs。 最初、 brew install emacs したらターミナルでしか動かなくて、どうしようかと思ったが、 --with-cocoa を渡してやったら Emacs.app もインストールされた。 brew linkapps emacs しておくと /Applications にリンクも張ってくれる。 便利じゃないか。 wanderlust。 Gentoo Prefix ではパッケージで入れていたが、最近は melpa で入れられる。 ということで、インストールした Emacs で M-x package-list-packages で wanderlust を選んであっという間にインストール完了。 おまけ。 brew install lesspipe して export LESSOPEN="|lesspipe.sh %s" と設定すると、 Mac でも linux みたいに gzip されたものが less で開ける、というのを最近知った。

何かの都合で、パッケージの必要な USE フラグがマスクされていることがある。 たとえば現在 prefix 上で各種 LISP のフラグがマスクされてしまっている。 どこでそんなことにされてしまっているかというと、$EPREFIX/usr/portage/profile/base/use.mask だ。 # Andrey Grozin (25 Jun 2014) # These lisps are available only on some arches clisp clozurecl cmucl ecls gcl sbcl ありがたい設定だね、まったく。 というわけで、このマスクを外したい。 たとえば、sci-mathematics/maxima をインストールしたいのに sbcl フラグがマスクされているから、LISP 処理系として SBCL が選べない状況だったりするのは、実際に dev-lisp/sbcl パッケージがキーワード付けされて存在する以上おかしい。 方法は、最初 use.unmask ファイルみたいなものがあるかと思ったのだが調べてみるとそうではなくて、use.mask に - 付きで USE フラグを書く。 二重否定みたいで少し解りづらいが、 man 5 portage にそう書いてある。 つまり先程の sbcl を例にとるとこうだ。 # sbcl フラグのマスクを外す -sbcl 自分で設定する use.mask は当然 $EPREFIX/etc/portage/profile に置く。

MacBook Air の OS を Snow Leopard(10.6) から Mavericks(10.9) に上げた。 Snow Leopard 時代の Gentoo prefix も何やらそのまま動いてはいるようだが、一応 bootstrap し直した。 引っかかった箇所は Bug 491098 - sys-devel/gcc-apple-4.2.1_p5666-r1: compile failed for redefinition of a 'extern inline' function で、そこにあるパッチに倣って bootstrap-prefix.sh を少し編集する必要があった。 数日前の readline の問題はもう直されていたので今回は何事も無し。 これから旧prefix環境の world ファイルを引っ張ってきて、emerge world を仕掛ける予定。

Gentoo prefix のブートストラップ stage3 で bash のコンパイルに失敗していた。 gcc -m32 -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob -L./lib/tilde -L./lib/sh -Wl,-search_paths_first -L/Users/tetsushi/G2/usr/lib -L/Users/tetsushi/G2/lib -L/Users/tetsushi/G2/tmp/usr/lib -march=nocona -o bash shell.o eval.o y.tab.o general.o make_cmd.o print_cmd.o dispose_cmd.o execute_cmd.o variables.o copy_cmd.o error.o expr.o flags.o jobs.o subst.o hashcmd.o hashlib.o mailcheck.o trap.o input.o unwind_prot.o pathexp.o sig.o test.o version.o alias.o array.o arrayfunc.o assoc.o braces.o bracecomp.o bashhist.o bashline.o list.o stringlib.o locale.o findcmd.o redir.o pcomplete.o pcomplib.o syntax.o xmalloc.o -lbuiltins -lglob -lsh -ltilde -liconv -ldl Undefined symbols for architecture i386: "_enable_hostname_completion", referenced from: _shopt_enable_hostname_completion in libbuiltins.a(shopt.o) ld: symbol(s) not found for architecture i386 collect2: ld returned 1 exit status Makefil...

gentoo と python と eselect と , dev-lang/python と /usr/lib/portage/pym , 0xF 0xB 0x31 0xFF と続いてきたシリーズも今回でひとまず終わり。 前回 libSystem.B.dylib で死ぬところまで見たが、 Gentoo Bugs #475284 では回避策の議論が進んだ。 eselect のコードでどこがこのバグを踏む原因になっているのかというと、 エラー出力のファイル記述子を置き換える辺りらしい。 決め打ちではエラーが起こるが、自動で振る機能は bash-4.1 以降の機能、というのが回避するコードを書く際の悩みどころだったようだ。 ともかく、対策済みのバージョンが eselect-1.3.6 としてリリースされた。 一件落着だ。 とはいえ、根本原因が塞がれたわけではないのでバグはまだオープンで、 バグタイトルが "app-shells/bash-4.2_p39-r1: "exec 3>&2" causes illegal instruction (seen with app-admin/eselect-1.3.5)" と大幅に変わって bash チームに投げられている状態である。

app-admin/eselect-1.3.5 問題の続き。 一応復習しておこう。 PORTAGE_ELOG_COMMAND で呼び出された gentwoo が eselect を呼び出したところで死ぬ。 環境変数を gentwoo に引き渡しておけば死なない。 Gentoo Bugs #475284 に報告してみて得た情報なども加味しながらもう少し情報を補足しよう。 環境変数が空っぽだと死ぬので env -i /path/to/eselect とすればいつでも再現できる、と主張したのだが、 これで現象が再現できるのは(少なくとも今のところは)私の Gentoo Prefix on OS X でだけである。 そもそも、eselect は bash スクリプトで、死んでいるのは具体的にどこなのか、と聞かれて core を吐かせることにする。 ulimit -c unlimited としておく(と core ファイルは /cores に core.PID という名前で残される)。 死んでいるのは bash の中だ。 bash 自体が死ぬような現象には遭遇した経験が無かったので、どうにもデバッグの糸口が摑めなかった。 とりあえず eselect の中に echo コマンドをいくつか挟んでみた。 どうも死ぬ場所は一定していないらしい(埋め込んだ echo が実行される前に死んだり、実行してから死んだりまちまち)。 とすると、むしろメモリーのゴミを踏んでしまっているか? メモリーエラーには valgrind。 ここでも環境変数を渡さないように env -i /path/to/valgrind /path/to/bash /path/to/eselect。 すると次のような出力を得る vex x86->IR: unhandled instruction bytes: 0xF 0xB 0x31 0xFF ==64989== valgrind: Unrecognised instruction at address 0x2a5ce9. ==64989== at 0x2A5CE9: _dispatch_mgr_invoke (in /usr/lib/libSystem.B.dylib) ==64989== by 0x2A4F58: _dispatch...

昨日の投稿で、gentwoo が上手く動かないのは python と eselect のせい、と書いた。 dev-lang/python は 2.7.3-r3 から 2.7.4 の間に何が変わったのか、ということを調べてみた。 昨日書いたように、portage.util の ImportError が第一の原因なので、それを見てみる。 python-2.7.3-r3 では sys.path に ${EPREFIX}/usr/lib/portage/pym が含まれているが、python-2.7.4 では含まれない。 では、python-2.7.3-r3 ではどこでこのパスを設定しているのか。 それは site.py の中である。 site.py にそれを書き加えているのはパッチ tar ボールの中の 03_all_add_portage_search_path.patch である。 python-2.7.4 ではこのパッチが消えている。 おお、これだ。 だがちょっと待て。 だとすると、普通に Gentoo Linux を使っている人も同じ症状になってしまわないか? ということで、VirtualBox に Gentoo Linux 環境をお手軽に用意するために liveDVD イメージをダウンロードして、起動。 最新の liveDVD とはいえ昨年末のなので、python のバージョンは 2.7.3 である。 当然、emerge --sync して emerge -1 =python-2.7.5 で 2.7.5 に上げる。 python2.7 を立ち上げて、import sys; print sys.path。 うん、なぜか /usr/lib/portage/pym がちゃんと含まれている。 パッチは消えたのだから、site.py には設定されていない。 環境変数? python -E で環境変数を無視して立ち上げると確かに pym のパスは消える。 $ env | grep pym PYTHONPATH="/usr/lib/portage/pym" そう、環境変数 PYTHONPATH で設定しているんだ。 環境変数自体は /etc/env.d/05portage で定義されていた。 翻って Prefix 環境で調べてみると、確か...

Gentoo の portage の機能として、make.conf で PORTAGE_ELOG_COMMAND にログ出力用の任意のコマンドを指定して実行させる仕組みがある。 gentwoo はそれを利用したログ収集のサイトで、そこにログを送るために betagarden overlay の app-portage/gentwoo をインストールして PORTAGE_ELOG_SYSTEM="custom:* save" PORTAGE_ELOG_COMMAND="gentwoo '${PACKAGE}' '${LOGFILE}'" といった行を make.conf に書き加えてある。 最近、といってももう3週間ぐらい、この gentwoo の呼び出しでエラーが発生するのである。 二種類のパターンがある。 一つめは gentwoo-2.7 という(Python 2.7 で実行される)スクリプト本体で発生するエラー。 Traceback (most recent call last): File "/Users/tetsushi/Gentoo/usr/bin/gentwoo-2.7", line 11, in from portage.util import getconfig ImportError: No module named portage.util !!! PORTAGE_ELOG_COMMAND failed with exitcode 1 二つめは gentwoo というラッパーシェルスクリプトで発生するエラー。 /Users/tetsushi/Gentoo/usr/bin/gentwoo: Execution of 'eselect python show --python2' failed !!! PORTAGE_ELOG_COMMAND failed with exitcode 1 どちらのエラーも portage がインストールする ${EPREFIX}/usr/lib/portage/pym/portage/elog/mod_custom.py で spawn_bash の引数に env=os.env...