Package update HOWTO/ja

In other languages: English (en) 中文（中国大陆） (zh-cn) 日本語 (ja) [edit]

この文書は、Fedoraにおいて、あなたが保守管理しているパッケージの更新を投稿する方法を説明しています。あなたがFedoraレポジトリのパッケージをすでに持っていることを過程しています。Fedoraパッケージソース制御システムの使い方に関する入門書ではありません。それについては、パッケージ保守管理入門 をみてください。

• Fedora Release Life Cycleにある様々な段階でのパッケージ更新のための要件に関する指針についての詳細は、Updates Policyをみてください。

Fedora Release Life Cycle

概要(Overview)

このページは、新しいパッケージと既存のパッケージの保守管理者向けに書かれています。テスト実施者と一般利用者は、updates-testingレポジトリとupdate feedback guidelinesに興味があるかもしれません。このページは、パッケージ更新時の投稿の流れを重点的に説明しています。

Fedoraには、パッケージ更新時の投稿において、二つの際立って異なる流れが存在しています:

• Bodhi enabling pointまでの間のRawhide
• α版締め切り変更と安定版リリース後のBranched リリース

Rawhide、Branchedと安定版のレポジトリのレイアウトがつがいますが、更新の流れは上のように分けられています。

Rawhideと初期のBranched(Rawhide and early Branche)

Bodhi enabling point以前での、Rawhide及びBranchedへのパッケージ更新の流れは単純です:

1. fedpkg buildでパッケージをビルドする (詳しくは Package maintenance guide を参照)

これだけです。あなたのパッケージは、Rawhide及びBranchedの、次の日次composeには表示されます。そして、そのツリーからビルドされたすべてのイメージにあなたのパッケージが使われることになります。

後期ブランチと安定版リリース(Later Branched and stable releases)

At the Bodhi enabling point, the Bodhi update feedback system is enabled by Release Engineering and builds submitted with fedpkg build are no longer automatically sent to any official repository. The update workflow for releases of this type is:

Fedora account name
fedpkg should be able to discover your Fedora account system user name from the ~/.fedora.cert file set up by fedora-packager-setup when you first configured your system for packaging. If this fails for any reason, you can specify it with --user (username). For the bodhi command line tool, you may need to specify your Fedora user name with -u (username) if it differs from your system user name.

1. Build the package with fedpkg build
2. Submit an update for the package with fedpkg update, the Bodhi web interface, or the Bodhi CLI tool. This causes the package to be sent to the updates-testing repository
3. Monitor the update's status and the feedback you receive via the web interface or the emails that are sent to you, and modify it with updated or additional builds if necessary
4. After the update meets the criteria in the Updates Policy and you are satisfied it should be released as a stable update, submit the update to stable with bodhi -R stable or the web interface

Updating inter-dependent packages
If a package you wish to update requires other package(s) to be rebuilt before it or they will work properly, you must submit the builds together as a multi-package update. See below for more details on this.

パッケージ更新における属性情報の更新(Update attributes)

At the time you submit the update, you will be asked for several attributes. The type of the update should be fairly self-explanatory: either it fixes bugs, adds new features, or is a new package.

If you are asked whether you want to send the update to updates-testing or stable, this is a no-op: all updates now go through updates-testing. It does not matter what you choose.

There are several schools of thought on filling out the update description. Some would suggest you consider the target audience: for a stable release, in particular, many Fedora users will see this text, and many of them may not be particularly familiar with your package. Consider not simply describing literally the changes in the update, but explaining as if to an outsider why your are updating the package, what benefits it will bring to them (if any), and anything they may want to note in order to have a smooth update experience.

If you associate one or more bug reports with your update, Bodhi will post comments into Bugzilla to alert those following the bug reports that an update is available. If you mark your update as fixing the bug(s), Bodhi will move the report(s) through the MODIFIED, ON_QA and CLOSED ERRATA states of the bug workflow as your update reaches various points in the process. Using this mechanism can be very useful both for you and for users of your package.

You may set a karma (feedback) level at which the update will automatically be submitted to stable. This is optional. If you choose to use it, please carefully consider an appropriate feedback level. For a relatively obscure package which is quite stable, 1 or 2 may be an appropriate value. For a popular, sensitive and complex package such as firefox or the kernel, the default of 3 may be insufficient and a choice of 5 or even 10 may be appropriate.

