注意: 原文はこの翻訳よりも新しくなっています。

パッケージメンテナとバグ対応者向けのバグ処理システムに関する情報

まず初めに、バグ報告はユーザから通常の電子メールとして [email protected] に提出されます。 バグ報告にはPackage行が1行ないといけません (詳細はバグを報告する方法を参照)。 このバグ報告は通し番号が与えられ、 ユーザには受領通知が送られ、debian-bugs-dist メーリングリストに転送されます。 Package行にメンテナのわかっているパッケージ名を指定した場合は、 該当するメンテナにもその写しが送られます。

Subject 行には Bug#nnn: が追加されます。Reply-To には、そのバグ報告の提出者と nnn@bugs.debian.org が設定されます。

バグ報告のクローズ (解決)

Debian のバグ報告はその問題が解決したときクローズ (解決) しなければなりません。パッケージ中の問題はそのバグの修正を含むパッケージが Debian アーカイブに入ったときのみ解決したとみなされます。

ふつう、バグ報告をクローズすべきなのはそのバグの報告者と そのバグが報告されたパッケージのメンテナだけです。この規則には例外があります。 たとえば、不明なパッケージや一般的な擬似パッケージに対するバグなどです。 バグは、もしバグが 放棄されたパッケージに対するものであったり、 パッケージのメンテナーがクローズを忘れているような場合には、コントリビューターなら誰でもクローズできます。 重要なのは、どのバージョンでそのバグが修正されたのかを記録することです。 よく分からないなら、バグ報告をクローズするのではなく、まず debian-devel メーリングリストで助言を求めましょう。

バグ報告は nnn[email protected] に電子メールを送ることによってクローズしなければなりません。 メッセージの本文はそのバグがどのように修正されたのかの説明を含む必要があります。

バグ追跡システムから受けとった電子メールがあるなら、 そのバグ報告をクローズするにはメールリーダプログラムで返信を作り、To 欄を編集して、たとえば nnn@bugs.debian.org のかわりに nnn[email protected] を使うだけでいいです (nnn-close は、nnn-done のエイリアスとして用意されています)。

可能なら、 バグ追跡システムがどのリリースのパッケージにその修正が含まれるのか分かるように、 バグを閉じる際のメッセージの疑似ヘッダ内に Version 行を書いておいてください。

バグ報告をクローズしようとしている人、それを提出した人および debian-bugs-closed メーリングリストにそのバグ報告のステータスが変更されたことが通知されます。 報告の提出者とこのメーリングリストには nnn-done へ送られたメッセージの内容も送られます。

フォローメッセージ

バグ追跡システムはバグ報告をフォワードする時に、Reply-To ヘッダに報告者のメールアドレスとそのバグのメールアドレス (nnn@bugs.debian.org) を含めます。これらは別個のメールアドレスであることに注意してください。

クローズされていないバグ報告に開発者が返信したい時は、単にそのバグ報告に返信します。 Reply-To ヘッダをそのまま使うわけです。 これはバグ報告をクローズしません。

もし確固とした受取人変更の意図がないのであれば、メーラーの reply to all recipients (すべての受取人に返事をする)や followup (フォローする) の機能を使ってはいけません。特にフォローメッセージを [email protected] に送らないように注意してください。

メッセージは以下のアドレスに送ることでバグ追跡システムに記録することができます:

受信通知メッセージを抑制するためのヘッダに関する情報や、 バグ追跡システムを使ってカーボンコピーを送る方法については、バグ報告の説明を見てください。

Severity (重要度) レベル

バグシステムは、それぞれのバグ報告について severity (重要度) レベルを記録します。デフォルトでは normal (通常) に設定されますが、バグ報告の際に疑似ヘッダに Severity 行を入れる (Debian にバグを報告する方法を参照) か、コントロールリクエストサーバに severity コマンドを送ることで変更できます。 複数のタグを指定する場合は、コンマ、スペース、またはその両方を使って区切ってください。

severity レベルには以下のものがあります。

critical (致命的)
システム上の関係のないソフトウェア (またはシステム全体) を破壊する、重大なデータの欠落を引き起こす、または、 そのパッケージをインストールしたシステム上でセキュリティホールが生じる場合。
grave (重大)
問題のあるパッケージが使用できない、またはほとんど使用できない。 またはデータの欠落を引き起こす、そのパッケージを使用するユーザの アカウントにアクセスを許してしまうセキュリティホールが生じる場合。
serious (深刻)
Debian ポリシーに対して見すごせない違反がある (大まかに言うと、mustや requiredの要件に違反している)、またはパッケージメンテナあるいはリリースマネージャの意見として そのパッケージがリリースに適していないと判断された場合。
important (重要)
バグがパッケージの有用性を大きく損なっている場合 (ただし、誰にとっても完全に使用できなくなっている場合を除く)。
normal (通常)
デフォルト値。通常のバグ。
minor (軽度)
問題がパッケージの利用に影響しない、 かつ修正はたいした事がないと思われる場合。
wishlist (要望)
将来的な要望、主に設計上の理由により修正が非常に困難なバグ。

