Skip to content

Systemd

About systemd in Hyperscale

We try to follow the systemd build from Fedora rawhide as closely as possible.

CI/CD

Links can be found on the CI/CD page.

Contributing to the Staging Repo

All of the patches we backport for the Hyperscale build of systemd are first merged to centos-sig-hyperscale/systemd, a Git repo where we stage patches. This allows people to use meson to build systemd with all of the Hyperscale patches, and run them against the systemd upstream unit tests without having to build a RPM.

We try to maintain as few patches as possible for each release, but we are open to including new features or bug fixes that are not yet available. Generally we prefer there to either be an open or merged pull request (PR) in systemd upstream before we will consider merging into the staging repo.

Steps:

  • Get a Fedora account here if you don't have one already.
  • Fork centos-sig-hyperscale/systemd.
  • Check out the latest Hyperscale branch there. It should be the last one alphabetically in the form of "hs-v<systemd-stable version number>". If you want to backport a patch to a stable systemd version that does not yet have a branch available in the staging repo, open an issue here to ask the maintainers to create a new branch for that version.
  • If you think your PR from upstream will apply cleanly, you can download it and git am <patch file> it directly. Otherwise you can use git cherry-pick and manual edits to ensure your change will build.
    • At minimum, do a meson test to ensure unit tests pass.
    • If you're backporting an upstream commit, update the BACKPORTS file with a link to the changes you're backporting
  • Open a PR against centos-sig-hyperscale/systemd with your change.
    • In the PR, include a link to your PR from systemd upstream.
    • Tag anitazha/daandemeyer for reviews.
  • Once merged, one of the systemd Hyperscale maintainers will update the RPM spec and publish a new version of systemd for Hyperscale with the patches.

Preparing a new release in the Staging Repo

  • Run create_or_checkout_release_branch.sh from the systemd-releng repo. Pass the name of the systemd stable release you want to base the new Hyperscale release on as an argument (e.g. ./create_or_checkout_release_branch.sh 250.3). This will push two new release branches to the pagure repository, one for the general Hyperscale release, one for the Meta specific release.
  • Look at the BACKPORTS file for the backports done for the previous release, find out which are still relevant for the next release and backport those changes to the new release branches. First, do the backports for the Hyperscale release branch, then merge the Hyperscale release branch into the Meta specific release branch and then do any Meta specific backports.
  • Add new entries to the BACKPORTS file for the new release branches, along with links to all the backports.
  • Push the branches to the pagure remote.
  • When backporting PRs that haven't been merged upstream yet, update systemd-git-update and systemd-cd in the systemd-releng repository as well. Update systemd-git-update to pull the upstream PR and mirror it to a branch on the pagure remote. Update systemd-cd to merge the mirror branch into the main branch when running the CI.

The new release branches are now ready to be used in the RPM spec. See the next section on how to do a new release for the RPM spec.

Contributing to the RPM spec / New Version Updates in the SIG

Make sure you're onboarded onto the SIG before following these steps.

For the following examples, most/all of the links will go to the c8s-sig-hyperscale branch when there are mentions of the RPM sources repo. Substitute as needed with the latest branches (e.g. c9s-sig-hyperscale).

When we're building for 2 releases (e.g. c8s and c9s), you can do most/all of the work on one branch (e.g. c8s) and push to the other branch (e.g. c9s) using the power of Git. Unless something happens, like a dependency being dropped on the newer CentOS version, rarely will changes on the older branch fail on the newer one.

