12月 122015
 

最近は Windows10 mobile 対応のスマートフォンがドドドと出て、検索サイトからこのサイトへ飛んでくる方も多くなったようです。

僕はずっと Nokia Lumia620 を利用していたのですが、Windows Phone8 -> 8.1 -> 10 と進んできました。
Nokia Lumia620 で利用する Windows10 mobile は非常に、良くフリーズします。一日 2,3 回バッテリーを抜くことがあります。マウスコンピューターの MADOSMA で Windows10 mobile を利用している人に聞いてみると『特にフリーズするようなことも無く安定して動作している。』とのことでした。マウスコンピューターの作り込みはちゃんとしている。と、いうことなのでしょうなぁ。

 
さて。今回は僕が利用している Lumia620 にインストールされているアプリの一覧をドドドと掲載します。非常に長い JPG ファイルになってしまったのですが、お許しくださいf(^^;;。

僕は Windows ストア ギフトカード を購入したことがあるので有料アプリも買うことができます。何個かのアプリは実際にお金を出して購入しています。

Windows Phone8/8.1 の頃には動いていたけど Windows10 mobile にしたら動かなくなった。なんてのもあったりします。Remote という iTunes リモコンアプリなんかは iTunes と同期ができなくなりました。ファイアーウォールとかが悪さしているのかな?しかし、まぁ、それはそれでしょーがないかな。

お勧めは

  • GPS Voice Navigation (有料版)
  • Net Check Pro (有料版)
  • Note Plus (有料)
  • People+
  • Pockt File Manager (有料)
  • UniShare

などでしょうかねぇ。有料版を買うのは『お金払うからさぁ。今後もジャンジャン Windows mobile 対応のアプリ書いてねぇ。』という、期待も込められています。

今、 Windows Store にアプリが少ない。と、言われていますが、考えてみると初代 iPod Touch や iPhone3G を使っていたときにはアプリはほとんど無かったんですよね。その頃と似たような状況です。
そして、今あるアプリは広告が無いのが多いので僕的には非常に嬉しいです。アプリがドドドと増えてくると広告が出るアプリが多くなってイヤなんですよねぇ。

と、いうことでアプリの一覧の JPG 貼り付けてこのエントリは終了です。皆さんも、少ないながらも、よさげなアプリを見つけてみてください;-)。

Windows10mobile_All_Apps

11月 152015
 

ほぼ一年前にドスパラで購入した DG-D08IWB 32GB は Windows10 にアップデートしました。しかし、アップデートするとサポート対象外になるんですな・・。恐ろしい。僕のはあと一ヶ月ほど保証が残っているんですけど・・。

しかし HDD というか SSD の容量は 32GB あったのに Windows10 Pro 入れて Office2013 をインストールすると残り 1GB になり OneDrive とか Dropbox 、ダウンロードフォルダなどを VHD 化した d:¥ に移動して mklink しても本当に容量が足りない。

しょーがないので『工場出荷時の状態』に戻すかねぇ。とか思い、Shift キーを押しつつ Windows10 の電源アイコンから再起動して、ドスパラが俗にいう「Diginnos かんたんリカバリー」を試しました。

そしたらあーた。工場出荷時は Windows8.1 with Bing なんだけど、実際には Windows10 の再インストールが走ってしまいました・・。orz

一応復旧用 USB メモリも作成しんだけど、 USB メモリからブートする方法が解らない。以前、 FreeBSD をブートしようと試みたんだけど FreeBSD もブートしない。

BIOS の画面のブートシーケンスを見ると「WindowsBootManager」とか表示されるのみで BIOS から外部のデバイスは見えないみたい。
なので、実質的に復旧用 USB メモリを作っても意味ないのかな? SSD 上にはリカバリー領域が残っているのに、非常にもったいないことです。

と、いうことで Windows10 Pro がクリーンインストールされてしまいました。あ。自分で全部消してインストールを選択したので。 SSD の容量は OS が使用するのみで大体 8GB ほど。残りが空きスペースになりました。まだ windows.old とか消してない状態ですけどね。

 
で、本題はここからです。
まっさらな状態で widnows10 Pro が入ったのですが、なんとっ!! タッチ画面が随分とずれてしまいます。あと、画面が回転してくれません。それ以外はちゃんと動作しているようなので、この二点のみ問題が残りました。

ウェブで検索するともちらほらと回避策が掲載されていました。今回はそれらを参考させて頂き、僕も復旧しました。

今回、主に参考にさせて頂いたのは以下のサイトです。

http://bbs.kakaku.com/bbs/K0000723371/SortID=19042689/
http://pretes.wp-x.jp/2015/08/15/post-25/

ここから下は自分のためにログ残しです。今後はいつでも Windows10 を新規に再インストールできる状態にしておく必要があるのでねぇ・・。

 
1). 画面の回転
画面の回転はセンサーが感知して、画面をクルっと回すようです。そのためのドライバがインストールされているのですが、一応、再インストールします。
ドライバは「デバイスマネージャ」で確認すると Sensor I/O devises の中にあります。

Sensor I/O devises の Kionix KXCJ9 Accelerometer SPB は本体の傾きを感じたら画面をクルっと回すセンサーのようで、そのドライバになります。

僕は以下のサイトからダウンロードして来ました。ありがとうございます。

http://www.tekwind.co.jp/faq/CLIDE/entry_314.php

現在インストールされている Kionix KXCJ9 Accelerometer SPB というを「デバイスマネージャ」で削除して再インストールするのが良いでしよう。

インストールして再起動が終わったら、以下のレジストリを変更します。上記サイトからダウンロードしたファイルにはレジストリ用のファイルもあるので、それを追加してあげます。

レジストリは以下のようですが、僕の場合は途中のが /0000/ でした。

HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Enum/ROOT/SENSOR/000/Device Parameters/kxfusion

上記の URL からダウンロードしたファイルの中にあるレジストリ設定は、僕の DG-D08IWB では横にすると縦になる。縦にすると横になる。と、いう状態で一個ずれてしまいます。

以下の値にすると正しい動作になりました。

01 01 01 01 00 00 02

これで多分、画面の回転が正常動作になるんではないかなと思われます。

 
2). タッチがずれる
画面をタップすると 5cm くらいずれて全然正確なところがタップできません。コントロールパネルの中に「タブレット PC 設定」というのがあり、ディスプレーとタップの調整をしてくれるメニューがあるのですが、それをやっても全然ずれる。と、いうか、タップがずれているので既にその画面から設定が行えない状態なのであります。

