From Fedora Project Wiki

Revision as of 20:15, 28 June 2011 by Jlaska (talk | contribs) (More content)

This page describes the process for tagging, building and deploying a new version of autoqa. This page assumes a basic understanding of rpm spec file syntax and commands such as git, mock and yum.

Update autoqa.spec

Once the decision has been made to release a new version of autoqa, the first step is to update the rpm spec file with the newer version. Ideally,

  1. Checkout the master branch of autoqa
    git clone ssh://git.fedorahosted.org/git/autoqa.git && cd autoqa
  2. Edit autoqa.spec by incrementing the Version and updating the %changelog
  3. Locally commit the changes
    git commit autoqa.spec
  4. Push your changes to the remote git repository
     git push ssh://git.fedorahosted.org/git/autoqa.git master

Cherry-pick and tag

Next, we'll cherry-pick the autoqa.spec change into the stable git branch and tag the release.

  1. Change to the stable branch
    git checkout -b stable origin/stable || git checkout stable
  2. Cherry pick the updated autoqa.spec change
    git cherry-pick origin/master
  3. Tag the release
    git tag vX.Y.X-1,2,3 stable
  4. Push your changes
    git push --tags ssh://git.fedorahosted.org/git/autoqa.git stable

Upload tarball

Like many projects, the appropriate method to release a new version is by tarball. Once you have tagged the release, upload a new tarball using the following commands.

  1. Change to the stable branch
    git checkout -b stable origin/stable || git checkout stable
  2. Upload a new release tarball
     make upload 

Build RPM

With the tarball uploaded, it's time to package the new release for all currently supported Fedora releases. This includes Fedora 41, Fedora 40 and, depending on the time of release, potentially Fedora 39.

  1. Change to the stable branch
    git checkout -b stable origin/stable || git checkout stable
  2. Install build dependencies (requires root privileges)
    yum install $(grep ^BuildRequires: autoqa.spec | awk '{print $2}')
  3. Build packages from the current stable branch
     make rpms 

Update repositories

Traditionally, this step would be handled by running the koji build --tag dist-f41-updates path/to/src.rpm command. However, since autoqa is not yet packaged and available in Fedora repositories, a custom package repository is used to deliver updates. This section describes building packages for different releases and updating the custom package repositories.

  1. Prepare a mock chroot for the desired release. In this example, we'll build for Fedora 40 on x86_64
     mock -r fedora-40-x86_64 --init 
  2. Using the src.rpm previously created in step #Build_RPM, build a new package for Fedora 40
     mock -r fedora-40-x86_64 --rebuild path/to/autoqa-X.Y.Z-1.2.3.src.rpm 
  3. Repeat this process for all desired releases.
Building for EPEL-5?
Due to changes in the filedigest algorithm, extra care is required when building packages for EPEL-5. Be sure to set the _source_filedigest_algorithm and _binary_filedigest_algorithm for any packages used when building for EPEL-5. This includes the package supplied by the --rebuild argument. Refer to the example below for guidance.
mock -r epel-5-x86_64 \
  --define '_source_filedigest_algorithm 1' \
  --define '_binary_filedigest_algorithm 1' \
  --rebuild path/to/autoqa-X.Y.Z-1.2.3.src.rpm

Deploy

FIXME