Steps:

  • Clone the CentOS RPM sources repo
    • Checkout the c8s-sig-hyperscale branch
  • Add the Fedora RPM sources repo as a git remote
    • git remote add fedora https://src.fedoraproject.org/rpms/systemd && git fetch fedora
  • Sync against changes from Fedora Rawhide.
    • The gist of this step is to figure out when we last synced from Fedora Rawhide, and get a diff between the latest Rawhide changes and the last time we synced. Have the Fedora Rawhide repo checked out and pulled to the latest commit.
    • For example, looking at this example commit again, scroll down to %changelog and the last non-CentOS Hyperscale log line was from Tue Sep 14 2021 Sahana Prasad <sahana@redhat.com>. You can tell because the version-release string in the changelog doesn't have the additional dot number appended that we use for Hyperscale (e.g. 249.4-2 vs. 249.4-2.1).
    • If we look for the Fedora Rawhide commit corresponding to that changelog line, it will take us to 46a408102a0cfb5692d4625a33025811cab0343f.
    • git diff 46a408102a0cfb5692d4625a33025811cab0343f..fedora/rawhide will get us all the changes from the latest commit to the last time we synced to CentOS Hyperscale. To apply these changes to the Hyperscale branch, run git apply -3 < $(git diff 46a408102a0cfb5692d4625a33025811cab0343f..fedora/rawhide). This will apply the changes and generate merge conflicts when the upstream changes conflict with our own changes.
  • Update the source commits, version/release and changelog.
    • At the top of the specfile, update the hs_commit macro to point to the latest commits for the Hyperscale and Facebook branches for the current release on the staging repo respectively.
      • For the v250 release, these would be the latest commits on the hs-v250.3 and hs+fb-v250.3 branches respectively.
    • At the top of the specfile, update the Version and Release values. This should match Fedora, except that we also append a dot number value to indicate which iteration of the Hyperscale release we're on.
    • At the bottom of the specfile under changelog, add an entry about these changes.
  • Run the following commands to download the tarballs for the Hyperscale and Facebook branches:
    • spectool --define "_sourcedir $PWD" --define "facebook 1" -g systemd.spec
    • spectool --define "_sourcedir $PWD" -g systemd.spec
  • Update the sources file with the new tarball names and SHA512 hashes.
    • For example, the c8s-sig-hyperscale sources contains the SHA512 hashes along with the names of the tarballs.
  • Git commit all these changes. Don't push just yet.
    • If you push at this point it's not the end of the world, but we haven't confirmed the build succeeds yet!
    • At this point it's also a good idea to ask for a sanity check from the other Hyperscale maintainers. You can do a git show and paste the output to the CentOS pastebin.
  • Build locally with mock
    • One common reason for the RPM build failing is patch files between the staging repo and Fedora not playing nicely together. If this is the case, you can try using git am <file> to apply the Fedora patches to the staging repo and iron out build failures there. Rearrange patches as needed in the staging repo or specfile to get things to fit.
    • Other reasons for failure are dependencies. This you'll need to figure out from logs.
  • Do a scratch build in CBS
    • You can use the source RPM generated by running mock to do the scratch build. It'll be located at /var/lib/mock/centos-stream-8-x86_64/root/builddir/build/SRPMS.
  • Upload the new version tarballs to CentOS.
    • Calculate the SHA512 hash of a tarball using sha512sum.
    • Check if the tarball has not already been uploaded here.
    • Upload the tarball to the CentOS lookaside cache by calling the upload-sources.sh script here from the directory of your sources file.
  • All updates are in and we have a successful build? Push your changes and get started with testing!

Build Commands

For CBS you will need to be onboarded to the SIG.

From inside the fork of the systemd Hyperscale RPM sources repo:

# Create src.rpm
rpmbuild --define "%_topdir $PWD" --define "%_sourcedir $PWD" --define "%dist .hs.el8" -bs systemd.spec
rpmbuild --define "%_topdir $PWD" --define "%_sourcedir $PWD" --define "%facebook 1" --define "%dist .hs+fb.el8" -bs systemd.spec

# Local build with mock; You can also skip these steps and use cbs directly
mock -r centos-stream-8-x86_64 -D "%dist .hs.el8" <path to src.rpm>
mock -r centos-stream-8-x86_64 -D "%facebook 1" -D "%dist .hs+fb.el8" <path to src.rpm>

# CBS scratch builds
cbs build --scratch hyperscale8s-packages-main-el8 <path to src.rpm>
cbs build --scratch hyperscale8s-packages-facebook-el8 <path to facebook src.rpm>

Once the specfile changes are pushed you can do a real build:

# CBS builds for CentOS Stream 8
git checkout c8s-sig-hyperscale
cbs build hyperscale8s-packages-main-el8 "git+https://git.centos.org/rpms/systemd.git#$(git rev-parse HEAD)"
cbs build hyperscale8s-packages-facebook-el8 "git+https://git.centos.org/rpms/systemd.git#$(git rev-parse HEAD)"

# CBS builds for CentOS Stream 9
git checkout c9s-sig-hyperscale
cbs build hyperscale9s-packages-main-el9s "git+https://git.centos.org/rpms/systemd.git#$(git rev-parse HEAD)"
cbs build hyperscale9s-packages-facebook-el9s "git+https://git.centos.org/rpms/systemd.git#$(git rev-parse HEAD)"

# Tag it for testing
cbs tag-build hyperscale8s-packages-main-testing systemd-<version num>.hs.el8
cbs tag-build hyperscale8s-packages-facebook-testing systemd-<version num>.hs+fb.el8
cbs tag-build hyperscale9s-packages-main-testing systemd-<version num>.hs.el9
cbs tag-build hyperscale9s-packages-facebook-testing systemd-<version num>.hs+fb.el9

# Tag for release; This will let it go to the mirrors
cbs tag-build hyperscale8s-packages-main-release systemd-<version num>.hs.el8
cbs tag-build hyperscale8s-packages-facebook-release systemd-<version num>.hs+fb.el8
cbs tag-build hyperscale9s-packages-main-release systemd-<version num>.hs.el9
cbs tag-build hyperscale9s-packages-facebook-release systemd-<version num>.hs+fb.el9
Back to top