openSUSE:Build Service ヒント

移動先: 案内, 検索
Open Build Service
パッケージングガイドライン

この howto は、build service で使えるいくつかの小さな tips と裏技を順不同で列挙しています。ここに挙げられた tips のうちのほとんどは、他のページに取り込まれて(included in other sides)ここから削除されるべきです。このページの意図は、より詳しく文書化されるべき情報やできるだけ早く修正されるべき情報を集めておくための場所を提供することにあります。

ほとんどの情報は buildservice-mailinglist (アーカイブ) から集められています。

目次

パッケージの構築を無効化するには

ある特定のパッケージだけを構築から除外するには、いくつかの方法があります。 1 つの方法としては、 'osc' コマンドラインクライアントを使用する方法があります。たとえば下記のように実行します: 

osc api -X POST "/source/<プロジェクト>/<パッケージ>?cmd=set_flag&flag=build&status=disable" # 無効化
osc api -X POST "/source/<プロジェクト>/<パッケージ>?cmd=set_flag&flag=build&status=enable" # 有効化
osc api -X POST "/source/<プロジェクト>/<パッケージ>?cmd=remove_flag&flag=build" # フラグ消去 (プロジェクトのデフォルトに戻す)

もしくは、下記のように実行して XML を編集する方法もあります: 

osc meta pkg -e <プロジェクト> <パッケージ>

上記を実行したあと、パッケージのメタデータ内の <build> タグ内に、 <disable> タグを追加してください。下記のように指定して、部分的に構築を無効化することもできます: 

<!-- [...] -->
<build>
  <disable arch="<無効化するアーキテクチャ>"/>
</build>
<!-- [...] -->

or 

<!-- [...] -->
<build>
  <disable repository="<ターゲットのリポジトリ名>"/>
</build>
<!-- [...] -->

下記のようにして、両方を指定することもできます: 

<!-- [...] -->
<build>
  <disable repository="SLES_9" arch="x86_64"/>
</build>
<!-- [...] -->

もう 1 つの方法としては、 Web クライアント を利用してパッケージを表示し、対応するボタンを押す、というやり方もあります。

注意: 既に開始されてしまっているジョブは、停止することができません。恒久的に削除したい場合は、 ローカルの OBS 内の /srv/obs/jobs/ ディレクトリ内からそれらを削除してください。

現在動作中のパッケージ構築を中止するには

osc abortbuild <project> <package> <repo> <arch>

展開エラー (expansion error) に対応するには

たとえば、特定のパッケージに対して、下記のようなエラーメッセージが表示されたとします: 

expansion error have choice for inet-daemon needed by imap: inetd xinetd

この場合、以下のうちいずれかの方法で解決することができます:

  • 上記のパッケージのうちのいずれか (inetd または xinetd) を BuildRequires に追加します。
  • もしくは下記のコマンドラインを実行して、プロジェクトファイルを編集して優先順位を設定します (たとえば Prefer: xinetd の行を追加します): osc meta -e prjconf <プロジェクト名>
  • 時間のかかる方法ではありますが、 opensuse-buildservice メーリングリスト にメールを送信して、リポジトリの .dsc ファイルに対して、いずれかのファイルを追加するようにお願いします。これにより、同種の問題が発生しているパッケージを一括で解決することができます。

プロジェクト内でパッケージを探すには

BuildRequires の行を記述する際など、ベースとなるプロジェクト内などでパッケージの名称を検索したいような場合があります。このような場合は、少し凝った形でコマンドを記述する必要があります。

たとえば下記のように実行します: 

 osc ls -b -r standard -a i586 Fedora:20

上記を実行すると、 Fedora 20 内にあるすべてのバイナリパッケージを検索します。あとは出力された内容から、必要なパッケージ名を見つけてください。 

 osc ls --help

を実行すると、より詳しい使い方の説明を読むことができます。

Build Service 内の構築処理に対して、特別な扱いを設定するには