リリースクリティカル とみなされる重要度があります。これはそのバグがそのパッケージを Debian の安定版でリリースするのに影響があるという意味です。 現在、critical、grave そして serious がこれに該当します。 これらの深刻度がもたらすあらゆる問題についての完全で正式なルールは、次期リリース のリリースクリティカル問題のリストを見てください。

バグ報告のタグ

それぞれのバグ報告は規定されたタグをつけることができます。 これらのタグは、パッケージのページやすべてのバグの記録を閲覧したときに、 バグ報告のリストの中に表示されます。

タグは、バグの報告時に擬似ヘッダに Tags 行を指定すること (バグ報告の勧め (使用説明書) を参照) や、コントロールリクエストサーバに対して tags コマンドを用いることで設定することができます。

現在のバグのタグは以下のものがあります。 patch, wontfix, moreinfo, unreproducible, help, security, upstream, pending, confirmed, ipv6, lfs, d-i, l10n, newcomer, a11y, ftbfs, fixed-upstream, fixed, fixed-in-experimental, potato, woody, sarge, etch, lenny, squeeze, wheezy, jessie, stretch, buster, bullseye, bookworm, trixie, forky, sid, experimental, sarge-ignore, etch-ignore, lenny-ignore, squeeze-ignore, wheezy-ignore, jessie-ignore, stretch-ignore, buster-ignore, bullseye-ignore, bookworm-ignore, trixie-ignore forky-ignore タグについての詳細をいくつか示します:

patch (パッチ)
バグ報告に、バグを修正するためのパッチや簡単な手順が含まれています。 パッチがあってもバグを適切に解決できない場合や別の問題を生じる場合は、 このタグは使うべきではありません。
wontfix (修正予定無)
このバグは修正されないでしょう。バグ修正に任意の 2 種類の選択肢があって メンテナと報告者がそれぞれ異なる方法を望んでいる場合や、 修正することによってより悪い問題が生じる場合や、その他の理由があるでしょう。
moreinfo (追加情報)
このバグは報告者が詳細情報を提供しないかぎり特定できません。 報告者が適当な期間 (数ヶ月) 中に詳細情報を提供しなければ、 バグはクローズされるでしょう。これは、動きませんというようなバグ報告のためにあります。 何が動かないのでしょう?
unreproducible (再現不可能)
このバグはメンテナのシステムでは再現できなかったものです。 問題の原因調査のために、第三者の協力が必要とされています。
help (助けを求む)
メンテナは、このバグを処理するのに助けを必要としています。 このバグの修正に必要とされるスキルがメンテナになく共同作業を希望している、 あるいはメンテナが多忙なため他の人にこの作業を任せたい、といった場合に利用します。 このタグを付けられたバグはnewcomerタグが合わせて付けられている場合を除き、 新しい貢献者には適さないかもしれません。
newcomer (新人向け)
このバグは解決方法がわかっていますがメンテナは他の人にそれを実装させるよう要求しています。 これから Debian に関わっていこうとする新しい貢献者や、 自らのスキルを向上させようと考えている人にとって理想的な作業です。
pending (保留)
バグの解決法が発見され、まもなくアップロードが行なわれます。
fixed (修正済)
(例えばノンメンテナ・アップロードのおかげなどで) このバグは修正されたかうまく動くようになりましたが、解決のために必要な事項がまだ残っています。 かつてのfixedという severity (重要度) はこのタグに置き換えられました。
security (セキュリティ)
このバグはパッケージのセキュリティ問題を説明します (例: アクセスされてはいけないデータへのアクセスを許可する不正な許可属性がある、 やれるべきではない方法でシステムを制御できるバッファオーバーフローがある、 修正すべき DoS 攻撃の穴がある、等)。ほとんどのセキュリティバグは、critical (致命的) や grave (重大) の severity (重要度) も設定すべきです。
upstream (上流)
このバグは、パッケージの上流の部分に影響します。
confirmed (確認済)
メンテナはこのバグを読み、理解し、その内容に基本的に合意しましたが、 まだ修正していません。(このタグの使用はできるだけ控えてください。 大量の未解決バグに対処しなければならないメンテナが使うことを想定したタグです。)
fixed-upstream (上流で解決済)
このバグは、上流メンテナによって修正されましたが、 まだパッケージにはなっていません (何らかの理由で: たとえば、変更が複雑すぎてバックポートできないとか、 あまりに些細なので無視しているとか)。
fixed-in-experimental (experimental で解決済)
このバグは experimental ディストリビューションのパッケージで修正されていますが、unstable ディストリビューションではまだです。
d-i (インストーラ)
このバグは、debian-installer に関するものです。 インストーラの開発に関係するけれども、 インストーラの直接の構成要素ではないパッケージに対するバグの場合、 このタグを使ってください。
ipv6
このバグは、インターネットプロトコル v6 (IPV6) のサポートに関係します。
lfs (巨大ファイルサポート)
このバグは、大きなファイル (2 ギガバイトを超える) のサポートに関係します。
l10n
このバグは、パッケージの地域化に関するものです。
a11y
このバグは、障がいのあるユーザーのためのアクセシビリティーに影響するものです。 とりわけ、システムやパッケージを利用するのにアクセシビリティー支援(あるいは適応)技術に依存している人々にとって 使いやすさに大きく影響します。
ftbfs
パッケージがソースからのビルドに失敗しています。 もしバグがソースパッケージに割り当てられているなら、そのパッケージはビルドに失敗します。 もしバグがバイナリパッケージに割り当てられているなら、その影響を受けるソースパッケージはビルドに失敗します。 このタグは標準のビルド環境でなくても適用できます(例: experimentalにあるパッケージに対してBuild-Dependsを している場合など)が、そのような場合に重要度は serious (深刻) (リリースクリティカル) より低くすべきです。
potato, woody, sarge, etch, lenny, squeeze, wheezy, jessie, stretch, buster, bullseye, bookworm, trixie, forky, sid, experimental
2つの効果を持つディストリビューションタグです。 バグに対してセットすると、そのバグは (たとえ他のディストリビューションタグが 設定されていて他のディストリビューションにも影響する可能性があったとしても) 特定のリリースのみに適用されるものとなります。その他の点では通常のバグ/修正/放置のルール が適用されます。このバグ報告は、当該リリースで修正されるまでアーカイブされません。
sarge-ignore, etch-ignore, lenny-ignore, squeeze-ignore, wheezy-ignore, jessie-ignore, stretch-ignore, buster-ignore, bullseye-ignore, bookworm-ignore, trixie-ignore forky-ignore
このリリースクリティカルバグは、特定リリースのリリースの目的のために無視されます。 このタグはリリースマネージャだけが使うべきものです。 リリースマネージャからの明示的な許可がない限りは使わないでください。

