Skip to content

Building packages

Prerequisites

  • For local test builds: mock and mock-centos-sig-configs
  • To interact with the lookaside: centos-get-sources and centos-lookaside-upload-sig from centos-packager
  • To interact with CBS: cbs from centos-packager

Working with git

SIG members can push SIG branches to any repo under git.centos.org. SIG branch names need to prefixed with cXs-sig-hyperscale, where cXs refers to the CentOS Stream version (e.g. c8s for CentOS Stream 8). Currently we're using:

  • cXs-sig-hyperscale: stuff meant to go in the main repository
  • cXs-sig-hyperscale-experimental: stuff meant to go in the experimental repository
  • cXs-sig-hyperscale-spin: stuff meant to go in the spin repository

To create a new package file a ticket for CentOS Infra. Before doing that, think about whether you actually need a new package in CentOS proper, or whether you can use Fedora/EPEL instead.

Cloning and building a package

To clone an existing package:

$ git clone ssh://git@git.centos.org/rpms/systemd.git

To fetch the sources from lookaside, run centos-get-sources from inside the checkout.

To do a local test build, make sure mock-centos-sig-configs is installed, then do:

$ mock -r centos-stream-hyperscale-9-x86_64 --sources ./SOURCES --spec ./SPECS/*.spec
Making changes

To make a new empty SIG branch (you can also branch c8s if you prefer starting from the existing packaging):

$ git checkout --orphan c9s-sig-hyperscale

If you need to add new source tarballs:

$ centos-lookaside-upload-sig -f systemd-249.4.tar.gz -n systemd

to push them to lookaside, then update gitignore and metadata (example)

Note that centos-lookaside-upload-sig requires a valid CentOS certificate. See the CentOS SIG Guide for more information.

Build tags

All our build tags set the %centos_hs macro 1, so that we can gate Hyperscale-specific behavior in package specs if needed.

Note

As explained in CentOS-Infra #75, when adding new tags, make sure to request that epel and epel-next repos are added to the tags.

CentOS Stream 9

We have two main build tags:

  • hyperscale9s-packages-main-el9s -- our default build tag, if you're not sure, this is probably what you want to use; packages built here will have %dist set to .hs.el9
  • hyperscale9s-packages-experimental-el9s -- use this when building for experimental; this tag does not inherit from main, and packages build here will have %dist set to .hsx.el9

There are three additional special purpose tags:

  • hyperscale9s-packages-facebook-el9s -- same as main, but also with %facebook set to 1 and %dist set to .hs+fb.el9; meant for Facebook-flavored builds, currently only used for systemd and btrfs-progs
  • hyperscale9s-packages-hotfixes-el9s -- do not use, use main instead
  • hyperscale9s-packages-spin-el9s -- use this when building for packages for spin that should not be in the main buildroot; prefer using main whenever possible
CentOS Stream 8

We have two main build tags:

  • hyperscale8s-packages-main-el8 -- our default build tag, if you're not sure, this is probably what you want to use; packages built here will have %dist set to .hs.el8
  • hyperscale8s-packages-experimental-el8 -- use this when building for experimental; this tag does not inherit from main, and packages build here will have %dist set to .hsx.el8

There are three additional special purpose tags:

  • hyperscale8s-packages-facebook-el8 -- same as main, but also with %facebook set to 1 and %dist set to .hs+fb.el8; meant for Facebook-flavored builds, currently only used for systemd and btrfs-progs
  • hyperscale8s-packages-hotfixes-el8 -- do not use, use main instead
  • hyperscale8s-packages-spin-el8s -- use this when building for packages for spin that should not be in the main buildroot; prefer using main whenever possible

Destination tags

For each build tag, we have three destination tags:

  • ${tag}-candidate - regular builds end up here by default and will be included in the buildroot for subsequent builds
  • ${tag}-testing - builds tagged here end up on buildlogs.centos.org
  • ${tag}-release - builds tagged here end up on mirrors.centos.org

where ${tag} would be something like hyperscale8s-packages-main, leading to a destination tags like hyperscale8s-packages-main-release, which will end up in /centos/8-stream/hyperscale/${arch}/packages-main.

Destination tags are orthogonal to build tags: you can tag any build into any destination tag (though, obviously, some combinations won't make much sense). Common workflows:

  • when building for main, tag into main; likewise, when building for experimental tag into experimental
  • when building non-modular packages that replace modular packages (e.g. libvirt), tag them into hotfixes instead of main (but still do the builds in main)
  • when building spin-specific packages that should only be used on spin installs, tag them into spin destination tags.

Note that you won't be able to tag into a destination tag unless it's been registered to the tag first with cbs add-pkg; likewise, packages can be unregistered from tags with cbs remove-pkg.

Working with cbs

To run a scratch build from git:

$ cbs build --scratch hyperscale9s-packages-main-el9s "git+https://git.centos.org/rpms/systemd.git#$(git rev-parse HEAD)"

To run a real build, the package needs to be registered to a destination tags first:

$ cbs add-pkg --owner=dcavalca hyperscale9s-packages-main-candidate systemd
$ cbs add-pkg --owner=dcavalca hyperscale9s-packages-main-testing systemd
$ cbs add-pkg --owner=dcavalca hyperscale9s-packages-main-release systemd

This only needs to be done once per package.

To kickoff a build:

$ cbs build hyperscale9s-packages-main-el9s "git+https://git.centos.org/rpms/systemd.git#$(git rev-parse HEAD)"

To publish to buildlogs.centos.org:

$ cbs tag-build hyperscale9s-packages-main-testing systemd-249.4-2.9.hs.el9