ArchLinux のリポジトリを akabei で楽に管理する

Arch のパッケージのリポジトリを作る 発展編 - eagletmt's blog で書いた内容を自動化するために akabei を作った。 さらに S3 の Static Website Hosting を利用する機能も実装して、実際に http://arch.wanko.cc/ を運用してみている。

基本機能

build サブコマンド

akabei build foo --repo-dir repo/x86_64 --repo-name bar --arch x86_64 で、foo/PKGBUILD をもとに repo/x86_64 以下に x86_64 向けのパッケージと、bar リポジトリの ABS tarball とデータベースとファイルリストが生成される。

% akabei build foo --repo-dir repo/x86_64 --repo-name bar --arch x86_64
(snip)
% ls repo/x86_64
bar.abs.tar.gz  bar.db  bar.files  foo-1.0.0-1-x86_64.pkg.tar.xz

さらに --repo-key や --package-key を指定すると、指定した鍵で署名を行う。署名を行うときは gpg-agent を立ち上げておくと楽。

ビルド時の chroot はデフォルトで毎回最初から作り直す。Arch で破壊的変更があったりすると chroot 環境をメンテするのがめんどくさいので、毎回作り直してもいいと思った。--chroot-dir オプションで既にある chroot を指定して使わせることもできる。

他にも --pacman-config、--makepkg-config、--logdest、--srcdest 等のオプションを指定できて、詳しくは akabei help build を参照。

その他のサブコマンド

また、ABS tarball やデータベースやファイルリストを扱うための abs-add、abs-remove、repo-add、repo-remove、files-add、files-remove といったサブコマンドがある。 {repo,files}-{add,remove} は既存の repo-add(8) と同じ機能だけど、余計なファイル出力や symlink が無いのが特徴。

Omakase mode

普通にリポジトリを運用するときに行う操作を自動化した Omakase mode がある。

最初に、akabei omakase init で設定ファイルを生成する。

% akabei omakase init foo --repo-key $GPGKEY --package-key $GPGKEY
      create  .akabei.yml
      create  foo
      create  sources
      create  logs
      create  PKGBUILDs
      create  etc
      create  etc/makepkg.i686.conf
      create  etc/pacman.i686.conf
      create  etc/makepkg.x86_64.conf
      create  etc/pacman.x86_64.conf
Edit etc/makepkg.*.conf and set PACKAGER first!
% echo 'PACKAGER="John Doe <john@doe.com>"' >> etc/makepkg.i686.conf
% echo 'PACKAGER="John Doe <john@doe.com>"' >> etc/makepkg.x86_64.conf

パッケージを追加するときは、PKGBUILDs/$pkgname というディレクトリを作ってその中に PKGBUILD を置き、akabei omakase build $pkgname とする。 するといいかんじに i686/x86_64 用のパッケージが作られ、ABS tarball、データベース、ファイルリストが更新される。 ビルド時にダウンロードしたソースやビルドのログも、それぞれ source ディレクトリと logs ディレクトリに作られる。

% akabei omakase build bar
(snip)
% tree foo
foo
`-- os
    |-- i686
    |   |-- bar-1.0.0-1-i686.pkg.tar.xz
    |   |-- bar-1.0.0-1-i686.pkg.tar.xz.sig
    |   |-- foo.abs.tar.gz
    |   |-- foo.db
    |   |-- foo.db.sig
    |   `-- foo.files
    `-- x86_64
        |-- bar-1.0.0-1-x86_64.pkg.tar.xz
        |-- bar-1.0.0-1-x86_64.pkg.tar.xz.sig
        |-- foo.abs.tar.gz
        |-- foo.db
        |-- foo.db.sig
        `-- foo.files

そして、この foo ディレクトリを Apache なり nginx なりで公開する。

パッケージを更新するときも、PKGBUILD を更新してから同じように akabei omakase build $pkgname とすればいい。 このとき、古いパッケージファイルは消されずに残る。 これは意図的にそうしている (けど、古いパッケージを消すオプションもあってもいいかもしれない)。

パッケージを削除するときは akabei omakase remove $pkgname とする。 ただし、これによって消されるのは ABS tarball、データベース、ファイルリスト内のエントリであり、パッケージファイル自体は消されずに残る。

Omakase mode with S3

これは完全に自分の都合で追加した。 S3 上にリポジトリを作るのは便利で楽だと思っていて、実際に http://arch.wanko.cc/ ではそうしてる。

