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

バグ制御とメールサーバの操作

[email protected] を利用してバグデータや説明をメールで取得できるのと同様、 [email protected] を利用してバグ報告を様々な方法で操作することができます。

制御サーバはコマンドが追加されていますが、リクエストサーバと同じように動作します — 実のところ同一のプログラムです。単に情報を取得する際にミスで問題を起こすのを避けるためだけの目的でこの 2 つのアドレスに分けられています。

制御サーバへの特定のコマンドは実際にバグの状態を変更するので、変更されたバグが割り当てられているパッケージのメンテナには、コマンドの処理に関する通知が送られます。さらに、サーバへ送られたメールと変更の結果はバグ報告にログとして残ります。これらは WWW ページで参照可能です。

どちらかのアドレスにメールを送る場合の、メールサーバの基本操作と利用可能な共通コマンドの詳細については、WWW 上のリクエストサーバ入門、ファイル bug-log-mailserver.txt、またはどちらかのメールサーバに help を送ることでも参照できます。

メールサーバのリファレンスカードを WWW 上やファイル bug-mailserver-refcard.txt で参照できます。または、電子メールで refcard コマンドを送ることでも利用できます。

メールサーバの制御に利用できるコマンド

一般	バージョン管理	複製	その他
reassign severity tags retitle submitter affects summary outlook	found \| notfound fixed \| notfixed reopen	merge \| unmerge forcemerge clone	thanks # forwarded \| notforwarded owner \| noowner block \| unblock archive \| unarchive user \| usertag \| usercategory

reassign バグ番号 パッケージ [ バージョン ]

バグ報告 #バグ番号がパッケージのバグであることを記録します。このコマンドは、ユーザが擬似ヘッダをつけ忘れた場合にパッケージを設定したり、以前のパッケージ設定を変更するために利用されます。この変更による通知は (処理中の写しの通常情報以外は) 誰にも送られません。

バージョンが指示された場合は、バグ追跡システムはそのバグが新しく割り当てられたパッケージのそのバージョンに影響することを記録します。

コンマ区切りでパッケージ名を連ねれば、2 つのパッケージに同時にバグを割り当てることが可能です。 しかし、そのようにするのは、 一方のパッケージを変更すればそのバグが解決できる場合のみにしてください。そうでない場合は、バグ報告を複製し、複製によって新たにできたバグをもう一方のパッケージに割り当て直してください。

reopen バグ番号 [ 報告者アドレス | = | ! ]

バグ報告 #バグ番号が閉じられている場合、再開し、修正済みバージョンの情報を削除します。

デフォルトあるいは = を指定した場合、元の報告者がそのままこの報告の報告者となり、再び閉じられる時に通知を受け取ることになります。

報告者アドレスを指定した場合、そのアドレスが報告者としてセットされます。自分を再開したバグの新しい報告者にする場合は、短縮形の ! を使用するか、自分のメールアドレスを指定してください。

通常は元々の報告者に自分がそのバグ報告を再開しようとしていることを連絡すると良いでしょう。それによって、再びバグが閉じられた時に通知を受け取ることが期待できます。

バグが閉じられていない場合、reopen は何もせず、報告者の変更も行いません。未解決バグの報告者を変更するには、 submitter コマンドを使います。このコマンドを使うと元々の報告者に通知されることに注意してください。

バグがそのパッケージの特定のバージョンで一旦閉じられてから、以降のバージョンで再発した場合は、代わりに found コマンドを使用してください。

found バグ番号 [ バージョン ]

バージョンで発生したことを記録します。 バージョンは完全修飾の ソースパッケージ名/バージョンの表記も使えます。

バグ追跡システムはこの情報とバグを閉じるときに記録するバージョンを合わせて利用して、それぞれのパッケージの複数のバージョンに対するバグの状況を示します。修正されたバージョンが存在しない、あるいは修正の後に再現されたものは未解決と見なします。

バージョンが指定されない場合は、そのバグの修正されたバージョンのリストがクリアされます。これは reopen と同じ事になります。 バージョンは完全修飾の ソースパッケージ名/バージョンの表記も使えます。

