Package Unretirement Process

Description

Sometimes a packager might request (via opening a ticket) that we unretire a package branch that has previously been retired.

Unretirements typically happen for the rawhide branch, but could conceivably happen for any stable branch.

A valid Kerberos (kinit) ticket and cvsadmin FAS group membership are needed.

Actions

Validate Package Ready For Unretirement

  1. Verify what the reason and time of the retirement was. This is usually stated in the retirement commit.

  2. Ensure that a Bugzilla ticket was filed to review the package for unretirement. This is not necessary in case the package was retired less than 8 weeks ago.

  3. Verify with the the requestor exactly which branches are to be unretired.

Revert The Retirement Commit

  1. Connect to one of the compose systems.

    $ ssh compose-branched01.rdu3.fedoraproject.org
  2. Clone the package using the the proper release engineering credentials.

    $ GIT_SSH=/usr/local/bin/relengpush fedpkg --user releng clone PACKAGENAME
  3. Enter the directory of the cloned package.

    $ cd PACKAGENAME
  4. Configure the git user information.

    $ git config --local user.name "Fedora Release Engineering"
    $ git config --local user.email "releng@fedoraproject.org"
  5. Revert the retirement commit (that introduced the dead.package file) in dist-git on the particular branch using its commit hash ID. Ensure the commit message contains a URL to the request in Pagure.

    $ git revert -s COMMIT_HASH_ID
  6. Push the commit.

    $ GIT_SSH=/usr/local/bin/relengpush fedpkg --user releng push

Commit message example:

Unretirement request: pagure.io/releng/issue/12345

Special Case: Branches That Have An Identical Commit History

Normally that should be all that is required in regards to git operations. If the branches have already diverged then each branch gets its own revert commit. However, from time to time a special case might arise (usually around the time of mass branching) where both of the branches have an identical commit history.

The package gets retired due to FTBFS/FTI reasons, has the dead.package file at the time of mass branching and then a new branch is created that also contains the dead.package file. At this point nobody without proper credentials can push to the repository.

In such a case we want to keep the commit history identical for both branches.

  1. Update the remote-tracking branches.

    $ GIT_SSH=/usr/local/bin/relengpush git fetch
  2. Switch to the other branch that is to be unretired.

    $ git switch BRANCH_NAME
  3. Reset both the index and the working tree of the branch you are on to the branch that already contains the unretirement commit.

    $ git reset --hard rawhide
  4. Push the changes to the correct branch.

    $ GIT_SSH=/usr/local/bin/relengpush git push origin BRANCH_NAME

The outcome of this should be that there is only one revert commit for both branches, keeping the commit history clean.

Unblock The Package In Koji

  1. Check the current state of the tags.

    $ koji list-pkgs --show-blocked --package PACKAGE_NAME
  2. Unblock each requested tag.

    $ koji unblock-pkg TAG_NAME PACKAGE_NAME
  3. Untag all of the builds for each tag that was unblocked.

    $ koji untag-build --all TAG_NAME PACKAGE_NAME --force

Verify Package Is Not Orphaned

  1. Navigate to dist-git and find the package.

  2. Check who the package owner is.

  3. If the owner is orphan then give the package to the requestor through the web interface.

    Settings → Give Project → NEW_MAINTAINER_FAS_NAME

It is a good idea to link the dist-git repository directly in the ticket when closing it and remind the requestor to submit a new build for each unretired branch.