DG-D08IWB を購入して Windows10 をクリーンインストールした人はこれに悩むみたいですね。ドスパラもドライバとかダウンロードできないし、(一回電話したが)サポートの対応してくれる人の知識が非常に低いようです。まぁ、言い方を変えると IT リテラシーがそんなに高くない人が対応しているようです。

対応策としては C:¥Windows/inf/ の中に TouchSetting.gt というファイルを一個いれるだけです。タッチや本体傾きソナー、ドライバに対する DG-D08IWB 用の設定ファイルらしいです。今 DG-D08IWB を利用していて工場出荷時の状態の状態の人は C:¥Windows/inf/TouchSetting.gt のバックアップを取っといた方が良いでしょう。

既に Windows10 をクリーンインストールして過去のしがらみから決別した人はインターネット上のどこからか拾ってくるのが良いでしょう。

 
これで一応復旧です。

しかし、復旧後に Windows10 1511 10586 が降ってきてインストールが始まったのですが、 40% か先に進まないのはどうしたモノか・・。ほっとけば良いのかなぁ・・。

11月 082015
 

いやぁ。ようやっと来た。と、いう感じです。あ。 NOKIA Lumia620 のお話です。

Windows Phone に Windows Insider をインストールして First にしていると、デスクトップ版のように一足早く試せるんだけど・・。

今までは 10.0.10166.0 という Insider Preview 版でした。こいつはひどいバージョンで、

  • 日本語キーボードがダウンロードできないので日本語が打ち込めない
  • SD カードが OS から見えないので本体のスペース食いつぶす

到底実用できるバージョンではありませんでした。

電話の更新 には新しいバージョンが見えていてダウンロードまでできるんだけど、インストールのときに失敗しているという状態が四ヶ月くらい(デスクトップ版 Windows10 がリリースされた直後くらいから)続いていたんだけど、ようやっとバージョンアップできたよー。

今度の Insider Preview のバージョンは 10.0.10581.0 です。

Windows10mobile_10581_1

やったーっ!! と、いう気分で色々いじってみました。あ。いじるときは羽田とか成田の出国ゲートを出た辺りで色々やりましょう。

何ができるようになったかと言うと、

  • 日本語キーボードがダウンロードできるようになったー。日本語が打てるようになったー。
  • 設定から[システム]->[ストレージ]と来て表示はちと怪しいんだけど SD カードが OS から認識されるようになりました。試しに写真撮ってみたらちゃんと SD カードに保存されるようになったり、ダウンロードしたモノも SD カードに保存されるようになったー。
  • スタートメニューにフォルダのようなモノが表示されるようになった。
  • 3G もバリバリー。ただ、10166 の頃に 3G SIM カード入れてないのでその頃から動いていたかは知らないf(^^;;。
  • テザリングも無事に使えます。ただし 3G なので非常に遅いけど・・。
  • Cortana は日本語版がダウンロードできるようになった。天気予報とかは教えてくれますf(^^;;。

 
まぁ、日本語キーボードが利用できて SD カードが OS から見えるようになったらそれはそれで使えかなぁ。とか思っています。

が、ダメな部分も書いておきます。

  • 結構頻繁にフリーズ・もしくは再起動する。OneNote 使っているときに再起動とか・・。orz
  • Bluetooth キーボードはまだ使えないみたい。
  • USB な機器もまだみたい。下にちょっと書くけど。
  • あと、なんかあるかな?
  • 画面出力ができないのは Lumia620 の機能がたりないからな・・。
  • がんばれーコルタナ。って感じ。会話は Siri には及ばないけど・・。けど、その前に良く落ちるf(^^;;。

 
とまぁ、こんな感じで、随分と使いやすくなりました。と、いうか、その前に Lumia620 も Windows10 mobile の対象になっていてくれていて良かった。と、いうのがあります。

 
ちゅーこって、あと、色々やってみたので書いてみます。

  • https://www.windowsphone.com/ja-jp/ ってのはどこに行ってしまったんだろう?以前はここから Windows Phone にアクセスして自分が購入したアプリはウェブから Lumia620 にインストールできたんだけど、その機能がどっか行っちゃったよー。 google の Play Store のようで嬉しい機能だったんだけど・・。
  • NOKIA Lumia620 を Mac に USB で接続すると、以前は Microsoft 謹製の Windows Phone アプリがあったんだけど、それは今は動かなくなりました。 Lumia620 を Mac に USB で接続すると 写真アプリが起動して写真を読み込んでくれる動作はするんだけど、撮った写真を SD カードに保存していると『写真は無い』と写真アプリが言います。

 
しかし、まぁ、最大の懸案であった日本語キーボードと SD カードが使えるようになったのは大きいですね。

なんか、あまりネタが無い記事になってしまいました。今日の午前中からいじり始めたのでねぇ・・。

しばらくは常用してみようと思います。あ。海外で;-)。

10月 182015
 

ちょっと前のエントリで「Zeroconf 考察。」というのを書きました。デスクトップで利用する場合には Avahi を、サーバで利用するなら mDNSResponder+howl で。って感じのエントリでした。

さて。サーバ側で利用している mDNSResponder (正確には mdnsd のこと) ですが、こいつは非常にお行儀の悪いプログラムですねぇ。さすがは Apple 謹製って感じでしょうか;-P。

どの辺りがお行儀悪いのか?

mdnsd は起動してからのログが随分と出力されます。例えば、サーバの場合は複数のインターフェースを持っていて、アクセスされたくないインターフェースには ipfw などで止めたりします。しかし、 mdnsd はそんなのお構いなしにサーバの全てのポートにマルチキャスト DNS パケットを port:5353 に流しまくりなんですね。

挙句の果てには『bge1 にパケット投げたら Permission denied だった。』とかログを出しまくりで、ヘタしたら /var/log/messages は mDNSResponder のログで溢れかえっしまいます。

これは非常にウザいので今回はログを一つのファイルに集約するようにして /var/log/messages には出力しないようにしてみましょう。
まずは syslog の設定から。あ。ターゲットは当然 FreeBSD です;-)。

 
o. syslog の設定
今回は mdnsd のログは今回は LOCAL4 に出力するようにします。なので、LOCAL4 に飛んできた syslog の扱いについて設定します。

まずは /etc/syslog.conf の設定変更です。

        :
*.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err;local4.none       /var/log/messages
        :
#
local4.*        /var/log/mdns.log
#
        :

 
/var/log/messages に出力されたくないので local4.none を追加します。そして LOCAL4 ファシリティ用のログファイルを設定してあげます。

次に /etc/newsyslog.conf も編集しましょうかね。

        :
/var/log/mdns.log                       644  7     100  *     JC
        :

 
まぁ、こんな感じで登録します。あとは syslod と newsyslog を restart すると準備は完了です。

 
o. mDNSResponder のソース改修
mDNSResponder は ports 的には net/mDNSResponder/ になります。ここでまず make patch とか打ってソースを展開したうえでソースコードを覗いてみます。今回は syslog に関わる部分ですね。

と、いうか mDNSResponder (バイナリ自体は ports の net/howl/ でインストールされる) と、いうか mdnsd (こちらが ports の net/mDNSResponder/ がインストールする) は syslog プライオリティなどを変更するオプションが無いんですね。なのでソースコードを眺めんですけども。

それで、ソースコードを眺めいたらありましたね。 syslog の openlog は mDNSShared/PlatformCommon.c でやっているようですね。

以下はパッチです。

--- mDNSShared/PlatformCommon.c.orig    2012-06-30 13:52:35.000000000 +0900
+++ mDNSShared/PlatformCommon.c 2015-10-16 10:57:01.595162000 +0900
@@ -184,7 +184,7 @@
             fflush(stderr);
         }