このコマンドは、バージョンが指定されていない場合、または発生 (found) の印をつけられたバージョンが最後に修正 (fixed) の印をつけられた最大のバージョン以上である場合、バグに未解決の印をつけるだけです。 (未解決の印をバグにつけたいのだと自分で確信している場合は、found とともに reopen を使用してください。)

reopen の書式でバージョンを追加するのが苦痛となっていることから、このコマンドが導入されました。

notfound バグ番号 バージョン

#バグ番号が割り当てられているパッケージの指定された バージョンで見つかったという記録を削除します。 バージョンは完全修飾の ソースパッケージ名/バージョンの表記も使えます。

これはそのバージョンで修正済みとしてバグを閉じるのとは異なり、そのバグがどちらのバージョンでも修正済みにはなりません — そのバージョンに対する情報はなくなります。これはバグが見つかった記録の誤りの修正に向いています。

fixed バグ番号 バージョン

バグ報告 #バグ番号 が、それが割り当てられたパッケージの指定のバージョンで修正済みであることを示します。 バージョンは完全修飾の ソースパッケージ名/バージョンの表記も使えます。

これは、バグを閉じたものとして印をつけることは行わず、単にバグが修正された特定のバージョンを追加するだけです。バグを閉じて特定のバージョンで修正された印をつけるには、バグ番号-done アドレスを利用してください。

notfixed バグ番号 バージョン

バグ報告 #バグ番号が指定のバージョン で修正されたという記録を削除します。

このコマンドは、notfound と同様に found と等価です (found は特定のバージョンでの fixed を削除し、notfound は found を削除します)。found のバージョンが既存のどの fixed バージョンよりも大きい場合は例外で reopened とはなりません。これを使うのは、バグを fixed としたときの誤りを修正する場合です。ほとんどの場合 notfixed ではなく found を使います。

submitter バグ番号 報告者アドレス | !

バグ報告 #バグ番号の報告者を報告者アドレス に変更します。

自分を新しい報告者にしたい場合は、短縮形の ! を使うか、自分のメールアドレスを指定してください。

reopen コマンドが再開の対象となるバグに結合されたバグの報告者も変更するのに対して、 submitter では結合されたバグを変更しません。

forwarded バグ番号 アドレス

バグ番号がアドレスで示す、上流の保守担当者に転送されることに注意してください。これは実際の転送は行いません。これは誤った forwarded-to アドレスの変更や、これまでに転送されてきたものではない、新しいアドレスを記録するのに使います。アドレスは一般に URI あるいはメールアドレスであるべきです。URI を使うと、リモートのバグ追跡システム (bugzilla など) にバグの状態をツールで照会できます。

使用例:

  forwarded 12345 http://bugz.illa.foo/cgi/54321

notforwarded バグ番号

バグ番号を転送していた上流の保守担当者の情報を抹消します。バグ報告の転送記録がない場合は何も行いません。

retitle バグ番号 新しい題名

指定したバグ報告の題名を変更します (元々のバグ報告のメールヘッダの Subject がデフォルトとなります)。また、このバグが結合された全バグ報告の題名についても変更されます。

severity バグ番号 重要度 (severity)

バグ報告 #バグ番号 の重要度レベルを severity に設定します。バグを報告したユーザには通知されません。

重要度には critical, grave, serious, important, normal, minor, wishlist があります。

これらの意味については、バグシステムの一般開発者文書で調べてください。

affects バグ番号 [ + | - | = ] パッケージ [ パッケージ ... ]

バグが他のパッケージに影響を及ぼすことを示します。実際のバグは割り当てられているパッケージに存在するけれども、 バグ番号によりパッケージで問題が発生する場合、 パッケージのバグリストにデフォルトでそのバグがリストされることになります。ユーザからの複数の報告が誤ったパッケージに割り当てられるような状況が非常に深刻な場合にこれを使います。= は指定されたパッケージリストに影響があることを示し、これがパッケージリストが指定されない場合の既定の動作となります。- は指定されたパッケージを影響するパッケージのリストから削除します。+ は指定されたパッケージを影響するパッケージのリストに追加します。これがパッケージが指定された場合の既定の動作になります。