ディストリビューション指定タグについて: -ignore タグは、 パッケージをテスト版 (testing) に移行できるよう、そのバグを無視します。 リリースタグは、問題のバグが指定された一連のリリースにおいて修正されるまでは アーカイブされるべきでないことを示します。リリースタグは、指定された一連の リリースにおいてのみそのバグをバグとみなすべきだということを示してもいます。 [言いかえれば、何かリリースタグがセットされている場合、対応するリリースタグ がセットされていないリリースについては、そのバグは ありません。何もセットされていなければ、通常の found/fixed ルールが適用されます。]

手作業での追加や削除が必要となるので、バグの適切なバージョン管理によって 望ましい効果が得られるのであれば、リリースタグを使用しては いけません。リリースタグが必要かどうかわからなければ、Debian BTS 管理者 ([email protected]) かリリースチームにアドバイスを 求めてください。

バグ報告を転送したことの記録

Debian パッケージの元である上流ソースパッケージの開発者に Debian パッケージ開発者からバグ報告を転送する際は、 バグ追跡システムに次のようにして記録しなければなりません。

あなたのメッセージの To フィールドには原作者達のアドレスのみが書かれていることを確認すること。 そして、CC フィールドにはバグを報告した人と nnn[email protected] そして nnn@bugs.debian.org を入れること。

原作者が返信をする際に、CC に nnn[email protected] を残すように依頼すること。 バグ追跡システムはこの返信を元々のバグ報告とともに保存します。 この場合、メッセージの保存はしますが送信はしません。 通常のようにメッセージを送信するには nnn@bugs.debian.org に送ってください。

バグがすでに転送済であると記録されていない場合、バグ追跡システムが nnn-forwarded でメッセージを受け取ると、そのメッセージは To フィールドにあるアドレスに転送済であることを該当するバグに記録します。

[email protected] にメッセージを送ることで、forwarded to情報を操作することができます。

バグの所有者を変更する

バグを修正する責任を持った人が、関連するパッケージのメンテナには割り当てられていない場合 (例えば該当するパッケージがチームでメンテナンスされている場合など)、 このことをバグ追跡システムに記録しておくと役に立つでしょう。 そのため、それぞれのバグは任意に所有者を持てるようになっています。