-        if (!log_inited) { openlog(ident, LOG_CONS, LOG_DAEMON); log_inited++; }
+        if (!log_inited) { openlog(ident, LOG_CONS, LOG_LOCAL4); log_inited++; }

 #if APPLE_OSX_mDNSResponder && LogTimeStamps
         if (ident && ident[0] && mDNSPlatformClockDivisor)

 
openlog() のオプションで LOG_DAEMON と書かれているので syslog.conf では daemon.none を設定すれば良いような気がしないでも無いですが LOG_DAEMON なプライオリティは他のアプリケーションもドカドカと利用しているような気がするので、今回は LOG_LOCAL4 に変更してみます。

上記パッチは net/mDNSResponder/files/ の中に patch-mDNSShared-PlatformCommon.c としてほーり込むと ports の make 時に毎回有効になるかと思われます。自分の好みでどうにかしてください。

また、僕は LOG_LOCAL4 にしましたが、自分の都合のようプライオリティに変更しても良いのではないかと思われます。

あとは make して deinstall して reinstall 、そしてデーモンを再起動すると全ては完了です。 /etc/syslog.conf に指定した情報の通り、 /var/log/messages 以外のファイルに蓄積されるようになるかと思われます。

 
mDNSResponder と mdnsd は非常に良いのですが、出力されるログが非常に気になるのですが、これで問題解決;-)。

ports の Makefile 自体を改修して make config でログのプライオリティを変更するようにもできるなぁ;-)。
機会があれば書いてみよう;-)。

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 のコンパイルが通らない人用のてっぷすでした;-)。

9月 302015
 

僕は VMWare ESXi 5.1 上で何個かの FreeBSD/amd64 を動かしているのですが、 9.2-R -> 10.0-R -> 10.1-R と来て、今回いよいよ 10.2-R にしてみました。

しかし、 10.2-RELEASE にした途端 powerd が動かなくなりました。あれ? 9.2-R から 10.1-R まで利用しているときには powerd が動いていて sysctl の dev.cpu.0.freq や dev.cpu.0.freq_levels が見えていたのですが、 10.2-R にした途端に見えなくなりました。おかげで powerd を起動すると以下のような感じ。

# service powerd start
Starting powerd.
powerd: no cpufreq(4) support -- aborting: No such file or directory
/etc/rc.d/powerd: WARNING: failed to start powerd

 
cpufreq.ko はロードしているのに有効になっていないようですね。あたたた。

そもそもハイパーバイザの上で動作する OS では cpufreq は見えないんじゃね? という話があります。例えばさくらの VPS では、その上で動く FreeBSD は powerd は動かないし Virtualbox 上の FreeBSD でも powerd が動かない。 dev.cpu.0.freq_levels が無いからですね。

しかし、 VMWare ESXi ではその上で動作する FreeBSD で cpufreq.ko が有効になって dev.cpu.0.freq_levels が生えてきて powerd が動作します。

powerd が動かないと CPU が最速でブン回って地球に優しくないよねぇ。などと思うので何とかしたいのであります。

 
で、色々調べたり、人に聞いた話だと FreeBSD 10.2-RELEASE ではとあるパラメータが追加になって、物理マシンではない場合には default で disable になったようです。なのでそのパラメータを変更して上げると以前のようになるらしいです。

/boot/loader.conf に以下の行を追加して上げると 10.2-R は 10.1-R の頃のように cpufreq.ko が有効になり dev.cpu.0.freq_levels が生えてきて powerd が動くようになります。

hint.acpi_throttle.0.disabled="0"
hint.p4tcc.0.disabled="0"

 
/boot/device.hints の最後に上記の行が追加になってますね。それも “1” で。これを “0” にすると cpufreq.ko が利用可能な状態になってくれます。

この設定が有効なのは今のところ VMWare ESXi のみのようです。実機では必要ありません。実機では default の設定でも cpufreq.ko が有効になります。
また、上記設定を書いても KVM や Virtualbox では dev.cpu.0.freq_levels が無いままだと思われます。

 
参考になる URL としては https://svnweb.freebsd.org/base?view=revision&revision=276986 を見るのが良いかと思われます。

それにしても VMWare ESXi (僕は 5.1 を利用) で FreeBSD を動かしていたけど 10.2-R にしてから powerd が動かなくなったとお嘆きの方は上記の行を /boot/loader.conf に書いてみることをおすすめします。

 
2015/10/04 加筆
上記の設定は VMWare ESXi のときのみの設定ではなく、物理マシンにおいても有効のようです。 10.2.-RELEASE では default で 1 なので、とりあえず powerd をどうにかしたいとか、 dev.cpu.0.freq_levels で表示される数を増やしたいなどあったら上記の設定を入れて試してみるのも一つの手でアルと思われます。

8月 302015
 

と、いうことで、ちょっと前に掲載した「FreeBSD/arm のクロスコンパイル環境をもっと簡単に作る。」では ports のクロスコンパイル環境が整ったので、早速 X と xfce4 のコンパイルに挑んでみました。

Raspberry Pi 2 で X を動かすためにインストールした主なものは以下の通り。あ。 ports の枝番は削っています。

・xorg-7.7
・xfce-4.12
・emacs24-24.5
・zh-fcitx-4.2.8.6
・ibus-1.5.9
・ja-mozc-server-2.17.2106.102

X はウィンドマネージャも含めてフルスペックで、更に日本語入力もできないとダメだよね。と、いうことで ibus と fcitx と mozc までコンパイルしました。あと、xfce4 は Thunar をインストールし、デスクトップに必要なマルチメディア系のアプリまでインストールしています。
コンパイルした ports の総数は 大体 490 個くらいっ!! 自分でいうのもなんだけど、すげーすげー;-)。

ちなみに FreeBSD/arm は 8GB の MicroSD に Xorg と xfce4 をインストールして / パーティションは約 30% ほど消費しています。

クロスコンパイル環境では portmaster -D -a も動作するのでバージョンアップにも対応しています。コンパイルしたバイナリは以下の URL にあるので良かったら持って行ってください。

http://distfiles.icmpv6.org/packages/All.armv6/
ftp://ftp.icmpv6.org/packages/All.armv6/

今後、 ports-CURRENT を追いかけて行って portmaster -D -a してバージョンアップしたものもどんどん追加していく予定です。

 
さてと。先に ports/packages の内容を書いてみましたが、実際にクロスコンパイル環境でコンパイルしたので、そのことについてちょっと書いてみます。

 
1). クロスコンパイル環境の準備
以前のエントリで ports の ports-mgmt/poudriere-devel/ を試したと書いているのですが、そのとき

# poudriere jail -c -j CURRENT-armv6 -m svn -a arm.armv6 -v head

 
を実行したので FreeBSD/arm CURRENT の jail 環境ができてしまいました。これを tar で固めて、最速の仮想マシン上に持って行ってクロスコンパイル環境を構築しました。FreeBSD/amd64 10.1-RELEASE-p16 の環境に tar で固めた FreeBSD/arm 環境を展開し、前回記載した chroot 用スクリプトで環境を整えて、実際に ports の make install を行いました。

母艦の FreeBSD/amd64 10.1-RELEASE-p16 上に qemu をインストールして FreeBSD/arm CURRENT に chroot します。 /usr/ports は母艦側のディレクトリを mount_nullfs して利用し、ひたすら make という、以前書いたのを実際にやってみた。と、いうことですね。

環境の作り方は前回のエントリを参考にしてください。

 
2). chroot はネットワークが使えない
chroot した FreeBSD/arm の環境で ports を make しようとしても make fetch でエラーになりソースコードを取りに行ってくれません。
chroot した状態で ifconfig -a とか打つと解りますが qemu が Qemu unsupported ioctl などというメッセージを出します。と、いうことで chroot した環境ではネットワークは使えないと認識したほうが良いでしょう。

では、ports のソースコードはどうやって取りに行くかというと、母艦側で揃えるしかありません。そもそも /usr/ports/ は母艦側のディレクトリを FreeBSD/arm のディレクトリに mount_nullfs しているので見ているところは一緒です。

母艦側でコンパイルしたい ports で以下のコマンドを打ちます。以下は editors/emacs/ のコンパイルの例です。

# cd /usr/ports/editors/emacs
# make fetch-recursive

 
ports のコンパイルのオプションには fetch-recursive というのがあるんですね。依存関係でインストールされる ports も含めてソースコードをダウンロードして来てくれます。 make config-recursive ってのは依存関係にある全ての ports の make config を実行しますが、それと似たようなモノですね。それにしても嬉しい make のオプションです。

母艦側でソースコードがゲットできたら FreeBSD/arm 側で実際に ports の make に入ります。
以前のエントリでも書きましたが遅いのでひたすら待ちましょう・・。

 
2). クロスコンパイル環境でコンパイルできないモノがある
いやー。さすがに 490 個くらいコンパイルすると qemu+chroot の環境でコンパイルが通らない ports が何個かありました。以下はそのリストです。

・emacs-nox11-24.5,3
・emacs24-24.5_1,3
・jsoncpp-0.6.0.r2_2
・py27-cairo-1.10.0_2
・tdb-1.3.4,1
・talloc-2.1.2
・tevent-0.9.24
・ja-mozc-server-2.17.2106.102

有名どころでは emacs ・ mozc 辺りでしょうか。 samba 辺りで利用される t シリーズ(tdb ・ talloc ・ tevent)も make が通りませんでした。

原因としては chroot 下で動作している qemu が make の実行時に core dump してしまいます。なのでクロスコンパイル環境では make が通りませんでした。

上記の ports の場合、実機 (Raspberry Pi 2 上の FreeBSD/arm) では make が通ったので、実機で作成した packages をクロスコンパイル環境に pkg add してあげて make を続行します。

 
クロスコンパイル環境で make が通らなくても実機でコンパイルが完走すれば良いのですが、実機でもコンパイルが通らないものがありました。
lang/spidermonkey170 です。これは困った。 FreeBSD の ML でも話題に上がっているようです。

FreeBSD/amd64 では問題なくコンパイルが通るのに FreeBSD/arm では通らない。なんでやねん?! と、いうことで試行錯誤を重ねた結果 FreeBSD/arm でむりくりコンパイルを通しました。

以下、手順です。

o. FreeBSD/arm 側で以下のコマンドを実行

# cd /usr/ports/lang/spidermonkey170
# make configure

 
o. 母艦側で続けて実行

# cd /usr/ports/lang/spidermonkey170/work/mozjs17.0.0/js/src
# gmake clean
# configure

 
FreeBSD/arm で実行した make configure の結果を母艦側で全てぶっ飛ばしてソースに対して FreeBSD/amd64 側で configure を実行します;-)。
その後 FreeBSD/arm 側に戻って make install を実行すると無事に make が通ります。これで ports 自体はインストールできるので、まぁヨシとしておきましょう;-)。

