Debian は、単にソフトウェアのパッケージを作ってメンテナンスをしているだけではありません。この章では、単にパッケージを作ってメンテナンスする以外で Debian へ協力・貢献するやり方、多くの場合とても重要となるやり方の情報を取り扱います。
ボランティア組織の例にたがわず、Debian の活動はメンバーが何をしたいのか、時間を割くのに最も重大だと思われることが何か、というメンバーの判断に依っています。
我々としては、Debian パッケージで見つけたバグを登録することを勧めています。実際のところ、大抵の場合は Debian 開発者が第一線でのテスト作業者となっています。他の開発者のパッケージで見つけたバグを報告することで Debian の品質が向上されています。
Debian バグ追跡システム (BTS) の バグ報告のやり方について (instructions for reporting bugs) を参照してください。
いつも使っているメールを受け取れるユーザアカウントからバグを送ってみてください。そうすることで、開発者がそのバグに関するより詳細な情報を必要とする場合にあなたに尋ねることができます。root ユーザでバグを報告しないでください。
バグを報告するには、reportbug(1) のようなツールが使えます。これによって作業を自動化し、かなり簡単なものにできます。
パッケージに対して既にバグが報告されていないことを確認しておいてください。個々のパッケージに対するバグのリストは
https://bugs.debian.org/
にて簡単に確認できます。querybts(1) のようなユーティリティでもこの情報を入手できます
(なお、reportbug では大抵の場合、バグを送信する前に
querybts の実行も行っています)。
パッケージ名
正しい所にバグを報告する様に心がけてください。例えばあるパッケージが他のパッケージのファイルを上書きしてしまうバグの場合ですが、バグ報告が重複して登録されるのを避けるため、これらのパッケージの両方のバグリストを確認してください。
さらに言うと、他のパッケージについても、何度も報告されているバグをマージしたり既に修正されているバグに「fixed」タグをつけたりすることもできます。そのバグの報告者であったりパッケージメンテナではない場合は (メンテナから許可をもらっていなければ)、実際にバグをクローズしてはいけないことに注意してください。
時折、あなたが登録したバグ報告について何が起こっているのかをチェックしたくなることでしょう。これは、もう再現できないものをクローズするきっかけになります。報告した全てのバグ報告を確認するには、https://bugs.debian.org/from:
を参照すればいいだけです。
your-email-addr
大量の異なるパッケージに対して、同じ問題についての非常に多くのバグ (例えば 10 個以上)
を報告するのは、推奨されていないやり方です。不要なバグ報告を避けるため、可能な限りの手続きを踏むようにしましょう。例えば、問題の確認を自動化できる場合は
lintian
に新しくチェック項目を追加すれば、エラーや警告が明確になります。
同じ問題について一度に 10 個以上のバグを報告する場合は、バグ報告を登録する前に <debian-devel@lists.debian.org>
へ送ることをお勧めします。バグ報告を送る前に注意点を記述し、メールのサブジェクトに事実を挙げておきます。これで他の開発者がそのバグが本当に問題であるかどうかを確認できるようになります。さらに、これによって複数のメンテナが平行して同じバグ報告を登録するのを防止できるようになります。
dd-list プログラムを利用することと、明確になっているのであれば影響を受けるパッケージのリストを
(devscripts
パッケージの)
whodepends を使って出力して、<debian-devel@lists.debian.org>
へのメールに含めて下さい。
同じサブジェクトで大量のバグを送信する際は、バグ報告がバグ情報用メーリングリストへ転送されないように <maintonly@bugs.debian.org>
へバグ報告を送るべきであるの注意してください。
多数のパッケージに対するバグを登録する際に BTS の usertag を使いたくなるかもしれません。usertag は 'patch' や 'wishlist' のような通常のタグに似ていますが、ユーザが定義する事と特定のユーザに対して一意な名前空間を占めるという点で違っています。これによって、同じバグについて衝突する事無しに、開発者がそれぞれ別のやり方で複数の設定ができるようになります。
バグを登録する際に usertag を追加するには、擬似ヘッダ (pseudo-header) User
と
Usertags
を指定します。
To: submit@bugs.debian.org Subject:バグタイトル
Package:パッケージ名
[ ... ]
User:メールアドレス
Usertags:タグ名 [ タグ名 ... ]
バグの説明 ...
Note that tags are separated by spaces and cannot contain underscores. If
you are filing bugs for a particular group or team it is recommended that
you set the User
to an appropriate mailing list after
describing your intention there.
特定の usertag でバグを参照する場合は
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=
を指定してください。
メールアドレス
&tag=タグ名
品質保証に割り当てられたグループの人々がいたとしても、QA
作業は彼らのみに課せられるものではありません。あなたもパッケージを可能な限りバグが無いように保ち、できるだけ lintian clean な状態
(「lintian
」 を参照)
にすることで品質保証の作業に参加することができるのです。それが可能ではないように思えるなら、パッケージをいくつか「放棄 (orphan)」してください
(「パッケージを放棄する」 参照)。または、溜まったバグ処理に追いつくため、他の人々に助力を願い出ることも可能です
(<debian-qa@lists.debian.org>
や <debian-devel@lists.debian.org>
で助けを求めることができます)。同時に共同メンテナ
(co-maintainer) を探すことも可能です (「共同メンテナンス」
を参照してください)。
From time to time the QA group organizes bug squashing parties to get rid of
as many problems as possible. They are announced on
<debian-devel-announce@lists.debian.org>
and the announcement explains which area will
be the focus of the party: usually they focus on release critical bugs but
it may happen that they decide to help finish a major upgrade (like a new
perl version that requires recompilation of all the
binary modules).
The rules for non-maintainer uploads differ during the parties because the announcement of the party is considered prior notice for NMU. If you have packages that may be affected by the party (because they have release critical bugs for example), you should send an update to each of the corresponding bug to explain their current status and what you expect from the party. If you don't want an NMU, or if you're only interested in a patch, or if you will deal with the bug yourself, please explain that in the BTS.
People participating in the party have special rules for NMU; they can NMU without prior notice if they upload their NMU to DELAYED/3-day at least. All other NMU rules apply as usual; they should send the patch of the NMU to the BTS (to one of the open bugs fixed by the NMU, or to a new bug, tagged fixed). They should also respect any particular wishes of the maintainer.
NMU をする自信が無い場合は、BTS へパッチを投げるだけにしてください。NMU でパッケージを壊してしまうより、遥かに良いことです。
Debian と共に過ごす間、様々な理由で他のメンテナに連絡を取りたくなることでしょう。関連パッケージ間での共同作業の新たなやり方について協議したい場合や、開発元で自分が使いたい新しいバージョンが利用可能になっていることを単に知らせたい場合などです。
パッケージメンテナのメールアドレスを探しだすのは骨が折れます。幸いな事に、
というシンプルなメールのエイリアスがあり、メンテナらの個人アドレスが何であれメンテナへメールを届ける手段となっています。パッケージ名
@packages.debian.orgパッケージ名
はパッケージのソース名かバイナリパッケージ名に置き換えてください。
「Debian パッケージトラッカー」 経由でソースパッケージの購読を行っている人に連絡を取りたくなるかもしれません。その場合は
メールアドレスが使えます。
パッケージ名
@packages.qa.debian.org
If you notice that a package is lacking maintenance, you should make sure that the maintainer is active and will continue to work on their packages. It is possible that they are not active anymore, but haven't registered out of the system, so to speak. On the other hand, it is also possible that they just need a reminder.
Missing In Action (行方不明) だと考えられているメンテナについての情報が記録されるシンプルなシステム (MIA データベース)
があります。品質保証グループ (QA グループ)
のメンバーが活動的ではないメンテナに連絡を取った場合や、そのメンテナについて新たな情報がもたらされた場合、その記録が MIA
データベースに残されます。このシステムは qa.debian.org
ホスト上の
/org/qa.debian.org/mia
で利用可能になっており、mia-query ツールで検索ができます。どうやってデータベースを検索するのかについては
mia-query --help
と入力してください。活動的ではないメンテナについての情報がまだ記録されていない、あるいはそのメンテナについての情報を追加できる場合は、おおよそ以下の手続きを行う必要があります。
最初の一歩はメンテナに丁寧にコンタクトを取り、応答するのに充分な時間待つことです。充分な時間というのを定義するのは非常に困難ですが、実生活では時折非常に多忙になるのを考慮に入れると重要なことです。一つのやり方としては、リマインダーを二週間後に送るという方法があります。
A non-functional e-mail address is a violation of Debian Policy . If an e-mail "bounces", please file a bug against the package and submit this information to the MIA database.
メンテナが4週間 (1ヶ月)応答をしない場合、おそらく反応がないと判断できます。この様な場合はより詳細に確認し、可能な限り問題となっているメンテナに関する有用な情報をかき集める必要があります。これには以下のようなものが含まれています。
開発者 LDAP データベース を通じて得られる
echelon
情報は、開発者が最後に Debian メーリングリストに投稿したはいつなのかを示します (これには
<debian-devel-changes@lists.debian.org>
での配布物のアップロードのメールも含まれます)。また、データベースでメンテナが休暇中かどうかも確認してください
このメンテナが対応しているパッケージ数やパッケージの状態。特に、長期間放置され続けている RC バグがあるかどうか? さらに通常どの程度の数のバグがあるか? もう一つの重要な情報はパッケージが NMU されているかどうか、されているとしたら誰によって行われているか、です。
Debian 以外でメンテナの活動があるかどうか? 例えば、近頃 Debian 以外のメーリングリストや news グループへの投稿をしているなど。
パッケージがスポンサーされている、つまりメンテナが公式の Debian 開発者ではない場合はちょっとした問題となります。例えば
echelon
の情報は、スポンサーされている人は利用できません。そのため実際にパッケージをアップロードした
Debian
開発者を探して確認を取る必要があります。彼らがパッケージにサインしたということは、アップロードについて何であれ責任を持ち、スポンサーした人に何が起こっているかを知っていそうだということです。
<debian-devel@lists.debian.org>
に、活動が見えないメンテナの居所に誰か気づいているかという質問を投稿するのもありです。問題の人を Cc:
に入れてください。
ここに書かれた全てを収集したなら、<mia@qa.debian.org>
に連絡しましょう。この名前の宛先を担当している人は、あなたが供給した情報を使ってどう進めるかを判断します。例えば、そのメンテナのパッケージの一部または全てを放棄
(Orphan) するかもしれません。パッケージがNMUされていた場合は、パッケージを放棄 (Orphan)
する前にNMUをした人に連絡する事を選ぶかもしれません — NMUをした人はきっとパッケージに関心があるでしょうから。
最後に一言: 礼儀正しく振る舞いましょう。我々は所詮ボランティアで、全ての時間を Debian に捧げられるわけではありません。また、関わっている人の状況がわかるわけでもありません。重い病気にかかっているかかもしれないし、あるいは死んでしまっているかもしれません - メッセージを受け取る側にどんな人がいるかは分かりません。亡くなった方のご親戚の方がメールを読んだ場合に、非常に無礼で怒った叱責調のメッセージを見つけてどうお感じになるかを想像してください。
On the other hand, although we are volunteers, a package maintainer has made a commitment and therefore has a responsibility to maintain the package. So you can stress the importance of the greater good — if a maintainer does not have the time or interest anymore, they should let go and give the package to someone with more time and/or interest.
If you are interested in working on the MIA team, please have a look at the
README
file in
/org/qa.debian.org/mia
on
qa.debian.org
, where the technical details and the MIA
procedures are documented, and contact <mia@qa.debian.org>
.
Debian の成功は新たな才能あるボランティアをどう魅了し確保するかにかかっています。あなたが経験豊かな開発者なら、新たな開発者を呼び込むプロセスに関与するべきです。このセクションでは新たな開発者候補者をどうやって手助けするのかについて記述します。
Sponsoring a package means uploading a package for a maintainer who is not able to do it on their own. It's not a trivial matter; the sponsor must verify the packaging and ensure that it is of the high level of quality that Debian strives to have.
Debian 開発者はパッケージをスポンサーできます。Debian メンテナはできません。
パッケージのスポンサー作業の流れは以下の通りです:
メンテナはソースパッケージ (.dsc
) を用意してオンライン上の何処か (例えば mentors.debian.net)
に置く、あるいはもっと良いのは、パッケージがメンテナンスされている公開 VCS リポジトリへのリンクを提供することです (「VCS (バージョン管理システム) サーバ」 参照)。
The sponsor downloads (or checks out) the source package.
スポンサーはソースパッケージをレビューします。問題を見つけたら、メンテナに知らせて修正版をくれるように尋ねます (作業は step 1 へやり直しされます)。
スポンサーは、何も問題が残っているのを見つけられませんでした。パッケージをビルドし、署名し、Debian へアップロードします。
Before delving into the details of how to sponsor a package, you should ask yourself whether adding the proposed package is beneficial to Debian.
There's no simple rule to answer this question; it can depend on many factors: is the upstream codebase mature and not full of security holes? Are there pre-existing packages that can do the same task and how do they compare to this new package? Has the new package been requested by users and how large is the user base? How active are the upstream developers?
それから、メンテナ候補者が良いメンテナになるであろうことを保証する必要があります。他のパッケージでの経験がありますか? そうであれば、良い仕事をしていますか (バグを確認している)? パッケージと使われているプログラミング言語について詳しいですか? そのパッケージに必要なスキルを持っていますか? そうでなければ、学ぶことが可能でしょうか?
候補者が、Debian に対してどの様な態度を取っているかを知るのも良い考えです: Debian の哲学に賛同していて、Debian に参加したいと思っていますか? Debian メンテナになるのがどれくらい簡単なのかを考えて、参加を検討している人たちだけをスポンサーするのが良いでしょう。こうすれば、最初からずっとスポンサーとして行動しなくて良いと思っておけます。
New maintainers usually have certain difficulties creating Debian packages — this is quite understandable. They will make mistakes. That's why sponsoring a brand new package into Debian requires a thorough review of the Debian packaging. Sometimes several iterations will be needed until the package is good enough to be uploaded to Debian. Thus being a sponsor implies being a mentor.
レビューをせずに新しいパッケージのスポンサーをしないでください。ftpmaster による新しいパッケージのレビューは、主にソフトウェアが本当にフリーなものであるかを確認するためです。もちろん、パッケージ化に関する問題に偶然気づくことはありますが、それを期待すべきではありません。アップロードされたパッケージが、Debian フリーソフトウェアガイドラインに適合し、良い品質であるのを保証するのは、あなたの仕事です。
パッケージをビルドし、ソフトウェアのテストを行うのはレビューの一部ではありますが、それだけでは十分ではありません。この章の残りの部分では、レビューでチェックするポイントの一覧を述べます (徹底的なものではありません)。[8]
upstream の tarball として提供されているものが、upstream の作者が配布しているものと同じかどうかを確認する (ソースが Debian 用に再パッケージされている場合、修正した tarball を自分自身で生成する)。
Run lintian (see 「lintian
」). It will
catch many common problems. Be sure to verify that any
lintian overrides set up by the maintainer are fully
justified.
licensecheck(「devscripts
」 の一部)
を実行し、debian/copyright
が正しく、そして完全な事を確認する。ライセンス問題を探してください
(頭に“All rights reserved”とあるファイルや、DFSG に適合しないライセンスがあるなど)。この作業には、grep
-ri が助けとなることでしょう。
ビルドの依存関係が完全であるのを保証するため、パッケージを pbuilder (やその他類似のツール)
でビルドする (「pbuilder
」 参照)。
debian/control
を査読する: ベストプラクティスに従っている? (「debian/control
のベストプラクティス」 参照) 依存関係は完璧ですか?
debian/rules
を査読する: ベストプラクティスに従っている? 改善可能な点がある?
メンテナスクリプト (preinst
, postinst
,
prerm
, postrm
,
config
) を査読する: 依存関係がインストールされていない時でも動作する? 全てのスクリプトが等羃
(idempotent、すなわち、問題無しに複数回実行できる)?
開発元のファイルに対する変更
(.diff.gz
、debian/patches/
、あるいは直接
debian
tarball に埋め込まれているバイナリファイル) をレビューする。十分な根拠がありますか?
(パッチに対し、DEP-3 に沿って) 正しくドキュメント化されている?
すべてのファイルについて、そのファイルが何故そこにあるのか、望んでいる結果をもたらすためにそれが正しいやり方かどうかを自身に問いかけてください。メンテナはパッケージ化のベストプラクティスに従っていますか? (6章パッケージ化のベストプラクティス 参照)
Build the packages, install them and try the software. Ensure that you can remove and purge the packages. Maybe test them with piuparts.
If the audit did not reveal any problems, you can build the package and upload it to Debian. Remember that even if you're not the maintainer, as a sponsor you are still responsible for what you upload to Debian. That's why you're encouraged to keep up with the package through 「Debian パッケージトラッカー」.
Note that you should not need to modify the source package to put your name
in the changelog
or in the control
file. The Maintainer
field of the
control
file and the changelog
should list the person who did the packaging, i.e. the sponsee. That way
they will get all the BTS mail.
Instead, you should instruct dpkg-buildpackage to use
your key for the signature. You do that with the -k
option:
dpkg-buildpackage -kKEY-ID
debuild と debsign
を使う場合は、~/.devscripts
に設定を決め打ちで書いても構いません:
DEBSIGN_KEYID=KEY-ID
You will usually assume that the package has already gone through a full review. So instead of doing it again, you will carefully analyze the difference between the current version and the new version prepared by the maintainer. If you have not done the initial review yourself, you might still want to have a deeper look just in case the initial reviewer was sloppy.
To be able to analyze the difference, you need both versions. Download the current version of the source package (with apt-get source) and rebuild it (or download the current binary packages with aptitude download). Download the source package to sponsor (usually with dget).
Read the new changelog entry; it should tell you what to expect during the
review. The main tool you will use is debdiff (provided
by the devscripts
package); you can
run it with two source packages (.dsc
files), or two
binary packages, or two .changes
files (it will then
compare all the binary packages listed in the
.changes
).
ソースパッケージを比較した場合 (新しい開発元のバージョンの場合には、例えば debdiff の出力を filterdiff -i '*/debian/*' などとして、開発元のファイルを除外します)、確認したすべての変更点を理解して、この変更点が Debian の changelog に正しく記載されている必要があります。
If everything is fine, build the package and compare the binary packages to verify that the changes on the source package have no unexpected consequences (some files dropped by mistake, missing dependencies, etc.).
You might want to check out the Package Tracking System (see 「Debian パッケージトラッカー」) to verify if the maintainer has not missed
something important. Maybe there are translation updates sitting in the BTS
that could have been integrated. Maybe the package has been NMUed and the
maintainer forgot to integrate the changes from the NMU into their
package. Maybe there's a release critical bug that they have left unhandled
and that's blocking migration to testing
. If you find
something that they could have done (better), it's time to tell them so that
they can improve for next time, and so that they have a better understanding
of their responsibilities.
何も大きな問題を見つけなければ、新しいバージョンをアップロードします。そうでなければ、メンテナに修正したバージョンをアップロードするよう要請します。
Debian ウェブサイトの開発者志願者の支持者になる (advocating a prospective developer)のページを参照してください。
Debian のウェブサイトにある 申請管理者用チェックリスト (Checklist for Application Managers) を参照してください。
[8] You can find more checks in the wiki, where several developers share their own sponsorship checklists.