Composing Fedora


All composes are defined by configuration files kept in the pungi-fedora repository.

Composes fall into two categories. They may be release candidates created on demand or nightly composes set to run at a scheduled time each day.

Compose Name Configuration File Compose Script
Atomic fedora-atomic.conf
Docker fedora-docker.conf
Cloud fedora-cloud.conf
Modular fedora-modular.conf
Nightly fedora.conf

When Quality Engineering (QE) requests a Release Candidate (RC) they do so by opening an issue in the releng repository on pagure. Release candidate composes are not currently automated.

Compose Name Configuration File Compose Script
Alpha fedora-alpha.conf
Beta fedora-beta.conf
GA fedora-final.conf


Fedora 26 was the last release to include an Alpha release candidate.


The following procedures are for release candidates only. They do not apply to the scheduled nightly composes.

Review Compose Tags

  1. List any pre-existing builds in the current compose tag

    $ koji list-tagged f[release_version]-compose
  2. Verify pre-existing builds are in compose tags

    The tagged builds from the previous composes should all be present in the output from the previous step. Consult the request ticket for the list of builds expected in this output.


    The very first run of an Alpha, Beta, or GA compose should have no builds listed under the compose tag. It is important to clear pre-existing builds from the compose tag when moving between the Alpha, Beta and RC composes. Verify that these builds were removed.

    $ koji list-tagged f[release_version]-compose
    $ koji untag-build --all f[release_version]-compose [build1 build2 ...]


    The order in which packages are added into the f[release_version]-compose tag matter. If the builds are untagged erroneously then special attention should be given to adding them back correctly.

  3. Add builds specified by QE to the current compose tag

    $ koji tag-build f[release_version]-compose [build1 build2 ...]


    These steps may be completed on a local machine as long as the user has appropriate permissions in the koji tool.

Package Signing before the Compose

  1. Check for unsigned packages

    $ koji list-tagged f[release_version]-signing-pending


    If there are unsigned builds then wait for the automated queue to pick them up and sign them. Contact a member of the Fedora infrastructure team if the package signing has taken more than thirty minutes.

Running the Compose

  1. Update the pungi-fedora config file Composes use a configuration file to construct the compose. Each compose uses its own configuration. The global_release variable should start from 1.1 and the second number should increment each time a new compose is created.

    • Alpha - fedora-alpha.conf
    • Beta - fedora-beta.conf
    • RC - fedora-final.conf
  2. Log into the compose backend

    $ ssh
  3. Open a screen session

    $ screen
  4. Obtain the pungi-fedora branch for the current compose

    The first time any user account executes a compose the pungi-fedora git repository must be cloned. The compose candidate script that invokes pungi should be run from

    $ git clone ssh://

    Enter the pungi-fedora directory.

    $ cd pungi-fedora

    If the clone step above was not required then fully update the existing repository checkout from pagure.

    $ git fetch origin
    $ git checkout f[release_version]
    $ git pull origin f[release_version]
  5. Run the compose

    $ sudo ./ [Alpha|Beta|RC]-#.#

    The numbering scheme begins with 1.1 and the second number is incremented after each compose.


    Pungi requires numbers in the format #.# as an argument. It is because of this that composes always start with the number 1 and the second number is incremented with each compose.


    If the compose fails with a directory missing error, then create the compose directory with mkdir /mnt/koji/compose/[release_version]

Syncing the Compose

We sync the compose to /pub/alt/stage to enable faster access to new content for QA and the larger Fedora community.

  1. Log into the compose backend

    $ ssh
  2. Open a screen session

    $ screen
  3. Check the status of the compose

    $  cat /mnt/koji/compose/[release_version]/[compose_id]/STATUS

    Do not continue with any further steps if the output above is DOOMED.

  4. Create the directory targeted for the copy

    $ sudo -u ftpsync mkdir -p /pub/alt/stage/[release_version]_[release_label]-[#.#]
  5. Locate the compose directory that will be the copy source

    $ ls /mnt/koji/compose/[release_version]/[compose_id]


    Take care executing the synchronization if the next compose is already running. Be sure to grab the correct directory.

    If in doubt, check /mnt/koji/compose/[release_version]/[compose_id]/STATUS to be sure it is finished.

  6. Run the synchronization one-liner

    The synchronization of the completed compose to the public domain is currently a one-liner shell script. Pay close attention to what needs replaced in the example below.

    $ for dir in Everything Cloud CloudImages Docker Labs Server Spins Workstation WorkstationOstree metadata; do sudo -u ftpsync rsync -avhH /mnt/koji/compose/26/Fedora-26-20170328.0/compose/$dir/ /pub/alt/stage/26_Alpha-1.4/$dir/ --link-dest=/pub/fedora/linux/development/26/Everything/ --link-dest=/pub/alt/stage/26_Alpha-1.1/Everything/ --link-dest=/pub/alt/stage/26_Alpha-1.2/Everything/ --link-dest=/pub/alt/stage/26_Alpha-1.3/Everything --link-dest=/pub/alt/stage/26_Alpha-1.4/Everything; done


    This one-liner prompts for the password+token several times over the course of its runtime. If the login window is missed it will skip an entire variant. Just check the source and destination after completion and, if there is a directory missing, run the script again.

  7. Update the issue in the releng pagure repository

    Once the compose and sync is complete the issue in pagure should be updated and closed.

    Standard Ticket Verbage

    Compose is done and available from it has been synced to rpms have all be hardlinked to /pub/fedora/linux/development/26/


The method for verifying a compose has completed is checking /mnt/koji/compose/[release_version]/[compose_dir]/STATUS. Any status other than DOOMED is OK.

Consider before Running

Composes and file synchronizations should be run in a screen session on a remote machine. This enables the operator to withstand network connection issues.