貢献という役割
本稿に記載されている内容は貢献という役割の単なる提案です。あなたのやる気次第で制限はありません。
Fedora パッケージコレクションメンテナへの参加方法
本当にあなたは Fedora プロジェクトのパッケージメンテナになることを決意しましたか？これはあなたが最初のパッケージを投稿するまでのガイドです。
Fedora パッケージコレクションメンテナになる
ガイドラインを読む
もしあなたが RPM パッケージの作成方法を知らないなら、簡易 RPM チュートリアルか、より高度で詳細な内容の RPM パッケージの作成方法を参照してください。
そしてパッケージングガイドライン と パッケージ名ガイドラインを読んでください。
あなたは RPM パッケージングに十分に精通する必要があります。RPM パッケージングの知識は全てのパッケージ投稿に影響を与えます。もし質問があれば、Fedora パッケージングメーリングリストで尋ねてください。
Bugzilla アカウントを作成する
Red Hat Bugzilla にアカウントを作成してください。
Bugzilla のアカウントで使用するメールアドレスは、Fedora パッケージングの全ての関連事項を扱うために Fedora アカウントシステムで使用するメールアドレスと同じメールアドレスを使用すべきです。
あなたがスポンサーになると、あなたの bugzilla 権限が取得できないので @fedoraproject.org のメールアドレスを Bugzilla で使用してはいけません。もし @fedoraproject.org のメールアドレスを使用したいなら、あなたの Fedora アカウントで接続する Bugzilla のメールアドレスを手動で上書きするように管理者へFedora インフラチケットシステムでリクエストした方が良いです。
Fedora アカウントを取得する
Fedora アカウントシステムでアカウントを作成してください(これは Bugzilla アカウントでは ありません )。
- https://admin.fedoraproject.org/accounts/ アカウントシステムのホームへ訪問する
- 'New account' を選択してブランク項目に記入してください。
- アカウントを作成した後で CLA に署名しているか(画面の "My Account" リンクをクリックすると CLA: CLA Done となっているか)確認してください。
注意: Red Hat 社員は CLA の代わりにcla_redhatを適用すべきです。アカウントシステム上で新たなグループを適用して、グループフィールドにcla_redhatを追加して適用してください。それから TomCallaway にあなたを承認するように依頼してください。 - さらに RSA の公開鍵をアップロードする必要があります。SSH 経由で Fedora マシンへアクセスする秘密鍵に対応する公開鍵を使用する必要があります。
重要なメーリングリストへ参加する
あなたは fedora devel-announce@lists.fedoraproject.org メーリングリストへ参加しなければなりません。それは流通量の少ないアナウンス用のメーリングリストで、重要な開発情報が投稿されます。
fedora devel@lists.fedoraproject.org メーリングリストに参加することもできます。そこでは開かれた Fedora 開発に関して議論されます。これは流通量の多いメーリングリストです。
さらに package-announce@lists.fedoraproject.org に参加することも考慮してください。Fedora リポジトリの全パッケージのコミット通知を取得するためのコミット情報のメーリングリストです。これはかなり流通量が多いメーリングリストです。Fedora パッケージデータベースは、あなたが(共同で)メンテナンスするパッケージのためにコミットメールを送信します。
参加した方が良いと見なされる(少なくともアーカイブを見れる方が良い)他のメーリングリストは packaging@lists.fedoraproject.org です。これは Fedora プロジェクトの公式パッケージングガイドラインを決定する Fedora パッケージング委員会のメーリングリストです。
パッケージが適切なものだと保証する
あなたが投稿するパッケージは既に Fedora でパッケージングされていない、フリーでオープンソースなプロジェクトになります。あなたのパッケージを作成する前に、そのソフトウェアが Fedora リポジトリに既に存在していないか、又はレビュー待ち状態でないかを確認してください。
- 既にリポジトリにパッケージが存在していないかを Fedora パッケージデータベースで検索してください。
- レビュー待ち状態でないかを レビュートラッカ で検索してください。
- さらに 関連パッケージリストを確認してください。
- 禁止されてるアイテムに注意してください。
あなたの義務を理解する
Fedoraに同梱されているソフトウエアコンポーネントは、積極的に保守管理される必要があります。バグ、特に、セキュリティに関する問題は、即座に修正される必要があります。これは、あなたが第一に認識するべきFedoraパッケージ保守管理者としての責任 です。私たちは、あなたに、パッケージの共同保守管理者となること、そして、あなたがヘルプが必要である場合はいつでも、開発者MLを通じて、Fedoraコミュニティに助けを求めることを、あなたに望みます。
他の提案を読む
パッケージングに関して学ぶために他の人のパッケージ投稿を読んで、そのプロセスや要求に精通してください。
そうするための1つの方法は package-review@lists.fedoraproject.org メーリングリストに参加することです。Fedora パッケージレビューの全てのコメントがこのメーリングリスト(あなたの視点からだと読み専用)に送られます。
あなたのGitを設定する
Fedoraパッケージ作成のための準備として、最初にやることは、Gitで使用するあなたの名前とメールアドレスを設定することです。Fedoraのパッケージに対するコミットごとに名前とメールアドレスがリンクされます。
git config --global user.name "John Doe" git config --global user.email johndoe@example.com
クライアントツールをインストールする
Fedora コレクション又は EPEL 向けにパッケージをビルドするために Koji を使用する必要があります。さらに Fedora アカウントシステムでクライアントサイド認証を生成して、fedpkg がデフォルトでその認証ファイルを見つけられるように ~/.fedora.cert というファイル名で保存する必要があります。
あなたの認証ファイルは6ヶ月後に有効期限が切れます。有効期限が切れたら、別の認証ファイルをリクエストする必要があります。新たな認証ファイルをリクエストすると、古い認証ファイルをそれ以上使用することはできません。
fedora-packager パッケージは fedora でパッケージング作業や環境構築を助けるツールを提供します。次のようにしてインストールすることができます。
yum install fedora-packager
インストール後に次のコマンドを実行してあなたのユーザアカウントに対して koji の設定を行ってください。
fedora-packager-setup
Fedora の認証ファイルを更新する毎に
fedora-packager-setup を再実行する必要があります。あなたが持っていないプラットホーム(例えば PPC)又は、ディストリビューション上で RPM パッケージのビルドを試すために "koji" を使用することができます。あなたのパッケージが承認されていなくて、スポンサーを取得していない状況であっても、ビルド("スクラッチ" ビルド)テストができることに注意してください。koji を使用してスクラッチビルドを行う最も簡単な方法はコマンドラインで次のように実行します。
koji build --arch-override=PLATFORM --scratch TARGET path_to_source_RPM
オプションやコマンドライン引数:
- TARGET は (Fedora 9 向けは)dist-f9 のようにディストリビューションのキーワードです。"koji list-targets" を実行すると全ての対応ディストリビューションを確認できます。次のリリース(rawhide)向けにビルドするためには "dist-rawhide" を 使用するのではなく 、"dist-fX" (X は最新の安定バージョンの番号よりも高い番号を指定する)を使用してください。
- PLATFORM は i386 (32-bit), x86_64, ppc 又は ppc64 のようなプラットホームのキーワードです。--arch-override=PLATFORM でそのプラットホームを除外することができます。koji は spec ファイルで設定された、そのパッケージがサポートする全てのアーキテクチャでビルドのテストを行います。
- URL ではなく 、ソース RPM (.src.rpm ファイル) への パス を与える必要があることに注意してください。(もし spec ファイルのみなら、新たなソース RPM を作成するために
rpmbuild --nodeps -bs SPECFILEを実行してください)
あなたの koji ビルドは実際に TARGET ディストリビューションのリポジトリにあるパッケージのみに依存します。あなたのパッケージがまだ Bodhi にリリースされていない新しいパッケージに依存している場合、リリースされているディストリビューションでしか koji を使用してビルドすることはできません。その新しいパッケージがこの後に説明されるように "rawhide" 向けにビルドされているなら、その新しいパッケージに依存していたとしても rawhide (次のリリースバージョン) 向けに koji を使用して ビルドすることができます 。安定版リポジトリへまだリリースされていないアップデートであるパッケージに対してビルドする必要があるなら、 https://fedorahosted.org/rel-eng/newticket で rel-eng を付けてチケットを登録して buildroot を上書きするようにリクエストすることができます。EPEL のパッケージでは、担当者がそのチケットを受け取れるようにコンポーネントに epel を使用する必要があります。
koji についてヘルプから学習することができます。
koji --help # 全般的なヘルプ koji --help-commands # koji コマンドを表示する koji COMMAND --help # COMMAND のヘルプを表示する
Koji の詳細については Using_the_Koji_build_system を参照してください。
パッケージを作る
- もし RPM パッケージを作成する方法を知らないなら RPM パッケージの作成方法を参照してください。
- あなたのパッケージが パッケージングガイドラインと パッケージング名ガイドラインに準拠しているかを確認してください。
- パッケージレビューガイドラインに注意してください(パッケージレビューに使用されます)。
- パッケージがビルドできることを確認してください。これは意外に重要です。なぜならば、注目されるほどの数の投稿がビルドしてないからです。
パッケージをアップロードする
SRPM と spec ファイルをインターネット上のどこかにアップロードしてください。それは URL でどこからでもアクセスできる場所になります。 あなたが既に Fedora アカウントを持っているなら、そのためのストレージとして http://fedorapeople.org を使用することができます。
レビューリクエストを作成する
https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=fedora-review のフォームに記入してください。
- あなたのリクエストを投稿する前に同じパッケージに対して直前のリクエストがないかを確認してください。
- そのパッケージが何なのかを説明する 短い要約 を添えて '
Review Summary' フィールドに パッケージ名 (バージョンとリリース番号を除く) があることを確認してください。
- spec ファイルと SRPM を公開されたウェブサイトへアップロードしてください。もしホスティングスペースが必要なら、チケット投稿の際にメモとして書いておくと誰かが面倒を見てくれるでしょう。あなたが既に Fedora パッケージメンテナなら http://fedorapeople.org を使用して作ることができます。
- あなたのパッケージの 説明 (通常は spec ファイルの %description に追加する内容と同じ説明)を '
Review Description' フィールドに追加してください。そして、あなたの SRPM や SPEC ファイルへの URLs を含めてください。さらにこれはあなたの最初のパッケージでスポンサーが必要であることも説明してください。
Review Description' で説明していることを確認してください。そして、スポンサーを探します。Fedora パッケージコレクションでは、全ての新たな貢献者はスポンサーを得なければなりません。潜在的なスポンサーはレビューするためのパッケージを見つけるために Bugzilla 上の FE-NEEDSPONSOR バグで探します。レビューリクエストバグを編集するために、あなたのパッケージをこのリストに追加することができます。そして 'Bug xyz blocks' フィールド(xyz はレビューリクエストのバグ番号になります)に FE-NEEDSPONSOR を追加してください。レビュープロセスの詳細は パッケージレビュープロセスページを参照してください。
アップストリームへ知らせる
プロジェクトとしての Fedora は アップストリームに近い状態を維持することを好みます。あなたがパッケージングしていることをそのソフトウェアの開発者へ知らせてください。自己紹介のメールを送ったり、レビューリクエストで指摘したりすることで自分がパッケージングを行っていると知らせることができます。これは今後の会話の場を提示します。彼らのソフトウェアが現在は Fedora の一部であるという事実を通常は公示するか、既存リリースの重要なバグ、今後のロードマップ等があればあなたに知らせたくなるかもしれません。
自己紹介する
新しいパッケージ保守管理者がFedoraプロジェクトに参加するときは、Fedora devel メーリングリストに自己紹介をお願いします。メーリングリストを購読するためには、devel メーリングリストの購読ページに訪れてください。自己紹介の主な目的は、Fedoraコミュニティメンバーがあなたをもう少し詳しく知ることによって、信頼を構築するプロセスを開始し、あなたのレビューリクエストがより早く進むチャンスを増やすことです。
私たちは、匿名性をなくし、プロジェクト内に、現実世界のコミュニティを作り出すことを願っています。あなたは、個人的な秘密を知らせる義務はありません。目的は、あなたとプロジェクトのほかのメンバーの間に一定の信頼を築くことです。しかし、あなたは私たちと意思疎通するときは、少なくとも自分の本当の名前を使う方が良いです。また、あなたが誰であるか、あなたの動機、そして、おそらくはあなたがレビューのために投稿したソフトウエアの説明をおすすめします。
件名: Self Introduction: <あなたの名前> 本文: あなたのフリー＆オープンソースプロジェクトの経験、 あなたが提出したレビューリクエストへのリンク、 あなた自身の簡単な説明含む、 あなたが妥当と考える情報を追加してください。 必要に応じてGPGキー情報を投稿することもできます。
フィードバックを監視する
あなたの最初のパッケージの Bugzilla レポートを監視してください。メールで変更通知を受け取るべきです。レビューアが blocker だと指摘したらとにかく修正してください。
スポンサーを得る
レビューアがパッケージを承認した場合、そのパッケージをチェックインしてビルドするために独立してスポンサーを得なければなりません。スポンサーは自動的に得られるのではなく、パッケージガイドラインの理解度を説明するために何らかの方法で参加するということを要求します。スポンサーを得る鍵は、あなたがプロジェクトのガイドラインとプロセスを理解して従っているということを既存のスポンサーレベルのメンバーへ説得することです。
スポンサーを得る方法の詳細は パッケージャグループでスポンサーを得る方法 を参照してください。
あなたのスポンサーはパッケージャグループにあなたを追加することができます。スポンサーに関する確認メールを受け取るべきです。
ソースコード管理(SCM)システムへパッケージを追加して所有者をセットする
先に進む前に、Fedora Account Systemのクレデンシャルを使って、 https://src.fedoraproject.org/ にログインし、 あなたのアカウントを同期してください。
もしあなたが、パッケージの共同保守管理者ではなくて、新しいパッケージの保守管理者になろうとしているなら、fedpkg をつかって、あなたのパッケージ用に、新しくgitレポジトリをリクエストしてください。サブコマンドは、 "fedpkg request-repo" です。これには、コマンドが必要とする、Pagure API token を準備するためのヘルプ文言を含んでいます。あなたは、レポジトリ名とレビューのバグ番号を指定しなければなりません。例えば、 "fedpkg request-repo python-prometheus_client 1590452" です。
gitレポジトリ作成のリクエストは、大抵24時間以内に管理者にレビューされて、処理されます。チケットが処理されると、パッケージをコミットしてビルドするためのアクセス権が与えられます。
モジュールをチェックアウトする
今すぐあなたのモジュールをチェックアウト することができます が、そうする前に "mkdir ~/fedora-scm ; cd ~/fedora-scm" を実行することを検討してください。そうすると、そのディレクトリ内に全てのファイルが展開されます。さらにキーフレーズを入力しなくて良いように ssh-add を実行して設定することも実行できます。
ssh-add を実行することは良い方法です。全ての操作に対してキーフレーズ入力の手間を削減します。セッションにつき1度だけ ssh-add を実行する必要があります。そして、それはログアウトか再起動するまで有効になります。もし "ssh-add" が "Could not open a connection to your authentication agent." と言ってきたら "exec ssh-agent bash" を実行して新たなシェル環境で試してみてください。SCM からあなたのモジュールをチェックアウトする準備が整いました。
fedpkg clone -B <packagename>
<packagename> はあなたのパッケージ名に置き換えてください。
あなたのパッケージ名を付けて作成したディレクトリ配下に各ブランチのディレクトリを作成してください。
.png){kind=small}
~/.ssh/id_rsa) のパーミッションが 400 でセットされているかを確認してください。新たな CVS モジュールへのリクエストが書き込みアクセス権を得るために承認された後で最大で1時間待つ必要があるかもしれません。Fedora アカウントシステム(FAS) と同様に公開鍵を確認してください。鍵の伝搬は FAS へアップロード後、1時間程度かかります。
パッケージをテストする
あなたのパッケージをテストするためのより詳しい情報は、 Mockを使ってパッケージのビルドをテストする と Kojiビルドシステムを使う を見てください。 Mockは、あなたのローカルシステムを使いますが、Kojiコマンドラインツールの方は、Fedoraのビルドシステムサーバを使います。
パッケージをインポートし、コミットし、ビルドする
今、あなたは fedpkg コマンドで(空の)パッケージモジュールをチェックアウトしました。そして、そのモジュールへ移動します。
cd MODULE_NAME
SCM 内へ SRPM のコンテンツをインポートするために fedpkg コマンドを実行してください。
fedpkg import PATH_TO_SRPM (Review Changes) fedpkg commit -p
明示的に、PATH_TO_SRPM の部分を承認された SRPM へのフルパス(URL ではない)に置き換えて実行ください。
これは master (rawhide) ブランチにのみインポートします。
さらに F-9 のように、その他のディストリビューションのパッケージをインポートする -b パラメータを使用して追加パッケージのインポート も おそらく行いたいでしょう。例えば、
./common/cvs-import.sh -b F-9 PATH_TO_SRPM
cvs-import.sh プログラムは次のように応答します。
Checking out module: 'NAME'
もしかしたらこの数倍のエラーを見るかもしれませんが、これらのエラーは無視できます。
buffer_get_ret: trying to get more bytes 129 than in buffer 34 buffer_get_string_ret: buffer_get failed buffer_get_bignum2_ret: invalid bignum key_from_blob: can't read rsa key key_read: key_from_blob AA.... failed
とはいえ、無視できるエラーだけでなく、次の表示を確認します。
Unpacking source package: NAME....src.rpm...
ソースパッケージに含まれていたソースファイルのリストに沿って、そのファイルをアップロードしてチェックするようにしてください。
その後、"If you want to make any changes before committing, please press Ctrl-C. Otherwise press Enter to proceed to commit." と表示されるのでエンターキーを押下してください。
最後に(もし他のエディタを設定していないなら) changelog を編集するために vi で開かれます。changelog は .spec ファイルの最後で記述する内容と同じフォーマットを使用してください。あなたが vi を使ったことがないなら changelog の内容を記述した後で 'エンターキー' を押下して次のように入力してください。
:wq
そして、入力を終了させるためにもう1度 'エンターキー' を押下してください。
ブランチを更新する(if desired)
f# (公式には F-# で、以前のは FC-#), master 等です。従って f13 は Fedora 13 のブランチです。
しかし、ローカルディレクトリは厳密に正しいバージョンのファイルを持っていないかもしれません。そのため、そのブランチディレクトリへ移動して(例えば cd devel/ 又は cd f12/)、実行するようにしてください。
git pull
Bodhi へ至るものとしてパッケージを投稿する
Bodhi という Fedora アップデートシステムはアップデートの公開やパッケージの分類等のために使用されます。Bodhi 経由で "master" (別名 rawhide) パッケージを投稿してはいけません。
コマンドラインから Bodhi を使用してアップデートを転送することができます。
fedpkg update
また Bodhi ガイド で説明されているように直接的に "bodhi" コマンドを使用することもできます。
新しいパッケージをリリースした各 Fedora 向けに機能拡張アップデートをリクエストするために Bodhi の Web インタフェース を使用することもできます。
最初のフィールドは "package" の名前を尋ねています。このフィールドは Koji ビルドシステムで検出されたパッケージ名を自動補完します。例えば <package-name>-<version>-<release>.fc9 といった感じです。もし補完機能が動作しなかったら、パッケージのビルド名を自分で入力してください。
新しいパッケージでは、アップデートの "type" として "newpackage" を選択してください。
最初にテストを通してパッケージを追加したいなら "Request" に "testing" を選択してください。詳細は Fedora 品質保証 を参照してください。そのパッケージを直接、安定版としたいなら "stable" を選択してください。
"Bugs" フィールドにパッケージのレビューリクエストのバグ番号を追加してください。Bodhi はリクエストしたアップデートステータスが転送されたときに自動的にそのバグを NEXTRELEASE としてクローズします。
新しいパッケージでは、エンドユーザにそのパッケージの概要が分かるように "Notes" セクションにパッケージの説明のコピーを追加してください。
詳細は Bodhi ガイド と Bodhi 環境の詳細情報 を参照してください。
bodhi 経由でアップデートを投稿した後、パッケージはキューに置かれます。定期的に管理者はそのキューをチェックして全てのパッケージを適用可能なリポジトリへ転送します。
パッケージを "comps" ファイルで利用可能にする
パッケージが適切なら、インストール中や yum のパッケージグループ操作で追加して選択されるように "comps" ファイルで利用可能にしてください。詳細は PackageMaintainers/CompsXml を参照してください。
アップデートを監視する
Fedora には、あなたがパッケージングしているソフトウェアのアップストリームの新たなリリースを監視するために利用できるインフラがあります。詳細はアップストリームのリリースを監視するを参照してください。パッケージアップデート入門を読んでアップデートの取り扱い方を学んでください。
ヘルプを取得する
我々はこのプロセスが時には泥のように不明確であることを認識していて、常にもっとより良いプロセスにしようと挑戦しています。あなたが何らかの問題に遭遇したり、何か質問があったら devel メーリングリストか、freenode の #fedora-devel で尋ねてください。詳細はコミュニケーションページを参照してください。
Fedora メンタープロジェクトには、パッケージングのために新たな貢献者を喜んで手伝ってくれる人たちがいます。詳細はメンターページを参照してください。
さらにパッケージメンテナのための git 使用の FAQ も参照してください。
既存のメンテナのために Fedora パッケージコレクションに新たなパッケージを入れる
あなたが既に Fedora のパッケージをメンテナンスしていて他のパッケージをメンテナンスしたいなら、既存の貢献者のための新たなパッケージプロセスに従うようにしてください。
一度限りの貢献
既存パッケージ への変更は、プルリクエスト を投稿することにより、提案可能です。プルリクエストを作成するためには、Fedoraアカウント を持たなければなりません。
もし、あなたのアカウントが'packager'グループにない場合は、あなたはsrc.fedoraproject.org上でフォークしたレポジトリに対して、変更をプッシュすることはできませんから、外部のGitホスティングプラットフォーム（例えば、https://pagure.io/new など）を使い、リモートからのプルリクエストを使わなければいけません。