電車内でgbs chrootできない( ﾟдﾟ)!
電車でPCを起動して、コンソール立ち上げ
$ gbs chr -r ~/GBS-ROOT/local/scratch.armv7l.0/
とすると、
info: chroot /home/moguriso/GBS-ROOT/local/scratch.armv7l.0/
chroot: failed to run command `su': 実行形式エラー
と言われて、一度lbで何らかのパッケージをbuildするまでchroot出来なかったりします。
特に電車ではネットワークに繋がっているとは限らないので結構ストレスです。
何が悪いのか
gbsコマンドはpythonで書かれたスクリプトで、フロント部分は /usr/bin/gbs に出されています。実際にはサブコマンドの集まりで、それらは
/usr/lib/python2.7/dist-packages/gitbuildsys
に格納されています。chrootの場合、実体はcmd_chroot.pyにあり、ここで
40 cmd = ['sudo', 'chroot', build_root, 'su', user]
というコマンドを組み立ててchrootしています。厳密には前２つの"sudo"、"chroot"はx86系のコマンドで、末尾の"su"はarmバイナリ（build_rootのパス配下にいる）を呼び出すことになります。
arm向けのパッケージビルドにはqemuが利用されいてるはずですが、スクリプトだけを追いかけてもどこで呼んでいるのかまでは、引っかかって来ません。
$ grep -rin qemu ./ バイナリファイル ./cmd_build.pyc に一致しました ./cmd_build.py:76:QEMU_CAN_BUILD = ['armv4l', 'armv5el', 'armv5l', 'armv6l', 'armv7l', ./cmd_build.py:232: if buildarch not in QEMU_CAN_BUILD:
結論からいうと、別に環境をスイッチするためのスクリプト（/usr/bin/depanneur）がいて、こいつが
1070 if ($arch ne "i586" ) { 1071 push @args, "--use-system-qemu"; 1072 }
的なオプションを内部で指定してqemu-user-staticを設定し、armバイナリのsuを実行できるようにbinfmtを利用してくれる設定をする（x86環境でarmバイナリを実行できるようにする）ようです。
なのですが、gbs lbでのみ上記を呼び出すため、起動直後にgbs chrootしてもbinfmt設定がなく、armバイナリのsuが呼べない→chroot出来ない、となっていました。
JIRAにあげてみた
「バグじゃね？」と思ったのでJIRAにあげて見ました。*1
どうも、gbs chrootはbuildする際に作成されるrootfsの作成を補助するものなので、そのrootfsをガリガリ使いまわしてる私がおかしいらしいです。（usage errorではないと思うとは言われましたけど。。。）*2
