From 5d8becd0f3779242ba682802bee25dc1d25c09f5 Mon Sep 17 00:00:00 2001 From: Daan De Meyer Date: Sep 17 2024 08:20:44 +0000 Subject: [PATCH 1/2] Update section on RPM patches a little --- diff --git a/docs/internal/systemd.md b/docs/internal/systemd.md index 9563ff9..06dc2e2 100644 --- a/docs/internal/systemd.md +++ b/docs/internal/systemd.md @@ -42,12 +42,13 @@ Steps: downstream patches. Every downstream patch should have a comment to an upstream pull request where the functionality is proposed for inclusion in systemd itself. * If the patch has been upstreamed but isn't in a stable release yet, you can ask upstream for a new stable release or - prepare one yourself using the instructions found [here](https://systemd.io/RELEASE/). If there was a recent stable - release and the issue that we need fixed only happens rarely in very specific use cases, the corresponding commit can - be added as a patch to the rpm repository instead. - * Run `git format-patch ` in the systemd repository - * Move the patch to the rpm repository - * Add something like `PatchXXXX: ` to the rpm spec + prepare one yourself using the instructions found [here](https://systemd.io/RELEASE/). Urgent fixes or newer feature backports + that aren't appropriate for stable releases can be added as patches to the rpm repository itself. To apply a patch to the rpm + repository, you can do the following: + * Add something like `PatchXXXX: https://github.com/systemd/systemd/pull/$PR.patch` to the rpm spec + * If a PR doesn't apply cleanly to the stable branch, cherry-pick the commits into a subbranch of the corresponding + stable branch in the systemd repository and open a PR on Github which you can then list in the rpm spec. If the patch + is a feature backport, you can immediately close the PR as it won't be merged anyway. * Update the version and release. * If we're building rpms for the same systemd stable release (from https://github.com/systemd/systemd/releases) as is shipped in Fedora Rawhide, no changes are required to the spec. @@ -60,7 +61,7 @@ Steps: * Exceptions can be made when Fedora makes a change that we want to explicitly want to deviate from. * The upstream systemd repository builds rpms for CentOS Stream using the Fedora Rawhide spec, so the more our spec matches the Fedora Rawhide one, the better our test coverage. -* Download the source tarball from the systemd github repository: +* Download the source tarball and patches from the systemd github repository: * `spectool --define "_sourcedir $PWD" -g systemd.spec` * Update the `sources` file with the new tarball name and SHA512 hash. * Use `sha512sum` to calculate the SHA512 hash of the tarball. From 3a8b25bae3e2fc49b67fb1f4ca1471f0387f54c6 Mon Sep 17 00:00:00 2001 From: Daan De Meyer Date: Sep 17 2024 08:21:07 +0000 Subject: [PATCH 2/2] Drop snippet on tools tree Let's assume the people reading and using this are OK with installing the required dependencies on their host system. --- diff --git a/docs/internal/systemd.md b/docs/internal/systemd.md index 06dc2e2..9532a4d 100644 --- a/docs/internal/systemd.md +++ b/docs/internal/systemd.md @@ -89,20 +89,7 @@ git clone https://github.com/systemd/mkosi.git sudo ln -s /usr/local/bin/mkosi $(pwd)/mkosi/bin/mkosi ``` -To install the dependencies required by mkosi, we can either use a tools tree or -install the required dependencies on our host system. To use a tools tree, write -the following to mkosi.local.conf within the same directory containing the mkosi -configuration that we're about to build (see below): - -```conf -[Host] -ToolsTree=default -ToolsTreeDistribution=centos -ToolsTreeRelease=9 -ToolsTreeRepositories=epel,epel-next,hyperscale-packages-main -``` - -To install all required dependencies on the host, run +To install all required dependencies on the host system, run `mkosi dependencies | xargs sudo dnf install`. Note that your host system will need to have systemd 256 or newer packaged to be able to run the integration tests successfully.