いつ誰があなたの更新を受理するか?(Who will receive your update, when?)

When a release is in Branched state, the updates-testing repository is enabled by default so most users will see the package, but only packages from the stable fedora repository are used in building milestone releases (Alpha, Beta and Final) and nightly images.

Where a package goes when it is marked as stable differs between Branched and stable releases. In Branched releases, stable packages are pushed to the base fedora repository. In stable releases, stable packages are pushed to the updates repository. However, from the point of view of the packager, this is an insignificant implementation detail. For more details, see Repositories.

When a release is in stable state, the updates-testing repository is disabled by default, but QA team members and others run with it enabled in order to provide testing and Bodhi feedback. The main user population will see your update only when it passes Bodhi, is marked as stable and reaches the updates repository.

相互依存パッケージの更新(Updating inter-dependent packages)

If an update you wish to submit would cause a dependency issue of any kind (a strict package dependency error, or simply another package failing to operate correctly) if updated alone, you must not submit the package as a single-package update. You must always collect all inter-dependent or related packages together into a single multi-package update, such that no user will face problems if they install all the packages in the update together.

For example: if you maintain a package libfoo which the package bar depends on, and you need to update libfoo, you should check that bar continues to function correctly with the updated version of libfoo. If it does not, you must ensure the appropriate changes are made to bar, and include the updated bar in your update along with the updated libfoo.

The fedpkg tool does not handle multi-package updates. You can add multiple packages to an update using the Bodhi web application, or the bodhi command line tool. You can pass as many package names as you like to the bodhi --new to create a new multi-package update, or use bodhi --edit to edit an existing update.

It is possible you will run into problems with permissions when trying to add builds of packages you do not have commit privileges for to an update, or trying to add a build for a package you do have privileges for to someone else's update. If you encounter a situation like this, you should contact the release engineering team or a proven packager for help.

You may need a buildroot override to complete a multi-package update successfully. For instance in the case described above, you may need to rebuild bar against the new libfoo package and submit both packages together as a multi-package update. However, in the normal course of events, you would not be able to build another package against your new libfoo build until it reached the stable state. To resolve this dilemma, you can request a buildroot override, which causes the libfoo build to be included in the buildroot for a short time in order to get the bar package build done.

You can request a buildroot override with bodhi: bodhi --buildroot-override=(name-version-release) --duration=2 --notes="Useful details." This would submit a buildroot override with a duration of two days. Buildroot overrides are usually granted within 15-30 minutes of submission. If you submit an override request with the bodhi tool, it will suggest a command that will let you monitor when the package appears in the buildroot, so you can fire your dependent build at the appropriate time.

You can also request buildroot overrides from the Bodhi web application.

The buildroot override instructions explain the buildroot override process in more detail.

自動テストからのフィードバックを処理する(Handling feedback from automated tests)

Fedora's automated testing systems, Taskotron and OpenQA, may run automated tests on your update. Several of the Taskotron/Tasks are documented. The openQA tests are functional tests of some critical Workstation and Server features.

In the Bodhi web interface, updates have a Automated Tests tab which displays the results of all automated tests. Tests shown with a red background failed. The tests are not all 100% accurate, but they are fairly often correct. If you see a failure, it is a very good idea to click on the result (which will take you to a detailed log) and investigate the issue. If you are unsure what the test indicates, you can contact the QA team for help.

結果を放棄する(Waive a result)

At present, a failure of the dist.rpmdeplint, dist.abicheck, or org.centos.prod.ci.pipeline.complete tests will prevent your update from being released. On the update's Details page in the Bodhi web interface, the Test Gating Status will be shown as N of N required tests failed. If you are sure such a failure is a false one, you can 'waive' the result using the waiverdb-cli tool, from the waiverdb-cli package (there is work pending to be able to waiver more easily, directly from the Bodhi UI).

You can submit a waiver for a failing result with waiverdb-cli specifying the subject and the testcase:

 waiverdb-cli -t YOUR_TESTCASE_HERE -s '{"item": "this-is-the-subject", "type": "also-this-is-part-of-the-subject"}' -p "fedora-26" -c "This is fine"

