From Fedora Project Wiki
m (和訳修正)
m (最後のセクション)
 
(8 intermediate revisions by the same user not shown)
Line 12: Line 12:
* [[Packaging:Guidelines|Fedoraパッケージガイドライン]]
* [[Packaging:Guidelines|Fedoraパッケージガイドライン]]


== Installing ''fedpkg'' and doing initial setup ==
== ''fedpkg'' のインストールと初期設定の実施 ==


Start by installing {{package|fedpkg}} with {{command|dnf install fedpkg}}. This will be your primary interface to the packaging system.
{{command|dnf install fedpkg}} を実行して、{{package|fedpkg}} のインストールを開始してください。これは、パッケージ管理システムへの主要なインターフェースとなります。


You also must have an ssh key configured in the [https://admin.fedoraproject.org/accounts/ Fedora Accounts System] to be able to make changes to any package (including your own). fedpkg will expect the correct ssh key to be available in your keyring.
あなたは、[https://admin.fedoraproject.org/accounts/ Fedoraアカウントシステム] に、SSH鍵を設定もしなければいけません。あなた自身のパッケージを含む、いずれのパッケージに対する変更できるようにするためです。fedpkgは、あなたの鍵リング（訳注：ローカルPCに保存されるあなたのSSHログインセッションに関するデータベース）に、利用可能な正しいSSH鍵があることを期待しています。


Before uploading sources with <code>new-sources</code> and <code>upload</code> and building packages in Koji, with <code>build</code> for example, you have to get your Kerberos credential first with <code>kinit</code>, e.g.
最初に <code>kinit</code> で Kerberoseユーザ識別情報を取得しなければなりません。<code>new-sources</code> と <code>upload</code> でパッケージをアップしたり、例えば <code>build</code> でKojiの中でパッケージをビルドする前に、やります。次のように実行します。:


   kinit [FAS name]@FEDORAPROJECT.ORG
   kinit [FAS name]@FEDORAPROJECT.ORG


(Keep FEDORAPROJECT.ORG in capital case)
(FEDORAPROJECT.ORG は、全て大文字です)


Set your Fedora Account System username in {{filename|~/.fedora.upn}}.  You can do this via {{command|echo "FAS_USERNAME" > ~/.fedora.upn}}.
{{filename|~/.fedora.upn}} に、Fedoraアカウントシステムのユーザ名をセットしてください。{{command|echo "FAS_USERNAME" > ~/.fedora.upn}} と実行することもできます。


== Common fedpkg commands ==
== よく使われる fedpkg コマンド ==


This section lists typical fedpkg commands in a normal workflow, with short descriptions. Longer explanations for each can be seen by clicking the 'Show' links. In this workflow, we will be operating on the [[Releases/Rawhide|Rawhide]] branch of the package.
このセクションでは、普段の一連の仕事の中で使う、典型的な fedpkg コマンドを短い説明とともに、表示しています。この一連の仕事の中では、パッケージの [[Releases/Rawhide|Rawhide]]ブランチ上で 実行しています。


* Check out a package:
* パッケージをチェックアウトする:
  fedpkg co <source_package_name>
  fedpkg co <source_package_name>
  cd <source_package_name>
  cd <source_package_name>
{{hidden|header=Details|content=This retrieves a copy of the package sources from the server. It's known as your 'working copy'.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=詳細|content=サーバからパッケージソースのコピーを取得します。作業用コピーとして知られています。|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
* Update your checked-out copy from the Fedora server:
* Fedoraサーバからチェックアウトしたコピーを更新する:
  fedpkg pull
  fedpkg pull
* Retrieve the package sources:
* パッケージソースを取得する:
  fedpkg sources
  fedpkg sources
{{hidden|header=Details|content=This pulls any sources stored in the "lookaside cache" (see below for more). Steps like {{command|fedpkg prep}} and {{command|fedpkg srpm}} will do this if necessary, but you may want a copy right away.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=詳細|content="ルックアサイドキャッシュ"（詳細は下記参照）に保存されたパッケージソースを取得します。必要ならば、{{command|fedpkg prep}} そして {{command|fedpkg srpm}} で取得されますが、すぐにコピー（訳注：fedpkg sourcesを使って、だと思います）しても良いです。|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
* Make your changes to the package
* パッケージに変更をする
{{hidden|header=Details|content=This is not an RPM packaging guide, so we'll assume you know what you're doing here. New sources and patches go in the working copy directory for now.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=詳細|content=これはRPMパッケージガイドではありませんので、ここであなたがしていることをわかっていることを前提としています。新しいパッケージソースとパッチは、今、作業コピーのディレクトリにあります。|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
* Run the 'prep' stage (extract source, apply patches etc) within the checkout directory:
* チェックアウトしたディレクトリで、'prep'ステージ（ソースを展開してパッチを適用するなど）を実行する:
  fedpkg prep
  fedpkg prep
{{hidden|header=Details|content=This is useful for making sure your patches apply cleanly, and inspecting the source tree if you need to do so.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=詳細|content=これはパッチが間違いなく適用されていることを確認するのに便利です。必要なときに、ソースツリーを調査するのにも便利です。|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
* Do a local build of the current state:
* ローカル環境で現在の状態をビルドする:
  fedpkg local
  fedpkg local
{{hidden|header=Details|content=This is the simplest kind of test build, but it's usually cleaner and a better test to do a Mock or Koji scratch build (see below).|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=詳細|content=これは一番簡単な部類のテストビルドです。しかし、MockかKojiでお試しビルド（下記参照）でテストする方が大抵はより間違いなく、より良いテストです。|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
* Do a mock build of the current state:
* モック環境で現在の状態をビルドする:
  fedpkg mockbuild
  fedpkg mockbuild
{{hidden|header=Details|content=This fires off a [https://github.com/rpm-software-management/mock/wiki Mock] build, if you have Mock configured correctly. [[Using_Mock_to_test_package_builds]] can help there. |headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=詳細|content=これは[https://github.com/rpm-software-management/mock/wiki Mock] ビルドを開始します。Mockが正しく構成されている前提です。 [[Using_Mock_to_test_package_builds|パッケージのビルドテストのためにMockを使う]] を見ると、役に立つかもしれません。|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
* Generate a .src.rpm from the current state:
* 現在の状態から .src.rpmファイルを作る:
  fedpkg srpm
  fedpkg srpm
{{hidden|header=Details|content=You can request a [[Koji]] 'scratch build' (a test build, which will not go to any repository) of the generated .src.rpm with the {{command|koji build --scratch}} command (see {{command|man koji}}).|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=詳細|content=生成された .src.rpm から [[Koji]] の'お試しビルド' (レポジトリに行かずにテストビルドを実行) します。{{command|koji build --scratch}} コマンドで実行します。 ({{command|man koji}}をみてください).|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
* Do a scratch build using koji: see [https://fedoraproject.org/wiki/Using_the_Koji_build_system#Scratch_Builds Koji scratch builds]
* Kojiでお試しビルドする: [https://fedoraproject.org/wiki/Using_the_Koji_build_system#Scratch_Builds Koji scratch builds] をみてください。
* Check changes you have made:
* あなたが変更した箇所を確認する:
  fedpkg diff
  fedpkg diff
{{hidden|header=Details|content=This is handy for making sure you didn't touch something by mistake, or forget to bump the release, or forget to include a changelog...|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=詳細|content=これは間違って何かをさわってないことや、リリースし忘れたり、変更履歴に入れ忘れたりしてないことを確認するのに便利です。|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
* Run some checks (rpmlint) on your package:
* パッケージに対していくつかのチェックを走らせる:
  fedpkg lint
  fedpkg lint
{{hidden|header=Details|content=If you want to whitelist some rpmlint errors and prevent them from appearing, you can create an rpmlint config file named <code>&lt;source_package_name&gt;.rpmlintrc</code> and it will get applied.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=詳細|content=いくつかのrpmlintのエラーをホワイトリストに登録し、エラーメッセージを表示させたくないなら、<code>&lt;source_package_name&gt;.rpmlintrc</code> という名前で、rpmlintの設定ファイルを作れます。そして、それは適用されます。|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
* Stage any small patches or new source files for commit:
* 小さなパッチもしくはコミットする新しいソースファイルをステージにアップする:
  git add (somefile)
  git add (somefile)
{{hidden|header=Details|content=git does not consider all files in the working directory to be a part of the git repository by default (handy, for keeping other files around that are relevant, like the source tree). This tells git to start considering these files as part of the repository ''locally''. When you 'commit' and 'push' later, this change is communicated to the server.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=詳細|content=git は、デフォルトでは、作業ディレクトリにある全部のファイルを、gitレポジトリの一部であるとみなしません。(これは、ソースツリーのような、関係ある他のファイルを保存するのに便利です)。このコマンドを実行すると、gitは、ローカル上で、これらのファイルをgitレポジトリの一部としてみなし始めます。コミットして、プッシュすると、この変更が、サーバに伝達されます。|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
* Upload new source files to the lookaside cache:
* 新しいソースファイルをルックアサイドキャッシュ（訳注：アップストリームのためのストレージシステム）にアップロードする:
  fedpkg new-sources
  fedpkg new-sources
{{admon/warning|Alert|This will replace the current list of source files, not add to it. See ''Details'' for more details on the lookaside cache system.}}
{{admon/warning|Alert|これは、現在のソースファイルの一覧を置き換えますが、一覧に追加はしません。詳細は ルックアサイドキャッシュシステムについてを参照。}}
  fedpkg upload
  fedpkg upload
{{hidden|header=Details|content='Pristine' upstream sources (like release tarballs) and other larger source files are stored in the [[Package_Source_Control#Lookaside_Cache|lookaside cache]] system, not committed directly to git. This provides more efficient storage and transfer of the files. The {{filename|sources}} and {{filename|.gitignore}} files in the repository keep it in sync with the lookaside cache. Any time you use {{command|fedpkg new-sources}} or {{command|fedpkg upload}}, you must remember to 'commit' changes to those files.
{{hidden|header=詳細|content=オリジナルの開発元のソースコード(リリース用に作成されたtarファイルのような) とその他のより大きなソースファイルは、 [[Package_Source_Control#Lookaside_Cache|ルックアサイドキャッシュ]] システムに保存されていて、gitに直接コミットはされていません。これは、より効率的な保存とファイル転送を提供します。レポジトリにある {{filename|ソース}} と {{filename|.gitignore}} ファイルは ルックアサイドキャッシュと同期しつづけます。{{command|fedpkg new-sources}} を使うか {{command|fedpkg upload}} が使われるときはいつでも、それらのファイルへの変更を忘れずにコミットしてください。


{{command|new-sources}} 'starts from scratch', replacing all files currently in the lookaside cache - you'll typically use this command for many packages with just a single source tarball, each time you update to a new upstream version. {{command|upload}} just adds the given file to those already in the cache. Do remember not to leave stale sources lying around.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{command|new-sources}} は、ゼロから始めます。つまり、そのときに ルックアサイドキャッシュ      にある全部のファイルを置き換えます。通常このコマンドは、一個のtarファイルにまとめられているソースファイルを持つ多くのパッケージに対して、このコマンドが使われます。新しい開発元のバージョンに対して、アップデートするごとに行われます。{{command|upload}} は、与えられたファイルをすでにキャッシュにあるファイルに追加するだけです。周辺に置かれている古くなったソースファイルをそのままにしないようにしてください。|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
* Switch to a different release branch:
* 別のリリースブランチに移動する:
  fedpkg switch-branch <f{{FedoraVersionNumber}}, el6, master>
  fedpkg switch-branch <f{{FedoraVersionNumber}}, el6, master>
{{hidden|header=Details|content=Each Fedora release has its own branch in each package repository so different builds can be sent to each release. See below for more details on working with branches.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=詳細|content=Fedoraリリースは、パッケージリポジトリにリリースごとのブランチを持っているので、異なるビルドを各リリースに送れます。ブランチを使った作業の詳細は下記参照してください。|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
* Generate git changelog from package changelog:
* パッケージの変更履歴からgitのchangelogを生成する:
  fedpkg clog
  fedpkg clog
{{hidden|header=Details|content=This command extracts your package changelog entry to the file {{filename|clog}}, so you can use it as the git changelog if you like. Some maintainers draw a distinction between the two, some do not.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=詳細|content=このコマンドはあなたのパッケージのchangelogエントリを{{filename|clog}}というファイルに抽出します。もしあなたが望むならば、それをgit changelogとして使うこともできます。メンテナの中には両者を区別する人もいれば、そうしない人もいます。|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
* Commit changes:
* 変更をコミットする:
  fedpkg commit (-F clog) (-p) (-c)
  fedpkg commit (-F clog) (-p) (-c)
{{admon/note|Difference from git|This behaves by default like {{command|git commit -a}} - it stages modified files and commits all at once, though it ''does not'' add files which git is not yet tracking.}}
{{admon/note|gitとの違い|デフォルトの挙動は、 {{command|git commit -a}} と似ています。- 変更されたファイルをステージに上げて、一度に全てをコミットします。しかし、まだgitが追跡していないファイルを追加はしません。}}
{{hidden|header=Details|content=This creates a sort of bundle, a 'commit', of your changes to the repository, with a unique identity and a changelog. Other maintainers - and you yourself, later - can view the history of changes to the repository with the 'commit' as the finest level of detail. It is good practice to use many relatively small commits, each for a single purpose - don't combine a version bump with a bunch of whitespace fixes and some scriptlet changes all in one commit, create separate commits for each.
{{hidden|header=詳細|content=これは、レポジトリへのあなたの変更をまとめ、一つの'commit'とします。これには、独自の識別子と変更履歴を伴います。あなた以外のパッケージ保守管理者とあなた自身もまた、’commit' を通じて、最も細かいレベルの詳細情報として、レポジトリへの変更履歴を見られます。一つの目的ごとに、比較的小さくコミットすることをおすすめします。複数の空白の修正といくつかのスクリプトレットの修正を一つのコミットにまとめて、一つのバージョンとせずに、それぞれを別のコミットとして作ることをおすすめします。


The {{command|-F clog}} parameter will use the {{filename|clog}} file from the previous step as the changelog. {{command|-p}} will push (see below) at the same time as committing. {{command|-c}} combines the {{command|clog}} and {{command|commit -F clog}} steps into one, if you like that.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{command|-F clog}} パラメータは、{{filename|clog}} ファイルを使います。これは、前のステップで変更履歴として使われているものです。{{command|-p}} は、コミットと同時に、プッシュします（詳細は下記参照）。{{command|-c}} は、 {{command|clog}} と {{command|commit -F clog}} のステップを一つにつなぎ合わせたものです。お好みで使えます。|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
* Push changes:
* 変更をプッシュする:
  fedpkg push
  fedpkg push
{{hidden|header=Details|content=This sends all the new 'commits' in your local working copy to the upstream server. If you are still learning the system, now is a good time to {{command|fedpkg co}} another copy of the repository somewhere else, compare what you get to your working copy, and run a test build on it.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=詳細|content=これは、ローカルの作業用コピーにある新しい’コミット'全てを上流のサーバに送信します。もしあなたがまだシステムについて勉強中であれば、今は{{command|fedpkg co}} を実行して、どこか他のレポジトリのもう一つのコピーに対して、あなたの作業用コピーに対してあなたが取得したものを比較してから、そこに対してテストビルドを走らせのが良いでしょう。|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
* Do an 'official' build of the latest pushed changes:
* プッシュした変更点を公式にビルドする:
  fedpkg build
  fedpkg build
* Submit 'official' builds from a stream branch
* ストリームブランチから公式ビルドを投稿する:
  fedpkg build
  fedpkg build
{{hidden|header=Details|content=There is no difference in the command line to submit multiple builds from a stream branch. But you need to create a config file {{command|package.cfg}} in the repository and set option for the builds. For example config file is created in a stream branch {{command|8}} of package {{command|foo}}, which has content,
{{hidden|header=詳細|content=複数のビルドを投稿するためのコマンドラインでは、ストリームブランチとの違いはありません。しかし、レポジトリに{{command|package.cfg}} という設定ファイルを作り、ビルドのための設定が必要となります。例えば、{{command|foo}} パッケージの {{command|8}} というストリームブランチには、次のような設定ファイルを作ります。
  [koji]
  [koji]
  targets = f28 epel7
  targets = f28 epel7
This example shows when you execute {{command|build}} command, fedpkg is able to submit builds for releases, {{command|f28}} and {{command|epel7}}.
この例では、あなたが {{command|build}} コマンドを実行した時に、fedpkg  は {{command|f28}} と {{command|epel7}} のブランチで、リリースのためにビルドを投稿することができます。


In practice, you are able to specify two shortcut names {{command|fedora}} and {{command|epel}} for convenience. fedpkg retrieves current active Fedora and EPEL releases automatically. Hence, if you don't want to select a subset of releases, or just simply going to build packages for active releases without knowing the concrete release name, shortcut names would be helpful. You can specify to build for {{command|rawhide}}, use name {{command|master}}.
実際には、便宜上 {{command|fedora}} と {{command|epel}} という短い名前を指定できます。fedpkgは、現在アクティブなFedoraとEPELのリリースを自動的に取得します。したがって、もしサブセットのリリースを選びたくない場合、もしくは、具体的なリリース名を知らずに、アクティブなリリースに対してパッケージをビルドしたいのなら、短い名前は便利です。{{command|rawhide}} 向けのビルドを指定する時は、 {{command|master}} という名前を使ってください。
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
* In the event you are working with a Docker [[Changes/Layered_Docker_Image_Build_Service|Container Layered Image Build]]
* Docker [[Changes/Layered_Docker_Image_Build_Service|コンテナ層のイメージビルド]]を使用している場合:
fedpkg container-build
{{admon/important|プロダクションに入れる|あなたが実際の利用者を本当の混乱を引き起こす可能性があります。ですから、注意して使いましょう。もし例にならって、Rawhideで動かす時は、あなたのビルドは、Rawhide向けに動くでしょう。Rawhideのユーザは、コマンドを打ってから、数時間後にビルドが有効になります。}}
{{admon/important|Going into production|This is the first point at which you might possibly cause real mess for a real user, so use it with caution. If you are following the example and operating on Rawhide, your build would go live for Rawhide users some few hours after you ran this command.}}
{{admon/note|プッシュした状態を使う|上で挙げたのほとんどのコマンドと違い、あなたがgitへプッシュした状態で動きます。ローカルの状態ではありません。もし問題があれば、すべてのパッチが正しくプッシュされて、コミットされていること、そして、ソースコードを正しく処理できていることを確認してください。}}
{{admon/note|Uses pushed state|Unlike most of the above commands, this operates on the ''state you have pushed to git'', not the local state. If you have issues make sure you have pushed and committed all patches and handled the sources correctly.}}
{{hidden|header=詳細|content=これは、あなたのパッケージを[[Koji]]で本当にビルド（お試しではなく）します。あなたがビルドしたリリースに依存するので、リリースは、直接[[Repositories#stable|''stable'' 状態]] になるかもしれませんし、アップデートプロセスを通じて、起動しなければならないかもしれません。詳細は、パッケージのアップデートガイドを見てください。コマンドは、あなたがKojiでのビルドの進行状況を確認できるURLを出力します。|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=Details|content=This triggers a 'real' (not scratch) build of your package in [[Koji]]. Depending on the release you are building for, it may go directly to the [[Repositories#stable|''stable'' state]] or it may have to run through the [[Updates Policy|update process]]. See the [[Package_update_HOWTO|package update guide]] for more details on this. The command will output a URL where you can monitor the build's progress in Koji.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
* 最終ビルドのパッケージ更新を投稿する:
* Submit a package update for the latest build:
  fedpkg update
  fedpkg update
{{hidden|header=Details|content=Again, see the [[Package_update_HOWTO|package update guide]] for more details on this process. This step is not actually applicable to Rawhide, but illustrated here for completeness.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=詳細|content=繰り返しますが、ビルドのパッケージを更新するには、 [[Package_update_HOWTO|パッケージ更新ガイド]] を見てください。このステップは、実際には、Rawhideには適用できませんが、完全を期すためにここに示しています。|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}


== Typical ''fedpkg'' session ==
== 典型的な ''fedpkg'' セッション ==


A typical session may look like this:
一つの典型的なセッションは次のような感じかもしれません:
<pre>
<pre>
fedpkg clone foo
fedpkg clone foo
Line 113: Line 112:
fedpkg sources
fedpkg sources
fedpkg new-sources foo-0.0.2.tar.bz2
fedpkg new-sources foo-0.0.2.tar.bz2
gedit foo.spec      # change the required things in the specfile.
gedit foo.spec      # specファイルの必要な部分を変更
                     # rpmdev-bumpspec is useful for simple version updates
                     # rpmdev-bumpspec は 簡単なバージョン更新には便利
fedpkg mockbuild    # check that the changes you made are correct
fedpkg mockbuild    # あなたが行なった変更が正しいことを確認
fedpkg diff
fedpkg diff
fedpkg lint
fedpkg lint
fedpkg commit -p -c  # commit and push in one go
fedpkg commit -p -c  # コミットしてプッシュを一回で実行
</pre>
</pre>


== Working with branches ==
== ブランチで作業する ==


Each Fedora release is represented by a branch in the git repository. You can switch between them like this:
各Fedoraのリリースは、gitレポジトリの中のブランチで表現されています。ブランチは次のように切り替えられます:
  fedpkg switch-branch f{{FedoraVersionNumber}}
  fedpkg switch-branch f{{FedoraVersionNumber}}
  fedpkg switch-branch f{{FedoraVersionNumber|previous}}
  fedpkg switch-branch f{{FedoraVersionNumber|previous}}
  fedpkg switch-branch master
  fedpkg switch-branch master
The ''master'' branch is for [[Releases/Rawhide|Rawhide]]. You can maintain each branch entirely separately, if you like, laboriously copying changes between them (so long as you always stay within the [[Updates Policy]] requirements). However, git provides us with several handy tools for working with branches. Here's an example:
 
"master"ブランチは、[[Releases/Rawhide|Rawhide]]用です。各ブランチは完全に分離して維持管理できます。もし希望するなら、じっくりブランチ間の変更をコピーしてください（[[Updates Policy]] の要求の範囲内である限りは）。しかし、gitは、ブランチを取り扱うための便利ないくつかのツールを提供しています。例えば：
{{#tag:pre|
{{#tag:pre|
fedpkg clone bzrtools
fedpkg clone bzrtools
# Make some changes in the master branch
# masterブランチで変更する
fedpkg new-sources bzrtools-2.2.tar.gz
fedpkg new-sources bzrtools-2.2.tar.gz
gedit bzrtools.spec
gedit bzrtools.spec
Line 136: Line 136:
fedpkg switch-branch f{{FedoraVersionNumber}}
fedpkg switch-branch f{{FedoraVersionNumber}}
git merge master
git merge master
# for push into repo
# レポジトリにpush
fedpkg push
fedpkg push
}}
}}
This will 'merge' the changes from the ''master'' (Rawhide) branch to the f{{FedoraVersionNumber}} branch. git aficionados may note this is a somewhat unusual workflow, but it is appropriate to the context of package management. Remember, after pushing to and building for a stable release or a [[Releases/Branched|Branched]] release after [[Updates Policy#Bodhi enabling|Bodhi has been enabled]], you will have to [[Package_update_HOWTO|submit an update]] before any other Fedora users will see your build.
これは"master"(Rawhide)ブランチからf{{FedoraVersionNumber}}ブランチへの変更点をマージします。gitマニアたちは、これはやや変わった業務フローだと気づくかもしれません。しかし、パッケージの保守管理という文脈においては、適切です。おぼえておいてほしいのは、[[Updates Policy#Bodhi enabling|Bodhiが有効にされた]]、安定版もしくは[[Releases/Branched|Branched]] リリースをプッシュしたりビルドした後では、他のFedoraユーザがあなたのビルドを見るよりも前に、アップデートを投稿する必要があります。


Note that merges will only be sure to work cleanly so long as the branches have not previously diverged. That is, if you do this:
ブランチが以前に分岐しない場合に限り、マージは正常に機能することに注意してください。つまり、こうすれば、マージは衝突("merge conflict")するかもしれません。
{{#tag:pre|
{{#tag:pre|
fedpkg clone bzrtools
fedpkg clone bzrtools
# Make some changes in the master branch
# masterブランチで変更する
fedpkg commit
fedpkg commit
fedpkg switch-branch f{{FedoraVersionNumber}}
fedpkg switch-branch f{{FedoraVersionNumber}}
# Make some changes in the f{{FedoraVersionNumber}} branch
# f{{FedoraVersionNumber}} ブランチで変更する
fedpkg commit
fedpkg commit
fedpkg switch-branch master
fedpkg switch-branch master
# Make some more changes in the master branch
# masterブランチで変更する
fedpkg commit
fedpkg commit
fedpkg switch-branch f{{FedoraVersionNumber}}
fedpkg switch-branch f{{FedoraVersionNumber}}
git merge master
git merge master
}}
}}
you may encounter a ''merge conflict''.


Remember that git is a ''collaborative'' system, and used as such in Fedora package management. It is often the case that you must consider changes made by others in working on a package, and consider how your changes will affect others.
gitは、"協働的"なシステムであり、Fedoraパッケージ管理においては、そのように使われていることを忘れないでください。多くの場合、あなたは、あるパッケージに他の人が加えた変更を考慮しなければならず、あなたの変更が他の人にも影響があるということを考慮しなければなりません。


=== Resolving merge conflicts ===
=== 衝突したマージを解決する ===


This is a large topic and somewhat beyond the scope of this guide, but we can give basic pointers. There are other good references in the [http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging git book] and at [https://help.github.com/articles/resolving-a-merge-conflict-from-the-command-line github].
これは大きな話題です。そして、このガイドの範囲を幾分か超えます。しかし、基本的な視点を提示します。他に良い参考文献が[http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging git book] や[https://help.github.com/articles/resolving-a-merge-conflict-from-the-command-line github]にあります。


When you git merge and a conflict occurs you can edit the files that have conflicts. Remove the conflict markers in the files and merge the changes manually. Use {{command|git diff}} or {{command|fedpkg diff}} to inspect the changes against the pre-conflict state and verify you are happy with the resolution. Then you can commit the files with {{command|fedpkg commit}} or {{command|git commit -a}}. git will know if you have resolved the conflict by checking that all the conflict markers have been removed.
あなたが git mergeするとき、衝突が発生したとき、衝突しているファイルを編集できます。ファイルの中の衝突マークを取り除き、手で変更箇所をマージしましょう。{{command|git diff}} もしくは {{command|fedpkg diff}}を使って、競合前の状態の変更箇所を精査し、その解決であなたが幸せであることを確認しましょう。


=== Using <code>git mergetool</code> to resolve conflicts ===
=== <code>git mergetool</code>を使って競合を解決する ===


Git provides a graphical diff program to help resolve conflicts.  This can be handy for visualizing what changes have occurred and dealing with them as a set.
Gitは、グラフィカルなプログラムを提供しており、それは、競合を解決する手助けをしてくれます。これは、どのような変更が起きたかを可視化し、一つのセットとして変更を扱う点が便利です。
{{#tag:pre|
{{#tag:pre|
git config --global merge.tool meld
git config --global merge.tool meld
fedpkg switch-branch f{{FedoraVersionNumber}}
fedpkg switch-branch f{{FedoraVersionNumber}}
git merge master
git merge master
# Conflicts occurred
# 競合が発生した
git mergetool            # Opens up a meld showing a three way diff of
git mergetool            # マージ、作業ツリー、最後のコミットの三つを
                         # the merge, working tree, and the last commit
                         # 一つにして表示する。
# Resolved all the conflicts in the GUI
# GUIの中ですべての競合を解決する。
git add CONFLICTEDFILES
git add CONFLICTEDFILES
git commit
git commit
}}
}}


== Requesting special dist tags ==
== 特別なdistタグをリクエストする ==


When a change to a package affects a large number of dependencies (e.g. all perl, python, ruby or ghc packages), requiring them to be rebuilt, it may be better to initially do the builds in a special repository, so that there is less disruption in Rawhide.
あるパッケージに対する変更が、大量の依存関係に影響する場合（例えば、perl, pyton, rubyもしくはghcパッケージのすべて）、それらをリビルドする必要があるので、特別なレポジトリの中で、最初にビルドしてしまうのが良いかもしれません。そうすれば、Rawhideであまり破壊的なことは起きません。


If you think you have an update that falls under this case you can request a special dist tag by filing a [https://fedorahosted.org/rel-eng/newticket release engineering ticket]. Someone from [[ReleaseEngineering|release engineering]] will likely want to discuss your needs to make sure this is really an appropriate case (it's OK ask if you aren't sure) and that you get what you need.
あなたがこのようなケースに陥るアップデートを抱えていると考えるならば、あなたは、[https://fedorahosted.org/rel-eng/newticket リリースエンジニアリングチケット]を発行し、特別なdistタグを要求できます。おそらく[[ReleaseEngineering|リリースエンジニアリング]]出身の誰かが、本当に適切なケースであるか、そして、あなたが必要とするものをあなたが獲得することを確認するために、あなたの必要性について議論したがるでしょう（あなたに確信がなければ、質問するのはOKです）


== Tips and tricks ==
== 小技とトリック ==


{{anchor|anon}}
{{anchor|anon}}
=== Using fedpkg anonymously ===
=== 匿名でfedpkgを使う ===


You can use fedpkg like this:
次のようにfedpkgを使えます:
  fedpkg clone --anonymous <somepackage>
  fedpkg clone --anonymous <somepackage>
to check out a package without requiring identification. Obviously, you will not be able to push any changes to this repository, but it is useful for non-packagers who simply want to examine a package, make changes for their own use, and perhaps submit changes to a Fedora developer.
ID確認なしでパッケージをチェックアウトします。もちろんレポジトリに対して変更をプッシュはできませんが、パッケージャーでない人がパッケージを単に精査したり、自分の用途に合わせて変更を加えたい、そしておそらくFedora開発者に変更を提出したいときに便利です。


=== Local branch names ===
=== ローカルなブランチ名 ===


If you use git commands to branch and checkout directly, you can define whatever local branch names you want. If you use {{command|fedpkg switch-branch}}, it will default to creating the names used in the examples above.
もしgitコマンドを使って、ブランチし、直接チェックアウトするなら、あなたが希望するどのようなローカルブランチ名でも定義できます。もし、{{command|fedpkg switch-branch}}を使うならば、上の例で使われている名前がデフォルトで作成されます。


=== Current branch and state in shell prompt ===
=== シェルプロンプトに現在のブランチと状態を表示する ===


It is often helpful to know what branch you are working on at a glance.  You can add this information to your bash prompt with the information [[Git_Quickref#Display_current_branch_in_bash|here]].
よく助かるのが、一目であなたが作業しているブランチがわかることです。あなたは、この情報をバッシュのプロンプトに追加できます。[[Git_Quickref#Display_current_branch_in_bash|ここ]]に書かれている情報をみてください。


=== Importing a .src.rpm to update ===
=== 更新のために.src.rpmをインポートする ===


The {{command|fedpkg import}} command usually used to initially populate a git package repository from a .src.rpm that has been through the [[Package Review Process]] can also be used to update a normal working copy, if you have an old-school packaging process to which you are particularly attached. Just run {{command|fedpkg import file.src.rpm}} and it will upload new tarballs into lookaside cache, update a working copy of the last version found in git, and commit all changes. {{command|fedpkg import --help}} documents some other parameters it can accept.
{{command|fedpkg import}} コマンドは、最初に.src.rpmファイルからgitパッケージレポジトリを作成するために使われます。特にあなたが愛着をもっている古いパッケージングプロセス[[Package Review Process|パッケージレビュー手順]]では、作業コピーをアップデートするためにも使われます。
ただ単に {{command|fedpkg import file.src.rpm}} を実行して、新しいtarで固めらたファイルをルックあサイドキャッシュにアップし、gitに見つかった最新バージョンの作業コピーを更新し、すべての変更をコミットします。{{command|fedpkg import --help}} すると、他にも受け取るパラメータのドキュメントが表示されます。


{{admon/warning|Caution!|This approach makes it harder to verify that your changes are safe and do not overwrite changes made to the package by others. For this reason, its use is not recommended.}}
{{admon/warning|注意!|このやり方は、あなたの変更が安全であるか確認するのが難しくなります。他の人が行なった変更を上書きしないでください。この理由のために、このやり方は非推奨となっています。}}


=== Making changes on an older branch without breaking the upgrade path ===
=== アップグレードパスを壊さずに古いブランチでの変更する ===


Here is the scenario: you've built your package successfully on the ''{{FedoraVersionNumber}}'' branch, but there is a problem keeping your package from building on ''{{FedoraVersionNumber|last}}''.
想定されるシナリオ: あなたは、''{{FedoraVersionNumber}}''ブランチで、パッケージビルドに成功しましたが、''{{FedoraVersionNumber|last}}''では、ビルドできない問題が起きています。


Solution: make your changes in the branch and then add a digit to the very right of the release tag. There is no need to change the release in the other branches. This allows upgrades to work smoothly if the user upgrades to a newer release of Fedora.
解決策: そのブランチで変更し、リリースタグの一番右に、数字を追加します。他のブランチでは、リリースを変更するはありません。これにより、ユーザがFedoraの新しいリリースにアップグレードした場合でも、アップグレードはスムーズに機能します。


<pre>
<pre>
Line 225: Line 225:
</pre>
</pre>


Then tag and build as usual. This approach was initially discussed [https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00083.html in this mailing list thread].
タグとビルドはいつも通りです。このアプローチは、最初に [https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00083.html in this mailing list thread] で議論されました。


=== Removing a package build pending for [[Releases/Rawhide|Rawhide]] or [[Releases/Branched|Branched]] ===
=== [[Releases/Rawhide|Rawhide]] または [[Releases/Branched|Branched]]でペンディングになっているパッケージビルドを削除する ===


From time to time you may want to remove a package build you submitted to Rawhide or to Branched prior to the Alpha freeze (both cases where the build would usually go out to the main [[Repositories|repository]] without further gating). This could happen in a situation where a bug or issue is found in your package that will be resolved upstream in the next release, or you realize you made a significant mistake in the build that cannot easily be corrected.
時々あなたがRawhideやアルファ版以前のブランチに投稿したパッケージを削除したいと思うかもしれません。(both cases where the build would usually go out to the main [[Repositories|repository]] without further gating). これは、パッケージ開発元が次のリリースで修正される予定だけど、あなたのパッケージには、バグや問題がある状況で起こり得ます。もしくは、あなたがビルドで重大な間違いを犯したために簡単に修正できないと気づく場合もあります。


{{admon/caution|Use this carefully!|This should only be done on the same day of the build, before it is included in a compose. If your build was already included in a compose you must not untag it! Check the [https://apps.fedoraproject.org/releng-dash/ Release Engineering Dashboard] to get the starting time of the last compose.}}
{{admon/caution|注意して使うこと！|これは、compose(Fedoraのスナップショット)にパッケージが含まれる前の状態で、ビルドした日と同じ日でだけ実施されるべきです。 もし、パッケージがcomposeに含まれてしまっていたならば、タグを外してはいけません。[https://apps.fedoraproject.org/releng-dash/ Release Engineering Dashboard] を確認して、最後のcomposeが始まった時刻を確認してください。}}


You can remove the package by using [[Koji]]: {{command|koji untag-pkg f{{FedoraVersionNumber|next}} foo-1.1.3-1.fc{{FedoraVersionNumber|next}}}}
[[Koji]]: {{command|koji untag-pkg f{{FedoraVersionNumber|next}} foo-1.1.3-1.fc{{FedoraVersionNumber|next}}}}をつかって、パッケージを削除できます。


where {{filename|foo-1.1.3-1.fc{{FedoraVersionNumber|next}}}} is replaced with the name of your package build.  See {{command|koji help}} or [[Using_the_Koji_build_system|using Koji]] for more information.
{{filename|foo-1.1.3-1.fc{{FedoraVersionNumber|next}}}} となっている部分は、あなたのパッケージビルドの名前に置き換えてください。詳細は、{{command|koji help}} もしくは [[Using_the_Koji_build_system|Kojiを使う]] を見てください。


=== ssh fingerprint ===
=== SSHの指紋 ===


The recommended option is to include "<code>VerifyHostKeyDNS yes</code>" in your ~/.ssh/config file. This will result in using DNS to check that the key is correct.
~/.ssh/config に、"<code>VerifyHostKeyDNS yes</code>" を含めることをお勧めします。これは、鍵が正しいことをDNSを使って結論づけます。


But you can also manually check against the  list of keys at https://admin.fedoraproject.org . The strings there are what ends up in your ~/.ssh/known_hosts file. So you can accept the fingerprint when prompted and then check that the correct string for src.fedoraproject.org ended up in your ~/.ssh/known_hosts file.
https://admin.fedoraproject.org にある鍵の一覧と照合することもできます。そこにある文字列は〜/ .ssh / known_hostsファイルに入っています。ですから、あなたは、プロンプトが出たときに、〜/ .ssh / known_hostsファイルに入っている src.fedoraproject.org の正しい文字列であることを確認して、文字列を受け入れることができます。


=== Problems connecting to the repository ===
=== レポジトリに接続中に発生する問題 ===


The ''fedpkg'' tool clones repositories using the ssh:// protocol, so this should not be a problem normally (as long as you have your ssh key).  If you cloned using the ''git'' utility itself, check the {{filename|.git/config}} file to ensure the remote repository is being accessed via an ssh:// protocol, and not git://.
''fedpkg'' ツールは、ssh:// プロトコルを使って、レポジトリをクローンします。ですので、普通これは、問題になるべきではありません（あなたが自分のSSH鍵をつかっている限りは）。もし、"git" ユーティリティそれ自体を使ってクローンしているならば、{{filename|.git/config}} ファイルを確認して、リモートレポジトリが ssh:// 経由でアクセスされていることを確認してください。git:// 経由ではありません。


=== It builds here, why doesn't it build there? ===
=== ここでビルドして、なんでそこでビルドしない？ ===


Is your package building locally - even with Mock, even as a scratch build! - but not when you run {{command|fedpkg build}}? Before you get too frustrated, remember {{command|fedpkg build}} runs on the package as it exists in the upstream repository, not your local working copy. Make sure you have committed and pushed all changes and source files, and handled the lookaside cache correctly. Other issues that have been reported, are issues because of [https://bugzilla.redhat.com/show_bug.cgi?id=1179139 build/make check parallelization] and failures because of test suites that depend on operations finish on precise timing (and a busy build system may not be able to perform operations on time).
あなたのパッケージはローカルでビルドされていますか？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の導入は比較的簡単だと思われます）

あなたは、以下のようなことをずっと探していた、もしくは、興味があるかもしれません:

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
Alert
これは、現在のソースファイルの一覧を置き換えますが、一覧に追加はしません。詳細は ルックアサイドキャッシュシステムについてを参照。
fedpkg upload
詳細

オリジナルの開発元のソースコード(リリース用に作成されたtarファイルのような) とその他のより大きなソースファイルは、 ルックアサイドキャッシュ システムに保存されていて、gitに直接コミットはされていません。これは、より効率的な保存とファイル転送を提供します。レポジトリにある ソース と .gitignore ファイルは ルックアサイドキャッシュと同期しつづけます。fedpkg new-sources を使うか fedpkg upload が使われるときはいつでも、それらのファイルへの変更を忘れずにコミットしてください。

new-sources は、ゼロから始めます。つまり、そのときに ルックアサイドキャッシュ にある全部のファイルを置き換えます。通常このコマンドは、一個のtarファイルにまとめられているソースファイルを持つ多くのパッケージに対して、このコマンドが使われます。新しい開発元のバージョンに対して、アップデートするごとに行われます。upload は、与えられたファイルをすでにキャッシュにあるファイルに追加するだけです。周辺に置かれている古くなったソースファイルをそのままにしないようにしてください。

  • 別のリリースブランチに移動する:
fedpkg switch-branch <f41, el6, master>
詳細

Fedoraリリースは、パッケージリポジトリにリリースごとのブランチを持っているので、異なるビルドを各リリースに送れます。ブランチを使った作業の詳細は下記参照してください。

  • パッケージの変更履歴からgitのchangelogを生成する:
fedpkg clog
詳細

このコマンドはあなたのパッケージのchangelogエントリをclogというファイルに抽出します。もしあなたが望むならば、それをgit changelogとして使うこともできます。メンテナの中には両者を区別する人もいれば、そうしない人もいます。

  • 変更をコミットする:
fedpkg commit (-F clog) (-p) (-c)
gitとの違い
デフォルトの挙動は、 git commit -a と似ています。- 変更されたファイルをステージに上げて、一度に全てをコミットします。しかし、まだgitが追跡していないファイルを追加はしません。
詳細

これは、レポジトリへのあなたの変更をまとめ、一つの'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 という名前を使ってください。

プロダクションに入れる
あなたが実際の利用者を本当の混乱を引き起こす可能性があります。ですから、注意して使いましょう。もし例にならって、Rawhideで動かす時は、あなたのビルドは、Rawhide向けに動くでしょう。Rawhideのユーザは、コマンドを打ってから、数時間後にビルドが有効になります。
プッシュした状態を使う
上で挙げたのほとんどのコマンドと違い、あなたがgitへプッシュした状態で動きます。ローカルの状態ではありません。もし問題があれば、すべてのパッチが正しくプッシュされて、コミットされていること、そして、ソースコードを正しく処理できていることを確認してください。
詳細

これは、あなたのパッケージをKojiで本当にビルド（お試しではなく）します。あなたがビルドしたリリースに依存するので、リリースは、直接stable 状態 になるかもしれませんし、アップデートプロセスを通じて、起動しなければならないかもしれません。詳細は、パッケージのアップデートガイドを見てください。コマンドは、あなたがKojiでのビルドの進行状況を確認できるURLを出力します。

  • 最終ビルドのパッケージ更新を投稿する:
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 f41
fedpkg switch-branch f40
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 f41
git merge master
# レポジトリにpush
fedpkg push

これは"master"(Rawhide)ブランチからf41ブランチへの変更点をマージします。gitマニアたちは、これはやや変わった業務フローだと気づくかもしれません。しかし、パッケージの保守管理という文脈においては、適切です。おぼえておいてほしいのは、Bodhiが有効にされた、安定版もしくはBranched リリースをプッシュしたりビルドした後では、他のFedoraユーザがあなたのビルドを見るよりも前に、アップデートを投稿する必要があります。

ブランチが以前に分岐しない場合に限り、マージは正常に機能することに注意してください。つまり、こうすれば、マージは衝突("merge conflict")するかもしれません。 

fedpkg clone bzrtools
# masterブランチで変更する
fedpkg commit
fedpkg switch-branch f41
# f41 ブランチで変更する
fedpkg commit
fedpkg switch-branch master
# masterブランチで変更する
fedpkg commit
fedpkg switch-branch f41
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 f41
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 すると、他にも受け取るパラメータのドキュメントが表示されます。

注意!
このやり方は、あなたの変更が安全であるか確認するのが難しくなります。他の人が行なった変更を上書きしないでください。この理由のために、このやり方は非推奨となっています。

アップグレードパスを壊さずに古いブランチでの変更する

想定されるシナリオ: あなたは、41ブランチで、パッケージビルドに成功しましたが、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). これは、パッケージ開発元が次のリリースで修正される予定だけど、あなたのパッケージには、バグや問題がある状況で起こり得ます。もしくは、あなたがビルドで重大な間違いを犯したために簡単に修正できないと気づく場合もあります。

注意して使うこと！
これは、compose(Fedoraのスナップショット)にパッケージが含まれる前の状態で、ビルドした日と同じ日でだけ実施されるべきです。 もし、パッケージがcomposeに含まれてしまっていたならば、タグを外してはいけません。Release Engineering Dashboard を確認して、最後のcomposeが始まった時刻を確認してください。

Koji: koji untag-pkg f42 foo-1.1.3-1.fc42をつかって、パッケージを削除できます。

foo-1.1.3-1.fc42 となっている部分は、あなたのパッケージビルドの名前に置き換えてください。詳細は、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

Retrieved from "https://fedoraproject.org/w/index.php?title=Package_maintenance_guide/ja&oldid=538968"