akabei omakase init --s3 とすると S3 の設定を含む .akabei.yml が生成されて、.akabei.yml に S3 用のアクセスキーを設定すれば、あとは同じように akabei omakase build $pkgname でビルドして公開できる。

Arch のパッケージのリポジトリを作る 発展編

基本編は http://eagletmt.hateblo.jp/entry/2012/12/21/214507 。 基本編で紹介した方法だけでもリポジトリとしての機能を果たせるディレクトリ構成を作れるが、 公式リポジトリと比較して足りないものが3つある。

1. 署名
2. pkgfile 用のデータベース
3. abs 用の tarball

実際にこれらを追加したリポジトリが http://arch.wanko.cc/vim-latest/ にある。

署名をつける

pacman 4 にメジャーバージョンアップしてから、パッケージとデータベースに署名をつけられるようになった。 2012-06-04 の時点ですべての公式リポジトリのパッケージに署名がつけられ、デフォルトで署名のチェックを強制するようになっている (Arch Linux - News: Having pacman verify packages)。 独自リポジトリでも署名のチェックを強制するには /etc/pacman.conf で SigLevel = Required に設定すればいい。

署名するにはもちろん GPG の鍵が必要なので、最初に用意しておく。自分は以下のサイトを参考にした。

• https://sites.google.com/site/kspjapanese/create-gpgkey
• https://wiki.archlinux.org/index.php/GnuPG

以下の説明では、署名する鍵として実際の自分の鍵である C48DBD97 を用いる。

パッケージに署名をつける

単純に makepkg で作る場合は、/etc/makepkg.conf で GPGKEY を設定して BUILDENV の !sign を sign に変更すればいい。

BUILDENV=(fakeroot !distcc color !ccache check sign)

GPGKEY="C48DBD97"

ただし、基本編に書いたようにきちんとパッケージを作るには makechrootpkg を利用して chroot 環境で作成したほうがいい。 chroot 環境から自分の GPG 鍵は見えないので、makechrootpkg でパッケージを作った後に gpg コマンドで普通に署名を追加するしかない (たぶん)。

例えば vim-latest というパッケージを作る場合、

sudo makechrootpkg -cur ~/chroot-x86_64
gpg --detach-sign -u C48DBD97 vim-latest-7.4.141-1-x86_64.pkg.tar.xz

とする。 あとはパッケージと同じディレクトリに .sig ファイルも置いて公開するだけでいい。

データベースに署名をつける

ついでにデータベースにも署名する。 これは --sign --key C48DBD97 というオプションをつけて repo-add すればいい。 さらに --verify というオプションをつけると、現在のデータベースの署名をチェックしてから新たな署名を生成する。 独自リポジトリを更新していくときは常に --verify をつけておいたほうがいいだろう。

例えば vim-latest というリポジトリの場合、

repo-add --sign --key C48DBD97 --verify vim-latest.db.tar.gz vim-latest-7.4.141-1-x86_64.pkg.tar.xz

とする。 すると vim-latest.db.tar.gz.sig も生成されるので、それぞれ vim-latest.db と vim-latest.db.sig という名前で公開する。

pkgfile 用のデータベースを作る

pkgfile を使うと、あるコマンドやファイルがどのパッケージについているか調べることができる。

% pkgfile -b vim
extra/gvim
extra/vim
vim-latest/vim-latest

この機能は pkgfile -u したときにリポジトリから "#{repo}.files" というデータベースをダウンロードしてくることで達成されている。 この .files というデータベースを作るには repo-add を使う。

repo-add --sign --key C48DBD97 --verify --files vim-latest.files.tar.gz vim-latest-7.4.141-1-x86_64.pkg.tar.xz

これによって生成された vim-latest.files.tar.gz を、 普通のデータベースと同様に vim-latest.files という名前で公開する。 .sig を一緒に公開してもいいけど、pkgfile は特に署名のチェックはしない。 結局、.files はリポジトリのデータベースにファイル一覧をつけただけのファイルなので、リポジトリのデータベースと同様に新たにパッケージを追加する度に repo-add --files して更新する。

abs 用の tarball を作る

これを作っておくと、abs コマンドでソースツリーを保ったり、yaourt -G でソースパッケージを展開したりすることができる。

ただし、これを作るための便利なコマンドというのは用意されていない様子。 なので適当に自分で tarball を作るしかない。

vim-latest/
vim-latest/vim-latest/
vim-latest/vim-latest/PKGBUILD
vim-latest/vim-latest/vim-7.4.035-breakindent.patch

というような構成の tarball を vim-latest.abs.tar.gz という名前でデータベースと同じディレクトリで公開すればいい。

