第7章 パッケージ化、そして…

目次

7.1. バグ報告
7.1.1. 一度に大量のバグを報告するには (mass bug filing)
7.1.1.1. Usertag
7.2. 品質維持の努力
7.2.1. 日々の作業
7.2.2. バグ潰しパーティ (BSP)
7.3. 他のメンテナに連絡を取る
7.4. 活動的でない、あるいは連絡が取れないメンテナに対応する
7.5. Debian 開発者候補に対応する
7.5.1. パッケージのスポンサーを行う
7.5.1.1. 新しいパッケージのスポンサーを行う
7.5.1.2. 既存パッケージの更新をスポンサーする
7.5.2. 新たな開発者を支持する (advocate)
7.5.3. 新規メンテナ申請 (new maintainer applications) を取り扱う

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 個以上のバグを報告する場合は、バグ報告を登録する前に へ送ることをお勧めします。バグ報告を送る前に注意点を記述し、メールのサブジェクトに事実を挙げておきます。これで他の開発者がそのバグが本当に問題であるかどうかを確認できるようになります。さらに、これによって複数のメンテナが平行して同じバグ報告を登録するのを防止できるようになります。

dd-list プログラムを利用することと、明確になっているのであれば影響を受けるパッケージのリストを (devscripts パッケージの) whodepends を使って出力して、 へのメールに含めて下さい。

同じサブジェクトで大量のバグを送信する際は、バグ報告がバグ情報用メーリングリストへ転送されないように  へバグ報告を送るべきであるの注意してください。

The program mass-bug (from the package devscripts) can be used to file bug reports against a list of packages.

品質保証に割り当てられたグループの人々がいたとしても、QA 作業は彼らのみに課せられるものではありません。あなたもパッケージを可能な限りバグが無いように保ち、できるだけ lintian clean な状態 (lintian を参照) にすることで品質保証の作業に参加することができるのです。それが可能ではないように思えるなら、パッケージをいくつか「放棄 (orphan)」してください (「パッケージを放棄する」 参照)。または、溜まったバグ処理に追いつくため、他の人々に助力を願い出ることも可能です ( で助けを求めることができます)。同時に共同メンテナ (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 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 メーリングリストに投稿したはいつなのかを示します (これには での配布物のアップロードのメールも含まれます)。また、データベースでメンテナが休暇中かどうかも確認してください

  • このメンテナが対応しているパッケージ数やパッケージの状態。特に、長期間放置され続けている RC バグがあるかどうか? さらに通常どの程度の数のバグがあるか? もう一つの重要な情報はパッケージが NMU されているかどうか、されているとしたら誰によって行われているか、です。

  • Debian 以外でメンテナの活動があるかどうか? 例えば、近頃 Debian 以外のメーリングリストや news グループへの投稿をしているなど。

パッケージがスポンサーされている、つまりメンテナが公式の Debian 開発者ではない場合はちょっとした問題となります。例えば echelon の情報は、スポンサーされている人は利用できません。そのため実際にパッケージをアップロードした Debian 開発者を探して確認を取る必要があります。彼らがパッケージにサインしたということは、アップロードについて何であれ責任を持ち、スポンサーした人に何が起こっているかを知っていそうだということです。

に、活動が見えないメンテナの居所に誰か気づいているかという質問を投稿するのもありです。問題の人を Cc: に入れてください。

ここに書かれた全てを収集したなら、に連絡しましょう。この名前の宛先を担当している人は、あなたが供給した情報を使ってどう進めるかを判断します。例えば、そのメンテナのパッケージの一部または全てを放棄 (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 .

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 メンテナはできません。

パッケージのスポンサー作業の流れは以下の通りです:

  1. The maintainer prepares a source package (.dsc) and puts it online somewhere (like on mentors.debian.net) or even better, provides a link to a public VCS repository (see 「salsa.debian.org: Git repositories and collaborative development platform」) where the package is maintained.

  2. The sponsor downloads (or checks out) the source package.

  3. スポンサーはソースパッケージをレビューします。問題を見つけたら、メンテナに知らせて修正版をくれるように尋ねます (作業は step 1 へやり直しされます)。

  4. スポンサーは、何も問題が残っているのを見つけられませんでした。パッケージをビルドし、署名し、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?

それから、メンテナ候補者が良いメンテナになるであろうことを保証する必要があります。他のパッケージでの経験がありますか? そうであれば、良い仕事をしていますか (バグを確認している)? パッケージと使われているプログラミング言語について詳しいですか? そのパッケージに必要なスキルを持っていますか? そうでなければ、学ぶことが可能でしょうか?

It's also a good idea to know where they stand with respect to Debian: do they agree with Debian's philosophy and do they intend to join Debian? Given how easy it is to become a Debian Member, you might want to only sponsor people who plan to join. That way you know from the start that you won't have to act as a sponsor indefinitely.

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.gzdebian/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

debuilddebsign を使う場合は、~/.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.

何も大きな問題を見つけなければ、新しいバージョンをアップロードします。そうでなければ、メンテナに修正したバージョンをアップロードするよう要請します。



[8] You can find more checks in the wiki, where several developers share their own sponsorship checklists.