ククログククログFedoraプロジェクトで新規パッケージをリリースする方法はじめに今回は、Fedoraプロジェクトで新規パッケージをリリースする方法を、Cutterをリリースしたときの経験をもとに紹介します。Cutterプロジェクトでは、従来はFedora向けに独自にリポジトリを用意してRPMを提供していました。この方法では、ユーザーがCutterをインストールするときにリポジトリを追加登録する手間がかかり、不便でした。そこで、FedoraでCutterを利用したいユーザーがもっと簡単に導入できるように、FedoraプロジェクトからRPMを提供するようにしました*1。maintainersに詳細がまとめられています。このドキュメントは日本語訳もあります。ところどころ内容が最新版に追従していませんが、参考としては十分です。上記ドキュメントを読まれることをお勧めしますが、簡単に紹介すると以下のようになります。System(FAS)のアカウントの取得メーリングリストへの参加レビューリクエストの準備レビューリクエストの投稿レビューリクエストの承認SCMリクエストパッケージのインポートパッケージのコミットパッケージのビルドパッケージのアップデートパッケージのテストパッケージのリリースそれでは、順を追って説明していきます。Bugzillaのアカウントを取得します。Accountのリンクから作成します。このアカウントは後述するレビューリクエストを行うときに必要になります。System(FAS)のアカウントの取得Fedoraプロジェクトでパッケージをメンテナンスするためには、FASアカウントと呼ばれるメンテナンスのためのアカウントが必要です。Accountのリンクから作成します。このアカウントはレビューリクエストを行う際や、レビューリクエストが承認されたあとのパッケージのインポートやコミット等のリポジトリ関連の作業に使います。Agreement(貢献者ライセンス同意書、以下CLA)に同意する必要があります。リンクをたどり、ライセンスを読んだうえで、同意します。署名するを参照してください。CLAに同意すると、図の状態になります。Account"メニューよりSSHの公開鍵を登録します。ここで登録した鍵を用いて後述するfedorapeople.orgやリポジトリへとアクセスします。~/.ssh/id_rsa.fedora.pkeyの設定は個々の環境で読み替えてください)。~/.ssh/id_rsa.fedora.pkeyメーリングリストへの参加これは必須ではありませんが、他のパッケージのレビューを見ることで、パッケージング作業についてより深く学べます。package-review他にもいくつか参考になるメーリングリストが存在します。必要に応じて参加すると良いでしょう。アナウンス向けのメーリングリスト。19のAlphaフリーズのアナウンスが流れた。開発者向けのメーリングリスト。パッケージのリリースアナウンス向けのメーリングリスト。パッケージがstable入りしたのを知るために登録する。新規パッケージを登録するためには、レビューというプロセスを経る必要があります。レビューをしてもらうには以下の情報が必要です。specファイルのURLSRPMファイルのURLFASアカウント名specファイルやSRPMファイルの場所は一般にアクセス可能な場所であれば、どこでも構いません。Cutterの場合はSourceforge.netを利用していたので、一時ディレクトリを用意して、そこにファイルをアップロードしていました。レビューリクエストを行うまえに、あらかじめパッケージに問題がないか確認する方法をいくつか紹介します。rpmlintによるチェックKojiによるビルドチェックmockによるビルドチェックfedora-reviewによるチェックrpmlintによるチェックパッケージに問題がないか確認する最もシンプルな方法です。*.rpmパッケージのレビューに関してはReviewGuidelinesというドキュメントがあります。このドキュメントには、レビュワーがしなければいけないことの1つとして「rpmlintの実行」が記載されています。rpmlintで報告されている警告やエラーを潰しておくと、レビューしてもらうときの余計なやりとりを減らすことができます*2。KojiによるビルドチェックFedoraプロジェクト向けにRPMパッケージをビルドするシステムとしてKojiがあります。Kojiを使うと複数のリリースもしくは複数のアーキテクチャ向けにRPMパッケージのビルドがうまくいくか確認することができます*3。Kojiを使うにはいくつかセットアップが必要です。systemを参照してください。fedora-packagerをインストールします。fedora-packager次にfedora-packager-setupを実行します。このとき、FASアカウントの入力が必要です。ブラウザ向けのクライアント証明書のパスワードの入力も必要です。~/.fedora-upload-ca.certパスワードを入力し終わると処理が進みます。fedora-packager-setupコマンドは以下の4つのファイルをホームディレクトリへと保存します*4。.fedora-server-ca.cert.fedora-upload-ca.cert(.fedora-server-ca.certへのシンボリックリンク).fedora.certfedora-browser-cert.p12この手順は通常一度だけ必要です*5。これで、Kojiを使う準備が整いました。Kojiを使ってビルドを試すには、以下の様に--scratchオプションを与えてkojiコマンドを実行します。cutter-1.2.2-4.fc18.src.rpmKojiでのビルドはすべてFedoraプロジェクトのビルドサーバーで行うので、他のビルドとの兼ね合いからビルドが完了するまでそれなりに時間がかかります。Mockによるビルドチェック依存関係などが適切に処理されているかについてはMockによるビルドを行うことで確認できます。KojiもMockを使って実現しています。Mockではローカルにchroot環境を構築してRPMをビルドするようになっています。常用しているFedoraの環境とは異なりクリーンな環境でビルドを行うため、依存関係の抜け等をチェックすることができます*6。Mockを使うにはいくつかセットアップが必要です。mockグループに作業ユーザ(任意)を追加します。この作業は初回のみ必要です。(作業ユーザーアカウント)次にmock環境を初期化します。この作業はビルドを試したい環境ごとに行う必要があります。--init最後にmockの特定環境でビルドするには以下のコマンドを実行します。cutter-1.2.2-4.fc18.src.rpmmockコマンドはビルド結果のログを以下に生成します。ビルドしたRPMも同じ階層に保存します。buildsを参照してください。fedora-reviewによるチェックfedora-reviewという専用のツールを使って確認することもできます。以下のようにしてインストールします。fedora-reviewfedora-reviewはレビュワー向けのツールなので、パッケージに関するより細かいレポート結果を得ることができます。ローカル環境で実行するには以下のようにSRPMを指定します。cutter-1.2.2-4.fc18.src.rpm実行が終了すると、fedora-reviewコマンドは(パッケージ名)/review.txtを生成します。review.txtの内容は以下のように、チェックする項目とその結果を含んでいます。Packageというセクションで、specやSRPMのアップロード先としてfedorapeople.orgを紹介しています。最初のレビューリクエストを投稿する時点では、fedorapeople.orgへファイルをアップロードする権限がありません。fedorapeople.orgへのアクセスするには、自分のFASアカウントを後述するpackagerグループに追加してもらう必要がありますが、これはパッケージのレビューが承認された後になるからです。そのため、この時点ではどこか他の場所にspecやSPRMをアップロードして、レビューしてもらえる状態にする必要があります。レビューリクエストの投稿specファイルとSRPMファイルが用意できたら、Bugzillaへレビューリクエストを投稿します。レビューを投稿するときの雛形は、専用の入力フォームとしてfedora-reviewがあります。Username:Cutterの場合は以下のようなレビューリクエストを投稿しました。SPECファイルのURLを記述します。SRPMファイルのURLを記述します。パッケージの説明を記述します。ここにあらかじめ取得したFASアカウント名を記述します。レビューリクエストの注意事項レビューリクエストを行う際には、以下の点に注意する必要があります。新規パッケージを投稿するときには、FE-NEEDSPONSORフラグを設定しなければなりません。これはパッケージのメンテナンスの権限を有するpackagerグループのうち、より高度な権限を持つsponsorという権限を持っている人にレビューをしてもらう必要があることを示します。FE-NEEDSPONSORフラグは、レビューリクエストの左側にあるBlocks:という項目を編集します。fedora-reviewフラグを設定するには、レビューリクエストのFlags:という項目を編集します。Flags:は登録したレビューリクエスト画面の右側に項目があります。Flags:の隣りの(edit)をクリックするといくつかプルダウンが表示されます。このうち、fedora-reviewという項目があるので、プルダウンから?を選択して更新します。fedora-reviewに設定できる値とその意味は以下の通りです。レビューが却下されたFE-NEEDSPONSORが設定されているレビューリクエストのみを一覧で参照することもできます。レビューリクエストの承認レビューリクエストを投げたものの、それがそのまますんなり通るとは限りません。Cutterの場合もレビューリクエストを最初に投げてから何度かspec記述上の問題点をレビュワーに指摘され、修正するというサイクルを繰り返しました。レビュワーは、指摘事項の根拠となるドキュメントを示しながら、問題点をどう修正すべきかをコメントしてくれます。Cutterの場合だと、指摘された問題点の一つにBuildRoot:タグを指定していたというものがありました。too.すべての指摘事項を修正し、レビューを通ると以下の状態になります。レビュワーがレビューリクエストにAPPROVEDというレビューコメントをつける(レビュワーによって表現は多少異なる場合があります)。レビュワーがレビューリクエストのfedora-reviewフラグを+に変更する。レビュワーがレビューリクエストした人をpackagerグループに追加する。packagerグループに入るとFedoraのサーバーへアクセスできるようになります*7。fedora-reviewフラグが+になったら、次のステップ「SCMリクエスト」に進みます。SCMリクエストについてパッケージのレビューが通ったら次にやることは、新規パッケージのためにリポジトリを用意することです。リポジトリについては、レビューリクエストのバグのコメントにSCMリクエストと呼ばれる作業依頼のコメントを投稿します。Cutterの場合は以下のようなSCMリクエストを行いました。パッケージ名を記述します。パッケージの説明を記述します。specのSummary:を書くなどすると良いでしょう。自身のFASアカウントを記述します。リポジトリに追加するブランチを記述します。Cutterは当時のリリースであるFedora18(f18)ブランチのみ指定しました。他にもメンテナとして追加したい人のFASアカウントを記述します。SCMリクエストを行ったあとは、しばらく待つ必要があります。Cutterの場合は一日程度でした。リポジトリを作成する権限のある人が、定期的にSCMリクエストをチェックし、順次対応してくれているようです。SCMリクエストが処理され、リポジトリの準備が完了すると、レビューリクエストに以下のようなコメントが書き込まれます。granted:という件名で、通知メールがあらかじめ登録しておいたアカウントに届きます。これで、specとSRPMをコミットするためのリポジトリが準備できました。次のステップ「パッケージのインポート」へと進みます。これ以降の作業(「パッケージのインポート」から「パッケージのアップデート」まで)は、master(rawhide)*8とSCMリクエストで指定したブランチごとにくりかえす必要があります。作業しているブランチによって一部手順が異なりますが、詳細については「ブランチごとの作業まとめ」として後述します。パッケージのインポートパッケージのインポートでは以下の作業が必要です。SSHアクセスの確認fedpkgのインストールリポジトリのcloneSRPMのインポート以下、順に説明していきます。SSHアクセスの確認レビューが通った後、レビュワーによりpackagerグループに追加してもらえます。packagerグループに所属しているとFedoraのサーバーへとアクセスすることができます。Group"でわかります。ここのStatus欄が"Approved"になっていると、packagerグループに所属していることになります。以降の作業ではサーバーへのアクセスをともなうので、FASアカウントを作成したときに用意した秘密鍵を用いて、SSHでログインできるか確認します。fedorapeople.orgSSHアクセスに成功したら、実際にパッケージのインポートを順に行っていきます。fedpkgのインストールFedoraプロジェクトではパッケージのビルドやアップロードなどのメンテナンス作業にfedpkgというコマンドを使います。fedpkgコマンドを使うには、あらかじめfedpkgパッケージをインストールする必要があります。前述のKojiによるビルド確認を試している場合は、fedora-packagerのインストール時に、既に(パッケージの依存関係により)fedpkgをインストールしているはずです。ない場合には以下の手順でインストールします。fedpkgfedpkgのインストールが完了したら、次のステップ「リポジトリのclone」に進みます。リポジトリのcloneまずは作業用のリポジトリをcloneします。作業用のディレクトリを用意して、そこにcloneするのが良いでしょう。(パッケージ名)上記コマンドを実行することでリポジトリをcloneすることができます。Cutterの場合は以下のように作業ディレクトリを用意してcloneしました。cutterSRPMのインポートリポジトリのcloneができたら、SRPMを以下のコマンドにてインポートします。importコマンドは、SRPMからspecファイルやパッチ、ソースアーカイブを抽出し、作業ディレクトリへと展開します。.gitignoreやハッシュ値を書きこんだsourcesファイルも生成します。Cutterの場合は以下のようになりました。-1cutter-1.2.2.tar.gzcutter-configure-gtk-debug-detection.diffcutter-test-use-upper-case-gdk-literal.diffcutter.specsourcesここまでで、パッケージのインポートが完了しました。次のステップ「パッケージのコミット」へと進みます。パッケージのコミットパッケージのインポートが完了したら、差分(新規追加)を確認した上でコミットします。pushしてローカルのコミット内容をアップストリームへと反映します。pushpushが完了したら、次のステップ「パッケージのビルド」へと進みます。buildを実行します。18ブランチ向けにビルドしたときは、以下のようになりました*9。successfullyビルドが成功したので、次のステップ「パッケージのアップデート」へと進みます。パッケージのアップデートFedoraプロジェクトではパッケージの追加/更新/削除やパッケージの公開・管理を行うためのシステムとしてBohdiを使っています。ユーザーが参照するyumリポジトリへと反映します。Bohdiへビルドしたパッケージを反映させるには、パッケージのアップデートを行います。パッケージのアップデートをするには以下のコマンドを実行します。updateを実行するとエディタが起動するので、アップデートに関する項目を編集します。何のパッケージの、どんな更新なのかといったメタ情報を記述します。必須なのはtypeで、新規パッケージの場合にはnewpackageを指定します。Cutterの場合は以下のようにしました。updateコマンドがその内容をBohdiへと送ります。https://admin.fedoraproject.org/updates/cutter-1.2.2-4.fc18ブランチごとの作業まとめ「パッケージのインポート」から「パッケージのアップデート」までは作業しているブランチごとに繰り返す必要があります。作業ブランチによっては、やるべきこと、やらなくていいことがあります。そこで、ここまでの作業手順を一旦まとめます。18ブランチについて作業しました。SRPMのインポートは不要。代わりにmasterブランチからマージする。必要まず、masterブランチ向けに「パッケージのインポート」から「パッケージビルド」まで行いました。18のブランチに切り替え、masterブランチからマージした後、パッケージのリリースまで行いました。上記を具体的な実行コマンド列で比較すると以下のようになります。18ブランチの手順では以下のことを行っています。updateでf18向けにビルドしたパッケージをBohdiへと反映するここまでの作業がブランチごとに完了したら、次のステップ「パッケージのテスト」へと進みます。updateでBohdiへとパッケージを更新するようにしむけても、それで終わりではありません。投稿したRPMパッケージが一般ユーザーが利用しているyumリポジトリへと反映されるまでには、いくつかの段階があります。一般ユーザーが利用するyumリポジトリへ反映されているRPMパッケージは一旦キューに入れられるのでpending状態になり、その後testingリポジトリ*10へと反映されます。testingリポジトリで一定評価を得たパッケージがstable*11に入る仕組みになっています。その際の評価はKarmaと呼ばれる仕組みによって行います。Bohdiにアカウントを有しているユーザーは、Webインターフェースからパッケージに対するコメントをすることができます。コメントするときには、あわせてパッケージを評価することができます。この評価欄の集計がKarmaです。work」にチェックを入れると-1の評価となります。デフォルトのKarmaは0からスタートします。BohdiはKarmaが+3になったパッケージをstableリポジトリへと反映し、逆に-3に達したパッケージをtestingリポジトリから削除します。update実行時にその都度メタ情報として設定できます*12。Testingを参照してください。パッケージのリリース一定評価(stable_karma)を得られたパッケージは、Bohdiが自動的に一般ユーザーが利用するyumリポジトリ(stableリポジトリ)へと反映します。一定評価を得られていないパッケージであっても、一定期間(2週間程度)経過すると、手動操作でyumリポジトリへと反映することができます。その場合は、パッケージをアップロードした人がBohdiのインターフェースから作業します。stable」をクリックするとyumリポジトリへ反映することができます。まとめ新規パッケージをリリースするまでに必要な情報については、すでにFedoraプロジェクトによって文書化されています。一部には日本語訳も用意されています。実際にやってみないことにはわからないこともあります。そこで今回は具体例をもとに実際にパッケージをリリースするところまでの流れを紹介しました。フリーソフトウェアの開発元がかならずしも使っているディストリビューション向けにRPMパッケージを提供してくれるとは限りません。ソースアーカイブからRPMを作成してくれるcheckinstallなどもあるので、手元の環境ではRPM化して管理しているという人もいるかも知れません。自作RPMパッケージを手元でだけ管理している状態では、他の人もRPM化して管理したい場合には、また同様の手順を踏むことになります。自分は問題を解決したけど、また再度同じ問題にぶつかる人がいるという状況に変化はありません。成果物については手元の環境だけで眠らせておかずにディストリビューションへと還元するのをおすすめします。今回は、新規にパッケージを登録するところまでを書きました。パッケージは登録して終わりではありません。継続してメンテナンスしていくことも重要です。既存パッケージを更新する方法については、またの機会に記事にしたいと思います。1.2.2をリリースして以降。rpmlintによりスペルミスとして警告されていても、固有名詞のため問題ない場合もあります。rpmlintはそれぞれのRPM単位でのチェックのため、メインパッケージに含まれていれば良いライセンス類がサブパッケージに含まれていないと警告として扱われたりします。19などでもビルド確認が行えます。fedora-browser-cert.p12についてはブラウザ経由でKojiへアクセスするときに必要です。セットアップ手順は上記のメッセージの通り証明書のインポートを行います。証明書の有効期限が切れたら更新する必要はあります。BuildRequires:の指定が抜けているなど。fedorapeople.orgに割り当てられたディスク領域を使うことができます。次回以降のレビューリクエストを行うときはこちらにspecファイルとSRPMを置くと良いでしょう。RawhideはFedoraの開発版を意味し、masterブランチのことです。18向けにビルドしたときのログです。testingリポジトリは、テスター向けのリポジトリです。標準では有効になっていないので、testingリポジトリのパッケージを実際にインストールするには別途有効にする必要があります。stableリポジトリへ反映される基準値はstable_karmaで、削除される基準値はunstable_karmaで設定できます。それぞれデフォルト値は3と-3です。4.0とGFDLのデュアルライセンスで自由に利用できます。クリアコードはプログラミングが楽しいソフトウェア開発者を1名募集しています。クリアコードは「クリアコードをいい感じにする人」を1名募集しています。クリアコードはフリーソフトウェア開発で培った技術力を提供しています。Thunderbird)とRubyとGroonga(全文検索)に関連した開発を得意としています。