[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
devel/buildd/wanna-build-states (1.17)
http://www.debian.org/devel/buildd/wanna-build-states
rev 1.17
--
victory
http://debian.rsz.jp/
don't include my addresses in mail body...
----------------------------------------------------------------
#use wml::debian::template title="Wanna-build states: an explanation" BARETITLE="true"
#use wml::debian::translation-check translation="1.17"
<p>このページでは、wanna-build 状態が意味するすべて、
また、この状態にあるパッケージに何が起こるのか、ということを
説明します。対象読者は自分のパッケージが特定のアーキテクチャで
どうしてビルドされているのか、あるいはされないのか、
ということを理解しようとするパッケージメンテナです。
また、異なる結果となったログについても説明します。</p>
<p>最後に wanna-build の状態のフローチャート版も<a
href="#graphlink">あります</a>が、
この文書で述べているすべてについて触れられている
わけではないことに注意してください。</p>
<h2>wanna-build 状態</h2>
<p>Debian でサポートされるアーキテクチャすべてにおいて、
buildd.debian.org にインストールされている wanna-build
データベースがあり、
全パッケージとその現在のコンパイル状態を管理しています。
状態は七つあります: <em>needs-build</em>, <em>building</em>,
<em>uploaded</em>, <em>dep-wait</em>, <em>failed</em>,
<em>not-for-us</em>, 及び <em>installed</em>。</p>
<p>それぞれの意味は次の通りです:</p>
<dl>
<dt><a name="needs-build">needs-build</a></dt>
<dd><em>needs-build</em> とされたパッケージはこの wanna-build
のアーキテクチャ以外についてはメンテナにより
新バージョンがアップロードされ、それ自体は再ビルドが必要です。
状態が <em>needs-build</em> なのはまだ autobuilder
が取り上げていないもの
(時間の経過に伴いリストの上位に来れば処理される)。
<em>needs-build</em> 状態のパッケージについて話す時に、
「パッケージが再ビルドキューに入った」と一般に言われます。<br>
<em>needs-build</em>
のキューが先に入ったものから処理されるものではないというのは、
興味深い注意点かもしれません;
処理の順序はそれよりも以下を基準に決められます:
<ol>
<li>パッケージの以前のコンパイル状態。
以前にビルドされているパッケージは新しいパッケージよりも
高い優先度を与えられます。</li>
<li>優先度 (<em>required</em> のパッケージは <em>extra</em>
のパッケージよりも前にビルドされます)</li>
<li>パッケージの属するセクション。この順序は、
どのパッケージがより重要であると考えられているかに基づきます。
例えば、セクション <em>games</em> はセクション <em>base</em>
よりも後に、また、セクション <em>libs</em> は <em>devel</em>
よりも前にビルドされます。</li>
<li>パッケージ名の ASCII 順。</li>
</ol>
さらに、一定の条件の下で、buildd
がキューの先頭のパッケージを取り上げないことが起こるかもしれません;
例えば、buildd がパッケージのソースを見つけられない場合は、
キューに戻されます (戻される先は元の位置、つまりキューの先頭です)。
ただし、数時間はそのパッケージは無視されます。
これが起こるかもしれない別の例は、アーキテクチャに複数の
autobuilder がある場合です。
その場合、そのアーキテクチャの移植者は、速い方の autobuilder
で大きい方のパッケージを、遅い方のマシンには小さい方を残す、
というように決めることができます。理論的には、buildd
はセクションの順序を明示的に指示できますが、通常は行いません。<br>
他にもキューの順序が無視されるような状況があるかもしれませんが、
それはすべて例外であることに注意してください。</dd>
<dt><a name="building">building</a></dt>
<dd>autobuilder が wanna-build キューの先頭から取り上げてから
autobuilder 管理者がログに返信するまで、パッケージは
<em>building</em> とされます。
パッケージは一つずつ選ばれるわけではないので、
つまりパッケージはビルドが実際に始まる前に <em>building</em>
とされることがある (通常そうなる) ということになります。しかし、
buildd はローカルのキューにあるパッケージを、
基本的には入った順にビルドするので、
ここからそう長くかかることはないでしょう。
また、ビルドが出来上がってもパッケージの状態は変更
<strong>されない</strong> ことに注意してください。変更されるのは
autobuilder 管理者がログに反応した時だけです。</dd>
<dt><a name="uploaded">uploaded</a></dt>
<dd>ビルドが成功すると、ビルドログが autobuilder 管理者と
buildd.debian.org に送られます。それから autobuilder 管理者が
ビルドログに埋め込まれる .changes ファイルに署名し、autobuilder
に送ります。そうすると autobuilder はパッケージをアップロードし、
状態を <em>uploaded</em> にします。
この状態のパッケージ自体は次期のキューのどこかにあります。<br>
<em>uploaded</em> 状態になると、少なくとも次のアップロードまたは
パッケージの状態の移植者による手作業での修正が行われるまで
autobuilder はパッケージに対して何もしません。</dd>
<dt><a name="dep-wait">dep-wait</a></dt>
<dd>パッケージがビルド時の依存のため失敗すると、autobuilder
管理者はメールを autobuilder に送り、パッケージソースを削除させ、
そのパッケージを欠けているビルド依存に対する <em>dep-wait</em>
とします。この状態のパッケージは示された依存が入手可能になれば自動的に、
人間の介入なしで needs-build に変更します。<br>
元々、パッケージはメンテナが手作業で <em>dep-wait</em>
状態にする前にビルドを試みる必要がありました。しかし、2005 年
8 月に wanna-build にコードが追加され、適切な場合はパッケージを直接
<em><a href='#installed'>installed</a></em> から <em>dep-wait</em>
に移動させるようになりました。<br>
パッケージが dep-wait になったままになる可能性が具体的に二例あります。
<em>dep-wait</em> 依存の指示に打ち間違いがあった場合
(つまりそのパッケージが決して存在しない、
することのないパッケージに対する dep-wait とされる) と、
ビルド時に、<em>not-for-us</em> とされている、あるいは
<em>packages-arch-specific</em>
リストにあるパッケージに対する依存状態が宣言される場合です。<br>
後者の例を示してみます。三つのパッケージを考えてみてください:
<tt>i386</tt> だけに存在するパッケージ <tt>foo</tt>、
<tt>m68k</tt> だけに存在するパッケージ <tt>bar</tt>
(乱暴に言って同じ機能を実行します)、そして、<tt>foo</tt> または
<tt>bar</tt> のどちらかがあればビルドできるパッケージ <tt>baz</tt>。
そして、パッケージ <tt>baz</tt> のメンテナが <tt>bar</tt>
をビルド依存に追加することを忘れて、<tt>baz</tt> が <tt>m68k</tt>
には存在しない <tt>foo</tt> に対する <em>dep-wait</em>
状態になっているときに気付いて追加した場合、<tt>m68k</tt> の
<em>dep-wait</em> 状態は <tt>m68k</tt>
移植者の手作業により変更されなければならないでしょう。</dd>
<dt><a name="wanna-build-state-failed">failed</a></dt>
<dd>ビルドが失敗し、autobuilder
管理者がそれを再試行すべきでない実際の失敗だと判断すると
パッケージは <em>failed</em> とされます。
パッケージは、移植者が変更すべきだと判断するまで、
あるいは新バージョンが入手可能になるまで、この状態から変わりません。
しかし、前のバージョンで <em>failed</em>
とされていたパッケージの新しいバージョンが入手可能になると、
autobuilder はそれを再試行すべきかどうか管理者に問い合わせます。
こうすることで、再び失敗するのが明らかにパッケージで buildd
の時間を浪費しないようにします。ビルド試行前にパッケージが失敗、
というのもいささかおかしな話ではありますが、autobuilder
管理者はオプションを使うことができます。<br>
人間の介在なしにパッケージを <em>failed</em> とすることは
<strong>決してない</strong>ことに注意してください。</dd>
<dt><a name="not-for-us">not-for-us</a></dt>
<dd>一部の特定のパッケージがアーキテクチャ固有のものです。
例えば、i386 ブートローダの <tt>lilo</tt> は alpha, m68k, あるいは
s390 でビルドされるべきでありません。しかし、<em>wanna-build</em>
はデータベースの作成時にパッケージの制御ファイルを見ません。
見るのはパッケージの名前とセクション、前のビルド状態、
及びその優先度だけです。そういうわけで、他のアーキテクチャで
ビルドされるべきでないアーキテクチャ固有のパッケージであっても、
ビルド試行は行われます(しかし、ビルド時の依存状態がダウンロードや
インストールの前であっても失敗となります)。<br>
autobuilder はアーキテクチャで必要とされないパッケージのビルドに
時間を消費すべきではないので、
ビルドの試行の必要さえないパッケージをリストする方法が必要になります。
この問題の最初の解決策は <em>not-for-us</em> でした。
しかし、これは保守しづらいので、最近では <em>not-for-us</em>
は非推奨となっています。autobuilder 管理者は代わりに
<em>packages-arch-specific</em> を使用すべきです。これは wanna-build
状態の代わりとなる、特定のアーキテクチャに特有なパッケージのリストです<br>
<em>not-for-us</em> や <em>packages-arch-specific</em>
のパッケージがこの状態から自動的に変わることは<strong>ありません</strong>。
以前に任意のアーキテクチャが制御ファイルで除外されていたパッケージで、
対象アーキテクチャが増えた場合は、それについては
<strong>手作業で</strong>キューに入れなければなりません。<br>
これを誰かに頼む必要があるポジションにいる場合は、該当する buildd
に依頼することができます。$arch@buildd.debian.org
で連絡を取ることができます。</dd>
<dt><a name="installed">installed</a></dt>
<dd>名前でわかるように、<em>installed</em> とされたパッケージはその
wanna-build データベースのアーキテクチャ向けにコンパイルされています。
Woody がリリースされる前は、daily katie の実行後に
<em>uploaded</em> から <em>installed</em> に変更されていました。
しかし、<a
href="http://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200206/msg00002.html";
>Accepted-autobuild</a> の実装によってこれは正しくなくなりました。
最近では、パッケージがアーカイブに受け入れられた時に
<em>uploaded</em> から <em>installed</em> に移行します。要するに、
パッケージは通常、平均して 15 分後に <em>installed</em> とされます。</dd>
</dl>
<p>以上の七つの状態に加えて、かなりまれですが
<em>wanna-build</em> には -removed の状態が二つあります。
<em>dep-wait-removed</em> と <em>failed-removed</em> です。
以下のようにそれぞれの「通常」の状態と関連します:
<em>failed</em> や <em>dep-wait</em> の状態にあるパッケージが、
<em>wanna-build</em> に送られた新しいパッケージのファイル中にない場合
– 出てきたときには既に削除済みとなっている –
パッケージファイルにないのは単なる一時的な不具合である、
何らかの理由により一時的に削除されているだけである
(時間の経過とともに再びアーカイブに出てくる)、といった可能性があるため、
そのパッケージについての情報は捨てられません。
代わりに、こういった場合にはパッケージは <em>-removed</em>
状態になり、失敗した理由や、何を待っている状態なのか、
という情報を保持しておくことができます。パッケージが以降の
wanna-build に送られるパッケージファイルに再び出てきた場合は、
さらなる処理が行われる前に <em>failed-removed</em> から
<em>failed</em> に戻されます。</p>
<p>wanna-build データベースに直接アクセスすることはできません。
このデータベースは制限されてる ftp-master.debian.org
にあり、autobuilder だけがそれぞれのアーキテクチャの wanna-build
データベースにアクセスできる SSH 鍵を持っています。
ftp-master が制限される前でもこうなっていました。wanna-build
はアクセス時に、データの読み込みであってもデータベースレベルでロックするので、
直接 wanna-build データベースにアクセスするには正しいグループ
(wb-<arch>) に属していなければなりません。</p>
<p>とは言っても、パッケージがどの状態にあるのかは、
<em>installed</em> の状態にあるものを除いて、<a
href="http://buildd.debian.org/stats/";>buildd 状況ページ</a>
で参照できます (数メガバイトに及ぶ "<arch>-all.txt"
ファイルを調べようというのであれば別です)。他にも、<a
href="http://crest.debian.org/";>crest.debian.org</a>
からたどれるウェブページで、<arch>-all.txt
ファイルを解析した情報を基にした、(少なくとも人間にとっては)
読みやすい形でパッケージがどの状態にあるのか確認できます。</p>
<h2>ビルドログの結果</h2>
<p>パッケージは sbuild (実際にビルドする buildd コンポーネント)
によってビルドされ、ログとビルド結果がメールにより autobuilder
管理者と logs@buildd.debian.org に送られます。
(なので http://buildd.debian.org で処理されます。)
ビルドログの結果は <em>successful</em>, <em>failed</em>,
<em>given-back</em>, <em>skipped</em> のうちの一つになります。
<a href="http://buildd.debian.org/";>buildd ログ概要ページ</a>で、
特に、ビルドが <em>failed</em> とされていても<em>実際の</em>
失敗ではない可能性があった (あるいは、
反対にビルド成功とされたパッケージが実は壊れていて再ビルドの必要があった)
ことにより過去に誤解を招いたため、頭に <em>maybe-</em>
が追加されていることに注意してください。</p>
<p>ログの結果の意味は次の通りです:</p>
<dl>
<dt><a name="successful">successful</a></dt>
<dd>ビルドは成功しました。autobuilder
管理者はこのログを受け取った場合、埋め込まれた <code>.changes</code>
ファイルを抽出し、署名して autobuilder に送り返します。
そうするとパッケージがアップロードされます。</dd>
<dt><a name="failed">failed</a></dt>
<dd>ビルドは失敗しました。ビルドが失敗する理由はいくつも考えられ、
すべて列挙するのは回りくどいだけなのでここでは挙げません。
もし自分のパッケージが <em>(maybe-)failed</em> となっていたら、
上記を読んで wanna-build の現在の状態を確認してみるとよいでしょう。</dd>
<dt><a name="given-back">given-back</a></dt>
<dd>ビルドは autobuilder の一時的な問題のため失敗しました。
例えば、ネットワークの問題、現在の sources.list
ではパッケージのソースが入手できない、ディスク領域の不足、等があります。<br>
<em>given-back</em> とされているパッケージは再び
<em><a href="#needs-build">needs-build</a></em> とされ、
準備ができ次第、他の autobuilder によって取り上げられます。</dd>
<dt><a name="skipped">skipped</a></dt>
<dd>パッケージが autobuilder により取り上げられて
<em><a href="#building">building</a></em> とされてから、
ビルド試行までに、そのパッケージの新バージョンがアップロードされたか、
何らかの理由で移植者が手作業で wanna-build 状態を変更した場合。
これが行われると、そのパッケージをビルドしないように、autobuilder
にメールが送られます。sbuild はこれを見て、ビルドを飛ばします
(ビルドログとこの結果が送られ、これが起きたということを示しますが)。</dd>
</dl>
<h2><a name="graphlink">視覚化バージョン</a></h2>
<p>上記を説明するために、この手順の<a
href="wanna-build.png">フローチャートバージョン</a>も用意しました。
繰り返しますが、これにはこの文書で言及したすべてが含まれているわけでは
ないことに注意してください。</p>
----------------------------------------------------------------