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
- Many different small fixes: systemd itself, systemd-networkd,
systemd-journal-remote, compilation fixes for newer kernels and
clang, systemd-homed, systemd-resolved, ukify, systemd-tmpfiles,
various other.
It was removed upstream in 711169905e75617eabf3934273aa37dac02c6458,
except for one call in test/test-functions, but we don't run those
during package build.
[skip changelog]
Most systemd tools run from scriptlets need libsystemd-shared-X.so (from
systemd package), which contains version and release in it's name.
Therefore, the same version of systemd package must be already installed
when they run.
Resolves: #2282821
When backporting the latest changes to CentOS Hyperscale reviewers
were confused by using %version and %release to define "Version" and
"Release" which are supposed to specify the values for %version and
%release. Let's use different macros to make it more clear that these
are supposed to be set by users building the rpm and add a comment
to explain why we do this.
Let's allow overriding the version and release by specifying the
corresponding macros on the rpmbuild command line. This allows us
to specify a custom version and release when doing upstream builds.
When building in upstream mode, the release doesn't really have any
meaning so let's stop passing it as part of the version-tag and
shared-library-tag arguments.
This also makes it possible to make the release a timestamp so that
each package built from upstream is guaranteed to be newer. If we
pass the release to meson via version-tag and shared-library-tag and
the release changes every build, we end up having constant rebuilds
of various targets in meson that depend on the version.
The second argument now specifies the version tag version so let's
adapt. Because the script now supports running without any arguments
at all, let's just do that.
The output now also doesn't use any hyphens anymore so we get rid
of the sed transformation as well;
Currently, the inplace macro only influences whether we use
tools/meson-vcs-tag.sh to figure out the version instead of using
the predefined one. But doing an inplace build shouldn't really
affect the version, since it's possible to do an inplace builds that's
not a git main upstream build, so the two concepts are disjoint.
Instead, let's replace the "inplace" macro with an "upstream" macro
to indicate that we're building from systemd git upstream. Aside from
influencing the version, this also disables various patches and adds
a libarchive dependency that was added upstream recently but isn't in
an official release yet.
There's a bug in dnf5 where it always downloads filelists metadata
even for file dependencies that are in the "allowed" paths, such as
/usr/bin/getfacl. Let's use the package names for now to avoid
downloading the filelists metadata unnecessarily.
See https://bugzilla.redhat.com/show_bug.cgi?id=2263771
/usr/bin/systemd-repart is in systemd-udev, so this Conflicts/Provides
combo was misplaced. (For the Conflicts, this is actually not a real
issue, because systemd-udev Requires systemd, so transitively, the
conflicting packages could not be installed. But for Provides, the
issue is real, because systemd by itself does _not_ provide the
binary.)
This was noticed by rpmdeplint CI job:
Undeclared file conflicts:
systemd-standalone-repart-255.3-1.fc40.x86_64 provides /usr/bin/systemd-repart which is also provided by systemd-udev-255.2-2.fc40.x86_64
- A bunch of various fixes for memory and behaviour, in many different
components (bootctl, systemd, udev, systemd-networkd, systemd-homed,
systemd-logind, systemd-resolve, systemd-repart, systemd-analyze,
systemd-dissect, systemd-boot, pam modules, systemd-storagetm,
systemd-journal-remote, kernel-install)
- Improved detection of virtualization (Google Compute Engine, Apple Virt)
- Updates for shell completions and docs
- An update for hardware database
Our config files in /etc/ were marked as %config(noreplace). This means that the
would not be replaced on upgraded if local modifications have been made. But
when we moved them to /usr/lib, they would be be renamed to .rpmsave, if they
had local modifications. This is not what I expected, but what rpm apparently
does. So we need to add them as %ghost to prevent the removal. This is probably
for the better anyway.
... (e.g. /etc/systemd/system.conf → /usr/lib/systemd/systemd.conf).
Both config file locations were already supported, and the files
installed in /etc/ were "empty" (i.e. they had only comments and section
headers). The move does not change the configuration, but just makes
/etc more empty by default. See
6495361c7d for more
discussion and details.