まとめ

最終的に公開するディレクトリの構成はこのようになる。

i686/vim-latest-7.4.141-1-i686.pkg.tar.xz
i686/vim-latest-7.4.141-1-i686.pkg.tar.xz.sig
i686/vim-latest.abs.tar.gz
i686/vim-latest.db
i686/vim-latest.db.sig
i686/vim-latest.files
x86_64/vim-latest-7.4.141-1-x86_64.pkg.tar.xz
x86_64/vim-latest-7.4.141-1-x86_64.pkg.tar.xz.sig
x86_64/vim-latest.abs.tar.gz
x86_64/vim-latest.db
x86_64/vim-latest.db.sig
x86_64/vim-latest.files

2013年の思い出

わりと色んな出来事や変化のある年だったと思う。

ICPC

1月の頭にコーチからメールが転送されてきて、世界大会へ行けることを知った。嬉しさより驚きのほうが上だった。 コンテストの結果は1問も通せなかったという非常に残念なものだったけど、世界大会は楽しかった。

バイト

1月から初めてのバイトを始めた。 大学でイベントのちょっとした手伝いや TA はやったことあったけど、普通(?)のアルバイトは初めてだった。 TA のときも思ったけど、時間を捧げてるとはいえ、これだけでこれくらいのお金が貰えるのかーというのが最初の感想だった。 技術的な新鮮味はあんまり感じなくて、労働とかお金とかについて考えることが多かった。

自分が自由に使えるお金が増えたことで、金銭感覚も多少変わったと思う。 バイト始めて少し経ってから 2TB の WD Red を一気に4個買ったりしてた。 趣味の品について「これ n 時間の労働と同じ価値か」と換算してしまうとだいたい不当に安く感じてしまってよくないので、この考え方はすぐやめるようにした。

電子書籍

最初にラノベを一冊買ってみて iPhone で読んでみたところ普通に読めることがわかったので、そこから一気に Kindle Store でラノベを買うようになった。 バイトへの行き帰りの電車内で読む習慣がついて、高校生のときと同じかそれ以上によく読むようになった。今数えたら去年一年間で45冊くらいだった。 漫画も電子書籍で買うようになった。漫画は iPhone で読むのは正直辛いけど読めないことはなく、漫画による部屋の圧迫と比較して電子書籍を選ぶようになった。

9月から同人誌を中心に本を裁断してスキャンして電子化し始めた。 最初は裁断に対して抵抗あると思っていたけど、いざ始めてみると極一部の同人誌を除いてガンガン裁断してた。 このおかげでだいぶ部屋の有効スペースを取り戻せた。

インターン

5月からの一ヶ月間インターンしてた。 ここでやったことの1つとして bundle install の並列化があって、先日その変更も含む bundler 1.5.1 がリリースされた。 OSS プロジェクトに適当に貢献することは前から個人でやってたけど、給料をもらってその時間で OSS 活動するのは初めてで気持ち良かった。 ここでもメンターの方からは技術的な話より仕事の進め方等について指摘されることが多かった。 計画とか目標の立て方とか、成果のアピールとか。このへんは今も悩んでる。

アニメ

GJ部、アイカツ、ちはやふる2期、あたりが特に最高だった。 あとアニメから入ってプリズマイリヤの漫画を読んだのもよかった。魔法少女いい。

ただ、バイトを始めたせいかアニメを見る時間はだいぶ削られた。 相変わらず録画はしてるけど、消化率は減り続けてると思う。

クレジットカード決済の流れと限度額

急にクレジットカードが一時的に使えなくなったことがこれまでで二度あって、カード会社に問い合わせたところどちらも理由は限度額によるものだった。 しかし、Web 上で確認できる速報の利用明細や自分でつけていた利用記録を確認してみても、限度額に到達しているとは思えなかった。 問い合わせの際に「最終的には利用明細には載らず請求もされないけれど、現時点では限度額の計算に使われているものがある」ということを示唆され、 一体どういうことなのかを知りたくてクレジットカード決済の流れと限度額について適当に調べた。

クレジットカードで決済するときは

1. 与信枠の確保
2. 売上の確定

という2つのステップを踏む。 1 のステップでカード情報や金額をカード会社に送信して、カードの有効性等を確認する。 このとき請求金額が限度額内かどうかも確認し、大丈夫ならその決済用の与信枠を確保する。 限度額の確認は、これまでに確保した与信枠と今回確保する与信枠の合計が限度額内かどうかで判定する。 その後、2 のステップで売上が確定する。 利用明細に載る日付は 2 を行った日である。

