使用することができます。ビルド)テストができることに注意してください。使用してスクラッチビルドを行う最も簡単な方法はコマンドラインで次のように実行します。ようにディストリビューションのキーワードです。実行すると全ての対応ディストリビューションを確認できます。最新の安定バージョンの番号よりも高い番号を指定する)を使用してください。与える必要があることに注意してください。ディストリビューションのリポジトリにあるパッケージのみに依存します。使用してビルドすることはできません。ビルドすることができます。上書きするようにリクエストすることができます。使用する必要があります。ついてヘルプから学習することができます。パッケージの作成方法を参照してください。パッケージング名ガイドラインに準拠しているかを確認してください。パッケージレビューガイドラインに注意してください(パッケージレビューに使用されます)。パッケージがビルドできることを確認してください。これは意外に重要です。注目されるほどの数の投稿がビルドしてないからです。ファイルをインターネット上のどこかにアップロードしてください。どこからでもアクセスできる場所になります。重要なことは、直接アクセスができることです。何かのサービスに隠れていないこと(ダウンロードされるまでに待たされたり、広告ページ経由でリダイレクトされる)が重要です。あなたが、公式レポジトリにパッケージを置くまでの間、ユーザーが必要に応じてビルドできるようにしたい場合は、Coprの利用を考えてください。軽量で自動化されたビルドシステムです。あなたがアップするSRPMを使ってレポジトリを作成できます。あなたは、Coprのスペースを使って、レビューアーにあなたの作ったsrc.rpmファイルとspecファイルの場所を提示することができます。フォームに記入してください。あなたのリクエストを投稿する前に同じパッケージに対して直前のリクエストがないかを確認してください。あることを確認してください。フィールドに追加してください。これはあなたの最初のパッケージでスポンサーが必要であることも説明してください。スポンサーとなる人にとって助けになるかもしれない情報はなんでも含めてください。あなたが、他のレビューをすでにしているならば、それらのリンクを含めてください。あなたがパッケージ対象ソフトウエアの直接の保守管理者ならば、必ずそう書いてください。Kojiのビルドが成功しているリンクを含めてください。ボーナスポイントとなります。全員があなたが全ての宿題をやったことがわかりますから。説明していることを確認してください。パッケージコレクションでは、全ての新たな貢献者はスポンサーを得なければなりません。レビューリクエストバグを編集するために、あなたのパッケージをこのリストに追加することができます。パッケージレビュープロセスページを参照してください。アップストリームに近い状態を維持することを好みます。あなたがパッケージングしていることをそのソフトウェアの開発者へ知らせてください。自己紹介のメールを送ったり、レビューリクエストで指摘したりすることで自分がパッケージングを行っていると知らせることができます。これは今後の会話の場を提示します。一部であるという事実を通常は公示するか、既存リリースの重要なバグ、今後のロードマップ等があればあなたに知らせたくなるかもしれません。メーリングリストに自己紹介をお願いします。メーリングリストの購読ページに訪れてください。自己紹介の主な目的は、Fedoraコミュニティメンバーがあなたをもう少し詳しく知ることによって、信頼を構築するプロセスを開始し、あなたのレビューリクエストがより早く進むチャンスを増やすことです。私たちは、匿名性をなくし、プロジェクト内に、現実世界のコミュニティを作り出すことを願っています。あなたは、個人的な秘密を知らせる義務はありません。目的は、あなたとプロジェクトのほかのメンバーの間に一定の信頼を築くことです。あなたは私たちと意思疎通するときは、少なくとも自分の本当の名前を使う方が良いです。あなたが誰であるか、あなたの動機、そして、おそらくはあなたがレビューのために投稿したソフトウエアの説明をおすすめします。あなたのフリー&オープンソースプロジェクトの経験、あなたが提出したレビューリクエストへのリンク、あなた自身の簡単な説明含む、あなたが妥当と考える情報を追加してください。必要に応じてGPGキー情報を投稿することもできます。レポートを監視してください。メールで変更通知を受け取るべきです。指摘したらとにかく修正してください。スポンサーを得るレビューアがパッケージを承認した場合、そのパッケージをチェックインしてビルドするために独立してスポンサーを得なければなりません。スポンサーは自動的に得られるのではなく、パッケージガイドラインの理解度を説明するために何らかの方法で参加するということを要求します。スポンサーを得る鍵は、あなたがプロジェクトのガイドラインとプロセスを理解して従っているということを既存のスポンサーレベルのメンバーへ説得することです。あなたのスポンサーはパッケージャグループにあなたを追加することができます。スポンサーに関する確認メールを受け取るべきです。あなたのアカウントを同期してください。つかって、あなたのパッケージ用に、新しくgitレポジトリをリクエストしてください。準備するためのヘルプ文言を含んでいます。あなたは、レポジトリ名とレビューのバグ番号を指定しなければなりません。gitレポジトリ作成のリクエストは、大抵24時間以内に管理者にレビューされて、処理されます。チケットが処理されると、パッケージをコミットしてビルドするためのアクセス権が与えられます。実行することを検討してください。すると、そのディレクトリ内に全てのファイルが展開されます。実行して設定することも実行できます。実行することは良い方法です。全ての操作に対してキーフレーズ入力の手間を削減します。実行する必要があります。それはログアウトか再起動するまで有効になります。実行して新たなシェル環境で試してみてください。あなたのモジュールをチェックアウトする準備が整いました。あなたのパッケージ名に置き換えてください。セットされているかを確認してください。モジュールへのリクエストが書き込みアクセス権を得るために承認された後で最大で1時間待つ必要があるかもしれません。同様に公開鍵を確認してください。アップロード後、1時間程度かかります。自動的に新しいgitレポジトリに対して、ユーザの設定をセットしないことに注意してください。最初のコミットをする前に、新しいレポジトリの中に、グローバル、または、ローカルに、ユーザの設定がセットされていることを確認してください。settingsを見てください。denied"を受け取ることになります。ユーザ指定なしのフラグ-aを使って、クローンしてください。Mockは、あなたのローカルシステムを使いますが、Kojiコマンドラインツールの方は、Fedoraのビルドシステムサーバを使います。コマンドで(空の)パッケージモジュールをチェックアウトしました。そのモジュールへ移動します。コマンドを実行してください。ない)に置き換えて実行ください。該当パッケージのレビューバグ番号に置き換えてください。ブランチにのみコミット&ビルドし、インポートします。128そのパッケージブランチを変更するのに必要な権限をあなたが持っていないです。見て、必要な権限をリクエストしてください。