Skip to content

Instantly share code, notes, and snippets.

@liangtai
Forked from anonymous/bugzilla-howto.xml
Created May 31, 2011 13:18
Show Gist options
  • Save liangtai/1000482 to your computer and use it in GitHub Desktop.
Save liangtai/1000482 to your computer and use it in GitHub Desktop.
Gentoo文書日本語翻訳
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/bugzilla-howto.xml,v 1.17 2010/02/28 06:14:00 nightmorph Exp $ -->
<guide lang="ja">
<title>Gentooバグ報告ガイド</title>
<author title="Author">
<mail link="chriswhite@gentoo.org">Chris White</mail>
</author>
<author title="Editor">
<mail link="fox2mike@gentoo.org">Shyam Mani</mail>
</author>
<author title="翻訳">
<mail link="liangtai.s4@gmail.com">島本良太</mail>
</author>
<abstract>
この文書はBugzillaへバグを報告する適切な手順をご紹介します。
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
<version>1.15</version>
<date>2010-02-27</date>
<!-- Original revision: 1.17 -->
<chapter>
<title>はじめに</title>
<section>
<title>まえがき</title>
<body>
<p>
バグ報告は、 その仕方によってはバグの修正が遅れてしまう一因になりえます。
私達はこのガイドを著すにあたり、
開発者と利用者がともにバグの解決に向けてより円滑に互いの意思疎通をはかってほしいとの願いを込めました。
どんなプロジェクトにあっても、
品質保証にバグの修正が果たす役割は決定的でなくとも重要なことです。
このガイドが適切なバグ修正の助けになることを望んでやみません。
</p>
</body>
</section>
<section>
<title>バグです!!!!バグです!!!!</title>
<body>
<p>
パッケージをemergeしていたとき、
あるいはプログラムを使っていたとき突如最悪の事態が発生、
つまりバグが現れたとしましょう。
バグは、
emergeが失敗することもあればセグメント違反が発生するなどいろいろその出方が異なります。
原因が何であっても、 とどのつまりその手のバグは潰さねばなりません。
どんなバグがあるか少し例を示します。
</p>
<pre caption="ランタイムエラー">
$ <i>./bad_code `perl -e 'print "A"x100'`</i>
Segmentation fault
</pre>
<pre caption="emerge の失敗例">
/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>
<p>
こういうエラーは本当に困りものです。 しかしちょっと待ってください、
見付けたのはいいのですがそのあとどうすればいいのでしょう。
つぎの節ではランタイムエラーを取り扱える、 2つの重要なツールを紹介します。
そのあとにコンパイルエラーの話をして、 その取り扱い方も論じましょう。
さてまずはランタイムエラーをデバッグする <c>gdb</c> から始めましょうか。
</p>
</body>
</section>
</chapter>
<chapter>
<title>GDBを使ってデバッグ作業</title>
<section>
<title>はじめに</title>
<body>
<p>
GDB[(G)NU (D)e(B)uggerの略]というプログラムは、
ランタイムエラーを発見するために使います。
通常このエラーはメモリエラーにつながります。
具体的にデバッグとは何をすればいいのか、 まずはそれから見て行きましょう。
プログラムをデバッグするときに大事な作業があります。
<c>FEATURES="nostrip"</c> というオプションつきでプログラムを
<c>emerge</c> しなおすのがそれです。 こうして、
プログラムに埋め込まれたデバッグシンボルがstrip(切除)されるのを防ぎます。
ところでなぜデフォルトではプログラムがstrip処理されるのでしょう。
その理由はmanページがgzip圧縮される理由と同じです。
つまり省スペース化ということです。
プログラムからデバッグシンボルが取り除かれた場合と残した場合とでサイズがどれほど違うかをご覧に入れましょう。
</p>
<pre caption="ファイル容量の比較">
<comment>(strip済み)</comment>
-rwxr-xr-x 1 chris users 3140 6/28 13:11 bad_code
<comment>(デバッグシンボルをそのまま残した場合)</comment>
-rwxr-xr-x 1 chris users 6374 6/28 13:10 bad_code
</pre>
<p>
ちなみに <e>bad_code</e> はこれから <c>gdb</c> でデバッグされるプログラムです。
ご覧のとおりデバッグシンボルが無ければプログラムは3140バイトになりますが、
それを残すと6374バイトにもなります。 ほとんど2倍近い比率です。
そのほかに2件、 デバッグ前にしておくとよいことがあります。
その1つめは、 CFLAGSとCXXFLAGSに <c>ggdb</c> を追加しておくことです。
このフラグがあれば通常よりも多めにデバッグ用情報がプログラムに埋め込まれます。
どうなるのかはあとで説明しましょう。
フラグの追加により <path>/etc/make.conf</path> がどんな感じに <e>なりそう</e>
かを例で示します。
</p>
<pre caption="make.confの設定">
CFLAGS="-O1 -pipe -ggdb"
CXXFLAGS="${CFLAGS}"
</pre>
<p>
そしてもう1つしておきたいこととは、
パッケージのUSEフラグにもデバッグ指示をつけるというしかけです。
これは <path>package.use</path> ファイルを編集して行ないます。
</p>
<pre caption="package.useファイルでUSEフラグにdebugを追加">
# <i>echo "カテゴリー名/パッケージ名 debug" >> /etc/portage/package.use</i>
</pre>
<note>
<path>/etc/portage</path> というディレクトリは初めは存在しませんので、
まだ作っていなければ作成しましょう。
既に <path>package.use</path> ファイルでこのパッケージにUSEフラグがついていたときはお好みのエディタで編集することになります。
</note>
<p>
以上の変更を施したうえでつぎのようにパッケージをemergeしなおします。
</p>
<pre caption="デバッグ用にパッケージを再度emerge">
# <i>FEATURES="nostrip" emerge package</i>
</pre>
<p>
これでデバッグシンボルが準備できましたので、
いよいよプログラムのデバッグに入ります。
</p>
</body>
</section>
<section>
<title>GDB上でプログラムを走らせる</title>
<body>
<p>
"bad_code"という名前のプログラムがあるとします。
そして誰かがプログラムのクラッシュを報告し、 その実例を提供したとしましょう。
あなたはこれを聞いてテストをしました。
</p>
<pre caption="プログラムをクラッシュさせる">
$ <i>./bad_code `perl -e 'print "A"x100'`</i>
Segmentation fault
</pre>
<p>
この人物の言うとおりでした。
確かにプログラムが壊れているのですからバグはあります。
いよいよ問題解決に <c>gdb</c> が登場する場面です。
ちゃんと引数つきで走らせたいので <c>gdb</c> 上では
<c>--args</c> を使って引数を渡し実行してみました。
</p>
<pre caption="GDB経由でプログラムを実行">
$ <i>gdb --args ./bad_code `perl -e 'print "A"x100'`</i>
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>
<note>
コアダンプを使ってデバッグする方法もあります。
コアファイルにはgdbからプログラムを起動して得られるのと同じ情報が入っています。
bad_codeプログラムとコアファイルでデバッグするときは
<c>gdb ./bad_code core</c> (coreはコアファイルの名前)というふうにしましょう。
</note>
<p>
"(gdb)"というプロンプトが現れ入力待ちとなります。
まずはプログラムを走らせなくてはなりません。
コマンド行に <c>run</c> と入力するとこんな反応が返ってきます。
</p>
<pre caption="GDB上でプログラムを実行">
(gdb) <i>run</i>
Starting program: /home/chris/bad_code
Program received signal SIGSEGV, Segmentation fault.
0xb7ec6dc0 in strcpy () from /lib/libc.so.6
</pre>
<p>
プログラムが始動したのがわかり、 SIGSEGV(セグメント違反)が通知されています。
これはプログラムがクラッシュしたとGDBが伝えているのです。
さらにプログラムがクラッシュした時点からトレースして判明できる最後に作動した関数名が示されています。
しかしこれはあまり役に立ちません。
というのもプログラムの中ではstrcpyをあちこちで使っているので、
そのどれが問題を起こしているか探るのが難しいからです。
そこでなんとか探る手段として、 バックトレース(後方追跡)という方法をとります。
バックトレースはプログラムで呼び出されるすべての関数を始動位置から事故現場まで逆順に辿ります。
クラッシュを引き起こさず復帰を終えている関数はバックトレースに現れません。
バックトレースの方法は、 (gdb)というプロンプトのあとに <c>bt</c> と書き送ります。
するとこんなふうになります。
</p>
<pre caption="プログラムのバックトレース">
(gdb) <i>bt</i>
#0 0xb7ec6dc0 in strcpy () from /lib/libc.so.6
#1 0x0804838c in run_it ()
#2 0x080483ba in main ()
</pre>
<p>
トレースパターンがはっきりしてきました。
main()がまず呼び出され、 つぎにrun_it()が来て、
run_it()内のどこかに問題のstrcpy()があります。
ここまでわかれば開発者が問題を絞り込むのが楽になります。
この出力には多少の例外があります。
第一にデバッグシンボルを残す <c>FEATURES="nostrip"</c>
オプションを忘れたらどうなるでしょう。
デバッグシンボルが取り除かれた場合、 出力はつぎのようになります。
</p>
<pre caption="デバッグシンボルが切除されたプログラムのバックトレース">
(gdb) <i>bt</i>
#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>
<p>
このバックトレースにはたくさんの??という表示が出てきます。
デバッグシンボルが無いため <c>gdb</c>
はプログラムがどんな動作をしたのか判らないのです。
したがってstrip <e>しない</e> ことが不可欠です。
さて先ほど-ggdbフラグについて触れました。
このフラグが有効な場合に出力がどうなるか見てみましょう。
</p>
<pre caption="-ggdbつきのプログラムバックトレース">
(gdb) <i>bt</i>
#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>
<p>
これはさっきよりかなり開発者向けの情報がつまっています。
関数名の表示にとどまらずソースコードの行番号までも明示されています。
容量が許せばこれが一番よさそうな方法でしょう。
デバッグシンボルあり、 なし、
-ggdb有効のそれぞれのプログラムがどれくらいのファイル容量になるかを示します。
</p>
<pre caption="-ggdbフラグつきともファイル容量を比較">
<comment>(strip済み)</comment>
-rwxr-xr-x 1 chris users 3140 6/28 13:11 bad_code
<comment>(デバッグシンボル有効)</comment>
-rwxr-xr-x 1 chris users 6374 6/28 13:10 bad_code
<comment>(-ggdbフラグ有効)</comment>
-rwxr-xr-x 1 chris users 19552 6/28 13:11 bad_code
</pre>
<p>
ご覧のとおり、 -ggdbにするとデバッグシンボル入りと比べおよそ
<e>13178</e> バイトもサイズが増えています。
しかし今まで見てきたとおりデバッグ情報が開発者の手に入るならファイルの肥大は無駄ではありません。
バックトレースの出力はターミナル上で写し取ってファイル化できます。
(X上のターミナルでないときはgpmを使う方法があります。
詳細は割愛しますがコピー・ペーストの方法については
<uri link="/doc/en/gpm.xml#doc_chap4">documentation for gpm</uri>
<uri link="/doc/ja/gpm.xml#doc_chap4">(日本語訳「gpmで作業を行う」)</uri>
を読んでください。)
以上、 <c>gdb</c> ですることはもうありませんので終了(quit)しておきましょう。
</p>
<pre caption="GDBを終了">
(gdb) <i>quit</i>
The program is running. Exit anyway? (y or n) <i>y</i>
$
</pre>
<p>
ここまでで <c>gdb</c> の話は終わりです。
<c>gdb</c> を利用してもっと良いバグ報告ができるようになってほしいと思います。
ところが他にも実行時にプログラムがおかしな動作をする種類のエラーがあります。
そのひとつが不正なファイルアクセスをして起きるエラーです。
これを見付けるとき <c>strace</c> という小粋なツールが使えます。
</p>
</body>
</section>
</chapter>
<chapter>
<title>straceを使ってファイルアクセスエラーを発見</title>
<section>
<title>はじめに</title>
<body>
<p>
プログラムは設定情報を読み出したりハードウェアにアクセスしたりログを書き出したりと、
たびたびファイルを利用しています。
たまにプログラムはそういったファイルへ不正にアクセスしようとすることがあります。
その動きをつかむために <c>strace</c> というプログラムが考案されました。
<c>strace</c> はメモリーやファイルを扱う呼び出し命令などのシステムコールを追跡(この名の由来)します。
foobar2という名前のプログラムを例として説明しましょう。
これがfoobarの新バージョンという位置付けです。
さて何とこれをfoobar2に更新してみたら今までの設定が失くなってしまいました。
foobar第1版の設定で"foo"としてあるところが無視され、
デフォルトの"bar"が使われています。
</p>
<pre caption="設定情報に不正が起きたfoobar2">
$ <i>./foobar2</i>
Configuration says: bar
</pre>
<p>
これまでの設定ではちゃんとfooにしてあったので
<c>strace</c> を使って何が起きているか探るとしましょう。
</p>
</body>
</section>
<section>
<title>straceを用いて問題を追跡</title>
<body>
<p>
システムコールが行き着くところまで <c>strace</c> に記録させてみます。 使い方は、
<c>strace</c> に"-o[ファイル名]"という形でオプションをつけます。
つぎのようにfoobar2に適用してみましょう。
</p>
<pre caption="strace経由でfoobar2を実行">
# <i>strace -ostrace.log ./foobar2</i>
</pre>
<p>
これで現在のディレクトリに <path>strace.log</path>
という名前のファイルができます。 これを読むと、 関係しそうなところがありました。
</p>
<pre caption="straceログのようす">
open(".foobar2/config", O_RDONLY) = 3
read(3, "bar", 3) = 3
</pre>
<p>
ははん。 やはり問題点がありますね。
設定ディレクトリの位置は <path>.foobar</path>
だったのに <path>.foobar2</path> に変えられています。
またプログラムはやはり"bar"を読んでいることもわかります。
こうした事例があるときはebuildの保守担当者に連絡してユーザに注意を促す表示をしてもらうようお願いしてもよいでしょう。
ただ今回は、 <path>.foobar</path>
ディレクトリから設定ファイルのコピーを持って来て従来の正しい結果を得ることにしても構いません。
</p>
</body>
</section>
<section>
<title>おわりに</title>
<body>
<p>
さてここまでは実行時のバグの発見に注意を払ってきました。
この手のバグはプログラムを動かしてみたり使っているときに問題が発覚します。
しかし、 そもそもコンパイルが通らない場合は、
実行時のエラーよりもコンパイルできないことが問題です。
どのようにして <c>emerge</c>
でのコンパイルエラーに取り掛かればよいか見てゆきましょう。
</p>
</body>
</section>
</chapter>
<chapter>
<title>emergeエラーの扱い方</title>
<section>
<title>はじめに</title>
<body>
<p>
先に挙げた例のような <c>emerge</c>
エラーはユーザをイライラさせる大きな原因になります。
これを報告していただくことがGentooを健全に保つうえで欠かせません。
foobar2という名のebuildにビルドエラーがあるという想定例をみてみましょう。
</p>
</body>
</section>
<section id="emerge_error">
<title>emergeエラーを評価</title>
<body>
<p>
とても単純な <c>emerge</c> エラーをここに示します。
</p>
<pre caption="emergeエラー(行が長過ぎるため画面幅に合わせ一部改行しています)">
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>
<p>
順調にコンパイルを進めていたプログラムが突如としてエラーメッセージを出して止まってしまいました。
この手のエラーはつぎのようにコンパイルメッセージとビルドエラーとemergeエラーメッセージの3つの部分に分けられます。
</p>
<pre caption="エラー文の抜粋(行が長過ぎるため画面幅に合わせ一部改行しています)">
<comment>(コンパイル中のメッセージ)</comment>
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
<comment>(ビルドエラー)</comment>
foobar2.c:1:17: ogg.h: No such file or directory
make: *** [foobar2.o] Error 1
<comment>(emergeエラー)</comment>
!!! 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>
<p>
コンパイラ関連のメッセージがエラーの出所を示しています。
エラーの発生時どこをコンパイルしていたか開発者が判る手掛かりになるように、
ほとんどの場合少なくとも10行程度コンパイル情報を含めておくとよいでしょう。
</p>
<p>
システムの言語を英語以外に設定してあっても報告に含めるエラーメッセージは必ず英語で出すようにしてください。
emergeコマンドの前に <c>LC_ALL=C</c> をつければ一時的に英語のロケールに切り替わります。
</p>
<pre caption="ロケールを一時的に英語へ切り替え">
# <i>LC_ALL=C emerge sys-apps/foobar2</i>
</pre>
<note>
ロケールを設定する <c>LC_ALL</c> 環境変数を変えなくてはならないのはほぼこの時だけです。
システムの言語を変える方法をお探しでしたらここではなく <uri
link="guide-localization.xml">Localization Guide</uri>
(日本語版 <uri link="doc/ja/guide-localization.xml">ローカライズガイド</uri>)
に答えを求めてください。
</note>
<p>
makeのエラーは現実に起こったエラーであり開発者に必要な情報です。
"make: ***" と出てきたら、 そこがエラーの発生場所である場合が多いようです。
通常は上から10行コピーして報告にペーストすればそれで開発者が問題をつきとめられます。
しかし必ずしもそれでうまくいくとは限りませんので別の方法もちょっと紹介しましょう。
</p>
<p>
emergeエラーとはエラーの際に <c>emerge</c> が出すものです。
たまに重要な情報が含まれることもあります。
しばしばこのemergeエラーの部分をポストしただけにしてしまう間違いを犯す人がいます。
この情報だけでは利用価値がありません。
makeエラーとコンパイル情報を添えてはじめて開発者に問題を起こしたアプリケーション名とバージョンが伝わります。
余談ですがmakeはプログラムの構築過程を担うのにひろく使われています(<b>ただし必ずというわけではありません</b>)。
どこにも "make: ***" エラーが無いときは、
ともかくemergeエラーが現れるところまで20行を写し取って報告に貼り付けましょう。
こうすればほぼどんなビルドシステムのエラーメッセージも間に合うはずです。
ではエラーがかなり長くなりそうなときはどうしましょう。
つまり全容をつかむのに10行では足りそうにない場合です。
そのときはPORT_LOGDIRが活躍します。
</p>
</body>
</section>
<section>
<title>emergeとPORT_LOGDIR</title>
<body>
<p>
PORT_LOGDIRはPortageの変数名であり、
emergeごとのログを入れておくログディレクトリを設定します。
何が起こるのかを見てみましょう。
まずPORT_LOGDIRで好みの位置のパスを指定し、 emergeを実行します。
例として <path>/var/log/portage</path> という場所を作ってみたとしましょう。
ここをログディレクトリとして利用するならつぎのようにします。
</p>
<note>
初期状態では <path>/var/log/portage</path> というディレクトリは無いので、
作らなくてはならないはずです。
作成を怠ったままですとこの設定どおりならemergeはログの書き出しに失敗することになります。
</note>
<pre caption="PORT_LOGDIRを設定してemerge">
# <i>PORT_LOGDIR=/var/log/portage emerge cate-gory/foobar2</i>
</pre>
<p>
それではもう一度emergeの失敗を起こしましょう。
今度はつぎの作業に使うログが手に入り、 これはあとでバグ報告に添付できます。
ちょっとログディレクトリの中を覗いてみましょうか。
</p>
<pre caption="PORT_LOGDIRの中身">
# <i>ls -la /var/log/portage</i>
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>
<p>
ログファイルの名前は [カテゴリー名]:[パッケージ名]-[バージョン]:[日付].log
となっています。
ログファイルはざっと見たところemerge過程の全体が記されているとわかります。
このあとのバグ報告の節で説明するとおり、 添付用に使えます。
もうこれで必要な情報は滞りなく入手できましたからバグ報告の実行に移れるはずです。
しかしその前に、 同じ報告を他の誰かがしていないか確かめる必要があります。
バグの検索方法について見てみましょう。
</p>
</body>
</section>
</chapter>
<chapter>
<title>Bugzillaの検索方法</title>
<section>
<title>はじめに</title>
<body>
<p>
Gentooでは <uri link="http://www.bugzilla.org">Bugzilla</uri> をバグ処理に使っています。
GenntooのBugzillaにはHTTPSやHTTPで接続できます。
HTTPSは安全に問題があるネットを介して接続する場合や単に気になる人向けに提供されています。
話に一貫性をもたせるためこれ以降の例ではどれもHTTPSの方を使うことにします。
サイトの様子は <uri link="https://bugs.gentoo.org">Gentoo Bugs</uri>
で見てください。
</p>
<p>
開発者やbug-wranglersによると、
重複して同内容のバグ報告が出されるのが最大級にイラッ☆とくるそうです。
他の重要なバグに対処できたはずの貴重な時間を削られることになるからです。
いくつか検索のしかたに簡単な工夫をすればこの問題は防げます。
ですからバグ検索の仕方と、 似たバグが無いか探す方法について見てゆきましょう。
先に挙げたxclassのemergeエラーを例にとって話をすすめます。
</p>
<pre caption="xclass emergeエラー">
/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>
<p>
バグを探すので <uri link="https://bugs.gentoo.org/">Gentoo Bugzilla
ホームページ</uri> に行きます。
</p>
<figure link="/images/docs/bugzie-homepage.png" caption="Bugzillaホームページ"/>
<p>
ここは"Query Existing bug reports"(既にあるバグ報告から探す)をクリックします。
"basic bug search"(基本のバグ検索)を素通りしてこちらを選ぶのには理由があります。
基本のバグ検索だとあいまいな結果が出やすく、
検索結果を調べて重複するバグを見つける作業を遅らせ妨げてしまいがちだからです。
さて検索画面でクリックしたあとにこんなページが出てきます。
</p>
<figure link="/images/docs/bugzie-search.png" caption="Bugzillaの検索ページ"/>
<note>
前に"Advanced Search"(高度な検索)を行なった場合はおそらく代わりにこの画面が出るはずです。
</note>
<p>
"Advanced Search"へのリンクをクリックして高度な検索のページに進みます。
</p>
<figure link="/images/docs/bugzie-adv-search.png" caption="高度な検索のページ"/>
<p>
これは「高度な検索」ページの様子を示しています。
一見して圧倒されそうな雰囲気ですけれど、
Bugzillaが返す少々あいまいな結果を絞り込むための条件をいくつか見ていくだけです。
</p>
<figure link="/images/docs/bugzie-content.png" caption="内容"/>
<p>
第1の記入欄はバグのSummary(要約)です。
ここは単にクラッシュしたパッケージ名を入れました。
Bugzillaさんが結果を出してくれないときは念のためパッケージ名を削除してやりなおしましょう。
パッケージ名を書かずに報告した人がいるかもしれないからです。
(まさかそんな、
と思われるかもしれませんが私達は結構な割合でおかしなバグ報告を見てきました。)
</p>
<p>
Product(部門)、 Component(構成部分)、
Version(バージョン)はそのままデフォルトでかまいません。
絞り込み過ぎてバグを見落してしまわないようにするためです。
</p>
<p>
Comment(コメント)は重要な部分です。
エラーを特定できそうな事実をかいつまんでコメント欄に書き出します。
基本的に、 ビルドエラーの最初の行のようなものまで挙げる必要はないので、
真のエラーが姿を現す直前の1行を探し出しましょう。
また、 Bugzillaがコメントを変な形に読み取らずに済むよう句読点をあらかじめ全部抜き取っておいてもよいでしょう。
さきのxclassのemergeエラーの例でいえばこうなります。
</p>
<pre caption="コメント行に書いた内容">
menudef.h:78: error: brace-enclosed initializer used to initialize `OXPopupMenu'
<comment>(引用符 ' ' を削除)</comment>
menudef.h 78 error brace-enclosed initializer used to initialize OXPopupMenu
</pre>
<p>
このように具体的であれば、
他のxclass関連のコンパイル失敗報告まで必死に読んで探すこともなく、
バグが見つかるはずです。
</p>
<p>
URI、 Whiteboard、 Keywordはそのままにしてかまいません。
これだけ書いておけばバグを見付けるのに充分すぎるほどです。
埋めた欄はつぎのとおりです。
</p>
<figure link="/images/docs/bugzie-comp-search.png" caption="書き込みが済んだ検索欄"/>
<p>
いよいよ検索ボタンをクリックすると、 こんな結果が現れます。
</p>
<figure link="/images/docs/bugzie-search-result.png" caption="検索結果"/>
<p>
バグはたったの2件だけ! 結構簡単にいけそうです。
1件目を見てみたら、 まさに探していたバグでした。
</p>
<figure link="/images/docs/bugzie-located.png" caption="突きとめられたバグ報告"/>
<p>
欲しいバグ報告が見付かっただけでなく、 既に解決されていたこともわかりました。
最後のコメントに解法が載っていて、 対処すべき方法がわかります。
では「高度な検索」を使わなかった場合はどうなっていたのでしょう。
</p>
<figure link="/images/docs/bugzie-basic-search-result.png" caption="基本のバグ検索の結果"/>
<p>
検討すべきバグがさらに4つも!
パッケージが大きくなるにつれもっとひどくなります。
しかしこんな簡単なツールを使っただけでも検索結果がしっかりと絞り込まれ、
特定のバグを試して突き止められるです。
</p>
</body>
</section>
<section>
<title>おわりに</title>
<body>
<p>
いくら探してもバグ報告が見付からなかった場合はどうでしょう。
そう、 あなたは新種のバグを発見したのです。
新しいバグを提出するところまでバグ報告の手順を見てゆきましょう。
</p>
</body>
</section>
</chapter>
<chapter>
<title>バグの報告の仕方</title>
<section>
<title>はじめに</title>
<body>
<p>
この章ではぴっかぴかの新バグをBugzillaに申告する方法を学びます。
<uri link="https://bugs.gentoo.org">Gentoo Bugs</uri> に移動したら、
</p>
<figure link="/images/docs/bugzie-homepage.png" caption="Bugzillaホームページ"/>
<p>
"Report a Bug - Using the guided format"(バグを報告 - ガイドつき記入欄を利用)
をクリックします。
</p>
<figure link="/images/docs/bugzie-prod-select.png" caption="部門を選択"/>
<p>
バグを出すところを間違えないようにと <b>大きく</b> 強調してあるのが見えます。
大部分のバグは、 Gentoo Linuxに該当します。
</p>
<p>
にもかかわらずebuildバグをPortage開発(Portageツリーを取り扱うPortageチームを想定)とかinfra(infraがミラーやrsyncに接続して直接問題解決をはかると想定)へ出してしまう人がいるのです。
残念ながら、 そうではありません。
</p>
<p>
他にも文書整備(ドキュメンテーション)関連のバグの勘違いがよくおこります。
たとえば <uri link="/proj/en/releng/catalyst/">Catalyst Docs</uri>
にバグを見付けたユーザがいたとしましょう。
一般的な考えでいくと <uri link="http://gdp.gentoo.org">GDP</uri> に関連したDocs-userの方へバグを申告してしまいがちなのですが、
本来は <uri link="/proj/en/releng/">Release Engineering</uri>
チームに知らせねばなりません。 大雑把に分ければ
<path>http://www.gentoo.org/doc/*</path> 以下の文書のみがGDPに属します。
それ以外で <path>http://www.gentoo.org/proj/*</path>
以下に置かれている文書なら該当するチームに属します。
</p>
<note>
Gentoo Linuxとは思えない製品のバグがGentoo Bugzillaに申告される事態は、
むしろGentoo Linuxの製品に関するバグなのにどこか他所に出される場合よりもよく見受けられるようです。
どちらも困ったものですが、 前者のほうが受け入れやすく理解できます
(ただしウェブサイトのバグを除きます。 この件の問題まで入ってきがちでした...)。
</note>
<p>
今回のバグはebuildバグなのでGentoo Linux行きです。
目指す進路をとるとバグ報告の階段がまちうけていました。
1歩目の段に進むと、
</p>
<figure link="/images/docs/bugzie-guide-step1.png" caption="ガイドつき記入欄での第1歩"/>
<p>
ここの第1段が実に重要です(赤字で記されています)。
ここでお持ちのバグと同じものをまだ他の誰も発見していないとわかるまで検索します。
この段階を省いて、 同じようなバグがあるのに報告を出したら、
DUPLICATE(重複)のマークが付けられてしまいます。
つまりQAの労力を多大に浪費したことになるのです。
上図で番号に打消線の入ったバグが重複バグだと言えばおわかりいただけますでしょうか。
さて第2段に進みましょう。 ここで情報を書き込みます。
</p>
</body>
</section>
<section>
<title>必須の情報</title>
<body>
<figure link="/images/docs/bugzie-basic.png" caption="基本情報"/>
<p>
それぞれがどういった内容なのか、 つぶさに見ていきましょう。
</p>
<ul>
<li>
まずは Product(部門)のところから。
ここでBugzilla(bugs.gentoo.orgに関係するバグ)、
Docs-user(ユーザ向け文書の整備)、
Gentoo Linux(ebuildなど)といったふうに分かれたGentooの部門のどこかにバグを仕分けます。
</li>
<li>
Component(構成部分)のところは、
問題発生箇所をさらに限定するためバグがあるのは部門のどの分野か選びます。
</li>
<li>
Hardware(ハードウェア)のところでは動作させている(CPUの)機種を選びます。
例えばSPARCで使用しているのならSPARCに設定します。
</li>
<li>
Operating System(オペレーティングシステム)でどのOSを利用しているか選びます。
Gentooは「メタディストリビューション」との位置付けなので、
Linuxとは違うオペレーティングシステムで動作させていることもあります。
</li>
</ul>
<p>
そして、 今回の例のバグについてはこうです。
</p>
<ul>
<li>Product - Gentoo Linux (ebuildの問題なので)</li>
<li>Component - Application (foobar2というアプリケーションの欠陥だから)</li>
<li>Hardware Platform - All (動作機種を選ばず起こりうるエラーだから「すべて」)</li>
<li>Operation System - All (あらゆる形式のシステムで起こりうるから「すべて」)</li>
</ul>
<figure link="/images/docs/bugzie-basic-comp.png" caption="書き終えられた基本情報"/>
<ul>
<li>
Build Identifier (User Agent)は基本的にバグ報告をしたウェブブラウザのユーザエージェント情報をBugzillaが記録するためにあります。
そのまま放置してかまいません。
</li>
<li>
URLは任意記入欄であり、
Bugzillaの供給側の引用やパッケージのホームページのリリースノートなど他のサイトからの関連情報を指し示すのに使われます。
決してpastebinサイトのほうにエラーメッセージやログや <c>emerge --info</c>
の出力やスクリーンショットなどを置いてリンクを貼るようなことはしないでください。
いずれもバグ報告に添付すべきです。
</li>
<li>
Summary(要約)でパッケージのカテゴリー名、 名称、 バージョン番号を記入します。
</li>
</ul>
<p>
要約にカテゴリー名を書かずに済ましても実際にさほどまずくはありませんが、
記入を推奨します。
しかしパッケージ名が書かれていないと何のバグの話が書いてあるのか判りようがないので、
結局あとでスタッフが聞き返すことになります。
バージョン番号はバグ報告を探す人にとって重要な情報です。
もし20人からバグ報告が寄せられて1件もバージョン番号が書かれていないとしますと、
同じバグを探すときみんなどうやって目当てのバグと同じか区別すればいいのでしょう。
いちいちバグ報告を読んで探すのもさほど困難ではないかもしれませんが、
これがもし200件の未記載だったら...。 とても容易ではありません。
パッケージ情報はここまでで、 そのあとに今回起きたことの短い説明を加えることになります。
たとえばこんなふうに。
</p>
<figure link="/images/docs/bugzie-summary.png" caption="まとめ"/>
<p>
こんな簡単な規則でもバグの扱いがとても楽になります。 つづいては詳細です。
バグにまつわる情報をここに書きます。 実例はこんなふうになります。
</p>
<figure link="/images/docs/bugzie-details.png" caption="詳細"/>
<p>
やっと開発者になぜバグ報告を寄せたかの理由が伝わるのがここです。
彼(女)らは問題が再現できるか試すつもりでいます。
再現性により問題再発の頻度がわかります。
今回の例では単にfoobar2を起動すればいつでも再現できます。
その情報を書き込みましょう。
</p>
<figure link="/images/docs/bugzie-reprod.png" caption="再現"/>
<p>
バグ発見の経緯は述べてあります。 つぎの段では、 実行結果はどうであったか、
そして本当はどうなってほしかったのかを書きます。
</p>
<figure link="/images/docs/bugzie-results.png" caption="結果"/>
<p>
ここに追加の情報が置けます。
追加情報とはスタックトレースや、 straceログの <b>一部</b>
(ログ丸ごとだと大き過ぎて使い難いことたびたびなので)のような情報のことですが、
やはり <c>emerge --info</c> の出力が最重要でしょう。 こんなふうに。
</p>
<figure link="/images/docs/bugzie-addl-info.png" caption="追加情報"/>
<p>
最後はバグの深刻度を選びます。 ここに関しては慎重に慎重を重ねてください。
ほとんどはそのまま手をつけずにおけば大丈夫です。
(必要に応じて)誰かが代わりに上げ下げしてくれます。
しかし提出したバグの深刻度を自ら上げるつもりでしたら、 注意書きをよく読み、
間違いのないことを再度確認してください。
各度合いの区別はつぎのようになっています。
</p>
<ul>
<li>
Blocker (障害物) - 疑いなくemergeするのが望ましくないプログラムのことです。
もしくはシステムの重大な障害物となるプログラムです。 例えば <c>baselayout</c>
に問題があればシステムが起動できなくなるのでれっきとしたblocker候補といえます。
</li>
<li>
Critical (深刻) - データの損失を起こす、
または動作中に重大なメモリーリークを起こすプログラムのことです。
やはり、 <c>net-tools</c>
のような重要なプログラムがコンパイルできなければcriticalになりえます。
システム起動を妨害するほどではないものの日に日に一大事となってゆきます。
</li>
<li>
Major (重大) - プログラムがクラッシュ(異常終了)しますが、
システムに異常をきたすわけでも、 情報の損失を招くものでもない場合です。
</li>
<li>
Minor (中程度) -
プログラムがあたりかまわずクラッシュしますが一定の回避策がわかっている場合です。
</li>
<li>
Normal (通常) - 初期設定値です。 わからなければそのままにすればよいでしょう。
ただし新しいビルドの場合や見た目の変更に留まるときはさらにこの下の選択肢の情報もご覧ください。
</li>
<li>Trivial (些事) - 言葉の綴り間違いとか空白文字の整理のようなことです。</li>
<li>
Enhancement (改善・向上) - プログラムに新機能をつけてもらう提案のほか、
<e>ebuildの新規・追加</e> は決まってここにします。
</li>
</ul>
<figure link="/images/docs/bugzie-sev.png" caption="深刻度"/>
<p>
今回の例ではNormalを選びます。
</p>
<p>
もうバグ報告を出せますので"Submit Bug Report"「バグ報告を提出」ボタンをクリックします。 すると新しいバグが上がってきます。
その結果どうなったかは <uri
link="https://bugs.gentoo.org/show_bug.cgi?id=97265">Bug 97561</uri> を見ましょう。
バグの報告ができました!
ではこれがどう扱われるか見てゆきます。
</p>
</body>
</section>
<section>
<title>ゼロデイバンプリクエスト</title>
<body>
<p>
ここまでずっとバグを申告する時点でしなければならないことを見てきました。
ではやっては <e>いけない</e> ことは何かお話ししましょう。
</p>
<p>
あなたが熱心に供給源(アップストリーム)プロジェクトの日程を追っているとしましょう。
ある日ホームページをチェックしていたら、 何と!
つい数分前に新バージョンが公表されているとわかりました。
たいていのユーザはすぐにGentooのBugzillaに行って新バージョンが出たと通報しそうです。
現バージョンは更新してPortageに加えてください。とかなんとか。
しかしこれは明らかに <b>やってはいけない</b> ことです。
新バージョンが出たその日に出されることから、
こういう要求は0-day bump request(ゼロデイバンプリクエスト)と呼ばれます。
</p>
<impo>
<b>私達のBugzillaに新バージョンを報告するのは <e>最短でも</e>
48時間待ってからにしてください。</b> 加えて、 要求を提出する前に <e>必ず</e>
Bugzillaをチェックして、 誰か他の人がもう報告を出していないか、
あるいはGentooの保守担当者が新バージョンにもう取り掛かっていないか、
確かめなければいけません。
</impo>
<p>
どうして待つ必要があるのでしょう? 第1に、
Gentoo開発者に向かって今している作業を全部中断してたった
15分前に出たばかりの新公開版の追加をしろというのは傲慢きわまりないことです。
ゼロデイバンプリクエストを出しても、
開発者たちが(修正や更新など)課題に追われてあくせく働いているときだったらINVALID(不正)もしくはLATER(後日)とマークされるかもしれません。
第2に、 開発者はきわめて密接に供給元を追跡しているはずですし、
普段からユーザに先んじて新公開までの経過によく注意を払っているからです。
新しい版が準備されていたことはもう既に知っています。
多くの場合バグはもう開示してあるだろうし、
マスクつきながら既にPortageへ加えられているかもしれません。
</p>
<p>
パッケージの新しい版を試すときや要求するときは賢く行ないましょう。
バンプリクエストを投げ込む前にBugzillaを検索しましょう。
バグは既に登録してあるかもしれません。
最近でもPortageツリーはsyncしなおしてありますか。
Portageにもう入っているかもしれません。
そもそも本当に供給源で公表されているのかな。
何はともあれ一般常識に則った行動がいちばんです。 それが、
多忙を極める開発者が少しでも親近感を覚えることにつながるでしょう。
公表日から何日か経っていてなおかつ誰もまだ要求を挙げていないのが確実に判っている(しかもPortageに入っていない)のでしたら、
新たなバグとして申請してよいでしょう。
その際お使いの機種でコンパイルできて動作したことも必ず書き添えましょう。
ほかにも役立ちそうな情報が提供できればもう文句のつけようがありません。
</p>
<p>
お気にいりのパッケージの最新版がPortageに欲しいとき、
バグ申告は賢く行ないましょう。
</p>
</body>
</section>
</chapter>
<chapter>
<title>報告してからのバグの処理</title>
<section>
<body>
<p>
バグ報告を読むと、 先ほど打ちこんだ情報が入っているのが見えます。
このバグはbug-wranglers@gentoo.orgに割り当て(アサイン)されているということもわかります。
アプリケーション分野のバグは既定どおりならここへ行きます。
</p>
<figure link="/images/docs/bugzie-new-basic.png" caption="新規バグの基本情報"/>
<p>
バグについて記した詳細も読めます。
</p>
<figure link="/images/docs/bugzie-new-details.png" caption="新規バグの詳細"/>
<p>
しかしbug-wranglersはバグ処理を(普段)何もしないことになっているので、
対処できる人物に再割り当てすることになります(bug-wranglersに割り当て手続を任せても構いません)。
このときパッケージのmetadata.xmlを利用します。 このファイルは通常
<path>/usr/portage/カテゴリー名/パッケージ名/metadata.xml</path> にあります。
foobar2用にやってみればこうなります。
</p>
<note>
当該バグの報告者かGentoo Bugzillaのグループ(Gentoo Developersなど)の一員でなければバグの再割り当ては行なえません。
</note>
<pre caption="metadata.xml">
&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>
<p>
maintainer(保守担当者)の節に注目します。 ここはパッケージ管理者の名簿であり、
この例では私ことChris Whiteの名があります。
掲載されている電子メールはchriswhite@gentoo.orgです。
特定の人物にバグを再割り当てするときはこれを使います。
その使い方は、
隣のReassign bug to(バグ再割り当て先)と書かれた記入欄をクリックして電子メールアドレスを記入、 です。
</p>
<note>
metadata.xmlが付属しないパッケージの場合はmaintainer-needed@gentoo.orgに、
誰かGentoo開発者が保守担当者として必要な場合はmaintainer-wanted@gentoo.orgにバグを割り当てなければなりません。
</note>
<figure link="/images/docs/bugzie-reassign.png" caption="バグの再割り当て"/>
<p>
そうしたら変更を反映させるためにCommitボタンを押します。
バグは私に割り当てられました。
しばらくするとバグ報告に私が返事した旨のお知らせ(通常は電子メール)が届きます。
プログラムがどんなふうに設定ファイルアクセスするのか見てみたいのでstraceログを見せてほしい、
と私は言っています。
そこであなたは前述のstraceの使い方に則ってstraceログを得ます。
これをバグに添付する必要がでてきました。
その方法は、 "Create A New Attachment"(添付ファイルを作成)をクリック、 です。
</p>
<figure link="/images/docs/bugzie-new-attach.png" caption="新たにファイルを添付"/>
<p>
ログを添付しなくてはなりません。 一歩づつ進みましょう。
</p>
<ul>
<li>
File (ファイル) - ファイルが置かれているお使いのコンピュータ上の場所です。
今回の例では <path>strace.log</path> があるところです。
"Browse..."ボタンからファイルを選び出すか、
記入欄にパスを直接記入してください。。
</li>
<li>
Description (要旨) - 一行で手短に、 あるいは添付ファイルのことを数語で表します。
strace.logとだけ書いたのはこれで充分自明だからです。
</li>
<li>
Content Type (データの型式) - バグ報告に添付しようとするファイルの型式です。
</li>
<li>
Obsoletes (改廃) - 今回の分より前にこのバグ報告に添付ファイルを提出していたとき、
前の添付ファイルが用済みになったならこのオプションで印をつけられます。
今回の例では前回提出分が無いので気にすることはありません。
</li>
<li>
Comment (コメント) - 添付ファイルを説明するコメントはここに記入します。
必要であれば添付ファイルについて、 詳細に書き込めます。
</li>
</ul>
<p>
Content Type(データの型式)に関してはもっと詳しくみてゆきます。
パッチを送るときには"patch"チェックボックスに印をつけると良いでしょう。
それ以外のものを送るならBugzillaの"auto-detect"(自動判定)でファイル型式を判断させる方法もあります(しかしお勧めはしません)。
オプションは一方で"select from list"(一覧から選択)もできるようになっていて、
ここはいちばんよく利用されます。 <e>大多数の</e>
添付ファイルは平文テキスト(text/plain)ですが、 バイナリファイルは例外で、
画像ならimage/gif、 image/jpeg、 image/pngなどから選び、
.tar.bz2のような圧縮ファイルならapplication/octet-streamがファイル型式です。
</p>
<figure link="/images/docs/bugzie-new-attach-comp.png" caption="添付できた新しいファイル"/>
<p>
<path>strace.log</path> を提出したらバグ報告に反映されました。
</p>
<figure link="/images/docs/bugzie-strace.png" caption="添付されたstraceのログ"/>
<p>
上に記したように、 ebuildがemergeエラーのメッセージ内でファイル添付をするように言ってくることがあります。
実例はこのようになります。
</p>
<pre caption="ファイル追加要請の例">
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>
<p>
このように言及されたファイルはバグ報告に添付してください。
</p>
<p>
ときには開発者がdiffもしくはpatchファイルを添付するよう求めるかもしれません。
標準的なdiffファイルはつぎのようにして取得します。
</p>
<pre caption="標準的なdiffの作成">
$ <i>cp file file.old</i>
$ <i>nano file</i>
$ <i>diff -u file.old file</i>
</pre>
<p>
C/C++のソースファイルにおいてはdiffがあるところの関数名も表示できるよう
<b>-p</b> オプションもつけます。
</p>
<pre caption="C/C++ソースのdiff取得">
$ <i>cp file.c file.c.old</i>
$ <i>nano file.c</i>
$ <i>diff -up file.c.old file.c</i>
</pre>
<p>
文書化チームは <b>-u</b> フラグに <b>-Nt</b> も組み合わせるよう要求するはずです。
このフラグは主にタブ展開に関係しています。
このようなdiffはつぎのようにして作成できます。
</p>
<pre caption="文書用diff">
$<i> cp file.xml file.xml.old</i>
$<i> nano file.xml</i>
$<i> diff -Nut file.xml.old file.xml</i>
</pre>
<p>
これでdiffファイルができました。 ここまでの作業をしている間に、
誰か他の人がこのバグ報告をBugzillaで探し出しバグの顛末に興味を抱いたとしたら、
その人はつぎに示したメールのCC欄に自分の電子メールアドレスを加えるかもしれません。
同じ方法で他の人のバグを追い掛けられます。
</p>
<figure link="/images/docs/bugzie-add-email.png" caption="電子メールをCC欄に追加"/>
<note>
電子メールアドレスはGentoo Bugzillaにあらかじめ登録しておかなくてはいけません。
いくつもアドレスをCC欄に入れるときはコンマもしくは空白で区切って並べます。
</note>
<p>
こうした作業がひととおり済むと、 バグはさまざまに状態マークづけを受けます。
普段はGentoo開発者がこの作業を行ないますが報告者自らが行なうこともたまにあります。
バグの一生の間にうける可能性のある状態指標はつぎのようにいろいろあります。
</p>
<ul>
<li>
UNCONFIRMED (未認証) - 一般的にあまり何度も見るようなものではありません。
これはバグ報告者が高度な方法でバグを報告してから、
そのバグがまだ本物のバグかどうか不明だという意味です。
</li>
<li>NEW (新規) - 開示されており新規とみなされているバグです。</li>
<li>
ASSIGNED (割り当て済み) - 割り当てを受けた人物もこれはバグだと確認したときに、
たいていはASSIGNEDの印をつけ、 問題を探るあいだはこのままとなります。
これがあればバグは本物のバグだとして受付けられたといえます。
</li>
<li>
REOPENED (再開示) -
誰かがバグ解決したのですがその手法が不可能だと思えたり問題がまだ残ってしまうと仮定しましょう。
この場合にバグを再び開いてもよろしい。
どうか <b>このしくみを乱用しない</b> でください。
開発者がバグを閉じてしまうのが2度目3度目を数えたら、
もうこのバグは閉じられるのが運命だといえます。
</li>
<li>
RESOLVED (解決済み) - 一件落着の運びとなったバグです。
なかでもバグが解決した時点で別の解法がある可能性がありながら、
それを残しつつ課題は終わったとみなされたならFIXED(修繕済み)と表示されます。
この分類についてはあとでさらに踏み込んで説明します。
</li>
<li>
VERIFIED (立証済み) - バグの対処と処置の手順は正しいということです。
たいていはQAの案件です。
</li>
<li>
CLOSED (閉じている) - 基本的な意味は、 バグよ安らかに眠りたまえ、
新たなバグの絶ゆまぬ流れの下に埋められたのだ、 ということです。
</li>
</ul>
<p>
さてしばらく経った日に、
このエラーの原因がstraceログから特定され処置を受けたのち、
RESOLVED FIXED(解決済み・閉じている)の刻印をマークされるとともに、
ebuildの警告文に「設定ファイルの位置が変更された」との事実を表示する更新を行うつもりだと言ったとします。
バグは解決に辿りついたのでこんな表示に変わります。
</p>
<figure link="/images/docs/bugzie-reso.png" caption="解決済みのバグ"/>
<p>
そのちょっと下にこんな表示も現れます。
</p>
<figure link="/images/docs/bugzie-options.png" caption="バグのオプション"/>
<p>
これはバグの再開示をするオプションで、
まだ開示してほしいとき(つまり開発者は解決済みと判断しましたが、
あなたの基準では解決していると考えられないとき)に使います。
以上でバグは治まりました。 しかし解決の帰着はほかにもあります。
ちょっと他の分もみておきましょう。
</p>
<ul>
<li>
FIXED (修繕済み) - 退治されたバグです。
書かれた解法の手順に従って問題に対処しましょう。
</li>
<li>
INVALID (不正) - 文書で明示されている手続を怠ったため発生したバグです。
</li>
<li>
DUPLICATE (重複) - このガイド文書のとおりにしなかったためバグ報告の重複が起きました。
</li>
<li>
WORKSFORME (要再現) - バグの解決を引き受けた開発者/人物はエラーを再現できませんでした。
</li>
<li>
CANTFIX (不可処置) - どういうわけか何らかの事情があって解決できないバグです。
バグを引き受けた人物が事情を説明する一文を添えることになります。
</li>
<li>
WONTFIX (変える気なし) -
たいていが新規ebuildや機能強化の要望に対して出されます。
基本的に開発者はある種の機能は追加不要と考えていたり、
それよりもっと良い代替案があるとか、
壊れた機能であるという理由があるときこうなります。
ときには解法を提示されたり、 問題が解決したと連絡が来たりするかもしれません。
</li>
<li>
UPSTREAM (供給元) -
このバグはGentoo開発チームによる処置ができないものであり、
あなた自身の手で問題を供給元(つまりプログラムを実際に作成した人々)に質してほしいという要望です。
供給元にはバグを取り扱う手段が多少なりともあります。
メーリングリスト、 IRCチャンネル、 さらにはバグ報告システムです。
通報方法がわからないときは、
バグ報告のなかで尋ねれば誰かが正しい方向を指し示してくれるはずです。
</li>
</ul>
<p>
ときどきバグの解決ができる前に、
開発者の方から更新済みのebuildを試してほしいと要望されるかもしれません。
つぎの章でebuildのテスト方法について見てゆきましょう。
</p>
</body>
</section>
</chapter>
<chapter>
<title>ebuildのテスト</title>
<section>
<title>ファイルを取得</title>
<body>
<p>
あなたがかつてfoobar2のコンパイルに修正を加えるバグ報告を送っていたとしましょう。
そこで開発者は問題点を洗い出して、
ebuild修正版を送ってあなたのマシンでも正しく動作するかどうかテストするよう求めたかもしれません。
</p>
<figure link="/images/docs/bugzie-ebuild-request.png" caption="ebuildテストの要請"/>
<p>
ちょっと紛らわしい語句がでますのでここでおことわりいたします。
まず、 オーバーレイとは何かについてお話しします。
オーバーレイは <path>/usr/portage</path> のような特別なディレクトリです。
その違いは中身のファイルが <c>emerge sync</c> を実行しても削除されないことです。
幸いにも特別に <path>/usr/local/portage</path> ディレクトリがこの目的で作成されます。
さっそくPortageオーバーレイを <path>/etc/make.conf</path> で設定しましょう。
お好みのエディタでmake.confを開いたらつぎの内容を末尾に付け足します。
</p>
<pre caption="PORTDIR_OVERLAYを設定">
PORTDIR_OVERLAY="/usr/local/portage"
</pre>
<p>
さあこれでテスト用ebuildのファイルが展開できる適切なディレクトリが作成できるようになりました。
今回の例ではsys-apps/foobar2にそれらを置くことにします。
2番目のコメントがパッチを <path>files</path>
ディレクトリに置くよう求めていることにお気づきいただけましたか。
このディレクトリは標準的なソース書庫に含まれていない他の必要なファイル(パッチやinit.dスクリプトなどなど)を入れる場所です。
パッケージディレクトリ下の <path>files</path> という名前のサブディレクトリです。
では先に進んでそのディレクトリを作成しましょう。
</p>
<pre caption="分類名とパッケージのディレクトリを設定">
# <i>mkdir -p /usr/local/portage/sys-apps/foobar2/files</i>
</pre>
<note>
mkdirコマンドに-pというオプションがあると、 当該ディレクトリそのものに限らず、
親ディレクトリに遡って存在しないディレクトリ(この場合はsys-appsとfoobar2)を作成します。
</note>
<p>
よろしい。 さあつぎはファイルをダウンロードしましょう。 まずebuildを
<path>/usr/local/portage/sys-apps/foobar2</path> にダウンロードして、 パッチを
<path>/usr/local/portage/sys-apps/foobar2/files</path> に置きます。
さてファイルが揃ったので、 ebuildのテストを開始します。
</p>
</body>
</section>
<section>
<title>ebuildをテスト</title>
<body>
<p>
emergeで利用できるebuildの作成過程はとても簡単です。
ebuildにはmanifestファイルを作成しなくてはいけません。
これはebuildコマンドで行なえます。 つぎのように実行しましょう。
</p>
<pre caption="Manifestファイルを作成">
# <i>ebuild foobar2-1.0.ebuild manifest</i>
&gt;&gt;&gt; Creating Manifest for /usr/local/portage/sys-apps/foobar2
</pre>
<p>
いよいよ予定どおりに動くかどうかテストするときになりました。
</p>
<pre caption="emerge -pvでテスト">
# <i>emerge -pv foobar2</i>
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>
<p>
動いたみたいです。 [ebuild ]の行の直後[1]に注目していただけますか。
ここは先に作成したオーバーレイである <path>/usr/local/portage</path>
を指し示しています。 つづいてパッケージをemergeします。
</p>
<pre caption="emergeの結果">
# <i>emerge foobar2</i>
Calculating dependencies ...done!
<comment>(コンパイル情報は中略)</comment>
>>> Unpacking foobar2-1.0.tar.bz2 to /var/tmp/portage/foobar2-1.0/work
* Applying foobar2-1.0-Makefile.patch ... [ ok ]
<comment>(コンパイル情報は中略)</comment>
>>> Merging sys-apps/foobar2-1.0 to /
>>> chris +sandbox(preinst)
--- /usr/
--- /usr/bin/
>>> /usr/bin/foobar2
</pre>
<p>
第1の節でemergeは予定どおり動き出したとわかりました。
第2の節で右側の状態メッセージに"[ ok ]"と出てパッチがうまく当ったことがわかりました。
最後の節でプログラムのコンパイルがokだと伝えてきました。 パッチは使えますよ!
さてこのあとは開発者にパッチがちゃんと使えたこととPortageに修正をコミットできることを伝えましょう。
</p>
</body>
</section>
<section>
<title>おわりに</title>
<body>
<p>
これでBugzillaの使い方の手引きを終えます。 お役に立つようなら本望です。
ご質問やコメント、 この文書に関するご意見があれば私
<mail>chriswhite@gentoo.org</mail> にお送りください。
-gフラグとコンパイルエラーのノートを提供してくれたmoreon氏、
bug-wranglingについて助言をくれた#gentoo-bugsのみなさん、
maintainter-neededについて助言をくれたGriffon26氏、
一般的助言をくれたrobbat2氏、
文書の修正や必要に応じた追加をしてくれたfox2mke氏、
以上の各位に特別な感謝を申し上げます。
</p>
</body>
</section>
</chapter>
</guide>
<?xml version='1.0' encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/proj/en/portage/doc/common-problems.xml">
<title>Portageの非特異な問題</title>
<author>
<mail link="genone@gentoo.org">Marius Mauch</mail>
</author>
<abstract>
この文書の目標はPortageのバージョンとツリーの間で一貫性に欠ける部分が原因で発生するよくありがちな問題に関する情報をすべて集めることです。
</abstract>
<license/>
<version>0.1</version>
<date>19 Feb 2006</date>
<!-- Original revision: 1.8 -->
<chapter>
<title>概要</title>
<section>
<title>取り扱い範囲</title>
<body>
この文書が扱う問題は、
過去これまでにかなりの数のユーザーが経験した(あるいはかなりの人数に影響を及ぼす懸念のある)、
通常操作を妨げる大きなものだけを扱います。
何か問題があったとき、 当文書に記載がないことだったらまず
<uri link="http://bugs.gentoo.org">bugzilla</uri>
に提出されていないか調べていただき(CLOSEされたバグやRESOLVEDなバグもお調べください)、
ここに報告が出ていないものでしたら、
たとえどこか他のところで解決法や回避策が記されていたとしてもバグ報告してください。
<p>
</p>
</body>
</section>
<section>
<title>Portageの更新</title>
<body>
<p>
Portage関連の問題はひとまずPortageを更新させてみたら解決する場合がよくあります。
これを定期的(3〜4ヶ月ごと)に行なうのが望ましく、
これまで同様Portageツリーは新しいPortageリリースのときに機能を導入して利用しはじめそれが古いバージョンをしばしば壊すことになるでしょう。
原則としてツリーと過去6ヶ月以内にリリースされたバージョンのPortageの間に互換性を確保いたしますので、
もしも仮にその期間内にリリースされたバージョンをお使いでない場合、
ツリーが全く使えない可能性があります。
</p>
<p>
Portageを更新する方法は、 何もオプションをつけずにただ <c>emerge portage</c>
とするのが望ましく、 とくに単独のパッケージの更新に何らかの不具合を起こす
<c>--update</c> オプションをつけないことが推奨されています。
</p>
</body>
</section>
</chapter>
<chapter>
<title>非特異な問題</title>
<!-- add new problems in reverse chronological order, so the newest problems are
listed first -->
<!-- 新しい問題を追加するときは時系列の逆順に、 つまり最新のものが最初に来るように並べます -->
<section>
<body>
<p>
<b><e>Portageキャッシュの更新中に「!!! Cannot resolve a virtual package name to an ebuild.」が出る</e></b>
</p>
<ul><li>バグ報告: <uri link="http://bugs.gentoo.org/show_bug.cgi?id=114798">114798</uri></li>
<li>原因: Portageのバージョンが古い</li>
<li>解決方法: Portageを更新し再度 <c>emerge --sync</c> を実行</li>
</ul>
<p>
<b><e>どんなパッケージをいくら入れようとしても「!!! No package digest file found:」というエラーが出る</b></b>
</p>
<ul><li>原因: portage-2.0.x系はManifest2をサポートしていない</li>
<li>解決方法: <uri link="manually-fixing-portage.xml">
手作業でportage-2.1以降に更新</uri></li>
</ul>
<p>
<b><e>Portageキャッシュを更新しているときに <br/>
&nbsp;&nbsp;&nbsp;&nbsp;portage.db["/"]["porttree"].dbapi.auxdb[porttree_root][cat].clear()<br/>
&nbsp;&nbsp;&nbsp;&nbsp;KeyError: 'app-dicts'<br/>
と出る</e></b>
<b><e></b></b>
</p>
<ul><li>バグ報告: <uri link="http://bugs.gentoo.org/show_bug.cgi?id=100444">100444</uri></li>
<li>原因: Portageのバージョンが古い</li>
<li>解決方法: Portageを更新し再度 <c>emerge --sync</c> を実行</li>
</ul>
<p>
<b><e>emergeで何を行なっても「!!! 'str' object has no attribute 'insert'」が出る</e></b>
<b><e></b></b>
</p>
<ul><li>バグ報告: <uri link="http://bugs.gentoo.org/show_bug.cgi?id=63400">63400</uri></li>
<li>原因: ancient portage version in combination with cascaded profiles</li>
<li>解決方法: a) <uri link="manually-fixing-portage.xml">手作業でportageを更新</uri> か
b) use a flat profile according to
<uri link="http://bugs.gentoo.org/show_bug.cgi?id=63400#c49">bug 63400</uri>,
update portage and update to a current (cascaded) profile
のいずれか
</li>
</ul>
<p><b><e>
<c>emerge --sync</c> を行なったあと、
emergeが「Calculating dependencies」するのに途方もない時間をかける。
同様に、 cvs更新を行なったあと、
「RepoMan scours the neighborhood」で途方もない時間を費す。
</e></b></p>
<p><b><e></b></b></p>
<ul><li>バグ報告: <uri link="http://bugs.gentoo.org/show_bug.cgi?id=124041">124041</uri></li>
<li>原因: /var/cache/edb/depのメタデータキャッシュが不正である</li>
<li>解決方法: <c>emerge --regen</c> を実行</li>
</ul>
</body>
</section>
</chapter>
</guide>
<?xml version='1.0' encoding="UTF-8"?>
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/eselect/dev-guide.xml,v 1.18 2012/03/09 15:2:02 ulm Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/proj/ja/eselect/dev-guide.xml" lang="ja">
<title>eselect開発者リファレンス</title>
<author title="Author">
<mail link="ciaranm@gentoo.org">Ciaran McCreesh</mail>
</author>
<author title="Author">
<mail link="kugelfang@gentoo.org">Danny van Dyk</mail>
</author>
<author title="Author">
<mail link="ulm@gentoo.org">Ulrich Müller</mail>
</author>
<author title="Editor">
<mail link="fox2mike@gentoo.org">Shyam Mani</mail>
</author>
<author title="翻訳">
<mail link="liangtai.s4@gmail.com">島本良太</mail>
</author>
<abstract>
この文書はeselectツールを開発しようとする方向けのリファレンスです。
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
<version>1.3.1</version>
<date>2012-03-09</date>
<!-- Originar revision: 1.18 -->
<chapter>
<title>はじめに</title>
<section>
<title>eselectについて</title>
<body>
<p>
eselectの役目は <c>foo-config</c> とか <c>blah-update</c>
のようなさまざまなツールを簡単に扱えるようにし、
導入口のはたらきをするフレームワークです。
</p>
<note>
この文書は読者が基本的なeselectの扱いに習熟していることを想定しています。
eselectの基礎的な知識は <uri link="user-guide.xml">eselect User Guide</uri>
(日本語訳 <uri link="proj/ja/eselect/user-guide.xml">eselectユーザーガイド</uri>) でご覧ください。
</note>
</body>
</section>
</chapter>
<chapter>
<title>最初から</title>
<section>
<title>はじめに</title>
<body>
<p>
一般的に、 アプリケーションソフトウェアがeselectフレームワークで使えるよう移植するときにはモジュールを作成してやる必要があります。
既にある(他のアプリケーションの)モジュールを基に作れてしまう場合がことのほか多いので、
いちばんやって欲しいところがだいたい揃っているものがあるかどうかを調べましょう
(シンボリックリンクの取り扱いなどはその良い例であり、
これは再発明しなくても他からコピーすれば済みます)。
</p>
</body>
</section>
<section>
<title>単純なモジュール</title>
<body>
<p>
これは例で見ていただくのが最も簡単です。
<c>kernel.eselect</c> モジュールの簡約版を例に説明します。
<c>show</c> と <c>list</c> と <c>set</c> の3つのアクションを具えていて、
さらに <c>help</c>、 <c>usage</c>、 <c>version</c> の標準アクションがあり、
<path>$(datadir)/eselect/modules/</path> にインストールされているものとします。
</p>
<pre caption="kernel.eselectのコード">
# -*-eselect-*- vim: ft=eselect
# Copyright 2005-2012 Gentoo Foundation
# Distributed under the terms of the GNU GPL version 2 or later
DESCRIPTION="Manage the /usr/src/linux symlink"
MAINTAINER="eselect@gentoo.org"
VERSION="20120307"
# find a list of kernel symlink targets
find_targets() {
local f
for f in "${EROOT}"/usr/src/linux-[[:digit:]]*; do
[[ -d ${f} ]] &amp;&amp; basename "${f}"
done
}
# remove the kernel sysmlink
remove_symlink() {
rm "${EROOT}/usr/src/linux"
}
# set the kernel symlink
set_symlink() {
local target=$1
if is_number "${target}"; then
local targets=( $(find_targets) )
target=${targets[target-1]}
fi
[[ -z ${target} || ! -d ${EROOT}/usr/src/${target} ]] \
&amp;&amp; die -q "Target \"$1\" doesn't appear to be valid!"
ln -s "${target}" "${EROOT}/usr/src/linux"
}
### show action ###
describe_show() {
echo "Show the current kernel symlink"
}
do_show() {
write_list_start "Current kernel symlink:"
if [[ -L ${EROOT}/usr/src/linux ]]; then
local kernel=$(canonicalise "${EROOT}/usr/src/linux")
write_kv_list_entry "${kernel%/}" ""
else
write_kv_list_entry "(unset)" ""
fi
}
### list action ###
describe_list() {
echo "List available kernel symlink targets"
}
do_list() {
local i targets=( $(find_targets) )
write_list_start "Available kernel symlink targets:"
for (( i = 0; i &lt; ${#targets[@]}; i++ )); do
# highlight the target where the symlink is pointing to
[[ ${targets[i]} = \
$(basename "${canonicalise "${EROOT}/usr/src/linux")") ]] \
&amp;&amp; targets[i]=$(highlight_marker "${targets[i]}")
done
write_numbered_list -m "(none found)" "${targets[@]}"
}
### set action ###
describe_set() {
echo "Set a new kernel symlink target"
}
describe_set_parameters() {
echo "&lt;target&gt;"
}
describe_set_options() {
echo "target : Target name or number (from 'list' action)"
}
do_set() {
[[ -z $1 ]] &amp;&amp; die -q "You didn't tell me what to set the symlink to"
[[ $# -gt 1 ]] &amp;&amp; die -q "Too many parameters"
if [[ -L ${EROOT}/usr/src/linux ]]; then
# existing symlink
remove_symlink || die -q "Couldn't remove existing symlink"
set_symlink "$1" || die -q "Couldn't set a new symlink"
elif [[ -e ${EROOT}/usr/src/linux ]]; then
# we have something strange
die -q "${EROOT}/usr/src/linux exists but is not a symlink"
else
set_symlink "$1" || die -q "Couldn't set a new symlink"
fi
}
</pre>
<p>
ご覧のように、 この書式はebuildのそれとかなり似通っています。
実体は特別な環境下で実行されるbashスクリプトなのです。
意図的にこうなっています。
そこにDESCRIPTIONとVERSIONというグローバル変数が存在していて、
<c>eselect</c> と、 いくつかのデフォルトアクションハンドラと、
一連の機能関数が利用しています。
</p>
<warn>
In ebuilds, global scope code can cause problems. In eselect modules,
global scope code is <e>absolutely forbidden</e>. Your module <e>will</e>
be sourced for tasks other than running your actions. For example, if
<c>eselect modules list</c> is executed, your module will be sourced to
obtain the description. Any code being run here would be a very bad thing.
ebuildでは、 グローバルな射程のコードが問題を引き起こす可能性があります。
eselectモジュール内でグローバルな射程のコードは <e>絶対に禁止</e>
されています。
ご自作のモジュールといえど意図したアクションだけでない他の命令もそこに源泉を求め根拠とする性質があります。
たとえば、 <c>eselect modules list</c> を実行すると、
説明文を読み取るために自作モジュールも根拠にとり入れられます。
XXXですからここで実行されることになるどんなコードがあっても非常に困った事態に陥ります。
</warn>
<p>
ebuildとは違い関数名は固定ではありません。
<c>do_</c> で始まる名前の関数はアクションの実装と解釈されます。
便宜的に、 <c>do_</c> 関数と対をなす <c>describe_</c>
関数が関数の説明文を提供するはたらきをします。 この説明関数は例えば
<c>eselect modulename help</c> が利用します。
任意で <c>describe_actions_options</c> 関数と <c>describe_action_parameters</c>
関数が追加できます。
</p>
<p>
どのeselectモジュールも変数ROOTのサポートが必須です。
プレフィクスのサポート用に変数EPREFIXとEROOTも定義されておりebuildでは両者の意味が同じです。
(この2つの変数はeselect-1.2より登場しました。)
</p>
<note>
<c>foo-config</c> あるいは (例えばシンボリック経由で) <c>foo-update</c> が
eselectを呼び出したとき、 自動的にfooのモジュールが実行されます。
</note>
<p>
どのモジュールもeselectのために提供するときはヘッダー部に著作権表示をしなくてはなりません。
上記の例のヘッダー部とそっくり同じ(もちろん年表示はその限りではない)にするべきです。
</p>
</body>
</section>
<section>
<title>アクションの標準的名称</title>
<body>
<p>
つぎの一覧表にはアクションにつけてよさそうな名前をまとめました。
どうしてもご自作の作業にふさわしい名前がこの中にない場合は、
当リストの更新を要望するのが最善の策です。 一貫性確保のために、
標準化されたアクション名の一覧表をお持ちになる方が良いでしょう。
</p>
<dl>
<dt>help</dt><dd>ヘルプのメッセージを表示します。 自動</dd>
<dt>usage</dt><dd>使用法のメッセージを表示します。 自動</dd>
<dt>version</dt><dd>現在のバージョンを表示します。 自動</dd>
<dt>show</dt>
<dd>
何らかのシンボリックリンクの現在の提供元、
もしくは現在インストールされているモジュール、 あるいは現在の状態を、
表示させるときに使います。
</dd>
<dt>list</dt>
<dd>
Used to display all available providers of a symlink, or all available
modules.
XXX何らかのシンボリックリンクのすべての利用可能な提供元、
あるいはすべての利用可能なモジュールを表示するときに使います。
</dd>
<dt>set</dt><dd>新たな提供元かシンボリックリンクを設定するときに使います。</dd>
<dt>enable</dt><dd>何らかのオプション機能を有効にするときに使います。</dd>
<dt>disable</dt><dd>何らかのオプション機能を無効にするときに使います。</dd>
<dt>scan</dt><dd>現在のファイルシステムから情報を読み取ります。</dd>
<dt>update</dt>
<dd>
何らかのシンボリックリンクの新たな提供元を自動的に選択するとき
(これとは対照的に <c>set</c>
はふつうパラメーターに提供元を手動で明示させます)、
もしくは今後のアクションにとって肝心なシステム情報を集めるときに使います。
</dd>
</dl>
<note>
<c>help</c>、 <c>usage</c>、 <c>version</c>
の各アクションは上書き設定が可能です。
既定では <path>lib/default.eselect</path> から提供されています。
上書きは正当な理由があるときだけにしましょう。
これを削除するのはよくありません。 <c>eselect</c>
はなおもそれが存在するとみなします。
</note>
</body>
</section>
</chapter>
<chapter>
<title>便利機能</title>
<section>
<title>はじめに</title>
<body>
<p>
eselectはたくさんの便利な関数を用意しています。
これらは標準に沿った書式の出力に役立ちます。
できれば、 とりわけ出力を行なう場においては、 これらを活用するべきです。
標準の関数の出力では必要な書式をまかなえない場合になってから、
実装を検討するようにしましょう。
</p>
<p>
はじめから利用可能な関数はつぎの分類のとおりです。
</p>
<ul>
<li><uri link="#core">一般ユーティリティ関数</uri></li>
<li><uri link="#output">出力ユーティリティ関数</uri></li>
<li><uri link="#tests">テスト関数</uri></li>
<li><uri link="#path-manipulation">パス操作関数</uri></li>
<li><uri link="#manip">操作関数</uri></li>
<li><uri link="#config">設定関数</uri></li>
<li><uri link="#multilib">マルチリブ関数</uri></li>
<li><uri link="#package-manager">パッケージ管理関数</uri></li>
</ul>
<p>
他の関数を利用するときは必ず相応のライブラリファイルを <c>inherit</c>
(継承)しなくてはいけません。
</p>
</body>
</section>
<section id="core">
<title>一般ユーティリティ関数</title>
<body>
<p>
これらは <path>libs/core.bash</path> で実装されています。
</p>
<dl>
<dt>die</dt>
<dd>
The <c>die</c> function (which, unlike its ebuild counterpart, <e>can</e>
be called from within subshells) is used to exit with a fatal error.
It should be invoked as <c>die -q "Message to display"</c>. If the
<c>-q</c> is not provided, a stacktrace will be displayed – this should
never happen because of user input error, only abnormal conditions.
<c>die</c> 関数は致命的なエラーを発して終了させるために使います。
XXX(この関数はebuildのもう片方とは違ってサブシェルから呼び出すこともできます。)
呼び出すときは <c>die -q "表示したいメッセージ"</c> のようにします。
<c>-q</c> がないときはスタックトレースが表示されることになっていますが、
XXXユーザー入力エラーの不正常な状況だけなので絶対にありえません。
</dd>
<dt>check_do</dt>
<dd>
The <c>check_do</c> utility function checks that the first parameter is
a function, and then calls it with any additional parameters as its
arguments. If the function does not exist, <c>die</c> is called. Again,
this is mostly internal.
<c>check_do</c> ユーティリティ関数は第1パラメータが関数かどうか検査し、
その関数を呼び出します。 つづくパラメータがあれば引数に渡します。
[第1パラメータに示した]関数が無いときは <c>die</c> が呼び出されます。
XXXこれもほぼ内部関数です。
</dd>
<dt>do_action</dt>
<dd>
<c>do_action</c> ユーティリティ関数は他のモジュールで定義されたユーティリティ関数の呼び出し方を正します。
第1パラメータに当アクションを、 つづくパラメータに引数を与えます。
</dd>
<dt>inherit</dt>
<dd>
<c>inherit</c> 関数はeselectライブラリから同名のファイルを根拠とします。
<path>libs/foo.bash</path> ファイルに根拠を求めるには、
ご自作のモジュール内でグローバルな射程上に <c>inherit foo</c> を追加します。
</dd>
<dt>sed</dt>
<dd>
<c>sed</c> 関数はGNU <c>sed</c> をくるむラッパです。
</dd>
</dl>
</body>
</section>
<section id="output">
<title>出力ユーティリティ関数</title>
<body>
<p>
これらは <path>libs/output.bash</path> で実装されています。
</p>
<dl>
<dt>write_error_msg</dt>
<dd>
<c>write_error_msg</c> 関数はエラーメッセージを標準書式で表示します。
<c>eerror</c> に似通っています。
</dd>
<dt>write_warning_msg</dt>
<dd>
<c>write_warning_msg</c> 関数は警告メッセージを標準書式で表示します。
<c>ewarn</c> に似通っています。
</dd>
<dt>write_list_*系の関数</dt>
<dd>
リストの表示には <c>write_list</c> 系の関数を使います。 関数の第1引数に
<c>-p</c> を与えるといずれの関数もハイライト表示が <e>plain</e>
(色分けしない)になります。
</dd>
<dt>write_list_start</dt>
<dd>
いつもヘッダ行(見出し)がついたリスト表示にします。
表示したい内容は <c>write_list_start ヘッダ行</c> で指示します。
</dd>
<dt>write_numbered_list_entry</dt>
<dd>
リストの項目に番号をつけたいときは、 個々の項目に
<c>write_numbered_list_entry</c> 関数を使います。
第1パラメータには項目に付ける番号を、
第2パラメータにリスト項目の本文を(「"」で両端を括って)与えます。
</dd>
<dt>write_kv_list_entry</dt>
<dd>
キーと値が対をなすリストを表示するときは <c>write_kv_list_entry</c>
を使うべきです。
第1パラメータにキーを、 第2パラメータに値を与えます。
</dd>
<dt>write_numbered_list</dt>
<dd>
を使い自動的に番号を振るラッパです。
受け取ったパラメータのひとつひとつを順番に番号付きリスト項目にします。
eselect-1.2.2以降には <c>-m</c> オプションが加わり、
空のリストを出力しようとしたときに否定的報告をするメッセージをこれで指定できます。
</dd>
<dt>highlight</dt>
<dd>
<c>highlight</c> ユーティリティ関数は、
上記の関数で表示する文を部分強調するために使います。
起用方法の代表的な例は、 下記の
<uri link="#doc_chap3_pre1">code listing</uri> になるようです。
</dd>
<dt>highlight_warning</dt>
<dd>
<c>highlight_warning</c> 関数は <c>highlight</c> 関数に似ていますが、
警告に用いるところが異なります。 疑問を示す文を赤く表示します。
</dd>
<dt>highlight_marker</dt>
<dd>
リスト項目のひとつに活性・選択中を示すマークをつけるには、
<c>highlight_marker</c> 関数を使います。
第1パラメータにリスト項目を与えます。
この関数の機能はハイライトつき星印(もしくは第2パラメータを使って指定したもの)を項目のあとにつけます。
起用方法の代表的な例は、 下記の
<uri link="#doc_chap3_pre2">code listing</uri> になるようです。
</dd>
<dt>is_output_mode</dt>
<dd>
<c>is_output_mode</c>
関数はパラメータがeselectの出力のモードと同じ場合にだけtrueを返します。
今のところデフォルトのほかに <c>brief</c> 出力モードだけが定義されていて、
<c>--brief</c> オプションに匹敵します。
(当関数はeselect-1.2.6より出現しました。)
</dd>
<dt>space</dt>
<dd>
<c>space</c> ユーティリティ関数は整数値をひとつパラメータにとります。
空白文字をその数だけ表示します。
</dd>
</dl>
<pre caption="highlightの例">
write_list_start "This is $(highlight list) example"
write_kv_list_entry "First" "This is the first entry"
write_kv_list_entry "$(highlight Second)" "This is the $(highlight second) entry"
write_kv_list_entry "Third" "$(highlight The end)"
</pre>
<pre caption="highlight_markerの例">
for (( i = 0; i &lt; ${#targets[@]}; i++ )); do
[[ test_if_target_is_active ]] \
&amp;&amp; targets[i]=$(highlight_marker "${targets[i]}")
done
</pre>
</body>
</section>
<section id="tests">
<title>テスト関数</title>
<body>
<p>
これらは <path>libs/tests.bash</path> で実装されています。
</p>
<dl>
<dt>has</dt>
<dd>
<c>has</c> ユーティリティ関数はPortageの <c>hasq</c> のようなものです。
第1パラメータが残りのパラメータのいずれとも等しい場合にだけtrueを返します。
</dd>
<dt>is_function</dt>
<dd>
<c>is_function</c>
ユーティリティ関数はパラメータが現存し関数である場合にだけtrueを返します。
ほとんどの場合これは内部で利用されますが、
モジュールで使われることもあります。
</dd>
<dt>is_number</dt>
<dd>
パラメータが正の整数である場合にだけtrueを返します。
</dd>
</dl>
</body>
</section>
<section id="path-manipulation">
<title>パス操作関数</title>
<body>
<p>
これらは <path>libs/path-manipulation.bash</path> で実装されています。
</p>
<dl>
<dt>basename</dt>
<dd>
<c>basename</c> 関数は外部の <c>basename</c> アプリケーションのような、
透過的なbash専用の代替品です。
</dd>
<dt>dirname</dt>
<dd>
<c>dirname</c> 関数は外部の <c>dirname</c> アプリケーションのような、
透過的なbash専用の代替品です。
</dd>
<dt>canonicalise</dt>
<dd>
<c>canonicalise</c> 関数はGNUの <c>readlink -f</c> とか <c>realpath</c>
のラッパです。
</dd>
<dt>relative_name</dt>
<dd>
<c>relative_name</c> 関数は(第1パラメータで与えられた)パス名を(第2パラメータで与えられた)現在のディレクトリからみた相対パス名に変換します。
絶対パス名から相対的なシンボリックリンクを生成するときに使えます。
(当関数はeselect-1.2.4より出現しました。)
</dd>
</dl>
</body>
</section>
<section id="manip">
<title>操作関数</title>
<body>
<p>
これらは <path>libs/manip.bash</path> で実装されています。
</p>
<dl>
<dt>svn_date_to_version</dt>
<dd>
お求めのモジュールがCVSもしくはsubversionリポジトリで保持されているときは、
VERSIONを手動で追い掛ける代わりに <c>svn_date_to_version</c>
関数を使います。
グローバルな射程で使用しても安全です。 正式な使用法は下記の
<uri link="#doc_chap3_pre3">code listing</uri> でご覧になれます。
</dd>
</dl>
<pre caption="svn_date_to_versionの使用法">
SVN_DATE='&#36;Date: &#36;'
VERSION=$(svn_date_to_version "${SVN_DATE}")
<comment>(SVNキーワード拡張をここでモジュールに適用)</comment>
svn propset svn:keywords "Date" modules/foo.eselect
</pre>
</body>
</section>
<section id="config">
<title>設定関数</title>
<body>
<p>
これらは <path>libs/config.bash</path> で実装されています。
</p>
<dl>
<dt>store_config</dt>
<dd>
<c>store_config</c>
関数は第1パラメータで与えられた設定ファイル内にキーと値の1対を保存します。
このファイルはキーと値の対だけからできているbashスクリプトであり、
手動で変更してはいけません。 ファイル内のコメントは <c>store_config</c>
が呼び出されるたびに削除されます。 この関数の呼び出し方は
<c>store_config ファイル名 キー 値</c> です。
</dd>
<dt>load_config</dt>
<dd>
<c>load_config</c>
関数はモジュールの設定ファイルに保存されている記録を読み出します。
<c>load_config ファイル名 キー</c> と呼び出すと対の値が表示されます。
</dd>
<dt>append_config</dt>
<dd>
<c>append_config</c>
関数は既にモジュール設定ファイルに保存されている記録に項目を追加します。
内部で <c>load_config</c> と <c>store_config</c> を使用しており、
呼び出し方は <c>append_config ファイル名 キー 値</c> です。
キーに相対する値が既にあれば項目の追加はできません。
</dd>
</dl>
</body>
</section>
<section id="multilib">
<title>マルチリブ関数</title>
<body>
<p>
これらは <path>libs/multilib.bash</path> で実装されています。
</p>
<dl>
<dt>list_libdirs</dt>
<dd>
<c>list_libdirs</c>
関数は使用しているアーキテクチャの有効なlibdirばかりを揃えて返します。
デフォルトでは有効なlibdirのすべてを <path>/etc/ld.so.conf</path>
より取得します。 ファイルが無い、 もしくは壊れていたために失敗すると、
この関数は <c>uname</c> を用いてアーキテクチャを断定します。
</dd>
</dl>
</body>
</section>
<section id="package-manager">
<title>パッケージ管理関数</title>
<body>
<p>
これらは <path>libs/package-manager.bash</path> で実装されています。
</p>
<dl>
<dt>arch</dt>
<dd>
<c>arch</c> 関数は現在のシステムの${ARCH}より正しい値を得て返します。
パッケージマネージャがこの情報を提供できないときは、 対照表に基づく
<c>uname -m</c> と <c>uname -s</c> に引き下がって値を得ます。
</dd>
<dt>envvar</dt>
<dd>
The <c>envvar</c> function retrieves the contents of a
configuration-environment variable for a given package. The syntax
is <c>envvar ${package-name} ${var-name}</c>.
XXX<c>envvar</c>
関数は与えられたパッケージから設定-環境変数の内容を取得します。
書式は <c>envvar ${パッケージ名} ${変数名}</c> です。
</dd>
<dt>best_version</dt>
<dd>
The <c>best_version</c> function returns the highest available version for
a given package dep atom.
XXX<c>best_version</c>
関数は与えられたパッケージのdepアトムに適用できる最上位のバージョンを返します。
</dd>
<dt>has_version</dt>
<dd>
The <c>has_version</c> function checks whether a given versioned package
dep atom is installed.
XXX<c>has_version</c>
関数は示されたバージョンのパッケージdepアトムがインストールされているかどうか調べます。
</dd>
<dt>get_repositories</dt>
<dd>
<c>get_repositories</c>
関数はパッケージマネージャが知っているレポジトリのリストを返します。
</dd>
<dt>get_repo_news_dir</dt>
<dd>
The <c>get_repo_news_dir</c> function returns the directory where to find
GLEP 42 news items for a given repository.
XXX<c>get_repo_news_dir</c>
関数は与えられたレポジトリ用にGLEP42ニュースアイテムを読み出すディレクトリを返します。
</dd>
</dl>
</body>
</section>
</chapter>
</guide>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/portage/doc/eapi.xml,v 1.23 2006/04/06 00:32:27 chriswhite Exp $ -->
<guide link="/proj/ja/portage/doc/eapi.xml" lang="ja" disclaimer="draft">
<title>ebuildアプリケーションンプログラミングインターフェース(EAPI)の概観</title>
<author title="Author">
<mail link="antarus@gentoo.org">Alec Warner</mail>
</author>
<author title="GuideXML">
<mail link="chriswhite@gentoo.org">Chris White</mail>
</author>
<abstract>
EAPIはPortageのバージョン2.0.53以降に導入されたメカニズムのひとつです。
このメカニズムによってPortageは処理が正しくできないとわかっているebuildを探しだしマスクをかけられるようになります。
この文書ではEAPIの一般的な背景とその内面の理論について述べています。
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
<version>1.0</version>
<date>2006-04-04</date>
<!-- Original revision: 1.23 -->
<chapter>
<title>はじめに</title>
<section>
<title>Rationale</title>
<title>理論的背景</title>
<body>
<p>
Older <c>Portage</c> versions would improperly process or die if the application
encountered an ebuild which used a newer feature not available in that version
of Portage. Often features would be added to Portage and not released for
general use in the tree for a while ( six months or more ). This caused feature
deprivation as a bunch of time was always required once a feature was released
to be relatively sure that all users had a recent version of portage. This can
be seen most recently with the <uri
link="https://bugs.gentoo.org/114798">new-style virtuals (Bug
&#035;114798)</uri> which broke portage.
かつての <c>Portage</c> はebuildに他のPortageでしか実行できない新しい機能が使われていると処理を正しく行なえなかったり止まってしまったりするアプリケーションでした。
Portageの装備はたびたび追加が行なわれるのですが、
ツリー上ではしばらくの間(6ヶ月以上)待たなければ一般利用に提供されませんでした。
何らかの装備がリリースされてからすべてのユーザーがPortageの最新バージョンを入手したと比較的はっきりするまでいつもある程度の時間を要するために、
XXXこれは顕著な.をもたらしました。
ごく最近ではPortageの破壊につながる事例(新型virtual) <uri
link="https://bugs.gentoo.org/114798">new-style virtuals (Bug
&#035;114798)</uri> にそれが現れています。
</p>
</body>
</section>
</chapter>
<chapter>
<title>実装</title>
<section>
<title>Portage</title>
<body>
<p>
EAPI is implemented in versions of Portage greater than or equal to 2.0.53. Each
version of Portage has a supported EAPI value. All current versions of Portage
have an EAPI of 0. This EAPI value is set in
<path>/usr/lib/portage/pym/portage_const.py</path>. Basically, if an ebuild
declares an EAPI that is greater than the EAPI of the Portage version that is
accessing the ebuild, the ebuild is masked by EAPI aware versions of Portage.
EAPIは2.0.53以降のバージョンのPortageに実装されています。
それぞれのPortageがサポートを受けられるEAPI値を持っています。
現在のバージョンのPortageはいずれも0の(:XXXに設定された)EAPIがひとつ具わっています。
こうしたEAPI値は <path>/usr/lib/portage/pym/portage_const.py</path>
で定義されています。 基本的に、
ebuildが宣言しているEAPIのほうがそのebuildを操作しようとするPortageのEAPIよりも高い値であるとき、
XXXebuildはPortageのEAPI検知バージョンでマスクされます。
</p>
</body>
</section>
<section>
<title>ebuild</title>
<body>
<p>
Ebuilds may declare what version of EAPI they use. For backwards compability,
if an ebuild does not declare an EAPI, it's EAPI is assumed to be the default (
currently set to 0 ). An ebuild would declare a higher EAPI if it used any new
functionality. Such a function would be something like default USE flags in
<c>IUSE</c>. Normally an ebuilds IUSE is one such as this:
ebuildはどのEAPIのバージョンを利用しているか宣言できます。 後方互換性のため、
ebuildがEAPIを宣言していないときはそのEAPIがデフォルトと見做されます(現在は0に設定されています)。
何か新しい機能を使うのであればebuildはEAPIの値を上げて定義するのです。
</p>
<pre caption="EAPI導入前のIUSE">
IUSE="foo bar baz"
</pre>
<p>
However with the new default USE in IUSE feature the IUSE line could be
something such as:
</p>
<pre caption="EAPI IUSE">
IUSE="foo +bar -baz"
</pre>
<p>
If an old version of portage attempts to parse the new-style IUSE line it could
very well get incorrect data and traceback. It also won't turn on or off the
specified use flags like the ebuild would expect.
</p>
</body>
</section>
<section>
<title>Cache</title>
<body>
<p>
If Portage attempts to generate a cache entry for an ebuild and the ebuild has
an EAPI value that is not supported by that version of Portage, the values in
the cache entry for that ebuild are set to empty and the corresponding EAPI
value is negated. This is done both to notify Portage that the ebuild is using
features that the currently running Portage cannot support, but also to inform
the rest of Portage that the cache entries are empty. Future enhancements
covered by EAPI may in fact invalidate how the cache entries are generated
and/or stored, thus once Portage determines that it doesn't support that EAPI
version, all bets on the data in the ebuild are off.
</p>
</body>
</section>
</chapter>
</guide>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/portage/doc/faq.xml,v 1.52 2011/08/28 20:17:50 zmedico Exp $ -->
<guide link="/proj/ja/portage/doc/faq.xml" lang="ja">
<title>Portageのよくある質問とその答え(FAQ)</title>
<author title="Author">
<mail link="antarus@gentoo.org">Alec Warner</mail>
</author>
<author title="Contributor">
<mail link="zmedico@gentoo.org">Zac Medico</mail>
</author>
<author title="GuideXML">
<mail link="chriswhite@gentoo.org">Chris White</mail>
</author>
<abstract>
Portageに関するよくある質問とその答え集(FAQ)。
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
<version>1.0</version>
<date>2011-05-17</date>
<!-- Original revision: 1.52 -->
<chapter>
<title>よくある質問とその答え</title>
<section>
<title>
パッケージ間の「ブロック」はどうやったら解けるの?
</title>
<body>
<p>
<uri
link="http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked">
Blocked Packages section in the Gentoo Handbook</uri> (日本語訳 <uri
link="http://www.gentoo.org/doc/ja/handbook/handbook-x86.xml?full=1#blocked">
Gentooハンドブックの「ブロックされたパッケージ」</uri>) をご覧ください。
</p>
</body>
</section>
<section>
<title>emergeがパッケージを全部は更新しないというのはなぜか?</title>
<body>
<p>
初期設定では依存グラフが何らかのパッケージをインクルードしないことがあります。
たとえば <c>emerge --pretend --depclean</c> の出力が列挙するパッケージはどれもインクルードされることがありません。
また、 インストールしてあるパッケージやバイナリパッケージにはビルド時依存のものをインクルードしません。
こうしたビルド時依存のものを必須でなくともインクルードしたいときは、
<c>--with-bdeps=y</c> を使いましょう。
デフォルトでこのオプションを有効にしたければ
<path>/etc/make.conf</path> に <c>EMERGE_DEFAULT_OPTS="--with-bdeps=y"</c>
を設定しましょう。
特定のパッケージをどんなときでも更新させたければ
<c>emerge --noreplace&lt;アトム&gt;</c> を実行してworldなsetに組み入れてもよいでしょう。
</p>
<p>
<c>emerge --deep --with-bdeps=y --update world</c> を実行したあとは、
削除を受けるパッケージがないか <c>emerge --pretend --depclean</c>
で調べるとよいでしょう。
このコマンドで現れたパッケージ名のなかにインストールしたままにしておきたいものがあれば
<c>emerge --noreplace &lt;アトム&gt;</c> でworldなsetに取り込んでおきましょう。
</p>
<warn>
不要なパッケージを削除するために <c>emerge --depclean</c> を使用したときは、
そのあとで(gentoolkitパッケージに入っている) <c>revdep-rebuild</c>
を実行しておくと良いでしょう。
</warn>
<note>
<c>man emerge</c> を実行すれば
<c>emerge</c> の全部のオプションの説明が書かれたマニュアルが読めます。
</note>
</body>
</section>
<section>
<title>
安全にアンインストールできるよう、
逆にこのパッケージに依存している他のパッケージが無いか調べる方法はありませんか。
</title>
<body>
<p>
<c>emerge --depclean --pretend --verbose [アトム]...</c>
を実行すれば該当パッケージに依存しているパッケージがあればすべて表示します。
</p>
<warn>
不要なパッケージを削除するために <c>emerge --depclean</c> を使用したときは、
そのあとで(gentoolkitパッケージに入っている) <c>revdep-rebuild</c>
を実行しておくと良いでしょう。
</warn>
</body>
</section>
<section>
<title>
emerge --depclean がたまにシステムパッケージを削除するのはなぜか。
</title>
<body>
<p>
システムが依存するパッケージにはvirtual/editorのようにvirtualとなっているものがあり、
依存に応じるために並行して複数のパッケージをインストールするのが普通に行なわれます。
このなかで余分なパッケージは <c>emerge --depclean</c> すれば削除されますが、
明示的にworldなsetに加えられているものば消されません。
<c>emerge --noreplace &lt;アトム&gt;</c> を行なえばそのパッケージはworldなsetに加えられ、
こんご <c>emerge --depclean</c> によって削除されない保証がつきます。
</p>
</body>
</section>
<section>
<title>
たまにemergeが依存従属側を捕捉しないのはなぜ?
</title>
<body>
<p>
依存する側を完全に捕捉するのは時間の浪費となり、
もしもそれがデフォルト動作であれば処理性能の低さに多くのユーザーが不満を訴えかねません。
そこで、 依存計算はしばしば依存する側を省略しますが、
<c>emerge --complete-graph</c> オプションを与えれば省略をしません。
<c>EMERGE_DEFAULT_OPTS="--complete-graph"</c> を <path>/etc/make.conf</path> に設定しておけば、
デフォルトでこのオプションが有効になります。
<c>emerge</c> のマニュアル(<c>man emerge</c> を実行)を見れば
<c>--complete-graph</c> についてのもっと詳しい説明が得られます。
</p>
</body>
</section>
<section>
<title>NFS経由でPortageのツリー(/usr/portage)をマウントしてもよいか?</title>
<body>
<p>
Porageのツリー(<path>/usr/portage</path>)をNFSで共有し、 ここだけで
<c>emerge --sync</c> による更新を行なう使い方が可能です。
これでNFSクライアントが <c>emerge --sync</c> をする必要はなくなりますが、
各クライアントで <c>emerge --metadata</c> を実行する必要は残ります。
これを怠るとメタデータキャッシュ(<path>/var/cache/edp/dep</path>)が古くなってしまいメタデータの依存計算が遅くなります。
</p>
<note>
バージョン2.1.5_rc6以降のPortageをお使いであれば、
make.confファイルでFEATURES="metadata-transfer"を指定していない限り
<c>emerge --metadata</c> を実行する必要が一切ありません。
metadata-transferが無効になっておれば直に <path>/usr/portage/metadata/cache/</path> にあるメタデータキャッシュが使用されるためです。
詳しくは <c>man make.conf</c> でmetadata-transferの説明が読めます。
</note>
<p>
NFSセットアップを行なっている最中に問題が発生するときは、
NFSクライアント機とNFSサーバー機の双方に正しくロックデーモンが作動しているか確かめることが重要です。 (訳注lockdのこと?)
XXX Portage uses hardlinks over NFS in an attempt to lock files;...
PortageはファイルをロックするときにNFSをまたいでハードリンクを活用します。
ロックデーモンがファイルのロックに失敗すると、
ロックが失敗したとか古くなったことをPortageが告げるかもしれません。
このスクリプト <path>/usr/lib/portage/bin/clean_locks</path>
を使用すれば古くなったロクファイルを除去できます。
</p>
</body>
</section>
<section>
<title>
emergeが"waiting for lock"というメッセージを出すのだがなぜか?
</title>
<body>
<p>
いちばんよくある理由は <c>FEATURES="parallel-fetch"</c>
が有効になっているためです。 この指定は
<path>/usr/share/portage/config/make.globals</path> ファイルにあり、
デフォルトで有効になっています。 無効にしたいときは
<path>/etc/make.conf</path> ファイルで <c>FEATURES="-parallel-fetch"</c>
と設定します。 <c>FEATURES</c> に関してはmake.confのマニュアル(<c>man make.conf</c> を実行)に詳しく書かれています。
</p>
<p>
<c>emerge</c> を複数同時に走らせているときや、
<c>DISTDIR</c> をネットワーク共有しているときは、
"waiting for lock"メッセージに似たものを出すかもしれません。
こうしたロックは同時に作動しているプロセスとの衝突を避けるために必要です。
</p>
</body>
</section>
<section>
<title>
@preserved-rebuildというsetはなぜ再構築が済んだパッケージを含んでいるのか?
</title>
<body>
<p>
これは <uri link="http://bugs.gentoo.org/show_bug.cgi?id=230257">
よくある問題</uri> のひとつであり、
現状のebuildのビルドシステムがパッケージのリンクを誤り新しいバージョンのライブラリでなく古い保存版(preserved)のものを繋いでしまっていることを示しています。
回避策になりますが、
(libreadline.so.5.2のような)古いライブラリを手作業で削除してから、
<c>revdep-rebuild</c> を実行してこのライブラリにリンクしていたパッケージを再構築する方法があります。
保存版のライブラリは `<c>portageq list_preserved_libs /</c>`
というコマンドで全部のリストが得られます。
</p>
</body>
</section>
<section>
<title>
パッケージの構築を--jobsオプションで同時進行させていたら、
ビルドが終わっているのにすぐにはインストールされないパッケージがあるけどなぜ?
かなりあとになってからでしかインストールされなかった。
</title>
<body>
<p>
保安上の用心のため、
システムパッケージやそれが依存するパッケージのインストール作業は他のパッケージの構築が進行していないときにのみ行なわれることになっています。
この挙動は
<uri link="http://bugs.gentoo.org/show_bug.cgi?id=256616">
bug 256616 (指定外のシステムの依存物)</uri> や
<uri link="http://bugs.gentoo.org/show_bug.cgi?id=259954">
bug 259954 (一時的に不十分なシステムの依存物)</uri>
といったバグを防ぐために必須です。
</p>
</body>
</section>
<section>
<title>
USE=multislotを有効にしたパッケージのSLOTをemerge --pretendが正しく表示しないのはなぜ?
</title>
<body>
<p>
USE=multislotをサポートしたebuildは「一貫性のあるメタデータ」という確立した秩序を乱すため、
キャッシュされたSLOT値と、
実際にパッケージをインストールしたときに得られるSLOT値とが異なってしまいます。
Portageにできる処置は
<uri link="http://bugs.gentoo.org/show_bug.cgi?id=174407">
bug #174407</uri> のような拡張的実装を除いては他に何もありません。
</p>
</body>
</section>
<section>
<title>
環境変数を特定のパッケージにのみ適用させるにはどうしたらよいか。
</title>
<body>
<p>
"sys-libs/glibc debug.conf"のような行を <path>/etc/portage/package.env</path>
に加え、 指定したい環境変数を <path>/etc/portage/env/debug.conf</path>
に書きます(書き方は <path>make.conf</path> と同じです)。
debug.confの内容はたとえばつぎのようになるでしょう。
</p>
<pre caption="debug.conf">
CFLAGS="${CFLAGS} -ggdb"
CXXFLAGS="${CXXFLAGS} -ggdb"
FEATURES="${FEATURES} installsources splitdebug"
</pre>
</body>
</section>
<section>
<title>
Portage-2.2*がマスクされているのはなぜ?
</title>
<body>
<p>
Portage 2.2がマスクされている理由は、 パッケージsetに
<uri link="http://bugs.gentoo.org/show_bug.cgi?id=144480">
bug #144480</uri> というバグがあり、 preserve-libs機能に
<uri link="http://bugs.gentoo.org/show_bug.cgi?id=240323">
bug #240323</uri> というバグがあるためです。 詳しくは
<uri link="http://bugs.gentoo.org/show_bug.cgi?id=253802">
bug #253802</uri> を読みましょう。
</p>
</body>
</section>
</chapter>
</guide>
<?xml version="1.0" encoding="UTF-8"?>
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/kde/at/index.xml,v 1.2 2010/06/07 22:41:18 tampakrap Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/proj/ja/desktop/kde/at/index.xml" lang="ja">
<title>KDE Herdテスタ(HT)プロジェクトチーム</title>
<author title="Author">
<mail link="jmbsvicetto@gentoo.org">Jorge Vicetto</mail>
</author>
<author title="Author">
<mail link="genstef@gentoo.org">Stefan Schweizer</mail>
</author>
<author title="Contributor">
<mail link="keytoaster@gentoo.org">Tobias Heinlein</mail>
</author>
<abstract>
KDE HTプロジェクトはパッケージをテストして課題を絞り込み解決法を探ることで開発者を献身的に援助しています。
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
<version>1.0</version>
<date>2007-12-09</date>
<!-- Original revision: 1.2 -->
<chapter>
<title>はじめに</title>
<section>
<body>
<p>
<uri link="http://www.gentoo.org/proj/en/glep/glep-0041.html">GLEP 41</uri>
で定義されているとおり、
HT(Herdテスタ)とはパッケージをテストして課題を絞り込み解決法を探ることで開発者を援助する信頼のおけるユーザーのことです。
</p>
</body>
</section>
</chapter>
<chapter>
<title>得られるもの</title>
<section>
<body>
<p>
HTになると、 <c>gentoo/contributor/${お名前}</c> というIRCクロークが与えられ、
<uri link="https://forums.gentoo.org/">Gentoo forums</uri> の「Arch/Herd
Tester」グループに編入され、 <c>#gentoo-kde</c> 内の自動的発言権を得られ、
<c>kde@gentoo.org</c> メール別名に加えられ、
<uri link="https://bugs.gentoo.org/">Gentoo Bugzilla</uri> の
<c>editbugs</c> 権が与えられます。
</p>
</body>
</section>
</chapter>
<chapter>
<title>なすべきこと</title>
<section>
<body>
<p>
HTは普段からパッケージをテストし、 バグ報告に案内を提供し、
KDEチーム内でIRCチャンネル (<c>#gentoo-kde</c>) を通じて交流を保ち、
<c>kde@gentoo.org</c> メール別名にメールを送ります。 また強制ではありませんが、
フォーラムやメーリングリストやIRCチャンネルにいるユーザーを助けていただきます。
</p>
</body>
</section>
</chapter>
<chapter>
<title>必要条件</title>
<section>
<body>
<p>
We expect people to do good testing, show good knowledge about Gentoo in general
and to be active (taking into account RL constraints).
HTのみなさんには、
良好なテストを行ないGentooについて一般的に正しい認識を示していただきます。
活動を
</p>
</body>
</section>
</chapter>
<chapter>
<title>参加</title>
<section>
<body>
<p>
If you think your comments and patches submitted to Bugzilla and willingness to
help other users on IRC, mailinglists and/or forums justifies HT status you can
talk to the KDE herd. Users will also be invited to become HTs by members of the
KDE herd that notice their work, abilities and desire to help the KDE herd.
Bugzillaに送ったコメントやパッチを気にかけたり、
XXXIRCやメーリングリストやフォーラムで他のユーザーを喜んで助ける心意気がHTの立場を良くすると考えていただけるのなら、
KDE Herdに連絡を取ってかまいません。
ユーザーには1
</p>
<p>
To become an HT, the user will have to complete the <uri
link="http://www.gentoo.org/proj/en/devrel/quiz/ebuild-quiz.txt">ebuild
quiz</uri> and have a review session with the AT lead (<mail
link="hparker@gentoo.org">hparker</mail>).
</p>
<p>
Interested users should read the <uri link="http://devmanual.gentoo.org/">Gentoo
Development Guide/DevManual</uri> and the <uri
link="http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml">Gentoo
Developer Handbook</uri> and should work with the other members of the herd to
address the questions on the quiz. The KDE HT lead will work closely with all
HTs, helping them prepare for the quiz and the interview, and will coordinate
their work on the herd.
</p>
</body>
</section>
</chapter>
</guide>
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
<!DOCTYPE project SYSTEM "/dtd/project.dtd">
<project>
<name>KDE</name>
<longname>Gentoo KDE プロジェクト</longname>
<date>2012-03-25</date>
<!-- Original revision: 1.143 -->
<author title="Author">
<mail link="caleb"/>
</author>
<author title="Author">
<mail link="deathwing00"/>
</author>
<author title="Author">
<mail link="philantrop"/>
</author>
<author title="Author">
<mail link="masterdriverz"/>
</author>
<author title="Author">
<mail link="jmbsvicetto"/>
</author>
<author title="Author">
<mail link="keytoaster"/>
</author>
<author title="Author">
<mail link="tanderson"/>
</author>
<author title="Author">
<mail link="scarabeus"/>
</author>
<author title="Author">
<mail link="yngwin"/>
</author>
<author title="Author">
<mail link="tampakrap"/>
</author>
<author title="Author">
<mail link="hwoarang"/>
</author>
<author title="Author">
<mail link="abcd"/>
</author>
<author title="Author">
<mail link="dilfridge"/>
</author>
<author title="Author">
<mail link="johu"/>
</author>
<description>
KDEプロジェクトはGentooにおけるKDE用ebuildを保守管理しています。
</description>
<longdescription>
<note>サポートやインストール方法の指導については <uri
link="#doc_chap4">サポートと救援の節</uri> を参考にしてください。</note>
<p>
Gentoo KDEチームの目標はKDEプロジェクトが出しているすべてのパッケージを運営しサポートを提供することです。
また下支えのパッケージについても、
KDEの環境を正常に保つうえで欠かせないものであるかぎりサポートします。
ただ、 実際はあまりにもアプリケーションの数が多くあって、
KDEの保守担当者でも使っていないものが多数あるために、
KDEプロジェクトとして全部の維持管理を正常に行なえないことを理由に、
他のチームに委ねられているKDEアプリケーションもいくつかありそうです。
とはいえKDEアプリケーションを管理しKDEのeclassを適切に利用できるよう、
そうしたチームを当プロジェクトはサポートします。
</p>
</longdescription>
<dev role="lead">dilfridge</dev>
<dev role="member">abcd</dev>
<dev role="member">alexxy</dev>
<dev role="member">jmbsvicetto</dev>
<dev role="member">johu</dev>
<dev role="member">mschiff</dev>
<dev role="member">patrick</dev>
<dev role="member">reavertm</dev>
<dev role="member">scarabeus</dev>
<dev role="member">tampakrap</dev>
<dev role="member">thev00d00</dev>
<extraproject name="KDE Herdテスタ" link="at/" lead="tampakrap">
KDE HTプロジェクトはパッケージをテストして課題を絞り込み解決法を探ることで開発者を献身的に援助しています。
</extraproject>
<herd name="kde"/>
<extrachapter position="goals">
<title>ご利用いただけるKDEのバージョン</title>
<section>
<title>KDE 4</title>
<body>
<p>
KDE公式のPortageツリーで最新のバージョンは <b>4.7</b> であり、 最新の
<b>安定版</b> バージョンは <b>4.7</b> です。
KDE 4シリーズは分割されたebuild経由でのみ入手できます。
サブマイナーリリース(例:4.7.4)は毎月の更新です。
逆戻りさえなければ、 Portageツリーに追加されて1ヶ月以内に安定化いたします。
</p>
<p>
KDE <b>4.7</b> が現在の安定版です。
KDEPIMを利用していて4.4から4.7に更新する場合は、 まず先に
<uri link="http://wiki.gentoo.org/wiki/KDEPIM-4.7_upgrade">Gentoo Wiki KDEPIM
4.7 Upgrade Guide</uri> をお読みください。
KDEPIMを4.4のまま残しておきたければ
<uri link="kdepim-4.7-mask.txt">KDEPIM 4.7をマスクする</uri> 方法があります。
一般的なヘルプ情報は
<uri link="kde4-guide.xml">Gentoo KDE Guide</uri>
(日本語版 <uri link="proj/ja/desktop/kde/kde4-guide.xml">Gentoo KDEガイド</uri>)
にあります。
</p>
<p>
また、 KDEチームはlaymanによる <uri
link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=summary">kde</uri>
のオーバーレイを維持管理しています。
ここには追加アプリケーションをはじめ、 スナップショットやKDE 4用live ebuildがあります。
ここに置かれているものはどれも正式なツリーに入れるには安定度が不十分でテスト対象という位置付けです。
さあそこの太っ腹な勇者さん、
Gentooユーザーならそんなebuildをテストしてみませんか。
</p>
</body>
</section>
<section>
<title>KDE 3.5</title>
<body>
<p>
KDE 3の維持管理は現在 <uri
link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde-sunset.git;a=summary">kde-sunset</uri>
のオーバーレイ(laymanによる)で行なわれています。
KDE 3中核と雑多のパッケージのすべてがここに移動しました。
このオーバーレイの維持管理はユーザーだけで行なわれており、
現在のKDEチームメンバーにはその状態について何ら責任がないので気をつけましょう。
維持管理の協力に関心のある方なら <mail link="tampakrap" />
にメールを送りコミットアクセス権を得ませんか。
このオーバーレイに関してバグの報告をする場合、
Gentoo Bugzillaには提出しないでください。 代わりに <uri
link="http://archives.gentoo.org/gentoo-desktop/">gentoo-desktop</uri>
メーリングリストを使います。 読者・投稿者になる方法の説明は <uri
link="http://www.gentoo.org/main/en/lists.xml">こちら</uri> です。
</p>
<p>
<uri link="http://www.gentoo.org/proj/en/overlays/userguide.xml">
Gentoo Overlays Users' Guide</uri> をお読みいただき、
オーバーレイの利用方法の情報を得ましょう。
</p>
</body>
</section>
</extrachapter>
<extrachapter position="goals">
<title>会合の会話録とその要旨</title>
<section>
<body>
<p>
KDEチームは通常で毎月第3木曜日の19:00UTC(世界標準時)[日本時間第3金曜日04:00]に
<uri link="irc://irc.freenode.net/gentoo-meetings">#gentoo-meetings</uri>
というirc上の非公式会合に参加しています。
会合を催すことになるときはいつもアナウンスされ、 <uri
link="irc://irc.freenode.net/gentoo-kde">#gentoo-kde</uri>
での話題から上ってきた打ち合わせ事項がそこで一緒に告げられる習わしです。
毎回の会合の要旨は、 閲覧用に公開された生ログとともにこちらで入手可能です。
</p>
<table>
<tr>
<th>実施日</th>
<th>参加者</th>
<th>ログ</th>
<th>要旨</th>
</tr>
<tr>
<ti>2012年3月22日</ti>
<ti>alexxy, dilfridge, johu, mschiff, scarabeus, tampakrap</ti>
<ti><uri link="meeting-logs/kde-project-meeting-log-20120322.txt">20120322</uri></ti>
<ti><uri link="meeting-logs/kde-project-meeting-summary-20120322.txt">20120322</uri></ti>
</tr>
<tr>
<ti>2012年1月16日</ti>
<ti>alexxy, dilfridge, jmbsvicetto, johu, mschiff, tampakrap, Thev00d00</ti>
<ti><uri link="meeting-logs/kde-project-meeting-log-20120116.txt">20120116</uri></ti>
<ti><uri link="meeting-logs/kde-project-meeting-summary-20120116.txt">20120116</uri></ti>
</tr>
<tr>
<ti>2011年8月31日</ti>
<ti></ti>
<ti><uri link="meeting-logs/kde-project-meeting-log-20110831.txt">20110831</uri></ti>
<ti></ti>
</tr>
<tr>
<ti>2011年6月2日</ti>
<ti></ti>
<ti><uri link="meeting-logs/kde-project-meeting-log-20110602.txt">20110602</uri></ti>
<ti><uri link="meeting-logs/kde-project-meeting-summary-20110602.txt">20110602</uri></ti>
</tr>
<tr>
<ti>2011年3月31日</ti>
<ti></ti>
<ti><uri link="meeting-logs/kde-project-meeting-log-20110331.txt">20110331</uri></ti>
<ti></ti>
</tr>
<tr>
<ti>2011年2月11日</ti>
<ti></ti>
<ti><uri link="meeting-logs/kde-project-meeting-log-20110210.txt">20110210</uri></ti>
<ti><uri link="meeting-logs/kde-project-meeting-summary-20110210.txt">20110210</uri></ti>
</tr>
<tr>
<ti>2010年9月2日</ti>
<ti>ABCD, dilfridge, reavertm, spatz, tampakrap</ti>
<ti><uri link="meeting-logs/kde-project-meeting-log-20100902.txt">20100902</uri></ti>
<ti><uri link="meeting-logs/kde-project-meeting-summary-20100902.txt">20100902</uri></ti>
</tr>
<tr>
<ti>2010年6月4日</ti>
<ti>ABCD, alexxy, dilfridge, wired, scarabeus, deathwing00, patrick, jmbsvicetto</ti>
<ti><uri link="meeting-logs/kde-project-meeting-log-20100604.txt">20100604</uri></ti>
<ti><uri link="meeting-logs/kde-project-meeting-summary-20100604.txt">20100604</uri></ti>
</tr>
<tr>
<ti>2010年3月18日</ti>
<ti>alexxy, jmbsvicetto, patrick, scarabeus, spatz, tampakrap, wired</ti>
<ti><uri link="meeting-logs/kde-project-meeting-log-20100318.txt">20100318</uri></ti>
<ti><uri link="meeting-logs/kde-project-meeting-summary-20100318.txt">20100318</uri></ti>
</tr>
<tr>
<ti>2010年2月25日</ti>
<ti>abcd, alexxy, jmbsvicetto, patrick, reavertm, scarabeus, spatz, ssuominen, tampakrap, wired</ti>
<ti><uri link="meeting-logs/kde-project-meeting-log-20100225.txt">20100225</uri></ti>
<ti><uri link="meeting-logs/kde-project-meeting-summary-20100225.txt">20100225</uri></ti>
</tr>
<tr>
<ti>2009年11月19日</ti>
<ti>abcd, ayoy, dagger, ingmar, jmbsvicetto, mrpouet, patrick, pesa, scarabeus, spatz, sput, tampakrap, wired, yngwin</ti>
<ti><uri link="meeting-logs/kde-qt-projects-meeting-log-20091119.txt">20091119</uri></ti>
<ti></ti>
</tr>
<tr>
<ti>2009年9月24日</ti>
<ti>abcd, alexxy, ayoy, dagger, jmbsvicetto, patrick, pesa, reavertm, tampakrap, wired</ti>
<ti><uri link="meeting-logs/kde-project-meeting-log-20090924.txt">20090924</uri></ti>
<ti></ti>
</tr>
<tr>
<ti>2009年9月17日</ti>
<ti>abcd, alexxy, ayoy, jmbsvicetto, patrick, pesa, reavertm, spatz, tampakrap, wired</ti>
<ti><uri link="meeting-logs/kde-project-meeting-log-20090917.txt">20090917</uri></ti>
<ti></ti>
</tr>
<tr>
<ti>2009年8月20日</ti>
<ti>abcd, ayoy, bonsaikitten, dagger, jmbsvicetto, reavertm, scarabeus, wired, yngwin</ti>
<ti><uri link="meeting-logs/kde-project-meeting-log-20090820.txt">20090820</uri></ti>
<ti><uri link="meeting-logs/kde-project-meeting-summary-20090820.txt">20090820</uri></ti>
</tr>
<tr>
<ti>2009年6月18日</ti>
<ti>alexxy, bonsaikitten, hworang, jmbsvicetto, Pessa, reavertm, scarabeus, spatz, tampakrap, wired, yngwin</ti>
<ti><uri link="meeting-logs/kde-project-meeting-log-20090618.txt">20090618</uri></ti>
<ti><uri link="meeting-logs/kde-project-meeting-summary-20090618.txt">20090618</uri></ti>
</tr>
<tr>
<ti>2009年5月21日</ti>
<ti>alexxy, bonsaikitten, civil, cryos, dagger, hwoarang, jmbsvicetto, krytzz, lxnay, papillon81, reavertm, scarabeus, tampakrap, wired, yngwin</ti>
<ti><uri link="meeting-logs/kde-project-meeting-log-20090521.txt">20090521</uri></ti>
<ti><uri link="meeting-logs/kde-project-meeting-summary-20090521.txt">20090521</uri></ti>
</tr>
<tr>
<ti>2009年4月1日</ti>
<ti>alexxy, bonsaikitten, cryos, hwoarang, jmbsvicetto, krytzz, reavertm, scarabeus, tampakrap, wired, yngwin</ti>
<ti><uri link="meeting-logs/kde-project-meeting-log-20090401.txt">20090401</uri></ti>
<ti><uri link="meeting-logs/kde-project-meeting-summary-20090401.txt">20090401</uri></ti>
</tr>
<tr>
<ti>2009年3月5日</ti>
<ti>alexxy, bonsaikitten, cryos, hwoarang, jmbsvicetto, reavertm, scarabeus, tampakrap, wired, yngwin</ti>
<ti><uri link="meeting-logs/kde-herd-meeting-log-20090305.txt">20090305</uri></ti>
<ti><uri link="meeting-logs/kde-herd-meeting-summary-20090305.txt">20090305</uri></ti>
</tr>
<tr>
<ti>2009年2月12日</ti>
<ti>alexxy, hwoarang, jmbsvicetto, krytzz, reavertm, scarabeus, Sput, tampakrap, wired, yngwin</ti>
<ti><uri link="meeting-logs/kde-project-meeting-log-20090212.txt">20090212</uri></ti>
<ti><uri link="meeting-logs/kde-project-meeting-summary-20090212.txt">20090212</uri></ti>
</tr>
<tr>
<ti>2009年1月8日</ti>
<ti>cryos, jmbsvicetto (at the end), patrick, scarabeus, yngwin, most of the HTs</ti>
<ti><uri link="meeting-logs/kde-herd-meeting-log-20090108.txt">20090108</uri></ti>
<ti><uri link="meeting-logs/kde-herd-meeting-summary-20090108.txt">20090108</uri></ti>
</tr>
<tr>
<ti>2008年12月4日</ti>
<ti>cryos, jmbsvicetto, keytoaster, patrick, scarabeus, yngwin, most of the HTs</ti>
<ti><uri link="meeting-logs/kde-herd-meeting-log-20081204.txt">20081204</uri></ti>
<ti><uri link="meeting-logs/kde-herd-meeting-summary-20081204.txt">20081204</uri></ti>
</tr>
<tr>
<ti>2008年3月6日</ti>
<ti>caleb, cryos, deathwing00, genstef, ingmar, jmbsvicetto, keytoaster, philantrop, tgurr, zlin</ti>
<ti><uri link="meeting-logs/kde-herd-meeting-log-20080306.txt">20080306</uri></ti>
<ti><uri link="meeting-logs/kde-herd-meeting-summary-20080306.txt">20080306</uri></ti>
</tr>
<tr>
<ti>2007年10月13日</ti>
<ti>cryos, genstef, jmbsvicetto, keytoaster, philantrop, tgurr</ti>
<ti><uri link="meeting-logs/kde-herd-meeting-log-20071013.txt">20071013</uri></ti>
<ti><uri link="meeting-logs/kde-herd-meeting-summary-20071013.txt">20071013</uri></ti>
</tr>
</table>
</body>
</section>
</extrachapter>
<extrachapter position="goals">
<title>サポートと救援</title>
<section>
<body>
<p>
KDE関連の問題でサポートを受けられる方法がいくつかあります。
</p>
<ul>
<li>
GentooにKDEをインストールするときは <uri link="kde4-guide.xml">Gentoo KDE
Guide</uri> (日本語版 <uri link="kde4-guide.xml">Gentoo KDEガイド</uri>)
を使いましょう。
このガイドはKDE 4と多彩なKDE 4アプリケーションをインストールする方法に加え、
よくある質問とその答えをまとめたFAQと、 ヒント集と、
問題解決例が入っています。
</li>
<li>
Freenode IRCネットワーク上の
<uri link="irc://irc.freenode.net/gentoo-kde">#gentoo-kde</uri>
にご参加いただけます。
ほぼどの時間帯でもチームメンバーの誰かにそこで会えるはずです。
</li>
<li>
思ったことをGentooフォーラムで発言できます。
我々当チームの全員がフォーラムの熱心な会員というわけではありませんが、
経験ある多数のユーザーと幾人かの開発者が助けてくれるかもしれません。
</li>
<li>
KDEチームは <uri
link="http://archives.gentoo.org/gentoo-desktop/">gentoo-desktop</uri>
メーリングリストをかなり頻繁に利用して、
問題の討議やいろいろな(会合のことや重大な変更についての)情報告知をしたり、
ユーザーとの触れ合いや問題の解決さえもします。
読者・投稿者になる方法の説明は <uri
link="/main/en/lists.xml">こちら</uri> です。
</li>
<li>
もちろんバグ報告もできます。 先に
<uri link="#doc_chap6">バグ報告の仕方</uri> の章を読んでおいてください。
</li>
</ul>
</body>
</section>
</extrachapter>
<extrachapter position="goals">
<title>支援の仕方</title>
<section>
<body>
<p>
主な任務は現在まだ閉じられていないバグを巡視して廻り、 古くなったものや <uri
link="https://bugs.kde.org">KDEのBugzilla</uri>
に同一のバグ報告が出されていないか探し出すことです。
</p>
<p>
現在まだ閉じられていないバグのリストは
<uri link="http://tinyurl.com/63fzlah">こちら</uri> にまとめられています。
</p>
<p>
古くなったバグ報告には現在のバージョンでも問題がなお発生するかどうか訊く必要があります。
誰かの手で既に訊かれているのにバグ報告者(さらには同じ問題に遭遇した他の人さえも)がまだ返答していないのであれば、
NEEDINFOのマークを付ける必要があります。
</p>
<p>
バグを議論するということはテスト民(Herd Tester)にもなれるということです!
HT(テスト民)になる条件も任務も必要な情報はすべて <uri
link="at/">KDE Herd Testers Project Page</uri> に書いてあります。
</p>
<ul>
<li>
現在信任されているユーザー: <uri
link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=Documentation/HACKERS">HACKERS</uri>
</li>
<li>
パッケージ担当者(その他の開発者)用のヒント集: <uri
link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=Documentation/CODE">CODE</uri>
</li>
</ul>
<note>
HTになるには <uri link="at/">document</uri> をお読みいただき、
現在のKDEのリーダーを努める <mail link="tampakrap"/> にご連絡願います。
</note>
<p>
Finally, it would be great to chat to you on IRC, too - this is how we normally
get to know each other. Please drop into <uri
link="irc://irc.freenode.net/gentoo-kde">#gentoo-kde</uri> and chat with us. If
you have any problems or questions, feel free to /query individual team members
or ask in <uri link="irc://irc.freenode.net/gentoo-kde">#gentoo-kde</uri>, <uri
link="irc://irc.freenode.net/gentoo-desktop">#gentoo-desktop</uri> or <uri
link="irc://irc.freenode.net/gentoo">#gentoo</uri>.
最後に、 IRCでお話しできてもうれしいものですね。
普段我々は互いの近況をここで知らせ合っています。 <uri
link="irc://irc.freenode.net/gentoo-kde">#gentoo-kde</uri>
にて落ち合ってお話ししませんか。 問題があったり質問があれば、
XXXお気軽にチームメンバーへ/queryしたり
<uri link="irc://irc.freenode.net/gentoo-kde">#gentoo-kde</uri> や <uri
link="irc://irc.freenode.net/gentoo-desktop">#gentoo-desktop</uri> や <uri
link="irc://irc.freenode.net/gentoo">#gentoo</uri> でご相談ください。
</p>
</body>
</section>
</extrachapter>
<extrachapter position="goals">
<title>バグ報告の仕方</title>
<section>
<body>
<p>
バグに遭遇したなら、 バグは報告されなくてはなりません。
まず一番大切なことはそのバグがまだ報告されていないか確かめることであり、
もしまだならば適切な人々にそれを報告することです。
バグの原因がGentooの方にあるのか供給元(アップストリーム)側にあるのかはっきりしないときはつぎの手続に従います。
</p>
<ul>
<li>
バグがランタイムで問題を起こす類いのもの(クラッシュやパッケージの不正な動作)なら供給元に報告すべきでしょう。
お望みなら私達の方にもバグを報告していただいて構いません、
こちらでも追跡を開始しパッチをバックポートできるからです。
まだkdebase-runtime-metaをインストールしていないのならまずそれをインストールしていただいてから、
再現可能な場合にはそのまま供給元でバグ報告をします。
再現が不可能なときはその情報をすべて添えてGentooだけに報告してください。
</li>
<li>
ビルドの失敗や、 依存エラーや一般的なebuildバグでしたら、
Gentooに報告すべきです。
</li>
<li>
それでもなおよくわからないのでしたらGentooにバグ報告を出した方が、
私たちがチェックしてこのあと何をすべきか助言できますから良いでしょう。
</li>
</ul>
<note>
バグを報告する前に同様のバグが無いかよく確かめ、 さらに当ガイドの <uri
link="kde4-guide.xml#doc_chap5">ヒント集と問題解決例</uri>
の節で解決法が出ていないか確かめましょう。
</note>
</body>
</section>
</extrachapter>
</project>
<?xml version='1.0' encoding="UTF-8"?>
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/eselect/index.xml,v 1.20 2012/03/09 18:39:01 ulm Exp $ -->
<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
<!DOCTYPE project SYSTEM "/dtd/project.dtd">
<project>
<name>eselect</name>
<longname>Gentoo's eselect modular framework for configuration and
administration utilities</longname>
<longname>Gentoo eselect設定・運用ユーティリティのモジュール化フレームワーク</longname>
<date>2012-03-09</date>
<!-- Originar revision: 1.20 -->
<author title="Author">
<mail link="kugelfang@gentoo.org">Danny van Dyk</mail>
</author>
<author title="Author">
<mail link="ulm@gentoo.org">Ulrich Müller</mail>
</author>
<author title="Contributor">
<mail link="slarti@gentoo.org">Tom Martin</mail>
</author>
<description>
このページはGentooのモジュール化した設定・運用フレームワークであるeselectについての情報を扱っています。
</description>
<longdescription><p>
このページはGentooのモジュール化した設定・運用フレームワークであるeselectについての情報を扱っています。
</p></longdescription>
<dev role="member" description="*">peper</dev>
<dev role="member" description="*">ulm</dev>
<dev role="member" description="modules">dberkholz</dev>
<dev role="member" description="documentation">fox2mike</dev>
<extrachapter>
<title>はじめに</title>
<section>
<body>
<p>
eselectはGentooのシステムにおいて既存のツールを集中し強固なものにするため、
モジュール化した設定フレームワークを提供します。
コマンド行インターフェースを装備しているにもかかわらず本当に親切です。
</p>
<p>
eselectはモジュールも含め徹頭徹尾 <c>bash</c> によって書かれています。
eselectモジュールが書き易くなり、 管理が簡単で、
CやPythonやRubyのような他の特定の言語に固有の知識が要求されないということから、
この業務に理想的な言語だと確認されました。
eselectモジュールはebuildと似た構造をしています。
</p>
<p>
eselectのモジュールには、 <path>/usr/src/linux</path>
のシンボリックリンクを変えるものや、
portageのプロファイルを変更するものがあったり、
モジュールとしてはやや実験的であるけれどCONFIG_PROTECTで保護されているファイルを相互対話的に更新できる便利なものや、
ランレベルやinitシステムを操作するものなどがあり、
ほかにもいろいろなたくさんのモジュールがあります。
</p>
<p>
eselectは使い易さと、
Gentooのインストール作業で使われるモジュールの設定と運用の間で一貫性を確保することを目指しています。
</p>
</body>
</section>
</extrachapter>
<resource link="user-guide.xml">eselect User Guide</resource>
(日本語版 <resource link="proj/ja/eselect/user-guide.xml">eselectユーザーガイド</resource>)
<resource link="dev-guide.xml">eselect Developer Reference</resource>
(日本語版 <resource link="proj/ja/eselect/dev-guide.xml">eselect開発者リファレンス</resource>)
<resource link="http://git.overlays.gentoo.org/gitweb/?p=proj/eselect.git;a=blob_plain;f=NEWS;hb=HeAD">News for eselect</resource>
<resource link="http://git.overlays.gentoo.org/gitweb/?p=proj/eselect.git">eselect source code</resource>
</project>
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
<!DOCTYPE project SYSTEM "/dtd/project.dtd">
<project>
<name>Portage</name>
<longname>Gentoo Linux Portage Development</longname>
<date>$Date: 2010/12/30 22:00:12 $</date>
<!-- Original revision: 1.69 -->
<author title="Author of old project page"><mail>carpaski</mail></author>
<author title="Author"><mail>genone</mail></author>
<description>
Portage開発プロジェクトはPortageの中心機能とユーティリティを保守管理し開発をすすめることを目的としています。
</description>
<longdescription>
<p>Portage開発プロジェクトはパッケージの管理とインストール作業に用いるツールを日常普段に拡張し開発するために活動しています。
開発者たちはなるべくトラブルがなく(後方互換性があり、 自動化された、
なおかつ簡素な)一貫したシステムをつくることに努めています。
バグは <uri link="http://bugs.gentoo.org/">Gentoo bug tracker</uri>
で追跡と処置が行なわれており、
開発者同士の交信はgentoo-portage-devメーリングリストが担います。
連絡手段はこの他にfreenodeネットワークにてIRCチャンネル上に#gentoo-portageが設けられています。<p>
</longdescription>
<goals>
</p>
<p>Portage開発プロジェクトの目標はGentoo Portageツリーの成長と維持管理を援けるための開発者向けおよびユーザー向けのツールを仕切りなく統合させることです。<p>
</goals>
<subproject ref="/proj/ja/portage/sandbox/index.xml" inheritmembers="yes"/>
<extraproject name="Documentation" lead="vapier">
Portage用ツールに関する文書の作成および更新。
</extraproject>
<subproject ref="/proj/en/portage/tools/index.xml" inheritmembers="yes"/>
<dev role="Member" description="Documentation">vapier</dev>
<dev role="Lead" description="Release Coordinator">zmedico</dev>
<dev role="Member">solar</dev>
<dev role="Member">volkmar</dev>
<extrachapter position="resources">
<title>当チーム以外で提供されている文書</title>
<section>
<body>
<p>つぎの資料は <uri link="/proj/en/gdp/">documentation project</uri>
が保守管理していることを明記していないものも含みますが、
Portageに関する重要なオンライン文書なのでここに列挙します。
<ul>
<li><uri link='/doc/en/handbook/handbook-x86.xml?part=2&amp;chap=1'>A Portage Introduction</uri>
(日本語版 <uri link='/doc/ja/handbook/handbook-x86.xml?part=2&amp;chap=1'>Portageについて</uri>)</li>
<li><uri link='/doc/en/handbook/handbook-x86.xml?part=2&amp;chap=3'>Portage Features</uri>
(日本語版 <uri link='/doc/ja/handbook/handbook-x86.xml?part=2&amp;chap=3'>Portageの機能</uri>)</li>
<li><uri link='/doc/en/handbook/handbook-x86.xml?part=3'>Working with Portage</uri>
(日本語版 <uri link='/doc/ja/handbook/handbook-x86.xml?part=3'>Portageを使いこなす</uri>)</li>
<li><uri link='/doc/en/handbook/handbook-x86.xml?part=2&amp;chap=2'>USE flags</uri>
(日本語版 <uri link='/doc/ja/handbook/handbook-x86.xml?part=2&amp;chap=2'>USEフラグ</uri>)</li>
<li><uri link='/proj/en/devrel/handbook/handbook.xml'>Gentoo Developer Handbook ('Developer relations'プロジェクトによる管理)</uri></li>
<li><uri link='http://devmanual.gentoo.org'>Gentoo Devmanual ('QA'プロジェクトによる管理)</uri></li>
</ul>
</body>
</section>
</extrachapter>
<resource link="doc/faq.xml">Portage Frequently Asked Questions (FAQ)</resource>
<resource link="doc/common-problems.xml">List of common major portage problems and solutions</resource>
<resource link="doc/manually-fixing-portage.xml">Guide for manually fixing a broken portage install</resource>
<resource link="doc/testing.xml">Some notes about how to obtain and test development versions</resource>
<resource link="http://dev.gentoo.org/~zmedico/portage/doc/">Portage Documentation (generated from docbook)</resource>
<resource link="http://dev.gentoo.org/~zmedico/portage/doc/api/">Portage API Documentation (generated with epydoc)</resource>
<resource link="doc/policies/membership.xml">Membership policies of the Portage project</resource>
<resource link="http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob_plain;f=NEWS;hb=master">Portage NEWS file listing new features</resource>
<resource link="http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob_plain;f=RELEASE-NOTES;hb=master">Portage RELEASE-NOTES file listing upgrade information</resource>
<resource link="irc://irc.freenode.net/gentoo-portage">#gentoo-portage IRC channel</resource>
<resource link="/main/en/lists.xml">gentoo-portage-dev mailing list</resource>
<resource link="http://packages.gentoo.org/package/sys-apps/portage">sys-apps/portage package</resource>
<resource link="http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=summary">Portage GIT repository (over gitweb)</resource>
<resource link="http://bugs.gentoo.org/buglist.cgi?bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=exact&amp;email1=dev-portage%40gentoo.org&amp;keywords_type=nowords&amp;keywords=InVCS+InSVN">Open bugs assigned to the dev-portage alias</resource>
<resource link="http://bugs.gentoo.org/buglist.cgi?bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=exact&amp;email1=pms-bugs%40gentoo.org">Open bugs assigned to the pms-bugs alias</resource>
<resource link="http://bugs.gentoo.org/buglist.cgi?bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=exact&amp;email1=tools-portage%40gentoo.org">Open bugs assigned to the tools-portage alias</resource>
<extrachapter position="recruitment">
<title>Portageのためにできること</title>
<section>
<title>バグ報告</title>
<body>
<p>バグを見つけたら漏れなく
<uri link="http://bugs.gentoo.org">バグ追跡システム</uri> にご報告ください。
新しいバグ報告を提出するときはその前に必ず同じ内容のバグ報告が他のユーザーから出されていないことを確認しておきましょう。</p>
<impo>sys-apps/portage以外の他パッケージに関わるバグ報告や要望をPortage開発プロジェクト宛てに出してはいけません。</impo>
<p>
バグ報告を書くときはつぎのような状況をはっきりと示しましょう。
</p>
<ul>
<li>どんなふうにしてバグが発生したか(実行したコマンドは?、変更したファイルは?)</li>
<li>バグが見つかったときに使用したPortageのバージョンは何か</li>
<li>バグは再現可能か</li>
<li><c>emerge --info</c> コマンドの出力</li>
</ul>
<p>提出したバグ報告に反応がすぐになくてもどうかあまりいらいらなさらないでください。
開発担当者が目を通すときまで多少の時間がかかることがあります(これはPortage以外でも同様です)。
バグの解決にとりかかるときになってさらに情報が欲しいと要求することもよくありますので、
そのときはできるだけ早く求められている情報を返答してください。
もし長い時間(1ヶ月以上)が過ぎても返答がないときは、
RESOLVED:NEEDINFOをつけてバグを閉じさせていただく可能性がありますが、
そのあとでもreopenすれば依頼された情報を投稿できます。
</p>
<p>
つぎのような状況のどれにもあてはまらない場合はバグをreopenしないでください。
</p>
<ul>
<li>
バグはRESOLVED:FIXEDとなっているのに、
修正が効いたはずの新しいバージョン(一般的にはバグが閉じられた時に処置を受けたバージョン)でも依然として同じバグが起きるとき。
</li>
<li>
バグはRESOLVED:NEEDINFOとなっていて、 要請された情報を提出しようとするとき。
</li>
<li>
バグはRESOLVED:WONTFIX、 RESOLVED:CANTFIX、
RESOLVED:LATERのいずれかとなっていて、 何か誤解があると考えられるとき。
<b>解決の判断に不満がある・同意できないという理由だけでreopenしてはいけません。</b>
</li>
</ul>
<p>
バグが閉じられていても寄せられるコメントには目を通すようにしていますので、
安心してください。 注意を惹こうという理由でreopenする必要はありません。
</p>
<p>
バグ報告はどれもそれぞれが一件の問題を扱います。
どうかこのことを尊重していただき、
そのバグ報告に直接の関係がない他のことを話題に出さないようにしましょう。
</p>
</body>
</section>
<section>
<title>複数のバージョンのPortageをテスト</title>
<body>
<note>この節の説明はPortage 2.1.2以降の版にのみ適用できます</note>
<p>
いろいろな理由から同時に複数のバージョンのPortageをシステムのデフォルトとしてインストールすることなく利用したくなる場合があります。
例えば、 ある特定のバグが影響するバージョンがどれか調べたいときや、
新しいバージョンに入れ替えずに新機能を試すとき、
あるいはgitからチェックアウトした版をテストできるようにしつつ、
通常の操作ができるように安定版も入れたままにしたいときがそうです。
</p>
<p>As of Portage-2.1.2 one can have and use an arbitrary number of Portage
installations parallel to each other by adjusting the two environment variables
<c>PATH</c> and <c>PYTHONPATH</c>. For example if you have a checkout of the
master branch at <path>/checkouts/portage</path> you'd set them like this:</p>
<p>
Portage 2.1.2以降、 環境変数 <c>PATH</c> と <c>PYTHONPATH</c>
を調整しておけばひとつのシステムにいくつものPortageを一緒に入れて利用できるようになっています。
例えば <path>/checkouts/portage</path>
へmasterブランチをチェックアウトしているのならつぎのように設定します。
</p>
<pre caption="Portageのmasterブランチを利用する設定">
export PYTHONPATH="/checkouts/portage/pym:${PYTHONPATH}"
export PATH="/checkouts/portage/bin:${PATH}"
</pre>
<p>
このように設定しておけば、 <c>emerge</c>、 <c>repoman</c>、 <c>ebuild</c>
のようなツールが正しくライブラリの位置を引き出せます。
gentoolkitやportholeのような外部ツールのなかにはこうした設定を尊重するものもあれば無視するものもあるようです。
常日頃からパスを省略せずに指定している場合(例えば <c>emerge</c> だけとせず
<c>/checkouts/portage/bin/emerge</c> とフルパスにしている場合)は <c>PATH</c>
の設定はさほど重要ではなくなります。
</p>
</body>
</section>
<section>
<title>パッチの提出</title>
<body>
<p>
sys-apps/portageパッケージもしくはこれに関連するパッケージに当てるパッチを提出するときは、
必ずパッチがつぎの基準要件を満たすようにしてください。
</p>
<ul>
<li>
タブを使用します。
字下げは人によってスペース8個分の幅が好まれたり4個が好まれたりし、
あるいは2個が好きな人たちも居ます。 タブはよくできたしくみです。
空白文字をならべたりタブと併用したりしてインデントを行なったパッチは拒否も止むを得ません。
</li>
<li>
原則としてファイル丸ごとでなくdiff形式で提出するものとし、
新しくしたファイルよりdiffの方が明らかにかさばる場合や、
未だ存在しないファイルを提出するときにのみファイル丸ごとでも良いこととします。
</li>
<li>Diffs have to be in unified form (<c>diff -u</c>, <c>git diff</c>).</li>
<li>
diffはXXX統一形式でなくてはいけません(<c>diff -u</c> や
<c>git diff</c> で生成できます)。
</li>
<li>
パッチがどんなことをするか詳細な説明を必ず加え、
更に何故その実装を行なったのか(換言すればそのパッチの利点はどこにあるか)の説明を必要に応じて書き添えます。
また、 そのパッチにより欠点や問題発生が想定できるなら付け加えます。
</li>
<li>
パッチの作成に使用した(リリース物の場合は)リリースバージョンもしくは(gitパッチの場合には)リポジトリのリヴィジョンとブランチ名を必ず明示します。
</li>
<li>
混じり気のないパッチだけを提出します。
提出するパッチに他のパッチを混ぜ込んではいけません。
パッチの説明にそぐわないコードが見つかったときには拒否も止むを得ません。
また、 関連ない部分のコードの整理をパッチに加えてもいけません。
</li>
<li>
Python docstringは <uri link="doc/policies/docstring-spec.xml">
Portage Docstring Specification</uri> に従わなければなりません。
</li>
</ul>
<p>
何らかのバグ報告に関連してパッチを添付するときはtext/plain形式でおねがいします。
そのバグ報告に直接の関連がない(関連があると思えない)場合は、
表題に「[PATCH]」を加えて <c>gentoo-portage-dev</c> メーリングリストにお送りください。
</p>
<note>
sys-apps/portageに無関係なパッケージ用のパッチは
<uri>http://bugs.gentoo.org</uri> に送ります。
どうかgentoo-portage-devメーリングリスト宛てに送らないでください。
</note>
</body>
</section>
<section>
<title>PortageのGITリポジトリにアクセス</title>
<body>
<p>
Portageのソースコードは
<uri link="http://git.overlays.gentoo.org/">git.overlays.gentoo.org</uri>
のGITリポジトリ上で管理運営されています。 開発者用には主要リポジトリが
<uri>git+ssh://git@git.overlays.gentoo.org/proj/portage.git</uri>
にありますが、 厳格なアクセス管理を要するため、
当ページ内の開発者セクションに名前が載っている人だけがコミットできることになっておりますのでお気をつけください。
</p>
<note>
リポジトリの内容は
<uri link="http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=summary">GitWeb</uri>
を通じてご覧になれます。
</note>
<p>
現在リポジトリ内にはつぎのブランチが入っています(抜粋)。
</p>
<p>
</p>
<ul>
<li>master: 現在の主要開発ライン</li>
<li>prefix: 実験的ブランチ。 prefixインストールのサポートつき</li>
<li>2.1.7: 現在の安定版を保守管理するブランチ</li>
</ul>
<note>The old SVN repository still exists, but is not updated anymore or used in any other way.</note>
<note>
XXX古いSVNリポジトリは今も有りますが一切更新が行なわれていないのか他の用途で使われています。
</note>
</body>
</section>
</extrachapter>
</project>
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
<!DOCTYPE project SYSTEM "/dtd/project.dtd">
<project>
<name>Gentoo Portageのツール</name>
<longname>Utilities related to Portage administration</longname>
<date>$Date: 2010/12/19 23:12:19 $</date>
<!-- Original revision: 1.15 -->
<author title="Author"><mail link="genone@gentoo.org">Marius Mauch</mail></author>
<description>
toolsサブプロジェクトはPortageに関連がありながらPortageの中心パッケージに含まれていないツールを扱います。
外部パッケージ用ebuildの管理運営や、
我々独自のユーティリティとスクリプトの開発と改良もその業務に入っています。
</description>
<longdescription><p>
toolsサブプロジェクトはPortageに関連がありながらPortageの中心パッケージに含まれていないツールを扱います。
外部パッケージ用ebuildの管理運営や、
我々独自のユーティリティとスクリプトの開発と改良もその業務に入っています。
</p></longdescription>
<goals>
<p>
このサブプロジェクトはPortageをもっと簡単に使用できる使い易いツール集をGentooユーザーに提供することが主な目標です。
これらツールには設定ユーティリティ(GUI用とコンソール用の両方)や、
ebuildを作成・管理するプログラム、 そして <c>emerge</c>
にできる以上のことをするPortage管理スクリプトが含まれます。
</p>
</goals>
<dev role="Lead" description="gentoolkit">fuzzyray</dev>
<dev role="Member" description="ufed">truedfx</dev>
<dev role="Member" description="gentoolkit-dev">idl0r</dev>
<herd name="tools-portage"/>
<resource link="http://git.overlays.gentoo.org/gitweb/?p=proj/gentoolkit.git;a=summary">Gentoolkit Gitリポジトリ(gitwebで提供)</resource>
<resource link="http://sources.gentoo.org/viewcvs.py/gentoo-src/ufed/">Ufed CVSリポジトリ(viewcvsで提供)</resource>
<!-- START: keep this in sync with portage/index-new.xml -->
<extrachapter position="bottom">
<title>Portageユーティリティへの貢献</title>
<section>
<title>バグ報告</title>
<body>
<p>Please report all bugs you encounter on
<uri link="http://bugs.gentoo.org">our bug tracking system</uri>.
Before opening a new bug report please make sure that the bug has not
already been reported by another user.</p>
<p>バグを見つけたら漏れなく
<uri link="http://bugs.gentoo.org">バグ追跡システム</uri> にご報告ください。
新しいバグ報告を提出するときはその前に必ず同じ内容のバグ報告が他のユーザーから出されていないことを確認しておきましょう。</p>
<impo>
Portage開発プロジェクトやPortageツールサブプロジェクトが出しているapp-portage/下のパッケージ以外の他パッケージに関わるバグ報告や要望を出してはいけません。
</impo>
<p>
バグ報告を書くときはつぎのような状況をはっきりと示しましょう。
</p>
<ul>
<li>バグを発生させたらしいツールはどれか</li>
<li>どんなふうにしてバグが発生したか(実行したコマンドは?、変更したファイルは?)</li>
<li>バグが見つかったときに使用したPortageのバージョンとツールのバージョンは何か</li>
<li>バグは再現可能か</li>
<li><c>emerge --info</c> コマンドの出力</li>
</ul>
<p>提出したバグ報告に反応がすぐになくてもどうかあまりいらいらなさらないでください。
開発担当者が目を通すときまで多少の時間がかかることがあります(これはPortage以外でも同様です)。
バグの解決にとりかかるときになってさらに情報が欲しいと要求することもよくありますので、
そのときはできるだけ早く求められている情報を返答してください。
もし長い時間(1ヶ月以上)が過ぎても返答がないときは、
RESOLVED:NEEDINFOをつけてバグを閉じさせていただく可能性がありますが、
そのあとでもreopenすれば依頼された情報を投稿できます。
<p>
つぎのような状況のどれにもあてはまらない場合はバグをreopenしないでください。
</p>
<ul>
<li>
バグはRESOLVED:FIXEDとなっているのに、
修正が効いたはずの新しいバージョン(一般的にはバグが閉じられた時に処置を受けたバージョン)でも依然として同じバグが起きるとき。
</li>
<li>
バグはRESOLVED:NEEDINFOとなっていて、 要請された情報を提出しようとするとき。
</li>
<li>
バグはRESOLVED:WONTFIX、 RESOLVED:CANTFIX、
RESOLVED:LATERのいずれかとなっていて、 何か誤解があると考えられるとき。
<b>解決の判断に不満がある・同意できないという理由だけでreopenしてはいけません。</b>
</li>
</ul>
<p>
バグが閉じられていても寄せられるコメントには目を通すようにしていますので、
安心してください。 注意を惹こうという理由でreopenする必要はありません。
</p>
<p>
バグ報告はどれもそれぞれが一件の問題を扱います。
どうかこのことを尊重していただき、
そのバグ報告に直接の関係がない他のことを話題に出さないようにしましょう。
</p>
</body>
</section>
<section>
<title>パッチの提出</title>
<body>
<p>
パッチを提出するときは、
必ずパッチがつぎの基準要件を満たすようにしてください。
</p>
<ul>
<li>
タブを使用します。
字下げは人によってスペース8個分の幅が好まれたり4個が好まれたりし、
あるいは2個が好きな人たちも居ます。 タブはよくできたしくみです。
空白文字をならべたりタブと併用したりしてインデントを行なったパッチは拒否も止むを得ません。
</li>
<li>
原則としてファイル丸ごとでなくdiff形式で提出するものとし、
新しくしたファイルよりdiffの方が明らかにかさばる場合や、
未だ存在しないファイルを提出するときにのみファイル丸ごとでも良いこととします。
</li>
<li>Diffs have to be in unified form (<c>diff -u</c>, <c>git diff</c>).</li>
<li>
diffはXXX統一形式でなくてはいけません(<c>diff -u</c> や
<c>git diff</c> で生成できます)。
</li>
<li>
パッチがどんなことをするか詳細な説明を必ず加え、
更に何故その実装を行なったのか(換言すればそのパッチの利点はどこにあるか)の説明を必要に応じて書き添えます。
また、 そのパッチにより欠点や問題発生が想定できるなら付け加えます。
</li>
<li>
パッチの作成に使用した(リリース物の場合は)リリースバージョンもしくは(gitパッチの場合には)リポジトリのリヴィジョンとブランチ名を必ず明示します。
</li>
<li>
<li>
混じり気のないパッチだけを提出します。
提出するパッチに他のパッチを混ぜ込んではいけません。
パッチの説明にそぐわないコードが見つかったときには拒否も止むを得ません。
また、 関連ない部分のコードの整理をパッチに加えてもいけません。
</li>
</ul>
<p>
何らかのバグ報告に関連してパッチを添付するときはtext/plain形式でおねがいします。
そのバグ報告に直接の関連がない(関連があると思えない)場合は、
新たに別の報告にして出してください。
</p>
</body>
</section>
<!-- END: keep this in sync with portage/index-new.xml-->
<section>
<title>Git/CVSリポジトリ</title>
<body>
<p>
All tools that are directly developed by the Portage Tools Project are maintained
in CVS or Git repositories on the Gentoo Git/CVS server. These include:
Portageツールプロジェクトが直接関わって開発されたツールはどれもGentooのGit/CVSサーバー上のリポジトリで保守管理されています。
つぎの場所にあります。
</p>
<ul>
<li>Gentoolkit: <uri>git+ssh://git@git.overlays.gentoo.org/proj/gentoolkit.git</uri></li>
<li>Ufed: <path>cvs.gentoo.org:/var/cvsroot/gentoo-src/ufed</path></li>
</ul>
<p>
これらのリポジトリは現在のところ匿名のアクセスができません。
</p>
</body>
</section>
</extrachapter>
</project>
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
<!DOCTYPE project SYSTEM "/dtd/project.dtd">
<project>
<name>TeX</name>
<author title="Author">
<mail link="aballier@gentoo.org">Alexis Ballier</mail>
</author>
<author title="翻訳">
<mail link="liangtai.s4@gmail.com">島本良太</mail>
</author>
<!-- Original revision: 1.3 -->
<description>
TeXプロジェクトはTex派生物やTeX関係のパッケージのebuildを保守維持しています。
</description>
<longdescription>
<p>
TeXプロジェクトはTex派生物やTeX関係のパッケージのebuildを保守維持しています。
その対象は <c>app-text/texlive</c> と <c>app-text/tetex</c>、
<c>dev-texlive</c> カテゴリのすべて、
および <c>dev-tex</c> のほとんどとその他数箇所です。
</p>
</longdescription>
<herd name="tex" />
<dev role="Member">aballier</dev>
<dev role="Member">dilfridge</dev>
<resource link="texlive-migration-guide.xml">
teTeXもしくはTeX Live 2005からTeX Live 2007に移行する方法。
</resource>
</project>
<?xml version='1.0' encoding='UTF-8'?>
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/kde-config.xml,v 1.35 2009/11/12 22:56:50 nightmorph Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide redirect="/proj/en/desktop/kde/kde4-guide.xml">
<title>The KDE Configuration HOWTO</title>
<author title="Author">
<mail link="swift@gentoo.org">Sven Vermeulen</mail>
</author>
<abstract>
One of the most used desktop environments is KDE. This guide tries to describe
all aspects of KDE, including installation, configuration and usage.
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
<version>2</version>
<date>2008-04-26</date>
<chapter>
<title>Moved</title>
<section>
<body>
<p>
This document was moved to <uri>/proj/en/desktop/kde/kde4-guide.xml</uri>
</p>
</body>
</section>
</chapter>
</guide>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/kde/kde4-guide.xml,v 1.89 2012/03/23 09:18:49 johu Exp $ -->
<guide>
<title>Gentoo KDE ガイド</title>
<author title="Author">
<mail link="tampakrap"/>
</author>
<author title="Author">
<mail link="dilfridge"/>
</author>
<author title="Author">
<mail link="scarabeus"/>
</author>
<author title="Author">
<mail link="jmbsvicetto"/>
</author>
<author title="Author">
<mail link="johu"/>
</author>
<author title="Author">
<mail link="cryos"/>
</author>
<author title="Editor">
<mail link="keytoaster"/>
</author>
<author title="Editor">
<mail link="nightmorph"/>
</author>
<abstract>
このガイドはKDE SCのセットアップの仕方をツリー内のebuildを用いて実演してみせます。
KDEチームのgitオーバーレイ(kde)由来のツールを使うつもりです。
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
<version>3.8</version>
<date>2012-03-23</date>
<!-- Original revision: 1.89 -->
<chapter>
<title>KDE 3</title>
<section>
<title>迅速情報</title>
<body>
<p>
KDE 3はその最後のリリースとなった3.5.10をもって供給元での維持管理が一切行なわれていません。
しかも、
ほとんどのKDE 3用アプリケーションも維持管理が終わってしまい、
KDE 4へ移植済みもしくは移植作業中です。
</p>
<p>
GentooではKDE 3はPortageツリーから削除されており、 ユーザーの維持管理による <uri
link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde-sunset.git;a=summary">kde-sunset</uri>
という名前の(laymanで利用可能な)オーバーレイに移設されています。
このオーバーレイはユーザー有志だけによる運営であり、
現在のKDEチームメンバーにはその内容について何ら責任がないので気をつけましょう。
維持管理の協力に関心のある方なら <mail link="overlays" />
にメールを送りコミットアクセス権を得ませんか。
このオーバーレイに関してバグの報告をする場合、
Gentoo Bugzillaには提出しないでください。 代わりに <uri
link="http://archives.gentoo.org/gentoo-desktop/">gentoo-desktop</uri>
メーリングリストを使います。 読者・投稿者になる方法の説明は <uri
link="http://www.gentoo.org/main/en/lists.xml">こちら</uri> です。
</p>
</body>
</section>
</chapter>
<chapter>
<title>KDE SC 4</title>
<section>
<title>はじめに</title>
<body>
<p>
現在はKDE SC 4が供給元によるサポートを受けられるKDEのバージョンです。
Portageには安定版が1系統あり、1系統(もしくはそれ以上)の非安定版を置くつもりです。
普段どおりなら新しい版は一ヶ月以内に安定化します。
これとは別に、 KDEの供給元は <uri
link="http://quickgit.kde.org">live git source repositories</uri>
を提供しています。
Gentoo KDEチームは <c>kde</c> オーバーレイを通じてsnapshot版とtrunk及び最新ブランチ版のlive ebuildを提供しています。
</p>
<p>
どのKDE SCのバージョンが最もふさわしいか選びましょう。
</p>
<table>
<tr>
<th>KDE SCのバージョン</th>
<th>Repository</th>
</tr>
<tr>
<ti><uri link="#kde4_7">KDE SC 4.7.4</uri></ti>
<ti>Portage</ti>
</tr>
<tr>
<ti><uri link="#kde4_8">KDE SC 4.8.1</uri></ti>
<ti>Portage</ti>
</tr>
<!--tr>
<ti><uri link="#snapshots">KDE SC 4.9スナップショット</uri></ti>
<ti>KDEオーバーレイ</ti>
</tr-->
<tr>
<ti><uri link="#live">Live Ebuilds (4.8 Branch, Trunk)</uri></ti>
<ti>KDEオーバーレイ</ti>
</tr>
</table>
</body>
</section>
</chapter>
<chapter id="prerequisites">
<title>前提条件</title>
<section>
<title>デスクトッププロファイルとサブプロファイル</title>
<body>
<p>
デスクトップのプロファイルはKDE用とGNOME用にサブプロファイルが分離されています。
つまりKDEやGNOMEに固有のUSEフラグが基本のデスクトッププロファイルとは切り離されてサブプロファイルにまとめられているということを意味します。
サブプロファイルを選定しても相応のデスクトップ環境(DE)だけに利用を限定されることにはなりません。
自分にぴったりのプロファイルを選ぶには、
<c>eselect profile list</c> を実行してプロファイルの一覧を出させ、
欲しいものの番号を選んで <c>eselect profile set 番号</c> を実行しましょう。
</p>
</body>
</section>
<section>
<title>USEフラグ</title>
<body>
<p>
KDE SCをインストールする前に数ヶ所のUSEフラグを設定しておくとよいでしょう。
desktop/kdeもしくはdesktopのプロファイルを使用した場合は一部ですがひとりでに設定できています。
USEすべき内訳はつぎのとおりです。
</p>
<table>
<tr>
<th>フラグ</th>
<th>意味</th>
</tr>
<tr>
<ti>consolekit</ti>
<ti>ユーザー、ログインセッション、座席を指定し追跡するconsolekitフレームワークを有効にします。</ti>
</tr>
<tr>
<ti>dbus</ti>
<ti>dbusメッセージバスシステムの利用を有効にします。</ti>
</tr>
<tr>
<ti>policykit</ti>
<ti>システム全域サービス権限制御フレームワーク <b>polkit</b> を有効にします。</ti>
</tr>
<tr>
<ti>udev</ti>
<ti>動的永続的Linuxデバイス命名機構udevのサポートを有効にします。</ti>
</tr>
</table>
<p>
他の組み合わせも技術的には可能かもしれませんが、
サポート外だったり思いがけない機能が使えなくなったりするみたいなので気をつけましょう。
</p>
<p>
広域USEフラグを変更した直後にemergeを実行するときは、
つぎのように-Nフラグをつけてシステムを更新させなくてはいけません。
</p>
<pre caption="USEフラグ変更後の全域更新">
# <i>emerge -uDNav world</i>
</pre>
</body>
</section>
<section>
<title>カーネル設定</title>
<body>
<p>
カーネルに独自のものを走らせているのでしたら新たにつぎのオプションをつけたものをインストールしてみてはいかがでしょうか。
</p>
<pre caption="カーネル推奨設定">
CONFIG_USB_SUSPEND=y
CONFIG_IDE=n
CONFIG_AUDITSYSCALL=y
</pre>
</body>
</section>
</chapter>
<chapter id="kde_portage">
<title>KDE SCをPortageでインストール</title>
<section id="kde4_7">
<title>KDE SC 4.7</title>
<body>
<p>
KDE SC 4.7.4が現在のamd64やppcおよびx86向け安定公開版です。
</p>
<pre caption="メタパッケージを用いたKDE SC 4.7のインストール">
# <i>emerge -av kde-meta</i> <comment>(すべてのKDEモジュールを含める)</comment>
# <i>emerge -av kdebase-meta kdegames-meta</i> <comment>(選ばれたモジュールのみインストールする)</comment>
</pre>
<warn>
KDEPIMを利用していて4.4から4.7に更新する場合は、 まず先に
<uri link="http://wiki.gentoo.org/wiki/KDEPIM-4.7_upgrade">Gentoo Wiki KDEPIM
4.7 Upgrade Guide</uri> をお読みください。
KDEPIMを4.4のまま残しておきたければ
<uri link="kdepim-4.7-mask.txt">KDEPIM 4.7をマスクする</uri> 方法があります。
</warn>
</body>
</section>
<section id="kde4_8">
<title>KDE SC 4.8</title>
<body>
<p>
現在のところKDE SC 4.8.1は~testingつきでPortageに入っていますが、
安定化の予定が近づいています。
</p>
<p>
安定版のシステムも使用している方は <path>/etc/portage/package.keywords</path> に
<uri
link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob_plain;f=Documentation/package.keywords/kde-4.8.keywords">
このキーワードファイル</uri> を入れる必要があります。
</p>
<pre caption="メタパッケージを利用したKDE SC 4.8のインストール">
# <i>emerge -av kde-meta</i> <comment>(すべてのKDEモジュールを含める)</comment>
# <i>emerge -av kdebase-meta kdegames-meta</i> <comment>(選ばれたモジュールのみインストールする)</comment>
</pre>
<warn>
KDEPIMを利用していて4.4から4.8に更新する場合は、 まず先に
<uri link="http://wiki.gentoo.org/wiki/KDEPIM-4.7_upgrade">Gentoo Wiki KDEPIM
4.7 Upgrade Guide</uri> をお読みください。
KDEPIMを4.4のまま残しておきたければ
<uri link="kdepim-4.7-mask.txt">KDEPIM 4.8をマスクする</uri> 方法があります
(このガイドは4.8でも有効です)。
</warn>
</body>
</section>
<chapter id="kde_overlay">
<title>KDE SCをオーバーレイよりインストール</title>
<section id="kde_overlay_prerequisites">
<title>前提条件</title>
<body>
<p>
スナップショット版やlive ebuildをインストールする手段が
<c>kde</c> オーバーレイを経由する方法でだけ提供されていますので、
まずはオーバーレイのインストールからはじめます。
</p>
<pre caption="kdeオーバーレイをインストール">
# <i>layman -f -a kde</i>
<comment>オーバーレイについては <uri
link="http://www.gentoo.org/proj/en/overlays/userguide.xml">Overlay Guide</uri>
が詳しく解説しています。
</comment>
</pre>
<impo>
<c>kde overlay</c> は薄型マニフェストレイアウトを使用します。 このために
<c>sys-apps/portage-2.1.10.18</c> 以降が必須です。
これより古いとマニフェストが見付からないとの理由でエラーになります。
</impo>
</body>
</section>
<section id="snapshots">
<title>KDE SC snapshotsをインストール</title>
<body>
<p>
KDEの供給元はテスト期間に入るとgitリポジトリから取り出した <uri
link="ftp://ftp.kde.org/pub/kde/unstable">snapshots</uri> を提供します。
KDEのベータ版やリリース候補版はつぎのようなsnapshotモデルに従っています。
</p>
<table>
<tr>
<th>KDE SCのバージョン</th>
<th>リリース名</th>
</tr>
<tr>
<ti>4.x.80</ti>
<ti>Beta 1</ti>
</tr>
<tr>
<ti>4.x.85</ti>
<ti>Beta 2</ti>
</tr>
<tr>
<ti>4.x.90</ti>
<ti>Release Candidate 1</ti>
</tr>
<tr>
<ti>4.x.95</ti>
<ti>Release Candidate 2</ti>
</tr>
</table>
<note>
利用できるsnapshotは現在ありません。
</note>
<!--最初のKDE SC4.9スナップショットがオーバーレイから利用できるようになった時点でこの段を明かす-->
<!--p>
安定版システムのユーザーは手掛けたいパッケージにkeywordを適用する必要があります。
<c>kde</c> オーバーレイ内にてpackage.keywordファイルを提供しております。
被マスク化してある依存関係のため、
KDE SC 4.8.80もマスクがかけられているはずです。
このファイルからシンボリックリンクを張らなくてはなりません。
</p>
<pre caption="keywordファイルのシンボリックリンクを作成">
# <i>ln -s /path/to/overlay/kde/Documentation/package.keywords/kde-4.9.keywords /etc/portage/package.keywords/</i>
# <i>ln -s /path/to/overlay/kde/Documentation/package.unmask/kde-4.9 /etc/portage/package.unmask/</i>
</pre>
<p>
メタパッケージとsetのいずれを用いてもインストールができます。
</p>
<pre caption="メタパッケージを利用したインストール">
# <i>emerge -av kde-meta</i> <comment>(すべてのKDEモジュールを含める)</comment>
# <i>emerge -av kdebase-meta kdegames-meta</i> <comment>(選ばれたモジュールのみインストールする)</comment>
</pre>
<pre caption="setを利用したインストール">
<comment>(KDE SC 4.9スナップショット版の場合)</comment>
# <i>emerge -av @kde-4.9</i> <comment>(すべてのKDEモジュールを含める)</comment>
# <i>emerge -av @kdebase-4.9 @kdegames-4.9</i> <comment>(選ばれたモジュールのみインストールする)</comment>
</pre-->
</body>
</section>
<section id="live">
<title>KDE SC live ebuildのインストール</title>
<body>
<p>
KDE SCはオープンソースになっており、 ソースコードが <uri
link="http://quickgit.kde.org">KDE QuickGit</uri> で閲覧できるうえ、
だれでもチェックアウトして入手できます。
Gentooはソースベースのディストリビューションなので、
live ebuidがソースで提供されており、
最新のブランチもしくはtrunkよりチェックアウトできます。 現時点では、
4.8ブランチを4.8.49.9999のebuildで提供し、 trunkを9999のebuildで提供しています。
</p>
<table>
<tr>
<th>ebuildのバージョン</th>
<th>KDE SCのバージョン</th>
</tr>
<tr>
<ti>4.8.49.9999</ti>
<ti>KDE 4.8 Branch</ti>
</tr>
<tr>
<ti>9999</ti>
<ti>KDE 4 Trunk</ti>
</tr>
</table>
<p>
安定版システムのユーザーは手掛けたいパッケージにkeywordを適用する必要があります。
<c>kde</c> オーバーレイ内にてpackage.keywordファイルを提供しておりますので、
このpackage.keywordへ直接シンボリックリンクを張らなくてはなりません。
</p>
<pre caption="keywordファイルのシンボリックリンクを作成">
# <i>cd /etc/portage/package.keywords</i>
# <i>ln -s /path/to/overlay/kde/Documentation/package.keywords/kde-4.8.49.9999.keywords .</i><comment>(4.8ブランチの場合)</comment>
# <i>ln -s /path/to/overlay/kde/Documentation/package.keywords/kde-live.keywords .</i><comment>(KDE trunkの場合)</comment>
</pre>
<p>
メタパッケージとsetのいずれを用いてもインストールができます。
</p>
<pre caption="メタパッケージを利用したインストール">
# <i>emerge -av kde-meta</i> <comment>(すべてのKDEモジュールを含める)</comment>
# <i>emerge -av kdebase-meta kdegames-meta</i> <comment>(選ばれたモジュールのみインストールする)</comment>
</pre>
<pre caption="setを利用したインストール">
<comment>(KDE SC 4.8 ブランチの場合)</comment>
# <i>emerge -av @kde-4.8</i> <comment>(すべてのKDEモジュールを含める)</comment>
# <i>emerge -av @kdebase-4.8 @kdegames-4.8</i> <comment>(選ばれたモジュールのみインストールする)</comment>
<comment>(KDE SC trunkの場合)</comment>
# <i>emerge -av @kde-live</i> <comment>(すべてのKDEモジュールを含める)</comment>
# <i>emerge -av @kdebase-live @kdegames-live</i> <comment>(選ばれたモジュールのみインストールする)</comment>
<comment>詳しくは <uri link="#sets">setの利用</uri> の節をご覧ください。</comment>
</pre>
</body>
</section>
</chapter>
<chapter>
<title>追加インストールと削除についての情報</title>
<section id="sets">
<title>setの利用</title>
<body>
<p>
Portageの新機能のうち、 2.2より提供が始まったのがsetです。
</p>
<p>
Sets allow the KDE team to provide a complete replacement for the monolithic
packages, with the added bonus that users may choose to remove from the default
sets any packages they do not want. There is still some discussion going on
before we can put sets in the Portage tree. Thus, grab the sets from the
<c>kde</c> overlay <uri
link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=tree;f=sets">sets
directory</uri> or grab them as a <uri
link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=snapshot;h=5b2fc54fa5d1c8aeddaeb05f044bf28754bb18be;sf=tbz2">
tar.bz2 archive</uri> and put the ones you like in <path>/etc/portage/sets</path> --
you can browse the list of sets provided by the KDE team in the overlay
by using the first link.
setが実現したおかげでKDEチームはこれまでの一体化パッケージに依らない完全な代替パッケージ集を提供できたうえ、
ユーザーにとってもデフォルトのsetから欲しくないパッケージを任意に選んで撤去できる特典が得られました。
XXX現在もなおPortageツリーにsetを導入できる以前の議論が続いています。
したがって、 <c>kde</c> オーバーレイ上の <uri
link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=tree;f=sets">setのディレクトリ</uri>
から取ってくるか、 もしくは <uri
link="http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=snapshot;h=5b2fc54fa5d1c8aeddaeb05f044bf28754bb18be;sf=tbz2">
tar.bz2 形式の圧縮書庫</uri> でsetをまとめて得てから、
<path>/etc/portage/sets</path> 内に欲しいものを置きます。
</p>
<note>
kdeオーバーレイを利用している場合は <path>/etc/portage/sets</path>
のコピーを置く方法をとらずとも直にsetが使えます。
</note>
<p>
とりわけなかでも個々のKDE tarballに準じたsetが、 @kdeaccessibility、
@kdeadmin、 @kdeartwork、 @kdebase、 @kdeedu、 @kdegames、 @kdegraphics、
@kdemultimedia、 @kdenetwork、 @kdepim、 @kdesdk、 @kdetoys、 @kdeutils
のそれぞれあります。
またsetのsetたる@kdeや、 バージョンを特定した@kde-3.5や@kde-4xが
(かつてのkde-metaパッケージと同じように)用意されているほか、
KDEが依拠する@kdedepsや任意追加パッケージ@kdeoptional、
Qtの細分化パッケージをまとめた@qt-splitもあります。
</p>
<p>
<c>emerge -av @kde</c> すればKDEを全部完全にインストールできます。
一方でバージョンの特定に相当することを <c>emerge -C @kde-3.5</c>
のように実行すれば旧いバージョンをアンインストールできますし、
特定のバージョンのすべてのパッケージを <c>emerge -av1 @kde-4x</c>
のようにして再インストールもできるのでたいへん便利です。
不要なパッケージをsetから除外するような、
高度な機能も今後のPortageリリースでサポートされる予定です。
この件に関しては <uri
link="http://blogs.gentoo.org/genone/2008/09/29/more_extensions_to_package_set_support">Marius
Mauch (genone)のブログ</uri> がもっといろいろ書いています。
このコードは一部がportage-2.2_rc12よりリリースされていますので、
set内のインストール済みのパッケージは <c>emerge -av @&lt;set&gt;/@installed</c>
を実行するかあるいは <path>/etc/portage/sets/kdebase-unwanted</path>
を設定しておいてから <c>emerge -av @kdebase-@kdebase-unwanted</c>
を実行すれば再インストールできます。
<p>
<c>kdebase</c> はすべてのKDE 4セッションを実現するためにインストールしておくことを強くおすすめします。
下記の例は <c>kdebase</c> setと <c>kdegames</c> setをインストールします。
</p>
<pre caption="KDE SCをインストール">
# <i>emerge @kdebase @kdegames</i>
</pre>
<note>
Portageでわかっている範囲のsetのリストは <c>emerge --list-sets</c>
とすれば確かめられます。
</note>
<note>
KDE 4.6以上のebuildはすべて新しいEAPI 4の仕様を使うため、
これらをすべて実装している <c>portage-2.1.9.27</c> かそれ以降が必要です。
(setを利用したいときは <c>>=sys-apps/portage-2.2_alpha11</c> が必要です。)
</note>
</body>
</section>
<section id="cleanup">
<title>KDEの浄化</title>
<body>
<p>
問題の発生を最小限に抑えるためにはビルド環境を一掃しておくのが最良の策です。
つぎのような場合に推奨されています。
</p>
<ul>
<li><c>+kdeprefix</c> を <c>-kdeprefix</c> に切り替えた(もしくはその逆の)とき</li>
<li>
KDEを旧版に戻したとき(例:snapshots版やlive版のebuildをPortage版に変更)
</li>
<li>KDE 3からKDE 4に全部更新(もしくは逆戻り)したとき</li>
<li>古いオーバーレイから切り替えたとき</li>
</ul>
<p>
この場合にインストールしていた古いKDEを完全に削除するにはつぎのような方法があります。
</p>
<pre caption="unmergeするコマンド">
# <i>emerge -ac kde-base/kdelibs $(qlist -IC 'kde-base/*') \
$(for name in $(qlist -IC|grep -v '^kde-base/') ; do ( qdepends -C $name | grep -q kdelibs ) &amp;&amp; echo $name ; done)</i>
</pre>
<p>
この方法はkdeのみならずそれに依存している他のパッケージ(例えばlibreoffice[kde])も一緒に削除しますので注意しましょう。
</p>
<p>
Portage 2.2を使用している場合はつぎの方法でもできます。
</p>
<pre caption="setを利用してunmergeするコマンド(portage-2.2)">
# <i>emerge -C @kde-4.X @kdebase-4.X @kde-3.5</i> <comment>(よくあるset名を使った場合)</comment>
</pre>
<p>
古いオーバーレイはKDEのebuildと衝突を起こすことのないよう最後の仕上げに残らず削除しておきましょう。
古いunmaskやkeywordのデータも削除しておかなくてはいけません。
</p>
<note>
依存がなくなり不要となった他のパッケージを <c>emerge --depclean</c>
でアンインストールするのをお忘れなく。
</note>
</body>
</section>
<section>
<title>地域化/国際化</title>
<body>
<p>
KDEが新しくなったのに伴い翻訳者の成果は国際化(i18n)でなく地域化(l10n)で得られます。
ちょっと混乱しそうですが気にしないでください。 ただの名称変更ですから。
</p>
<pre caption="翻訳を手に入れる">
<comment>KDE 4とKOffice 2用:</comment>
# <i>emerge kde-l10n</i>
# <i>emerge koffice-l10n</i>
</pre>
</body>
</section>
<section>
<title>3.5の設定を4.Xに移植</title>
<body>
<p>
KDEはデフォルトで <path>~/.kde</path> 以下に設定ファイルを保管します。
GentooのebuildはここをKDE 4.Xで変更して、
同一アカウントでKDE 3.5とKDE 4.Xがよりよく同居できるようにしました。
$KDEHOMEをexportすると、 このしくみに上書きが発生します。
絶対にしないようお願いします。
$KDEHOMEのせいでKDE 3.5とKDE 4.Xが同じ設定ディレクトリを使用してしまい、
通常は望ましくない事態になります。
</p>
<p>
KDE 3.5 uses <path>~/.kde</path> and the default FHS (<c>-kdeprefix</c>) KDE 4.X
uses <e>~/.kde4</e>.
XXXKDE 3.5は <path>~/.kde</path> とデフォルトのFHS(<c>-kdeprefix</c>)を使用し、
KDE 4.Xは <path>~/.kde4</path> を使用します。
</p>
<p>
設定がデフォルトで移植されることはありません。
設定を移植しようとするならログインする前に古い設定ディレクトリを新しい場所にコピーしなくてはいけないでしょう。
例えば、
</p>
<pre caption="設定ディレクトリをコピー">
$ <i>cp -r ~/.kde ~/.kde4</i>
</pre>
<p>
これでうまくいけば設定がすべて移植できたことになります。
だめなときはログアウトしてから新しく作った設定ディレクトリを削除してまっさらな設定ディレクトリからやりなおせばよいのです。
</p>
<impo>
4.Xから3.5へバージョンを後戻りすることはサポート外です。
</impo>
</body>
</section>
</chapter>
<chapter>
<title>ヒント集と問題解決例</title>
<section>
<title>"KResource Migration Tool"の出現を回避</title>
<body>
<p>
ログインするたびに「KResource Migration Tool」というウィンドウが出てくるというバグ報告が来ています。
適切な解決法はまだ見付かっていませんが、 <uri
link="https://bugs.gentoo.org/353200">bug 353200</uri>
には回避方法が載っています。
</p>
</body>
</section>
<section>
<title>アプリケーション用のデータベースを再構築</title>
<body>
<p>
KMenu内のアプリケーションの全部もしくはどれかがなくなると、
おそらくKDEアプリケーションデータベースを再構築させる必要が出てくるはずです。
つぎの処置はアイコンがなくなったときもふくめKMenuに関する問題を何でも解決する方法のひとつです。
</p>
<pre caption="kbuildsycocaのコマンド">
# <i>kbuildsycoca4 --noincremental</i>
</pre>
</body>
</section>
<section>
<title>GTKのアプリケーションの外観をQt4風にする</title>
<body>
<p>
外観が両ツールキット(GTK/GnomeとQt/KDE)で共通しているテーマは2種類あります。
QtCurveは <c>gtk-engines-qtcurve</c> と <c>x11-themes/qtcurve-qt4</c>
の両パッケージで提供されています。 OxygenはKDE 4.xの一部なのですが、
GTKにも同等品が <c>x11-themes/oxygen-gtk</c> のパッケージで提供されています。
KDEのテーマは「KDE システム設定」の「外観」ページの「スタイル」タブ内で調整できます。
「KDE システム設定」からGTKアプリケーションのテーマを調整するには、
<c>kde-misc/kcm-gtk-config</c> をインストールしましょう。
これで「外観」ページに新たに「GTK+ スタイル」タブが現れます。
<!-- 原文は "Gtk Config" だがおそらく kdebase/desktop_kde-workspace.po の "GTK+ Style" のこと -->
</p>
</body>
</section>
<section>
<title>AkonadiがMySQLの設定に関して文句を言う</title>
<body>
<p>
まずは <path>/usr/share/config</path> と <path>usr/share/kde4</path>
のパーミッションを調べます。 いずれも700だったら再帰的に755へ変更します。
</p>
<pre caption="/usr/share/configのパーミッションを更新">
# <i>chmod -R 755 /usr/share/{config,kde4}</i>
</pre>
<p>
これでも問題が解決しないときはakonadiの設定を呼び出しデフォルトのmysql設定を変更しなくてはなりません。
トレイを実行していなければ <c>akonaditray</c> をスタートさせ、
「Akonadi サーバの設定」を選んで「組み込み MysQL サーバを使う」を有効にしてからテストボタンを押します。
組み込みの実行プログラムではなくmysqlサーバーの方を使いたいときは、
mysqlが常駐しているかどうか確かめる必要があるでしょう。
</p>
</body>
</section>
<section>
<title>起動時にKDEをスタートさせる</title>
<body>
<p>
コンピュータを起動したときにKDEをスタートさせる方法は2通りあります。
簡単なのはKDMを利用する方法で、 これは <c>kde-base/kdm</c> にあります。
はじめに設定ファイルXorgを編集してDISPLAYMANAGERをkdmに定義します。
</p>
<pre caption="/etc/conf.d/xdmを編集">
# What display manager do you use ? [ xdm | gdm | kdm | kdm-4.3 | gpe | entran$
# NOTE: If this is set in /etc/rc.conf, that setting will override this one.
#
# KDE-specific note:
# - If you are using kdeprefix go with "kdm-4.Y", e.g. "kdm-4.3".
# You can find possible versions by looking at the directories in /usr/kde/.
# - Else, if you are using KDE 3 enter "kdm-3.5"
# - Else, if you are using KDE 4 enter "kdm" without a version
DISPLAYMANAGER="kdm"
</pre>
<p>
そのつぎにxdmをデフォルトのrunlevelに加えます。
</p>
<pre caption="xdmをデフォルトのrunlevelに追加">
# <i>rc-update add xdm default</i>
</pre>
</body>
</section>
<section>
<title>おすすめのフォント</title>
<body>
<p>
クリックしてメニューを見たら文字が全然判別できないというときは、
フォントをいくばくかインストールする必要があります。
普通に選ぶなら <c>media-fonts/corefonts</c>、
<c>media-fonts/ttf-bitstream-vera</c>、 <c>media-fonts/dejavu</c>
あたりはいかがでしょう。
</p>
</body>
</section>
<section>
<title>KDMが起動に失敗する</title>
<body>
<p>
まずは <path>/usr/share/config</path> のパーミッションを確かめましょう。
ここが700になっていたら755に変更します。 この前の節も調べます。
それでもエラーを解決できないときは、 kdmのebuildでつぎの留意点を調べましょう。
</p>
<pre caption="kdm notice">
If when you restart xdm, kdm fails to start with a message like "gentoo kdm[2116]: X
server startup timeout, terminating" in /var/log/messages, uncomment the ServerTimeout
line in "grep kdmrc /var/db/pkg/kde-base/kdm-4.3.1/CONTENTS | cut -f2 -d " ""
and be sure to increase the timeout - 60 should work
(日本語訳:
xdmを再起動したとき、 kdmが起動に失敗して
「gentoo kdm[2116]: X server startup timeout, terminating」
のようなメッセージを /var/log/messages に残すようであれば、
「grep kdmrc /var/db/pkg/kde-base/kdm-4.3.1/CONTENTS | cut -f2 -d " "」
のファイルでコメント化されているServerTimeout行のコメントを外し、
もれなくtimeout時間を増やしましょう。 60程度でいけます。)
</pre>
<p>
それと、 つぎのサービスが起動しているか確かめましょう。
</p>
<pre caption="サービスを調べて起動">
# <i>/etc/init.d/dbus status</i>
# <i>/etc/init.d/consolekit status</i>
</pre>
<p>
作動していないときは <c>status</c> を <c>start</c> に替えて有効化しておき、
それぞれに <c>rc-update add dbus default</c>
のようなコマンドを実行してデフォルトのrunlevelに加えます。
</p>
<p>
そして最後に、 KDMが <path>/etc/X11/xorg.conf</path>
のエラーで失敗するようであれば、 ログを見てみましょう。
<path>/var/log/Xorg.0.log</path> と <path>/var/log/kdm.log</path> を見て、
適当に <path>xorg.conf</path> を直します。 まだ他に助けが必要ならば、
IRC上(Freenodeの#gentoo-kde)で私たちを探しましょう。
</p>
</body>
</section>
<section>
<title>電源アプレットやsolid通知機能が肝心の情報を表示しない</title>
<body>
<p>
電源アプレットなどのsolid通知機能が相応の情報を表示できるようにするため、
dbusとconsolekitを作動させるが必要があります。
</p>
<pre caption="dbusとconsolekitを調べて起動">
# <i>/etc/init.d/dbus status</i>
# <i>/etc/init.d/dbus start</i>
# <i>/etc/init.d/consolekit status</i>
# <i>/etc/init.d/consolekit start</i>
</pre>
</body>
</section>
<section>
<title>二重休眠もしくは休眠後のクラッシュ (bug 363363)</title>
<body>
<p>
KDE 4.6は自力でsleepボタンの処理ができシステムを正常に休眠(ハイバネート)状態に移行できます。
このイベントを扱える(例えばacpidのような)他のプログラムを手作業セットアップで入れてある場合は無効化してください。
さもないと二重に休眠させたりシステムを不安定にするおそれがあります。
</p>
</body>
</section>
<section>
<title>コンピューター停止、 再起動、 ログアウトが効かない (bug 326393)</title>
<body>
<p>
おかしな相互作用が音声システムとログアウト機構の間で進行しています。
システム設定ダイアログを開き、 ログアウト用のサウンドを取り消しましょう。
その後はちゃんとログアウトできるようです。
</p>
</body>
</section>
<section>
<title>デスクトップ背景がすべてのウィンドウを覆い隠す (bug 365623)</title>
<body>
<p>
何枚かのスクリーンを使った作業のあとで稀にデスクトップ設定が正常に消去できていないときがあります。
結果としてデスクトップの背景がすべてのウィンドウを覆い尽くすようなことになります。
より詳しい事情と手作業で対処する方法が
<uri link="https://bugs.kde.org/show_bug.cgi?id=260360">このKDEバグ報告</uri>
に載っています。
</p>
</body>
</section>
<section>
<title>ログインできない、 スプラッシュスクリーンで固まる (bug 365637)</title>
<body>
<p>
不安定版のGNOME系プログラムを入れていると、 (naughtyだけに!)
使用中にひどくわけがわからない非互換性に遭遇するかもしれません。
net-libs/glib-networkingをインストールするとたちまちKDEログインが失敗します。
このパッケージはunmergeしましょう。 すぐによくなるはずです。
</p>
</body>
</section>
</chapter>
<chapter>
<title>過去記事</title>
<section>
<title>KDE SC 4.4を4.6に更新</title>
<body>
<p>
KDE <b>4.6.3</b> は現在安定しています。 更新作業中に何らかの問題が発生した場合は、
まず先に <uri link="kde44-46-upgrade.xml">Gentoo KDE 4.4 - 4.6 Upgrade Guide</uri>
(日本語版 <uri link="proj/ja/desktop/kde/kde44-46-upgrade.xml">Gentoo KDE 4.4→4.6更新ガイド</uri>)
をお読みください。
</p>
</body>
</section>
</chapter>
</guide>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/desktop/kde/kde44-46-upgrade.xml,v 1.17 2011/08/12 20:07:56 dilfridge Exp $ -->
<guide>
<title>Gentoo KDE 4.4→4.6更新ガイド</title>
<author title="Author">
<mail link="dilfridge"/>
</author>
<author title="Author">
<mail link="tampakrap" />
</author>
<author title="Author">
<mail link="ssuominen" />
</author>
<abstract>
このページではKDE SC 4.4からKDE SC 4.6へ滞りなき更新をさらに順調にするためのヒントを提供します。
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
<version>0.1</version>
<date>2011-04-09</date>
<!-- Original revision: 1.17 -->
<chapter>
<title>はじめに</title>
<section>
<title>更新について</title>
<body>
<p>
安定版KDEをKDE SC 4.4.5からKDE SC 4.6.2に更新するときメジャーリリース番号が丸ごと飛び級で上がります。
普通にいけば機能のいくつかは両パッケージを通じて継続し、 あるいは置き換えられ、
あるいは廃止されます。 全体的にみれば更新作業はたいへん順調に進むはずです。
このページがまとめた技や秘策は、
稀に起こるうまくいかない事態に応じるためにあります。
</p>
</body>
</section>
</chapter>
<chapter>
<title>更新前と更新開始時</title>
<section>
<title>Amarokの失態(bug 365719)</title>
<body>
<p>
Amarokをご利用でしたらご注意。
更新時にプレイリストの統計値をよくもまあ全部削除してしまうというバグがみつかっています。
対処方法はただひとつ、 <b>更新の前に</b>
Amarokデータベースのバックアップをとっておいて、
手作業である程度無様なやりくりをしてゆくという方法だけです。 詳しくは <uri
link="https://bugs.gentoo.org/show_bug.cgi?id=365719">バグ報告</uri> と <uri
link="http://forum.kde.org/viewtopic.php?f=116&amp;t=94868&amp;p=195086">KDEフォーラムの投稿</uri>
で得てください。
</p>
</body>
</section>
<section>
<title>設定すべきUSEフラグ</title>
<body>
<p>
Before you upgrade your system it is recommended that you set/unset several useflags.
Part of that is done automatically if you use a desktop/kde or desktop profile.
In detail you should use:
システムを更新する前に数カ所のuseflagの設定をお勧めします。
設定の一部は自動的に、
XXXdesktop/kdeかdesktopのプロファイルを使用すれば決定されます。
</p>
<table>
<tr>
<th>フラグ</th>
<th>説明</th>
</tr>
<tr>
<ti>consolekit</ti>
<ti>ユーザー、 ログインセッション、
座席を設定し追跡するconsolekitフレームワークを有効にします</ti>
</tr>
<tr>
<ti>dbus</ti>
<ti>dbusメッセージバスシステムを有効にします</ti>
</tr>
<tr>
<ti>policykit</ti>
<ti>システム全般のサービスの特権を管理する <b>polkit</c>
フレームワークを有効にします</ti>
</tr>
<tr>
<ti>udev</ti>
<ti>Linuxで動的・持続的デバイス命名を行なうudevのサポートを有効にします</ti>
</tr>
<tr>
<ti>-hal</ti>
<ti>ハードウェアアクセスを行なうsys-apps/halの使用を止めます</ti>
</tr>
</table>
<p>
これ以外の組み合せも技術的には可能ですが、
サポート外だったりテストができていなかったり、
あるいは予想外の機能損失が起こるかもしれないので気をつけましょう。
</p>
<p>
If you changed any global useflags, you should later include the -N flag when running the actual emerge command
which updates your system, e.g.
グローバル照準なuseフラグを変更したあとにemergeコマンドでシステムを更新させるときは、
つぎのように必ず-Nフラグをつけましょう。
</p>
<pre caption="useフラグ変更後のworld更新">
# <i>emerge -uDNav world</i>
</pre>
</body>
</section>
<section>
<title>更新の前に選択から除外もしくはunmergeすべきパッケージ</title>
<body>
<p>
KDEはkde-baseに含まれていないパッケージも特定のサービスのために利用します。
例えばKDE SC 4.4ではbluetooth統合をnet-wireless/kbluetoothで提供しています。
KDE SC 4.6は新しいbluetoothシステムをnet-wireless/bluedevilで提供しており、
kbluetoothとbluedevilは両方一緒に同一システム内にインストールができません。
通常はPortageが自動的にこれを解決するはずです。
しかしworldファイルにnet-wireless/kbluetoothを入れておくと、
そのunmergeをportageが拒否してしまい更新がすべて止められてしまいます。
こんなときはつぎのコマンドを実行する必要があります。
</p>
<pre caption="worldファイルから(例として)net-wireless/kbluetoothを削除">
# <i>emerge --deselect net-wireless/kbluetooth</i>
</pre>
<p>
そのあとはPortageがもっとうまく更新作業を解決するはずです。
こうした事情のあるパッケージはつぎのとおり。
</p>
<table>
<tr>
<th>KDE 4.4が利用していたパッケージ</th>
<th>変更後のパッケージ</th>
<th>註</th>
</tr>
<tr>
<ti>net-wireless/kbluetooth</ti>
<ti>net-wireless/bluedevil</ti>
<ti>useフラグにbluetoothがあるとき引き入れ</ti>
</tr>
<tr>
<ti>kde-misc/filelight</ti>
<ti>kde-base/filelight</ti>
<ti>現在はKDEの主要配布物内に含まれる</ti>
</tr>
</table>
</body>
</section>
</chapter>
<chapter>
<title>更新の後にしておきたいこと</title>
<section>
<title>更新の後に削除すべきパッケージ</title>
<body>
<p>
KDE SC 4.6は今後一切HALに依存しません。 HALは非推奨となっており、
ハードウェアにアクセスする新しいメカニズムにとっては妨げになるため、
更新が終わったら削除しなくてはいけません。 HALデーモンを停止して、 unmergeし、
それでとうとう時代遅れとなってしまったdevicekitとpolicykit(どちらのパッケージも削除済みならもちろん結構です)もunmergeします。
</p>
<pre caption="HALなどを停止しunmergeする">
# <i>/etc/init.d/hald stop</i>
# <i>emerge -cav hal hal-info policykit devicekit devicekit-disks devicekit-power</i>
</pre>
<p>
ちなみにここで削除した <b>policykit</b> は古い名前です。
その後継は <b>polkit</b> なので気をつけましょう。
通常この変化は透過的に行なわれます(useフラグの名前は <b>policykit</b>
のままなので間違えないようにしましょう)。
</p>
<p>
この時点でもしメッセージが出てきて、
何らかのパッケージが依然としてhalを必要とするためunmergeできないということであれば、
今もhalを要求しているパッケージが厳密にはどれか確かめてください。
それらのパッケージにとってバグだとみなせることですし、
halはまもなくだめになるのですから、
バグ報告に出して直してもらわなくてはいけません。
残りのHALが必要だというパッケージをunmergeするか、
一切halに依存しないテスト版への更新をご検討ください。
</p>
<p>
最後に、
halの撤去がちゃんとできたらinitスクリプトもデフォルトのrunlevelから削除できます。
</p>
<pre caption="runlevelからhalデーモンのinitスクリプトを削除">
# <i>rc-update del hald</i>
</pre>
<p>
何があっても金輪際halが蘇えることのないよう、
package.maskファイルにつぎのような項目を追加するのも良いでしょう。
</p>
<pre caption="/etc/portage/package.mask">
sys-apps/hal
</pre>
<p>
このほか、 consolekitやdbusのサポートの追加が今からだったときはこれらをデフォルトのrunlevelに追加してはいかがでしょう。
</p>
<pre caption="consolekitとdbusのinitスクリプトをデフォルトのrulevelに追加">
# <i>rc-update add dbus default</i>
# <i>rc-update add consolekit default</i>
</pre>
<p>
XXXご自分のカーネルを転がしている場合はつぎのようなオプションをつけた新しいカーネルをインストールしたくなってきます。
</p>
<pre caption="推奨されているカーネル設定">
CONFIG_USB_SUSPEND=y
CONFIG_IDE=n
CONFIG_AUDITSYSCALL=y
</pre>
<p>
CONFIG_USB_SUSPEND=yとCONFIG_IDE=nはsys-fs/udisksに必要な設定です。
前者がUSBポートに差し込まれるデバイスの電源管理を有効にし、
後者は古い非推奨なサポート外のIDEドライバーを無効にします。
CONFIG_AUDITSYSCALL=yはsys-auth/consilekitがその一部の機能のために要ります。
</p>
<p>
もうリブートしようという場面かもしれませんね(そうするとhalの残りが削除され、
新しいカーネルが使われ、 consolekitが起動するなどします)。
</p>
</body>
</section>
<section>
<title>更新すべきパッケージ</title>
<body>
<p>
KDE SC 4.4用に開発されたいくつかのアプリケーションがKDE SC 4.6では二度と正しくコンパイルできません。
ほかにも、 版が新しくなったアプリケーションがKDE SC 4.6をその機能用に要求し、
しかもKDE SC 4.4上ではビルドが一切できなくなってしまうかもしれません。
こうした事態に誰も陥ることのないよう、
新しい版のものをKDE SC 4.6で安定化させるべく取り組んでおります。 念のため、
下記に比較用の関連情報を挙げておきます。
</p>
<table>
<tr>
<th>パッケージ名</th>
<th>KDE 4.4対応最終バージョン</th>
<th>KDE 4.6対応最初期バージョン</th>
</tr>
<tr>
<ti>media-gfx/digikam</ti>
<ti>1.2</ti>
<ti></ti>
</tr>
<tr>
<ti>media-plugins/kipi-plugins</ti>
<ti>1.2</ti>
<ti></ti>
</tr>
<tr>
<ti>app-office/koffice-libs</ti>
<ti>2.2.2</ti>
<ti>2.3.2</ti>
</tr>
</table>
</body>
</section>
</chapter>
<chapter>
<title>更新完了後に想定されうる問題</title>
<section>
<title>"KResource Migration Tool"の出現を回避</title>
<body>
<p>
ログインするたびに「KResource Migration Tool」というウィンドウが出てくるというバグ報告が来ています。
適切な解決法はまだ見付かっていませんが、 <uri
link="https://bugs.gentoo.org/353200">bug 353200</uri>
には回避方法が載っています。
</p>
</p>
</body>
</section>
<section>
<title>アプリケーション用のデータベースを再構築</title>
<body>
<p>
KMenu内のアプリケーションが全部もしくはどれかがなくなると、
おそらくKDEアプリケーションデータベースを再構築させる必要が出てくるはずです。
それもアイコンがなくなったときもふくめKMenuに関するあらゆる問題を解決できそうな処置です。
問題が起きたユーザーアカウントでつぎのコマンドを実行しましょう。
</p>
<pre caption="kbuildsycocaのコマンド">
$ <i>kbuildsycoca4 --noincremental</i>
</pre>
</body>
</section>
<section>
<title>二重休眠もしくは休眠後のクラッシュ(bug 363363)</title>
<body>
<p>
KDE 4.6は自力でsleepボタンの処理ができシステムを正常に休眠(ハイバネート)状態に移行できます。
このイベントを扱える(例えばacpidのような)他のプログラムを手作業セットアップで入れてある場合は無効化してください。
さもないと二重の休眠やシステム不安定化を招きかねません。
</p>
</body>
</section>
<section>
<title>シャットダウン、 リブート、 ログアウトが効かない(bug 326393)</title>
<body>
<p>
おかしな相互作用が音声システムとログアウト機構の間で進行しています。
システム設定ダイアログを開き、 ログアウト用のサウンドを取り消しましょう。
その後はちゃんとログアウトできるようです。
</p>
</body>
</section>
<section>
<title>デスクトップ背景がすべてのウィンドウを覆い尽くす(bug 365623)</title>
<body>
<p>
何枚かのスクリーンを使った作業のあとで稀にデスクトップ設定が正常に消去できていないときがあります。
結果としてデスクトップの背景がすべてのウィンドウを覆い尽くすようなことになります。
より詳しい事情と手作業で対処する方法が
<uri link="https://bugs.kde.org/show_bug.cgi?id=260360">このKDEバグ報告</uri>
に載っています。
</p>
</body>
</section>
<section>
<title>ログインできない、 スプラッシュスクリーンで固まる(bug 365637)</title>
<body>
<p>
不安定版のGNOME系プログラムを入れていると、 (naughtyだけに!)
使用中にひどくわけがわからない非互換性に遭遇するかもしれません。
net-libs/glib-networkingをインストールするとあっというまにKDEログインが失敗します。
このパッケージはunmergeしましょう。 すぐによくなるはずです。
</p>
</body>
</section>
</chapter>
</guide>
<?xml version='1.0' encoding="UTF-8"?>
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/portage/doc/manually-fixing-portage.xml,v 1.24 2012/03/18 19:50:08 zmedico Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd" [
<!ENTITY stable_version "2.1.10.49">
]>
<guide link="/proj/ja/portage/doc/manually-fixing-portage.xml">
<title>インストールしたあと壊れてしまったPortageを手作業で修復</title>
<author>
<mail link="genone@gentoo.org">Marius Mauch</mail>
</author>
<abstract>
この文書の目標はインストール状態が壊れたsys-apps/portageを手作業で直そうとするときに役立つことです。
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
<version>0.3</version>
<date>2007-05-31</date>
<!-- Original revision: 1.24 -->
<chapter>
<title>Portageの手作業修復</title>
<section>
<title>目的</title>
<body>
<p>
This section will tell you how to manually update/fix your portage installation
in case you can't run <c>emerge sys-apps/portage</c>. While not hard it is
still to be done with great care, so please follow the listed steps exactly
(but apply common sense when necessary).
この節では、 <c>emerge sys-apps/portage</c> が実行不可能となった場合を想定し、
Portageのインストール状態を手作業で更新または修繕する方法を述べます。
XXX充分慎重に取り組む限りそれ以上難しくはならないので、
つぎに示した手順通りに(ある程度の常識を踏まえて)行なってください。
</p>
</body>
</section>
<section>
<title>Portageのtarballを入手</title>
<body>
<p>
まずは現在バージョンのPortageのtarballを取ってくる必要があります。
これ以降 <e>portage-&stable_version;</e> を例として話をすすめます(これは原稿執筆時点での現行安定版です)が、
できれば実際のツリーで用いているバージョンで置き換えてお読みください。
</p>
<table>
<tr><th>Pythonのバージョン</th><th>Portageのバージョン</th></tr>
<tr>
<ti>&lt;= Python 2.5</ti>
<ti>
<uri link="http://distfiles.gentoo.org/distfiles/portage-2.1.6.tar.bz2">
portage-2.1.6.tar.bz2
</uri>
</ti>
</tr>
<tr>
<ti>&gt;= Python 2.6</ti>
<ti>
<uri link="http://distfiles.gentoo.org/distfiles/portage-&stable_version;.tar.bz2">
portage-&stable_version;.tar.bz2
</uri>
</ti>
</tr>
</table>
<warn>
<c>python -V</c> で調べた現在インストールされているpythonのバージョンが2.6未満(2.6より古い)場合、
その版に互換性のあるバージョンのPortageを選ばなくてはなりません。
python 2.6以上が入っていたら <e>portage-&stable_version;.tar.bz2</e> を使います。
python 2.4 か 2.5 が入っていたら <e>portage-2.1.6.tar.bz2</e> を使います。
</warn>
<p>
Portageが動かないときの原因を厳密にみてゆくと、
場合によってはtarballを取得するためなら使えないこともないので、
とりあえず <c>emerge --fetchonly sys-apps/portage</c> を試してみてください。
これもうまくいかない場合のみ手作業によりつぎの方法でtarballを取得する必要があります。
</p>
<pre caption="wgetでPortageのtarballを取得">
# <i>wget -P /usr/portage/distfiles http://distfiles.gentoo.org/distfiles/portage-&stable_version;.tar.bz2</i>
</pre>
<p>
これが終わると
<path>/usr/portage/distfiles/portage-&stable_version;.tar.bz2</path>
にtarballがあるはずです。
</p>
</body>
</section>
<section>
<title>インストール済みのバージョンを入れ替え</title>
<body>
<p>
そのつぎはtarballをどこか適当な仮置き場に解凍します。
たとえば仮に <path>/root/portage-recover</path>
へ展開するならコマンドはつぎのようになるでしょう。
</p>
<pre caption="Portageのtarballを解凍">
# <i>cd /root</i>
# <i>mkdir portage-recover</i>
# <i>cd portage-recover</i>
# <i>tar xfj /usr/portage/distfiles/portage-&stable_version;.tar.bz2</i>
</pre>
<p>
そうしたら(大抵の場合ほとんど)あとはインストールしてあったPythonとbashのファイルをtarballに入っていたものと交換することだけです。
つぎのとおりに実行してください。
</p>
<pre caption="インストールしてあったファイルを交換">
# <i>cd /root/portage-recover/portage-&stable_version;</i>
# <i>rm -rf /usr/lib/portage/*</i>
# <i>cp -R pym bin /usr/lib/portage/</i>
</pre>
<p>
FreeBSD上でGentooを使用しているのでなければ、 不要なsedのラッパースクリプトが残っていて古いバージョンのbashに不具合をもたらすとのことですので削除しなくてはなりません。
</p>
<pre caption="sedラッパースクリプトを削除">
# <i>rm -f /usr/lib/portage/bin/sed</i>
</pre>
<note>
先にPortageをunmergeするなど何かの拍子にうっかり <path>/etc/make.globals</path>
を失なってしまった場合は、 <path>cnf/make.globals</path> を <path>/etc</path>
にコピーする必要があります。 これが無いとPortageは異常な動作をするかもしれません。
</note>
<note>
Portageをバージョン2.1より古いものから入れ替えた場合はつぎの作業に進む前にここで
<c>emerge --metadata</c> を実行しなくてはいけません。
これはebuild用メタデータを変換してPortageの2.1以上準拠の新しい形式にする必要があるからです。
ちなみに以前のPortageバージョンがよくわからなかった場合でもこのコマンドを実行して問題ありません。
</note>
<p>
さあこれでインストールが終わり再びPortageが利用可能になったはずです。
しかしシステムの一貫性ある状態を確実にする意味で念のため直ちにもう一度
<c>emerge sys-apps/portage</c> を実行するべきでしょう。
</p>
<p>
もしも <c>emerge</c> を実行したときに <e>command not found</e>
というエラーメッセージが返ってきたときは、
つぎのようにしてシンボリックリンクを再生させなくてはいけません。
</p>
<pre caption="emergeシンボリックリンクを再生">
# <i>ln -sf ../lib/portage/bin/emerge /usr/bin/emerge</i>
</pre>
<p>
以上の工程を経てもなお動作しなかった場合、
不具合のありかはPortageインストールとは無関係な何か別の、
この文書の範疇から外れた問題だろうと思われます。 再度
<uri link="/proj/en/portage/doc/common-problems.xml">list of common
problems</uri> (日本語訳
<uri link="/proj/ja/portage/doc/common-problems.xml">非特異な問題まとめ</uri>)
をお読みいただくとともに同様な問題が報告されていないか <uri
link="http://bugs.gentoo.org">bugzilla</uri> でもお調べください。
</p>
</body>
</section>
</chapter>
</guide>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/tex/texlive-migration-guide.xml,v 1.7 2009/04/15 05:59:09 aballier Exp $ -->
<guide link="/proj/ja/tex/texlive-migration-guide.xml" lang="ja">
<title>TeX Live 2008ガイド</title>
<author title="Author">
<mail link="aballier@gentoo.org">Alexis Ballier</mail>
</author>
<author title="翻訳">
<mail link="liangtai.s4@gmail.com">島本良太</mail>
</author>
<abstract>
このガイドはGentooにTex Live 2008をインストールする方法、 なかでもとくに、
既にtetexやTeX Live 2005のようなTeX派生物をインストールしている場合に注意を払うべき点を紹介することを目的としています。
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
<version>1.5</version>
<date>2009-04-15</date>
<!-- Original revision: 1.7 -->
<chapter id="uninstall">
<title>白紙インストール</title>
<section>
<title>はじめに</title>
<body>
<p>
この節では <c>>=app-text/tetex-3</c>
をインストールしてあるものとして話をすすめます。
<c>app-text/texlive-2005</c> をインストールしていた人も対象にしています。
この世界が完璧ならこれからする作業もunmergeするのと変わりないはずですが、
残念ながらそうはいきません。
</p>
</body>
</section>
<section>
<title>旧い設定を保存</title>
<body>
<p>
<path>/etc/texmf</path> を書き換えて <c>tetex</c> の設定に手を加えていた場合は、
これらをまず保存しなくてはなりません。
</p>
<pre caption="旧い設定ファイルを保存">
$ <i>cp -rf /etc/texmf ~/tetex-texmf</i>
</pre>
</body>
</section>
<section>
<title>tetexを削除</title>
<body>
<p>
これで安心して <c>tetex</c> の削除にかかれます。
</p>
<pre caption="tetexを削除">
# <i>emerge -C tetex</i>
</pre>
<p>
はぐれ設定ファイルが <path>/etc/texmf</path>
に置き忘れられていると妙なエラーが報告されてきます。
<c>TeX Live</c> を安全に白紙インストールするために、
<path>/etc/texmf/texmf.d/00texmf.cnf</path>
ファイルを削除されることをお勧めします。
</p>
<pre caption="/etc/texmf内を掃除">
# <i>rm /etc/texmf/texmf.d/00texmf.cnf</i>
</pre>
<note>
旧い設定ファイルは保存しておきましたから逸失するものは何もありません。
</note>
<p>
パッケージマネージャーの管理が及ばないところで <c>tetex</c> が <c>texlinks</c>
を使用しているため、 ただunmergeしただけでは、
はぐれシンボリックリンクがいくつか残ってしまいます。
</p>
<pre caption="tetexのはぐれシンボリックリンク">
$ <i>ls -l /usr/bin/pdftex</i>
lrwxrwxrwx 1 root root 7 2007-07-09 07:34 /usr/bin/pdftex -> pdfetex
</pre>
<p>
pdfetexは <c>tetex</c> と一緒に削除されるため、
pdftexというシンボリックリンクは断線してしまっておりもちろん削除しても大丈夫です。
<c>find</c> コマンド(ただしGNU拡張つき)でつぎのようにすれば断線したシンボリックリンクを探し出し対話的に削除ができます。
</p>
<pre caption="断線したシンボリックリンクを対話的に消去">
# <i>find /usr/bin -type l ! -xtype f ! -xtype d -ok rm -f {} \;</i>
&lt; rm ... /usr/bin/pdflatex &gt; ? y
&lt; rm ... /usr/bin/amstex &gt; ? y
&lt; rm ... /usr/bin/pdftex &gt; ? y
&lt; rm ... /usr/bin/eplain &gt; ? y
&lt; rm ... /usr/bin/jadetex &gt; ? y
&lt; rm ... /usr/bin/lambda &gt; ? y
&lt; rm ... /usr/bin/pdfamstex &gt; ? y
&lt; rm ... /usr/bin/elatex &gt; ? y
&lt; rm ... /usr/bin/lamed &gt; ? y
&lt; rm ... /usr/bin/pdfjadetex &gt; ? y
&lt; rm ... /usr/bin/latex &gt; ? y
</pre>
<p>
ここまでは <c>tetex</c> がインストールしたまま残してしまうファイルです。
</p>
<p>
また <c>tetex</c> はパッケージマネージャーの管理の及ばないところで
<c>fmtutil</c> を用いて <c>.fmt</c> フォーマットファイルを生成しています。
<c>Tex Live 2008</c> はパッケージをコンパイルする時点でほとんどの <c>.fmt</c>
フォーマットファイルを生成し、 これらは
<path>/var/lib/texmf</path> にインストールされることになっています。
つまり決してはぐれ <c>.fmt</c> フォーマットファイルが残っていてはいけません。
</p>
<pre caption="はぐれフォーマットファイルを削除">
# <i>rm -rf /var/lib/texmf/web2c</i>
</pre>
</body>
</section>
</chapter>
<chapter>
<title>TeX Live 2008をインストール</title>
<section>
<body>
<p>
以上の手順を済ませれば <c>TeX Live 2008</c> のインストールはとても簡単なはずです。
</p>
<pre caption="TeX Live 2008のインストール">
# <i>emerge texlive</i>
</pre>
<p>
理論通りであればこれで滞りなく何もかもインストールされるはずです。
追加のTeXパッケージもインストールするつもりで <c>app-text/texlive</c>
のUSEフラグを調整しておこうとのお考えがあるかもしれませんが、
これはあとからでも可能です。 <c>app-text/texlive</c>
は実際のパッケージを引き込むだけのメタebuildであり、
USEフラグに従って入れるものを選択します。
</p>
<p>
でもやはり依存に変調をきたしたりパッケージのインストール中にエラーが生じたりなど、
何らかの問題が起こる可能性はあります。 そんなときは
<uri>https://bugs.gentoo.org</uri> にバグ報告を申請すればよいのです。
バグ報告にはエラーの出力に加え少なくとも <c>texconfig conf</c>
コマンド(ただし環境変数が重要な意味を持つのでインストールを失敗したユーザー権限で実行)の出力を載せてください。
この出力文は最もよく使われます。
</p>
</body>
</section>
</chapter>
<chapter>
<title>Configuration</title>
<section>
<title>はじめに</title>
<body>
<p>
<c>tetex-3</c> のときと同じく、 <c>Gentoo</c> の <c>TeX Live</c>
も主に3つの設定ファイルがあって、 <c>texmf-update</c> で分けて取り扱います。
それぞれ名前は <path>texmf.cnf</path>、 <path>fmtutil.cnf</path>、
<path>updmap.cfg</path> です。 いずれも <path>/etc/texmf/web2c</path>
に置かれています。 これらの内容に直接の変更を加えないでください。 次回に
<c>texmf-update</c> を実行すると変更した情報は失われてしまいます。
</p>
</body>
</section>
<section>
<title>texmf.cnf</title>
<body>
<p>
<path>texmf.cnf</path> はTeXの導入設定ファイルの根幹です。
定数の定義が行なわれており、 数多くのプログラムがこれを利用します。
</p>
<p>
<path>texmf.cnf</path> ファイルの内容は <path>/etc/texmf/texmf.d</path>
にあるファイルを連結した物です。
TeX環境変数の設定を変更するためにはそちらのファイルを編集しなければなりません。
書き込んだ時点で <c>Gentoo TeX Live</c>
のebuildは6つのファイルをそこにインストールします。
</p>
<pre caption="texmf.dにインストールされるファイル">
00header.cnf
05searchpaths.cnf
10standardpaths.cnf
15options.cnf
20sizes.cnf
25misc.cnf
</pre>
<p>
このとりあわせは <c>TeX Live 2008</c> DVD の <path>texmf.cnf</path>
ファイルを(ほんの少しだけ)変更したうえで、
その内容を節ごとにファイルに分割した結果です。
</p>
<p>
<path>00header.cnf</path>、 <path>05searchpaths.cnf</path>、
<path>10standardpaths.cnf</path>、 <path>25misc.cnf</path>
の各ファイルを編集してはなりません。 この初期設定内容に改善点があれば、
バグ報告をお願いします。
</p>
<warn>
これらのファイルを移動しても <c>TeX Live</c> のebuildは感知できないので、
パスを変更したのなら何が起きているか必ずご自身で確認しましょう。
</warn>
<p>
<path>15options.cnf</path> と <path>20sizes.cnf</path>
の各ファイルの変更は注意が必要です。
ファイル内のコメント文がそれぞれのオプションを説明しているはずです。
例えば、 <path>20sizes.cnf</path> にはTeXのメモリーを調整する項目があり、
文書が巨大すぎて処理中に <c>TeX capacity exceeded, sorry</c>
エラーが出てしまう場合にここで増やします。
</p>
<p>
<path>texmf.cnf</path> に何か追加したいとき、 <path>/etc/texmf/texmf.d</path>
ディレクトリ内に例えば <path>99myadditions.cnf</path>
のような名前のファイルを新たに作る方法もあります。
上記の核心的設定ファイルよりも優先度が高くなってはいけませんので、
ファイル名の頭につける二桁の数値が <c>25</c>
以下にならないように気をつけましょう。
</p>
<p>
<path>texmf.cnf</path> に何らかの追加を行なう必要のあるパッケージは、
これと同じ手段をとりながらも、 <path>texmf.d</path>
内のファイルをこのようにしてインストールするはずです。
</p>
<pre caption="texmf.d内にファイルをインストールためのebuildサンプルコード">
<keyword>insinto</keyword> <const>/etc/texmf/texmf.d</const>
<keyword>doins</keyword> <const>40mytexmfadditions.cnf</const>
</pre>
</body>
</section>
<section>
<title>updmap.cfg</title>
<body>
<p>
<path>updmap.cfg</path> ファイルは、 他方で特に設定がないかぎり、 <c>updmap</c>
(および <c>updmap-sys</c>)が使用する設定ファイルです。
いろいろな種類があるTeX出力ドライバのフォントマップのどれを更新すべきかがこれでわかります。
</p>
<p>
<path>/etc/texmf/web2c</path> 内にある <path>updmap.cfg</path> ファイルの内容は
<path>/etc/texmf/updmap.d</path> にあるファイルを連結したものです。
最初の <path>00updmap.cfg</path> ファイルは <c>app-text/texlive-core</c>
がインストールしたものであり、 インストールされている <c>texmf</c> ツリー上で
<c>updmap --syncwithtrees</c> を実行した結果がその内容です(厳密に言えば、
<c>updmap --syncwithtrees</c> の模倣なのですが、
その違いは技術的細部にとどまります)。
</p>
<p>
さまざまな種類の <c>TeX Live</c> 系ebuildがフォントをインストールするときに
<path>/etc/texmf/updmap.d</path> ディレクトリへファイルを追加します。
これらのファイルを編集すれば一部のフォントマップを更新させない設定ができますが、
いっそ関係しているパッケージを削除したほうがおそらく賢明でしょう。
</p>
<p>
第三者提供のパッケージがフォントマップの追加を求めたときは、
<path>/etc/texmf/updmap.d</path> にインストールさせ、 <c>texmf-update</c>
で取り扱わせるようにすべきです。
</p>
<warn>
ある種のebuildや第三者提供のフォントパッケージについてくる導入方法の説明で
<c>updmap-sys --enable Map=mymap.map</c>
というのを見かけることが時折あるようですが、 はじめにこの操作がなされても、
あとから <c>texmf-update</c> の実行で元に戻されることになってしまいます。
</warn>
<p>
こんなときは <path>/etc/texmf/updmap.d</path>
にインストールするファイルを用意して、 <c>texmf-update</c>
を通す方法のサポートがあるTeX派生物の代わりにインストールするほうがよいでしょう。
</p>
<pre caption="フォントマップを有効にするには">
<keyword>inherit</keyword> <ident>latex-package</ident>
...
<stmt>src_install()</stmt> {
...
<keyword>if</keyword> <stmt>latex-package_has_tetex_3</stmt>; then
<keyword>insinto</keyword> /etc/texmf/updmap.d
<keyword>doins</keyword> myfontmapconfig.cfg
<keyword>fi</keyword>
...
}
...
<stmt>pkg_postinst()</stmt> {
<stmt>latex-package_pkg_postinst</stmt>
<stmt>latex-package_has_tetex_3</stmt> || updmap-sys --enable Map=mymap.map
}
<stmt>pkg_postrm()</stmt> {
<stmt>latex-package_pkg_postinst</stmt>
<stmt>latex-package_has_tetex_3</stmt> || updmap-sys --disable Map=mymap.map
}
</pre>
<p>
<path>/etc/texmf/updmap.d</path> のファイルは <c>updmap</c>
の書式・構文に則って書かねばなりません。
</p>
<pre caption="updmap.cfgより書式・構文について説明した部分の抜粋と和訳">
There are two possible entries: Map and MixedMap. Both have one additional
argument: the file name of the map file. MixedMap ("mixed" means that the font
is available as bitmap and as outline) lines will not be used in the default map
of dvips if dvipsPreferOutline is false. Inactive Map files should be marked by
"#! " (without the quotes), not just #.
(和訳)
MapとMixedMapの2つが設置できうる項目です。
どちらもマップファイルの名前を追加で引数に持ちます。
MixedMap(ミックスとはフォントがビットマップとアウトラインの両方使えるという意味です)の行は、
dvipsPreferOutlineがfalseである場合、
dvipsのデフォルトマップとして使われません。
Inactive Mapファイルは#でなく#!でマークすべきです。
</pre>
</body>
</section>
<section>
<title>fmtutil.cnf</title>
<body>
<p>
<path>fmtutil.cnf</path> ファイルには <c>.fmt</c>
フォーマットファイルをどう作成しどう扱うかの情報が入っています。
</p>
<p>
<path>fmtutil.cnf</path> ファイルの内容は <path>/etc/texmf/fmtutil.d</path>
にあるファイルを連結した物です。 さまざまな種類の <c>TeX Live</c>
系ebuildがここにファイルをインストールします。
これらのファイルは追加でサポートした書式と、
関連エンジンへのシンボリックリンクがついてきます。
</p>
<pre caption="fmtutil.cnf(5)のマニュアルより構文規則を説明している部分の抜粋および和訳">
The fmtutil.cnf file contains the configuration information for fmtutil(8).
Each line contains the name of the format (e.g., "tex", "latex", "omega"), the
name of the engine that is used by that format (e.g., "tex", "etex", "omega"),
the pattern file (e.g., language.dat, language.def), and any arguments (name of
an .ini file).
Fields are separated by whitespace and complete lines can be commented out with
"#". The "pattern file" field cannot be used to define a file that is used
while building the format. It tells fmtutil which file the format creation
procedure reads and it has an effect to the options --showhyphen and --byhyphen.
If the format has no way to customize hyphenation, a "-" can be used to indicate
this.
(和訳)
fmtutil.cnfファイルにはfmtutil(8)コマンドの設定情報が入っています。
行ごとに構文規則名(例:"tex"、 "latex"、
"omega")とそれを扱うエンジン名(例:"tex"、 "etex"、 "omega")、
パターンファイル(例:language.dat、 language.def)、
および他のあらゆる引数(.iniファイルの名前)が書かれています。
行内の成分は空白文字で区切られ、 完結している行は"#"でコメントアウトできます。
パターンファイル欄はフォーマットを構築するときに使うファイルが定義できません。
この定義はフォーマット生成手続きが読むファイルがどれか、
また--showhypenや--byhyphenオプションが効くファイルかどうかをfmtutilに知らせるためにあります。
そのフォーマットに独自のハイフン処理がないときは、
"-"の文字がハイフン表記に使用されます。
</pre>
<p>
<path>fmtutil.d</path> 内にファイルをインストールする <c>TeX Live</c> 系ebuildは、
関連するフォーマットファイルを <path>/var/lib/texmf/web2c</path>
にインストールし、 そのフォーマットからエンジンにシンボリックリンクを張ります。
</p>
<p>
ちなみに何らかの言語用にサポートファイルを追加したときは、 <c>texmf-update</c>
が <path>language.dat</path> 内のファイルに追加する役を引き受けて、
新たにインストールされた言語をサポートできるようフォーマットファイルを再生成します。
</p>
</body>
</section>
<section>
<title>設定を更新</title>
<body>
<p>
ひとまずこれで <c>TeX Live</c> の設定を管理する方法を学んだので、
旧いTeX派生物に施してきた設定を、 <c>TeX Live</c>
設定レイアウトに移植できるようになったはずです。
</p>
</body>
</section>
</chapter>
<chapter>
<title>ありがちなエラー</title>
<section>
<title>はじめに</title>
<body>
<p>
この章ではもっともよくあるエラーを短くまとめ、
どこがいけなかったのかについて説明を試みます。
</p>
</body>
</section>
<section>
<title>フォーマットが(pdf)etexで書かれていた</title>
<body>
<p>
たまにlatexが必須のパッケージをインストールしているとき、
このようなエラーが出ます。
</p>
<pre caption="フォーマットがpdfetexで書かれている">
---! //var/lib/texmf/web2c/latex.fmt was written by pdfetex
</pre>
<p>
これは古いファイルが残っているために起きるエラーで、 かつてインストールしてあった
<c>etex</c> 系の <c>TeX</c> 派生物の残骸が原因です。
たぶんこのガイドにちゃんと従っていなくて、 とくに
<uri link="#uninstall">白紙インストールの章</uri>
のとおりにできていないからでしょう。
</p>
<p>
ところがどっこいなにもインストールをやり直さなくてもあっというまに修正ができる可能性がまだあります。
ルートユーザーになってつぎのようにしましょう。
</p>
<pre caption="古いフォーマットを削除">
# <i>rm -rf /var/lib/texmf/web2c</i>
# <i>texmf-update</i>
</pre>
</body>
</section>
<section>
<title>フォーマットのディレクトリがありません</title>
<body>
<p>
インストール中に、 具体的には例えば <c>texlive-latex</c>
を導入しているときにこんなエラーに遭遇したかもしれません。
</p>
<pre caption="フォーマットのディレクトリがありません">
fmtutil: format directory
`/var/tmp/portage/dev-texlive/texlive-latex-2008/work/texmf-var/web2c' does not
exist.
</pre>
<p>
この原因は十中八九が設定のミスによるものです。
つぎのようにコマンドを実行してこのとおりの結果がでるかみてみます。
</p>
<pre caption="TEXMFMAIN定義">
$ <i>kpsewhich --var-value=TEXMFMAIN</i>
/usr/share/texmf
</pre>
<p>
<c>fmtutil</c> はこの場所で <c>mktexdir</c> を探して読むのでここは非常に重要です。
さきのコマンドで違う結果が出るようなら <c>fmtutil</c> は <c>mktexdir</c>
を発見できず、
したがってコンパイルしたフォーマットを一時的に保管するためのディレクトリを生成できません。
</p>
<p>
これを解決する魔法の呪文のコマンドは無く、
設定ファイルが正しく書かれているか、 そして <path>/etc/texmf/texmf.d</path>
にはぐれ設定ファイルが残されていないかあらためなくてはなりません。
ほとんどの原因は古い <path>00texmf.cnf</path> がまだ残っていたため
<path>texmf.cnf</path> ファイルが間違った定義で設定していたためのようです。
<uri link="#uninstall">白紙インストールの章</uri> を参考にしてください。 また、
<path>/etc/texmf/*.d</path> の形のディレクトリでファイルを変えたり削除するときは、
必ず <c>texmf-update</c> を実行して変更を反映させることを忘れないでください。
</p>
</body>
</section>
<section>
<title>.texファイルが見つかりません</title>
<body>
<p>
<c>texlive-latex</c>
(もしくはbabelハイフン処理サポートがある他のフォーマット)をインストールするときに、
このようなエラーに遭遇したかもしれません。
</p>
<pre caption="bghyphen.texがありません">
===========================================
Local configuration file hyphen.cfg used
===========================================
(/var/tmp/portage/dev-texlive/texlive-latex-2008/work/texmf-dist/tex/generic/ba
bel/hyphen.cfg (/usr/share/texmf/tex/generic/hyphen/hyphen.tex)
(/usr/share/texmf/tex/generic/hyphen/ushyphmax.tex)
(/usr/share/texmf/tex/generic/hyphen/dumyhyph.tex)
(/usr/share/texmf/tex/generic/hyphen/zerohyph.tex)
(/usr/share/texmf/tex/generic/hyphen/zerohyph.tex)
(/usr/share/texmf-dist/tex/generic/xu-hyphen/xu-bahyph.tex
(/usr/share/texmf/tex/generic/hyphen/bahyph.tex))
(/usr/share/texmf-dist/tex/generic/xu-hyphen/xu-bghyphen.tex
! I can't find file `bghyphen.tex'.
l.10 \input bghyphen.tex
Please type another input file name:
! Emergency stop.
l.10 \input bghyphen.tex
No pages of output.
Transcript written on latex.log.
Error: `pdftex -ini -jobname=latex -progname=latex
-translate-file=cp227.tcx *latex.ini' failed
</pre>
<p>
この場合、 どの <path>language.dat</path>
ファイルが使われているか確かめなくてはならなくなります。
</p>
<pre caption="language.datを見つけだす">
$ <i>kpsewhich language.dat</i>
/usr/share/texmf/tex/generic/config/language.dat
</pre>
<p>
このファイルは <c>texmf-update</c> が自動的に生成するもので、
<path>language.us</path> のあるディレクトリ内の <path>language.*.dat</path>
を連結してできています。 (たとえば TeX Live 2008の場合は
<path>/etc/texmf/language.dat.d/</path> にある <path>language.*.dat</path>
をもとにします。) このディレクトリは
<path>/usr/share/texmf/tex/generic/config/</path> でなくてはいけません。
なので <c>dev-texlive/texlive-lang*</c>
ebuildのいずれかがインストールしたもの以外に <path>language.*.dat</path>
ファイルがそのディレクトリに入っていないことを必ず確かめましょう。
このディレクトリに何かファイルを入れたらそれがサポートする言語のハイフン処理を有効にすることになります。
ハイフン処理サポートファイルが手元にない場合、
この追加ハイフン処理サポートを使用するフォーマットの生成は失敗するはずです。
</p>
</body>
</section>
</chapter>
</guide>
<?xml version='1.0' encoding="UTF-8"?>
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/eselect/user-guide.xml,v 1.10 2012/01/22 00:24:38 ulm Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/proj/ja/eselect/user-guide.xml" lang="ja">
<title>eselectユーザーガイド</title>
<author title="Author">
<mail link="ciaranm@gentoo.org">Ciaran McCreesh</mail>
</author>
<author title="Author">
<mail link="kugelfang@gentoo.org">Danny van Dyk</mail>
</author>
<author title="Author">
<mail link="ulm@gentoo.org">Ulrich Müller</mail>
</author>
<author title="Editor">
<mail link="fox2mike@gmail.com">Shyam Mani</mail>
</author>
<author title="翻訳">
<mail link="liangtai.s4@gmail.com">島本良太</mail>
</author>
<abstract>
この文書はeselectツールの末端ユーザー向け完全リファレンスガイドです。
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
<license/>
<version>1.3</version>
<date>2012-01-21</date>
<!-- Originar revision: 1.10 -->
<chapter>
<title>はじめに</title>
<section>
<title>概略</title>
<body>
<p>
eselectはGentoo上のシステムを管理・設定するためのツールです。
システムの動作を改変することに <e>なってしまう</e> ので、
システム管理者の立場で慎重に使用しなければなりません。
eselectは設定を書くためのモジュール化構造ユーティリティーです。
その中身は、
</p>
<ul>
<li>
<e>eselect</e> という名前の主プログラム。
</li>
<li>
それぞれに仕事をこなすさまざまなモジュール(*.eselectファイル)。
</li>
<li>
一貫した動作を保証し、
新たなモジュールの作成を単純化するのに役立つライブラリー集。
</li>
</ul>
<p>
ひとつのライブラリーに複数のアクションが入っています。
主なアクションには情報を表示するもの(よくあるアクションは <c>list</c> や
<c>show</c>)や、
システムのどこかを更新するもの(例えば <c>set</c> や <c>update</c>)があります。
どのモジュールも <c>help</c> と <c>usage</c>
アクションがあってこれでモジュールの使い方の説明が読めます。
</p>
<note>
モジュールのなかにはメインのプログラムにシンボリックリンクを張るものもあります。
これをeselectは知能的に操作します。
例えば、 <c>profile-config list</c> と命令するとまるで
<c>eselect profile list</c> を走らせたかのようにふるまうことでも判ります。
</note>
</body>
</section>
<section>
<title>末端ユーザとシステム管理者それぞれの利点</title>
<body>
<p>
eselectモジュール的に書かれたツールがあると、
システム管理者の立場からも、 末端ユーザーにとっても、
従来の「一からツールを書き起こす」手法に勝るさまざまな利点が得られます。
</p>
<ul>
<li>
一貫性UI - eselectモジュールが首尾一貫したユーザインターフェイスをもたらします。
ツールを操作する何十個もの-xの形のオプションスイッチは、
eselectのアクション構造のおかげでもう覚えなくてもいちいち探して調べなくても済みます。
しかもモジュールは出力の書式が標準化されています。
</li>
<li>
一貫性のあるヘルプ書式 - どのeselectモジュールも <c>help</c> と
<c>usage</c> アクションを通じて簡単にヘルプ文書がとりだせます。
</li>
<li>
一貫したツール命名規則 - 沢山ある 何とか-config だとか update-何それ
のような名前を一切覚えなくてもよくなります。
利用できるツールを一覧にして出したいなら、 単に引数なしで <c>eselect</c>
を実行すればいいのです。
何とか-config 形式の方がよろしければ、
もちろん(シンボリックリンクで通じていますので)それらも使えます。
</li>
<li>
<c>sROOT</c> の保証つきサポート - <c>sROOT</c> をご利用のみなさまには、
ツールごとにこれはこの作業に使えるのか使えないのかなどと気にしなくてもよくしてあります。
どのeselectモジュールも <c>sROOT</c> のサポートが必須です。
</li>
</ul>
</body>
</section>
<section>
<title>開発者とパッケージ保守担当者にとって有用な側面</title>
<body>
<p>
一から全部書くよりもeselectモジュールとして書く方がこんなにも有利にはたらきます。
</p>
<ul>
<li>
開発時間の短縮 – 作業内容の大多数はもうやってあります。
よくある行為がeselectのライブラリに収められており、 中心の
<c>eselect</c> プログラムがめんどうな仕事のほとんどを処理します。
やるべきことはアクションを起こすことと、
必要なドメイン限定の関数を全部用意することだけです。
</li>
<li>
自動アクション – <c>help</c> と <c>usage</c>
の各アクションは選んだアクションに応じて自動的に生成されますので、
何も心配しなくてもこれらはいつも最新に保たれます。
</li>
<li>
手軽に、 一貫した操作性 -
入力と出力とコマンドライン操作の大部分がライブラリ関数化して分離されているので、
他のツールと同じように一貫したふるまいをする「標準的」なモジュールがとても簡単に書けます。
</li>
<li>
慣れ親しんだ書式 -
eselectのモジュール書式はGentoo開発者には馴染み深い姿をしているはずです。
ebuildにかなり近い構造をしたbashファイルなのです。
</li>
</ul>
</body>
</section>
</chapter>
<chapter>
<title>eselectの利用</title>
<section>
<title>使い方</title>
<body>
<p>
eselectは以下に示す方法で呼び出さなくてはなりません。
</p>
<pre caption="eselect – 一般規則">
# <i>eselect [&lt;global options&gt;] &lt;module&gt; &lt;action&gt; &lt;options&gt;</i>
</pre>
<p>
eselectは数あるモジュールのほとんどを通じて一貫した名前をアクションにつける仕様となっています。
このガイドを執筆した現時点でふたつだけ汎用オプションがあります。
そのひとつは <c>--brief</c> というオプションであり、
これはeselectの出力を短くします(たとえば他のプログラム用の入力に使います)。
もうひとつは <c>--colour</c> というオプションであり、
これはeselectの着色出力を制御します。 つぎの表は標準のアクション名です。
モジュールは個別にこれらアクションのサブセットを提供しているかもしれません。
</p>
<ul>
<li>
<c>help</c> – モジュールのヘルプを表示します。
</li>
<li>
<c>usage</c> – モジュールのアクションを呼び出す方法についての情報を表示します。
</li>
<li>
<c>version</c> – モジュールのバージョンと他の有用な情報を表示します。
</li>
<li>
<c>list</c> – 選択可能なオプション集を表示します。
</li>
<li>
<c>show</c> – 現在アクティブになっている設定を表示します。
</li>
<li>
<c>set</c> – <c>list</c> で得られるオプションのひとつを選択します。
</li>
<li>
<c>enable</c> – そのモジュールが持つ機能のひとつを有効に設定します。
</li>
<li>
<c>disable</c> – そのモジュールが持つ機能のひとつを無効に設定します。
</li>
<li>
<c>set</c> と同じはたらきをしますが、
パラメータをとらず自動的にオプションを選びます。
</li>
<li>
<c>scan</c> –
システムまわりの情報を収集し保存して今後のモジュールの用途に備えます。
</li>
</ul>
<p>
A typical session will look like the following for most modules:
たいていのモジュールではつぎのような一連の行動をよくするでしょう。
</p>
<pre caption="eselectセッションの例">
<comment>(モジュールのオプションを見ます)</comment>
# <i>eselect &lt;module&gt; list</i>
These selections are available:
[1] &lt;first&gt;
[2] &lt;second&gt;
<comment>(オプションを設定します)</comment>
# <i>eselect &lt;module&gt; set &lt;first&gt;</i>
<comment>(現在の設定を表示します)</comment>
# <i>eselect &lt;module&gt; show</i>
Active Selection:
&lt;item1&gt;
</pre>
<p>
通常はアイテムを名前か番号のいずれかで設定できます。
</p>
</body>
</section>
</chapter>
</guide>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment