m (第五セクション) |
m (最後のセクション) |
||
Line 185: | Line 185: | ||
あなたがこのようなケースに陥るアップデートを抱えていると考えるならば、あなたは、[https://fedorahosted.org/rel-eng/newticket リリースエンジニアリングチケット]を発行し、特別なdistタグを要求できます。おそらく[[ReleaseEngineering|リリースエンジニアリング]]出身の誰かが、本当に適切なケースであるか、そして、あなたが必要とするものをあなたが獲得することを確認するために、あなたの必要性について議論したがるでしょう(あなたに確信がなければ、質問するのはOKです) | あなたがこのようなケースに陥るアップデートを抱えていると考えるならば、あなたは、[https://fedorahosted.org/rel-eng/newticket リリースエンジニアリングチケット]を発行し、特別なdistタグを要求できます。おそらく[[ReleaseEngineering|リリースエンジニアリング]]出身の誰かが、本当に適切なケースであるか、そして、あなたが必要とするものをあなたが獲得することを確認するために、あなたの必要性について議論したがるでしょう(あなたに確信がなければ、質問するのはOKです) | ||
== | == 小技とトリック == | ||
{{anchor|anon}} | {{anchor|anon}} | ||
=== | === 匿名でfedpkgを使う === | ||
次のようにfedpkgを使えます: | |||
fedpkg clone --anonymous <somepackage> | fedpkg clone --anonymous <somepackage> | ||
ID確認なしでパッケージをチェックアウトします。もちろんレポジトリに対して変更をプッシュはできませんが、パッケージャーでない人がパッケージを単に精査したり、自分の用途に合わせて変更を加えたい、そしておそらくFedora開発者に変更を提出したいときに便利です。 | |||
=== | === ローカルなブランチ名 === | ||
もしgitコマンドを使って、ブランチし、直接チェックアウトするなら、あなたが希望するどのようなローカルブランチ名でも定義できます。もし、{{command|fedpkg switch-branch}}を使うならば、上の例で使われている名前がデフォルトで作成されます。 | |||
=== | === シェルプロンプトに現在のブランチと状態を表示する === | ||
よく助かるのが、一目であなたが作業しているブランチがわかることです。あなたは、この情報をバッシュのプロンプトに追加できます。[[Git_Quickref#Display_current_branch_in_bash|ここ]]に書かれている情報をみてください。 | |||
=== | === 更新のために.src.rpmをインポートする === | ||
{{command|fedpkg import}} コマンドは、最初に.src.rpmファイルからgitパッケージレポジトリを作成するために使われます。特にあなたが愛着をもっている古いパッケージングプロセス[[Package Review Process|パッケージレビュー手順]]では、作業コピーをアップデートするためにも使われます。 | |||
ただ単に {{command|fedpkg import file.src.rpm}} を実行して、新しいtarで固めらたファイルをルックあサイドキャッシュにアップし、gitに見つかった最新バージョンの作業コピーを更新し、すべての変更をコミットします。{{command|fedpkg import --help}} すると、他にも受け取るパラメータのドキュメントが表示されます。 | |||
{{admon/warning| | {{admon/warning|注意!|このやり方は、あなたの変更が安全であるか確認するのが難しくなります。他の人が行なった変更を上書きしないでください。この理由のために、このやり方は非推奨となっています。}} | ||
=== | === アップグレードパスを壊さずに古いブランチでの変更する === | ||
想定されるシナリオ: あなたは、''{{FedoraVersionNumber}}''ブランチで、パッケージビルドに成功しましたが、''{{FedoraVersionNumber|last}}''では、ビルドできない問題が起きています。 | |||
解決策: そのブランチで変更し、リリースタグの一番右に、数字を追加します。他のブランチでは、リリースを変更するはありません。これにより、ユーザがFedoraの新しいリリースにアップグレードした場合でも、アップグレードはスムーズに機能します。 | |||
<pre> | <pre> | ||
Line 224: | Line 225: | ||
</pre> | </pre> | ||
タグとビルドはいつも通りです。このアプローチは、最初に [https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00083.html in this mailing list thread] で議論されました。 | |||
=== | === [[Releases/Rawhide|Rawhide]] または [[Releases/Branched|Branched]]でペンディングになっているパッケージビルドを削除する === | ||
時々あなたがRawhideやアルファ版以前のブランチに投稿したパッケージを削除したいと思うかもしれません。(both cases where the build would usually go out to the main [[Repositories|repository]] without further gating). これは、パッケージ開発元が次のリリースで修正される予定だけど、あなたのパッケージには、バグや問題がある状況で起こり得ます。もしくは、あなたがビルドで重大な間違いを犯したために簡単に修正できないと気づく場合もあります。 | |||
{{admon/caution| | {{admon/caution|注意して使うこと!|これは、compose(Fedoraのスナップショット)にパッケージが含まれる前の状態で、ビルドした日と同じ日でだけ実施されるべきです。 もし、パッケージがcomposeに含まれてしまっていたならば、タグを外してはいけません。[https://apps.fedoraproject.org/releng-dash/ Release Engineering Dashboard] を確認して、最後のcomposeが始まった時刻を確認してください。}} | ||
[[Koji]]: {{command|koji untag-pkg f{{FedoraVersionNumber|next}} foo-1.1.3-1.fc{{FedoraVersionNumber|next}}}}をつかって、パッケージを削除できます。 | |||
{{filename|foo-1.1.3-1.fc{{FedoraVersionNumber|next}}}} となっている部分は、あなたのパッケージビルドの名前に置き換えてください。詳細は、{{command|koji help}} もしくは [[Using_the_Koji_build_system|Kojiを使う]] を見てください。 | |||
=== | === SSHの指紋 === | ||
~/.ssh/config に、"<code>VerifyHostKeyDNS yes</code>" を含めることをお勧めします。これは、鍵が正しいことをDNSを使って結論づけます。 | |||
https://admin.fedoraproject.org にある鍵の一覧と照合することもできます。そこにある文字列は〜/ .ssh / known_hostsファイルに入っています。ですから、あなたは、プロンプトが出たときに、〜/ .ssh / known_hostsファイルに入っている src.fedoraproject.org の正しい文字列であることを確認して、文字列を受け入れることができます。 | |||
=== | === レポジトリに接続中に発生する問題 === | ||
''fedpkg'' ツールは、ssh:// プロトコルを使って、レポジトリをクローンします。ですので、普通これは、問題になるべきではありません(あなたが自分のSSH鍵をつかっている限りは)。もし、"git" ユーティリティそれ自体を使ってクローンしているならば、{{filename|.git/config}} ファイルを確認して、リモートレポジトリが ssh:// 経由でアクセスされていることを確認してください。git:// 経由ではありません。 | |||
=== | === ここでビルドして、なんでそこでビルドしない? === | ||
あなたのパッケージはローカルでビルドされていますか?Mockを使っていても、スクラッチビルドとしてもです。- しかし、{{command|fedpkg build}} を実行したときではありませんか? イラつく前に、思い出してください。{{command|fedpkg build}} は、パッケージがアップストリームのレポジトリの中にあるように、動いています。あなたのローカルのワーキングコピーではありません。すべての変更とソースファイルがコミットされ、プッシュされ、ルックアサイドキャッシュを正しく処理していることを確認してください。報告されている他の問題としては、[https://bugzilla.redhat.com/show_bug.cgi?id=1179139 build / make check parallelization]や、テストスイートが原因で失敗することが挙げられます(そしてビジーなビルドシステムは時間通りに操作を実行できないかもしれません)。 | |||
== References == | == References == |
Latest revision as of 07:18, 29 March 2019
このページでは、gitベースのFedoraのパッケージ保守管理システムの、日常的に行う基本操作を説明しています。主な対象読者は、新規、及び、既存のFedoraのパッケージ保守管理者です。しかし、簡単に匿名かつ読み取り専用でのシステムの利用も含んでいます。このガイドは、RPMパッケージングガイドではありません。gitについてのある程度の事前知識があると助かるかもしれませんが、必須ではありません(事実、Fedoraパッケージングは、gitの導入は比較的簡単だと思われます)
あなたは、以下のようなことをずっと探していた、もしくは、興味があるかもしれません:
- パッケージの作り方を学ぶ
- パッケージの保守管理者になる
- パッケージ更新を投稿する
- 既存の保守管理者として レポジトリに新しいパッケージを追加する
- 既存パッケージに対して 新しいリリースブランチを登録する
- Fedoraパッケージガイドライン
fedpkg のインストールと初期設定の実施
dnf install fedpkg
を実行して、
のインストールを開始してください。これは、パッケージ管理システムへの主要なインターフェースとなります。
fedpkg
あなたは、Fedoraアカウントシステム に、SSH鍵を設定もしなければいけません。あなた自身のパッケージを含む、いずれのパッケージに対する変更できるようにするためです。fedpkgは、あなたの鍵リング(訳注:ローカルPCに保存されるあなたのSSHログインセッションに関するデータベース)に、利用可能な正しいSSH鍵があることを期待しています。
最初に kinit
で Kerberoseユーザ識別情報を取得しなければなりません。new-sources
と upload
でパッケージをアップしたり、例えば build
でKojiの中でパッケージをビルドする前に、やります。次のように実行します。:
kinit [FAS name]@FEDORAPROJECT.ORG
(FEDORAPROJECT.ORG は、全て大文字です)
~/.fedora.upn
に、Fedoraアカウントシステムのユーザ名をセットしてください。echo "FAS_USERNAME" > ~/.fedora.upn
と実行することもできます。
よく使われる fedpkg コマンド
このセクションでは、普段の一連の仕事の中で使う、典型的な fedpkg コマンドを短い説明とともに、表示しています。この一連の仕事の中では、パッケージの Rawhideブランチ上で 実行しています。
- パッケージをチェックアウトする:
fedpkg co <source_package_name> cd <source_package_name>
サーバからパッケージソースのコピーを取得します。作業用コピーとして知られています。
- Fedoraサーバからチェックアウトしたコピーを更新する:
fedpkg pull
- パッケージソースを取得する:
fedpkg sources
"ルックアサイドキャッシュ"(詳細は下記参照)に保存されたパッケージソースを取得します。必要ならば、fedpkg prep
そして fedpkg srpm
で取得されますが、すぐにコピー(訳注:fedpkg sourcesを使って、だと思います)しても良いです。
- パッケージに変更をする
これはRPMパッケージガイドではありませんので、ここであなたがしていることをわかっていることを前提としています。新しいパッケージソースとパッチは、今、作業コピーのディレクトリにあります。
- チェックアウトしたディレクトリで、'prep'ステージ(ソースを展開してパッチを適用するなど)を実行する:
fedpkg prep
これはパッチが間違いなく適用されていることを確認するのに便利です。必要なときに、ソースツリーを調査するのにも便利です。
- ローカル環境で現在の状態をビルドする:
fedpkg local
これは一番簡単な部類のテストビルドです。しかし、MockかKojiでお試しビルド(下記参照)でテストする方が大抵はより間違いなく、より良いテストです。
- モック環境で現在の状態をビルドする:
fedpkg mockbuild
これはMock ビルドを開始します。Mockが正しく構成されている前提です。 パッケージのビルドテストのためにMockを使う を見ると、役に立つかもしれません。
- 現在の状態から .src.rpmファイルを作る:
fedpkg srpm
生成された .src.rpm から Koji の'お試しビルド' (レポジトリに行かずにテストビルドを実行) します。koji build --scratch
コマンドで実行します。 (man koji
をみてください).
- Kojiでお試しビルドする: Koji scratch builds をみてください。
- あなたが変更した箇所を確認する:
fedpkg diff
これは間違って何かをさわってないことや、リリースし忘れたり、変更履歴に入れ忘れたりしてないことを確認するのに便利です。
- パッケージに対していくつかのチェックを走らせる:
fedpkg lint
いくつかのrpmlintのエラーをホワイトリストに登録し、エラーメッセージを表示させたくないなら、<source_package_name>.rpmlintrc
という名前で、rpmlintの設定ファイルを作れます。そして、それは適用されます。
- 小さなパッチもしくはコミットする新しいソースファイルをステージにアップする:
git add (somefile)
git は、デフォルトでは、作業ディレクトリにある全部のファイルを、gitレポジトリの一部であるとみなしません。(これは、ソースツリーのような、関係ある他のファイルを保存するのに便利です)。このコマンドを実行すると、gitは、ローカル上で、これらのファイルをgitレポジトリの一部としてみなし始めます。コミットして、プッシュすると、この変更が、サーバに伝達されます。
- 新しいソースファイルをルックアサイドキャッシュ(訳注:アップストリームのためのストレージシステム)にアップロードする:
fedpkg new-sources
fedpkg upload
オリジナルの開発元のソースコード(リリース用に作成されたtarファイルのような) とその他のより大きなソースファイルは、 ルックアサイドキャッシュ システムに保存されていて、gitに直接コミットはされていません。これは、より効率的な保存とファイル転送を提供します。レポジトリにある ソース
と .gitignore
ファイルは ルックアサイドキャッシュと同期しつづけます。fedpkg new-sources
を使うか fedpkg upload
が使われるときはいつでも、それらのファイルへの変更を忘れずにコミットしてください。
new-sources
は、ゼロから始めます。つまり、そのときに ルックアサイドキャッシュ にある全部のファイルを置き換えます。通常このコマンドは、一個のtarファイルにまとめられているソースファイルを持つ多くのパッケージに対して、このコマンドが使われます。新しい開発元のバージョンに対して、アップデートするごとに行われます。upload
は、与えられたファイルをすでにキャッシュにあるファイルに追加するだけです。周辺に置かれている古くなったソースファイルをそのままにしないようにしてください。
- 別のリリースブランチに移動する:
fedpkg switch-branch <f40, el6, master>
Fedoraリリースは、パッケージリポジトリにリリースごとのブランチを持っているので、異なるビルドを各リリースに送れます。ブランチを使った作業の詳細は下記参照してください。
- パッケージの変更履歴からgitのchangelogを生成する:
fedpkg clog
このコマンドはあなたのパッケージのchangelogエントリをclog
というファイルに抽出します。もしあなたが望むならば、それをgit changelogとして使うこともできます。メンテナの中には両者を区別する人もいれば、そうしない人もいます。
- 変更をコミットする:
fedpkg commit (-F clog) (-p) (-c)
これは、レポジトリへのあなたの変更をまとめ、一つの'commit'とします。これには、独自の識別子と変更履歴を伴います。あなた以外のパッケージ保守管理者とあなた自身もまた、’commit' を通じて、最も細かいレベルの詳細情報として、レポジトリへの変更履歴を見られます。一つの目的ごとに、比較的小さくコミットすることをおすすめします。複数の空白の修正といくつかのスクリプトレットの修正を一つのコミットにまとめて、一つのバージョンとせずに、それぞれを別のコミットとして作ることをおすすめします。
-F clog
パラメータは、clog
ファイルを使います。これは、前のステップで変更履歴として使われているものです。-p
は、コミットと同時に、プッシュします(詳細は下記参照)。-c
は、 clog
と commit -F clog
のステップを一つにつなぎ合わせたものです。お好みで使えます。
- 変更をプッシュする:
fedpkg push
これは、ローカルの作業用コピーにある新しい’コミット'全てを上流のサーバに送信します。もしあなたがまだシステムについて勉強中であれば、今はfedpkg co
を実行して、どこか他のレポジトリのもう一つのコピーに対して、あなたの作業用コピーに対してあなたが取得したものを比較してから、そこに対してテストビルドを走らせのが良いでしょう。
- プッシュした変更点を公式にビルドする:
fedpkg build
- ストリームブランチから公式ビルドを投稿する:
fedpkg build
複数のビルドを投稿するためのコマンドラインでは、ストリームブランチとの違いはありません。しかし、レポジトリにpackage.cfg
という設定ファイルを作り、ビルドのための設定が必要となります。例えば、foo
パッケージの 8
というストリームブランチには、次のような設定ファイルを作ります。
[koji] targets = f28 epel7
この例では、あなたが build
コマンドを実行した時に、fedpkg は f28
と epel7
のブランチで、リリースのためにビルドを投稿することができます。
実際には、便宜上 fedora
と epel
という短い名前を指定できます。fedpkgは、現在アクティブなFedoraとEPELのリリースを自動的に取得します。したがって、もしサブセットのリリースを選びたくない場合、もしくは、具体的なリリース名を知らずに、アクティブなリリースに対してパッケージをビルドしたいのなら、短い名前は便利です。rawhide
向けのビルドを指定する時は、 master
という名前を使ってください。
- Docker コンテナ層のイメージビルドを使用している場合:
- 最終ビルドのパッケージ更新を投稿する:
fedpkg update
繰り返しますが、ビルドのパッケージを更新するには、 パッケージ更新ガイド を見てください。このステップは、実際には、Rawhideには適用できませんが、完全を期すためにここに示しています。
典型的な fedpkg セッション
一つの典型的なセッションは次のような感じかもしれません:
fedpkg clone foo cd foo fedpkg sources fedpkg new-sources foo-0.0.2.tar.bz2 gedit foo.spec # specファイルの必要な部分を変更 # rpmdev-bumpspec は 簡単なバージョン更新には便利 fedpkg mockbuild # あなたが行なった変更が正しいことを確認 fedpkg diff fedpkg lint fedpkg commit -p -c # コミットしてプッシュを一回で実行
ブランチで作業する
各Fedoraのリリースは、gitレポジトリの中のブランチで表現されています。ブランチは次のように切り替えられます:
fedpkg switch-branch f40 fedpkg switch-branch f39 fedpkg switch-branch master
"master"ブランチは、Rawhide用です。各ブランチは完全に分離して維持管理できます。もし希望するなら、じっくりブランチ間の変更をコピーしてください(Updates Policy の要求の範囲内である限りは)。しかし、gitは、ブランチを取り扱うための便利ないくつかのツールを提供しています。例えば:
fedpkg clone bzrtools # masterブランチで変更する fedpkg new-sources bzrtools-2.2.tar.gz gedit bzrtools.spec fedpkg commit fedpkg switch-branch f40 git merge master # レポジトリにpush fedpkg push
これは"master"(Rawhide)ブランチからf40ブランチへの変更点をマージします。gitマニアたちは、これはやや変わった業務フローだと気づくかもしれません。しかし、パッケージの保守管理という文脈においては、適切です。おぼえておいてほしいのは、Bodhiが有効にされた、安定版もしくはBranched リリースをプッシュしたりビルドした後では、他のFedoraユーザがあなたのビルドを見るよりも前に、アップデートを投稿する必要があります。
ブランチが以前に分岐しない場合に限り、マージは正常に機能することに注意してください。つまり、こうすれば、マージは衝突("merge conflict")するかもしれません。
fedpkg clone bzrtools # masterブランチで変更する fedpkg commit fedpkg switch-branch f40 # f40 ブランチで変更する fedpkg commit fedpkg switch-branch master # masterブランチで変更する fedpkg commit fedpkg switch-branch f40 git merge master
gitは、"協働的"なシステムであり、Fedoraパッケージ管理においては、そのように使われていることを忘れないでください。多くの場合、あなたは、あるパッケージに他の人が加えた変更を考慮しなければならず、あなたの変更が他の人にも影響があるということを考慮しなければなりません。
衝突したマージを解決する
これは大きな話題です。そして、このガイドの範囲を幾分か超えます。しかし、基本的な視点を提示します。他に良い参考文献がgit book やgithubにあります。
あなたが git mergeするとき、衝突が発生したとき、衝突しているファイルを編集できます。ファイルの中の衝突マークを取り除き、手で変更箇所をマージしましょう。git diff
もしくは fedpkg diff
を使って、競合前の状態の変更箇所を精査し、その解決であなたが幸せであることを確認しましょう。
git mergetool
を使って競合を解決する
Gitは、グラフィカルなプログラムを提供しており、それは、競合を解決する手助けをしてくれます。これは、どのような変更が起きたかを可視化し、一つのセットとして変更を扱う点が便利です。
git config --global merge.tool meld fedpkg switch-branch f40 git merge master # 競合が発生した git mergetool # マージ、作業ツリー、最後のコミットの三つを # 一つにして表示する。 # GUIの中ですべての競合を解決する。 git add CONFLICTEDFILES git commit
特別なdistタグをリクエストする
あるパッケージに対する変更が、大量の依存関係に影響する場合(例えば、perl, pyton, rubyもしくはghcパッケージのすべて)、それらをリビルドする必要があるので、特別なレポジトリの中で、最初にビルドしてしまうのが良いかもしれません。そうすれば、Rawhideであまり破壊的なことは起きません。
あなたがこのようなケースに陥るアップデートを抱えていると考えるならば、あなたは、リリースエンジニアリングチケットを発行し、特別なdistタグを要求できます。おそらくリリースエンジニアリング出身の誰かが、本当に適切なケースであるか、そして、あなたが必要とするものをあなたが獲得することを確認するために、あなたの必要性について議論したがるでしょう(あなたに確信がなければ、質問するのはOKです)
小技とトリック
匿名でfedpkgを使う
次のようにfedpkgを使えます:
fedpkg clone --anonymous <somepackage>
ID確認なしでパッケージをチェックアウトします。もちろんレポジトリに対して変更をプッシュはできませんが、パッケージャーでない人がパッケージを単に精査したり、自分の用途に合わせて変更を加えたい、そしておそらくFedora開発者に変更を提出したいときに便利です。
ローカルなブランチ名
もしgitコマンドを使って、ブランチし、直接チェックアウトするなら、あなたが希望するどのようなローカルブランチ名でも定義できます。もし、fedpkg switch-branch
を使うならば、上の例で使われている名前がデフォルトで作成されます。
シェルプロンプトに現在のブランチと状態を表示する
よく助かるのが、一目であなたが作業しているブランチがわかることです。あなたは、この情報をバッシュのプロンプトに追加できます。ここに書かれている情報をみてください。
更新のために.src.rpmをインポートする
fedpkg import
コマンドは、最初に.src.rpmファイルからgitパッケージレポジトリを作成するために使われます。特にあなたが愛着をもっている古いパッケージングプロセスパッケージレビュー手順では、作業コピーをアップデートするためにも使われます。
ただ単に fedpkg import file.src.rpm
を実行して、新しいtarで固めらたファイルをルックあサイドキャッシュにアップし、gitに見つかった最新バージョンの作業コピーを更新し、すべての変更をコミットします。fedpkg import --help
すると、他にも受け取るパラメータのドキュメントが表示されます。
アップグレードパスを壊さずに古いブランチでの変更する
想定されるシナリオ: あなたは、40ブランチで、パッケージビルドに成功しましたが、lastでは、ビルドできない問題が起きています。
解決策: そのブランチで変更し、リリースタグの一番右に、数字を追加します。他のブランチでは、リリースを変更するはありません。これにより、ユーザがFedoraの新しいリリースにアップグレードした場合でも、アップグレードはスムーズに機能します。
Name: foo Version: 1.0 Release: 1%{?dist} Name: foo Version: 1.0 Release: 1%{?dist}.1
タグとビルドはいつも通りです。このアプローチは、最初に in this mailing list thread で議論されました。
Rawhide または Branchedでペンディングになっているパッケージビルドを削除する
時々あなたがRawhideやアルファ版以前のブランチに投稿したパッケージを削除したいと思うかもしれません。(both cases where the build would usually go out to the main repository without further gating). これは、パッケージ開発元が次のリリースで修正される予定だけど、あなたのパッケージには、バグや問題がある状況で起こり得ます。もしくは、あなたがビルドで重大な間違いを犯したために簡単に修正できないと気づく場合もあります。
Koji: koji untag-pkg f41 foo-1.1.3-1.fc41
をつかって、パッケージを削除できます。
foo-1.1.3-1.fc41
となっている部分は、あなたのパッケージビルドの名前に置き換えてください。詳細は、koji help
もしくは Kojiを使う を見てください。
SSHの指紋
~/.ssh/config に、"VerifyHostKeyDNS yes
" を含めることをお勧めします。これは、鍵が正しいことをDNSを使って結論づけます。
https://admin.fedoraproject.org にある鍵の一覧と照合することもできます。そこにある文字列は〜/ .ssh / known_hostsファイルに入っています。ですから、あなたは、プロンプトが出たときに、〜/ .ssh / known_hostsファイルに入っている src.fedoraproject.org の正しい文字列であることを確認して、文字列を受け入れることができます。
レポジトリに接続中に発生する問題
fedpkg ツールは、ssh:// プロトコルを使って、レポジトリをクローンします。ですので、普通これは、問題になるべきではありません(あなたが自分のSSH鍵をつかっている限りは)。もし、"git" ユーティリティそれ自体を使ってクローンしているならば、.git/config
ファイルを確認して、リモートレポジトリが ssh:// 経由でアクセスされていることを確認してください。git:// 経由ではありません。
ここでビルドして、なんでそこでビルドしない?
あなたのパッケージはローカルでビルドされていますか?Mockを使っていても、スクラッチビルドとしてもです。- しかし、fedpkg build
を実行したときではありませんか? イラつく前に、思い出してください。fedpkg build
は、パッケージがアップストリームのレポジトリの中にあるように、動いています。あなたのローカルのワーキングコピーではありません。すべての変更とソースファイルがコミットされ、プッシュされ、ルックアサイドキャッシュを正しく処理していることを確認してください。報告されている他の問題としては、build / make check parallelizationや、テストスイートが原因で失敗することが挙げられます(そしてビジーなビルドシステムは時間通りに操作を実行できないかもしれません)。
References
- https://src.fedoraproject.org/
- Infrastructure/Kerberos
- Package SCM admin requests
- Package_Renaming_Process
- PackageMaintainers/PackagingTricks
- Package_update_HOWTO
- PackageMaintainers/BuildSystemClientSetup#Install_the_Client_Tools_.28Koji.29
- PackageMaintainers/MockTricks#How_do_I_use_Mock.3F
- Using_the_Koji_build_system
- Package_Review_Process
- Fedora_Release_Life_Cycle
- PackageMaintainers/Join
- Infrastructure/VersionControl/dist-git