Skip to content

Instantly share code, notes, and snippets.

/bugzilla-howto.xml

Created May 29, 2011 13:38
Show Gist options
  • Save anonymous/997787 to your computer and use it in GitHub Desktop.
Save anonymous/997787 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
bugzilla-howto.xml
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="ja">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link title="new" rel="stylesheet" href="../../css/main.css" type="text/css">
<link REL="shortcut icon" HREF="../../favicon.ico" TYPE="image/x-icon">
<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/www-gentoo-org.xml" title="Gentoo Website">
<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/forums-gentoo-org.xml" title="Gentoo Forums">
<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/bugs-gentoo-org.xml" title="Gentoo Bugzilla">
<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/packages-gentoo-org.xml" title="Gentoo Packages">
<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/archives-gentoo-org.xml" title="Gentoo List Archives">
<title>Gentoo Linux Documentation
--
Gentoo バグ報告指南</title>
</head>
<body style="margin:0px;" bgcolor="#ffffff"><table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr><td valign="top" height="125" bgcolor="#45347b"><a href="/"><img border="0" src="../../images/gtop-www.jpg" alt="Gentoo Logo"></a></td></tr>
<tr><td valign="top" align="right" colspan="1" bgcolor="#ffffff"><table border="0" cellspacing="0" cellpadding="0" width="100%"><tr>
<td width="99%" class="content" valign="top" align="left">
<br><h1>Gentoo バグ報告指南</h1>
<form name="contents" action="http://www.gentoo.org">
<b>目次</b>:
<select name="url" size="1" OnChange="location.href=form.url.options[form.url.selectedIndex].value" style="font-family:sans-serif,Arial,Helvetica"><option value="#doc_chap1">1. はじめに</option>
<option value="#doc_chap2">2. GDB を使ってデバッグ作業</option>
<option value="#doc_chap3">3. strace を使ってファイルアクセスエラーを発見</option>
<option value="#doc_chap4">4. emerge エラーの扱い方</option>
<option value="#doc_chap5">5. Bugzilla の検索方法</option>
<option value="#doc_chap6">6. バグの報告のし方</option>
<option value="#doc_chap7">7. バグの処理</option>
<option value="#doc_chap8">8. Testing Ebuilds</option></select>
</form>
<p class="chaphead"><a name="doc_chap1"></a><span class="chapnum">1. 
</span>はじめに</p>
<p class="secthead"><a name="doc_chap1_sect1">まえがき</a></p>
<p>
バグをつぶすのが遅れてしまう原因のひとつに、 バグ報告の方法がまずかったということが挙げられる。
この指南が、 開発者と利用者がバグの解決に向けてよりよい交流を図れる一助となることを我々は願っている。
どんなプロジェクトにあっても、 品質保証にバグ処置が果たす役割は決定的でなくとも重要であり、 願わくばこの指南でプロジェクトの成功に貢献したい。
One of the factors that delay a bug being fixed is the way it is reported. By
creating this guide, we hope to help improve the communication between
developers and users in bug resolution. Getting bugs fixed is an important, if
not crucial part of the quality assurance for any project and hopefully this
guide will help make that a success.
</p>
<p class="secthead"><a name="doc_chap1_sect2">バグです!!!!</a></p>
<p>
パッケージを emerge していたとき、 あるいはプログラムを使っていたとき突如問題が発生、 つまりバグが現れたとしよう。
バグとひとくちに言っても、 emerge が失敗するとかセグメント違反が発生するとかいろいろその出方は異なる。
原因が何であれ、 とどのつまりその手のバグは潰さねばならぬ。 どんなバグがあるか少し例を示そう。
You're emerge-ing a package or working with a program and suddenly the worst
happens -- you find a bug. Bugs come in many forms like emerge failures or
segmentation faults. Whatever the cause, the fact still remains that such a bug
must be fixed. Here is a few examples of such bugs.
</p>
<a name="doc_chap1_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 1.1: A run time error</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
$ <span class="code-input">./bad_code `perl -e 'print "A"x100'`</span>
Segmentation fault
</pre></td></tr>
</table>
<a name="doc_chap1_pre2"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 1.2: An emerge failure</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/g++-v3/backward/backward_warning.h:32:2:
warning: #warning This file includes at least one deprecated or antiquated
header. Please consider using one of the 32 headers found in section 17.4.1.2 of
the C++ standard. Examples include substituting the &lt;X&gt; header for the &lt;X.h&gt;
header for C++ includes, or &lt;sstream&gt; instead of the deprecated header
&lt;strstream.h&gt;. To disable this warning use -Wno-deprecated.
In file included from main.cc:40:
menudef.h:55: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:62: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:70: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:78: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
main.cc: In member function `void OXMain::DoOpen()':
main.cc:323: warning: unused variable `FILE*fp'
main.cc: In member function `void OXMain::DoSave(char*)':
main.cc:337: warning: unused variable `FILE*fp'
make[1]: *** [main.o] Error 1
make[1]: Leaving directory
`/var/tmp/portage/xclass-0.7.4/work/xclass-0.7.4/example-app'
make: *** [shared] Error 2
!!! ERROR: x11-libs/xclass-0.7.4 failed.
!!! Function src_compile, Line 29, Exitcode 2
!!! 'emake shared' failed
</pre></td></tr>
</table>
<p>
こういうエラーは本当に困りものだ。
いやまて、 見付かったはいいがそのあとどうすればいいんだろう。
つぎの節に重要な2つのツールを紹介する。 これでランタイムエラーが処理できるのだ。
そのあとにコンパイルエラーの話をして、 その扱い方も論じよう。
さてまずはランタイムエラーをデバッグする
<span class="code" dir="ltr">gdb</span> から始めようか。
These errors can be quite troublesome. However, once you find them, what do you
do? The following sections will look at two important tools for handling run
time errors. After that, we'll take a look at compile errors, and how to handle
them. Let's start out with the first tool for debugging run time errors --
<span class="code" dir="ltr">gdb</span>.
</p>
<p class="chaphead"><a name="doc_chap2"></a><span class="chapnum">2. 
</span>GDB を使ってデバッグ作業</p>
<p class="secthead"><a name="doc_chap2_sect1">はじめに</a></p>
<p>
GDB [(G)NU (D)e(B)ugger の略] というプログラムは、 ランタイムエラーを発見するのに使う。 通常このエラーはメモリーの不正を引き起こす。
具体的にデバッグって何をすればいいのか、 まずはそれから見てゆこう。
プログラムをデバッグするときに大事な作業がある。
<span class="code" dir="ltr">FEATURES="nostrip"</span> というオプションつきでプログラムを <span class="code" dir="ltr">emerge</span> しなおすのだ。
これで、 プログラムに埋め込まれたデバッグ用指標が切除 (strip) されるのを防ぐ。
ところでなぜデフォルトではプログラムが strip されるのだろう。
その理由は man ページが gzip 圧縮される理由と重なる。 つまり省スペース化だ。
プログラムが strip された場合とされない場合とでそのサイズがどれほど違うかをご覧に入れよう。
GDB, or the (G)NU (D)e(B)ugger, is a program used to find run time errors that
normally involve memory corruption. First off, let's take a look at what
debugging entails. One of the main things you must do in order to debug a
program is to <span class="code" dir="ltr">emerge</span> the program with <span class="code" dir="ltr">FEATURES="nostrip"</span>. This
prevents the stripping of debug symbols. Why are programs stripped by default?
The reason is the same as that for having gzipped man pages -- saving space.
Here's how the size of a program varies with and without debug symbol stripping.
</p>
<a name="doc_chap2_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 2.1: ファイル容量の比較</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
<span class="code-comment">(debug symbols stripped)</span>
-rwxr-xr-x 1 chris users 3140 6/28 13:11 bad_code
<span class="code-comment">(debug symbols intact)</span>
-rwxr-xr-x 1 chris users 6374 6/28 13:10 bad_code
</pre></td></tr>
</table>
<p>
ちなみに <span class="emphasis">bad_code</span> はこれから <span class="code" dir="ltr">gdb</span> でデバッグされるプログラムだ。
ご覧のとおりデバッグ用指標が無ければプログラムは 3140 バイトになるが、 残すと 6374 バイトにもなる。 ほとんど2倍近い。
そのほかに2件、 デバッグ前にしておくとよいことがある。
まず CFLAGS と CXXFLAGS に <span class="code" dir="ltr">ggdb</span> を追加しておこう。
このフラグがあれば通常よりも多めにデバッグ用情報がプログラムに埋め込まれる。
どうなるかはあとで説明しよう。
フラグの追加で <span class="path" dir="ltr">/etc/make.conf</span> がどんな感じに
<span class="emphasis">なりそう</span> か例を示す。
Just for reference, <span class="emphasis">bad_code</span> is the program we'll be debugging with
<span class="code" dir="ltr">gdb</span> later on. As you can see, the program without debugging symbols is
3140 bytes, while the program with them is 6374 bytes. That's close to double
the size! Two more things can be done for debugging. The first is adding
<span class="code" dir="ltr">ggdb</span> to your CFLAGS and CXXFLAGS. This flag adds more debugging
information than is generally included. We'll see what that means later on. This
is how <span class="path" dir="ltr">/etc/make.conf</span> <span class="emphasis">might</span> look with the newly added flags.
</p>
<a name="doc_chap2_pre2"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 2.2: make.conf settings</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
CFLAGS="-O1 -pipe -ggdb"
CXXFLAGS="${CFLAGS}"
</pre></td></tr>
</table>
<p>
もう1件はパッケージの USE フラグにもデバッグ指示をつけるというもの。
<span class="path" dir="ltr">package.use</span> ファイルを編集するとよい。
Lastly, you can also add debug to the package's USE flags. This can be done
with the <span class="path" dir="ltr">package.use</span> file.
</p>
<a name="doc_chap2_pre3"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 2.3: Using package.use to add debug USE flag</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">echo "category/package debug" &gt;&gt; /etc/portage/package.use</span>
</pre></td></tr>
</table>
<table class="ncontent" width="100%" border="0" cellspacing="0" cellpadding="0"><tr><td bgcolor="#bbffbb"><p class="note"><b>注記: </b>
<span class="path" dir="ltr">/etc/portage</span> というディレクトリは初めは存在しないのでまだ作っていなければ作成しよう。
既に <span class="path" dir="ltr">package.use</span> ファイルでこのパッケージに USE フラグがついていたときはお好みのエディターで編集することになる。
The directory <span class="path" dir="ltr">/etc/portage</span> does not exist by default and you may
have to create it, if you have not already done so. If the package already has
USE flags set in <span class="path" dir="ltr">package.use</span>, you will need to manually modify them
in your favorite editor.
</p></td></tr></table>
<p>
以上、 変更をつぎのように施したうえでパッケージを emerge しなおす。
Then we re-emerge the package with the modifications we've done so far as shown
below.
</p>
<a name="doc_chap2_pre4"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 2.4: Re-emergeing a package with debugging</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">FEATURES="nostrip" emerge package</span>
</pre></td></tr>
</table>
<p>
これでデバッグ用指標が準備できたから、 いよいよプログラムのデバッグに入る。
Now that debug symbols are setup, we can continue with debugging the program.
</p>
<p class="secthead"><a name="doc_chap2_sect2">GDB 上でプログラムを走らせる</a></p>
<p>
"bad_code" という名前のプログラムがあるとする。
そして誰かがプログラムのクラッシュを報告し、 その実例を提供したとしよう。
あなたはこれを聞いてテストをした。
Let's say we have a program here called "bad_code". Some person claims that the
program crashes and provides an example. You go ahead and test it out:
</p>
<a name="doc_chap2_pre5"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 2.5: Breaking The Program</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
$ <span class="code-input">./bad_code `perl -e 'print "A"x100'`</span>
Segmentation fault
</pre></td></tr>
</table>
<p>
この人物の言うとおりだ。 確かにプログラムが壊れているのだからバグはある。
いよいよ事件解決に <span class="code" dir="ltr">gdb</span> が登場する場面だ。
<span class="code" dir="ltr">gdb</span> に <span class="code" dir="ltr">--args</span>
を使って引数を渡し走らせてみた。
It seems this person was right. Since the program is obviously broken, we have
a bug at hand. Now, it's time to use <span class="code" dir="ltr">gdb</span> to help solve this matter. First
we run <span class="code" dir="ltr">gdb</span> with <span class="code" dir="ltr">--args</span>, then give it the full program with
arguments like shown:
</p>
<a name="doc_chap2_pre6"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 2.6: Running Our Program Through GDB</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
$ <span class="code-input">gdb --args ./bad_code `perl -e 'print "A"x100'`</span>
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
</pre></td></tr>
</table>
<table class="ncontent" width="100%" border="0" cellspacing="0" cellpadding="0"><tr><td bgcolor="#bbffbb"><p class="note"><b>注記: </b>
コアダンプを使ってデバッグする場合もある。
コアファイルには gdb からプログラムを起動して得られるのと同じ情報が入っている。
bad_code プログラムとコアファイルでデバッグするときは
<span class="code" dir="ltr">gdb ./bad_code core</span> (core はコアファイルの名前) というふうにしよう。
One can also debug with core dumps. These core files contain the same
information that the program would produce when run with gdb. In order to debug
with a core file with bad_code, you would run <span class="code" dir="ltr">gdb ./bad_code core</span> where
core is the name of the core file.
</p></td></tr></table>
<p>
"(gdb)" というプロンプトが現れ入力待ちとなる。 まずはプログラムを走らせるべし。
コマンド行に
<span class="code" dir="ltr">run</span> と記入して送るとこんな反応が返る。
You should see a prompt that says "(gdb)" and waits for input. First, we have to
run the program. We type in <span class="code" dir="ltr">run</span> at the command and receive a notice like:
</p>
<a name="doc_chap2_pre7"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 2.7: Running the program in GDB</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
(gdb) <span class="code-input">run</span>
Starting program: /home/chris/bad_code
Program received signal SIGSEGV, Segmentation fault.
0xb7ec6dc0 in strcpy () from /lib/libc.so.6
</pre></td></tr>
</table>
<p>
プログラムが始動したのがわかり、 SIGSEGV やセグメント違反が通知されている。
これはプログラムがクラッシュしたと GDB が伝えているのだ。
さらにプログラムがクラッシュした時点から辿れる最後の関数名が示される。
しかしこれはあまり役に立たない。 というのもプログラムの中では strcpy(3) をあちこちで使っているので、
そのどれが問題を起こしているか探るのは難しいからだ。
なんとか探る手段として、 後方追跡 (backtrace) というのをよくやる。
後方追跡はプログラムで呼び出されるすべての関数を始動位置から事故現場まで逆順に辿る。
クラッシュを引き起こさず復帰を終えている関数は後方追跡に現れない。
後方追跡の方法は、 (gdb) というプロンプトのあとに <span class="code" dir="ltr">bt</span> と送る。
するとこうなる。
Here we see the program starting, as well as a notification of SIGSEGV, or
Segmentation Fault. This is GDB telling us that our program has crashed. It
also gives the last run function it could trace when the program crashes.
However, this isn't too useful, as there could be multiple strcpy's in the
program, making it hard for developers to find which one is causing the issue.
In order to help them out, we do what's called a backtrace. A backtrace runs
backwards through all the functions that occurred upon program execution, to the
function at fault. Functions that return (without causing a crash) will not show
up on the backtrace. To get a backtrace, at the (gdb) prompt, type in <span class="code" dir="ltr">bt</span>.
You will get something like this:
</p>
<a name="doc_chap2_pre8"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 2.8: Program backtrace</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
(gdb) <span class="code-input">bt</span>
#0 0xb7ec6dc0 in strcpy () from /lib/libc.so.6
#1 0x0804838c in run_it ()
#2 0x080483ba in main ()
</pre></td></tr>
</table>
<p>
追跡パターンがはっきりしてきた。 main() がまず呼び出され、 つぎに run_it() が来て、 run_it() 内のどこかに問題の strcpy() がある。
こうなれば開発者にとって問題の絞り込みもしめたもの。
この出力には多少の例外がある。
第一にデバッグ用指標を残す
<span class="code" dir="ltr">FEATURES="nostrip"</span> オプションを忘れたらどうだろう。
デバッグ用指標が切除された場合、 出力はつぎのようになる。
You can notice the trace pattern clearly. main() is called first, followed by
run_it(), and somewhere in run_it() lies the strcpy() at fault. Things such as
this help developers narrow down problems. There are a few exceptions to the
output. First off is forgetting to enable debug symbols with
<span class="code" dir="ltr">FEATURES="nostrip"</span>. With debug symbols stripped, the output looks something
like this:
</p>
<a name="doc_chap2_pre9"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 2.9: Program backtrace With debug symbols stripped</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
(gdb) <span class="code-input">bt</span>
#0 0xb7e2cdc0 in strcpy () from /lib/libc.so.6
#1 0x0804838c in ?? ()
#2 0xbfd19510 in ?? ()
#3 0x00000000 in ?? ()
#4 0x00000000 in ?? ()
#5 0xb7eef148 in libgcc_s_personality () from /lib/libc.so.6
#6 0x080482ed in ?? ()
#7 0x080495b0 in ?? ()
#8 0xbfd19528 in ?? ()
#9 0xb7dd73b8 in __guard_setup () from /lib/libc.so.6
#10 0xb7dd742d in __guard_setup () from /lib/libc.so.6
#11 0x00000006 in ?? ()
#12 0xbfd19548 in ?? ()
#13 0x080483ba in ?? ()
#14 0x00000000 in ?? ()
#15 0x00000000 in ?? ()
#16 0xb7deebcc in __new_exitfn () from /lib/libc.so.6
#17 0x00000000 in ?? ()
#18 0xbfd19560 in ?? ()
#19 0xb7ef017c in nullserv () from /lib/libc.so.6
#20 0xb7dd6f37 in __libc_start_main () from /lib/libc.so.6
#21 0x00000001 in ?? ()
#22 0xbfd195d4 in ?? ()
#23 0xbfd195dc in ?? ()
#24 0x08048201 in ?? ()
</pre></td></tr>
</table>
<p>
この後方追跡にはたくさんの ?? という表示が出てくる。
デバッグ指標が無いため
<span class="code" dir="ltr">gdb</span> はプログラムがどんな動作をしたか判らないのだ。
したがってデバッグ指標を切除 (strip) <span class="emphasis">しない</span>
ことが不可欠だ。
さて先ほど -ggdb フラグについて触れた。 このフラグが有効な場合に出力がどうなるか見てみよう。
This backtrace contains a large number of ?? marks. This is because without
debug symbols, <span class="code" dir="ltr">gdb</span> doesn't know how the program was run. Hence, it is
crucial that debug symbols are <span class="emphasis">not</span> stripped. Now remember a while ago we
mentioned the -ggdb flag. Let's see what the output looks like with the flag
enabled:
</p>
<a name="doc_chap2_pre10"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 2.10: Program backtrace with -ggdb</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
(gdb) <span class="code-input">bt</span>
#0 0xb7e4bdc0 in strcpy () from /lib/libc.so.6
#1 0x0804838c in run_it (input=0x0) at bad_code.c:7
#2 0x080483ba in main (argc=1, argv=0xbfd3a434) at bad_code.c:12
</pre></td></tr>
</table>
<p>
これはさっきよりかなり開発者向けの情報がつまっている。
関数名の表示にとどまらずソースコードの行番号までも明示されている。
容量が許せばこれが一番よさそうな方法だ。
デバッグ用指標あり、 なし、 -ggdb 有効のそれぞれのプログラムがどれくらいのファイル容量になるかを示す。
Here we see that a lot more information is available for developers. Not only is
function information displayed, but even the exact line numbers of the source
files. This method is the most preferred if you can spare the extra space.
Here's how much the file size varies between debug, strip, and -ggdb enabled
programs.
</p>
<a name="doc_chap2_pre11"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 2.11: Filesize differences With -ggdb flag</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
<span class="code-comment">(debug symbols stripped)</span>
-rwxr-xr-x 1 chris users 3140 6/28 13:11 bad_code
<span class="code-comment">(debug symbols enabled)</span>
-rwxr-xr-x 1 chris users 6374 6/28 13:10 bad_code
<span class="code-comment">(-ggdb flag enabled)</span>
-rwxr-xr-x 1 chris users 19552 6/28 13:11 bad_code
</pre></td></tr>
</table>
<p>
ご覧のとおり、 -ggdb にするとデバッグ用指標入りと比べおよそ <span class="emphasis">13178</span> バイトもサイズが増えている。
しかし今まで見てきたとおりデバッグ情報が開発者の手に入るならファイルの肥大は価値がある。
後方追跡の出力はターミナル上で写し取ってファイル化できる。 (X 上のターミナルでないときは gpm を使う方法がある。
詳細は割愛するので写し取って貼り付けるやりかたについては
<a href="/doc/en/gpm.xml#doc_chap4">gpm の説明</a> を読んでほしい。)
以上、 <span class="code" dir="ltr">gdb</span> ですることはもうないので終了 (quit) しておこう。
As you can see, -ggdb adds about <span class="emphasis">13178</span> more bytes to the file size over
the one with debugging symbols. However, as shown above, this increase in file
size can be worth it if presenting debug information to developers. The
backtrace can be saved to a file by copying and pasting from the terminal (if
it's a non-x based terminal, you can use gpm. To keep this doc simple, I
recommend you read up on the <a href="/doc/en/gpm.xml#doc_chap4">documentation
for gpm</a> to see how to copy and paste with it). Now that we're done with
<span class="code" dir="ltr">gdb</span>, we can quit.
</p>
<a name="doc_chap2_pre12"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 2.12: Quitting GDB</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
(gdb) <span class="code-input">quit</span>
The program is running. Exit anyway? (y or n) <span class="code-input">y</span>
$
</pre></td></tr>
</table>
<p>
ここまでで <span class="code" dir="ltr">gdb</span> の話は終わる。
<span class="code" dir="ltr">gdb</span> を利用してもっと良いバグ報告ができるようになってほしいと思う。
だがしかし他にも実行時にプログラムがコケる種類のエラーがある。
そのひとつが不正なファイルアクセスをして起きるエラーだ。
こいつを見付けるとき <span class="code" dir="ltr">strace</span> という小粋なツールが使える。
This ends the walk-through of <span class="code" dir="ltr">gdb</span>. Using <span class="code" dir="ltr">gdb</span>, we hope that you
will be able to use it to create better bug reports. However, there are other
types of errors that can cause a program to fail during run time. One of the
other ways is through improper file access. We can find those using a nifty
little tool called <span class="code" dir="ltr">strace</span>.
</p>
<p class="chaphead"><a name="doc_chap3"></a><span class="chapnum">3. 
</span>strace を使ってファイルアクセスエラーを発見</p>
<p class="secthead"><a name="doc_chap3_sect1">はじめに</a></p>
<p>
プログラムは設定情報を読み出したりハードウェアにアクセスしたりログを書き出したりと、 たびたびファイルを利用している。
たまにプログラムはそういったファイルへ不正に接触することがある。
ここに斬り込むために <span class="code" dir="ltr">strace</span> というプログラムが作られた。
<span class="code" dir="ltr">strace</span> はメモリーやファイルを扱う呼び出し命令などのシステムコール (つまりその名前) を追跡する。
foobar2 という名前のプログラムを例として説明しよう。
これが foobar の新バージョンだという位置付けだ。
さて何とこれを foobar2 に更新してみたら設定情報がさっぱり見付からないときた。
foobar 第1版の設定で "foo" としてあるところが無視され、 デフォルトの "bar" が使われている。
Programs often use files to fetch configuration information, access hardware or
write logs. Sometimes, a program attempts to reach such files incorrectly. A
tool called <span class="code" dir="ltr">strace</span> was created to help deal with this. <span class="code" dir="ltr">strace</span>
traces system calls (hence the name) which include calls that use the memory and
files. For our example, we're going to take a program foobar2. This is an
updated version of foobar. However, during the change over to foobar2, you
notice all your configurations are missing! In foobar version 1, you had it
setup to say "foo", but now it's using the default "bar".
</p>
<a name="doc_chap3_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 3.1: Foobar2 With an invalid configuration</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
$ <span class="code-input">./foobar2</span>
Configuration says: bar
</pre></td></tr>
</table>
<p>
これまでの設定ではちゃんと foo にしてあったので
<span class="code" dir="ltr">strace</span> を使って何が起きているか探るとしよう。
Our previous configuration specifically had it set to foo, so let's use
<span class="code" dir="ltr">strace</span> to find out what's going on.
</p>
<p class="secthead"><a name="doc_chap3_sect2">Using strace to track the issue</a></p>
<p>
システムコールの成果を <span class="code" dir="ltr">strace</span> に記録させてみる。
そこで、 <span class="code" dir="ltr">strace</span> に -o[ファイル名] 対象 という形でオプションをつけて実行した。 対象は foobar2。
We make <span class="code" dir="ltr">strace</span> log the results of the system calls. To do this, we run
<span class="code" dir="ltr">strace</span> with the -o[file] arguments. Let's use it on foobar2 as shown.
</p>
<a name="doc_chap3_pre2"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 3.2: Running foobar2 through strace</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">strace -ostrace.log ./foobar2</span>
</pre></td></tr>
</table>
<p>
これで現在のディレクトリに <span class="path" dir="ltr">strace.log</span> という名前のファイルができる。
これを読むと、 関係しそうなところがあった。
This creates a file called <span class="path" dir="ltr">strace.log</span> in the current directory. We
check the file, and shown below are the relevant parts from the file.
</p>
<a name="doc_chap3_pre3"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 3.3: A Look At the strace Log</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
open(".foobar2/config", O_RDONLY) = 3
read(3, "bar", 3) = 3
</pre></td></tr>
</table>
<p>
ははん。 ここが問題点だな。 設定ディレクトリの位置は
<span class="path" dir="ltr">.foobar</span> だったのに <span class="path" dir="ltr">.foobar2</span> に変わっている。
ついでにプログラムは必ず "bar" を読むこともわかった。
こうした事例があるときは ebuild の保守担当者に連絡してユーザーに注意を促す表示をしてもらうようお願いしてもよい。
ただ今回は、 <span class="path" dir="ltr">.foobar</span> ディレクトリから設定ファイルの写しを持って来て従来の正しい結果を得ることにする。
Aha! So There's the problem. Someone moved the configuration directory to
<span class="path" dir="ltr">.foobar2</span> instead of <span class="path" dir="ltr">.foobar</span>. We also see the program
reading in "bar" as it should. In this case, we can recommend the ebuild
maintainer to put a warning about it. For now though, we can copy over the
config file from <span class="path" dir="ltr">.foobar</span> and modify it to produce the correct
results.
</p>
<p class="secthead"><a name="doc_chap3_sect3">Conclusion</a></p>
<p>
さてここまでは実行時のバグ発見に注意を払ってきた。
この手のバグはプログラムを動かしてみたり使っているときに問題が発覚する。
しかし実行時エラーもプログラムのコンパイルが通らないうちはほとんど注意を払うものとはならない。
<span class="code" dir="ltr">emerge</span> コンパイルエラーを address? する方法について見てゆこう。
Now we've taken care of finding run time bugs. These bugs prove to be
problematic when you try and run your programs. However, run time errors are
the least of your concerns if your program won't compile at all. Let's take a
look at how to address <span class="code" dir="ltr">emerge</span> compile errors.
</p>
<p class="chaphead"><a name="doc_chap4"></a><span class="chapnum">4. 
</span>emerge エラーの扱い方</p>
<p class="secthead"><a name="doc_chap4_sect1">はじめに</a></p>
<p>
先に挙げた例のような <span class="code" dir="ltr">emerge</span> エラーはユーザーの気を損ねる大きな原因になる。
こうしたことの報告は Gentoo の健全さを維持するうえで不可欠だ。
ebuild で foobar2 にビルドエラーがあるという想定例をみていただこう。
<span class="code" dir="ltr">emerge</span> errors, such as the one displayed earlier, can be a major cause
of frustration for users. Reporting them is considered crucial for maintaining
the health of Gentoo. Let's take a look at a sample ebuild, foobar2, which
contains some build errors.
</p>
<p class="secthead"><a name="emerge_error"></a><a name="doc_chap4_sect2">Evaluating emerge Errors</a></p>
<p>
とても単純な <span class="code" dir="ltr">emerge</span> エラーをここに示す。
Let's take a look at this very simple <span class="code" dir="ltr">emerge</span> error:
</p>
<a name="doc_chap4_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 4.1: emerge Error (long lines are manually wrapped to fit the window)</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2-7.o foobar2-7.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2-8.o foobar2-8.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2-9.o foobar2-9.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2.o foobar2.c
foobar2.c:1:17: ogg.h: No such file or directory
make: *** [foobar2.o] Error 1
!!! ERROR: sys-apps/foobar2-1.0 failed.
!!! Function src_compile, Line 19, Exitcode 2
!!! Make failed!
!!! If you need support, post the topmost build error, NOT this status message
</pre></td></tr>
</table>
<p>
順調にコンパイルが進んでいたプログラムが突如としてエラーメッセージを出して構築を止めた。
典型的なこのエラーはコンパイルメッセージとビルドエラーと emerge エラーメッセージの3つの部分からなる。
The program is compiling smoothly when it suddenly stops and presents an error
message. This particular error can be split into 3 different sections, The
compile messages, the build error, and the emerge error message as shown below.
</p>
<a name="doc_chap4_pre2"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 4.2: Parts of the error (long lines are manually wrapped to fit the window)</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
<span class="code-comment">(Compilation Messages)</span>
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2-7.o foobar2-7.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2-8.o foobar2-8.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2-9.o foobar2-9.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod \
-c -o foobar2.o foobar2.c
<span class="code-comment">(Build Error)</span>
foobar2.c:1:17: ogg.h: No such file or directory
make: *** [foobar2.o] Error 1
<span class="code-comment">(emerge Error)</span>
!!! ERROR: sys-apps/foobar2-1.0 failed.
!!! Function src_compile, Line 19, Exitcode 2
!!! Make failed!
!!! If you need support, post the topmost build error, NOT this status message
</pre></td></tr>
</table>
<p>
コンパイラー関連のメッセージがエラーの出所を示している。
エラーの発生時どこをコンパイルしていたか開発者が判る手掛かりとなるコンパイル情報はほとんどの場合少なくとも10行程度入っていれば充分だ。
The compilation messages are what lead up to the error. Most often, it's good to
at least include 10 lines of compile information so that the developer knows
where the compilation was at when the error occurred.
</p>
<p>
システムの言語を英語以外に設定してあっても報告に含めるエラーメッセージは必ず英語で出すようにしていただきたい。
emerge コマンドの前に <span class="code" dir="ltr">LC_ALL=C</span> をつければ一時的に英語のロケールになる。
Please make sure you always include error messages in English, even when your
system language is set to something else. You can temporarily switch to English
locale by prepending <span class="code" dir="ltr">LC_ALL=C</span> to the emerge command like this:
</p>
<a name="doc_chap4_pre3"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 4.3: Temporarily switching locale to English</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">LC_ALL=C emerge sys-apps/foobar2</span>
</pre></td></tr>
</table>
<table class="ncontent" width="100%" border="0" cellspacing="0" cellpadding="0"><tr><td bgcolor="#bbffbb"><p class="note"><b>注記: </b>
ロケールを設定する <span class="code" dir="ltr">LC_ALL</span> 環境変数を変えねばならないのはほぼこの1回だけだ。
システムの言語を変える方法をお探しならここではなく
<a href="guide-localization.xml">Localization Guide</a> に答えを求めていただきたい。
This is also about the only time you should use the <span class="code" dir="ltr">LC_ALL</span> environmental
variable for specifying locale settings. If you are looking for a way to switch
your system's language, then please consult our <a href="guide-localization.xml">Localization Guide</a> instead.
</p></td></tr></table>
<p>
Make のエラーは現実に起こったエラーであり開発者に必要な情報だ。
"make: ***" と出てきたら、 そこがエラーの発生場所である場合が多い。
通常は上から10行写し取って報告に貼りつければそれで開発者が問題をつきとめられる。
しかし必ずしもそれでうまくいくとは限らないので別の方法もちょっと紹介しよう。
Make errors are the actual error and the information the developer needs. When
you see "make: ***", this is often where the error has occurred. Normally, you
can copy and paste 10 lines above it and the developer will be able to address
the issue. However, this may not always work and we'll take a look at an
alternative shortly.
</p>
<p>
emerge エラーとは <span class="code" dir="ltr">emerge</span> がエラーと判断して投げ掛けたエラー情報のことである。
たまに重要な情報が含まれることもある。
しばしばこの emerge エラーの部分をポストしてそのままにする間違いを犯す人がいる。
この情報だけでは利用価値がない。 make エラーとコンパイル情報を添えてはじめて開発者に問題を起こしたアプリケーション名とバージョンが伝わる。
余談であるが make はひろくプログラムの構築過程を担うのに使われる (<b>ただし必ずというわけではないが</b>)。
どこにも "make: ***" エラーが無いときはともかく emerge エラーが現れるところまで20行を写し取って報告に貼り付けよう。
ほぼすべてのビルドシステムのエラーメッセージに気を配るべきである。
ではエラーがかなり長くなりそうなときはどうだろう。
つまり全容をつかむのに10行では足りそうにない場合だ。
そのときは PORT_LOGDIR が活躍する。
The emerge error is what <span class="code" dir="ltr">emerge</span> throws out as an error. Sometimes, this
might also contain some important information. Often people make the mistake of
posting the emerge error and that's all. This is useless by itself, but with
make error and compile information, a developer can get what application and
what version of the package is failing. As a side note, make is commonly used as
the build process for programs (<b>but not always</b>). If you can't find a
"make: ***" error anywhere, then simply copy and paste 20 lines before the
emerge error. This should take care of most all build system error messages. Now
let's say the errors seem to be quite large. 10 lines won't be enough to catch
everything. That's where PORT_LOGDIR comes into play.
</p>
<p class="secthead"><a name="doc_chap4_sect3">emerge and PORT_LOGDIR</a></p>
<p>
PORT_LOGDIR は portage の変数名であり、 別口で emerge のログをとるためのログディレクトリを設置する。
要するに何が起こるのかを見てみよう。
まず PORT_LIGDIR で好みの位置のパスを指定し、 emerge を実行する。
例として <span class="path" dir="ltr">/var/log/portage</span> という場所を作ってみたとしよう。
ここをログディレクトリとして利用するならつぎのようにする。
PORT_LOGDIR is a portage variable that sets up a log directory for separate
emerge logs. Let's take a look and see what that entails. First, run your
emerge with PORT_LOGDIR set to your favorite log location. Let's say we have a
location <span class="path" dir="ltr">/var/log/portage</span>. We'll use that for our log directory:
</p>
<table class="ncontent" width="100%" border="0" cellspacing="0" cellpadding="0"><tr><td bgcolor="#bbffbb"><p class="note"><b>注記: </b>
初期状態では
<span class="path" dir="ltr">/var/log/portage</span> というディレクトリは無いので、 作ってやららねばならないはずだ。
作成を怠ったままではこの設定で emerge はログの書き出しを失敗することになる。
In the default setup, <span class="path" dir="ltr">/var/log/portage</span> does not exist, and you will
most likely have to create it. If you do not, portage will fail to write the
logs.
</p></td></tr></table>
<a name="doc_chap4_pre4"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 4.4: emerge-ing With PORT_LOGDIR</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">PORT_LOGDIR=/var/log/portage emerge cate-gory/foobar2</span>
</pre></td></tr>
</table>
<p>
さてもう一度 emerge の失敗を起こそう。 しかしこんどはつぎの作業に使うログが手に入り、 あとでバグ報告に添付できる。
ちょっとログディレクトリの中を覗いてみようか。
Now the emerge fails again. However, this time we have a log we can work with,
and attach to the bug later on. Let's take a quick look at our log directory.
</p>
<a name="doc_chap4_pre5"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 4.5: PORT_LOGDIR Contents</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">ls -la /var/log/portage</span>
total 16
drwxrws--- 2 root root 4096 Jun 30 10:08 .
drwxr-xr-x 15 root root 4096 Jun 30 10:08 ..
-rw-r--r-- 1 root root 7390 Jun 30 10:09 cate-gory:foobar2-1.0:20090110-213217.log
</pre></td></tr>
</table>
<p>
ログファイルの名前は [カテゴリ名]:[パッケージ名]-[バージョン]:[日付].log となっている。
ログファイルはざっと見ると emerge 過程の全体が記されているとわかる。
このあとのバグ報告の節で説明するとおり、 添付用に使える。
もうこれでバグ報告に必要な情報は滞りなく入手できたから実行に移せるはずだ。
しかしその前に、 同じ報告を他の誰かがしていないか確かめる必要がある。
バグの検索方法について見てみよう。
The log files have the format [category]:[package name]-[version]:[date].log. A
quick look at the log file will show the entire emerge process. This can be
attached later on as we'll see in the bug reporting section. Now that we've
safely obtained our information needed to report the bug we can continue to do
so. However, before we get started on that, we need to make sure no one else
has reported the issue. Let's take a look at searching for bugs.
</p>
<p class="chaphead"><a name="doc_chap5"></a><span class="chapnum">5. 
</span>Bugzilla の検索方法</p>
<p class="secthead"><a name="doc_chap5_sect1">はじめに</a></p>
<p>
<a href="http://www.bugzilla.org">Bugzilla</a> は gentoo でバグ処理に使っているしくみだ。
genntoo のバグジラには HTTPS や HTTP で接続できる。
HTTPS は安全に問題があるネットを介して接続する場合や単に気になる人向けに提供されている。
話にブレがないようにするためこれ以降の例ではどれも HTTPS の方を使うことにする。
サイトの様子は <a href="https://bugs.gentoo.org">Gentoo Bugs</a> で見てほしい。
<a href="http://www.bugzilla.org">Bugzilla</a> is what we at Gentoo use to
handle bugs. Gentoo's Bugzilla is reachable by HTTPS and HTTP. HTTPS is
available for those on insecure networks or simply paranoid :). For the sake of
consistency, we will be using the HTTPS version in the examples to follow. Head
over to <a href="https://bugs.gentoo.org">Gentoo Bugs</a> to see how it
looks.
</p>
<p>
開発者やバグ評論家に言わせると同内容のバグ報告が出されるのが最上級にイラッ☆とくるそうだ。
他の重要なバグに対処できたはずの貴重な時間を削られることになるからだ。
ほんのちょっとした検索のしかたひとつでかなりこの問題は防げる。
だからバグ検索のしかたと、 似たバグが無いか探す方法について見てゆこう。
先に挙げた xclass の emerge エラーを例にとって話をすすめる。
One of the most frustrating things for developers and bug-wranglers is finding
duplicate bug reports. These cost them valuable time that they could otherwise
use to work on more important bugs. Often, this can be prevented by a few simple
search methods. So we're going to see how to search for bugs and find out if
you have one that's similar. For this example, we're going to use the xclass
emerge error that was used earlier.
</p>
<a name="doc_chap5_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 5.1: xclass emerge error</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/g++-v3/backward/backward_warning.h:32:2:
warning: #warning This file includes at least one deprecated or antiquated
header. Please consider using one of the 32 headers found in section 17.4.1.2 of
the C++ standard. Examples include substituting the &lt;X&gt; header for the &lt;X.h&gt;
header for C++ includes, or &lt;sstream&gt; instead of the deprecated header
&lt;strstream.h&gt;. To disable this warning use -Wno-deprecated.
In file included from main.cc:40:
menudef.h:55: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:62: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:70: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:78: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
main.cc: In member function `void OXMain::DoOpen()':
main.cc:323: warning: unused variable `FILE*fp'
main.cc: In member function `void OXMain::DoSave(char*)':
main.cc:337: warning: unused variable `FILE*fp'
make[1]: *** [main.o] Error 1
make[1]: Leaving directory
`/var/tmp/portage/xclass-0.7.4/work/xclass-0.7.4/example-app'
make: *** [shared] Error 2
!!! ERROR: x11-libs/xclass-0.7.4 failed.
!!! Function src_compile, Line 29, Exitcode 2
!!! 'emake shared' failed
</pre></td></tr>
</table>
<p>
バグを探すので <a href="https://bugs.gentoo.org/">gentoo Bugzilla ホームページ</a> に行く。
So to begin searching, we head over to the <a href="https://bugs.gentoo.org/">Bugzilla Homepage</a>.
</p>
<br><a name="doc_chap5_fig1"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 5.1: Bugzilla Homepage</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-homepage.png" alt="Fig. 1"></td></tr>
</table>
<br><p>
"Query Existing bug reports" (既にあるバグレポートから探す) をクリックしよう。
"basic bug search" (基本のバグ検索) を素通りしてこちらを選ぶのには理由がある。
基本のバグ検索だとあいまいな結果が出やすく、 全部を通しで検め同じバグを探し出そうとするユーザーにとってはたびたび作業の妨げとなってしまうからだ。
さて検索画面でクリックしたあとにこんなページが出てくる。
We'll click on "Query Existing bug reports". The reason why we choose this
over the basic bug search is because the basic bug search tends to give vague
results and often hinders users from looking through the results and finding the
duplicate bug. Once we click on the query screen, we reach the next page:
</p>
<br><a name="doc_chap5_fig2"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 5.2: Bugzilla Search Page</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-search.png" alt="Fig. 2"></td></tr>
</table>
<br><table class="ncontent" width="100%" border="0" cellspacing="0" cellpadding="0"><tr><td bgcolor="#bbffbb"><p class="note"><b>注記: </b>
前に "Advanced Search" (高度な検索) を行なった場合はおそらく代わりにこの画面が出るはずだ。
If you've used the Advanced Search before, you'll most likely see that screen
instead.
</p></td></tr></table>
<p>
"Advanced Search" へのリンクをクリックして高度な検索のページに進む。
Proceed by clicking on the "Advanced Search" link to bring up the Advanced
Search page.
</p>
<br><a name="doc_chap5_fig3"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 5.3: Advanced Search Page</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-adv-search.png" alt="Fig. 3"></td></tr>
</table>
<br><p>
これは「高度な検索」ページの様子を示している。
一見して圧倒されそうな雰囲気だけれど、 これから見るところはほんの少しで、 単にバグジラがあいまいな結果を返さずに済むよう絞り込みを行なう区画だけだ。
This is how the Advanced Search Page looks like. While it may seem overwhelming
at first, we're going to look at a few simple areas to narrow down the rather
vague searches bugzilla returns.
</p>
<br><a name="doc_chap5_fig4"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 5.4: Content</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-content.png" alt="Fig. 4"></td></tr>
</table>
<br><p>
第1の区画はバグの Summary (要約)。 ここは単にクラッシュしたパッケージ名を入れた。
バグジラくんが結果を出せないときは念のためパッケージ名を削除してやりなおそう。
パッケージ名を書かずに報告した人がいるかもしれないからだ。
(まさかそんな、 と思われるかもしれないが我々は結構な割合でおかしなバグ報告を見てきた。)
The first field is the summary of the bug. Here we're simply going to put the
name of the package that's crashing. If bugzie doesn't return results, try
removing the package name, just in case someone didn't put that in the summary
(highly unlikely, but we've seen a fair share of strange bug reports).
</p>
<p>
Product (製品名)、 Component (成分名)、 Version (バージョン) はそのまま既定値でよい。
絞り込み過ぎでバグの見落しが起きてしまわぬようにするためだ。
Product, Component, and Version should all be set to the default. This
prevents us from being too specific and missing all the bugs.
</p>
<p>
Comment (コメント) は重要な部分。 エラーを特定できそうな事実をかいつまんでコメント欄に書き出す。
基本的に、 ビルドエラーの最初の行のようなものまで挙げる必要はなく、 真のエラーが確立する直前の1行を探し出そう。
また、 バグジラがコメントを変な形に読み取らずに済むよう句読点をあらかじめ全部抜き取っておいてもよいだろう。
さきの xclass の emerge エラーの例でいえばこうなる。
Comment is the important part. Use the comment field to list what appears to be
a specific instance of the error. Basically, don't use anything like the
beginning of the build error, find a line that's before it stating a true
error. Also, you'll want to filter out any punctuation to prevent bugzilla
from interpreting the results the comment the wrong way. Example from the xclass
emerge error:
</p>
<a name="doc_chap5_pre2"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 5.2: Comment Line Content</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
menudef.h:78: error: brace-enclosed initializer used to initialize `OXPopupMenu'
<span class="code-comment">(Remove the quotes ' ')</span>
menudef.h 78 error brace-enclosed initializer used to initialize OXPopupMenu
</pre></td></tr>
</table>
<p>
このようにすれば充分はっきりと、 xclass のコンパイル失敗で出た他の関係ありそうな行をかきわけて行くことなく、 バグを発見できるはずだ。
The above is specific enough to where we'll find the bug without wading through
other xclass compile failure candidates.
</p>
<p>
URI、 Whiteboard、 Keyword はそのままにしてよい。
これだけ書いておけばバグを見付けるのに充分すぎるほどだ。
埋めた欄はつぎのとおり。
URI, Whiteboard, and Keywords can all be left alone. What we've entered so far
should be enough to find our bug. Let's take a look at what we have filled out.
</p>
<br><a name="doc_chap5_fig5"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 5.5: Completed Search Form</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-comp-search.png" alt="Fig. 5"></td></tr>
</table>
<br><p>
いよいよ検索ボタンをクリックすると、 こんな結果が現れる。
Now we click on the Search button and here come the results...
</p>
<br><a name="doc_chap5_fig6"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 5.6: Search Results</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-search-result.png" alt="Fig. 6"></td></tr>
</table>
<br><p>
バグはたったの2件だけ! 結構簡単にいけそうだ。
1件目を見てみたらまごうことなき、 探していたバグだった。
Only 2 bugs! That's a lot easier to deal with. We click on the first one to
check, and sure enough it's the one we're looking for.
</p>
<br><a name="doc_chap5_fig7"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 5.7: Bug Located</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-located.png" alt="Fig. 7"></td></tr>
</table>
<br><p>
欲しいバグ報告が見付かっただけでなく、 解決されていたとわかる。
最後のコメントに解法が載っていて、 対処すべき方法がわかった。
では「高度な検索」を使わなかった場合はどうなっていたのだろう。
Not only is it the one we want, but it has also been resolved. By checking the
last comment we see the solution and know what to do in order to resolve it.
Now, let's see what would have happened if we had not used the advanced search.
</p>
<br><a name="doc_chap5_fig8"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 5.8: Basic Search Results</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-basic-search-result.png" alt="Fig. 8"></td></tr>
</table>
<br><p>
検討すべきバグがさらに4つも! パッケージが大きくなるにつれもっとひどくなる。
こんな簡単なツールであっても、 検索結果をしっかりと絞り込めるから意中のバグを試して突き止められる。
4 more bugs to deal with! It gets even worse with larger packages. However,
with these simple tools, we're able to significantly narrow down the search to
try and locate a specific bug.
</p>
<p class="secthead"><a name="doc_chap5_sect2">Conclusion</a></p>
<p>
探せども探せどもバグ報告が見付からなかったという場合はどうか。 あなたは新種のバグを発見したのだ。
新しいバグを提出するところまでバグ報告の手順を見てゆこう。
Let's say that you have searched and searched but still can't find a bug.
You've found yourself a new bug. Let's take a look at the bug reporting process
for submitting your new bug.
</p>
<p class="chaphead"><a name="doc_chap6"></a><span class="chapnum">6. 
</span>バグの報告のし方</p>
<p class="secthead"><a name="doc_chap6_sect1">Introduction</a></p>
<p>
この章ではぴっかぴかの新バグを Bugzilla に記帳する方法を学ぶ。
<a href="https://bugs.gentoo.org">Gentoo Bugs</a> に移動したら、
In this chapter, we'll figure out how to use Bugzilla to file a shiny, new bug.
Head over to <a href="https://bugs.gentoo.org">Gentoo Bugs</a> and...
</p>
<br><a name="doc_chap6_fig1"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 6.1: Bugzilla Homepage</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-homepage.png" alt="Fig. 1"></td></tr>
</table>
<br><p>
"Report a Bug - Using the guided format" (バグを報告 - 指南つき記入欄を利用) をクリックする。
Click on "Report a Bug - Using the guided format".
</p>
<br><a name="doc_chap6_fig2"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 6.2: Product Selection</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-prod-select.png" alt="Fig. 2"></td></tr>
</table>
<br><p>
バグを出すところを間違えないようにと <b>大きく</b> 強調してあるのが見える。
Gentoo Linux は大集団のバグが群がるところだ。
As you can see, <b>major</b> emphasis has been placed on putting your bug in the
right place. Gentoo Linux is where a large majority of bugs go.
</p>
<p>
にもかかわらず ebuild バグを portage 開発 (portage の木構造を取り扱う portage チームを想定) とか infra
(infra がミラーや rsync に接続して直接問題解決をはかると想定) へ出してしまう人がいるのだ。
物体の運動法則のような簡単なものではない。
Despite this, some people will file ebuild bugs in portage development
(assumption that portage team handles the portage tree) or infra (assumption
that infra has access to mirrors and rsync and can fix it directly). This is
simply not how things work.
</p>
<p>
他にも文書整備 (ドキュメンテーション) 関連のバグとの勘違いがよくおこる。
たとえば
<a href="/proj/en/releng/catalyst/">Catalyst Docs</a> にバグを見付けたユーザーがいたとしよう。
一般的な考えでいくと <a href="http://gdp.gentoo.org">GDP</a> に関連した
Docs-user の方へバグを記帳してしまいがちであるが、
本来は <a href="/proj/en/releng/">Release Engineering</a> チームに知らせねばならない。
大雑把に分ければ
<span class="path" dir="ltr">http://www.gentoo.org/doc/*</span> は GDP に属する。
それ以外で <span class="path" dir="ltr">http://www.gentoo.org/proj/*</span> 以下なら個々のチームに属する問題となる。
Another common misconception occurs with our Documentation bugs. For example, a
user finds a bug with the <a href="/proj/en/releng/catalyst/">Catalyst
Docs</a>. The general tendency is to file a bug under Docs-user, which gets
assigned to the <a href="http://gdp.gentoo.org">GDP</a>, when it should
actually go to a member of the <a href="/proj/en/releng/">Release
Engineering</a> team. As a rule of thumb, only documentation under
<span class="path" dir="ltr">http://www.gentoo.org/doc/*</span> is under the GDP. Anything under
<span class="path" dir="ltr">http://www.gentoo.org/proj/*</span> is under the respective teams.
</p>
<table class="ncontent" width="100%" border="0" cellspacing="0" cellpadding="0"><tr><td bgcolor="#bbffbb"><p class="note"><b>注記: </b>
むしろ Gentoo Linux とは思えない製品のバグ(XXXすみません構文がわかりません.泣)
どちらも困ったものだが、 前者のほうが受け入れやすく理解しやすい
(ただしウェブサイトのバグを除く。 この件の問題まで入ってきがちだった...)。
We would rather see a bug whose product was not supposed to be Gentoo Linux but
has been filed under the same rather than seeing a bug which belongs the Gentoo
Linux product and filed elsewhere. While neither is preferred, the former is
more acceptable and understandable (except website bugs.. we might have an issue
with that...).
</p></td></tr></table>
<p>
今回のバグは ebuild バグなので Gentoo Linux 行きである。
目指す進路をとるとバグ報告の階段がまちうけていた。
1歩目の段に進むと、
Our bug goes in Gentoo Linux as it's an ebuild bug. We head over there and are
presented with the multi-step bug reporting process. Let us now proceed with
Step 1...
</p>
<br><a name="doc_chap6_fig3"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 6.3: Guided Format Step 1</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-guide-step1.png" alt="Fig. 3"></td></tr>
</table>
<br><p>
ここの第1段が実に重要だ (赤字で記されている)。
ここでお持ちのバグと同じものをまだ他の誰も仕留めていないとわかるまで検索する。
この段階を省いて同じようなバグがあるのに報告を出したら、
DUPLICATE (重複) のマークが付けられる。 つまり QA の労力を多大に浪費したことになる。
上図で番号に打消線の入ったバグが重複バグだと言えばわかっていただけるだろうか。
さて第2段に進もう。 ここで情報を書き込む。
The first step here is really important (as the red text tells you). This is
where you search to see that someone else hasn't hit the same bug you have, yet.
If you do skip this step and a bug like yours already exists, it will be marked
as a DUPLICATE thus wasting a large amount of QA effort. To give you an idea,
the bug numbers that are struck out above are duplicate bugs. Now comes step 2,
where we give the information.
</p>
<p class="secthead"><a name="doc_chap6_sect2">Required Information</a></p>
<br><a name="doc_chap6_fig4"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 6.4: Basic Information</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-basic.png" alt="Fig. 4"></td></tr>
</table>
<br><p>
どれが何になるかつぶさに見てゆこう。
Let us take a closer look at what's what.
</p>
<ul>
<li>
まずは Product (製品) のところから。
ここで製品の分野分けにしたがい Bugzilla (bugs.gentoo.org に関係するバグ)、
Docs-user (ユーザー向け文書の整備)、 Gentoo Linux (ebuild など)
に Gentoo のバグを仕分ける。
First, there's the Product. The product will narrow down the bug to a
specific area of Gentoo like Bugzilla (for bugs relating to
bugs.gentoo.org), Docs-user(for User Documentation) or Gentoo Linux (for
ebuilds and the like).
</li>
<li>
Component (構成分野) のところは、 問題発生箇所をもっと限定するためバグがあるのは製品のどの部分か選ぶ。
Component is where exactly the problem occurs, more specifically which part
of selected product the bug comes under. This makes classification easier.
</li>
<li>
Hardware (ハードウェア) のところでは動作させている (CPU の) 機種を選ぶ。
例えば SPARC で使用しているのなら SPARC に設定する。
Hardware platform is what architecture you're running. If you were running
SPARC, you would set it to SPARC.
</li>
<li>
Operating System (オペレーティングシステム) でどの OS を利用しているか選ぶ。
Gentoo は「メタディストリビューション」との位置付けなので、
Linux とは違うオペレーティングシステムで動作させていることもある。
Operating System is what Operating System you're using. Because Gentoo is
considered a "Meta-distribution", it can run on other operating systems
beside Linux.
</li>
</ul>
<p>
そして、 今回の例のバグについてはこうだ。
So, for our example bug, we have :
</p>
<ul>
<li>Product - Gentoo Linux (Since it is an ebuild issue)</li>
<li>Product - Gentoo Linux (ebuild の問題なので)</li>
<li>Component - Application (It is an application at fault, foobar2)</li>
<li>Component - Application (foobar2 というアプリケーションの欠陥だから)</li>
<li>Hardware Platform - All (This error could occur across architectures)</li>
<li>Hardware Platform - All (動作機種を選ばず起こりうるエラーだから「すべて」)</li>
<li>Operation System - All (It could occur on all types of systems)</li>
<li>Operation System - All (あらゆる形式のシステムで起こりうるから「すべて」)</li>
</ul>
<br><a name="doc_chap6_fig5"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 6.5: Completed Basic Information</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-basic-comp.png" alt="Fig. 5"></td></tr>
</table>
<br><ul>
<li>
Build Identifier (User Agent) は基本的にバグ報告をしたウェブブラウザのユーザーエイジェント情報をバグジラが記録するためにある。
そのまま放置してかまわない。
Build Identifier is basically the User Agent of the browser that is being
used to report the bugs (for logging purposes). You can just leave this as
is.
</li>
<li>
URL は任意記入欄であり、 bugzilla の供給側の引用やパッケージのホームページのリリースノートなど他のサイトからの関連情報を指し示すのに使われる。
決してペイストビンサイトのほうにエラーメッセージやログや
<span class="code" dir="ltr">emerge --info</span> の出力やスクリーンショットなどを置いてリンクを貼るようなことはしないでほしい。
いずれもバグ報告に添付すべきだ。
URL is optional and is used to point to relevant information on another site
(upstream bugzilla, release notes on package homepage etc.). You should
never use URL to point to pastebins for error messages, logs, <span class="code" dir="ltr">emerge
--info</span> output, screenshots or similar information. Instead, these should
always be attached to the bug.
</li>
<li>
Summary (要約) でパッケージの分野、 名称、 版番号を記入する。
In the Summary, you should put the package category, name, and number.
</li>
</ul>
<p>
分野名を要約に書かずに済ましても実際にさほどまずくはないものの、 記入を推奨する。
しかしパッケージ名が書かれていないと何のバグの話が書いてあるのか判りようがないので、
結局あとでスタッフが聞き返すことになる。
版番号はバグ報告を探す人にとって重要な情報だ。
もし 20 人からバグ報告が寄せられて 1 件もバージョン番号が書かれていないとすると、
同じバグを探すときみんなどうやって目当てのバグと同じか区別すればいいのだろう。
いちいちバグ報告を読んで探すのもさほど困難ではないだろうが、
これがもし 200 件の未記載だったら...。 とても容易ではない。
パッケージ情報はここまでで、 そのあとに本件事案の短い説明を加えることになる。
たとえばこんなふうに。
Not including the category in the summary really isn't too bad, but it's
recommended. If you don't include the package name, however, we won't know what
you're filling a bug for, and will have to ask you about it later. The version
number is important for people searching for bugs. If 20 people filed bugs and
not one put a version number, how would people looking for similar bugs be able
to tell if one was there's? They'd have to look through every single bug, which
isn't too hard, but if there are say, 200 bugs.. it's not that easy. After all
the package information, you'll want to include a small description of the
incident. Here's an example:
</p>
<br><a name="doc_chap6_fig6"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 6.6: Summary</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-summary.png" alt="Fig. 6"></td></tr>
</table>
<br><p>
こんな簡単な規則でもバグの扱いはとても楽になる。 つづいては詳細。
バグにまつわる情報をここに書く。 実例はこんなふうになる。
These simple rules can make handling bugs a lot easier. Next are the details.
Here we put in the information about the bug. We'll demonstrate with an example:
</p>
<br><a name="doc_chap6_fig7"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 6.7: Details</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-details.png" alt="Fig. 7"></td></tr>
</table>
<br><p>
やっと開発者にバグ報告のを寄せたかが伝わるのがここ。
彼らは問題が再現できるか試すつもりである。 再現性により問題再発の頻度がわかる。
今回の例では単に foobar2 を起動すればいつでも再現できる。
その情報を書き込もう。
Now the developer knows why we're filing the bug. They can then try to
reproduce it. Reproducibility tells us how often we were able to make the
problem recur. In this example, we can reproduce it any time simply by running
foobar2. Let's put that information in.
</p>
<br><a name="doc_chap6_fig8"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 6.8: Reproduction</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-reprod.png" alt="Fig. 8"></td></tr>
</table>
<br><p>
バグ発見の経緯は述べた。
それを次の段でどう説明するか、 そしてどうあってほしいかあなたの考えを説明する方法を学ぼう。
We have explained how we found the bug. The next step is to explain what were
the results we got and what we think they should actually be.
</p>
<br><a name="doc_chap6_fig9"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 6.9: Results</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-results.png" alt="Fig. 9"></td></tr>
</table>
<br><p>
ここに追加の情報が置ける。
追加情報とはスタックトレースや、 strace ログの <b>一節</b> (ログ丸ごとだと大き過ぎて使い難いことたびたびなので) のような情報のことだが、
やはり <span class="code" dir="ltr">emerge --info</span> の出力が最重要だろう。
こんなふうに。
We could then provide additional information. This could be things such as
stack traces, <b>sections</b> (since the whole log is usually big and of not
much use) of strace logs, but most importantly, your <span class="code" dir="ltr">emerge --info</span>
output. Here's an example.
</p>
<br><a name="doc_chap6_fig10"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 6.10: Additional Information</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-addl-info.png" alt="Fig. 10"></td></tr>
</table>
<br><p>
最後はバグの深刻度を選ぶ。
ここに関しては慎重に慎重を重ねてほしい。
ほとんどはそのまま手をつけずにおけば大丈夫だ。 (必要に応じて) 誰かが代わりに上げ下げしてくれる。
しかし提出したバグの深刻度を自ら上げるつもりなら、 注意書きをよく読み、 間違いのないことを再度確認してほしい。
各度合いの区別はつぎのようになっている。
Lastly we select the severity of the bug. Please look this over carefully. In
most cases it's OK to leave it as is and someone will raise/lower it for you.
However, if you raise the severity of the bug, please make sure you read it over
carefully and make sure you're not making a mistake. A run down of the various
levels is given below.
</p>
<ul>
<li>
Blocker (障害物) - このプログラムはもう疑いなく emerge しえないといえる、
もしくはシステムの重大な障害物である。
例えば <span class="code" dir="ltr">baselayout</span> に問題があればシステムが起動できなくなるので blocker 候補といえる。
Blocker - The program just plain doesn't want to emerge or is a major
hinderance to the system. For example a <span class="code" dir="ltr">baselayout</span> issue which
prevents a system from booting up would be a sure candidate to be labelled
blocker.
</li>
<li>
Critical (深刻) - このプログラムはデータの損失を起こす、
または動作中に重大なメモリーリークを起こす。
やはり、 <span class="code" dir="ltr">net-tools</span> みたいな重要なプログラムがコンパイルできなければ critical になりうる。
システム起動までは妨害しないものの日に日に一大事となってゆく。
Critical - The program has loss of data or severe memory leaks during
runtime. Again, an important program like say <span class="code" dir="ltr">net-tools</span> failing to
compile could be labelled critical. It won't prevent the system from
starting up, but is quite essential for day to day stuff.
</li>
<li>
Major (重大) - プログラムがクラッシュ (異常終了) するけれど、 システムに異常をきたすわけでも、 情報の損失を招くものでもない。
Major - The program crashes, but nothing that causes your system severe
damage or information loss.
</li>
<li>
Minor (二流) - プログラムがあたりかまわずクラッシュするも一定の回避策がわかっている。
Minor - Your program crashes here and there with apparent workarounds.
</li>
<li>
Normal (通常) - 初期設定値。 わからなければそのままにすればよい。
ただし新しいビルドの場合や見た目の変更に留まるときはさらにこの下で情報を得ること。
Normal - The default. If you're not sure leave it here unless it's a new
build or cosmetic change, then read below for more information.
</li>
<li>
Trivial (些事) - 言葉の綴り間違いとか空白文字の整理のようなこと。
Trivial - Things such as a mispelled word or whitespace clean up.
</li>
<li>
Enhancement (改善・向上) - プログラムに新機能をつけてもらう提案のほか、
<span class="emphasis">ebuild の新規・追加</span> は決まってここだ。
Enhancement - A request to enable a new feature in a program, or more
specifically <span class="emphasis">new ebuilds</span>.
</li>
</ul>
<br><a name="doc_chap6_fig11"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 6.11: Severity</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-sev.png" alt="Fig. 11"></td></tr>
</table>
<br><p>
今回の例では Normal を選ぶ。
Here, we'll set it to Normal.
</p>
<p>
もうバグ報告を出せるので Submit Bug Report 「バグ報告を提出」ボタンをクリックする。
そうしたら新しいバグが上がってくる。
その結果どうなったかは <a href="https://bugs.gentoo.org/show_bug.cgi?id=97265">Bug 97561</a> を見よう。
バグの報告ができた!
ではこれがどう扱われるか見てゆく。
Now we can submit the bug report by clicking on the Submit Bug Report box. You
will now see your new bug come up. See <a href="https://bugs.gentoo.org/show_bug.cgi?id=97265">Bug 97561</a> for what
the result looks like. We've reported our bug! Now let's see how it's dealt
with.
</p>
<p class="secthead"><a name="doc_chap6_sect3">Zero-day bump requests</a></p>
<p>
ここまでずっとバグを記帳する時点でしなければならないことを見てきた。
ではやっては <span class="emphasis">いけない</span> ことは何か話そう。
So far, we've shown what to do when filing a bug. Now let's take a look at what
<span class="emphasis">not</span> to do.
</p>
<p>
あなたが熱心に供給源プロジェクトの日程を追っているとしよう。
ある日ホームページをチェックしていたら、 何と! つい数分前に新バージョンが公表されているとわかった。
たいていのユーザーはすぐに Gentoo の bugzilla に行って新バージョンが出たと通報するだろう。 現バージョンは更新して portage に加えてください。とかなんとか。
しかしこれは明らかに <b>やってはいけない</bi> ことだ。
新バージョンが出たその日に出されることから、
こういう要求は 0-day bump request (ゼロデイバンプリクエスト: 即日アゲ要求) と呼ばれる。
Suppose that you've eagerly been following an upstream project's schedule, and
when you check their homepage, guess what? They just released a new version a
few minutes ago! Most users would immediately rush over to Gentoo's bugzilla to
report the new version is available; please bump the existing version and add
it to Portage, etc. However, this is exactly what you should <b>not</b> do.
These kinds of requests are called zero-day (or 0-day) bump requests, as they're
made the same day that a new version is released.
</p>
<table class="ncontent" width="100%" border="0" cellspacing="0" cellpadding="0"><tr><td bgcolor="#ffffbb"><p class="note"><b>重要: </b>
<b>bugzilla に新バージョンを報告するのは <span class="emphasis">最短でも</span> 48時間待ってからにしてもらいたい。</b>
加えて、 要求を提出する前に <span class="emphasis">必ず</span> bugzilla をチェックして
誰か他の人がもう報告を出していないか、 あるいは Gentoo の保守担当が新バージョンにもう取り掛かっていないか、 確かめなければいけない。
<b>Please wait <span class="emphasis">at least</span> 48 hours before reporting a new release on our
bugzilla.</b> Also, you <span class="emphasis">must</span> check bugzilla before posting your request
to make sure that someone else hasn't already reported it, or that the Gentoo
maintainers haven't already dealt with the new version.
</p></td></tr></table>
<p>
どうして待つ必要があるかって? 第1に、 Gentoo 開発者に向かって今している作業を全部中断してたった15分前に出たばかりの新公開版の追加をしろというのは傲慢きわまりないことだ。
ゼロデイバンプリクエストを出しても開発者たちが課題に追われてせっせとやってるときだったら INVALID (不正) もしくは LATER (後日) とマークされるかもしれない。
第2に、 開発者はきわめて密接に開発元を追跡しているはずであり、
普段からユーザーに先んじて新公開までの経過によく注意を払っているからだ。
新しい版が出ているのはもう既に知っている。
多くの場合バグはもう開いてあるだろうし、 マスクつきながら既に portage へ加えられているかもしれない。
Why should you wait? First, it's quite rude to demand that Gentoo developers
drop everything they're doing just to add a new release that came out 15 minutes
ago. Your zero-day bump request could be marked as INVALID or LATER, as
developers have plenty of pressing issues to keep them busy. Second, developers
are usually aware of pending new releases well in advance of users, as they must
follow upstream quite closely. They already know a new version is on its way.
In many cases, they will have already opened a bug, or might even already added
it in Portage as a masked package.
</p>
<p>
パッケージの新しい版を試すときや要求するときは抜け目なくやろう。
アゲ要求を投げ込む前に bugzilla を検索しよう。 開いてあるバグが既にあるかも。
もうしばらくしてから emerge を sync しなおそう。 portage にもう入っているかも。
そもそも本当に供給源で公表されているのかな。
一般常識は長持ちするものだし、 (これに則って行動すれば) まだ業務がいろいろ残っていそうな開発者の目にも愛嬌ありと映る。
公表日から何日か経っていてなおかつ誰もまだ要求を挙げていないのが確実に判っている (しかも portage に入っていない) のなら、
新たなバグとして申請してよい。
その際お使いの機種でコンパイルできて動作したことも必ず書き添えよう。
ほかにも役立ちそうな情報が提供できれば文句なし。
Be smart when testing and requesting new versions of packages. Search bugzilla
before posting your bump request -- is there already a bug open? Have you synced
lately; is it already in Portage? Has it actually been released by upstream?
Basic common sense will go a long way, and will endear you to developers that
already have a lot to do. If it's been several days since release and you're
sure that there are no open requests for it (and that it's not in Portage), then
you can open up a new bug. Be sure to mention that it compiles and runs well on
your arch. Any other helpful information you provide is most welcome.
</p>
<p>
お気にいりのパッケージの最新版が portage に欲しいとき、 バグ申請は賢くやろう。
Want to see the newest version of your favorite package in Portage? File smart
bugs.
</p>
<p class="chaphead"><a name="doc_chap7"></a><span class="chapnum">7. 
</span>バグの処理</p>
<p>
バグを見ていると、 とっくの昔に発表してある情報が通報されてくる。
このバグは bug-wranglers@gentoo.org に付託されているのがおわかりになるはずだ。
アプリケーション分野のバグは既定どおりならここへ行く。
Looking at the bug, we see the information we provided earlier. You will notice
that the bug has been assigned to bug-wranglers@gentoo.org. This is the default
location for Application component bugs.
</p>
<br><a name="doc_chap7_fig1"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 7.1: New Bug Basic Information</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-new-basic.png" alt="Fig. 1"></td></tr>
</table>
<br><p>
バグについて記した詳細も読める。
The details we entered about the bug are available as well.
</p>
<br><a name="doc_chap7_fig2"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 7.2: New Bug Details</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-new-details.png" alt="Fig. 2"></td></tr>
</table>
<br><p>
しかし bug-wranglers は (普段) バグ処理を何もしないことになっているので、
対処できる人物に再付託することになる (bug-wranglers に付託手続を任せてもよい)。
このときパッケージの metadata.xml を利用する。
このファイルは通常 <span class="path" dir="ltr">/usr/portage/分野/パッケージ名/metadata.xml</span> にある。
foobar2 でやってみればこうなる。
However, bug-wranglers (usually) won't fix our bugs, so we'll reassign it to
someone that can (you can let bug-wranglers re-assign it for you as well). For
this we use the package's metadata.xml. You can normally find them in
<span class="path" dir="ltr">/usr/portage/category/package/metadata.xml</span>. Here's one I've made up
for foobar2.
</p>
<table class="ncontent" width="100%" border="0" cellspacing="0" cellpadding="0"><tr><td bgcolor="#bbffbb"><p class="note"><b>注記: </b>
当該バグの報告者か Gentoo Bugzilla のグループ (Gentoo Developers など) の一員でなければバグの再付託は行なえません。
You have to be the reporter of the bug or a member of certain Gentoo Bugzilla
groups (like Gentoo Developers) to be able to reassign bugs.
</p></td></tr></table>
<a name="doc_chap7_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 7.1: metadata.xml</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd"&gt;
&lt;pkgmetadata&gt;
&lt;herd&gt;chriswhite&lt;/herd&gt;
&lt;maintainer&gt;
&lt;email&gt;chriswhite@gentoo.org&lt;/email&gt;
&lt;name&gt;Chris White&lt;/name&gt;
&lt;/maintainer&gt;
&lt;longdescription lang="en"&gt;
Foobar2 is a package that uses a configuration file to display a word.
&lt;/longdescription&gt;
&lt;/pkgmetadata&gt;
</pre></td></tr>
</table>
<p>
管理人の節に注目。 ここはパッケージ管理者の名簿であり、 この例では私こと Chris White の名がある。
掲載されている電子メールは chriswhite@gentoo.org。
特定の人物にバグを再付託するときはこれを使う。
やり方は、 Reassign bug to (バグ再付託先) と書かれた隣の吹き出しをクリックして、
空欄に電子メールアドレスを記入だ。
Notice the maintainer section. This lists the maintainer of the package, which
in this case is myself, Chris White. The email listed is chriswhite@gentoo.org.
We will use this to re-assign the bug to the proper person. To do this, click
the bubble next to Reassign bug to, then fill in the email.
</p>
<table class="ncontent" width="100%" border="0" cellspacing="0" cellpadding="0"><tr><td bgcolor="#bbffbb"><p class="note"><b>注記: </b>
metadata.xml が付属しないパッケージの場合は maintainer-needed@gentoo.org に、
誰か Gentoo 開発者が管理者として必要な場合は maintainer-wanted@gentoo.org にバグを付託しなければならない。
付託したうえで
A bug for a package without a metadata.xml file should be re-assigned to
maintainer-needed@gentoo.org and a package that needs a Gentoo Developer to
maintain should be assigned to maintainer-wanted@gentoo.org.
</p></td></tr></table>
<br><a name="doc_chap7_fig3"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 7.3: Bug Reassignment</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-reassign.png" alt="Fig. 3"></td></tr>
</table>
<br><p>
そうしたら変更を反映させるために Commit (委任) ボタンを押す。
バグは私に付託された。
しばらくすると私がバグの責任を持つ旨のお知らせ (通常は電子メール) が送られる。
そして私は、 プログラムがどんなふうに設定ファイルに接触を図るのか見てみたいので strace ログを見せてほしい、 と表明する。
そこであなたは前述の strace の使い方に則って strace ログを得る。
これをバグに添付する必要がでてきた。
やり方は、 "Create A New Attachment" (添付ファイルを作成) をクリック。
Then hit the Commit button for the changes to take place. The bug has been
reassigned to me. Shortly afterward, you notice (by email usually) that I've
responded to your bug. I've stated that I'd like to see an strace log to figure
out how the program is trying to reach your configuration file. You follow the
previous instructions on using strace and obtain an strace log. Now you need to
attach it to the bug. In order to do this, click on "Create A New Attachment".
</p>
<br><a name="doc_chap7_fig4"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 7.4: New Attachment</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-new-attach.png" alt="Fig. 4"></td></tr>
</table>
<br><p>
ログを添付しなくてはならない。 一歩づつ進めよう。
Now we have to attach the log. Let's go throught it step wise.
</p>
<ul>
<li>
File (ファイル) - ファイルが置かれているお使いのコンピューター上の場所。
今回の例では <span class="path" dir="ltr">strace.log</span> があるところ。
"Browse..." ボタンからファイルを選び出すか、 記入欄にパスを直接記入すればよい。
File - This is the location of the file in your machine. In this example,
the location of <span class="path" dir="ltr">strace.log</span>. You can use the "Browse..." button
to select the file, or enter the path directly in the text field.
</li>
<li>
Description (要旨) - 一行で手短に、 あるいは添付ファイルのことを数語で。
strace.log とだけ書いたのはこれで充分自明だからだ。
Description - A short one liner, or a few wors describing the attachment.
We'll just enter strace.log here, since that's quite self-explanatory.
</li>
<li>
Content Type (データの型式) - バグ報告に添付しようとするファイルの型式。
Content Type - This is the type of the file we're attaching to the bug.
</li>
<li>
Obsoletes (改廃) - 今回の分より前にこのバグ報告に添付ファイルを提出していたとき、
用済みになったならこのオプションで印をつけられる。
前回提出分は無いので気にすることはない。
Obsoletes - If there were attachements submitted to the bug before the
current one, you have an option of declaring them obsoleted by yours. Since
we have no prior attachments to this bug, we need not bother.
</li>
<li>
Comment (コメント) - コメントをつけると添付ファイルと (要旨) ともに目に入る言葉になる。
添付ファイルについて念には念を入れておきたいならここに書く。
Comment - Enter comments that will be visible along with the attachments.
You could elaborate on the attachment here, if needed.
</li>
</ul>
<p>
Content Type (データの型式) に関してはもっと詳しくみてゆく。
パッチを送るときには "patch" チェックボックスに印をつけるとよい。
それ以外のものを送るなら Bugzilla の "auto-detect" (自動判定) でファイル型式を判断させる方法もある (ただし介入できない)。
オプションは一方で "select from list" (一覧から選択) もできるようになっていて、
ここはいちばんよく利用される。
<span class="emphasis">大多数の</span> 添付ファイルは平文テキスト (text/plain) であるが、
バイナリファイルは例外で、 画像なら image/gif、 image/jpeg、 image/png などから選び、
.tar.bz2 のような圧縮ファイルなら application/octet-stream がファイル型式である。
With respect to Content Type, here are a few more details. You can check the
"patch" checkbox if you're submitting a patch. Otherwise, you could ask
Bugzilla to "auto-detect" the file type (not advisable). The other options are
"select from list", which is most frequently used. Use plain text (text/plain)
for <span class="emphasis">most</span> attachments except binary files like images (which can use
image/gif, image/jpeg or image/png depending on type) or compressed files like
.tar.bz2 which would use application/octet-stream as content type.
</p>
<br><a name="doc_chap7_fig5"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 7.5: New Attachment Completed</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-new-attach-comp.png" alt="Fig. 5"></td></tr>
</table>
<br><p>
<span class="path" dir="ltr">strace.log</span> を提出したらバグ報告に反映された。
We submit <span class="path" dir="ltr">strace.log</span> and it is reflected on the bug report.
</p>
<br><a name="doc_chap7_fig6"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 7.6: Attached strace log</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-strace.png" alt="Fig. 6"></td></tr>
</table>
<br><p>
ときには ebuild が emerge エラーのメッセージ内でファイル添付をするように言ってくることはもう述べた。 実例はこう。
We've mentioned before that sometimes ebuilds will tell you to attach a file in
the emerge error. An example can be seen below.
</p>
<a name="doc_chap7_pre2"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 7.2: Example File Attachment Request</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
configure: error: PNG support requires ZLIB. Use --with-zlib-dir=&lt;DIR&gt;
!!! Please attach the config.log to your bug report:
!!! /var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/config.log
!!! ERROR: dev-php/php-5.0.3-r1 failed.
!!! Function econf, Line 485, Exitcode 0
!!! econf failed
!!! If you need support, post the topmost build error, NOT this status message.
</pre></td></tr>
</table>
<p>
このように言及されたファイルはバグ報告に添付するようにしていただきたい。
Please attach any file mentioned like this to your bug report.
</p>
<p>
ときには開発者が diff もしくは patch ファイルを添付するよう求めるかもしれない。
標準的な diff ファイルはつぎのようにして取得する。
Sometimes a developer might ask you to attach a diff or patch for a file.
Standard diff files can be obtained through:
</p>
<a name="doc_chap7_pre3"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 7.3: Standard Diff Creation</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
$ <span class="code-input">cp file file.old</span>
$ <span class="code-input">nano file</span>
$ <span class="code-input">diff -u file.old file</span>
</pre></td></tr>
</table>
<p>
C/C++ のソースファイルにおいては diff があるところの関数名も表示できるよう
<b>-p</b> オプションもつける。
For C/C++ source files, the <b>-p</b> flag is added to show what function calls
the diff applies to:
</p>
<a name="doc_chap7_pre4"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 7.4: Diff-ing C/C++ source</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
$ <span class="code-input">cp file.c file.c.old</span>
$ <span class="code-input">nano file.c</span>
$ <span class="code-input">diff -up file.c.old file.c</span>
</pre></td></tr>
</table>
<p>
文書化チームは <b>-u</b> フラグに <b>-Nt</b> も組み合わせるよう要求するはずだ。
このフラグは主にタブ展張に関係している。
このような diff はつぎのようにして作成できる。
The documentation team will require the flag combination <b>-Nt</b> as well as
<b>-u</b>. This mainly has to do with tab expansion. You can create such a diff
with:
</p>
<a name="doc_chap7_pre5"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 7.5: Documentation diffs</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
$<span class="code-input"> cp file.xml file.xml.old</span>
$<span class="code-input"> nano file.xml</span>
$<span class="code-input"> diff -Nut file.xml.old file.xml</span>
</pre></td></tr>
</table>
<p>
これで diff ファイルができた。 ここまでの作業を終えるまでに、
誰か他の人がこのバグ報告を bugzilla で探し出しバグの顛末に興味を抱いたとしたら、
その人はつぎに示したメールの CC 欄に自分の電子メールアドレスを加えるかもしれない。
同じ方法で他の人のバグを追い掛けられる。
And your diff is created. While we're doing all this, suppose another person
finds your bug by searching through bugzilla and is curious to keep track of
the bug, they may do so by putting their email in the Add CC field of the bug
as shown below. You could also keep track of other bugs by following the same
method.
</p>
<br><a name="doc_chap7_fig7"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 7.7: Adding Email To CC:</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-add-email.png" alt="Fig. 7"></td></tr>
</table>
<br><table class="ncontent" width="100%" border="0" cellspacing="0" cellpadding="0"><tr><td bgcolor="#bbffbb"><p class="note"><b>注記: </b>
電子メールアドレスは Gentoo Bugzilla にあらかじめ登録しなくてはならない。
いくつもアドレスを CC 欄に入れるときはコンマもしくは空白で区切って並べる。
Email addresses must be registered with Gentoo Bugzilla. In order to CC multiple
addresses, simply separate them with commas or spaces.
</p></td></tr></table>
<p>
こうした作業がひととおり済むと、 バグはさまざまに状態マークづけを受ける。
普段は Gentoo 開発者がこの作業を行なうが報告者自らが行なうこともたまにある。
バグの一生の間にうける可能性のある状態指標はつぎのようにいろいろある。
After all this work, the bug can undergo various status markings. This is
usually done by the Gentoo Developers and sometimes by the reporter. The
following are the various possible states a bug may go through during its
lifetime.
</p>
<ul>
<li>
UNCONFIRMED (未認証) - 一般的にあまり何度も見るようなものではない。
これはバグ報告者が高度な方法でバグを開示してから、
そのバグがまだ本物のバグかどうか不明だという意味である。
UNCONFIRMED - You're generally not going to see this too often. This means
that a bug reporter has opened a bug using the advanced method and is
uncertain his or her bug is an actual bug.
</li>
<li>
NEW (新規) - バグは開示されており新規とみなされている。
NEW - Bugs that are first opened are considered new.
</li>
<li>
ASSIGNED (付託済み) - 付託を受けた人物もこれはバグだと確認したときに、
たいていは ASSIGNED の印をつけ、 問題を探るあいだはこのままとなる。
これがあればバグは本物のバグだとして受付けられたといえる。
ASSIGNED - When the person you've assigned the bug too validates your bug,
it will often receive ASSIGNED status while they figure out the issue.
This lets you know that they've accepted your bug as a real bug.
</li>
<li>
REOPENED (再発) - 誰かがバグ解決したがその手法が不可能だと思ったり問題がまだ残ってしまうとしよう。
この場合にバグを再び開いてもよい。 どうか <b>このしくみを乱用しない</b> でほしい。
開発者がバグを閉じてしまうのが2度目3度目を数えたら、
もうバグが閉じられるのが運命だ。
REOPENED - Someone has resolved a bug and you think the solution is not
feasible or the problem still persists. At this point, you may re-open the
bug. Please <b>do not abuse this</b>. If a developer closes the bug a
second or third time, chances are that your bug is closed.
</li>
<li>
RESOLVED (解決済み) - バグは一件落着の運びとなった。
なかでもバグが解決したところで別の解法がある可能性を残しつつ課題は終わったとみなされたなら FIXED (修繕済み) と表示される。
この分類についてはあとでさらに踏み込んで説明する。
RESOLVED - A firm decision has been taken on the bug. Usually goes onto
FIXED to indicate the bug is solved and the matter closed although various
other resolutions are possible. We'll look into those a little later.
</li>
<li>
VERIFIED (立証済み) - バグの対処と処置の手順は正しい。
たいていは頻出問答集にある内容。
VERIFIED - The steps take to work the bug are correct. This is usually a QA
thing.
</li>
<li>
CLOSED (閉じている) - 基本的な意味はバグよ安らかに眠りたまえ、
絶ゆまず流れゆく新たなバグの下に埋められたのだということ。
CLOSED - Basically means RIP for the bug and it's buried under the never
ending flow of new bugs.
</li>
</ul>
<p>
さてしばらく経った日に、 このエラーの原因が strace ログから発見され処置を受けたのち、
RESOLVED FIXED (解決住み・閉じている) の刻印を得るとともに、
設定ファイルの位置が変更されたのでこの事実を ebuild の警告文に表示する更新を行うと言明することになった。
バグは解決に辿りついたのでこんな表示に変わる。
Now shortly afterward, we find the error in the strace log and fix the bug and
mark it as RESOLVED FIXED and mention that there was a change in the location
of configuration files, and that I will update the ebuild with a warning about
it. The bug now becomes resolved, and you are shown the following.
</p>
<br><a name="doc_chap7_fig8"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 7.8: Resolved Bug</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-reso.png" alt="Fig. 8"></td></tr>
</table>
<br><p>
そのちょっと下にこんな表示も現れる。
A little below, you'll see the following:
</p>
<br><a name="doc_chap7_fig9"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 7.9: Bug Options</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-options.png" alt="Fig. 9"></td></tr>
</table>
<br><p>
これはバグの再開示をするオプションで、 まだ開示してほしいとき
(つまり開発者は解決済みと判断したがあなたにとってそれは標準的とは事実上考えられないとき) に使う。
以上でバグは治まった。 しかし解決の帰着はほかにもある。
ちょっと他の分もみておこう。
This gives you the option of Reopening the bug if you wish to (i.e. the
developer thinks it's resolved but it's really not to your standards). Now our
bug is fixed! However, different resolutions can occur. Here's a small list:
</p>
<ul>
<li>
FIXED (修繕済み) - バグは退治された。 教えられた手順に従って問題解決しよう。
FIXED - The bug is fixed, follow the instructions to resolve your issue.
</li>
<li>
INVALID (不正) - 文書で明示されている手続を怠ったためバグが発生した。
INVALID - You did not do something specifically documented, causing the
bug.
</li>
<li>
DUPLICATE (重複) - この指南どおりにしていなくてバグ報告の重複が起きた。
DUPLICATE - You didn't use this guide and reported a duplicate bug.
</li>
<li>
WORKSFORME (要再現) - 開発者/人物はエラーが再現できないバグとした。
WORKSFORME - Developer/person assigned the bug cannot reproduce your error.
</li>
<li>
CANTFIX (不可処置) - どういうわけか何らかの事情があって解決できないバグである。
バグを引き受けた人物が事情を説明する一文を添えることになる。
CANTFIX - Somehow the bug cannot be solved because of certain
circumstances. These circumstances will be noted by the person taking the
bug.
</li>
<li>
WONTFIX (修繕求む) - たいていが新規 ebuild や機能強化の要望に対して出される。
基本的に開発者はある種の機能は追加不要と考えていたり、
それよりもっと良い代替案があるとか、 壊れた機能であるという理由があるときこうなる。
ときには解法を提示されたり、 問題が解決したと連絡が来たりするかもしれない。
WONTFIX - This is usually applied to new ebuilds or feature requests.
Basically the developer does not want to add a certain feature because it
is not needed, a better alternative exists, or it's just plain broken.
Sometimes you may be given a solution to get said issue resolved.
</li>
<li>
UPSTREAM (供給元) - このバグは Gentoo 開発チームによる処置ができないものであり、
あなた自信の手で問題を供給元 (つまりプログラムを実際に作成した人々) に質してほしいという要望である。
供給元にはバグを取り扱う手段が多少なりともある。
あるいは供給元のメイリングリスト、 IRC チャンネル、 バグ報告システムさえもあるかもしれない。
通報方法がわからないときは、 バグ報告のなかで尋ねれば誰かが正しい方向を指し示してくれるだろう。
UPSTREAM - The bug cannot be fixed by the Gentoo development team, and have
requested you take the problem upstream (the people that actually made the
program) for review. Upstream has a few ways of handling bugs. These
include mailing lists, irc channels, and even bug reporting systems. If
you're not sure how to contact them, ask in the bug and someone will point
you to the right direction.
</li>
</ul>
<p>
ときどきバグの解決より前に開発者の方から更新済みの ebuild を試してほしいと要望されるかもしれない。
つぎの章で ebuild のテスト方法について見てゆこう。
Sometimes, before the bug can be resolved, a developer may request that you
test an updated ebulid. In the next chapter we'll take a look at testing
ebuilds.
</p>
<p class="chaphead"><a name="doc_chap8"></a><span class="chapnum">8. 
</span>Testing Ebuilds</p>
<p class="secthead"><a name="doc_chap8_sect1">Getting The Files</a></p>
<p>
あなたはかつて foobar2 のコンパイルに修正を加えるバグ報告を送っていたとしよう。
そのとき開発者は問題点を理解できたかもしれないし、
ついでに ebuild 修正版をあなたに送ってちゃんと修正が効くかテストするよう求めたかもしれない。
Let's say that you reported a bug for the foobar2 compile fix from earlier. Now
developers might find out what the problem is and might need you to test the
ebuild for them to be sure it works for you as well:
</p>
<br><a name="doc_chap8_fig1"></a><table cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Figure 8.1: Ebuild Test Request</p></td></tr>
<tr><td align="center" bgcolor="#ddddff"><img src="../../images/docs/bugzie-ebuild-request.png" alt="Fig. 1"></td></tr>
</table>
<br><p>
ちょっと紛らわしい語句がでるのをここでことわっておく。
まず、 オーバーレイとは何かについて話そう。
オーバーレイは <span class="path" dir="ltr">/usr/portage</span> のような特別なディレクトリである。
その違いは中身のファイルが
<span class="code" dir="ltr">emerge sync</span> を実行しても削除されないことである。
幸いにも特別に <span class="path" dir="ltr">/usr/local/portage</span> ディレクトリがこの目的で作成される。
さっそく portage オーバーレイを <span class="path" dir="ltr">/etc/make.conf</span> で設定しよう。
お好みのエディタで make.conf を開いたらつぎの内容を末尾に付け足す。
Some rather confusing vocabulary is used here. First off, let's see what an
overlay is. An overlay is a special directory like <span class="path" dir="ltr">/usr/portage</span>,
the difference being that when you <span class="code" dir="ltr">emerge sync</span>, files contained within it
will not be deleted. Luckily, a special <span class="path" dir="ltr">/usr/local/portage</span>
directory is created for that purpose. Let's go ahead and set our portage
overlay in<span class="path" dir="ltr">/etc/make.conf</span>. Open make.conf up in your favorite editor
and add this towards the end.
</p>
<a name="doc_chap8_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 8.1: Setting Up PORTDIR_OVERLAY</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
PORTDIR_OVERLAY="/usr/local/portage"
</pre></td></tr>
</table>
<p>
さあこれでテスト用 ebuild のファイルが展開できる適切なディレクトリが作成できるようになった。
今回の例では sys-apps/foobar2 にそれらを置くことにする。
2番目のコメントがパッチを <span class="path" dir="ltr">files</span> ディレクトリに置くよう求めていることにお気づきだろうか。
このディレクトリは標準的なソース書庫 (パッチや init.d スクリプトなどなど) に含まれていない他の必要なファイルを入れる場所だ。
パッケージディレクトリに <span class="path" dir="ltr">files</span> という名前で加えられたサブディレクトリである。
では先に進んでそのディレクトリを作成しよう。
Now we'll want to create the appropriate directories to put our test ebuild
files in. In this case, we're supposed to put them in sys-apps/foobar2. You'll
notice that the second comment asks for a <span class="path" dir="ltr">files</span> directory for the
patch. This directory holds other required files that aren't included with
the standard source archive (patches, init.d scripts, etc). This is a subdir in
the package directory called <span class="path" dir="ltr">files</span>. Go ahead and create these
directories:
</p>
<a name="doc_chap8_pre2"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 8.2: Setting Up The Category And Package Directories</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">mkdir -p /usr/local/portage/sys-apps/foobar2/files</span>
</pre></td></tr>
</table>
<table class="ncontent" width="100%" border="0" cellspacing="0" cellpadding="0"><tr><td bgcolor="#bbffbb"><p class="note"><b>注記: </b>
-p というオプションは当該ディレクトリそのものに限らず親ディレクトリも存在しなければ (この場合は sys-apps と foobar2)
遡ってそれらも作成する。
The -p in mkdir creates not only the directory you want but also any missing
parent directories as well (sys-apps and foobar2 in this case).
</p></td></tr></table>
<p>
よろしい。 さあつぎはファイルをダウンロードしよう。
まず ebuild を
<span class="path" dir="ltr">/usr/local/portage/sys-apps/foobar2</span> にダウンロードして、
パッチを
<span class="path" dir="ltr">/usr/local/portage/sys-apps/foobar2/files</span> に置く。
さてファイルが揃ったところで ebuild のテストを開始する。
Ok now, we can go ahead and download the files. First, download the ebuild
into <span class="path" dir="ltr">/usr/local/portage/sys-apps/foobar2</span>, and then add the patch
to <span class="path" dir="ltr">/usr/local/portage/sys-apps/foobar2/files</span>. Now that we have the
files, we can begin working on testing the ebuild.
</p>
<p class="secthead"><a name="doc_chap8_sect2">Testing The ebuild</a></p>
<p>
emerge で利用できる ebuild の作成過程はとても簡単である。
ebuild には manifest ファイルを作成しなくてはならない。
これは ebuild コマンドで行なえる。 つぎのように実行しよう。
The process to create an ebuild that can be used by emerge is fairly simple. You
must create a Manifest file for the ebuild. This can be done with
the ebuild command. Run it as shown.
</p>
<a name="doc_chap8_pre3"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 8.3: Creating the Manifest file</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">ebuild foobar2-1.0.ebuild manifest</span>
&gt;&gt;&gt; Creating Manifest for /usr/local/portage/sys-apps/foobar2
</pre></td></tr>
</table>
<p>
いよいよ予定どおりに動くかテストするときだ。
Now let's test to see if it works as it should.
</p>
<a name="doc_chap8_pre4"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 8.4: Testing With emerge -pv</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">emerge -pv foobar2</span>
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild N ] sys-apps/foobar2-1.0 0 kB [1]
Total size of downloads: 0 kB
Portage overlays:
[1] /usr/local/portage
</pre></td></tr>
</table>
<p>
動いたみたいだ。 [ebuild ] の行の直後 [1] に注目しているか。
ここは先に作成したオーバーレイである
<span class="path" dir="ltr">/usr/local/portage</span> を指し示している。
先に進んでパッケージを emerge する。
It does seem to have worked! You'll notice the [1] next to the [ebuild] line.
That points to <span class="path" dir="ltr">/usr/local/portage</span>, which is the overlay we created
earlier. Now we go ahead and emerge the package.
</p>
<a name="doc_chap8_pre5"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing 8.5: Emerge Result</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">emerge foobar2</span>
Calculating dependencies ...done!
<span class="code-comment">(compile info snipped)</span>
&gt;&gt;&gt; Unpacking foobar2-1.0.tar.bz2 to /var/tmp/portage/foobar2-1.0/work
* Applying foobar2-1.0-Makefile.patch ... [ ok ]
<span class="code-comment">(compile info snipped)</span>
&gt;&gt;&gt; Merging sys-apps/foobar2-1.0 to /
&gt;&gt;&gt; chris +sandbox(preinst)
--- /usr/
--- /usr/bin/
&gt;&gt;&gt; /usr/bin/foobar2
</pre></td></tr>
</table>
<p>
第1の節で emerge は予定どおり動き出したとわかった。
第2の節で右側の状態メッセージに "[ ok ]" と出てパッチがうまく当ったことがわかった。
最後の節でプログラムのコンパイルが ok だと伝えてきた。
パッチは使えるよ!
さてこのあとは開発者にパッチがちゃんと使えたことと portage に修正をコミットできることを伝えよう。
In the first section we see that the emerge started off as it should. The second
section shows our patch being applied successfully by the "[ ok ]" status
message to the right. The last section tells us the program compiled ok. The
patch works! Now we can go and let the developer know that their patch works
fine, and that they can commit the fix to portage.
</p>
<p class="secthead"><a name="doc_chap8_sect3">Conclusion</a></p>
<p>
これで Bugzilla の使い方の手引きを終える。 お役に立つようなら本望だ。
ご質問やコメント、 この文書に関するご意見があれば私こと Chris White にお送りいただきたい。
-g フラグとコンパイルエラーのノートを提供してくれた moreon 氏、
bug-wrangling について助言をくれた #gentoo-bugs のみなさん、
maintainter-needed について助言をくれた Griffon26 氏、
一般的助言をくれた robbat2 氏、
文書の修正や必要に応じた追加をしてくれた fox2mke 氏、
以上の各位に特別な感謝を申し上げる。
This concludes the howto on working with Bugzilla. I hope you find this useful.
If you have any questions, comments, or ideas regarding this document, please
send them to me at Chris White. Special thanks go to
moreon for his notes on -g flags and compile errors, the people at #gentoo-bugs
for helping out with bug-wrangling, Griffon26 for his notes on
maintainer-needed, robbat2 for general suggestions and fox2mike for fixing up
the doc and adding stuff as needed.
</p>
<br><p class="copyright">
The contents of this document are licensed under the <a href="http://creativecommons.org/licenses/by-sa/2.5">Creative Commons -
Attribution / Share Alike</a> license.
</p>
<!--
<rdf:RDF xmlns="http://web.resource.org/cc/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<License rdf:about="http://creativecommons.org/licenses/by-sa/2.5/">
<permits rdf:resource="http://web.resource.org/cc/Reproduction" />
<permits rdf:resource="http://web.resource.org/cc/Distribution" />
<requires rdf:resource="http://web.resource.org/cc/Notice" />
<requires rdf:resource="http://web.resource.org/cc/Attribution" />
<permits rdf:resource="http://web.resource.org/cc/DerivativeWorks" />
<requires rdf:resource="http://web.resource.org/cc/ShareAlike" />
</License>
</rdf:RDF>
--><br>
</td>
<td width="1%" bgcolor="#dddaec" valign="top"><table border="0" cellspacing="4px" cellpadding="4px">
<tr><td class="topsep" align="center"><p class="altmenu"><a title="View a printer-friendly version" class="altlink" href="/doc/en/bugzilla-howto.xml?style=printable">Print</a></p></td></tr>
<tr><td class="topsep" align="center"><p class="alttext">Updated February 27, 2010</p></td></tr>
<tr><td class="topsep" align="left"><p class="alttext"><b>Summary: </b>
This document shows the proper method of reporting bugs using Bugzilla.
</p></td></tr>
<tr><td align="left" class="topsep"><p class="alttext">
Chris White
<br><i>Author</i><br><br>
<a href="mailto:fox2mike@gentoo.org" class="altlink"><b>Shyam Mani</b></a>
<br><i>Editor</i><br></p></td></tr>
<tr lang="en"><td align="center" class="topsep">
<p class="alttext"><b>Donate</b> to support our development efforts.
</p>
<form action="https://www.paypal.com/cgi-bin/webscr" method="post">
<input type="hidden" name="cmd" value="_xclick"><input type="hidden" name="business" value="paypal@gentoo.org"><input type="hidden" name="item_name" value="Gentoo Linux Support"><input type="hidden" name="item_number" value="1000"><input type="hidden" name="image_url" value="/images/paypal.png"><input type="hidden" name="no_shipping" value="1"><input type="hidden" name="return" value="http://www.gentoo.org"><input type="hidden" name="cancel_return" value="http://www.gentoo.org"><input type="image" src="http://images.paypal.com/images/x-click-but21.gif" name="submit" alt="Donate to Gentoo">
</form>
</td></tr>
<tr lang="en"><td align="center"><iframe src="http://sidebar.gentoo.org" scrolling="no" width="125" height="850" frameborder="0" style="border:0px padding:0x" marginwidth="0" marginheight="0"><p>Your browser does not support iframes.</p></iframe></td></tr>
</table></td>
</tr></table></td></tr>
<tr><td colspan="2" align="right" class="infohead">
Copyright 2001-2011 Gentoo Foundation, Inc. Questions, Comments? <a class="highlight" href="/main/en/contact.xml">Contact us</a>.
</td></tr>
</table></body>
</html>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment