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

Debian は、単にソフトウェアのパッケージを作ってメンテナンスをしているだけではありません。この章では、単にパッケージを作ってメンテナンスする以外で Debian へ協力・貢献するやり方、多くの場合とても重要となるやり方の情報を取り扱います。

ボランティア組織の例にたがわず、Debian の活動はメンバーが何をしたいのか、時間を割くのに最も重大だと思われることが何か、というメンバーの判断に依っています。

7.1. バグ報告

我々としては、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 を参照すればいいだけです。

7.1.1. 一度に大量のバグを報告するには (mass bug filing)

大量の異なるパッケージに対して、同じ問題についての非常に多くのバグ (例えば 10 個以上) を報告するのは、推奨されていないやり方です。不要なバグ報告を避けるため、可能な限りの手続きを踏むようにしましょう。例えば、問題の確認を自動化できる場合は lintian に新しくチェック項目を追加すれば、エラーや警告が明確になります。

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

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

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

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

7.1.1.1. Usertag

多数のパッケージに対するバグを登録する際に BTS の usertag を使いたくなるかもしれません。usertag は 'patch' や 'wishlist' のような通常のタグに似ていますが、ユーザが定義する事と特定のユーザに対して一意な名前空間を占めるという点で違っています。これによって、同じバグについて衝突する事無しに、開発者がそれぞれ別のやり方で複数の設定ができるようになります。

バグを登録する際に usertag を追加するには、擬似ヘッダ (pseudo-header) User と Usertags を指定します。

To: submit@bugs.debian.org
Subject: title-of-bug

Package: pkgname
[ ... ]
User: email-addr
Usertags: tag-name [ tag-name ... ]

description-of-bug ...

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=タグ名 を指定してください。

7.2. 品質維持の努力

7.2.1. 日々の作業

品質保証に割り当てられたグループの人々がいたとしても、QA 作業は彼らのみに課せられるものではありません。あなたもパッケージを可能な限りバグが無いように保ち、できるだけ lintian clean な状態 (lintian を参照) にすることで品質保証の作業に参加することができるのです。それが可能ではないように思えるなら、パッケージをいくつか「放棄 (orphan)」してください (パッケージを放棄する 参照)。または、溜まったバグ処理に追いつくため、他の人々に助力を願い出ることも可能です (debian-qa@lists.debian.org や debian-devel@lists.debian.org で助けを求めることができます)。同時に共同メンテナ (co-maintainer) を探すことも可能です (共同メンテナンス を参照してください)。

7.2.2. バグ潰しパーティ (BSP)

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 でパッケージを壊してしまうより、遥かに良いことです。

7.3. 他のメンテナに連絡を取る

Debian と共に過ごす間、様々な理由で他のメンテナに連絡を取りたくなることでしょう。関連パッケージ間での共同作業の新たなやり方について協議したい場合や、開発元で自分が使いたい新しいバージョンが利用可能になっていることを単に知らせたい場合などです。

パッケージメンテナのメールアドレスを探しだすのは骨が折れます。幸いな事に、パッケージ名@packages.debian.org というシンプルなメールのエイリアスがあり、メンテナらの個人アドレスが何であれメンテナへメールを届ける手段となっています。パッケージ名 はパッケージのソース名かバイナリパッケージ名に置き換えてください。

Debian パッケージトラッカー 経由でソースパッケージの購読を行っている人に連絡を取りたくなるかもしれません。その場合は パッケージ名@packages.qa.debian.org メールアドレスが使えます。

7.4. 活動的でない、あるいは連絡が取れないメンテナに対応する

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.