あ。僕は mozjs17.0.0 ってのはどこで利用されているのか知らないので実際に正しい動作をしているのか、よく判りませんf(^^;;。

関連性でインストールされるので必要だからとりあえず ports でコンパイルを通すワザを発見した。と、いう感じですf(^^;;。

 
と、ここまで書いたと、いうか、コンパイルを通したのですが、その後、原因が判明したようですね。どうやら llvm のバグで ARM の場合に発生するようです。

FreeBSD では gcc を使うようにするとコンパイルが通るようですね。

再度書きますが、僕の make の方法は ports の関連性に必要な他のプログラムのコンパイルを進ませるためにむりくりの方法を編み出した。と、いうことにしておいてくださいf(^^;;。

http://comments.gmane.org/gmane.os.freebsd.devel.cvs.ports/349757

ちゅーこって FreeBSD/arm 用に gcc-4.8.5 を make しないと・・。 orz

 
とまぁ、こんな感じで地道に qemu+chroot の環境で ports をじっくりと make していきます。 490 個程度の ports をコンパイルするのに、途中で make fetch やコンパイルエラーで止まることもあるので、大体一週間程度でしょうかねぇ。 ひたすらがんばります。

 
3). Raspberry Pi 2 で X 起動
一通り packages 化された ports が出来上がったので全てを実機にインストールして実際に X を起動してみます。
今回、僕がチョイスしたバージョンは FreeBSD 11.0-CURRENT r286285 です。このバージョンの CURRENT は HDMI にディスプレーを接続するとフラッシュのようにブラックアウトする場合があるのでちょっと困りもの。 OS と、いうか CURRENT の問題なのか、ハードウェアの問題なのかは良く判りません。
あと、 r286285 は default の root のパスワードが設定してない!! ので シングルユーザに落として /etc/master.passwd の :*: の * を消してあげる必要があります。 orz
ちなみに r286893 では root のパスワードが設定してありました;-)。

 
さてと。気を取り直して ~/.xinitrc に xfce4 を起動するように記述して startx です。

おぉーーっ!!

IMG_2407_RPi2_FreeBSD_X_1

ディスプレーのすぐしたにあるのが Raspberry Pi 2 の FreeBSD で HDMI で表示しております。

xorg.conf のディスプレードライバには scfb を指定します。 ports 的には x11-drivers/xf86-video-scfb をインストールしてあげます。 vesa ではないです。

xfce4-terminal で文字を打つとぬるぬると動いていく感が良いですね。 NoAccel 感満載です;-)。

hald を動かすと USB のキーボード・マウスも無事に動作します。なので X の環境で利用する分には問題は無いですね。あとは細かいところの設定をしていくと xfce4 は無事に動作するようになるのではないでしょうか。

あ。mozc がどうも起動しないんですよね。 core dump する。まだ深くは追ってないのですが、環境整わせつつ、おいおい見ていきたいと思います。

多分 mozc_server を FreeBSD/arm でコンパイルして動かしたのは、僕が世界初ではないかなぁ;-)。

 
と、いうことで今回は ports のクロスコンパイル環境で make したものを利用して Raspberry Pi 2 上の FreeBSD/arm で X まで動かしてみました。

これでバリバリと Raspberry Pi 2 を利用するようになるかな? データセンタに行った時とかに NotePC の代わりに Raspberry Pi 2 を取り出してバリバリ仕事する。とか、良いかも;-)。

 
Raspberry Pi 2 に FreeBSD/arm インストールしたけど ports のコンパイルが大変なので断念している方、 packages を作ったので是非 X が起動するところを見てみてください。ただ、さすがに KDE4 を packages 化しようとは思わないですがf(^^;;。

僕はこのあと、どうしようかなぁ・・。

8月 272015
 

ちょっと前のエントリでiPod mini を復活させたー。ってのを書いたのですが、iPhone6 は大きすぎてダメだぁ。音楽聴くには iPod のほうが良いねぇ。と、いうことになったんですけども。

でもって、その復活した iPod mini も 4GB のディスクから 32GB の SD カードにしたので容量がドドドと増えた。と、いうことですね;-)。

最近は音楽は iPod mini で聞いておりますが iPhone5,6 に付属の EarPods のリモコン機能は iPod mini では利用できないですね。
考えてみると iPod mini は 3.5 インチジャックの横にリモコンコネクタが付いていて、他の機種とは互換が無いのでありました。

と、いうことで、今更ですが Dokc コネクタ用の FiiO E1 を購入しました。別に新規に利用するということはなく、今回が二回目の購入になります。
一回目の購入は iPhone4 用に購入していますね。

当時は 2,980yen で購入した。と、書いていますが、今回は 1,400yen で購入しました。もしかしたら、もう在庫一斉セールになっているのかもしれないですね。最近は Dokc のデバイスも少なくなっていますしね。

IMG_2411_get_FiiOE1_1

しかし、つい最近まで iPod Classic が売っていたので、それを利用している人にとっては Dock コネクタはまだまだ現役ですしねぇ。

今のうちに Dock コネクタ用のパーツを色々買い求めておくのが良いのかもしれません。近いうちにアキバに行って Dock コネクタの車載用 FM トランスミッターも手に入れてくるかなぁ。

うちではまだまだ現役の iPod mini なのであります;-)。

8月 172015
 

前回のエントリは「FreeBSD/arm の ports コンパイル環境の作成。」というヤツを書きました。

ports の ports-mgmt/poudriere-devel/ というのを利用すると FreeBSD/arm のクロスコンパイル環境ができますよ。っていうやつです。

しかし、環境構築が大変すぎる。もっと簡単にできないのか?などと思うわけですね。環境構築に時間が掛かり過ぎる点は以下の辺り。

・FreeBSD のソース一式を svnweb から取ってきて make buildworld する。
・ports ツリー一式を portsnap で取ってきてインストールする。

時間が掛かり過ぎるよー。ってんで、今回はもっとお気楽に環境を構築する案を思いつきました。

ports-mgmt/poudriere-devel/ は jail に FreeBSD/arm のバイナリの環境を構築して qemu でエミュレートして動作しているようです。そのためにソースコード取ってきたり ports ツリー取ってきたりしているんですが、既にあるものを使おう。ってのが今回の趣旨です。

 
1). 準備するモノ
まずは Raspberry Pi 2 に FreeBSD をインストールします。多分 CURRENT が良いのかもしれないです。
Raspberry Pi 2 用の img を用意して SD カードに dd したら、同じバージョンの FreeBSD/amd64 の iso イメージもダウンロードしてきて、仮想環境に FreeBSD/amd64 をインストールします。あ。実機にインストールしても全然良いんですけどね;-)。

僕の場合、は以下のような環境を作りました。

o. Raspberry Pi 2 の FreeBSD/arm

FreeBSD wanchan.running-dog.net 11.0-CURRENT
FreeBSD 11.0-CURRENT #0 r284544: Thu Jun 18 19:36:01 UTC 2015
root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI2  arm

 
o. 仮想環境上の FreeBSD/amd64

FreeBSD nyanchan.running-dog.net 11.0-CURRENT
FreeBSD 11.0-CURRENT #0 r284544: Thu Jun 18 12:24:12 UTC 2015
root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

 
ちなみに、仮想環境上の FreeBSD/amd64 が母艦になります。ここで FreeBSD/arm の ports の make をする予定です。