Example:

 waiverdb-cli -t dist.rpmdeplint -s '{"item": "python-requests-1.2.3-1.fc26", "type": "koji_build"}' -p "fedora-26" -c "This is fine"

You can also waive a failing result by result's id, which you can retrieve from resultsdb with curl. To do that, you'll need the testcase name and the nvr. For example:

 curl "https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0/results?testcases=dist.python-versions&item=python-alembic-0.9.7-1.fc27" | jq ".data[0].id"

This should print out the result_id of the failing result. You can then submit a waiver for this failing result with waiverdb-cli

 waiverdb-cli -p fedora-27 -r YOUR_ID_HERE -c "This is fine."

Also, if you enabled automatic stable push at a karma threshold, this will be disabled if any automated test fails. If you have examined the result and you are sure it is a false one and there is no problem with the package, you may re-enable the automatic push mechanism or submit the package to stable manually once it meets the other requirements of the Updates Policy.

存在しない結果を放棄する(Waive the absence of a result)

Submitting a waiver using subject/testcase allows to waive the absence of a result (eg. the test never ran for some reason, so there is no result item).

If which testcase you should be specified it is not clear/known, it is possible to run this python script, chainging it with the corrects parameter:

#!/usr/bin/env python
""" Ask a question of greenwave.  """
# Usage: either modify and set PRODUCT_VERSION and NVR_LIST and run, or pass version as first arg and then NVRs as further args
import pprint
import requests
import sys
PRODUCT_VERSION = 'fedora-27' if len(sys.argv) == 1 else sys.argv[1]
NVR_LIST = [] or sys.argv[2:]  # Insert your NVRs here, or pass them via command line args
for nvr in NVR_LIST:
    url = (
        'https://greenwave-web-greenwave.app.os.fedoraproject.org/'
        'api/v1.0/decision')
    payload = dict(
        #verbose=True,
        decision_context='bodhi_update_push_stable',
        product_version=PRODUCT_VERSION,
        subject=[{'item': nvr, 'type': 'koji_build'}],
    )
    response = requests.post(url, json=payload)
    print("-" * 40)
    print(nvr, response, response.status_code)
    data = response.json()
    print(pprint.pformat(data))

The output will show that Greenwave is requiring a specific testcase to run, but it cannot find a result for it (neither pass nor failure). So now it is possible to submit a waiver with the specified testcase in the output and the subject already known.

トラブルの解決方法(Troubleshooting)

If you run the waiverdb-cli tool and it gives you the following error:

 Error: The config option "resultsdb_api_url" is required

Edit /etc/waiverdb/client.conf and add the following line:

 resultsdb_api_url=https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0

マイルストーンごとにブランチされたフリーズ（Branched milestone freezes）

For a short period before each milestone release, the stable fedora repository is frozen. These periods are shown as the Milestone freezes (Beta Freeze, Final Freeze) on schedules. During these periods, builds will not be marked stable and pushed from updates-testing to fedora even after being submitted manually or automatically. In the normal course of events, they will be pushed after the milestone release is approved at a Go_No_Go_Meeting. If you believe your update deserves to break a milestone freeze, a freeze exception may be granted through the freeze exception process. Accepted release blocking bugs are granted the same status through the blocker bug process.

For more on the Fedora development process, see Fedora Release Life Cycle.

If you are unsure whether your build is currently considered stable for a given release, you can check with koji latest-pkg fXX (where XX is the release).

セキュリティのための更新（Security updates）

There is an additional process that layers over the regular update process for bugs identified as security issues. If a bug is assigned to you that blocks a security tracking bug, you must follow that process in addition to this one.

新しいパッケージの投稿(New package submissions)

If you want to build a new package, but you aren't sure which releases to send it to:

• New packages should always be built for Rawhide
• New packages can be built for Branched and stable releases if adding them would provide value to users of those releases without significant risk of causing harm

The submission process for new packages, after they have passed the Package_Review_Process and been given an SCM repository, is exactly the same as that for package updates.

パッケージテスト計画作成について考える(Consider creating a package test plan)

If you create test cases for your package, and categorize them appropriately, they will be automatically linked in Bodhi, so that testers will have some guidance for planned update testing.