request@bugs.debian.org を利用してバグデータや説明をメールで取得できるのと同様、
control@bugs.debian.org
を利用してバグ報告を様々な方法で操作することができます。
制御サーバはコマンドが追加されていますが、 リクエストサーバと同じように動作します — 実のところ同一のプログラムです。 単に情報を取得する際にミスで問題を起こすのを避けるためだけの目的でこの 2 つのアドレスに分けられています。
制御サーバへの特定のコマンドは実際にバグの状態を変更するので、 変更されたバグが割り当てられているパッケージのメンテナには、 コマンドの処理に関する通知が送られます。 さらに、サーバへ送られたメールと変更の結果はバグ報告にログとして残ります。 これらは WWW ページで参照可能です。
どちらかのアドレスにメールを送る場合の、
メールサーバの基本操作と利用可能な共通コマンドの詳細については、WWW
上の リクエストサーバ入門、
ファイル bug-log-mailserver.txt、
またはどちらかのメールサーバに help
を送ることでも参照できます。
メールサーバのリファレンスカードを WWW
上やファイル bug-mailserver-refcard.txt
で参照できます。または、電子メールで refcard
コマンドを送ることでも利用できます。
| 一般 | バージョン管理 | 複製 | その他 |
reassign バグ番号
パッケージ [ バージョン ]バグ報告 #バグ番号がパッケージのバグであること を記録します。このコマンドは、ユーザが擬似ヘッダをつけ忘れた場合に パッケージを設定したり、以前のパッケージ設定を変更するために利用されます。 この変更による通知は (処理中の写しの通常情報以外は) 誰にも送られません。
バージョンが指示された場合は、バグ追跡システムはそのバグが 新しく割り当てられたパッケージのそのバージョンに影響することを記録します。
コンマ区切りでパッケージ名を連ねれば、2 つのパッケージに同時にバグを割り当てることが可能です。 しかし、そのようにするのは、 一方のパッケージを変更すればそのバグが解決できる場合のみにしてください。 そうでない場合は、バグ報告を複製し、 複製によって新たにできたバグをもう一方のパッケージに割り当て直してください。
reopen バグ番号
[ 報告者アドレス | = | ! ]バグ報告 #バグ番号が閉じられている場合、再開します。
デフォルトあるいは =
を指定した場合、元の報告者がそのままこの報告の報告者となり、
再び閉じられる時に通知を受け取ることになります。
報告者アドレスを指定した場合、
そのアドレスが報告者としてセットされます。
自分を再開したバグの新しい報告者にする場合は、短縮形の !
を使用するか、自分のメールアドレスを指定してください。
通常は元々の報告者に 自分がそのバグ報告を再開しようとしていることを連絡すると良いでしょう。 それによって、再びバグが閉じられた時に通知を受け取ることが期待できます。
バグが閉じられていない場合、reopen
は何もせず、報告者の変更も行いません。未解決バグの報告者を変更するには、
submitter コマンドを使います。
このコマンドを使うと元々の報告者に通知されることに注意してください。
バグがそのパッケージの特定のバージョンで一旦閉じられてから、
以降のバージョンで再発した場合は、代わりに
found コマンドを使用してください。
found バグ番号 [ バージョン ]#バグ番号が割り当てられているパッケージの指定された バージョンで発生したことを記録します。
バグ追跡システムはこの情報とバグを閉じるときに記録するバージョンを合わせて利用して、 それぞれのパッケージの複数のバージョンに対するバグの状況を示します。 修正されたバージョンが存在しない、 あるいは修正の後に再現されたものは未解決と見なします。
バージョンが指定されない場合は、
そのバグの修正されたバージョンのリストがクリアされます。これは
reopen と同じ事になります。
このコマンドは、バージョンが指定されていない場合、または発生 (found)
の印をつけられたバージョンが最後に修正 (fixed)
の印をつけられたバージョンと同一である場合、
バグに未解決の印をつけるだけです。
(未解決の印をバグにつけたいのだと自分で確信している場合は、found
とともに reopen を使用してください。)
reopen
の書式でバージョンを追加するのが苦痛となっていることから、
このコマンドが導入されました。
notfound バグ番号 バージョン#バグ番号が割り当てられているパッケージの指定された バージョンで見つかったという記録を削除します。
これはそのバージョンで修正済みとしてバグを閉じるのとは異なり、 そのバグがどちらのバージョンでも修正済みにはなりません — そのバージョンに対する情報はなくなります。 これはバグが見つかった記録の誤りの修正に向いています。
fixed バグ番号 バージョンバグ報告 #バグ番号 が、それが割り当てられた パッケージの指定のバージョンで修正済みであることを示します。
これは、バグを閉じたものとして印をつけることは行わず、 単にバグが修正された特定のバージョンを追加するだけです。 バグを閉じて特定のバージョンで修正された印をつけるには、 バグ番号-done アドレスを利用してください。
notfixed バグ番号 バージョンバグ報告 #バグ番号が指定のバージョン で修正されたという記録を削除します。
このコマンドは、notfound と同様に found
と等価です (found は特定のバージョンでの fixed を削除し、notfound
は found を削除します)。
submitter バグ番号
報告者アドレス | !バグ報告 #バグ番号の報告者を報告者アドレス に変更します。
自分を新しい報告者にしたい場合は、短縮形の !
を使うか、自分のメールアドレスを指定してください。
reopen
コマンドが再開の対象となるバグに結合されたバグの報告者も変更するのに対して、
submitter では結合されたバグを変更しません。
forwarded バグ番号 アドレスバグ番号がアドレスで示す、 上流の保守担当者に転送されることに注意してください。 これは実際の転送は行いません。これは誤った forwarded-to アドレスの変更や、これまでに転送されてきたものではない、 新しいアドレスを記録するのに使います。
notforwarded バグ番号バグ番号を転送していた上流の保守担当者の情報を抹消します。 バグ報告の転送記録がない場合は何も行いません。
retitle バグ番号 新しい題名指定したバグ報告の題名を変更します (元々のバグ報告のメールヘッダの
Subject がデフォルトとなります)。
他のほとんどのバグ操作コマンドと異なり、 結合されたバグ報告のひとつに用いた場合、 変更を要求したバグ報告の題名のみが変更され、 結合されているバグ報告すべての題名が変更されるわけではありません。
severity バグ番号 重要度 (severity)バグ報告 #バグ番号 の重要度レベルを severity に設定します。バグを報告したユーザには通知されません。
重要度には critical(致命的)、grave(重大)、
serious(深刻)、important(重要)、
normal(通常)、minor(軽度)、
wishlist(要望) があります。
これらの意味については、 バグシステムの一般開発者文書で調べてください。
clone バグ番号 新 ID [ 新 ID ... ]clone 制御コマンドによりバグ報告を複製することができます。 これは、一つの報告が実際には複数のバグを指摘しているような場合に便利です。 「新 ID」はスペース区切りのマイナスの数値で、 以降のコマンドから新しく複製されたバグを参照するのに使うことができます。 新しいバグ報告は、それぞれの「新 ID」に対して作成されます。
使用例:
clone 12345 -1 -2
reassign -1 foo
retitle -1 foo: foo sucks
reassign -2 bar
retitle -2 bar: bar sucks when used with foo
severity -2 wishlist
clone 123456 -3
reassign -3 foo
retitle -3 foo: foo sucks
merge -1 -3
merge バグ番号 バグ番号 ...複数のバグ報告を結合します。バグ報告が結合されると、 結合されたバグ報告の任意の一つに対してオープン、クローズ、 転送済としてマーク、マーク解除、新しいパッケージの再指定の場合に、 結合されたバグ報告すべてに対して同じ操作が行なわれます。
バグ報告を結合する場合には、それらが厳密に同じ状態でなければなりません:
バグがすべてオープンであるかクローズで、
すべて同じ上流担当者のアドレスに転送、あるいは未転送になっていて、
バグがすべて同じパッケージ (群) を対象としていて
(バグが対象としているパッケージについて完全な文字列比較が行われます)、
バグがすべて同じ重要度 (severity) になっていないといけません。
対象のバグが同じ状態でない場合、merge
コマンドを使用する前に、reassign、reopen
等を使って同じ状態にしなければなりません。
タイトルが一致している必要はなく、結合により影響を受けることもありません。
同様にタグも影響を受けません。それらは結合されます。
merge
コマンドで与えられた任意のバグが既に別のバグに結合されている場合、
コマンドに与えられた任意のバグに結合されているバグがすべて結合されます。
「結合」は(数学の)等号に似て、再帰性、推移性、対称性があります。
バグ報告を結合すると、それぞれの報告のログに注釈を記録します。 WWW ページ上では、結合されている他のバグへのリンクが含められます。
結合されたバグ報告は、バグ報告それぞれの抹消期限がすべて満了した後で、 すべて同時に抹消されます。
forcemerge バグ番号 バグ番号 ...複数のバグ報告を強制的に結合します。 リストの先頭のバグがマスターとなり、 その設定が以降のバグに割り当てられます (通常の結合 (merge) においては、 設定が一致していなければなりません)。誤記による誤った結合を防ぐため、 バグはすべて同じパッケージのものでなければなりません。 結合が意味することについては上記の説明文を参照してください。
これを使うと結合でバグを閉じることができるということに注意してください — これを行う場合は、 閉じるにあたって適切なメッセージを報告者に通知する責任があります。
unmerge バグ番号指定したバグ報告を、これに結合されていた他のバグ報告から分離します。 指定したバグ報告が複数のバグ報告に結合されていた場合は、 指定したバグ報告以外はすべて結合されたままとなります — 明示的に指定したバグのみが結合を解除されます。
多くのバグ報告が一つに結合されているのを二つのグループに分けたい場合は、 新しいグループに移したいバグ報告をそれぞれ個別に分離し、 それから新しいグループに結合しなければなりません。
unmerge
コマンド一つで分離することができるバグ報告は一つだけです。
複数のバグ報告を分離したい場合は、メール本文に複数の
unmerge コマンドを含めてください。
tags バグ番号 [ + | - | = ] タグ [ タグ ... ]バグ報告 #バグ番号 にタグを設定します。
バグの報告者には通知されません。+ は追加、-
は削除、=は
現在のタグを無視して新しいタグを付けなおすことをそれぞれ意味します。
デフォルトの動作は追加です。
使用例:
# 'tags 123456 + patch' と同じ
tags 123456 patch
# 'tags 123456 + help security' と同じ
tags 123456 help security
# 'fixed' と 'pending' タグを追加
tags 123456 + fixed pending
# 'unreproducible' タグを削除
tags 123456 - unreproducible
# 'moreinfo' タグと 'unreproducible' タグだけを設定
tags 123456 = moreinfo unreproducible
現在、有効なタグには patch (パッチ)、
wontfix (修正予定無)、moreinfo (追加情報)、
unreproducible (再現不可能)、help (助力)、
pending (保留)、fixed (修正済)、
fixed-in-experimental (experimentalで修正済),
fixed-upstream (上流で修正済),
security (セキュリティ)、upstream (上流)、
confirmed (確認済)、d-i (インストーラ)、
ipv6、lfs、l10n、
potato、woody、sarge、
sarge-ignore、etch、etch-ignore、
sid、experimental があります。
これらの意味 については、 バグシステムに関する開発者情報で調べてください。
block バグ番号 by バグ ...最初のバグの修正がリストの他のバグによって妨害されていることを記録します。
unblock バグ番号 by バグ ...最初のバグ修正がリストの他のバグによって妨害されていたものが 解除されたことを記録します。
close バグ番号 [ 修正されたバージョン ]
(非推奨)バグ報告 #バグ番号 を閉じます。
バグを報告したユーザに通知が送られますが、
(バグ番号-done@bugs.debian.org
にメールを送った場合とは異なり) バグを閉じたメールの本文はその通知には
含まれません。バグ報告を閉じた担当者は、
別にメッセージを送るなどして、どうしてそのバグが閉じられたのか、
バグを報告したユーザが確実に分かるようにしなければなりません。
こういうわけで、このコマンドの使用は非推奨となっています。
バグの正しい閉じ方についての開発者情報を見てください。
修正されたバージョンを指示した場合は、 バグ追跡システムはそのパッケージのそのバージョンで そのバグが修正されたことを記録します。
package [ パッケージ名 ... ]以降に続くコマンドが一覧に示したパッケージへのバグにのみ適用されるよう、 制限します。複数のパッケージを指定することも可能です。 パッケージを何も指定しない場合、以降のコマンドは全バグに適用されます。 この機能は誤って間違ったバグ番号を使う可能性に対する保護機能として使うことができます。
使用例:
package foo
reassign 123456 bar 1.0-1
package bar
retitle 123456 bar: bar sucks
severity 123456 normal
package
severity 234567 wishlist
owner バグ番号 アドレス | !アドレス を #バグ番号 の「所有者」に設定します。 バグの所有者はその修正に対して責任を負います。 これは、パッケージをチームで管理している場合に、作業を共有するのに便利です。
自分をバグの所有者にしたい場合は、省略形の !
または自分のメールアドレスを指定します。
noowner バグ番号バグの通常のメンテナ以外の所有者の情報をすべて消去します。 もしバグに所有者が記録されていなければ、これは何もしません。
archive バグ番号バグがアーカイブの要件を満たしている場合、 過去のある時点でアーカイブされたけれども現在はアーカイブされていないそのバグを、時間を無視してアーカイブします。
unarchive バグ番号過去にアーカイブされたバグのアーカイブを解除します。 アーカイブ解除は、一般に、適切な reopen および found/fixed と 組み合わせられるべきです。 アーカイブ解除されたバグは、時間ベースではないアーカイブ要件を 満たすと仮定して、archive を使ってアーカイブできます。
#...一行コメントです。#は行頭になければなりません。
コメント内のテキストは、送信者と関連する担当者への通知に含められるので、
コマンドの理由を示すのに利用できます。
quitstopthankthanksthankyouthank you--各行はどれも空白文字で続けることができます。 制御サーバにメッセージの処理を停止することを伝えます — メッセージのリマインダとして説明、署名、 その他を記入することができますが、制御サーバには検知されません。
その他の BTS ページ:
Debian bug tracking system
Copyright © 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd,
1994-1997 Ian Jackson.