BugReport

Contents

バグ報告を始める
詳細な説明を入力する
1. レポートの確認
2. バグ報告のよくあるテンプレート

Ubuntuにおいて「バグ」とは欠陥に限らず、使いにくさも含む広義の「バグ」です。

バグ報告は基本的に Launchpad を使って行います。そのため、バグ報告をする場合は、予め Launchpad のアカウントを取得しておいてください。(アカウントの取得方法についてはこちらをご覧ください)

Launchpad は基本的に英語のみでの受付となります。
日本語でバグ報告したい場合は Ubuntu Japanese Kaizen Project に報告してください。報告の仕方は、下記: Launchpadの「Report a bug」を使うの通りです。

バグ報告を始める

バグレポートは以下のいずれかの方法で作成してください。

「問題点を報告する」からレポートを作成する

Ubuntuに付属のソフトウェアの多くは、上部の「ヘルプ」メニュー内に「問題点を報告する」という項目があります。ここからバグレポートを作成する方法を説明します。

問題があるソフトウェアの「ヘルプ」>「問題点を報告する」をクリックします。
不具合の情報(コンピュータの情報など)を収集すると、送信確認画面が表示されます。「レポートを送信」をクリックしてください。
Webブラウザが起動し、「Report a bug」のページが表示されるので、詳細な説明を入力するに進んでください。

端末からレポートを作成する

ソフトウェアに「問題を報告する」がない場合や、端末ベースのソフトウェアの場合は、「アプリケーション」>「アクセサリ」>「端末」で以下のコマンドを入力することでバグレポートを作成できます。

$ ubuntu-bug [process_id|program_name]

[process_id|program_name]の部分は、例えば「firefox」のように入力するか、「システム・モニタ」の「プロセス」の「ID」欄の数値を入力してください。

コマンドを実行すると、「問題点を報告する」と同様の画面になります。

Launchpadの「Report a bug」を使う

パッケージ名が分からない場合や、PPAの追加リポジトリのパッケージについてバグ報告する場合、また、Ubuntu Japanese Kaizen Projectに報告する場合は、Launchpadのプロジェクトページ右側の「Report a bug」というリンクをクリックしてください。この場合は使用中のパソコンの情報が自動送信されません。必要に応じて、パソコンの情報を報告フォームで手動入力してください。> ハードウェア情報を調べるには

詳細な説明を入力する

バグ報告をするには、詳細な説明を入力する必要があります。

1.「Report a bug」の「Summary」欄に簡単な説明を入力し、「Next」をクリックします。10語以内で簡単な単語がいいでしょう。
Summaryに入力したワードから、既出のバグがリスト表示されます。似ているバグがリスト上にない場合は「No, I need to report a new bug」をクリックしてください。
「Further information」欄に、細かい説明を入力します。バグの場合は、再現するための手順(Step to repro)を書くと分かりやすくなるでしょう。また「Extra options」でファイルを添付できます。GUIの表示上のバグの場合など、スクリーンショットが必要と思われる場合は添付しましょう。
バグレポートが完成したら、「Submit Bug Report」をクリックしてください。コメントやバグに関する情報が入ると、メールが送られてきます。

レポートの確認

バグレポートを作成したら、次のことを確認しましょう。

「Summary」に充分な情報が含まれているか

バグレポートのSummaryは、メールなどのSubjectとして、あるいはバグ一覧での見出しとして使われる情報です。できるだけ分かりやすく、キーワードを含んだものにする必要があります。
Summaryのできるだけ先頭にアプリケーション名が入るようにしましょう。
- 最悪な例：geditがおかしいので直してください
- 悪い例：geditがクラッシュする
- 良い例：日本語環境でgeditのフォントの設定ダイアログを開くとクラッシュする
- より良い例：geditが、フォントの設定ダイアログを開くとクラッシュする(日本語環境のみ)

バグレポートに複数の問題が含まれていないか

バグレポートは、1つの問題に対して1つのレポートを行うようにしましょう。複数の問題を同時に報告すると、書くのも読むのも非常に大変になります。

バグレポートに充分な客観性があるか

アプリケーションのバグの場合、再現手順（Step to reproduce）として「アプリケーションを起動するところから、バグが再現するところまで」1手順ずつ書きましょう。
具体的な手順にし、省略しないようにしましょう。
主観的な指摘は含めないようにしましょう。
- 悪い例：geditを起動し、フォントの設定を開くと再現します。
- 悪い例：アプリケーション→アクセサリ→gedit テキストエディタを開いて gedit を起動します。次に、メニューを編集→設定とたどり、「フォントと色」タブを開きます。バグが再現します。ついでに、このフォントは汚いと思いますし、どうにかならないでしょうか。
- 良い例：アプリケーション→アクセサリ→gedit テキストエディタを開いて gedit を起動します。次に、メニューを編集→設定とたどり、「フォントと色」タブを開きます。バグが再現します。

なぜそれがバグだと判断したのかを書きましょう

ある挙動に問題があると思われる場合、読んだ人が誰でも、それがバグであると分かるように書きましょう。バグであると判断した理由を書くのが一番です。
「期待する挙動」（Expected result）と「実際の挙動」（Actual result）を書きましょう。
- 例：
  - Expected result : ダイアログが表示される。
  - Actual result : ダイアログが表示されず、アプリケーションがクラッシュし、Aportによって「アプリケーションがクラッシュしました」という報告が行われる。

ハードウェアに関わるバグの場合、構成を書きましょう

特定のハードウェアでだけ問題が発生する（と思われる）場合、問題を整理するためには具体的なハードウェア情報が必要です。分かっている範囲で、詳細なハードウェア情報を記載しましょう。多くの場合、以下のような情報が必須です。
- 「sudo lspci -vv」や「sudo lshw」の出力。これらは非常に長くなるので、バグレポートに添付しましょう。
- 具体的なハードウェア製品名。
- どういう時に問題が発生するのか。何もしなくてもしばらく待てば問題が発生するのか、特定の操作で問題が起きるのか、といった情報（たとえば「マウスを動かしていると」「ウインドウを動かしていると」「起動時に三割程度の確率で」など）。
- 悪い例：
  - ノートPCがフリーズします。CPUはCeleronです。
  - Ubuntuが起動できません。使っているのはVAIOです。
  - 印刷すると色が違います。インクジェットプリンタを使っています。
- 良い例（注：実際に発生する問題ではありません）：
  - Lenovo Thinkpad X200（TYPE:7454-A26）で、起動時、GRUBが終わった後の起動ロゴ（Ubuntuロゴが表示され、「●」インジケータが表示される画面）で画面が崩れることがあります。発生確率は体感で3割程度です。起動時に、本体左側面手前についている、無線スイッチをOffにしていると再現しません。

バグ報告のよくあるテンプレート

...最初に現象の概略を書く...

[How To Reproduce]

...現象を再現させるまでの手順を書く...

[Actual Result]

...どのような現象が発生するのかを書く...

[Expected Result]

...本来なら、どのような動作が起こるべきかを書く...

[How To Fix](任意)

...根本的に問題を解決するパッチなどがあれば書く...

[Workaround](任意)

...なんらかの方法で、問題を回避できる場合はその方法を書く...

Ubuntu Japanese LoCo Wiki