何らかの理由で、 Build Service 内とそれ以外の構築処理を区別して実施したいような場合があります。このような場合は、 spec ファイル内で %opensuse_bs マクロをお使いください。下記のように指定します: 

%if 0%{?opensuse_bs}
# Build Service 内でだけ実行する箇所
%endif

ローカルでの構築で 32 ビット版の RPM を作成するには

x86_64 のマシンで 32 ビット版のパッケージをローカルで構築するには、下記のようにします: 

linux32 build foo.spec

なお、 osc build でもこれを実行することができます。

アクセス拒否エラーに対応するには

ローカルでは問題なく構築できるものの、下記のようなメッセージで Build Service では構築が失敗するような場合があります: 

 /usr/bin/install: cannot create regular file `/usr/lib/libfoo.so.0.0`: Permission denied

このような場合は、まず Build Service の構築処理が chroot 内でのみ行なわれることに留意してください (おそらくは、お使いのパッケージが DESTDIR 変数に対応しておらず、 RPM_BUILD_ROOT 以下にインストールしようとしていないものと思われます) 。

このような場合は、 spec ファイル内に下記を追加してください: 

# norootforbuild

これにより、ローカルでの構築時でも Build Service と同じエラーを表示させることができます。まずはローカルの環境でこのエラーを修正し、 Build Service 側にアップロードしてください...

_link と _aggregate

_link (リンク) と _aggregate (アグリゲート) の違いについて

他のパッケージから BuildRequires で指定されたような場合や、エンドユーザに対してディストリビューションを配布するにあたって全パッケージの構築を完了させたいような場合など、パッケージを不用意に再構築しないようにするため、 Build Service には _aggregate という機能が用意されています。

新しいプロジェクト内で _aggregate を利用してパッケージがリンクされていると、その新しいプロジェクト内ではパッケージが再構築されず、元のプロジェクトで構築されたものをそのままコピーして更新し続けるようになります。

下記に、要件に対してどちらを使用すべきなのかを示します:

要件 _link _aggregate コメント
ソースコードを変更する必要がない場合   X アグリゲートを使用することができますが、構築処理が遅くなるばかりか、容量を 2 倍必要としてしまいます。他のリポジトリに対して直接構築するとよいでしょう。
ソースコードを変更する必要がある場合 X    
必要なディストリビューションやアーキテクチャに対して、パッケージが構築されていないような場合 X X 2 つの疑似パッケージを作成するのがベストです: 1 つは _aggregate 機能を利用して、元のプロジェクトからバイナリパッケージだけを取得するように設定し、もう 1 つは _link 機能を利用してパッケージを構築するようにします (ただし、元のプロジェクトのメンテナンス担当者に対して、それらのディストリビューションやアーキテクチャを追加するようにお願いするのが最も簡単ではあります)

なお、 パッケージ のリンクと プロジェクト のリンクは異なることに注意してください。プロジェクトに対するリンクは、 Build Service における追加の機能です。詳しくは プロジェクトリンクのページ をお読みください。

リンクの例

_link の簡単な例

お使いのプロジェクト内に新しいパッケージを作成 (元のパッケージと同じ名前であるものとしますが、下記の記述では特に重要ではありません) し、 _link というファイル名で下記のような内容を記述します: 

<link project='openSUSE:Factory' package='tse3'/>

他の OBS インスタンスとのリンク

ローカルの OBS インスタンスを動作させていて、 公式の Build Service や API に対応したその他の OBS インスタンスに対してパッケージのリンクを作成したい場合は、下記のように _link ファイルを作成します: 

<link project='openSUSE.org:openSUSE:Factory' package='tse3'/>

上記の例では、 openSUSE.org で動作している Build Service 内の openSUSE:Factory にある tse3 という名前のパッケージとのリンクを作成します。

この例では、 Build Service の管理者がローカルのインスタンス内に openSUSE.org という空のプロジェクトを作成し、下記の内容をプロジェクト定義に記述する必要があります: 
<remoteurl>https://api.opensuse.org/public</remoteurl>
管理者としての作業はこれだけです。