この後、母艦側で ports の emulators/qemu-user-static/ をインストールします。

これで、ほぼ九割の環境が整いました;-)。

ports-mgmt/poudriere-devel/ とかインストールする必要はありません。 jail 環境用に make buldworld もする必要はありません。

と、いうことでここでだいたいの構成がわかってきたと思いますが;-)。

 
2). 環境構築
まず、 Raspberry Pi 2 側の FreeBSD/arm で nfsd を起動します。

以下は /etc/exports の設定内容。

/   -network 192.168.1.0 -mask 255.255.255.0 -maproot=root
/   -network 2001:470:fe36:1234::/64 -maproot=root

 
強引ですねぇ。 / を NFS mount するようにします;-)。
あ。/etc/rc.conf の設定は今回は書かないです。

 
続いて母艦側の FreeBSD/amd64 側で nfs client を有効にします。こちらも /etc/rc.conf の設定は書かないですが、大丈夫ですね?

あとは母艦側で mount_nfs を実行します。

# mount_nfs -o rw wanchan:/ /home/armv6

 
うひょー。これで ports-mgmt/poudriere-devel/ でいうところの jail 環境ができてしまいました。ちょっと強引ですが。しかし、 make buildworld したのと一緒の状態ですね;-)。

一個、そして一回だけ、以下のコマンドを打ちます。

# cp -pr /usr/local/bin/qemu-arm-static /home/armv6/usr/local/bin/

 
FreeBSD/arm 側の /usr/local/bin/ に FreeBSD/amd64 上でコンパイルした qemu-arm-static をコピーしてあげます。これで準備は全て整いました。

 
まぁ、FreeBSD/arm の環境一式は色々抜き出すことができます。例えばインストールの iso イメージを mount して抜き出すとか、 ports-mgmt/poudriere-devel/ をインストールしてできた jail 環境を tar で固めて持ってくるとかですね。

しかし、 make buildworld を走らせるのは辛すぎる・・。ってのが今回の根本にあります。
make buildworld するより OS 二つインストールしたほうが速くないかい? みたいな;-P。

 
3). 環境構築スクリプト
まずは下に起動用のサンプルを書きますね。

#!/bin/sh

HOME=/
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin/:/usr/local/bin
export HOME PATH

export LC_CTYPE=ja_JP.UTF-8
export LANG=ja_JP.UTF-8

ARMV6DIR='/home/armv6'

kldload imgact_binmisc.ko

binmiscctl add armv6 --interpreter "/usr/local/bin/qemu-arm-static" --magic "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00" --mask "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff" --size 20 --set-enabled

mount_nullfs -o rw /usr/ports ${ARMV6DIR}/usr/ports
#mount -t devfs devfs ${ARMV6DIR}/dev

chroot ${AMD64DIR}

 
解る人は何をしているか解ると思います。

jail 環境作るの大変なので直接 Raspberry Pi 2 の FreeBSD/arm の環境を利用してしまいます。
そして chroot しています。 jexec でなくとも chroot で十分なのでそうしているんですが。

ちと説明をすると、

kldload は自動的にしてくれると思います。

binmiscctl add armv6 の行は qemu を使うおまじないです。このコマンドを叩かないと chroot したときに /bin/tcsh えぐぜっくふぉーまっとえらー。とか言われます。

FreeBSD/arm 側に母艦の /usr/ports を mountしてあげます。これで portsnap で ports ツリー一式取ってくる必要がなくなります;-)。

mount -t devfs は多分必要ないと思います。 jail 環境の場合は必要なのですが、今回は nfs mount した環境なのですねぇ。

と、いうことで最後に chroot します。

うひひ。これで FreeBSD/amd64 上に FreeBSD/arm の環境が整いました。ports のコンパイルや(多分)カーネルのコンパイルなど、もう何でもできます;-)。

このスクリプトは別途置いといたのでダウンロードしてください。ブログだと binmiscctl add armv6 の行が全部表示できないので・・。

 
ちなみに FreeBSD/arm 側が CURRENT で母艦側が 10.1-RELEASE だったりすると ports のコンパイル時に uname -r のチェックでエラーになってしまいます。 chroot した FreeBSD/arm 側で uname -r すると母艦側のバージョン情報を返してしまいます。あたたた。なので、 FreeBSD/arm 側と母艦側では FreeBSD のバージョンを揃える必要があります。

が、uname には裏ワザがあるようで、

$ uname -r
10.1-RELEASE-p16
$ setenv UNAME_r 11.0-CURRENT
$ uname -r
11.0-CURRENT
$

 
おやおや。環境変数で uname -r が変更できるのね。と、いうこで母艦が 10.1-RELEASE-p16 で FreeBSD/arm 側は 11-CURRENT の状態で ports を make してみましたが ports のコンパイルが始まって configure の実行中に「存在しないシステムコール (core dumped)」などと言われてコンパイルが途中で止まってしまうのでありました。

ふむ。10.1-RELEASE から 11-CURRENT で機能が追加された分があったりして、その辺りが問題となってしまうのでしょうなぁ・・。まぁ、取り合えずはこの環境で利用するのはやめて、母艦側も FreeBSD/arm 側もバージョンは揃えた。と、いうことになります。

 
2015/08/18 加筆
母艦側の FreeBSD/amd64 と FreeBSD/arm 側でバージョンが違っていてもコンパイルできることが解りました。 母艦側の /usr/local/bin/qemu-arm-static と FreeBSD/arm 側のヤツを同じモノにすると無事に動作します。
母艦側の /usr/local/bin/qemu-arm-static は 10.1-RELEASE-p16 で make したモノ、 FreeBSD/arm 側のヤツは 11.0-CURRENT で make したモノ。と、いうふうに異なるバージョンで make したものがインストールされていると「存在しないシステムコール (core dumped)」と出て動作しません。
/usr/local/bin/qemu-arm-static は母艦側で make したものを FreeBSD/arm 側に cp してあげましょう。

 
4). 実際に使ってみると
ports の make は一応問題無しですね。母艦側で make install したやつは FreeBSD/arm で pkg info で見るとちゃんと見えます。 portmaster -D -a も無事に動きます。

しかし、遅い・・。今回の母艦側仮想マシンは CPU 4Core に 1GB のメモリを用意したのですが遅いです。
FreeBSD/arm を NFS しているし SD カード上に入っているのでディスクアクセスが遅いのかもしれません。

それにしても chroot した先で色々動かすと全て qemu がワンクッション入るのでそれが遅いのかもしれません。僕はまだ本格的に qemu を使ったことが無いのでアレですが、パフォーマンスチューニングすればもっと速くなるのかな?

