This reverts commit 56377438ba. Dropping
of the option currently doesn't disable anything, it just moves the
file. I don't think we gain anything by moving the file and actually
this causes problems [1], so let's just return to status quo ante.
[1] file /etc/init.d conflicts between attempted installs of systemd-259.999+69+g6ceb76bfc-2548.1.x86_64 and chkconfig-1.33-3.fc44.x86_64
[skip changelog]
Neither dbus nor pam are required in the initrd so
let's make both recommended dependencies instead
of required dependencies so that we can build
initrds without either of them getting pulled in.
The shell expansion we use to determine the top-level directory will
get expanded even if we don't execute %prep, so add a %_build_in_place
check to make sure we don't try to search for the top-level directory
if --build-in-place is set.
Upstream is moving towards making a lot more libraries dlopen() style
dependencies. Let's make sure to add these as Requires to corresponding
packages so they still get pulled in.
2ace9416e8 broke packit as the fallback
url wasn't listed first anymore. Make sure the fallback URL is listed
first again as clearly documented just above the conditionals.
systemd-networkd-resolve-hook.socket will be introduced by
https://github.com/systemd/systemd/pull/39293 but we need the spec
to handle the socket for the upgrade/downgrade test to pass so adding
it early behind the upstream bcond.
We use our own macros. They get pulled into the buildroot in Fedora
builds, but we shouldn't rely on this. In OBS builds, they are not
pulled in and the build fails.
- This is the first (large) batch of fixes after v258:
- fixes for boot loader and early boot code
- fixes for systemd itself, systemd-udevd, systemd-logind,
systemd-machined, and library code
- unprivileged operation in systemd-machined is disabled for now
- lots of documentation and shell-completion fixes
- includes an hwdb update
... (rhbz#2397579)
In https://bugzilla.redhat.com/show_bug.cgi?id=2397579 users are doing
a partial upgrade (seemingly) and that fails because of a file conflict.
Add Conflicts to prevent such partial upgrades.
An admin can create users in this directory instead of /etc/passwd. As
the .user file can contain hashed password, only root should be able to
read the files.
The upstream PR was closed with the intent to force the SELinux
policy to be updated instead. While we're waiting for that to happen,
include the patch here.
The RPM recipe files for SUSE and Fedora conflict and cannot be
both unpacked at the same time (e.g.: triggers.systemd, systemd.spec,
etc). The tarballs creation are unconditional. This means the same
project build cannot build for both Fedora and SUSE.
All other distros can co-habitate in the same project, so that a single
repository checkout, single trigger, single everything is used.
By storing the RPM recipe files in a separate directory it means they
don't conflict anymore, and they are moved in place in the right recipe
at the right time.
This allows building fedora/suse/centos/debian/ubuntu/arch from a
single project.
[skip changelog]
In the light of the recent discussion about dropping i686 packages, let's stop
building our docs there. This reduces the amount of tools needed in the mock
root.
Unfortunately we need to move the man page out of the noarch ukify subpackage,
because it needs to be the same on all architectures where it is built.
When testing build reproducibility, we got the following result:
+ rpmdiff cache/rpms/systemd-257.6-1.fc43/systemd-257.6-1.fc43.x86_64.rpm \
cache/build/systemd-257.6-1.fc43/rebuild/systemd-257.6-1.fc43.x86_64.rpm
......V..F. /etc/xdg/systemd/user
This is because we'd apply %ghost to a symlink to a directory, if the directory
stat reported 0 blocks. It seems that this depends on the filesystem type or
something and didn't pop up in previous rebuilds.
The first chunk is a noop to increase clarity.
The resulting difference from this patch in the file list:
$ diff -u systemd-257.6-build/systemd-257.6/.file-list-main{.0,}
-%config(noreplace) %ghost /etc/xdg/systemd/user
+%config(noreplace) /etc/xdg/systemd/user
When downgrading to package versions before 257.3-6 we have this error:
Error: Transaction test error:
file /usr/bin/systemd-sysusers from install of systemd-257-9.el10.x86_64 conflicts
with file from package systemd-sysusers-258~devel-20250416115850.el10.x86_64
Add Conflicts on systemd-sysusers subpackage to allow downgrades
across version 257.3-6.
- Fix for local information disclosure in systemd-coredump (CVE-2025-4598)
- Fixes for systemd itself, run0, systemd-networkd, "secure" pager,
man pages, shell completions, sd-boot, sd-varlink
- Hardware database update
This breaks suspend on my machine as of Linux 6.14, furthermore both
linked issues in rhbz#2321268 are closed and fixed in Linux upstream.
This reverts commit 6162965002.
Running from the source tarball implies running with unpatched tests,
whereas the same files from the systemd-tests package (which now contains
the mkosi and integration test files) will be patched.
[skip changelog]
Both work and if we do full sha we can retrieve the full sha from the
source filename in the source rpm later on which is useful for various
use cases.
[skip changelog]
Using the source tree of the spec can still lead to conflicts if a
mkosi/ directory exists there (which is the case in the hyperscale
systemd spec repo), so let's check out mkosi in /var/tmp to ensure
we don't conflict.
https://github.com/systemd/systemd/pull/36954 will move all the mkosi
configuration in the systemd repository into a mkosi/ subdirectory. This
means we have to put mkosi.local.conf in that subdirectory as well, so check
if the mkosi/ directory exists and put mkosi.local.conf in there if it exists.
The mkosi/ directory will conflict with our checkout of mkosi so we move that
checkout one level up. Additionally, we can't use .. anymore as the package
directory as that only works when mkosi.local.conf is in the top level directory
of the repository so we use an absolute path instead.
In OBS, noarch packages are shared between all architectures and
independent architectures can be rebuilt automatically without all
the other architectures getting rebuilt. This can result in the noarch
packages being newer than the archful packages for some architectures,
which means our current strict deps from the noarch packages on the
archful packages can't be satisfied.
To address this problem, let's relax the dependencies from the noarch
packages on the archful packages for OBS builds. Let's only do this for
OBS builds because this isn't an issue on Fedora as it's impossible to
build a package for only some of the architectures.
Noticed in https://bugzilla.redhat.com/show_bug.cgi?id=2348669#c25.
Most of those units listed don't have an [Install] section, and of those that
have, almost all were disabled by default. This might be something to fix, e.g.
we might want to enable systemd-udev-load-credentials.service, this is
something to consider. But it's clearer if we list all the units that those
packages ship. In priciple somebody might ship a preset to enable them.
Anyway, the impact of this change is much smaller than might seem at first.
But systemd-network-generator.service has an [Install] section and is preset
to true, so not listing it in the scriptlets was a visible bug.
There's the additional caveat that systemd-network-generator.service is coowned
by two packages. The current system does not have a way of handling this
properly, because unit enablement is tied to the package install state. Let's
just call the scriptlet for this unit twice for now. I think that's not going
to cause any real problem.
I noticed that systemd-sysusers creates accounts with /usr/bin/nologin.
On merged systems is fine, but would not work for systems where
/usr/sbin is still a separate directory and /usr/bin/nologin does not
exist. This problem occurs because the meson configuration script discovers
the location using $PATH, which on recent builds results in /usr/bin always.
Just specify all the paths so that we don't depend on the presence and
order of paths in $PATH.
If we download the main branch from github by defining %branch, the
source tarball will be named main.tar.gz, so let's make the tarball
pattern more generic to match.
Primarily, this allows us to get rid of dist-git-source which makes
the fmf stuff reusable for CentOS Stream in gitlab which we'd like to
make use of in the systemd backport in the Hyperscale SIG.
Also in general making the integration touch points with Fedora CI
and the other systems as small as possible seems like a good thing.
And in non-Fedora builds, undo the neutering of sysusers macros.
Downstreams like CentosStream did not go through the same changes
as Fedora but they may use packages built from the rawhide branch.
We had a bunch of Obsolets on self. This is useful when a subpackage
is split out to make it optional, and we want to install both the
original subpackage and the subpackage on ugprades. If both new
subpackages have Obsoletes on the old name, dnf will install both. But
we don't need to keep this infinitely, it's mostly useful for the
duration of a single stable release.
Apparatenly, those Obsoletes cause problems with downgrades.
The most recently added case is for the split of systemd-sysusers. But
we have an alternative mechanism in place: systemd Requires
/usr/bin/systemd-sysusers, and this path is provided by systemd-sysusers
and systemd-standalone-sysusers, with a bias towards systemd-sysusers.
So we should be able to drop the self-Obsoletes without a change in
functionality.
Also, drop some old Provides where 'dnf repoquery' indicates it is not
used by anything. Actually, only 'timedatex'. All the other ones are
used by one spec or another.
We don't need 1.5.0 to avoid the libbpf crash, the latest libbpf 1.4
patch release (1.4.7) also has the necessary fixes, so relax the
requirement a little to allow builds on Fedora 41 to succeed.
In CI builds we have %version that it smaller than 257.3-4 when the split
happened, and this causes problems when the packages are installed:
Failed to resolve the transaction:
Problem: package
systemd-sysusers-257-1.20250225060108317145.pr36507.1659.g4635c37946.fc43.x86_64
from @commandline
obsoletes
systemd < 257.3-4 provided by
systemd-257-1.20250225060108317145.pr36507.1659.g4635c37946.fc43.x86_64
from @commandline
- conflicting requests
I'm not sure if we even need the self-Obsoletes. We have a Requires and
Recommends in the main systemd package that will cause on of the providers of
/usr/bin/systemd-sysusers to be installed, and the non-standalone version is
preferred. But it's possible that if recommends are disabled, the
non-standalone package could be installed for some reason. So let's keep the
self-Obsoletes for now.
Another caveat is that it's not clear if v-string comparisons require %[] as a
wrapper. Some chat in #fedora-devel suggested that that's the case, but things
seem to work without it.
None of the systemd git tags have tildes in them, so there's no need
to use version_no_tilde for these.
This is another change to make packit work as the archive it sets up
for us based on the systemd upstream packit config file does have a
tilde in its name which then makes %prep fail as we transform the tilde
to a hyphen and then fail to find the systemd source directory.
"""
+ /usr/lib/rpm/rpmuncompress -x /builddir/build/SOURCES/systemd-258~devel.tar.gz
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd systemd-258-devel
/var/tmp/rpm-tmp.gw7KSw: line 42: cd: systemd-258-devel: No such file or directory
"""
Previously, /usr/bin/systemd-sysusers was provided by both systemd and
systemd-standalone-sysusers, creating a file conflict, and the packages
declared Conflicts. This changed when systemd-sysusers was split out to a
separate subpackage. So we don't need the Conflicts and can allow a "cross
installation" of systemd-sysusers-standalone and and the other "normal"
systemd subpackages.
This should solve https://bugzilla.redhat.com/show_bug.cgi?id=2344322 without
requiring changes in the container definitions. (Though those changes probably
should be made anyway. If we end up installing systemd, we probably want to use
shared systemd-sysusers, to avoid wasting space.)
... (rhbz#2344322)
rpm-libs has Requires:/usr/bin/systemd-sysusers.
We split split out /usr/bin/systemd-sysusers (the normal version) to a
subpackage, and the shared library
/usr/lib64/systemd/libsystemd-shared-257.2-14.fc42.so to a second subpackage.
(In preparation for maybe making further splits later.)
systemd-sysusers+libsystemd-shared.so is 4.8MB, but libsystemd-shared.so also
pulls in a bunch of libraries. We'll find out what the actual change in
installation footprint (compared to systemd-standalone-sysusers) really is when
we build some images with the new split.
- systemd-ac-power is moved to systemd-udev
- portablectl and importctl are moved to systemd-container (rhbz#2345551)
ac-power clearly is only useful for real hardware. portablectl
and importctl are niche tools that don't need to be in the main package
(even though they could theoretically be used not for containers).
We are doing self-signing, so don't tag the EFI binaries as if
they were Fedora's, since they are not. Set upstream-specific
tags, that are the same for all distros built on OBS..
[skip changelog]
Let's add a tmt plan to read the upstream fmf metadata which contains
a single test to run the upstream integration tests.
To make this work, we also add a downstream patch with some fmf test
script fixes that landed after 257.2 was released.
We request virtualization support so we can run qemu based integration
tests in qemu with KVM.
On OBS the https://github.com/openSUSE/pesign-obs-integration
package is the way to get binaries signed. Build depend on it,
and call its hook.
Also rename and change the description and provides of the package,
given it is signed.
[skip changelog]
In the past, we used patch numbers to skip some patches in upstream CI
builds. The upstream bcond is now used for this instead, so we can
drop the numbering to make it easier to add an remove patches.
[skip changelog]
The test fails because of the same reason as the installability test,
it tries to install every subpackage which fails because the standalone
subpackages conflict with all the other packages.
Given there's no owner for the test, nobody looks at or seems interested
in the results, STI itself will likely be deprecated soon
(https://fedoraproject.org/wiki/Changes/DeprecateSTI) and systemd's
upstream integration tests will soon support checking for AVC denials
(https://github.com/systemd/systemd/pull/35921), let's remove the STI test.
- Fixes for assertion crashes and memory access issues in pid1 and
systemd-machined, and other fixes for systemd-repart, systemd-resolved,
systemd-stdio-bridge, systemctl, journalctl, sd-device, hibernation,
and the hardware database.
The version substitution system is not able to fully subst
the current Version field due to the inline use of macros, so you end up with like:
257-123-gabcd257.1
instead of:
257-123-gabcd
I.e., the hard-coded 257.1 gets appended to the OBS-specified version.
If it was simply hardcoded as 257.1 it would work, but the inline
macros throw it off.
[skip changelog]
OBS does not support files with names starting with a dot.
https://fedoraproject.org/wiki/How_to_filter_libabigail_reports does
not make it really clear if the file can renamed. (The first part of
the paragraph implies a positive answer, the second is unclear.)
Let's see how this goes.
Let's use the %upstream macro to gate patches which are backports of
upstream instead of relying on patch numbers. We'll build with %upstream
defined in packit so that patches which should not be applied on upstream
builds are skipped.
Building with %upstream doesn't necessarily imply we want a developer
build, so let's always build in release mode. If needed
%meson_extra_configure_options can be used to override this and build
in developer mode after all.
From the 257 release notes:
* The --purge switch of systemd-tmpfiles (which was added in v256) has
been reworked: it will now only apply to tmpfiles.d/ lines marked
with the new "$" flag. This is an incompatible change, and means any
tmpfiles.d/ files which shall be used together with --purge need to
be updated accordingly. This change has been made to make it harder
to accidentally delete too many files when using --purge incorrectly.
The feature is now sufficiently hard to misuse that we can drop the patch.
- A bunch of small fixes in various components: systemd itself, systemd-cryptenroll,
sd-varlink, sd-boot, documentation, tests
- Includes an update of the hardware database
The build is slow anyway, so the difference shouldn't matter. But more
tests is better. The build logs show that slow tests were disabled.
Inspired by https://github.com/systemd/systemd/issues/34471.
Our mkosi.conf.d/10-centos-fedora/mkosi.prepare script tries to install
the soft dependencies too.
The build fails in centos 9 and 10:
Error: Unable to find a match: qemu-device-display-virtio-gpu
qemu-device-display-virtio-vga
[skip changelog]
... (rhbz#2328723)
The files systemd-networkd-generator generates are read by udev (.link files)
and by networkd (.netdev, .netdev files). We can't move it to systemd-networkd
subpackage only, because that would potentially break the corner case of people
having systemd-udev installed and using the generator, but not systemd-networkd.
And there is no dependency from systemd-networkd to systemd-udev. I think this
is correct, because networkd can be used in containers without udev. But the
generator is not useful without either of those two daemons, so let's move
it to make the core package a bit lighter.
Anything we put in a %postun script needs two releases of the rpm
before it is invoked. The reason for using %postun to restart services
is because it runs after the old version has been removed so we can be
sure all remaining dropins and such files from the old version have been
removed. %posttrans gives us the same guarantee but the %posttrans of the
new version will run on install and upgrade which means the changes will
be applied immediately instead of having to release twice before the changes
take effect.
We define the systemd_posttrans_with_restart macro in the spec because we
can't use the upstream one as we ship it ourselves.
This drastically simplifier reexecs of user managers by using
systemctl reload to do a user manager reexec. This means we don't
need systemd-run, a pam session or systemd-stdio-bridge anymore to
do a user manager reexec and all job tracking is handled by pid 1
instead of bash.
Even on non-uefi architectures, ukify can be used to build UKIs for
UEFI images. For example, mkosi can use it to build UKIs on s390x.
To enable this use case, let's always build ukify, but with a conditional
dependency on systemd-boot only on arches that support UEFI.
We still want the Fedora systemd-user pam config when building with
--noprep so let's install the pam config file using a regular source
instead of patching the one provided by systemd.
rpm will imply --noprep when using --build-in-place in rpm 4.20 and
we're switching the mkosi rpm builds to use --noprep as well on older
rpm versions. This means we don't need to gate out patch applications
anymore with the %upstream macro.
rpmautospec doesn't like the merge: "unresolvable merge".
To avoid the issue, re-add the changelog file. Also, let's drop the
stuff that is only specific to EPEL, since this branch is primarily
for rawhide.
We had a *lot* of breakage caused by this change internally so let's
make the spec a little more conservative by only applying the shorter
shutdown timer for Fedora builds.
meson on CentOS Stream 9 is too old to properly handle symlinks
when installing test data so the systemd meson build script uses
rsync instead. Let's add the requisite build requires to make that
work.
For our nightly systemd build for the CentOS Hyperscale build it
would be very useful to download sources straight from git main on
github so let's allow defining the "branch" macro to do just that.
In a minimal installation, we pull in coreutils via dependencies.
coreutils-single is much smaller, so bias the resolved towards that.
$ sudo dnf5 install --releasever=rawhide --installroot=/var/tmp/inst1 --use-host-config \
/var/lib/mock/fedora-rawhide-x86_64/result/systemd-standalone-{repart,shutdown,sysusers,tmpfiles}-256.2-5*rpm
After this operation 57 MiB will be used (install 57 MiB, remove 0 B).
$ sudo dnf5 install --releasever=rawhide --installroot=/var/tmp/inst1 --use-host-config \
/var/lib/mock/fedora-rawhide-x86_64/result/systemd-standalone-{repart,shutdown,sysusers,tmpfiles}-256.2-6*rpm
After this operation 41 MiB will be used (install 41 MiB, remove 0 B).
For the CentOS Stream Hyperscale SIG we backport a newer version of
dracut and still want the Conflicts to apply so let's conditionalize
the check on the %upstream macro since we only need it for upstream
builds anyway.
Make sure on centos stream 10 we also conflict with dracut 060-2
and that on centos stream 9 so that the spec can still be used to
build systemd rpms for centos stream 9 upstream in systemd CI that
can be installed on centos stream 9.
(dracut is pulled in as a required dependency of kernel-core so we
can't just not install it on centos stream 9 unfortunately).
Let's make sure we use the vmlinux.h from kernel-devel or none at
all. This makes sure the systemd BPF programs are built against a
known version of vmlinux.h and we don't depend on /sys being available
to generate vmlinux.h ourselves.
Use rpmdev-vercmp to select vmlinux.h from the latest kernel.
This reverts commit a76669ee22.
People create /usr-only images by making an installation and only picking
up /usr from it. In that case, the snippet is needed to re-recreate /home
on the rootfs.
In systemd upstream CI, we only have the rawhide branch, because we import
dist-git via git submodule. But we want to build systemd on F40 too from this
branch, so conditionally ressurect the patch to make that work. This partially
reverts 69d6e44695.
[skip changelog]
I think this is a bug in rpmautospec. The release tag is always generated
as "1". Before this is investigated and fixed, just set it manually.
[skip changelog]
There were a bunch of other commits incl. bugfixes that mean that it'd
make sense to update to the latest snapshot, but I chose not to do that to
avoid introducing new issues. We'll get -rc2 soon enough anyway.
`systemd-ukify` requires `/usr/lib/systemd/boot/efi/{addonx64,linuxx64}.efi.stub` to work properly, e.g.
```
Traceback (most recent call last):
File "/usr/bin/ukify", line 1660, in <module>
main()
File "/usr/bin/ukify", line 1648, in main
check_inputs(opts)
File "/usr/bin/ukify", line 390, in check_inputs
value.open().close()
File "/usr/lib64/python3.9/pathlib.py", line 1252, in open
return io.open(self, mode, buffering, encoding, errors, newline,
File "/usr/lib64/python3.9/pathlib.py", line 1120, in _opener
return self._accessor.open(self, flags, mode)
FileNotFoundError: [Errno 2] No such file or directory: '/usr/lib/systemd/boot/efi/addonx64.efi.stub'
```
`/usr/lib/systemd/boot/efi/{addonx64,linuxx64}.efi.stub` are now contained in `systemd-boot-unsigned` sub-package so adding a dependency on it seems like the easiest solution.
Originally reported by: Vitaly Kuznetsov <vkuznets@redhat.com> in https://issues.redhat.com/browse/RHEL-33990
Signed-off-by: Jan Macku <jamacku@redhat.com>
I think this is a bug in rpmautospec. The release tag is always generated
as "1". Before this is investigated and fixed, just set it manually.
[skip changelog]
https://github.com/systemd/systemd/issues/32508#issuecomment-2079991745
> The new systemd package does the reexec in %postun, but the old one does it in
> %post. So if we install the new one, we don't do any reexec (since %postun
> doesn't run in this case), but once we remove the old one we also don't do any
> reexec, because in this case there's no reexec in %postun:
> # dnf upgrade --rpmverbosity=debug ./*.rpm |& tee log.txt
> ...
> : %postun(systemd-255.5-1.fc41.x86_64): scriptlet start
> D: %postun(systemd-255.5-1.fc41.x86_64): execv(/bin/sh) pid 2649
> D: Plugin: calling hook scriptlet_fork_post in selinux plugin
> D: setexecfilecon: (/bin/sh, rpm_script_t)
> + '[' 1 -eq 1 ']'
> + '[' -w /var ']'
> + journalctl --update-catalog
> + systemd-tmpfiles --create