リンクされているパッケージに対するパッチ (修正)

> 他のプロジェクトから自分のプロジェクトにパッケージをリンクしてみましたが、
> その時点では特に問題はありませんでした。ところが、 osc で新しいパッケージを
> チェックアウトしても、 "_link" というファイルが取れるだけでした。
> パッチを追加したり spec ファイルを追加したりしたいのですが、どうしたらいいですか？

リンクしたパッケージであっても、ファイルを追加することはできます。追加されたファイルは、元のプロジェクト内にあるファイルを上書きするように追加されます。 spec ファイルについても同様です。元のプロジェクトのファイルを上書きしたくない場合は、パッチファイルを追加するとよいでしょう。パッチファイルは下記のようにして _link ファイル内に記述しなければなりません: 

<link project='openSUSE:Factory' package='tse3'>
  <patches>
    <apply name="patch" />
  </patches>
</link>

リンクされているパッケージ内への修正 (パッチ) の追加

既に spec ファイル内に記載されているものとは別に、ソースに対して新しいパッチを適用したい場合は、 spec ファイルに対するパッチを作成して、上のセクションのように <apply> で適用する方法もありますが、 <add> コマンドを使用するともっと簡単に実現できます: 

<link project='openSUSE:Factory' package='tse3'>
  <patches>
    <add name="mybugfix.patch" />
  </patches>
</link>

上記では、 'mybugfix.patch' を spec ファイル内のパッチ一覧に追加することになります (Build Service 側でパッチへの登録処理を行ないます) 。新しいパッチは spec ファイル内に記載されているパッチの末尾に追加されます。もちろん 'mybugfix.patch' ファイルが (リンクした) プロジェクト内に存在していなければなりません。

また、 <add> コマンドには 'popt="番号"' という属性を指定することもできます。これは %patch の -p(番号) と同じ意味になります。また、 'dir="some/dir"' という属性を追加すると、パッチを適用する前に指定したディレクトリに移動するようになるほか、 'after="番号"' を指定すると、指定した番号の行以降を %patch に追加します。

spec ファイルの冒頭部への追加

たとえば %define 句など、 spec ファイルの冒頭部に行を追加したい場合は、 spec ファイルに対するパッチを作成する必要はありません。その代わり、下記のように <topadd> を利用することができます: 

<link project="myproject" package="theotherpackage">
  <patches>
    <topadd>%define small_build 1</topadd>
  </patches>
</link>

このファイルを取得するには、まず --unexpand-link パラメータを付けてチェックアウトしてください。たとえば下記のようになります:

osc checkout --unexpand-link <プロジェクト名> <パッケージ名>


あとは _link という名前のファイルを確認して編集を行ない、上記を追加してください。

正しく動作しているかどうかを確認するには、他の場所にチェックアウトしてから spec ファイルの冒頭部分を確認してみてください。 <topadd> で指定した行があれば成功です。

ソースと詳細: [1]

アグリゲートの例

_aggregate の例

お使いのプロジェクト内に新しいパッケージを作成 (元のパッケージと同じ名前であるものとしますが、下記の記述では特に重要ではありません) し、 _aggregate というファイル名で下記のような内容を記述します。なお、 _aggregate はデータ容量を 2 倍必要としてしまうことから、あまり望ましい方法ではないことにご注意ください。 Build Service ではそのようなパッケージの構築を遅らせる場合があるほか、互換性を壊してしまう場合もあります。通常は 下記 に説明されている手順で、追加のリポジトリを設定して構築します: 

<aggregatelist>
  <aggregate project="KDE:Backports">
    <package>ksimus</package>
  </aggregate>
</aggregatelist>

リポジトリ名が合わない場合は、下記のように <repository> 要素を指定して、マッピングを設定することもできます (source で元のパッケージのリポジトリ名を指定します): 

<aggregatelist>
  <aggregate project="KDE:Backports">
    <package>ksimus</package>
    <repository target="openSUSE_10.2" source="SUSE_10.2" />
    <repository target="openSUSE_10.1" source="SUSE_10.1" />
  </aggregate>
