Using the Koji build system

Sometimes you want to make sure that one build has succeeded before launching the next one, for example when you want to rebuild a package against a dependency that has just been rebuilt. fedpkg provides a chain-build command to help with this. As explained in the Package Update Guide, multi-build chains like this should be created on a side tag, and you can use fedpkg chain-build to do the builds on the side tag.

To do a chained build to a side tag, first create the side tag, as explained in the Package Update Guide. In the simplest case, just do:

This will print a command you can use to wait for the side tag to be created. Run that command, and when it exits, do:

replacing side-tag-name with the actual name of your side tag.

The current package is added to the end of the CHAIN list. Colons (:) can be used in the CHAIN parameter to define groups of packages. Packages in any single group will be built in parallel and all packages in a group must build successfully and populate the repository before the next group will begin building. For example:

causes libwidget and libaselib to be built in parallel, followed by libgizmo, and then the package in your current directory. If no groups are defined, packages will be built sequentially.

If a build fails, following builds are canceled, but the builds that already succeeded are pushed to the repository.

Note: It is possible to do a chained build directly to the default build target for Rawhide, but this is no longer recommended or reliable. Building for the default Rawhide target immediately auto-creates an update, and some Rawhide updates are now subject to gating tests. If any package in the chain is subject to gating tests, and one fails, that package will never reach stable and the rest of the chain will not be able to build. This is quite likely to happen to chains containing critical path packages. When using a side tag, no updates will be automatically created, and each build is immediately available in the side tag’s buildroot without having to pass tests first. You can manually create the update once all the builds are done, and the tests will not encounter dependency issues if you rebuilt all the dependent packages correctly.

koji can be used to replicate a build root for local debugging.

For example to get the latest buildroot for f40-build run:

You must pass --topurl=https://kojipkgs.fedoraproject.org/ to any mock-config command to get a working mock-config from Fedora’s koji.

List tasks:

List only tasks requested by you:

requeue an already-processed task (general syntax is: koji resubmit [options] taskID):

Instead of using the fedpkg target, you can also directly use the command line tool, koji.

To build a package, the syntax is:

For example:

The koji build command creates a build task in Koji. By default, the tool will wait and print status updates until the build completes. You can override this with the --nowait option.

In Koji, it is sometimes necessary to distinguish between a package in general, a specific build of a package, and the various rpm files created by a build. When precision is needed, these terms should be interpreted as follows:

Koji organizes packages using tags. In Koji a tag is roughly a collection of packages:

A build target specifies where a package should be built and how it should be tagged afterward. This allows target names to remain fixed as tags change through releases.