Submitting module builds in Fedora

With Modularity, you no longer build individual packages. Instead, you need to submit a module build.

Module builds are triggered using fedpkg from within your dist-git repository.

$ fedpkg clone modules/NAME
$ cd NAME
$ fedpkg switch-branch BRANCH
$ fedpkg module-build

  • NAME — name of the module

  • BRANCH — name of the stream branch of the module

Please note the module build ID. You will need it to verify the build state and to publish the module later.

Submitting module builds from a system without a web browser

fedpkg module-build requires an authorization to MBS. Fedora infrastructure uses OpenID Connect (OIDC) for authorizing to web applications. This authorization needs a web browser. If you are submitting a build from a system without a browser, e.g. from a virtual machine or a container, please follow this procedure:

fedpkg module-build prints a message with a URL to your terminal, like this:

Please visit https://id.fedoraproject.org/openidc/Authorization?scope=openid+https%3A%2F%2Fid.fedoraproject.org%2Fscope%2Fgroups+https%3A%2F%2Fmbs.fedoraproject.org%2Foidc%2Fsubmit-build&response_type=code&client_id=mbs-authorizer&redirect_uri=http%3A%2F%2Flocalhost%3A12345%2F&response_mode=query to grant authorization

You must open it in your web browser. After succeeding an authentication step, your browser will complain with:

This site can’t be reached localhost refused to connect.
Search Google for localhost 12345
ERR_CONNECTION_REFUSED

Your browser at this point have a localhost URL in its address bar, like this:

http://localhost:12345/?code=7c35ded4-054b-4df0-9151-7ef12c7fb838_xe3JWkvf_sL1UyLOzftHJZ3uIlfOo00N

At this point fedpkg waits on port 12345 of your system for an incoming connection from your web browser. While fedpkg waits for an incoming OIDC answer from your browser, imitate the answer with curl tool in a parallel terminal using the very same URL:

$ curl 'http://localhost:12345/?code=7c35ded4-054b-4df0-9151-7ef12c7fb838_xe3JWkvf_sL1UyLOzftHJZ3uIlfOo00N'

That will unblock fedpkg module-build command and it will resume with submitting the module build.

Common failures when submitting a module build

If a fedpkg module-build command fails immediatelly before reporting the identifiers of spawned module build tasks, there could be a mistake in the YAML file. Here is is an explanation of some nonobvious error messages:

  • None of the base module (platform or bootstrap) streams in the buildrequires section could be found — one of the dependency configurations requires a platform stream which does not exist in MBS. That often happens when an old Fedora release is removed from the build infrastructure. A remedy is removing a configuration block referring to that platform stream from the YAML file.

  • Required platform:f36 and platform:f37 — a build-required module stream does not exist in a context for the same platform stream as a module you submitted for building. This happens when you forget to build the dependent module for the new platform. A remedy is either building the dependent module first, or remove a configuration for that platform.

Module build progress

To watch the state of your module build, run:

$ fedpkg module-build-watch BUILD_ID

When the module is in a "ready" state, the build has successfully completed.

You can also watch the build(s) on Fedora Module build service:

https://release-engineering.github.io/mbs-ui/modules

Module build results

All the packages built in the module are tagged in Koji tag named as module-$name-$stream-$version-$context. The link to this tag is also available in Fedora Module build service UI mentioned earlier.

There are also two Koji Builds representing single module build.

  • $name-$stream-$version.$context - Contains the metadata with final RPMs which will be included in a compose and will be therefore visible by the end user.

  • $name-devel-$stream-$version.$context - Contains the metadata with filtered RPMs which are not normally visible to end user, but might be sometimes useful when building other packages against the module. Generally, in Fedora we do not ship the -devel modules.

You will not find $name-devel module build in Module Build Service, because this is only another representation of non-devel module build. It is not separate module build on its own and it only exists as Koji build.

Both Koji module builds contains various metadata files:

  • modulemd.src.txt - The unchanged input modulemd metadata used to build a module as stored in dist-git.

  • modulemd.txt - The expanded modulemd metadata which was used by Module Build Service to build this particular module. This for example contains the right build requirements based on the Module Stream Expansion.

  • modulemd.$arch.txt - The per-architecture modulemd metadata listing the RPMs which will end up in a compose and therefore be visible to end user. This for example respects filters or multilib modulemd options.

Rebuild strategies

In case you want to control which packages get rebuilt and which get reused, you can enforce a specific rebuild strategy while submitting a build.

There are different rebuild strategies to choose from:

  • all — All packages in the module get rebuilt.

  • only-changed — Only packages that have changed since the last successful build get rebuilt. This is the default in Fedora.

  • changed-and-after — This one leverages build groups (buildorder). Packages that have changed since the last successful build get rebuilt, and also all packages with a buildorder higher than any of the changed ones get rebuilt as well.

For more detailed information, please see the MBS rebuild strategies documentation.

To enforce a specific rebuild strategy, submit the module build with the following command:

$ fedpkg module-build --optional rebuild_strategy=STRATEGY

  • STRATEGY — name of a specific build strategy (listed above)

Want to help? Learn how to contribute to Fedora Docs ›