</aggregatelist>

i586 上で i686 パッケージを選択するには

既定のアーキテクチャ以外でパッケージを構築したい場合 (たとえば i586 ではなく i686 で glibc を構築したい場合など) は、下記のようにします:

osc meta prjconf <プロジェクト名> -e


あとは下記の行をプロジェクトの設定に追加します: 

ExportFilter: \.i686\.rpm$ .

その後、下記のように指定すると、 i586 上で i686 のパッケージを取得することができるようになります: 

<aggregatelist>
  <aggregate project="openSUSE:Factory">
    <package>glibc.i686</package>
  </aggregate>
</aggregatelist>

プロジェクトに対して複数のリポジトリを追加するには

パッケージが 1 つ以上の Build Service リポジトリに依存 (Requires または BuildRequires) しているような場合、特定のプロジェクトに対して複数のリポジトリを追加するのは簡単です: 

 osc meta -e prj <プロジェクト名>

上記を実行すると、プロジェクトのメタデータのエディタが起動します。リポジトリは <path project="プロジェクト名"/> の形式で追加することができます。なお、依存関係にあるリポジトリについては、追加する必要はありません。下記の例では openSUSE:Tools プロジェクトだけを追加していますが、 openSUSE:10.3/standard リポジトリに対して構築処理を行なうものであるため、これらのパッケージも構築処理に含まれることになります。 

 <repository name="openSUSE_10.3">
   <path project="openSUSE:Tools" repository="openSUSE_10.3"/>
   <arch>i586</arch>
   <arch>x86_64</arch>
 </repository>

他の例: openSUSE:10.2 プロジェクトに対して、 NonFree と Update のリポジトリを追加した場合の例です。ベースとなる openSUSE:10.2/standard リポジトリは、それらに対してパッケージを構築するものであることから、指定不要です。なお、 :Update プロジェクトを追加すると、ユーザは :Update が提供するすべてのパッケージ (つまり、更新パッケージ) を適用しないと、構築済みのパッケージを利用できないことになる場合もありますので、できる限り避けてください。 :Update プロジェクトを指定しない場合は、更新の適用いかんにかかわらず、パッケージを利用できるようになります。ただしカーネルモジュールについては例外で、 :Update リポジトリを指定する必要があることがあります (Linux カーネルは場合によっては互換性を失う場合があるためです。通常のソフトウエアであれば、そのようなことは起こりません): 

<repository name="openSUSE_10.2">
   <path project="openSUSE:10.2:Update" repository="standard"/>
   <path project="openSUSE:10.2:NonFree" repository="standard"/>
   <arch>i586</arch>
   <arch>x86_64</arch>
</repository>

下記の点にもご注意ください:

  • リポジトリの設定順序にご注意ください: Build Service は、バージョンが適合するかどうかにかかわらず、上から順にパッケージを検索して利用します。
  • 依存関係は再帰的に取り込まれます。
  • パッケージのユーザは Requires: タグに示されたパッケージをインストールしなければならないことから、ここで指定したすべてのリポジトリを追加しなければならなくなることに注意してください。たとえば、あまり一般的には使われないプロジェクトを指定してしまうと、プロジェクトを見つけにくくなってしまいます。

例:
プロジェクト A では下記のように指定しているものとします: 

 <repository name="openSUSE_Factory">
   <path repository="snapshot" project="openSUSE:Factory"/>
   <arch>i586</arch>
   <arch>x86_64</arch>
</repository>

プロジェクト A のパッケージを利用して、プロジェクト B でパッケージを構築したい場合は、下記のようにします:

 <repository name="openSUSE_Factory">
   <path repository="openSUSE_Factory" project="A"/>
   <path repository="snapshot" project="openSUSE:Factory"/>
   <arch>i586</arch>
   <arch>x86_64</arch>
</repository>

もしくは下記のようにしてもかまいません (openSUSE:Factory/snapshot はプロジェクト A に含まれているため): 

 <repository name="openSUSE_Factory">
   <path repository="openSUSE_Factory" project="A"/>
   <arch>i586</arch>
   <arch>x86_64</arch>