実店舗でカードを使ってその場で物を買う場合やダウンロードコンテンツへの課金の場合、1 と 2 がほぼ同時に行われるので気になることは無いけれども、 例えば通販や予約販売で注文と発送のタイミングが異なる場合、注文のタイミングで 1 を行い発送のタイミングで 2 を行うことが多い(?)ので 1 と 2 の間に時間的なズレが生じる。 すると 1 と 2 の間では「与信枠は確保されているけど請求は確定していない」という状態になり、速報の利用明細には載らないけど限度額の計算には使われている、という状態になる。 注文をキャンセルした場合、通常は確保した与信枠のキャンセルも行われるらしいものの、 カード会社によってはキャンセルが反映されるまでに時間がかかるらしい。 また毎月固定の金額を請求するような継続課金のサービスの場合、売上を確定するのは月末が多いものの、取りっぱぐれるリスクを抑えるために月初のほうに与信枠を確保することが多いらしい [要出典]。

したがって、予約 (キャンセル済みであっても) や継続課金によって利用明細と確保された与信枠の間に差が出てくるようだった。 発売日が遠い商品の予約等は請求金額には影響が無いものの、限度額の低い学生にとっては気をつけるべきことだと思った。

RubyGems 2.2 から拡張ライブラリのインストール先が変わったっぽい

ruby 2.1.0-preview2 に同梱されている RubyGems は 2.2 であり、このバージョンから拡張ライブラリのインストール先が変わったっぽい。まだ preview なので正式版でもこのままなのかはわからないけど…

今までは lib/ruby/gems/2.1.0/gems/foo-0.1.0/lib みたいなディレクトリが基点になっていて普通の Ruby のコードと同じ場所に置かれていたけど、RubyGems 2.2 から新たに lib/ruby/gems/2.1.0/extensions というディレクトリができ、lib/ruby/gems/2.1.0/extensions/x86_64-linux/2.1.0-static/foo-0.1.0 のようなディレクトリが基点になる。この変更に関係する pull-request はたぶんこれ https://github.com/rubygems/rubygems/pull/596 。

extensions 以下のディレクトリも自動的に $LOAD_PATH に追加されるので普通は影響がないはずだけど、lib 以下に拡張ライブラリも存在すると仮定した処理を行っている場合は動かなくなってしまう。 実際に msgpack-ruby がこれに該当していて、先週直されてた https://github.com/msgpack/msgpack-ruby/pull/22 。

ScanSnap iX500 を VirtualBox 内の Windows 8 から使う

ScanSnap iX500 と Windows 8 を買った。 サーバ的に使っている Linux マシンの VirtualBox 内に Windows 8 をインストールして、そこから iX500 を使っている。

Linux から全く使えないわけではなくて、sane を使うとスキャンはできる。 現時点で最新のリリース版である 1.0.23 は iX500 の発売より前のリリースなので、当然対応しておらず、HEAD をビルドする必要がある。

• http://www.sane-project.org/cvs.html
• http://www.sane-project.org/snapshots/

ただし、本当に画像としてスキャンができるだけで、サイズを自動的に調節したりカラーと白黒の判別を自動的にしたり OCR をかけて pdf にしたりといったことができないため、俺は勧めない。

なので素直に Windows 8 から使うようにした。ただし VirtualBox 内の。 準備として、まず Oracle Extension Pack をインストールする。これはリモートから VirtualBox のゲストマシンに VRDP で接続するのに必要なため。 また、ホストマシンに差した USB をゲストマシンから使う際にユーザが vboxusers グループに属している必要があるので、これも行っておく。

% yaourt -S virtualbox virtualbox-ext-oracle
# gpasswd -a eagletmt vboxusers

次に仮想マシンを用意する。VirtualBox では VBoxManage でコマンドラインから操作できる。

% VBoxManage createvm --name Win8 --ostype Windows8_64 --register
% VBoxManage modifyvm Win8 --memory 2048 --boot1 dvd --nic1 nat --acpi on --vrde on --usb on --usbehci on --cpus 2 --vram 64
% VBoxManage createhd --filename Win8.vdi --size 40960
% VBoxManage storagectl Win8 --name Win8sata1 --add sata --bootable on
% VBoxManage storageattach Win8 --storagectl Win8sata1 --port 1 --type hdd --medium ~/VirtualBox\ VMs/Win8/Win8.vdi
% VBoxManage storageattach Win8 --storagectl Win8sata1 --port 2 --type dvddrive --medium /tmp/win8.iso

