SSH鍵を設定もしなければいけません。あなた自身のパッケージを含む、いずれのパッケージに対する変更できるようにするためです。fedpkgは、あなたの鍵リング(訳注:ローカルPCに保存されるあなたのSSHログインセッションに関するデータベース)に、利用可能な正しいSSH鍵があることを期待しています。SSH鍵を設定もしなければいけません。あなた自身のパッケージを含む、いずれのパッケージに対する変更できるようにするためです。fedpkgは、あなたの鍵リング(訳注:ローカルPCに保存されるあなたのSSHログインセッションに関するデータベース)に、利用可能な正しいSSH鍵があることを期待しています。Kerberoseユーザ識別情報を取得しなければなりません。次のように実行します。Kerberoseユーザ識別情報を取得しなければなりません。Kojiの中でパッケージをビルドする前に、やります。次のように実行します。Fedoraアカウントシステムのユーザ名をセットしてください。Fedoraアカウントシステムのユーザ名をセットしてください。実行することもできます。コマンドを短い説明とともに、表示しています。copy'.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}+{{hidden|header=詳細|content=サーバからパッケージソースのコピーを取得します。作業用コピーとして知られています。away.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}+{{hidden|header=詳細|content="ルックアサイドキャッシュ"(詳細は下記参照)に保存されたパッケージソースを取得します。sourcesを使って、だと思います)しても良いです。now.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}+{{hidden|header=詳細|content=これはRPMパッケージガイドではありませんので、ここであなたがしていることをわかっていることを前提としています。新しいパッケージソースとパッチは、今、作業コピーのディレクトリにあります。so.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}+{{hidden|header=詳細|content=これはパッチが間違いなく適用されていることを確認するのに便利です。必要なときに、ソースツリーを調査するのにも便利です。below).|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}+{{hidden|header=詳細|content=これは一番簡単な部類のテストビルドです。MockかKojiでお試しビルド(下記参照)でテストする方が大抵はより間違いなく、より良いテストです。Mockが正しく構成されている前提です。見ると、役に立つかもしれません。コマンドで実行します。changelog...|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}+{{hidden|header=詳細|content=これは間違って何かをさわってないことや、リリースし忘れたり、変更履歴に入れ忘れたりしてないことを確認するのに便利です。いう名前で、rpmlintの設定ファイルを作れます。デフォルトでは、作業ディレクトリにある全部のファイルを、gitレポジトリの一部であるとみなしません。(これは、ソースツリーのような、関係ある他のファイルを保存するのに便利です)。このコマンドを実行すると、gitは、ローカル上で、これらのファイルをgitレポジトリの一部としてみなし始めます。コミットして、プッシュすると、この変更が、サーバに伝達されます。system.}}+{{admon/warning|Alert|これは、現在のソースファイルの一覧を置き換えますが、一覧に追加はしません。ルックアサイドキャッシュシステムについてを参照。システムに保存されていて、gitに直接コミットはされていません。これは、より効率的な保存とファイル転送を提供します。ルックアサイドキャッシュと同期しつづけます。使われるときはいつでも、それらのファイルへの変更を忘れずにコミットしてください。ある全部のファイルを置き換えます。通常このコマンドは、一個のtarファイルにまとめられているソースファイルを持つ多くのパッケージに対して、このコマンドが使われます。新しい開発元のバージョンに対して、アップデートするごとに行われます。与えられたファイルをすでにキャッシュにあるファイルに追加するだけです。周辺に置かれている古くなったソースファイルをそのままにしないようにしてください。branches.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}+{{hidden|header=詳細|content=Fedoraリリースは、パッケージリポジトリにリリースごとのブランチを持っているので、異なるビルドを各リリースに送れます。ブランチを使った作業の詳細は下記参照してください。not.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}+{{hidden|header=詳細|content=このコマンドはあなたのパッケージのchangelogエントリを{{filename|clog}}というファイルに抽出します。changelogとして使うこともできます。メンテナの中には両者を区別する人もいれば、そうしない人もいます。変更されたファイルをステージに上げて、一度に全てをコミットします。gitが追跡していないファイルを追加はしません。each.+{{hidden|header=詳細|content=これは、レポジトリへのあなたの変更をまとめ、一つの'commit'とします。これには、独自の識別子と変更履歴を伴います。通じて、最も細かいレベルの詳細情報として、レポジトリへの変更履歴を見られます。一つの目的ごとに、比較的小さくコミットすることをおすすめします。複数の空白の修正といくつかのスクリプトレットの修正を一つのコミットにまとめて、一つのバージョンとせずに、それぞれを別のコミットとして作ることをおすすめします。これは、前のステップで変更履歴として使われているものです。コミットと同時に、プッシュします(詳細は下記参照)。ステップを一つにつなぎ合わせたものです。it.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}+{{hidden|header=詳細|content=これは、ローカルの作業用コピーにある新しい’コミット'全てを上流のサーバに送信します。実行して、どこか他のレポジトリのもう一つのコピーに対して、あなたの作業用コピーに対してあなたが取得したものを比較してから、そこに対してテストビルドを走らせのが良いでしょう。content,+{{hidden|header=詳細|content=複数のビルドを投稿するためのコマンドラインでは、ストリームブランチとの違いはありません。いう設定ファイルを作り、ビルドのための設定が必要となります。いうストリームブランチには、次のような設定ファイルを作ります。ブランチで、リリースのためにビルドを投稿することができます。いう短い名前を指定できます。fedpkgは、現在アクティブなFedoraとEPELのリリースを自動的に取得します。したがって、もしサブセットのリリースを選びたくない場合、もしくは、具体的なリリース名を知らずに、アクティブなリリースに対してパッケージをビルドしたいのなら、短い名前は便利です。いう名前を使ってください。container-build+{{admon/important|プロダクションに入れる|あなたが実際の利用者を本当の混乱を引き起こす可能性があります。注意して使いましょう。例にならって、Rawhideで動かす時は、あなたのビルドは、Rawhide向けに動くでしょう。Rawhideのユーザは、コマンドを打ってから、数時間後にビルドが有効になります。command.}}+{{admon/note|プッシュした状態を使う|上で挙げたのほとんどのコマンドと違い、あなたがgitへプッシュした状態で動きます。ローカルの状態ではありません。問題があれば、すべてのパッチが正しくプッシュされて、コミットされていること、そして、ソースコードを正しく処理できていることを確認してください。correctly.}}+{{hidden|header=詳細|content=これは、あなたのパッケージを[[Koji]]で本当にビルド(お試しではなく)します。なるかもしれませんし、アップデートプロセスを通じて、起動しなければならないかもしれません。詳細は、パッケージのアップデートガイドを見てください。コマンドは、あなたがKojiでのビルドの進行状況を確認できるURLを出力します。このステップは、実際には、Rawhideには適用できませんが、完全を期すためにここに示しています。this:+各Fedoraのリリースは、gitレポジトリの中のブランチで表現されています。example:++"master"ブランチは、[[Releases/Rawhide|Rawhide]]用です。各ブランチは完全に分離して維持管理できます。要求の範囲内である限りは)。gitは、ブランチを取り扱うための便利ないくつかのツールを提供しています。build.+これは"master"(Rawhide)ブランチからf{{FedoraVersionNumber}}ブランチへの変更点をマージします。gitマニアたちは、これはやや変わった業務フローだと気づくかもしれません。パッケージの保守管理という文脈においては、適切です。リリースをプッシュしたりビルドした後では、他のFedoraユーザがあなたのビルドを見るよりも前に、アップデートを投稿する必要があります。this:+ブランチが以前に分岐しない場合に限り、マージは正常に機能することに注意してください。conflict")するかもしれません。others.+gitは、"協働的"なシステムであり、Fedoraパッケージ管理においては、そのように使われていることを忘れないでください。多くの場合、あなたは、あるパッケージに他の人が加えた変更を考慮しなければならず、あなたの変更が他の人にも影響があるということを考慮しなければなりません。github].+これは大きな話題です。このガイドの範囲を幾分か超えます。基本的な視点を提示します。github]にあります。mergeするとき、衝突が発生したとき、衝突しているファイルを編集できます。ファイルの中の衝突マークを取り除き、手で変更箇所をマージしましょう。diff}}を使って、競合前の状態の変更箇所を精査し、その解決であなたが幸せであることを確認しましょう。set.+Gitは、グラフィカルなプログラムを提供しており、それは、競合を解決する手助けをしてくれます。これは、どのような変更が起きたかを可視化し、一つのセットとして変更を扱う点が便利です。GUIの中ですべての競合を解決する。rubyもしくはghcパッケージのすべて)、それらをリビルドする必要があるので、特別なレポジトリの中で、最初にビルドしてしまうのが良いかもしれません。すれば、Rawhideであまり破壊的なことは起きません。リリースエンジニアリングチケット]を発行し、特別なdistタグを要求できます。developer.+ID確認なしでパッケージをチェックアウトします。レポジトリに対して変更をプッシュはできませんが、パッケージャーでない人がパッケージを単に精査したり、自分の用途に合わせて変更を加えたい、そしておそらくFedora開発者に変更を提出したいときに便利です。above.+もしgitコマンドを使って、ブランチし、直接チェックアウトするなら、あなたが希望するどのようなローカルブランチ名でも定義できます。switch-branch}}を使うならば、上の例で使われている名前がデフォルトで作成されます。[[Git_Quickref#Display_current_branch_in_bash|here]].+よく助かるのが、一目であなたが作業しているブランチがわかることです。あなたは、この情報をバッシュのプロンプトに追加できます。[[Git_Quickref#Display_current_branch_in_bash|ここ]]に書かれている情報をみてください。コマンドは、最初に.src.rpmファイルからgitパッケージレポジトリを作成するために使われます。Process|パッケージレビュー手順]]では、作業コピーをアップデートするためにも使われます。実行して、新しいtarで固めらたファイルをルックあサイドキャッシュにアップし、gitに見つかった最新バージョンの作業コピーを更新し、すべての変更をコミットします。すると、他にも受け取るパラメータのドキュメントが表示されます。recommended.}}+{{admon/warning|注意!|このやり方は、あなたの変更が安全であるか確認するのが難しくなります。他の人が行なった変更を上書きしないでください。この理由のために、このやり方は非推奨となっています。あなたは、''{{FedoraVersionNumber}}''ブランチで、パッケージビルドに成功しましたが、''{{FedoraVersionNumber|last}}''では、ビルドできない問題が起きています。そのブランチで変更し、リリースタグの一番右に、数字を追加します。他のブランチでは、リリースを変更するはありません。これにより、ユーザがFedoraの新しいリリースにアップグレードした場合でも、アップグレードはスムーズに機能します。thread].+タグとビルドはいつも通りです。corrected.+時々あなたがRawhideやアルファ版以前のブランチに投稿したパッケージを削除したいと思うかもしれません。これは、パッケージ開発元が次のリリースで修正される予定だけど、あなたのパッケージには、バグや問題がある状況で起こり得ます。あなたがビルドで重大な間違いを犯したために簡単に修正できないと気づく場合もあります。compose.}}+{{admon/caution|注意して使うこと!|これは、compose(Fedoraのスナップショット)にパッケージが含まれる前の状態で、ビルドした日と同じ日でだけ実施されるべきです。パッケージがcomposeに含まれてしまっていたならば、タグを外してはいけません。確認して、最後のcomposeが始まった時刻を確認してください。foo-1.1.3-1.fc{{FedoraVersionNumber|next}}}}をつかって、パッケージを削除できます。なっている部分は、あなたのパッケージビルドの名前に置き換えてください。含めることをお勧めします。これは、鍵が正しいことをDNSを使って結論づけます。ある鍵の一覧と照合することもできます。known_hostsファイルに入っています。正しい文字列であることを確認して、文字列を受け入れることができます。プロトコルを使って、レポジトリをクローンします。普通これは、問題になるべきではありません(あなたが自分のSSH鍵をつかっている限りは)。経由でアクセスされていることを確認してください。time).+あなたのパッケージはローカルでビルドされていますか?Mockを使っていても、スクラッチビルドとしてもです。イラつく前に、思い出してください。パッケージがアップストリームのレポジトリの中にあるように、動いています。あなたのローカルのワーキングコピーではありません。すべての変更とソースファイルがコミットされ、プッシュされ、ルックアサイドキャッシュを正しく処理していることを確認してください。parallelization]や、テストスイートが原因で失敗することが挙げられます(そしてビジーなビルドシステムは時間通りに操作を実行できないかもしれません)。[edit]このページでは、gitベースのFedoraのパッケージ保守管理システムの、日常的に行う基本操作を説明しています。主な対象読者は、新規、及び、既存のFedoraのパッケージ保守管理者です。簡単に匿名かつ読み取り専用でのシステムの利用も含んでいます。このガイドは、RPMパッケージングガイドではありません。インストールを開始してください。これは、パッケージ管理システムへの主要なインターフェースとなります。SSH鍵を設定もしなければいけません。あなた自身のパッケージを含む、いずれのパッケージに対する変更できるようにするためです。fedpkgは、あなたの鍵リング(訳注:ローカルPCに保存されるあなたのSSHログインセッションに関するデータベース)に、利用可能な正しいSSH鍵があることを期待しています。Kerberoseユーザ識別情報を取得しなければなりません。Kojiの中でパッケージをビルドする前に、やります。次のように実行します。Fedoraアカウントシステムのユーザ名をセットしてください。実行することもできます。コマンドを短い説明とともに、表示しています。<source_package_name>詳細サーバからパッケージソースのコピーを取得します。作業用コピーとして知られています。sources詳細"ルックアサイドキャッシュ"(詳細は下記参照)に保存されたパッケージソースを取得します。sourcesを使って、だと思います)しても良いです。パッケージに変更をする詳細これはRPMパッケージガイドではありませんので、ここであなたがしていることをわかっていることを前提としています。新しいパッケージソースとパッチは、今、作業コピーのディレクトリにあります。prep詳細これはパッチが間違いなく適用されていることを確認するのに便利です。必要なときに、ソースツリーを調査するのにも便利です。local詳細これは一番簡単な部類のテストビルドです。MockかKojiでお試しビルド(下記参照)でテストする方が大抵はより間違いなく、より良いテストです。Mockが正しく構成されている前提です。見ると、役に立つかもしれません。コマンドで実行します。diff詳細これは間違って何かをさわってないことや、リリースし忘れたり、変更履歴に入れ忘れたりしてないことを確認するのに便利です。いう名前で、rpmlintの設定ファイルを作れます。デフォルトでは、作業ディレクトリにある全部のファイルを、gitレポジトリの一部であるとみなしません。(これは、ソースツリーのような、関係ある他のファイルを保存するのに便利です)。このコマンドを実行すると、gitは、ローカル上で、これらのファイルをgitレポジトリの一部としてみなし始めます。コミットして、プッシュすると、この変更が、サーバに伝達されます。new-sourcesAlertこれは、現在のソースファイルの一覧を置き換えますが、一覧に追加はしません。ルックアサイドキャッシュシステムについてを参照。システムに保存されていて、gitに直接コミットはされていません。これは、より効率的な保存とファイル転送を提供します。ルックアサイドキャッシュと同期しつづけます。使われるときはいつでも、それらのファイルへの変更を忘れずにコミットしてください。ある全部のファイルを置き換えます。通常このコマンドは、一個のtarファイルにまとめられているソースファイルを持つ多くのパッケージに対して、このコマンドが使われます。新しい開発元のバージョンに対して、アップデートするごとに行われます。与えられたファイルをすでにキャッシュにあるファイルに追加するだけです。周辺に置かれている古くなったソースファイルをそのままにしないようにしてください。master>詳細Fedoraリリースは、パッケージリポジトリにリリースごとのブランチを持っているので、異なるビルドを各リリースに送れます。ブランチを使った作業の詳細は下記参照してください。clog詳細このコマンドはあなたのパッケージのchangelogエントリをclogというファイルに抽出します。changelogとして使うこともできます。メンテナの中には両者を区別する人もいれば、そうしない人もいます。変更されたファイルをステージに上げて、一度に全てをコミットします。gitが追跡していないファイルを追加はしません。詳細これは、レポジトリへのあなたの変更をまとめ、一つの'commit'とします。これには、独自の識別子と変更履歴を伴います。通じて、最も細かいレベルの詳細情報として、レポジトリへの変更履歴を見られます。一つの目的ごとに、比較的小さくコミットすることをおすすめします。複数の空白の修正といくつかのスクリプトレットの修正を一つのコミットにまとめて、一つのバージョンとせずに、それぞれを別のコミットとして作ることをおすすめします。これは、前のステップで変更履歴として使われているものです。コミットと同時に、プッシュします(詳細は下記参照)。ステップを一つにつなぎ合わせたものです。push詳細これは、ローカルの作業用コピーにある新しい’コミット'全てを上流のサーバに送信します。実行して、どこか他のレポジトリのもう一つのコピーに対して、あなたの作業用コピーに対してあなたが取得したものを比較してから、そこに対してテストビルドを走らせのが良いでしょう。複数のビルドを投稿するためのコマンドラインでは、ストリームブランチとの違いはありません。いう設定ファイルを作り、ビルドのための設定が必要となります。いうストリームブランチには、次のような設定ファイルを作ります。ブランチで、リリースのためにビルドを投稿することができます。いう短い名前を指定できます。fedpkgは、現在アクティブなFedoraとEPELのリリースを自動的に取得します。したがって、もしサブセットのリリースを選びたくない場合、もしくは、具体的なリリース名を知らずに、アクティブなリリースに対してパッケージをビルドしたいのなら、短い名前は便利です。いう名前を使ってください。コンテナ層のイメージビルドを使用している場合:プロダクションに入れるあなたが実際の利用者を本当の混乱を引き起こす可能性があります。注意して使いましょう。例にならって、Rawhideで動かす時は、あなたのビルドは、Rawhide向けに動くでしょう。Rawhideのユーザは、コマンドを打ってから、数時間後にビルドが有効になります。プッシュした状態を使う上で挙げたのほとんどのコマンドと違い、あなたがgitへプッシュした状態で動きます。ローカルの状態ではありません。問題があれば、すべてのパッチが正しくプッシュされて、コミットされていること、そして、ソースコードを正しく処理できていることを確認してください。詳細これは、あなたのパッケージをKojiで本当にビルド(お試しではなく)します。なるかもしれませんし、アップデートプロセスを通じて、起動しなければならないかもしれません。詳細は、パッケージのアップデートガイドを見てください。コマンドは、あなたがKojiでのビルドの進行状況を確認できるURLを出力します。このステップは、実際には、Rawhideには適用できませんが、完全を期すためにここに示しています。コミットしてプッシュを一回で実行ブランチで作業する各Fedoraのリリースは、gitレポジトリの中のブランチで表現されています。master"master"ブランチは、Rawhide用です。各ブランチは完全に分離して維持管理できます。要求の範囲内である限りは)。gitは、ブランチを取り扱うための便利ないくつかのツールを提供しています。pushこれは"master"(Rawhide)ブランチからf31ブランチへの変更点をマージします。gitマニアたちは、これはやや変わった業務フローだと気づくかもしれません。パッケージの保守管理という文脈においては、適切です。リリースをプッシュしたりビルドした後では、他のFedoraユーザがあなたのビルドを見るよりも前に、アップデートを投稿する必要があります。ブランチが以前に分岐しない場合に限り、マージは正常に機能することに注意してください。conflict")するかもしれません。mastergitは、"協働的"なシステムであり、Fedoraパッケージ管理においては、そのように使われていることを忘れないでください。多くの場合、あなたは、あるパッケージに他の人が加えた変更を考慮しなければならず、あなたの変更が他の人にも影響があるということを考慮しなければなりません。衝突したマージを解決するこれは大きな話題です。このガイドの範囲を幾分か超えます。基本的な視点を提示します。githubにあります。mergeするとき、衝突が発生したとき、衝突しているファイルを編集できます。ファイルの中の衝突マークを取り除き、手で変更箇所をマージしましょう。diffを使って、競合前の状態の変更箇所を精査し、その解決であなたが幸せであることを確認しましょう。mergetoolを使って競合を解決するGitは、グラフィカルなプログラムを提供しており、それは、競合を解決する手助けをしてくれます。これは、どのような変更が起きたかを可視化し、一つのセットとして変更を扱う点が便利です。GUIの中ですべての競合を解決する。rubyもしくはghcパッケージのすべて)、それらをリビルドする必要があるので、特別なレポジトリの中で、最初にビルドしてしまうのが良いかもしれません。すれば、Rawhideであまり破壊的なことは起きません。あなたがこのようなケースに陥るアップデートを抱えていると考えるならば、あなたは、リリースエンジニアリングチケットを発行し、特別なdistタグを要求できます。<somepackage>ID確認なしでパッケージをチェックアウトします。レポジトリに対して変更をプッシュはできませんが、パッケージャーでない人がパッケージを単に精査したり、自分の用途に合わせて変更を加えたい、そしておそらくFedora開発者に変更を提出したいときに便利です。ローカルなブランチ名もしgitコマンドを使って、ブランチし、直接チェックアウトするなら、あなたが希望するどのようなローカルブランチ名でも定義できます。switch-branchを使うならば、上の例で使われている名前がデフォルトで作成されます。シェルプロンプトに現在のブランチと状態を表示するよく助かるのが、一目であなたが作業しているブランチがわかることです。あなたは、この情報をバッシュのプロンプトに追加できます。ここに書かれている情報をみてください。コマンドは、最初に.src.rpmファイルからgitパッケージレポジトリを作成するために使われます。あなたが愛着をもっている古いパッケージングプロセスパッケージレビュー手順では、作業コピーをアップデートするためにも使われます。実行して、新しいtarで固めらたファイルをルックあサイドキャッシュにアップし、gitに見つかった最新バージョンの作業コピーを更新し、すべての変更をコミットします。すると、他にも受け取るパラメータのドキュメントが表示されます。注意!このやり方は、あなたの変更が安全であるか確認するのが難しくなります。他の人が行なった変更を上書きしないでください。この理由のために、このやり方は非推奨となっています。あなたは、31ブランチで、パッケージビルドに成功しましたが、lastでは、ビルドできない問題が起きています。そのブランチで変更し、リリースタグの一番右に、数字を追加します。他のブランチでは、リリースを変更するはありません。これにより、ユーザがFedoraの新しいリリースにアップグレードした場合でも、アップグレードはスムーズに機能します。1%{?dist}.1タグとビルドはいつも通りです。Branchedでペンディングになっているパッケージビルドを削除する時々あなたがRawhideやアルファ版以前のブランチに投稿したパッケージを削除したいと思うかもしれません。これは、パッケージ開発元が次のリリースで修正される予定だけど、あなたのパッケージには、バグや問題がある状況で起こり得ます。あなたがビルドで重大な間違いを犯したために簡単に修正できないと気づく場合もあります。注意して使うこと!これは、compose(Fedoraのスナップショット)にパッケージが含まれる前の状態で、ビルドした日と同じ日でだけ実施されるべきです。パッケージがcomposeに含まれてしまっていたならば、タグを外してはいけません。確認して、最後のcomposeが始まった時刻を確認してください。foo-1.1.3-1.fc32をつかって、パッケージを削除できます。なっている部分は、あなたのパッケージビルドの名前に置き換えてください。含めることをお勧めします。これは、鍵が正しいことをDNSを使って結論づけます。ある鍵の一覧と照合することもできます。known_hostsファイルに入っています。正しい文字列であることを確認して、文字列を受け入れることができます。プロトコルを使って、レポジトリをクローンします。普通これは、問題になるべきではありません(あなたが自分のSSH鍵をつかっている限りは)。経由でアクセスされていることを確認してください。ここでビルドして、なんでそこでビルドしない?あなたのパッケージはローカルでビルドされていますか?Mockを使っていても、スクラッチビルドとしてもです。イラつく前に、思い出してください。パッケージがアップストリームのレポジトリの中にあるように、動いています。あなたのローカルのワーキングコピーではありません。すべての変更とソースファイルがコミットされ、プッシュされ、ルックアサイドキャッシュを正しく処理していることを確認してください。parallelizationや、テストスイートが原因で失敗することが挙げられます(そしてビジーなビルドシステムは時間通りに操作を実行できないかもしれません)。Guidelines。