summary バグ番号 [メッセージ番号 | サマリー本文]

バグのサマリーとして使うメッセージを選択します。ヘッダや制御ではないと判定した最初の段落を解析してバグのサマリーにセットし、それがバグ報告ページの一番上に表示されます。元の報告で問題がうまく説明されていない、あるいはバグへのメッセージが多くなり実際の問題の把握が難しくなった、という場合に有用です。

メッセージ番号が指定されていない場合はサマリーは消えます。 メッセージ番号はバグ報告の cgi スクリプトの出力にあるメッセージ番号です。メッセージ番号として 0 を指定すると現在のメッセージを使用します (つまり、[email protected] に送られた、サマリー制御コマンドを含むメッセージ)。

メッセージ番号が数値や空白文字列ではない場合は、それをサマリーにセットする文だと想定します。

outlook バグ番号 [メッセージ番号 | 見通し文]

バグの修正の見通し (またはバグ修正の現状) として使用するメッセージを選択します。メッセージの最初に現れる非疑似ヘッダ/非制御項目が解析され、バグの見通しにセットされてバグ報告ページの最上部に表示されます。これは (例えばバグ退治パーティで) 共にこのバグの修正にあたっている他の人との調整に便利です。

メッセージ番号が指定されない場合、見通しはクリアされます。メッセージ番号はバグ報告 cgi スクリプトの出力に表示されるメッセージ番号です; メッセージ番号に 0 を指定するとこのメッセージ (つまり outlook 制御コマンドを記述して [email protected] 宛に送られたメッセージ) が使われます。

メッセージ番号が数値や空白文字列ではない場合は、それを見通しにセットする文だと想定します。

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 バグ番号 [ + | - | = ] タグ [ タグ ... ] [ + | - | = tag ... ] ]

バグ報告 #バグ番号 にタグを設定します。バグの報告者には通知されません。+ はそれに続くタグ をそれぞれ追加、- はそれに続くタグをそれぞれ削除、 =はそれに続くタグを新しく付けなおすことをそれぞれ意味します。 +, -, あるいは = が間にある場合はそれに続くタグへの動作を変更します。デフォルトの動作は追加です。

使用例:

        # '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

        # 'moreinfo' タグを削除して 'patch' タグを追加
        tags 123456 - moreinfo + patch

現在、有効なタグには 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 があります。

これらの意味については、バグシステムに関する開発者情報で調べてください。

block バグ番号 by バグ ...

最初のバグの修正がリストの他のバグによって妨害されていることを記録します。

unblock バグ番号 by バグ ...

最初のバグ修正がリストの他のバグによって妨害されていたものが解除されたことを記録します。

close バグ番号 [ 修正されたバージョン ] (非推奨)

バグ報告 #バグ番号 を閉じます。

バグを報告したユーザに通知が送られますが、 (バグ番号[email protected] にメールを送った場合とは異なり) バグを閉じたメールの本文はその通知には 含まれません。バグ報告を閉じた担当者は、別にメッセージを送るなどして、どうしてそのバグが閉じられたのか、バグを報告したユーザが確実に分かるようにしなければなりません。こういうわけで、このコマンドの使用は非推奨となっています。バグの正しい閉じ方についての開発者情報を見てください。

修正されたバージョンを指示した場合は、バグ追跡システムはそのパッケージのそのバージョンでそのバグが修正されたことを記録します。

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 を使ってアーカイブできます。報告者の変更のような些細な変更をアーカイブされたバグに加えるためにアーカイブ解除を使うべきではありません。アーカイブ解除の本来の目的は BTS 管理者の手に拠らずアーカイブされたバグを再開できるようにすることです。

#...

一行コメントです。#は行頭になければなりません。コメント内のテキストは、送信者と関連する担当者への通知に含められるので、コマンドの理由を示すのに利用できます。

quit

stop

thank

thanks

thankyou

thank you

--

各行はどれも空白文字で続けることができます。制御サーバにメッセージの処理を停止することを伝えます — メッセージのリマインダとして説明、署名、その他を記入することができますが、制御サーバには検知されません。

その他の BTS ページ:

Debian BTS administrators <[email protected]>