バグの所有者は、バグ報告時に疑似ヘッダに Owner 行を付けたり (バグ報告の説明を参照)、 コントロールリクエストサーバに owner や noowner のコマンドを使って設定できます。

パッケージメンテナが間違っている場合

パッケージメンテナが間違っている場合、 多くの原因は最近メンテナが交替されていて、新メンテナが control ファイルの Maintainer フィールドを更新した新しいパッケージをアップロードしていないためです。 これは、パッケージをアップロードすることにより修正されます。 これ以外に、アーカイブメンテナが パッケージに記録されているメンテナを無視するように設定することが可能です。 これは例えば、すぐにパッケージの再構築、再アップロードの必要がないと思われる場合に利用します。 override file を変更するには [email protected] に連絡してください。

バグを再オープン (reopen)、再指定 (reassign)、操作する

別のパッケージにバグ報告を再指定 (reassign) する事や、誤ってクローズしてしまったバグを再オープン (reopen) する事、バグ報告が転送されている送付先について述べている情報を修正する事、バグ報告の severity (重要度) やタイトルを変更する事、バグの所有者を設定する事、バグ報告のマージ (merge)・マージ解除 (unmerge) をする事、 バグが発見された・修正されたパッケージのバージョンを記録する事ができます。 これらの操作は、[email protected] にメールを送ることにより行います。

これらのメッセージの書式 は WWW 上で利用できる別の文書や bug-maint-mailcontrol.txt ファイルに記述されています。テキストバージョンは、上記のアドレスのサーバに help と書いたメールを送ることで入手することも可能です。

バグ報告を購読する

バグ追跡システムでは、バグの報告者、開発者およびそれに関心のある第三者が、 個々のバグ報告を購読できます。あるバグに注意を払い続けたい場合、Debian Package Tracker を通してパッケージの購読をしなくても、 この機能を利用できます。nnn@bugs.debian.org に届いたすべてのメッセージは購読者に送られます。

nnn のバグ報告を購読するには、nnn[email protected] にメールを送ります。メールの件名、本文は BTS によって無視されます。 このメールが処理されると、そのバグに関するメッセージを受け取れるようにしたい場合は これに返信してください、という内容の確認メッセージがユーザに届きます。

購読を停止することも可能です。購読を止めるには nnn[email protected] へメールを送ります。 この場合も、メールの件名、本文は BTS によって無視されます。 購読を止めるための確認メッセージが届きますので、それに返信する必要があります。

通常、購読に使用されるメールアドレスは From ヘッダに書かれているものになります。別のメールアドレスで購読したいなら、 購読に使用するメールアドレスを符号化して購読メッセージの宛先に埋め込む必要があります。 nnn-subscribe-localpart=example.com@bugs.debian.org という形式になります。 この例では、バグ nnn の購読メッセージを [email protected] へ送ります。@ 記号を = 記号に置き換えて符号化しなければなりません。同様に、購読を止める場合も、 nnn-unsubscribe-localpart=example.com@bugs.debian.org という形式になります。 どちらのケースでも、メールの件名と本文は確認のリクエストに含めて、 そのメールアドレスに転送されます

廃止されつつあるサブジェクト検査機能

サブジェクトが Bug#nnn で始まるメッセージが submit や bugs に到着した場合、このメッセージは nnn@bugs.debian.org に送信されたものとして扱われます。 これは、昔のアドレスから転送されたメールと互換性を残すためと、誤って (例えば、全ての受取人へ返信をしてしまうことにより) submit に送られたフォローメールを捕えるためです。

maintonly、done、quiet、forwarded についても同様に扱われます。これらのアドレスでは、サブジェクトタグのあるメールは、 nnn-whatever@bugs.debian.org (whatever は maintonly、done、quiet、forwarded のうち対応するもの) というアドレスに送信されたものとして扱われます。

forwarded と done に届いたタグのないメッセージ (例えばアドレスにバグ番号がないもの) で、サブジェクトにバグ番号がついていないメッセージは junkとして記録され数週間保存はされますが、それ以外の処理は無効となります。

X-Debian-PR: quiet 機能は廃止

バグ追跡システムが debian-bugs で受け取ったメッセージをどこにも転送させないようにするためには、 従来は実際のメールヘッダに X-Debian-PR: quiet 行を入れていました。

現在、このヘッダ行は無視されます。代わりに、 quiet や nnn-quiet (もしくは、maintonly や nnn-maintonly) にメッセージを送ってください。

その他の BTS ページ:

Debian BTS administrators <[email protected]>

Debian bug tracking system
Copyright © 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd, 1994-1997 Ian Jackson.