</repository>

実際の例としては、 devel:languages:python のプロジェクトを既存のリポジトリに追加するような場合があります: 

 <repository name="openSUSE_12.1">
   <path project="devel:languages:python" repository="openSUSE_12.1"/>
   <path project="openSUSE:12.1" repository="standard"/>
   <arch>i586</arch>
   <arch>x86_64</arch>
 </repository>
 <repository name="openSUSE_12.2">
   <path project="devel:languages:python" repository="openSUSE_12.2"/>
   <path project="openSUSE:12.2" repository="standard"/>
   <arch>i586</arch>
   <arch>x86_64</arch>
 </repository>

構築環境はどのようにして定義されているのか

build パッケージ内の /usr/lib/build/configs/$distro.conf で定義しています。 各項目の説明については、 各項目の説明 をお読みください。

ここには構築環境の設定がすべて記されています。パッケージの依存関係の展開もこちらに記述されています。

構築中に X Server を必要となるパッケージを構築するには

こちらは "RuntimeError: Gtk couldn't be initialized" エラーへの回避策です。 openSUSE 12.3 での python-gobject のバグでした。
> パッケージを構築する際、 X Server (または DISPLAY 環境変数) が必要になって
> しまっています。
>
> Build Service から X Server にアクセスする方法はありませんか？
> spec ファイルで何を変更したらよいですか？

Xvfb を起動 (spec ファイル内で指定できます) して、この問題を回避してください。

たとえば下記のように spec ファイルに記述してください: 

BuildRequires:  xorg-x11-server
%define         X_display         ":98"
...
%install
#############################################
### Launch a virtual framebuffer X server ###
#############################################
export DISPLAY=%{X_display}
Xvfb %{X_display} >& Xvfb.log &
trap "kill $! || true" EXIT
sleep 10
...
# 以降でアプリケーションやテストを実行します

それぞれのプラットフォームに対して別々の spec ファイルを使用するには

過去から現在、未来に対しても、すべてのプラットフォームを単一の spec ファイルで賄うのが理想ではありますが、実際には単一の spec ファイルでは実現できなかったり、あまりにも %if 分岐が多すぎて、読めなくなってしまったりすることがあります。

そのような場合に対応するため、 Build Service にはそれぞれのプラットフォームに対して別々の spec ファイルを使用する方法があります。

たとえば "foo" という名称のパッケージで、 "foo.spec" という spec ファイルがあるものとします。 openSUSE, SLES, SLED など、 SUSE ベースのディストリビューションに対しては問題なく動作するものの、パッケージレイアウトの違いにより、 Fedora などの全く異なるディストリビューションでは、別の spec ファイルを用意して対応したいとします。このような場合、 Build Service 内でのリポジトリが "Fedora_Extras_6" である場合、 "foo.spec" の代わりに使用する spec ファイルとして、 "foo-Fedora_Extras_6.spec" を作成して対応することができます。

なお、この方法では 1 つのリポジトリに対して spec ファイルを作成することができますが、複数のリポジトリに対して spec ファイルを作成するような方法はありません。上記の例でいうと、 Fedora Extras 4, 5, 6 にだけ対応するような spec ファイルは、作成することができません。たとえ内容が全く同一のものであるとしても、 "foo-Fedora_Extras_4.spec", "foo-Fedora_Extras_5.spec", "foo-Fedora_Extras_6.spec" の各ファイルを作成する必要があります。

実際にこの方法を利用している例としては、 net-snmp プロジェクト内の "net-snmp-main-snapshot" パッケージ があります。

無効化されてはいるが、構築が完了してしまっているパッケージをリポジトリから削除するには

現時点では、これを Web フロントエンドで実施することはできません。 osc であれば、下記のように実行します: 

osc wipebinaries <プロジェクト名>

