1 files changed, 156 insertions, 0 deletions
diff --git a/markup/pod/live-manual/media/text/ja/project_bugs.ssi b/markup/pod/live-manual/media/text/ja/project_bugs.ssi
new file mode 100644
index 0000000..11018fb
--- /dev/null
+++ b/markup/pod/live-manual/media/text/ja/project_bugs.ssi
@@ -0,0 +1,156 @@
+:B~ バグの報告
+
+1~bugs バグの報告
+
+Live システムは完璧にはほど遠いですが、可能な限り完璧に近づけたいと思っています -
+あなたの支援とともに。バグの報告を躊躇わないでください。バグがあるのに報告されないよりも二重に報告される方がいいからです。この章ではバグ報告を提出するにあたっての推奨事項について説明します。
+
+せっかちな人向け:
+
+_* 常にまず http://live-systems.org/ にある私達のホームページにあるイメージの更新状況により既知の問題を確認してください。
+
+_* バグ報告を提出する前に使用している live-build、live-boot、live-config、live-tools
+のブランチの*{最新版}* (live-build 4 を使っているなら最新のバージョン 4.x の live-build)
+でそのバグを再現できるか常に確認します。
+
+_* バグについて*{できるだけ具体的な情報}*を提示するようにしてください。これには (最低限) 利用した
+live-build、live-boot、live-config、live-tools のバージョンや Live
+システムをどのディストリビューションでビルドしたのか、等があります。
+
+2~ 既知の問題
+
+Debian *{テスト版 (testing)}* と Debian *{不安定版 (unstable)}*
+ディストリビューションは変化しているのでこのどちらかを対象システムディストリビューションに指定している場合、ビルドが常に成功するとは限りません。
+
+% FIXME:
+
+そのためにあまり困難になる場合はビルドに*{テスト版 (testing)}* や*{不安定版 (unstable)}*
+をベースにしたシステムではなく*{安定版 (stable)} を使ってください。live-build は常に*{安定版 (stable)}*
+リリースをデフォルトとしています。
+
+現在わかっている問題は http://live-systems.org/ にある私達のホームページの「status」に一覧があります。
+
+開発用ディストリビューションのパッケージにある問題を正しく識別、修正するための訓練はこのマニュアルの目的ではありませんが、常に確認できることが2つあります:
+*{テスト版 (testing)}* を対象ディストリビューションとしてビルドに失敗した場合に*{不安定版 (unstable)}*
+で試してみるということです。*{不安定版 (unstable)}* でもダメな場合は*{テスト版 (testing)}*
+に差し戻し、失敗しているパッケージのもっと新しいバージョンを*{不安定版 (unstable)}* から利用するようにしてみます (詳細については
+{APTのPIN設定}#apt-pinning 参照)。
+
+2~ 最初から再ビルド
+
+きれいではない環境でシステムがビルドされたことにより特定のバグが発生しているのではないことを保証するため、Live
+システム全体を最初から再ビルドして、そのバグが再現するか常に確認してください。
+
+2~ 最新のパッケージを使う
+
+問題を再現 (最終的には修正)
+しようとするときに古くなったパッケージを使用すると重大な問題を引き起こす可能性があります。ビルドシステムが最新であること、同様にそのイメージに収録されているパッケージがどれも最新であることを確認してください。
+
+2~collect-information 情報収集
+
+報告では十分な情報を提供してください。最低でもそのバグが発生した live-build
+の正確なバージョンとそれを再現する手順を含めてください。常識的に考えて問題解決の支援になりそうだと思う関連情報が何か他にあればそれも提供してください。
+
+バグ報告を最大限に活用するため、最低限次の情報が必要です:
+
+_* ホストシステムのアーキテクチャ
+
+_* ホストシステムのディストリビューション
+
+_* ホストシステムの live-build のバージョン
+
+_* ホストシステムの /{debootstrap}/ のバージョン
+
+_* Live システムのアーキテクチャ
+
+_* Live システムのディストリビューション
+
+_* Live システムの live-boot のバージョン
+
+_* Live システムの live-config のバージョン
+
+_* Live システムの live-tools のバージョン
+
+#{tee}# コマンドを使ってビルドプロセスのログを生成することができます。#{auto/build}#
+スクリプトによりこれを自動的に行うことを推奨します (詳細は{設定管理}#managing-a-configuration 参照)。
+
+code{
+
+ # lb build 2>&1 | tee build.log
+
+}code
+
+ブート時に、live-boot と live-config はログファイルを #{/var/log/live/}#
+に保存します。エラーメッセージはここを確認してください。
+
+さらに、他のエラーを除外するため、#{config/}# ディレクトリを tar でまとめてどこかにアップロードするのは常に良い方法です
+(メーリングリストに添付として送ら*{ないでください}*)。それにより、そのエラーの再現を試みることが可能になります。それが
+(例えばサイズの問題により) 困難な場合は #{lb config --dump}# の出力を使ってください。これは設定ツリーのまとめです (つまり
+#{config/}# のサブディレクトリにあるファイル一覧を列挙しますがファイル自体は収録しません)。
+
+ログは全て英語のロケール設定で生成されたものを提示することを忘れないでください。例えば先頭に #{LC_ALL=C}# や
+#{LC_ALL=en_US}# を付けて live-build コマンドを実行してください。
+
+2~ 可能であれば失敗している状況を分離する
+
+可能であれば失敗している状況を可能な限りうまくいかなくなる最小の変更に分離してください。これは常に簡単だとは限らないので、報告の際にできないようであれば気にする必要はありません。しかし、開発サイクルを向上させたい場合、繰り返しのたびに変更する量を十分に小さくすると、実際の設定により近く、より単純な「ベース」設定を構成することによりうまくいかなくなる追加の変更点だけに問題を分離することができるかもしれません。どの変更によりうまくいかなくなっているのか区別するのに苦労している場合、それぞれの変更点が多すぎることが考えられ、その場合開発の進行は緩くなるはずです。
+
+2~ 正しいパッケージに対してバグを報告する
+
+どの構成要素がそのバグの原因なのかわからない、あるいはそのバグが Live システム全般に関係するバグである場合は debian-live
+疑似パッケージに対するバグとして報告してください。
+
+とはいうものの、バグの現れ方を元にその範囲を限定してくれると助かります。
+
+3~ ビルド時のパッケージ収集中
+
+live-build は最初に /{debootstrap}/ で Debian
+システムの基本的なパッケージを収集します。バグがここで起きていると思われる場合は、そのエラーが特定の Debian パッケージに
+(ほとんどの場合こちらです) 関連するのか、パッケージ収集ツール自体に関連するものなのか確認してください。
+
+どちらの場合でも、これは Live システムではなく Debian
+自体のバグで、恐らく私達が直接修正することはできません。こういったバグはパッケージ収集ツールまたは失敗しているパッケージに対して報告してください。
+
+3~ ビルド時のパッケージインストール中
+
+live-build は追加のパッケージを Debian アーカイブからインストールしているため、利用する Debian
+ディストリビューションとその日のアーカイブの状態によっては失敗するかもしれません。バグがここで起きていると思われる場合は、そのエラーが通常のシステムで再現できるか確認してください。
+
+通常のシステムで再現できる場合これは Live システムではなく Debian のバグです - 失敗しているパッケージに対して報告してください。Live
+システムのビルドとは別に /{debootstrap}/ を実行、あるいは #{lbbootstrap --debug}#
+を実行するとさらなる情報を得られるでしょう。
+
+また、ローカルミラーやプロキシの類を使っていて問題が起きている場合はまず、公式ミラーからパッケージを収集した場合に再現するか常に確認してください。
+
+3~ ブート時
+
+イメージがブートしない場合は{情報収集}#collect-information
+で指定している情報を添えてメーリングリストに報告してください。そのイメージが正確にどのように/どの段階で失敗しているのか、仮想化を使っているのか実際のハードウェアなのか、ということについて忘れずに言及してください。何らかの仮想化技術を使っている場合はバグを報告する前に常に実際のハードウェアで実行してください。失敗しているときのスクリーンショットを提供することも、とても参考になります。
+
+3~ 実行時
+
+パッケージのインストールには成功したけれども Live システムを実際に実行している間に何か失敗している場合、これは恐らく Live
+システムのバグです。その場合:
+
+2~ 調査してください
+
+バグを報告する前に、問題の症状やそのエラーメッセージについてウェブを検索してください。その問題に遭っているのがあなた一人だけだという可能性は非常に低いからです。他のどこかで議題に上り、解決できそうな方法やパッチ、回避策が提案されている可能性は常にあります。
+
+Live
+システムのメーリングリストや同様にホームページには。最新の情報がある可能性があるので、特に注意を払ってください。そういった情報が存在する場合は、バグ報告で常に参照するようにしてください。
+
+さらに、似たことが既に報告されていないか live-build、live-boot、live-config、live-tools
+の現在のバグ一覧を確認してください。
+
+2~ バグの報告先
+
+${project}ではバグ追跡システム (BTS) に報告されたバグを全て追跡しています。このシステムの使い方についての情報は
+https://bugs.debian.org/ を見てください。#{reportbug}#
+パッケージの同名コマンドを使ってバグを報告することもできます。
+
+一般的に、ビルド時のエラーは live-build に、ブート時のエラーは live-boot に、実行時のエラーは live-config
+パッケージに対して報告してください。どのパッケージが適切なのかよくわからない、あるいはバグの報告前にもっと支援が必要だという場合は
+debian-live 疑似パッケージに対して報告してください。その場合は私達が調べて適切なものに割り当てし直します。
+
+(Ubuntu その他の) Debian 派生ディストリビューションで見つかったバグは、それが公式の Debian パッケージを使っている Debian
+システムでも再現するものでない限り、Debian BTS に報告すべきでは*{ない}*ことに注意してください。