28468 1 I  0:01.76 /usr/local/bin/qemu-arm-static /bin/tcsh -i
28672 1 S+ 0:00.83 qemu-arm-static -L /usr/gnemul/qemu-arm /usr/bin/make install
28689 1 R+ 0:00.48 qemu-arm-static -L /usr/gnemul/qemu-arm /usr/bin/make config

 
母艦側で ps -ax するとこんな感じで chroot 先の全てのプロセスが qemu 経由で動いております。

 
母艦側で ports のコンパイルとかすると、遅いけど律儀に進んでいきます。そのとき FreeBSD/arm 側では CPU ロードアベレージは低いままなので、頑張っているのは母艦側。と、いうことになり、遅いけど Raspberry Pi 2 は無傷な状態ですね。

 
とまぁ、こんな感じの FreeBSD/arm のクロスコンパイル環境なのですが、それにしても qemu が絡むと遅くてしょうがない(と、僕は思っているんだけど、本当に qemu が原因なのか、僕はまだ特定していません・・f(^^;;)。

その昔、 Linux で BB ルータ作っていたんですが、組み込み Linux の ARM のバイナリを i386 の Linux 母艦で作っていたときは qemu 使ってなくて、もっとサクサクとコンパイルができていたんだけど・・。
qemu を使わずに ports をコンパイルする方法をやっぱり見つけないとダメっぽい。ってのが、今回の結論でしょうかねぇ。

それにしても ports-mgmt/poudriere-devel/ で色々仕掛けが解ったので良かったです。そして、それを参考にして ports-mgmt/poudriere-devel/ を使わない、もっと楽したコンパイル環境構築がこうして解ったわけですしね。ネタになったかぁ? ;-)。

次回、qemu を使わない ports のコンパイル環境の構築について掲載できるか?! (多分無理;-)

実は某所で発表した FreeBSD/arm に関する資料があるのですが ports のコンパイル環境構築についても触れています。その時は qemu を使わずに頑張ったのですが、結局ダメでした。その資料を一応おいておきますね。

FreeBSD/arm Raspberry Pi 2 ModelB で動作確認

 
ちなみに文章は Microsoft Office2013 で作りましたが、資料の発表は okular (KDE 4 universal document viewer) で行いました。 calligrastage (KDE graphic art and office suite) では文章を作成するのに苦痛でして・・f(^^;;。
そして、okular は pptx をサクっと開けてしまうすぐれものです;-)。

8月 152015
 

ちょっと前に Raspberry Pi 2 を購入して、FreeBSD を動かした「Raspberry Pi2 で FreeBSD。」と、いうエントリを書きましたが、 FreeBSD/arm が動いておしまい。 ports のコンパイルは大変だぁ。などと書いていますが FreeBSD/amd64 で ports のクロスコンパイル環境が整ったのでちょっと書いてみたいと思います。

英語の文章はあちこちにあるようですね。あと、日本語のウェブもちらほらあるようです。

今回参考にさせてもらったのは以下の二つのサイトです。

http://www.textplain.net/tutorials/2015/cross-compiling-freebsd-ports-for-the-beaglebone-black/
http://www.dvatp.com/tech/armv6_freebsd_poudriere

このサイトを日本語化した。と、いうような感じでしょうかねf(^^;;。

で、結論から先に申しますと『クロスコンパイル環境で ports をコンパイルしても遅いよね。』ですX-(。 と、いうことで、ここから始まりです。

 
1). ports のインストール
母艦は FreeBSD/amd64 10.1-RELEASE です。ここに FreeBSD/arm CURRENT の ports コンパイル環境を構築します。カーネルの構築はしません。カーネルはブートイメージを利用します。

と、いうことで FreeBSD/amd64 や FreeBSD/i386 上で FreeBSD/arm の ports をコンパイルする環境を構築するには ports が用意されているんですね。それを利用します。

ports 的には ports-mgmt/poudriere-devel/ というのを利用します。こいつを make install すれば環境が整います;-)。ただ make config のオプションでは QEMNU を [X] する必要があります。
poudriere は jail と qemu の連合軍で FreeBSD/arm の packages を作るんですな。

無事にインストールできれば準備は完了。

 
2). poudriere の環境設定
ports から ports-mgmt/poudriere-devel/ をインストールしたら準備完了というのは大きな間違いでして、ここから長い道のりが待っております。orz
まず poudriere の設定フアイルとして /usr/local/etc/poudriere.conf というフアイルを用意してあげます。以下は僕が用意したそのファイルの中身です。

ZPOOL=zroot
ZROOTFS=/poudriere
FREEBSD_HOST=ftp://ftp2.jp.FreeBSD.org/pub/FreeBSD/
BASEFS=/usr/local/poudriere
SVN_HOST=svnweb.icmpv6.org
POUDRIERE_DATA=${BASEFS}/data
NOLINUX=yes
USE_COLORS=yes
PRESERVE_TIMESTAMP=yes
BUILDER_HOSTNAME=build
DISTFILES_CACHE=/usr/ports/distfiles

 
BASEFS= は環境を構築するディレクトリ。
SVN_HOST= は svnweb を指定します。おーーっとっ!! ここで登場だぁ;-)。
DISTFILES_CACHE= は ports のソース置き場ですね。

こんな感じでしょうか。

一個前のエントリで「svn:// に対応しました。」と、いうのを書いているのですが、 poudriere はソースコードを取りに行く時に port 3690 にアクセスします。 http:// で用意した svnweb にアクセスするとエラーになるんですね。なので、今回、僕は svnweb.icmpv6.org を svn:// 対応にした。と、いうことなんですけどもね。

と、いうことで config ファイルの準備が整いました。

 
3). qemu の設定と poudriere の実行
poudriere は qemu を利用しているので、先に qemu の設定を行います。