上記以外にも buildservice-API と直接 "対話" して実施することもできます。リポジトリ全体 (たとえば home:foo) に対して、無効化されているすべてのパッケージ RPM を削除したい場合は、下記のようにします:

  • ~/.netrc ファイルを作成して、 build.opensuse.org に対するログイン情報を記録するか、もしくは "-u username:password" オプションを使用します。
  • curl -n -X POST -d '' 'https://api.opensuse.org/build/home:foo?cmd=wipe&code=disabled'
    もしくは 
    curl -u username:password -X POST -d '' 'https://api.opensuse.org/build/home:foo?cmd=wipe&code=disabled'
    を実行します。

"コマンド" について、詳しくは API ドキュメンテーション をお読みください。

ディストリビューション内で利用可能なパッケージを一覧表示するには

構築に必要な正確なパッケージ名がわからない場合は、 Web 検索機能 か osc ls -b を使用することができます。

例: Ubuntu で mysql の開発用パッケージを知るには.. 

#           <repository> <arch> <project>
$ osc ls -b -r standard -a i586 Ubuntu:7.10 | grep 'mysql.*dev'
libmysqlclient15-dev_5.0.45-1ubuntu3_i386.deb
# -> "libmysqlclient15-dev" というパッケージ名であることがわかります。

Build Service のリポジトリ内で rpmlint のチェックを有効にするには

RpmLint ページ、および こちらの章 をお読みください。

他のアーキテクチャに対して特定のビット版のパッケージを構築するには (baselibs)

openSUSE:Build Service_baselibs.conf をお読みください。

構築されたパッケージのリリース番号を制御するには

通常は Build Service が Release タグを自動的に処理し、 CI_CNT.B_CNT という値を設定します。ここで CI_CNT はコミット回数、 B_CNT は再構築回数 (再構築が始まった場合) を表します。

上記の動作は、プロジェクトの設定ファイルで 

Release: <CI_CNT>.<B_CNT>

を指定しているのと同じ意味になります (osc meta prjconf -e [プロジェクト名] でアクセスできます) 。

このような動作を改善する方法があります。たとえば jpackage.org からインポートした RPM では、プロジェクトの設定で 

Release: %%{?release_prefix}.<CI_CNT>.<B_CNT>

のように設定することができます。ここで、 %{release_prefix} は spec ファイル内にて定義されているものとします。 この結果、 RPM に対して jpackage.org と openSUSE の両方に互換性のあるリリース番号を設定することができます。つまり、 SUSE のパッケージを jpackage.org のパッケージにアップグレードすることができることになります。

上記以外の方法として、 spec ファイル内で下記のように指定することもできます (たとえば jenkins job 123 が生成したリリースの場合): 

Release: <CI_CNT>.<B_CNT>.j123

この結果、 RPM に対して通常のリリース番号のほかに、 '.j123' という文字列が付加されるようになります。これで jenkins job が構築したものであることをリリース番号に含まることができます。

詳しくは openSUSE:Build_Service_prjconf#Release をお読みください。

プロジェクトを削除しようとする際、 "does not exist" というエラーを回避するには

バックエンドにタイムアウトが設定されている場合、 API のデータベースとバックエンドとの間が不整合な状態になってしまうことがあります。このような場合、プロジェクトを削除するには、下記のようにして osc でメタデータを編集してください: 

osc meta prj -e <プロジェクト名>

そのまま保存したあと、削除を行ないます: 

osc rdelete <プロジェクト名>


SLES 11 SP1 のライブ CD を構築するには

kiwi-3.74-5.101.1 でテスト済み ビルドシステムに clicfs-1.1.3-3.1.x86_64.rpm と liblzma0-4.999.9beta-11.1.x86_64.rpm をインストールし、これらのファイルを /usr/share/kiwi/image/isoboot/suse-SLES11/config.xml で指定したリポジトリのディレクトリにコピーします。

あとは /usr/share/kiwi/image/isoboot/suse-SLES11/config.xml ファイルを編集し、 <packages type="bootstrap"> セクション内に下記を追加します:

<package name="clicfs"/>