ここでやっていることは、

• Win8 という名前の仮想マシンを作成する
• Win8 という仮想マシンの設定を行う
  • メモリは 2GB
  • ブートの順序の最初は dvd
  • ネットワークアダプタの割り当ては NAT
  • ACPI をサポート
  • VRDP をサポート (リモートから rdesktop-vrdp でゲストマシンに接続できる)
  • USB コントローラを有効化
  • USB 2.0 (EHCI) コントローラを有効化
  • CPU は2つ (最初1コアでやったらスキャンがだいぶ遅れることがあったので)
  • VRAM は 64MB (デフォルトでは足りなかったので適当に増やした)
• Win8.vdi という 40GB のディスクイメージを作成
• Win8sata1 という仮想 SATA コントローラを作成
  • これに Win8.vdi と Windows 8 のインストールディスクを繋げる

というもの。EHCI コントローラを有効にし忘れると、iX500 を接続したのになぜか認識されないということになる。

そして

% VBoxHeadless --startvm Win8

で起動できる。 クライアントからは

% rdesktop-vrdp $REMOTE_IP

で接続できるので、Windows 8 のインストール作業を行う。VirtualBox Guest Additions もインストールしておく。

USB デバイスをゲストマシンに認識させるには、さらに USB デバイスフィルタを設定する必要がある。 まず VirtualBox がちゃんと USB デバイスを認識できてるかどうかを確認する。

% VBoxManage list usbhost
Host USB Devices:

UUID:               0d4dadeb-a48e-4be1-a412-b79b28f1c917
VendorId:           0x04c5 (04C5)
ProductId:          0x132b (132B)
Revision:           1.0 (0100)
Port:               5
USB version/speed:  2/2
Manufacturer:       Fujitsu
Product:            ScanSnap iX500
Address:            sysfs:/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.6//device:/dev/vboxusb/003/006
Current State:      Available

これが表示されないときは、ユーザが vboxusers グループに所属していない可能性がある。 iX500 だけをパスさせるようにするため、vendor id と product id を指定してフィルタを作る。

% VBoxManage usbfilter add 0 --target Win8 --name ScanSnap --vendorid 04C5 --productid 132B

ちなみにこの vendor id と product id は lsusb でも調べられる。

そうしてから Win8 を立ち上げる。すると、usbhost の Current State が Captured に変化するはずである。

% VBoxHeadless --startvm Win8 &
[1] 16562
Oracle VM VirtualBox Headless Interface 4.2.16_OSE
(C) 2008-2013 Oracle Corporation
All rights reserved.

VRDE server is listening on port 3389.

% VBoxManage list usbhost
Host USB Devices:

UUID:               33fd08be-3bab-4280-8545-290ffffe4a8a
VendorId:           0x04c5 (04C5)
ProductId:          0x132b (132B)
Revision:           1.0 (0100)
Port:               5
USB version/speed:  2/2
Manufacturer:       Fujitsu
Product:            ScanSnap iX500
Address:            sysfs:/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.6//device:/dev/vboxusb/003/006
Current State:      Captured

この状態ならゲストマシンから iX500 を認識できているはずなので、iX500 のインストールディスクを VBoxManage storageattach で繋げてインストール作業をすれば使えるようになる。

スキャンしたデータは共有したいので、VirtualBox の共有フォルダ機能を使った。

% VBoxManage sharedfolder add Win8 --name scansnap --hostpath ~/scansnap

ゲストマシンでは \\VBOXSVR\scansnap にスキャンデータを置くようにする。 俺の場合はさらに ~/scansnap をホスト側で NFS で export するようにしている。

こんなかんじで iX500 を使ってますが、それなりに快適です。

参考

• Chapter 7. Remote virtual machines http://www.virtualbox.org/manual/ch07.html
• Chapter 8. VBoxManage http://www.virtualbox.org/manual/ch08.html

neco-ghc で補完時に型情報を表示できるようにした

ghc-mod のほうに補完に使えそうな機能追加があったので久しぶりに neco-ghc を更新した https://github.com/ujihisa/neco-ghc

vimrc で let g:necoghc_enable_detailed_browse = 1 とすると補完時に型情報が表示されるようになる。 ghc-mod 1.11.5 で追加された機能を使っているので、有効化するにはそれ以上のバージョンが必要。

変数だけではなく型クラスや型シノニム等にも表示される。

欠点としては、無効化したときと比べてやや初期化に時間が掛かることが挙げられる。 キャッシュされるので最初さえ我慢できれば従来通り高速に補完候補が表示される。