Ubuntu Weekly Recipe

第487回 ARM向けバックポートパッケージをsbuildでビルドする

この記事を読むのに必要な時間:およそ 10 分

ARM向けバイナリのバックポート

このように公式リポジトリだけで完結するバックポートですが,もちろんバックポートが難しいパッケージも存在します。特に他のパッケージから使われうるライブラリやツールを提供するパッケージについては,そのパッケージに依存しているすべてのパッケージが期待通り動くことを確認しなくてはなりません。ライブラリの中身が変わるのであれば,他のパッケージの再ビルドも必要になるでしょう。言い方を変えると,広く利用されているライブラリはその確認作業の手間を考えるとバックポートを行うことは現実的ではありません。

もしローカルで使う特定のプログラムのためにライブラリのバージョンを変えたいのであれば,広く使われるバックポートは使用せず,たとえばPPAなどを使って特定の環境用という限定で提供すべきでしょう。しかしながらPPAを使う場合,リポジトリのサイズに上限があります。2GiB程度なので,よほど大きなプロジェクトでない限りあふれることはまずありませんし,申請すれば増やすことも可能ではありますが,上限があることは事実です。またタイミングによってはビルドサーバーが混んでいて,なかなかビルドされないこともあります。あとは当然のことですが,再配布可能なライセンスのものでない限りPPAにはアップロードできません。

特定のプロジェクト・ターゲット向けパッケージセットの構築を目的としてバックポートするのであれば,ローカルでビルドし,ローカルのリポジトリにアップロードできる環境があると何かと便利です。ローカルのリポジトリについては第485回で紹介しましたので,今回は開発版のUbuntuからローカルにパッケージをバックポートし,それをARM用バイナリとしてビルドするところまでを紹介します。話の流れ上ARM固有の話もありますが,全体を通してアーキテクチャに依存しませんので,amd64やその他のアーキテクチャーでも参考になることでしょう※2)⁠

※2
とても前置きがすごく長くなってしまいました。しかしながら,⁠ARMとバックポート」という言葉をタイトルに入れたかったので,仕方がないのです。

armhf向けクロスビルド環境の準備

パッケージのビルドには「ネイティブビルド」「クロスビルド」⁠それに「QEMUを使ったビルド」の3種類の方法が存在します。一番確実なのはネイティブビルドです。しかしながらx86以外のアーキテクチャーの場合,ビルドに使えるターゲットマシンが必ずしも存在するわけではありません。速度の面ではクロスビルドが有利ではありますが,クロスビルドはアーキテクチャによって環境構築の手間が異なります。構築の手間とビルド時間のバランスを考えると,QEMUを使ったビルドになるでしょう※3)⁠

※3
Launchpadの場合,OpenStackを用いて複数のホストマシンの上に仮想マシンとして複数台のビルドサーバーを用意しています。ARMについてもarm64のホストマシンの上にarm64・armhf・armelの仮想マシンを用意しているようです。以前はqemu-user-staticを使ったビルド方法を使っていました。また,特定のプロジェクト向けにPandBoardやBeagleBoardを使ったビルドクラスターを構築していました。どちらもスケールの面で難があったのですが,arm64+OpenStackになってからは,個人のPPAにもARMビルド機能が提供されています。

さらにQEMUを使ったビルドも,仮想マシンを作る方法と作らない方法があります。作る方法はカーネルから用意しなくてはなりません。今回は作らない方法を紹介します。

Debianパッケージを個人でビルドする場合,pbuider-distやcowbuilder-distを使うのが一番お手軽です。ただ残念ながら現在のpbuilder-dist/cowbuilder-distには,ホスト以外のアーキテクチャをビルドするとこけるという問題が存在します※4)⁠よって今回は,本家のビルドサーバー(buildd)でも使われているsbuildを用いてビルドしましょう。

※4
ラッパースクリプトであるpbuilder-dist/cowbuilder-distではなく,生のpbuilder/cowbuilderを使えばこけないかもしれませんが未確認です。

まずは必要なパッケージをインストールして,いくつかの環境変数の設定,所属グループの追加を行います。

$ sudo apt install packaging-dev sbuild
$ cat >>~/.profile <<'EOSEOS'
export DEBFULLNAME='Mitsuya Shibata'
export DEBEMAIL='shibata@example.com'
EOSEOS
$ sudo usermod -aG sbuild $USER
(一度ログアウトしてログインし直す)

環境変数DEBFULLNAMEDEBEMAILはDebianパッケージで使われるさまざまなスクリプトから参照される環境変数です。ここで設定した名前とメールアドレスはdebian/changelogファイルなどを経由して,作成したパッケージにアクセス可能なすべてのユーザーに公開されますので注意してください。

また第485回などを参考に,GPG鍵も作っておいてください。この鍵はソースパッケージの署名に使います。自分自身でビルドし,自分自身で構築したリポジトリにアップロードするのであればGPG鍵を使う必要はないのですが,パッケージングのツールが要求してくることもあるので,作っておいたほうが便利です。今のうちに使い慣れておけば,将来的に公式リポジトリのパッケージの開発に携わる際に役に立つでしょう。ちなみに作ったGPG鍵は,原則としてDEBEMAILの値を使ってツールから参照することになるため,作成時に値を合わせておきましょう。

さっそくarmhfアーキテクチャー用のビルド環境を構築しましょう。環境構築にはsbuild標準のsbuild-createchrootコマンドと,ubuntu-dev-toolsパッケージのmk-sbuildコマンドの両方を使えます。今回はpackaging-dev経由でubuntu-dev-toolsパッケージをインストールしているため,作成時のオプションを減らせるmk-sbuildを使います。ビルドサーバーの様に必要最低限なビルドマシンを構築するのであればsbuildパッケージのみをインストールしてsbuild-createchrootを使うと良いでしょう。

$ mk-sbuild --arch=armhf xenial
(中略)
Done building xenial-armhf.

 To CHANGE the golden image: sudo schroot -c source:xenial-armhf -u root
 To ENTER an image snapshot: schroot -c xenial-armhf
 To BUILD within a snapshot: sbuild -A -d xenial-armhf PACKAGE*.dsc
 To BUILD for : sbuild -A -d xenial-armhf --host  PACKAGE*.dsc

最後のxenialはリリース名です。Ubuntu 16.04 LTS以外の環境を構築したいのであれば,それにあわせてリリース名を変更してください。たとえばDebianの開発版ならsidを指定します。--archオプションで対象アーキテクチャーを指定しています。省略するとホストと同じアーキテクチャーが指定されます。最終的に/var/lib/schroot/chroots/RELEASE-ARCHなビルド環境が構築されるはずです。ちなみにリリースは同じでも別名の環境を構築したい場合は,--nameオプションを指定してください。

今回の場合は,/var/lib/schroot/chroots/xenial-armhfが作られているはずです。

$ ls /var/lib/schroot/chroots/xenial-armhf
bin   build  etc   lib    mnt  proc  run   srv  tmp  var
boot  dev    home  media  opt  root  sbin  sys  usr

また個々の環境の定義ファイルは,/etc/schroot/chroot.d以下に作成されます。

これで開発環境の事前準備は完了です。

著者プロフィール

柴田充也(しばたみつや)

Ubuntu Japanese Team Member株式会社 創夢所属。数年前にLaunchpad上でStellariumの翻訳をしたことがきっかけで,Ubuntuの翻訳にも関わるようになりました。

コメント

コメントの記入