Packaging 101
- 講演者
Daniel Holbach (dholbach)
- コーディネータ
Alan Pope (popey) / Lorenzo J Lucchini (LjL)
- 日時
- 2007年10月23日15時〜17時(UTC) / 24日19時〜21時(UTC)
- 原文
- 翻訳者
- Shibata
セッション1
Packaging 101セッションへようこそ！
私の名前はDaniel Holbach。Canonical社員であり、MOTUの一員でもあり、他のいくつかのUbuntuチームの一員でもあります。現在は、MOTUの作業をより簡単で楽しいものにすべく働いています。もし質問や提案、心配事があるなら、気軽に[email protected] までメールを送ってください。このセッション中に質問したい場合は、#ubuntu-classroom-chatにて、先頭にQUESTIONをつけて発言してください。
さて、この中ですでにUbuntuにパッケージやパッチを提供している方はいますか？いや、すでにパッケージングツールを楽しんでいる方はいますか？ 
多くの聴衆が、はいと応える
すばらしい！なかなかいい滑り出しです。:-)
本日のセッションでは、Ubuntu開発者がよく行う次の作業について説明します。1) 上流(upstream)で新しくリリースされたときに、パッケージをアップデートする方法、2) debdiffを提供する方法の二つです。なぜこの二つが重要なのか？この作業は本当に頻繁に行われるますし、これらをうまく使えるようになることは、Ubuntu開発者になるための最初の一歩としては良い実例になるからです。
どのようにして、Ubuntu開発者になるのか。まず最初はMOTU(Master Of The Universe)になることです。その方法については http://wiki.ubuntu.com/UbuntuDevelopers に書かれています。要約すると：
- パッチや新しいパッケージを提供する
- 審査チーム(reviewer team)によって、審査がなされる
- 引受人(sponsor)によってアップロードされる
- 上記を何度か繰り返すと、引受人があなたに「そろそろ、あなた自身がやった方がいい」と言う
- MOTU評議会に参加申請をする
という流れになります。http://wiki.ubuntu.com/SponsorshipProcess にはアップロードを引き受けてもらうための方法が説明されています。また、あなたが提供したパッケージは、引受人のGPG鍵で署名されます。審査の流れはとっても簡単です：そのソースパッケージにリンクしたバグを提示するか、パッチを添付します(debdiff)、そしてubuntu-main-sponsors(mainかrestrictedのパッケージの場合)かubuntu-universe-sponsors(universeかmultiverseのパッケージの場合)のどちらかに登録します。
ここまでで何か質問はありますか？
<oly->の発言：自分が書いたアプリケーションをパッケージングしたとき、私はdpkg-deb -b フォルダというコマンドを利用した。ところがこの方法を使うべきでないと言われたんだが、それはなぜ？正しくないの？
パッケージ作成の方法にはいろんなやり方があります。http://wiki.ubuntu.com/PackagingGuide/Basic を読むといいでしょう。またそこには、debian/ディレクトリに必要なものも載っています。さらに助けが必要な場合は、[email protected] にメールを送ってください。
<oly->の発言：いろんなやり方があるのは知っているのだけれど、なぜさっきのやり方を使うべきでないのかを知りたい。
それに答えるためには、あなたのソースパッケージを確認する必要がありますね。
<scorpioxy>の発言：pyGTKで書かれたGnomeアプレットをパッケージ化する場合に、何か特別なことをする必要はある？
いいえ、比較的簡単に行えます。http://wiki.ubuntu.com/PackagingGuide/Basic とpython referenceパッケージも読むといいでしょう。必要ならubuntu-motu-mentorsのMLで質問してください。
<evarlast>の発言：ドキュメントが点在していたり重複していたりしているけどどうするの？Pythonアプリケーションやeggを使ったPythonライブラリ、Monoアプリケーションとライブラリ、Rubyアプリケーションなどのパッケージ作成方法について書かれたドキュメントは作成しないの？
いい質問です。ここ一週間はその件に関して作業をしていました。私の計画では、http://wiki.ubuntu.com/PackagingGuide と http://wiki.ubuntu.com/UbuntuDevelopment にすべての物を置く予定です。
<tuxmaniac>の発言：Debian testingとUbuntuを同期させるのはどうしたらいい？"謝辞"以外のメンテナやMOTUに参加する？
同期プロセスは簡単です： 1) (差分を読んだり、ビルドテストやインストールテストを実施することで)Debianから新しいバージョンを同期できることを確認します。2) 同期のリクエストを添えて不具合を報告します。これらについては、http://wiki.ubuntu.com/UbuntuDevelopment でも説明(もしくはリンク)されています。
<DrDabbles>の発言：パッケージに上流のアップデートを適用したが、universeやmultiverseにはそのパッケージがなかった。どうすればいい？
http://wiki.ubuntu.com/UbuntuDevelopment#NewPackages にやるべきことが記載されています。あなた自身の手でパッケージを作成するか、誰かに頼むことになるでしょう。どちらも、やり方がそのページに書かれています。http://wiki.ubuntu.com/SponsorshipProcess と http://wiki.ubuntu.com/UbuntuDevelopers にはパッケージの作成方法の流れがまとめられていますので、パッケージングに興味があるならブックマークしておくとよいでしょう。MOTUチームのメンバーについては、#ubuntu-motuやhttp://wiki.ubuntu.com/MOTU で見つけることができます。質問があるなら、http://lists.ubuntu.com/ubuntu-motu-mentors のメーリングリストで尋ねることもできます。
<DrDabbles>の発言：聞きたかったのは、パッケージをmainにいれるべきか、universeにいれるべきかについてなんだ。
そうでしたか。mainにパッケージを提供したい場合は、いくつかの条件を満たす必要があります。その手順に関してはhttp://wiki.ubuntu.com/UbuntuMainInclusionRequirements を読むといいでしょう。
<tikal26>の発言：誰か他の人が何かをパッケージ化しようとしているのは、どうやって確認しているの？
http://launchpad.net/ubuntu/+bugs にて、needs-packagingで(タグを)フィルタすると確認することができます。もしくはhttp://revu.tauware.de を確認してください。Debianでの作業を確認したいなら、http://bugs.debian.org/wnpp を読むといいでしょう。
さて、パッケージをアップデートする作業にはいりましょう。まず最初に/etc/apt/sources.listに次のようなdeb-srcエントリがあることを確認してください。
deb-src http://archive.ubuntu.com/ubuntu gutsy main restricted universe multiverse
これはGutsyの場合です。次に、DEBFULLNAMEとDEBMAIL環境変数を設定します。私の場合、次のような内容が~/.bashrcファイルに書かれています。
export DEBFULLNAME='Daniel Holbach' export DEBEMAIL='[email protected]'
そのファイルにこのような行がなければ、みなさんの名前とアドレスに置き換えて追加してください。これらの環境変数はいくつかのツールで利用されていて、設定しておくと手動で入力する手間が省けます。(セッション3より追加：この後、source ~/.bashrcを実行するか端末を再起動してください)
その後、以下の方法で必要なソフトウェアをインストールします。
sudo apt-get install devscripts build-essential wget cdbs fakeroot liburi-perl debhelper
build-essentialはビルド環境(makeやgcc他)を構築するための必要最低限なパッケージをインストールしてくれます。devscriptsには、より簡単にパッケージを作成できるツールが含まれています。それ以外については、http://wiki.ubuntu.com/PackagingGuide のBuildToolsセクションに説明されています。
<mruiz>の発言：開発環境(hardy chrootやpbuilder他)を用意する方法を説明してくれるとうれしい。
このチュートリアルでは長くなりすぎるので、chrootやpbuilderについて説明する予定はありません。
さて、古いパッケージのソースを手に入れましょう。ちょっと古い例ではありますが、brasero 0.5.2をbrasero 0.5.90にします(私にとって都合がいいのです…… :))。アーカイブからソースを取得する方法としてapt-get source braseroを使う代わりに
dget -x http://people.ubuntu.com/~dholbach/motu/brasero_0.5.2-0ubuntu1.dsc
を実行します。ダウンロードが完了したら、.orig.tar.gzと.diff.gz、.dscファイルがダウンロードされているはずです。.orig.tar.gzは上流で作成され提供されているソースアーカイブです。.diff.gzには、パッケージメンテナによって加えられた変更点が圧縮して含まれています(セッション3より追加：ビルドサービスによりビルドされるときにこの変更点が適用されます)。.dscファイルはテキスト形式のdescriptionファイルです。(セッション3より追加：dget -xはソースアーカイブをダウンロードし、展開し、変更点を適用してくれます)
今度はアップデートしたい新しいソースファイル(0.5.90)を、上流から手に入れます。
wget http://people.ubuntu.com/~dholbach/motu/brasero-0.5.90.tar.gz
次にそのファイルを展開します。
tar xfz brasero-0.5.90.tar.gz
そして、ファイル名を.orig.tar.gzに変更します。
mv brasero-0.5.90.tar.gz brasero_0.5.90.orig.tar.gz
パッケージ化の際の変更箇所をコピーします。今回の場合はdebianディレクトリをコピーするだけです。
cp -r brasero-0.5.2/debian brasero-0.5.90/
このパッケージをビルドするために必要なパッケージ(build-dependencies)をインストールします。
sudo apt-get build-dep brasero
(セッション3より追加：debian/controlを見ると最初の一節ソースとBuild-Dependsについて書かれていることに気づくでしょう。次の一節では、Dependsについて述べられています。Dependsは、バイナリパッケージをインストールするために必要なパッケージです。Build-Dependsはそのパッケージをビルドするために必要なパッケージです。Ubuntuのビルドデーモンは最初のビルド環境のみを持っているので、このBuild-Dependsにて必要なものを指定する必要があります)
さて、ここまでで何か質問はあるでしょうか？
<Knightlust>の発言：なぜ、審査サイトのホスト名はrevu.tauware.deなの？revu.ubuntu.comでないのは何故？
いい質問です。これはパッケージの審査を補助するためにコミュニティによって作成されたものなのです。長い間、.ubuntu.comからリダイレクトされたか.ubuntu.comのホスト名を持っていたと思います。今のところ私に言えるのはこれがすべてです。
<kavoor>の発言：例えばFirefoxの1.5のような古いバージョンはどこで手に入れられるの？
Launchpadを確認するのがいいでしょう：http://launchpad.net/ubuntu/+source/firefox 古いバージョンはすべてそこで手に入れることができます。
<gonzalo>の発言：他のパッケージの場合はどこから手に入れたらいい？Synaptic？手に入れるための標準的な場所はある？
ソースファイルについて言っているのなら、apt-get sourceかsynapticを使うといいでしょう。
<DrDabbles>の発言：新しいバージョンでビルドに必要なパッケージ(build-dependencies)が変更されているときは、手動でビルドに必要なパッケージをインストールして、パッケージのメタデータを変更するの？
とてもいい質問です。次のコマンドを実行してみてください。
diff -u brasero-0.5.{2,90}/configure.in二つのリリース(0.5.2と0.5.90)の間で、次の例のようにビルドシステムにいくつかの変更点が加えられていることに気づくでしょう。
-LIBBURN_REQUIRED=0.2.3 +LIBBURN_REQUIRED=0.3.4
例えば、この変更点をdebian/controlに反映させる場合を考えます。brasero-0.5.90/debian/controlを探せば、Build-Dependsという行が見つかるはずです。ここには、パッケージをビルドする際にインストールされているべきすべてのパッケージを指定します。braseroの今回のバージョンでは、libburnではなくlibnautilus-burnを使っているので、この変更点は関係ありません。ただし、通常は重要な確認事項です。
<Sophomore>の発言：debianディレクトリをコピーするよりは gzip -dc ../brasero*diff.gz | patch -p1 を実行した方が安全じゃない？たぶん、~のついたバックアップファイルがコピーされないと思うんだけど。
そのとおりです。debian/watchファイルやuupdateを利用した方がいいでしょう。今回は簡単な方法を選びましたが、あなたの意見は正しいと思います。
<ian_brasil>の発言：審査サイトに自分の鍵を登録できる？ウェブページに書いてあるメールアドレスは間違っていると思うんだけど。
#ubuntu-motuで聞いた方がいいでしょう。何人かの審査サイトの管理者が常駐していますから(これで回答になっていなければ、http://wiki.ubuntu.com/REVU を確認してください)。
<tuxmaniac>の発言：自分のマシンに、自分のパッケージに関するbuild-dependencesをインストールしたくないのだけれども、すべての作業が完了したら、インストールしたbuild-dependenciesを削除する方法はある？
いい質問です。pbuilderが良い例になるでしょう：http://wiki.ubuntu.com/PbuilderHowto これは、パッケージをインストールしたり削除できるchroot環境を作成するもので、ビルドのためにクリーンで最小の環境を作成するのに適しています。このセッションでは時間がないのでchrootの設定については説明できません。
<andresmujica>の発言：開発者ではない人間がパッケージ化を行う一番簡単な方法は何？
パッケージ化の作業においてコーディングの経験はあまり必要ありません。それよりも重要なのは、十分に気をつけてテストすること、ドキュメントを読むこと、相談し、何かを作ることに興味があり、臆せず実行できることです。http://wiki.ubuntu.com/MOTU/TODO や http://wiki.ubuntu.com/MOTU/Bugs には、新しく貢献したい人のために、やるべき作業の一覧が載っています。とりあえず'bitsize'の作業を確認してみてはどうでしょうか。
さて、次に進みましょう。準備はいいですか？ビルドに必要なパッケージはインストールされましたか？
Ubuntuへアップロードするためには、changelogに新しく変更点を追加する必要があります。以下のコマンドを実行してください。
cd brasero-0.5.90 dch -i
すでにいろんな項目が記入されていることに気づくでしょう。前に触れたDEBFULLNAMEとDEBMAILの値が使われています。アップロードターゲット('gutsy')は実行した場所に依存します。バージョンの部分は0.5.90-0ubuntu1に変更します。ここで、0.5.90は上流のバージョンです。0ubuntu1は(Debian版にマージされずに)Ubuntuへ最初にアップロードされたことを意味します。0.5.90-1なら、まず最初にDebianにアップロードされてそれに同期しようとしていることを意味します(パッケージ化の方法の違いに依存します)。
アップロードターゲット('gutsy'か'feisty'になっているでしょう)を'hardy'に変更してください。Ubuntuでは、「現在の開発版」に対してのみアップロードが行えます。Gutsyはもうリリースされたので、バージョンアップは行えず、gutsy-updatesとgutsy-securityに対してのみアップロードが行えます(-proposedや-backportsなどもあります)。
changelogには"New Upstream release"と記入し、ファイルを保存してください。そして以下のコマンドを実行します。
debuild -S -sa
これによりソースパッケージが作成されます(.diif.gzと.dscファイルが作成されます)。GPGが設定されていなかったら警告が出るかもしれませんが、今回はかまいません。このセッションが終わったあとに、https://help.ubuntu.com/community/GnuPrivacyGuardHowto を読んでください。Ubuntu開発者になるなら必須です。:)
(セッション3より追加：この時点で
brasero_0.5.2-0ubuntu1.diff.gz brasero_0.5.2-0ubuntu1.dsc brasero_0.5.2.orig.tar.gz brasero_0.5.90-0ubuntu1.dsc brasero_0.5.90-0ubuntu1.diff.gz brasero_0.5.90-0ubuntu1_source.build brasero_0.5.90-0ubuntu1_source.changes brasero_0.5.90.orig.tar.gz
これらのファイルがあるはずです)
<ian_brasil>の発言：自分は現在、いくつかの文書を自分のPPAのuniverse/develにアップロードしている。これにはGutsyとHardy、どちらのターゲットラベルを利用すべき？
HardyにインストールしたいならHardyを利用すべきでしょう。Hardyはすでに設定完了しているでしょうし、PPAも使えるはずだと期待しています。詳しいことは#launchpadで尋ねるといいでしょう。もしレビューとテストが目的なら'gutsy'を利用すると良いでしょう。
<ian_brasil>の発言：自分の作業結果を誰かにレビューしてもらいたい場合、どのファイルを送る必要があるの？
最善の方法はどこかにアップロードし、.dscファイルのURLを伝えることです。そうすれば、
dget -x <URL>
を実行するだけで必要なパッケージファイルがダウンロードされます。アップロードする必要があるのは.orig.tar.gz、.diff.gz、.dscファイルです。
<tuxmaniac>の発言：このパッケージはDevianのリビジョンナンバーを持っているが、親ディレクトリには適切なtarファイル、もしくは.origディレクトリがあるようには思われない。.orig.tar.gzは持ってるがうまくいかない。何を間違っているんだろう？
以下の出力はどうなっているでしょうか？
daniel@bert:~$ ls *.tar.gz brasero_0.5.2.orig.tar.gz brasero_0.5.90.orig.tar.gz daniel@bert:~$
そして、debian/changelogの(新しいチェンジログエントリに)バージョン番号を0.5.90-0ubuntu1に変えましたか？
<tuxmaniac>の発言：はい。
そこまでできているなら、あとはdebuild -S -saをもう一度実行するだけです。
さて、パッケージのテストビルドを行いましょう。これまでに、ソースに修正を加え、ソースパッケージを作成しました。ソースパッケージはUbuntuビルドデーモンにアップロードされれば、バイナリパッケージが作成されますが、ローカル環境でテストすることも大事です。というわけで次のコマンドを実行してください。
debuild -us -uc
これでパッケージがビルドされますが、パッケージに署名は行われません。:-)
おそらく完了するまでに時間がかかるでしょうから、その間に質問を受け付けましょう。
<popey>の発言：コンパイルが失敗したよ。
どんなエラーメッセージが出ました？
<popey>の発言：http://pastebin.ubuntu.com/1242/
すみません、こちらでも問題が発生しました。
data-disc.c:89: Fehler: expected specifier-qualifier-list before »GtkTooltips« data-disc.c: In Funktion »brasero_data_disc_get_property«: data-disc.c:602: Fehler: »BraseroDataDiscPrivate« hat kein Element namens »reject_files« data-disc.c: In Funktion »brasero_data_disc_set_property«:
これはbraseroの新バージョンでは解決していると思われます。みなさんを巻き込んでしまって申し訳ありません。ちょっと今すぐには解決できそうにありませんし、次のセッションまで5分ほど休憩しましょう。
セッション2
ではセッション2を始めましょう。
さきほどはすみませんでした。休憩時間の間に解決策を見つけておきました。;-)
少し前に、誰かが#ubuntu-classroom-chatで「これは良い例だ」と言っていましたが、本当にその通りだと思いました。なぜなら、MOTUの仕事は探偵の仕事と同じである場合があることを示してくれたからです。:)
(セッション3より追加：このような不具合に遭遇したとき、まず上流を確認します、またDebianや他のディストリビューションで同じようなことが起こってないか確認します)
以前にも言ったように、上流の新バージョンではこの問題が解決しているので、以下のコマンドで新しいソースを入手してください。
wget http://ftp.gnome.org/pub/gnome/sources/brasero/0.6/brasero-0.6.1.tar.gz
<rootvzla>の発言：この作業はpbuilderを使ってもできる？pbuilderのガイドは別に読んだ方がいい？(訳註：一部スペイン語)
スペイン語を喋れないのですが、おそらくその通りです。pbuilderを使っても行えますし、その使い方についてはhttp://wiki.ubuntu.com/PbuilderHowto に掲載されています。設定ができているなら、
sudo pbuilder build file.dsc
を実行してください。pbuilderの使い方については、このセッションでは扱いません。
さて、tarボールが手に入ったら、以下のコマンドを実行してください。
mv brasero-0.6.1.tar.gz brasero_0.6.1.orig.tar.gz tar xfz brasero_0.6.1.orig.tar.gz cp -r brasero-0.5.90/debian brasero-0.6.1 cd brasero-0.6.1 dch -i
そして新しいチェンジログエントリを追加し、バージョン番号を0.6.1-0ubuntu1に変更します。チェンジログエントリ内部には、"New upstream release"とでも書いておいてください。メンテナによっては、ここに上流で加えられた変更点の中でも重要なものを記載します。変更点に関する情報は、大抵の場合はNEWSファイルを参照すると良いでしょう。ファイルを保存し、
debuild -S -sa
を実行してください。ようやく、以下のコマンドでパッケージをビルドすることができます。:-)
debuild -us -uc
<matthe1>の発言：以下のエラーが表示されたよ：
matthew@matthew:~/brasero-0.6.1$ dch -i dch: fatal error at line 391: Cannot find debian/changelog anywhere!
前のパッケージから、debian/ディレクトリをコピーしていませんね。
cp -r brasero-0.5.90/debian brasero-0.6.1
みなさんは、成功しましたか。これで最初のパッケージが作成されました。:)
次に興味のあることは、このパッケージにどのような変更点が加えられたかということです。
cd ..; wget http://people.ubuntu.com/~dholbach/motu/brasero_0.5.2-0ubuntu1_i386.deb
を実行して、以前のバイナリパッケージを手に入れます。さらに、そのバイナリパッケージと今回作成したバイナリパッケージを比較します(ファイル名はi386を利用している場合)。
debdiff brasero_0.5.2-0ubuntu1_i386.deb brasero_0.6.1-0ubuntu1_i386.deb
ファイルの変更点や、依存性の変更点が表示されるでしょう。これはメンテナが、ファイルが失われていないかどうかなどを確認するために重要なものになります。
以上が、最初に皆さんに伝えたかったことです：パッケージのアップデートはとっても簡単で、Ubuntuに参加するための良いステップの一つなのです。seb128やloolは常にデスクトップチーム(Desktop Team)への新しい参加者を探しています。彼らは数多くのGNOMEアップデートを行う必要があるからです。#ubuntu-desktopやhttp://wiki.ubuntu.com/DesktopTeam/TODO を訪れれば、参加する方法がわかるでしょう。:)
'upgrade'というタグがつけられhttp://wiki.ubuntu.com/MOTU/Bugs にリンクがはられたバグもたくさんあります。
では、次の例にいきましょう。その前にここまでで何か質問はありますか？
<afranke>の発言：パッケージのアップデートは、パッケージメンテナに委ねられているのではないの？
すばらしい質問です。Ubuntuではパッケージの管理はすべてチームごとに行われています。GNOMEに関係するすべてのパッケージは、デスクトップチーム(Desktop Team)に尋ねる必要があります。Telepathy(訳註：インスタントメッセンジャなどに使われているD-Busフレームワークの一つ)に関係するパッケージはTelepathyチームに、と言った具合です。http://wiki.ubuntu.com/Teams にはすべてのチームへのリンクが掲載されています。
<evarlast>の発言：!DesktopTeam/TODOには最初に"needs UVFe"と書かれているが、UVFeって何？そして、パッケージ作成者などがよく使う頭字語の情報はどこを探せば良い？
それは、この前のリリースから残ったままになっているものですね。UVFeはUpsteram Version Freeze exception(上流バージョンの凍結の適用除外)を意味します。http://wiki.ubuntu.com/GutsyReleaseSchedule にはGutsyのリリーススケジュールが載っていますが、Upstream Version Freeze(上流バージョンの凍結)は、この時点以降、承認なしには上流の新しいバージョンを利用しないということです。freeze exception(凍結の適用除外)に関する話は、http://wiki.ubuntu.com/FreezeExceptionProcess に掲載されています。
<rootvzla>の発言：pbuilderはfeisty fawnやgutsy gibbonなどあらゆるバージョンで動作するのか、それとも一つのバージョンのみで使えるのか。
ubuntu-dev-toolsパッケージのpbuilder-distが参考になるでしょう。
では次に行きましょう。
(セッション4より追加：簡単な不具合を修正してみます。このような不具合リストはhttp://wiki.ubuntu.com/MOTU/TODO やhttp://wiki.ubuntu.com/MOTU/Bugs などに'bitesize'タスクとして表示されています)
例えば、xiccパッケージの概要(description)部分について、「"colour"は"color"にすべきだ」というバグレポートをもらったとしましょう。直す必要のない内容なので、普段ならおそらく却下(reject)されるでしょうが、練習にはちょうどいいので、変更してみることにしましょう。
まず、この報告が事実かどうかを確認します。
apt-cache show xicc
と実行すると、概要(description)の部分に
This utility lets you set an ICC colour profile for an X display, so that applications can use it to display colour calibrated images. Applications have to specifically look for this atom but several applications such as Gimp and Eye Of Gnome already do.
と表示されます。どうやら作業を行わなくてはいけないようです。:-)
以下のコマンドでソースコードを入手してください：
dget -x http://people.ubuntu.com/~dholbach/motu/xicc_0.2-2.dsc
(セッション4より追加：繰り返すようですが、これにより.orig.tar.gzと.diff.gzと.dscファイルがダウンロードされ、自動的に展開されます)
パッケージの概要は、debian/controlファイルの中に書いてありますので、
cd xicc-0.2 sed -i 's/colour/color/g' debian/control
を実行して修正します(もしくは、debian/controlファイルをお好みのエディタで開き、修正してください)。次に、チェンジログエントリを編集します。
dch -i
"hardy"にアップロードすること、そして変更点をはっきりと書きます。"* debian/control: change all occurences of 'colour' to 'color'"などが良いでしょう(セッション4より追加：これは重要な作業です。特にUbuntuの場合はチーム全体でパッケージの管理を行うので、他のメンテナが簡単に確認できるようにしておく必要があります)。バージョン番号は0.2-2ubuntu1にします。"0.2"は上流のバージョンです。"-2"はDebianのリビジョンです。"ubuntu1"は私たちが修正したことを意味します。
ファイルを保存し、
debuild -S
を実行してソースパッケージを作成します。成功しましたか？私は次のようなメッセージが表示されました。
dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address debuild: fatal error at line 1247: dpkg-source -b xicc-0.2 failed
これは次のURLによるものです：http://wiki.ubuntu.com/DebianMaintainerField
Debianの友人達は私たちに、私たちがパッケージを修正したときはメンテナフィールド(maintainer field)を変更するようにと依頼してきました。そのため、debian/controlに修正を加える必要があります。
Maintainer: Ross Burton <[email protected]>
の部分を、
XSBC-Original-Maintainer: Ross Burton <[email protected]> Maintainer: Ubuntu MOTU Developers <[email protected]>
に変えてください。オリジナルなメンテナの名前は残しておいて、Universeパッケージのメンテナ名をMOTUチームにします。
幾人かはこのエラーが表示されないようですが、それはとても奇妙です。あとで調査しておきます。http://wiki.ubuntu.com/DebianMaintainerField はポリシーとして決定しているので、それに従う必要があります(そのため、ubuntu-dev-toolsパッケージのupdate-maintainerツールが自動的にやってくれるのかもしれません)。
さて、ソースパッケージをビルドすることにしましょう。
debuild -S
(セッション4より追加：この時点で、以下のようなファイルができているはずです。
xicc_0.2-2.diff.gz xicc_0.2-2ubuntu1.diff.gz xicc_0.2-2ubuntu1_source.build xicc_0.2.orig.tar.gz xicc_0.2-2.dsc xicc_0.2-2ubuntu1.dsc xicc_0.2-2ubuntu1_source.changes
)うまくできたら、以下のコマンドを実行してください。
cd ..; debdiff xicc_0.2-2.dsc xicc_0.2-2ubuntu1.dsc
変更点が表示されるはずです(前のセッションでこのツールを使ったときは、.debパッケージに対する変更点を表示したことに注意してください)。
誰かdebdiffの結果をhttp://pastebin.ubuntu.com/ に張り付けてもらえますか？
<savvas>の発言：debtags(それぞれのdebパッケージのタグ)はどこに保存されるの？
正直に言うと、debtagsを使ったことがありません。どうやら/var/lib/debtagsにあるようです。これについて詳しいmvoを呼んでみましょう。
<mvo>の発言：debtagsは現在、/var/lib/debtagsにダウンロードされます。Debianではパッケージファイルの中にありますが、Ubuntuの場合は違います。
これで回答になりましたか、savvas。ありがとうmvo。みなさん、AptヒーローなMichael 'rockstar' Vogt(mvo)に拍手をお願いします。
さて、誰か成功したdebdiffの結果をpastebin.ubuntu.comに張り付けてくれましたか？
<giftnudel>の発言：http://pastebin.ubuntu.com/1243/
すばらしい。たしかにうまくいっているようですね。では、
debdiff xicc_0.2-2.dsc xicc_0.2-2ubuntu1.dsc > xicc_0.2.2ubuntu1.debdiff
としてdebdiffの結果をファイルに保存します。これでhttp://wiki.ubuntu.com/SponsorshipProcess を用いて審査をうける準備ができました。
もし不具合に出くわし修正したい場合は、そのdebdiffファイルを添付して送信してください。パッケージがuniverseかmultiverseに属する場合はubuntu-universe-sponsorsに、mainかrestrictedに属する場合はubuntu-main-sponsorsに送ります。これはMOTUになるための道のりの一つです。:)
(セッション4より追加：実際の不具合報告の際には、チェンジログエントリに (LP: #1234567) のように修正した不具合の番号(今回だと1234567)を記載してください。これにより、修正パッケージをビルドデーモンが受け入れたとき不具合が自動で閉じられます)
何度か審査が成功し、チームに覚えられ、推薦されると、MOTUへの参加依頼がやってくることでしょう。
<tuxmaniac>の発言：このdebdiffでいいのかな http://pastebin.ubuntu.com/1246/
debdiffを実行する時に.dscファイル順番を逆にしませんでしたか？
<tuxmaniac>の発言：逆でした
あと、チェンジログエントリを重複して追加していますね。
<kongo>の発言：一つのソフトウェアに対して、DebianとUbuntuでメンテナを分けるのは良い考えかな？
パッケージの管理と作業をする人がまったく別なら。ただ、DebianとUbuntuのメンテナ(それに上流の開発者を含むその他の人)が協力をすることは大事です。
<kongo>の発言：別な場合もあるけれど、同じ場合もあるね。
メンテナフィールドにあなたの名前が書かれるというのは、どういう意味であるととらえているのでしょうか。
- 私はこのパッケージを管理しています
- 私はこのバグが修正されたことを確認します
メンテナフィールドに名前が書かれるということは本当に強い義務が発生します。
<kongo>の発言：自分が考えているのは、Debianパッケージを除外したUbuntuパッケージを作るということ。Debianからの派生でないUbuntuパッケージを意味している。
あなたがDebianパッケージへマージしないという決定をすること自体は正しい選択かもしれませんが、二重の努力が必要になるかもしれません。そのパッケージに興味を持っている他の人にも連絡を取り、一緒に協力して作業を行う方が良いと思います。
<afranke>の発言：パッケージがunvierseでもmainでもない場合は、どこに登録したら良い？
例えば(main/restricted/universe/multiverseではないものとして)どのようなことを考えておられるのでしょうか？
<afranke>の発言：リポジトリにまだ登録されていないような新しいパッケージ、"needs-packaging"なパッケージを考えている。
その場合、すべてuniverseに登録することから始まります。
<evarlast>の発言：Ubuntuパッケージをアップデートする場合も同じ方法でいいのかな。例えばGutsyでは、pkgx-1.2.3を利用しているけれども、自分はpkgx-1.3.4を使いたいとする。この場合も同じ方法でdebdiffを送ればいいの？
はい。おおよそこのセッションでやった通りの方法になります。審査を受ける場合、PPA(http://help.launchpad.net/PPAQuickStart )もしくはREVU(http://wiki.ubuntu.com/REVU )を使いたいかもしれません。また、別のチームではまったく違う審査方法を採用している場合もありますが、スポンサーチーム(sponsoring team)に不具合を登録するのがもっとも一般的な方法です。
<evarlast>の発言：PPA用に自動的なにアップデートを検知する方法はあるだろうか？PPAは、誰かが何かをUniverseにアップロードしたりアップデートした時、自動的にバグをそのパッケージに関連付けたり、バグを登録できるスマートなやり方はあるだろうか。
そのために、私はppaputを作成しました(ubuntu-dev-toolsパッケージにあります)。使い方についてはmanpageをご確認ください。
<evarlast>の発言：ppaputはdputの代わりに使えるの？
はい、そうです。若干文法(syntax)は違いますが、基本的に同じです。ソースパッケージをビルドし、バグを登録し、PPAにアップロードできます。ppaputはまだ若干の問題を抱えていますが、直す予定です。
他に質問はありませんか？ このセッションののことでも、MOTUになる方法でも、Ubuntuの開発に関することでも。:-)
セッション中に問題はありませんでしたか？(0.5.90がビルドできないことを除いて) 退屈はしませんでしたか？
<amarillion>の発言：JAVAで書かれたソフトウェアをパッケージ化しようとしている。しかし、pbuilderが依存パッケージとしてsun-java5-binを使うことを許してくれない。どうすればいい？
pbuilderのソースにmultiverseを追加しましたか？ 方法については次のページで説明されています：http://wiki.ubuntu.com/PbuilderHowto
<Hobbsee>の発言：sun-java5-binがライセンスへの同意を要求するから、pbuilderが落ちるんじゃないかな？
<amarillion>の発言：問題はJAVAライセンスの確認のために、sun-java5-binを自動でインストールできないことなんだ。
これについてはdokoに尋ねるか、回避方法を[email protected] に聞いた方がいいでしょう。
<Riddell>の発言：icedteaを使ってみたら？
<amarillion>の発言：試してみたけれど、クラッシュしたよ。:(
<Riddell>の発言：たしかに。管理者はこの問題に気づいているので、すぐに修正されることを期待しよう(あなた個人でpbuilderを使うなら、pre-seed debconfを利用する手もある)。
<slytherin>の発言：evarlastも質問していたけれど、UVFEとSRUについて教えておくれ。
UVFeについては前に説明しましたが、Upstream Version Freeze exception(上流バージョンの凍結の適用除外)な状態を意味します。SRUはStable Release Update(安定版に対するアップデート)の略であり、次のような手順を要求します：http://wiki.ubuntu.com/StableReleaseUpdates
システムの安定性を維持するために、この手順では例えばgutsy-updatesなどにアップロードするために、より入念なテストが必要になります。
<hydrogen>の発言：無料のアイスクリーム(free ice cream)はどこにある？
良い質問です。見つけたらぜひ教えてください。:)
<afranke>の発言：あるパッケージに対して二種類のバージョンをパッケージ化し、(例えば互換性が理由などで)両方ともUniverseにいれたい場合はどうすればいい？
ソースパッケージとバイナリパッケージの名前を変える必要があるでしょう。例えば(上流のスナップショット(snapshot)をパッケージ化したい場合は)pingusとpingus-snapshotのようにです。
他に質問はありませんか？
今、MOTUになりたいと思っている人はいませんか？
チームへの参加に興味がある人はいませんか？
<savvas>の発言：出席できなかったのだが、新しく「修正された」パッケージはどこにアップロードもしくは送信すればいいのだろうか？
例えばどのようなものでしょう？
<savvas>の発言：もしパッケージに大小問わず変更を加えたとき、どこにアップロード・送信すればいいのだろうか？
すべてのアップロードにおいて、http://wiki.ubuntu.com/SponsorshipProcess の手順でスポンサーを手に入れる必要があります。debdiffかソースパッケージ(.diff.gz .orig.tar.gz .dsc)へのリンクを用意してください。
<amarillion>の発言：orig.tar,gzのサイズに制限はある？ (もう一度言うがJavaパッケージのような)Linuxシステムには不要なものを含む、大量のライブラリに依存するものを見たことがあるんだけれど。
いいえ、制限はありません。例えばopenoffice.orgのソースは数百メガバイトにもなります。:)
ただ、なるべく既存のパッケージのコンポーネントを再利用するようにはしています。不幸なことにそれがうまくいかない場合は、上流の作者に相談すべきでしょう。
<amarillion>の発言：今回の場合、パッケージは60Mbほどで、大量のjarファイルが含まれている。
ソースからビルドすることを推奨します。それぞれについて、ソースからビルドして別々にパッケージ化してみてはどうでしょうか。Javaの場合、簡単にはいかない場合がありますが。:-/
<slytherin>の発言：それらのjarファイルがUbuntuで利用可能かを確認し、それに応じてビルド依存性を変えるといいよ。
<amarillion>の発言：うん、何度か試したことあと、Javaのパッケージ化に飽き飽きしてきたよ。
dokoかubuntu-javaメーリングリストのメンバーに相談すると良いかもしれません。
<scorpioxy>の発言：あるパッケージの不具合を修正するとき、依存する別のパッケージのアップデートが必要になったらどうすればいい？ 両方とも別々にパッケージ化すればいい？
はい。そして依存するそれぞれについて、不具合のレビューを伝えてください。
<slytherin>の発言：Javaの問題に関して、--save-after-loginオプションを使い、chroot内でJavaパッケージを手動でインストールすることは可能？
どういうことでしょう？
<slytherin>の発言：sudo pbuilder login --save-after-loginを実行した後にinstall sun-javaは可能？
あぁ。おそらく大丈夫でしょうが、試したことはありません。
それではセッションを終了しましょうか。参加してくれた皆さまありがとうございました。すぐにMOTUになって、MOTUメーリングリストや#ubuntu-motuで出会えることを期待しています。参加するにはhttp://wiki.ubuntu.com/MOTU を確認してください。では、ありがとうございました。
セッション3
(訳註：基本的な流れはセッション1,2と同じなので、質疑応答部分だけを抜き出して翻訳しています)
<amarillion>の発言：新しいパッケージに対して、引受人(sponsor)に審査を受ける前に自分自身のメールアドレスとGPG鍵を利用することはできる？
はい。良い質問です。debian/changelog他にはあなた自身の名前を使うことが奨励されています。それらは、あなたのhttp://launchpad.net/~<LaunchpadID>/+packages ページに表示されるでしょう。このページはMOTUになったときに重要になります。リリースサイクルに渡ってあなたがやったことが表示されるからです。引受人がするのは、差分ファイルを読み、それがOKかどうかを確認し、彼らの鍵で署名し、それをアップロードするだけです。
<mzungu>の発言：すでに.debとしてパッケージ化されているけれども、Ubuntuのuniverseなどには含まれていないデスクトップツールがある。これをUbuntuに含めるためにはどうすればいい？
その手順はとても簡単で、http://wiki.ubuntu.com/UbuntuDevelopment#NewPackages で説明されています。.debファイルではなく、.orig.tar.gzや.diff.gz、.dscを含むソースパッケージをアップロードする必要があるでしょう。審査をうけ、OKならばアップロードされます。
<hendrixski>の発言：パスワードで保護されたレポジトリをホスティングすることで、会社にプロプライエタリなサービスをホストすることは可能？ オープンソースでないソフトウェアのために、パスワードで隠すことは可能かな？
はい、できます。sftpを使えるでしょう。詳しいことはaptのmanページを確認すると良いでしょう。
<mbt>の発言：パッチをあてたりしたパッケージをテストしたいとき、(a)現在のパッケージよりも新しく、(b)次にリリースされるパッケージよりも「古い」テストパッケージを作りたいんだけども、バージョン番号はどうすればいいだろう？(例：LP 131526)
例えば、(0.5.4-3ubuntu1を修正した)0.5.4-3ubuntu2を用意するとします。このとき、0.5.6-3ubuntu2~testing1というバージョン番号が使えます。ここで、~は「それよりは小さい」ことを意味します。
<hendrixski>の発言：テスト目的などのために、メインブランチのナイトリービルドパッケージを作成するのは可能だろうか。すでにそれをしてくれるツールとかはある？それとも自分でスクリプトを自分で書く必要がある？
CVSチェックアウトか何かを考えていますか？ チェックアウトごとに'dch'を用いて新しいチェンジログエントリを自動生成するスクリプトを書けばいいでしょう。シェルかpythonを使えば数行で書けると思います。
<mbt>の発言：このビルドプロセスはSMPなシステムに調整されている？ 例えば、'make'時に並行処理を望む数Xを用いて-jXオプションをつけるとか。
それは自動的にやってくれるはずです。
<mbt>の発言：実際にこのパッケージ(訳註：brasero-0.5.90)をビルドし(そして失敗し)たけれども、CPUの一つしか使ってないみたいだから、質問してみたんだよ。
自分の場合は、両方のコアを使っていますね。これについては#ubuntu-develで尋ねると良いでしょう。
<amarillion>の発言：debuildは新しいファイルを作成するが、"clean"ターゲットはそれを削除しない。これは問題じゃないかな？ これらはdiffに追加されるだろうか？
一般的にはcleanターゲットが壊れているしるしですね。自動生成されたファイルはcleanターゲットの中で確実に削除されるようにするのが最良です。Debianでは私の知る限り、これはRCバグですね。
<FayZee>の発言：RCって何？
RCはrelease-critical(リリースクリティカル)のことです。
<mbt>の発言：もし上流のパッケージは利用できなくて、パッチを当てれば解決できるとすると、*.orig.tar.gzを修正する？それとも望んだ結果を得るために何かをする？
いくつかの特殊なケースを除いて、.orig.tar.gzに修正を加えてはいけません。dpatchやcdbsなどのようなパッチシステムを使うと良いでしょう。これらについてはhttp://wiki.ubuntu.com/PackagingGuide で説明されています。パッチはdebian/patchesに保存され、ビルド時に適用されます。パッチを追跡するのは良い方法です。新しい上流リリースにアップデートするとき、いくつかのパッチファイルは上流のSVNに適用済みなので、それらは削除されることになるでしょうから。
<DaveMorris>の発言：hardyはターゲットとしていつ公開されるの？
すでに公開されているはずです。
<bahadunn>の発言：build-depsその他で散らかさないために、pbuilderを利用したほうがいいんじゃない？
良い質問です。このチュートリアルでは、(接続が遅いために)pbuilderの設定まで含めると長すぎると考えました。pbuilderは(ビルドデーモンのように)最小の環境を作ってくれます。そしてchrootを用いて必要なbuild-dependsをそこにインストールすることになります。そうすることで「メインのシステム」にそれらをインストールする必要がなくなるのです。詳しいことについてはhttp://wiki.ubuntu.com/PbuilderHowto を参照してください。
<mbt>の発言：ある人がそれなりの数のパッケージを管理していたとして、自分で設置したビルドサーバに送るのはどうだろう？PPAは良いものだけれども、たくさんのパッケージを扱うには容量が幾分小さい。
pbuilderを利用した小さなスクリプトを書くのが良いと思います。'dak'を設定するのは、より面倒だと聞いています。
<bahadunn>の発言：今後、pbuilderのための独立したセッションを設ける予定は？
wikiのPbuilderHowtoだけで充分だと考えています。
<mbt>の発言：debdiffはアーキテクチャを越えて動作するの？
はい。私の場合はamd64で動かしています。:)
セッション4
(訳註：基本的な流れはセッション1,2と同じなので、質疑応答部分だけを抜き出して翻訳しています)
<harrisony>の発言：今起きたところで、このセッションを見逃してしまったんだけど、あとでログを見ることはできる？
はい。誰かがあとでリンクを提示してくれるでしょう。私には今すぐ見つけられないので。:)
<amarillion>の発言：不具合を修正するためには、不具合の報告にdebdiffファイルを添付すれば良いと思うんだけど、debdiffの出力はファイルのリストでしかなくて、修正したファイルそのものではないのはどうなんだろう。
素晴らしい質問です。出力結果は、debdiffを二つの.debファイルに対して実行したか、二つの.dscファイルに対して実行したかによって、変わってきます。もし上流の新しいバージョンをアップロードしたいと思うなら、ソースに対する差分を添付するのではなく、どこかにアップロードしたソースパッケージのリンクを提示すべきでしょう。そのために、PPA(http://help.launchpad.net/PPAQuickStart )やREVU(http://wiki.ubuntu.com/REVU )を使い、.dscファイルへのリンクを提示すれば良いでしょう(それを見た人々はdget -x <dsc file>を実行するだけでソースパッケージを入手し、審査することができますから)。
<desertc>の発言：x86とx86-64パッケージの違いについて教えてもらえるかな。すべてのパッケージは両方で利用可能なの？ これら二つのアーキテクチャに対するUbuntuのポリシーはどのようなものなの？
debian/controlの中でArchitecture: anyとなっていて、私たちが利用するすべてのアーキテクチャ上のすべてのbuilddsでソースパッケージがビルドされているなら利用可能です。これは、アーキテクチャに依存したコードを含んでいるパッケージの場合は必要になります。(pythonのような)スクリプトやアートワークのみを含むパッケージの場合は、その必要はありませんので、Architecture: allとすることができます。
<effie_jayx>の発言：最初のセッションではカットされなかった話ってなんだろう。そのとき使われたものよりもbraseroのバージョンが新しくなっているように思うんだけど……
0.5.90がビルドに失敗したという話です(seb128が指摘したように、GTKの上流ではGtkToolTipが廃止されているためです)。これは、0.6.1で修正されています。
<mbt>の発言：pbuilderを「使わずに」build-depsを掃除する簡単な方法はあるかな。我々が最初にインストールしたものとか。
deborphanのようなツールを使うことができます。
<mbt>の発言：あるdebdiffファイルを手元で適用したい場合どうすればいいかな。patch -p4 < file.debdiffみたいにできる？
可能です。多くの場合はp1になるでしょうが、patchコマンドを使うことができます。
<effie_jayx>の発言：パッチファイルは、古いパッケージと新しいパッケージの間のdebdiffの結果を使うのかな？
はい。.dscファイルに対してdebdiffを実行し、不具合報告に添付してください。
<amarillion>の発言：現在、70名ほどのMOTUがいるようだけどこれは少なくないかな。DebianだとDD(Debian開発者)は900名ぐらいいるみたいだけど……。
現在、積極的に勧誘中です。:-)
MOTUは上流やDebianのメンテナたちと共に素晴らしい仕事をしてくれていますし、皆さんもそれに参加することになるようん奨励しています。まさしく現在進行中の作業です。
<pwnguin>の発言：もしMOTUに提供したdebdiffが却下された場合、どこに上訴すればいい？
パッケージの変更や問題については、いつでも[[email protected]] で議論することができます。引受人チーム(sponsoring team)には素晴らしい能力を持った人がたくさんいますし、あなたが提出してくれたdebdiffをたった一人だけで審査するということはありません。
<sistpoty>の発言：個々のメンバーと問題が生じた場合は、motu-council(もしくはjono)に連絡を取ってください。
技術的な質問である場合はubuntu-motu@ もしくは ubuntu-devel@ の方が良いでしょう。しかし、メンテナ同士の人間関係の問題なら、お気軽に私かmotu-councilに相談してください。
<pwnguin>の発言：自分の場合は、他の人とうまくいっているよ。ただ、他の多くの人がそのパッチを受け入れているのに、ある一人の人によってそのパッチが拒絶されるという状況を想定したんだ。
たしかに、起こり得るでしょう。幾人かの引受人は、そのパッチによって引き起こされる小さな不具合を修正するようあなたに依頼するでしょうし、別の引受人は依頼しないかもしれません。これらの問題についてはもっともな話ですし、彼らと話をすれば良いでしょう。
<amarillion>の発言：Debianにはあるけれど、Ubuntuにはないパッケージを見たことがある。これらは1:1の対応をしていないということ？ このようにUbuntuにパッケージがない理由はなんだろう？
その理由の多くは、Debianソースパッケージに対するオートインポートがオフになっているからでしょう。私たちはリリースサイクルの最初の段階でDebianからのソースの変更点をインポートします(この時点で上書きされるようなUbuntuの変更点がない場合)。インポートされないパッケージについては、準手動でマージを行う必要があります。Hardyでの計画については、http://wiki.ubuntu.com/HardyReleaseSchedule (のdebian import freeze)を確認してください。
<amarillion>の発言：そのパッケージはbatikなんだ。一度、#ubuntu-motuでbatikライブラリのパッケージ化を要求して、誰かが古いバージョンがすでにDebianにあるよって言っていたんだ。
[email protected] で頼んでいないのなら、hardyで実行されるでしょう。
<eolo999>の発言：パッケージ化に関する文書を、より多くの実行例を含めて書き直すことはしないの？
私は現在http://wiki.ubuntu.com/PackagingGuide でそれを書いています。また、より実践的な例については、http://wiki.ubuntu.com/MOTU/Recipes に書かれているでしょう。
<mbt>の発言：-docや-dev、-dbgなどのようにパッケージを分離することに関するビルドシステムを用いた詳細な情報はどこにあるのかな？
その情報はhttp://wiki.ubuntu.com/PackagingGuide に載っています。/BasicのReerence Pacagesセクションにも載せる予定です。
<willwill>の発言：Wikipediaで、Ubuntuの不安定版であるGrumpy Groundhogなるものを読んだんだけど、Grumpyではパッケージはどれくらい新鮮なの？
Grumpyは現在のところコンセプトであり、まだ実装されていません。計画では、上流からSVNスナップショットを取得しパッケージ化することになっています。その頻度については私はわかりません。
<Riddell>の発言：debianディレクトリを持ったパッケージを、bzrの中でビルドする最良の方法は何？
素晴らしい質問です。いくつかのチームはメインのソースレポジトリとしてアーカイブを使うだけでなく、バージョン管理システムも使っています。そのシステムにアップロードできない場合は、bzr-builddebが役に立つでしょう。上流のtarballをビルドするために、--orig-dir=..と渡すだけです。
<amarillion>の発言：dh_makeを実行したときに自動で生成されるファイルの一つにwatch.exがある。おそらく新しいリリースを自動で追いかけるためにあるんだろうけど、これについて説明してもらえるかな。実際のところこれは動作しているの？
しっかりと動作しています。その例についてはhttp://wiki.ubuntu.com/MOTU/Recipes を参照してください。
<mbt>の発言：mainへのパッケージを提出は、universe/multiverseと同様にすればいいの？ 例えばGNU coreutilsはとても古くて再パッケージ化が必要なんだけれども、それがなされていないのは何か理由があるのかな？
coreutilsのようなツールをアップデートする場合は、[email protected] の人々と調整するべきでしょう。それらの変更点の影響はあまり大きくないように見える場合もありますが、「ちゃんと動く」ようにするにはプロジェクトが大きすぎるのです。しかしながら、一般的にはmainへのアップデートも同じ方法で行えます。あなたの望むように作業も行えますし、提案することもできます。
<pwnguin>の発言：Ubuntuユーザの利便性のために不具合を修正することと、上流と協力すること、MOTUにとってどちらが大事だろう。例えば、gksudoはちょっとした不具合があり、上流のpam moduleはたった3行のパッチをそれがハック的であることを理由に拒絶した。
gksuはデスクトップチームの管理ですので、その不具合をパッチと共に登録し、そのパッチが適用されるように依頼すべきでしょう。もちろん、MOTUにとっては両方大事です。
<pwnguin>の発言：いやいや。そのパッチはpam moduleに対するものでgksudoに対するものじゃない。gksudoに対するパッチは大きくなりすぎるだろうし、デスクトップチームやgksudoの上流はわかっているけれども、不具合を修正できるわけじゃない。
あぁ。ある時は、パッチと共に不具合を報告し、引受人チームに登録し、上流の議論にもリンクを張るのがいいでしょう。場合によっては、上流メンテナの考えを覆す決定を下すこともあります。私たちの利用者の利便性に合わせる場合は特にそうです。そのような決定は、いくつかの場合において不可避なものです。
<aos101>の発言：パッケージ化をするために特定のプログラミング言語を覚える必要はあるかな？ C++その他のことを知らなくてもできる？
重要なことはプログラミング言語の知識よりも、それを学ぼうとする気持ちと、やる気と、あとあなたが加える変更点は数百万の利用者に影響を与えるということに対する意識です。パッケージ化の途中で、シェルスクリプトやMakefileについて、もしかするとPythonも少しだけ、学ぶことになるでしょう。CやC++のソースにパッチを当てる場合は、それらについても学ぶかもしれません。これらは徐々に学んでいけばいいので、最初からC++やその他についてちゃんと知っておく必要はありません。
<mbt>の発言：次リリースまでの開発サイクルにおいて、どれくらいから関わることができるの？(例えば、Hardyは今のところ使えない、パッケージ化ができるのはいつ頃になる？)
リリースサイクルの初期段階で、私たちはDebianとUbuntuのパッケージをマージします。http://merges.ubuntu.com/universe.html では、マージが必要なパッケージが載っています。これに参加するのも素晴らしいことでしょう。なぜなら、UbuntuとDebianの違いを積極的に減らし、Debianにそれらの変更点をフィードバックすることができるからです。また、リリースサイクルの最初の段階で、UbuntuにもDebianにもない「新しい」パッケージについて調べます。Feature Freezeのあとは、安定化と不具合の修正、インストール可能なパッケージの作成などに終始します。
<effie_jayx>の発言：マージ関係で聞いた記憶があるんだけれども、MOMって何？ あと同じような言葉をもう一つ聞いたんだけど思い出せない。あなたはどっちを使っているの？
MOMはhttp://merges.ubuntu.com のことです。DebianとUbuntuのパッケージを比較し、大抵の場合はすぐに適用可能なパッチを作成してくれます。DaDはコミュニティによるサービスです。MOMと同様のことができますが、こちらはコメントを残すこともできます。私は大抵の場合、MoMを使うか、手動でマージしています(デスクトップパッケージの場合は、私たちは大抵の場合、マージと新しい上流バージョンへのアップデートを同時に行っています)。
<mbt>の発言：新しいソフトウェアを書いていて、それを次のリリース前にはUbuntuのuniverseに持ち込みたいと考えているんだけど可能だろうか。それとも新しいソフトウェアを持ち込むためには何か理由や正当性が必要になるんだろうか？
もしそれが再配布可能(な良いライセンス)で、既存の同じような機能のソフトウェアの10000回目のコピーでなければ、ぜひ持ち込んでください！
<willwill>の発言：checkinstallの利点と欠点は？
checkinstallは利用者が自分自身のために、面倒なことを考えることなくパッケージ化を行うためのツールです。開発者は使うべきではありません。それは過去に多くの問題を引き起こしたためですが、現在それが修正されているかどうかはわかりません。
<mbt>の発言：debパッケージ化について網羅された本はあるかな。
DebianポリシーとDebianメンテナガイドが良いでしょう。次のページからもリンクされています：http://wiki.ubuntu.com/MOTU/Documentation
Ubuntuのパッケージ化に関する全ての情報は、http://wiki.ubuntu.com/PackagingGuide に載っていますし、私はそこで精力的に活動を行っています。
<amarillion>の発言：debhelperとcdbsのどちらを使うべきとか言う公式の取り決めはあるの？
いいえ、ありません。私は簡単に思えたのでCDBSをよく使っています。CDBSは文書があまりないために、避けている人たちもいるようですが、私にとってはとても便利でした。
<sistpoty>の発言：Ubuntuに参加することの素晴らしさを教えて。
人々から学ぶことができます。毎日何かを知ることができます。不具合を修正することで利用者を幸せにすることができます。多くの人々と楽しい時間を共有することができます。:-)
<savvas>の発言：不具合を報告したとき、誰もその報告を見ることさえしていないんじゃないかと不満を言う利用者が数多くいる。これについて何か言うことはある？ 「スタッフの誰それが確認しました」みたいなことを伝えるべきじゃないかな。今のところ多くの不具合とまでは言わないが、いくつかの不具合は放置されたままであるように思う。
現在それについて作業中です。今週の後半には、不具合のチームと、不具合の扱い方についてのセッションを行います。すべての不具合を修正することは難しいですが、少しずつ良くなっています。
<mbt>の発言：コアの開発者になる方法は、MOTUになるのと同じ？
はい。より多くの経験値が必要になります。詳しい手順はhttp://wiki.ubuntu.com/UbuntuDevelopers にも載っています。
<Muzik-qa>の発言：ここで説明された内容をもとに、http://merges.ubuntu.com/universe.html から例として"Celestia"をやろうと思う。「base version」って何？ またここにいるみんながcelestiaについて作業することを(余分な努力が生じないように)防ぐにはどうすればいい？
DaDのコメント機能を利用して尋ねてみてください。
<LjL>の発言：willwillの発言に関して、可能な限り標準に準拠したパッケージを作成する、checkinstallのようなエンドユーザ向けのツールはどうかな。そのようなツールの存在は(より多くの人々が簡単にパッケージを作成できるために)より高品質のパッケージが増える思う？それとも(同じ理由で)より低品質のパッケージが増えると思う？
それがうまくいくとは思いません。パッケージの作成に際しては、考慮しなければいけないことがたくさんあります。ある場合はとても簡単にできるでしょうが、他のパッケージの機能に依存するようなパッケージを作るとなるとすぐにトラブルに遭遇するでしょう。私はパッケージ化の手順をすべて簡単に行えていますが、いまだ「すべてやってくれる」ツールはありません。