あと、これはおそらくバグと思われますが、下記のような行では動作しません (CD が起動しません):

<packages type="bootstrap" profiles="std">

ですが、 type="image" にすると、 CD がうまく動作するようになります:

<packages type="image" profiles="std">


  1. kiwi --createhash /usr/share/kiwi/image/isoboot/suse-SLES11

あとは clicfs を使用するため、お使いのライブ CD 向けの config.xml (おそらく config.xml というファイル名ではないと思いますが) を修正します:

<type primary="true" boot="isoboot/suse-SLES11" flags="clic">iso</type>

squashfs および aufs で SLES 10 SP2/SP3 KIWI イメージを設定するには

ビルドホストも SLES 10 SP2 x86_64 でした。

詳しくは KIWI のドキュメンテーションをお読みください。

ステップ 1: KIWI のインストール

注意: SLES 10 SDK のリポジトリ内にいくつかのパッケージがあると思いますが、 kiwi-3.01-93.1 を下記の場所からインストールしました:

http://download.opensuse.org/repositories/openSUSE:/Tools/SLE_10

注意: kiwi-desc-oemboot, kiwi-desc-vmxboot には qemu が必要となりますが、これらはインストールしていません。

smart パッケージマネージャをインストールします: 

rpm -ivh /usr/share/kiwi/repo/suse-repo/suse-sle10-repo/smart-0.41-23.4.$(arch).rpm

SLES 10 SP2/SP3 向けの squashfs を下記からダウンロードします: http://download.opensuse.org/repositories/home:/mopp:/squashfs/

SLES 10 SP2/SP3 向けの aufs を下記からダウンロードします: http://download.opensuse.org/repositories/home:/mopp:/aufs

KIWI サーバに squashfs パッケージをインストールします: 

rpm -ivh /tmp/kiwi/squashfs-3.4-35.1.x86_64.rpm

ステップ 2: KIWI 起動イメージ環境の作成

もちろん SLES 10 SP2/3 のソースが必要です。私はローカルのディレクトリにコピーしました。 お使いのシステムに合わせてディレクトリパスは変更してください: 

cp -a aufs-kmp* squashfs-kmp* /usr/share/kiwi/repo/suse-repo/suse-sle10-repo/

注意: aufs と squashfs のモジュールは、 /lib/modules/<カーネルバージョン>/updates/ 内にインストールされます。カーネルモジュールと KIWI イメージ内にインストールしようとしているカーネルが適合していることをご確認ください。

ここでは config.xml (boot/initrd イメージ) を編集し、 aufs と squashfs モジュールを見つけられるようにします。 kiwi を更新することで config.xml が上書きされるため、編集するよりも前にディレクトリをコピーしていると思います: 

cd /usr/share/kiwi/image/isoboot/suse-SLES10
vi config.xml

aufs と squashfs を <drivers type="drivers"> セクション内に追加します。これらのモジュールがないと、ライブ CD を見つけることができなくなってしまいます: 

<file name="../updates/aufs.ko"/>
<file name="../updates/fs/squashfs/*"/>

<packages type="bootstrap"> セクションには下記の行を追加します: 

<package name="squashfs-kmp-default"/>
<package name="squashfs-kmp-smp"/>
<package name="aufs-kmp-default"/>
<package name="aufs-kmp-smp"/>

あとは新しいハッシュを作成します: 

kiwi --createhash /usr/share/kiwi/image/isoboot/suse-SLES10

ステップ 3: システムイメージの準備

まずは起動用のイメージに含まれるはずのカーネルと、システム側のカーネルが混在していない (たとえば -default と -smp など) ことを確認します。

あとは下記のように実行して、システムイメージを準備します (最小限の構成となることから、私は suse-11.0 を使用しています): 

cp -pr /usr/share/doc/packages/kiwi/examples/suse-11.0/suse-live-iso /usr/local/kiwi/suse-sle10sp2-live-iso

あとは /usr/local/kiwi/suse-sle10sp2-live-iso 内にある config.xml を編集します。少なくとも "boot", "repository" の各タグがあることを確認します。