メンテナが４週間 (１ヶ月）応答をしない場合、おそらく反応がないと判断できます。この様な場合はより詳細に確認し、可能な限り問題となっているメンテナに関する有用な情報をかき集める必要があります。これには以下のようなものが含まれています。

  • 開発者 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.

7.5. Debian 開発者候補に対応する

Debian の成功は新たな才能あるボランティアをどう魅了し確保するかにかかっています。あなたが経験豊かな開発者なら、新たな開発者を呼び込むプロセスに関与するべきです。このセクションでは新たな開発者候補者をどうやって手助けするのかについて記述します。

7.5.1. パッケージのスポンサーを行う

パッケージのスポンサーをするというのは、パッケージをアップロードする権限をもたないメンテナーのためにかわりにアップロードするということです。アップロードを軽く考えてはなりません。スポンサーはパッケージを検証し、Debianに含まれるのにふさわしい高水準の品質であることを担保すべきです。

Debian 開発者はパッケージをスポンサーできます。Debian メンテナはできません。

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

  1. メンテナーはソースパッケージ (.dsc) を準備し、オンラインで参照できるどこかにアップロード (例えば mentors.debian.net) や他のどこか適切な場所にアップロードし、パッケージをメンテナンスしている公開されているVCSリポジトリ (salsa.debian.org: Git repositories and collaborative development platform を参照) を示します。

  2. スポンサーはソースパッケージをダウンロード (もしくはチェックアウト)します。

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

  4. スポンサーは、何も問題が残っているのを見つけられませんでした。パッケージをビルドし、署名し、Debian へアップロードします。

どのようにパッケージをスポンサーするのかの詳細を掘り下げるまえに、提案されているパッケージをDebianに追加するメリットがあるのかを問うべきです。

この質問に答えるシンプルなルールは存在しません。様々な要素に依存しうるからです。アップストリームのコードが十分枯れており、脆弱性がまったくないか? 同じようなことができるパッケージがすでにパッケージ化されていないだろうか? そして新しいパッケージはそれらと比較してどんな違いがあるだろうか? 新しいパッケージはユーザーの要望があるだろうか? どれくらいのユーザー数がいるだろうか? アップストリームの開発者はどれくらい精力的に活動しているだろうか?

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

Debianについてどのような立ち位置にあるかを知るのもよいでしょう: 彼らはDebianの哲学に同意し、Debianコミュニティーへ参加するつもりがあるでしょうか? Debianメンバーになることは簡単なので、Debianメンバーになろうと思っている人だけをスポンサーしたいことでしょう。そのようにすれば無期限にスポンサーとして活動する必要がないことが最初からわかります。

7.5.1.1. 新しいパッケージのスポンサーを行う

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 フリーソフトウェアガイドラインに適合し、良い品質であるのを保証するのは、あなたの仕事です。

パッケージをビルドし、ソフトウェアのテストを行うのはレビューの一部ではありますが、それだけでは十分ではありません。この章の残りの部分では、レビューでチェックするポイントの一覧を述べます (徹底的なものではありません)。 [1]

  • 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 を査読する: ベストプラクティスに従っている? (debian/rules についてのベストプラクティス 参照) 改善可能な点がある?

  • メンテナスクリプト (preinst, postinst, prerm, postrm, config) を査読する: 依存関係がインストールされていない時でも動作する? 全てのスクリプトが等羃 (idempotent、すなわち、問題無しに複数回実行できる)?

  • 開発元のファイルに対する変更 (.diff.gz、debian/patches/、あるいは直接 debian tarball に埋め込まれているバイナリファイル) をレビューする。十分な根拠がありますか? (パッチに対し、DEP-3 に沿って) 正しくドキュメント化されている?

  • すべてのファイルについて、そのファイルが何故そこにあるのか、望んでいる結果をもたらすためにそれが正しいやり方かどうかを自身に問いかけてください。メンテナはパッケージ化のベストプラクティスに従っていますか? (パッケージ化のベストプラクティス 参照)

  • 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

7.5.1.2. 既存パッケージの更新をスポンサーする

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.

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

7.5.2. Granting upload permissions to DMs

Debianメンテナーの鍵はdebian-maintainersキーリングに追加され、Debian開発者は特定のパッケージに関するアップロード権限をDMに許可することがあります。 これは署名したdakコマンドを FTP-Masterによるdebian-develへのアナウンス のとおりにftp.upload.debian.orgにアップロードすることで行います。

このプロセスは dput-ng パッケージに含まれる dcut コマンドにより簡略化できます。 dput パッケージの dcut では動作しないことに注意が必要です!

例:

dcut dm --uid 0xfedcba9876543210 --allow nano --deny bash

DMの鍵がキーリングパッケージに含まれていないがDDのローカルのキーリングに含まれている場合、--force オプションとスペースを含まないフィンガープリントを指定します。とりわけ0xというプレフィクスをつけず、すべて大文字を指定します。

dcut --force dm --uid FEDCBA9876543210FEDCBA9876543210 --allow nano

7.5.3. 新たな開発者を支持する (advocate)

Debian ウェブサイトの開発者志願者の支持者になる (advocating a prospective developer)のページを参照してください。

7.5.4. 新規メンテナ申請 (new maintainer applications) を取り扱う

Debian のウェブサイトにある 申請管理者用チェックリスト (Checklist for Application Managers) を参照してください。