以下の呪文のようなコマンドを打つようです。あー。コマンドが突き抜けてしまっていますねf(^^;;。マウスでつかんだときに –set-enabled がついていれば OK 一番最後のオプションです。
このコマンドは QEMU に対するコマンドで、色々やるときに qemu-arm-static が呼ばれるようになります。

# binmiscctl add armv6 --interpreter "/usr/local/bin/qemu-arm-static" --magic "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00" --mask "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff" --size 20 --set-enabled

 
これで準備は完了。続いて poudriere なコマンドを打ちます。

# poudriere jail -c -j CURRENT-armv6 -m svn -a arm.armv6 -v head

 
poudriere は合わせて jail 環境も構築するのですが、その時 CURRENT-armv6 が生成されます。任意の文字列で問題はありません。
アーキテクチャは arm.armv6 で、今回は CURRENT の環境を構築するので -v で head を指定しました。
10.1-RELEASE の環境を作りたい場合には release/10.1.0 とか指定します。 http://svnweb.icmpv6.org/base/release/ 配下にあるヤツを -v で指定します。 stable/10 とかでも良いと思います。

で、このコマンドを実行すると、なんとっ!! svnweb からソースコードを svn co して来ます。そして make buildworld が走りますっ!! 半日くらい放っときましょうかねf(^^;;。

あ。コンパイルが完了したファイルは母艦側の /usr/obj/arm.armv6/ に一式 obj ファイルが生成されます。

 
4). ports 環境の準備
上のコマンドが走っている最中でも ports の環境は生成できます。並行してやっても良いかも知れないですがディスクアクセスが大変なことになっているかも・・。仮想マシン上であると随分と遅くなります。

ports 環境を生成するためには以下のコマンドを打ちます。

# poudriere ports -c

 
こいつもまた冗長ぎみで、 portsnap とか動いて ports の環境一式持ってきて差分比較して展開するというだいそれたことをしてくれます。 orz
僕的には素直に母艦の /usr/ports を symlink もしくは mount_nullfs すれば済むじゃないかっ!! と思うんですけどもね。
けど、それをやってこの工程を省くと /usr/local/etc/poudriere.d/ports/default/mnt がねーぞ。ぼけっ!! などと怒られるのであります。 orz

と、いうことで、これで ports の環境が整いました。ここまででシーケンシャルにやると大体八時間位かかりますかねぇ。ひたすら待つことになります。

 
4). さて。いよいよ ports のコンパイルだっ!!
準備が整ったのでいよいよ ports の make をします。コマンドは二つ。

まずは make config に相当するコマンドになります。

# poudriere options -j CURRENT-armv6 dns/libidn

 
-j で jail の環境を指定します。その次にコンパイルしたい ports を指定します。今回は dns/libidn/ をコンパイルする予定です。
上記で make config 相当がはしります。あ。正確に言うと make config-recursive が走ります。関連性でインストールされる ports の全ての make config が走ってくれます。
続いていよいよコンパイル。

# poudriere bulk -j CURRENT-1armv6 dns/libidn
[00:00:00] ====>> Creating the reference jail... done
[00:01:04] ====>> Warning: !!! Jail is newer than host. (Jail: 1100078, Host: 1100077) !!!
[00:01:04] ====>> Warning: This is not supported.
[00:01:04] ====>> Warning: Host kernel must be same or newer than jail.
[00:01:04] ====>> Warning: Expect build failures.
[00:01:05] ====>> Mounting system devices for CURRENT-armv6-default
[00:01:05] ====>> Mounting ports/packages/distfiles
[00:01:05] ====>> Stashing existing package repository
[00:01:05] ====>> Mounting packages from: /usr/local/poudriere/data/packages/CURRENT-armv6-default
[00:01:05] ====>> Copying /var/db/ports from: /usr/local/etc/poudriere.d/CURRENT-armv6-options
[00:01:06] ====>> Raising MAX_EXECUTION_TIME and NOHANG_TIME for QEMU
[00:01:06] ====>> Starting jail CURRENT-armv6-default
[00:01:17] ====>> Logs: /usr/local/poudriere/data/logs/bulk/CURRENT-armv6-default/2015-08-14_12h50m22s
        :

 
こんな感じで始まります。

がっ!! しっかしっ!! 遅いっ!! japanese/nkf とかコンパイルしても全然遅い。ヘタしたら FreeBSD/arm 上で make install したほうが速いんじゃね?と思えるくらい遅くてうんざりです。 orz

あと、 DISTFILES_CACHE=/usr/ports/distfiles を指定しているんだけど、この中に無いヤツは勝手に取ってきてくれないようで、事前に入れておく必要があったりします。

思いの外使えない状態かなぁ・・。

 
5). 環境についての説明
poudriere は設定フアイルとして /usr/local/etc/poudriere.conf と /usr/local/etc/poudriere.d/ を利用します。 /usr/local/etc/poudriere.d/ のほうは下を覗くと色々あります。 jail 環境を作り直したい場合には jails/ ディレクトリをサクっと rm すれば良いです。あ。これはイリーガルなやり方で、上記の URL では以下のコマンドを打て。と、書いてありますね;-)。

# binmiscctl remove armv6

 
僕はこのコマンドは打ったことないです;-)。

 
実際にできた ports ですが、設定ファイルで指定した BASEFS=/usr/local/poudriere の中にできます。
/usr/local/poudriere/data/packages/CURRENT-armv6-default/.building/All/ の中とかですね。途中のディレクトリに All@ とか symlink されたものがあり、その中を見ても良いかと思われます。

poudriere ports -c で生成した ports ツリーは /usr/local/poudriere/ports/default/ にあります。僕は portsnap とか使ったことないので、このディレクトリで svn co 叩いても良いかと思われます。

# cd /usr/local/poudriere/ports/default/
# svn co http://svnweb.icmpv6.org/ports/head ./

 
これでいつも最新の ports-CURRENT が手に入る。しかし、その分コンパイルしないとダメですけどね・・。

 
5). ports 一括コンパイル
最後にですが、必要な ports 一括コンパイルの方法を書いておきます。

まず、ports の一覧が書かれているファイルを用意します。仮に /root/pkglist.txt としておきましょうかねぇ。

japanese/nkf
games/sl
misc/lv
japanese/w3m
editors/emacs-nox11

 
自分の FreeBSD/arm で動かしたい ports をドドドとリスト化すると良いですね。

その後まずは make config-recursive に相当する以下のコマンドを実行します。

# poudriere options -j CURRENT-armv6 -cf /root/pkglist.txt

 
上にも書きましたが、関連性を含めて make config を実行してくれます。それにしても /etc/make.config に相当する指定はできないのかなぁ? jail の中に用意すればよいのかな?

続いて make します。

# poudriere bulk -j CURRENT-armv6 -cf pkglist.txt

 
あとは時間が掛かるので寝てしまい、うまくいけば朝には完成している。と、いう感じでしょうか。

 
とまぁ、こんな感じで FreeBSD/amd64 上で FreeBSD/arm-CURRENT の ports が packages として構築できると思います。

それにしても遅いのでどうしようか悩み中なのですけど・・。

皆さんも時間があったら試してみてください。