さらに 

<type primary="true" boot="isoboot/suse-11.0" flags="unified">iso</type>

を 

<type primary="true" boot="isoboot/suse-SLES10" flags="unified">iso</type>

に変更し、"bootsplash-branding-openSUSE" パッケージを削除します (SLES 10 には用意されていないため) 。

smart などの追加パッケージを見つけることができるようにするため、下記のようにリポジトリを追加します: 

       <repository type="rpm-dir">

 <source path="/usr/share/kiwi/repo/suse-repo/suse-sle10-repo/"/>

       </repository>

config.xml 内に必要なパッケージを追加、もしくは不要なパッケージを削除して、システムをカスタマイズします。

たとえば DHCP を利用するには、 dhcpcd パッケージを追加します。

opensusePattern は SLES では動作しないものと思われます。

ステップ 4: ISO イメージの作成

まずは十分な空き容量があることを確認します。その後、下記を実行します: 

kiwi --prepare /usr/local/kiwi/suse-sle10sp2-live-iso --root /tmp/myiso

あとはログファイルを確認してください。 作成されたターゲットシステムを確認するには、下記のように実行してください: 

chroot /tmp/myiso

上記で確認した結果、問題なく作成できているようであれば、下記のようにして iso イメージを作成します: 

kiwi --create /tmp/myiso -d /tmp/myiso-result

再度ログファイルをご確認のうえ、問題なければ iso イメージから起動してみてください。

VCS チェックアウトからナイトリービルドを実施するには

OBS では現在、 _service ファイルを利用して VCS から直接ダウンロードできる機能が追加されています。詳しくは 考え方のページ と OBS (ドラフト) ドキュメンテーション をお読みください。

_service ファイルの技術を利用して .spec ファイルの処理や編集を回避したい場合で、 Debian のパッケージングとバージョン情報を共有してもかまわない場合は、 https://github.com/boombatower/obs-git-update をお試しください。それ以外の場合は、下記をお読みください。

この作業を行なうには、 cron と osc がインストールされたマシンが必要です。

まずは、お使いのコードを VCS からチェックアウトして、 Build Service からパッケージを取り出すための作業ディレクトリを準備します。また、下記のようにして、 .spec ファイルの Version の項目にプレースホルダー (後から置き換えるための特殊なキーワード) を指定します: 

Name:         monitord
Version:      ##TIMESTAMP##
Requires:     alsa
...

次に、ローカルで更新して tar ボールを準備し、 spec ファイルを修正して Build Service にアップロードするまでのシェルスクリプトを作成します。

下記は SVN リポジトリ向けのスクリプト例です: 

#!/bin/bash

# OBS チェックアウトに対する相対パス
PACK_PATH=home:cwh:monitord-nightly/monitord

# SVN チェックアウトに対する相対パス
REPO_PATH=trunk

TIMESTAMP=`date +"%Y%m%d"`

# SVN のディレクトリに入る
pushd $REPO_PATH

# 最新のリビジョンに更新する
svn up

# tar ボールを準備する
make dist

# 作成した tar ボールをパッケージのディレクトリにコピーする
cp monitord-2.0svn.tar.gz ../$PACK_PATH

popd

# パッケージディレクトリ内に、置換済みの spec ファイルをコピーする
perl -p -e "s/##TIMESTAMP##/$TIMESTAMP/" monitord.spec > $PACK_PATH/monitord.spec

# パッケージのディレクトリに入る
pushd $PACK_PATH

# OBS に変更点 (新しい tar ボールと spec ファイル) をアップロードする
osc commit -m "updated to current SVN snapshot $TIMESTAMP"

popd

echo "完了"

これを cron から呼び出すようにします。

例: 

0 5 * * *       cd /space/monitord-nightly && ./push_to-obs.sh
zh:openSUSE:Build_Service_Tips_and_Tricks
「https://ja.opensuse.org/index.php?title=openSUSE:Build_Service_ヒント&oldid=6249」から取得