ありがとうございます。 修正しました。 差分を貼りつけておきます。 1行が長いため読みづらいですが。。。 titanpad の方にも反映しておきました。 diff --git chapter-bugs.sgml chapter-bugs.sgml index 5a71d6a..c2cb46a 100644 --- chapter-bugs.sgml +++ chapter-bugs.sgml @@ -20,7 +20,7 @@ --> <p> - 報告者は問題のあるカーネルバージョンの環境下で <prgn>reportbug</prgn> か、それ以外の <package>bug</package> スクリプトを実行するツールを使用することを求められます。この情報のない報告に対する回答として <prgn>reportbug</prgn> を使用するよう、フォローアップリクエストが行われます。リクエストがあってから 1 ヶ月以内に必要な情報を私たちが受け取らなかった場合、バグは閉じられる場合がります。 + 報告者は問題のあるカーネルバージョンの環境下で <prgn>reportbug</prgn> か、それ以外の <package>bug</package> スクリプトを実行するツールを使用することを求められます。この情報のない報告に対する回答として <prgn>reportbug</prgn> を使用するよう、フォローアップリクエストが行われます。リクエストがあってから 1 ヶ月以内に必要な情報を私たちが受け取らなかった場合、バグは閉じられる場合があります。 </p> <p> @@ -443,7 +443,7 @@ to see whether something similar has been reported already. --> <item> <em>調査を行う</em>: - バグ報告を行う前に特定のエラーメッセージや症状に関して web 上で検索を行いましょうあなただけがある問題に遭遇しているというのは極めて稀なケースです。常に、すでにどこかで議論されており、解決策や回避策やパッチが既に提示されている可能性が高いと考えるべきです。もしそのような情報が存在する場合は、常にバグレポート内に参照先を示すようにしましょう。すでに同様の報告がされているかどうかについては、<url id="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=linux&src=linux-2.6" name="現在のバグ一覧">を確認してください。</item> + バグ報告を行う前に特定のエラーメッセージや症状に関して web 上で検索を行いましょう。あなただけがある問題に遭遇しているというのは極めて稀なケースです。常にすでにどこかで議論されており、解決策や回避策やパッチが既に提示されている可能性が高いと考えるべきです。もしそのような情報が存在する場合は、常にバグレポート内に参照先を示すようにしましょう。すでに同様の報告がされているかどうかについては、<url id="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=linux&src=linux-2.6" name="現在のバグ一覧">を確認してください。</item> <!-- <em>Collect the information.</em> Please provide enough @@ -462,7 +462,7 @@ if you think that it might help in solving the problem. --> <item> <em>情報を収集する</em>: - バグレポートには充分な情報を提供してください。レポートには最低限でも、バグに遭遇した Debian 公式カーネルパッケージのバージョンと、再現方法を記載してください。あなたが報告するバグの性質によっては、<tt>dmesg</tt> の出力 (または、その一部) と <tt>lspci -vn</tt> の出力も報告してください。<prgn>reportbug</prgn> は、これを自動で行います。あてはまる場合には、知りうる限りバグが発生しない最新のカーネルバージョンと動作しているカーネルに対する上記のコマンド出力も報告してください。あなたの common sense を使い、あなたが問題の解決の手助けになると思う情報を付加してください。</item> + バグレポートには充分な情報を提供してください。レポートには最低限でも、バグに遭遇した Debian 公式カーネルパッケージの正確なバージョンと、再現方法を記載してください。あなたが報告するバグの性質によっては、<tt>dmesg</tt> の出力 (または、その一部) と <tt>lspci -vn</tt> の出力も報告してください。<prgn>reportbug</prgn> は、これを自動で行います。あてはまる場合には、知りうる限りバグが発生しない最新のカーネルバージョンと動作しているカーネルに対する上記のコマンド出力も報告してください。常識的に考えて問題の解決の手助けになると思う情報があればそれを付加してください。</item> <!-- <em>Try to reproduce the problem with "vanilla" kernel.</em> @@ -485,7 +485,7 @@ --> <item> <em> "vanilla" カーネルで再現させる</em>: - 機会があれば、"vanilla" カーネルからビルドした バイナリカーネルイメージで再現できるか試してみてください。vanilla カーネルのソースは<url id="http://www.kernel.org" name="http://www.kernel.org"> か、そのミラーから入手することができます。Debian の stock カーネルと同じ設定を使用してください。これをどのように実施するか、さらに詳しい情報は、<ref id="common-building">を参照して下さい。もしバグがカーネルに対して行なわれた Debian 特有の変更が原因であるという説得力のある証拠があれば、バグはカーネルチームによってより高い優先度をつけられます。もしバグが Debian 特有のものでない場合は、すでにアップストリームで報告済みでないか<url id="http://bugzilla.kernel.org" name="kernel bug database">を確認してください。 アップストリームの問題であることが明確な場合は、そちらにもバグ報告をすることができます。(いずれにせよ、その問題を追跡できるように Debian BTS には報告してください。)</item> + 機会があれば、"vanilla" カーネルからビルドした バイナリカーネルイメージで再現できるか試してみてください。vanilla カーネルのソースは<url id="http://www.kernel.org" name="http://www.kernel.org"> か、そのミラーから入手することができます。Debian の stock カーネルと同じ設定を使用してください。これをどのように実施するか、さらに詳しい情報は、<ref id="common-building">を参照して下さい。もしバグがカーネルに対して行なわれた Debian 特有の変更が原因であるという説得力のある証拠があれば、バグはカーネルチームによってより高い優先度をつけられます。もしバグが Debian 特有のものでない場合は、すでにアップストリームで報告済みでないか<url id="http://bugzilla.kernel.org" name="カーネルバグデータベース">を確認してください。 アップストリームの問題であることが明確な場合は、そちらにもバグ報告をすることができます。(いずれにせよ、その問題を適切に追跡できるように Debian BTS には報告してください。)</item> <!-- <em>Use the correct package to report the bug against.</em> @@ -496,7 +496,7 @@ --> <item> <em>正しいパッケージに対してバグ報告をする</em>: - バグ報告は、問題が発生したカーネルのバージョン番号を持つパッケージに対して行いメタパッケージ (e.g. <package>linux-image-686-pae</package>) には報告しないでください。</item> + バグ報告は、問題が発生したカーネルのバージョン番号を持つパッケージ (e.g. <package>linux-image-3.2.0-2-686-pae</package>) に対して行いメタパッケージ (e.g. <package>linux-image-686-pae</package>) には報告しないでください。</item> <!-- <em>Bugs involving tainted kernels.</em> If a kernel @@ -516,7 +516,7 @@ --> <item> <em>tainted カーネルに関連するバグ</em>: - カーネルがクラッシュした場合、通常はデバッグ情報を出力します。これには、動作中だったカーネルが taint (汚染) だったかも含まれています。クラッシュ時にサードパーティ製のバイナリモジュールがロードされていたカーネルは tainted (汚染された) と表現されます。カーネル開発者がソースコードを見ることができないので、そのようなモジュールが絡んだ問題はデバッグが非常に困難になります。そのような事情から、(例えばバイナリモジュールをロードしないようにするなどして) untainted (汚染されていない) カーネルで再現できるか試してみることを強くおすすめします。問題がそのようなモジュールの内部に起因するものであれば、カーネルコミュニティができることはあまりありませんので、直接モジュールの作成者に報告すると良いでしょう。</item> + カーネルがクラッシュした場合、通常はデバッグ情報を出力します。これには、動作中だったカーネルが taint (汚染) だったかも含まれています。クラッシュ時にサードパーティ製のバイナリモジュールがロードされていたカーネルは tainted (汚染された) と表現されます。カーネル開発者がソースコードを見ることができないので、そのようなモジュールが絡んだ問題はデバッグが非常に困難になります。そのような事情から、(例えばバイナリモジュールをロードしないようにするなどして) untainted (汚染されていない) カーネルで再現できるか試してみることを強くおすすめします。問題がそのようなモジュールの存在に起因するものであれば、カーネルコミュニティができることはあまりありませんので、直接モジュールの作成者に報告すると良いでしょう。</item> </list> </p> @@ -566,7 +566,7 @@ $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git $ cd linux </example> - 上記のコマンドで vanilla カーネルを取得します。<ref id="common-building">で説明したバイナリパッケージの設定、ビルド、テストを行うには: + 上記のコマンドで vanilla カーネルを取得します。<ref id="common-building">で説明したバイナリパッケージの設定、ビルド、テストを行います: <example> $ make localmodconfig; # 最低限の設定
Attachment:
signature.asc
Description: Digital signature