... (rhbz#2240828)
We currently have grubby-8.40-72.fc39 and sdubby-1.0-3.fc39.
systemd had 'Conflicts: grubby < 8.40-72', which is satisfied by grubby.
But sdubby has 'Provides: grubby' (with no version), which prevented
installation:
$ sudo rpm -i ./sdubby-1.0-3.fc39.noarch.rpm
error: Failed dependencies:
grubby < 8.40-72 conflicts with (installed) systemd-udev-254.2-7.fc39.x86_64
The rpm docs don't actually say what the meaning of the 'if' is:
is it only satisfied by actual package names, or also by Provides. But
experiments suggest that Provides are not used. The rich dependency seems
to avoid the issue.
This reverts commit 8eea43e714.
Fedora already ships 'disable systemd-boot-update.service' in
/usr/lib/systemd/system-preset/90-default.preset, so we don't need
this.
[skip changelog]
The macro expansions would only work when compiled with a recent version of
systemd. We don't want to create a dependency loop like this, let's just expand
the string manually.
Also backport the patch adding %systemd_postun_with_reload and
%systemd_user_postun_with_reload so a FPC documentation change can be filed.
Let's make sure we clean up after ourselves. We have to remove
the generated timeout user config file, the file list files and the
generated .lang file.
... (rhbz#2217997)
systemd-homed.service and systemd-portabled.service are in
systemd-udev but the scriptlet was attached to main subpackage, so it
wouldn't work because the unit file wasn't installed yet when it was
invoked. systemd-pstore.service and remote-cryptsetup.target were
forgotten, so they wouldn't get enabled on installation.
Rpm >= 4.19 has native sysusers integration and generates similar
user() and group() provides but encodes additional information into
them, information that is required for the rpm integration to work.
Besides additional data, one noteworthy difference in the rpm generated
provides is there are no provides generated for m(ember) directives.
This is because users and groups possibly created by that directive are
a too implicit for dependency resolution and install ordering purposes
in the case where the user/group is actually owned by some other package.
... (rhbz#2177722)
Oomd was killing a login session (user-*.slice/session-*.scope).
Quoting https://bugzilla.redhat.com/show_bug.cgi?id=2177722#c21:
> In F37 and prior the config was killing based on swap and pressure
> on user-*.slice/user@.service. In 7665e1796f
> it was changed to pressure only on system.slice and all slices under
> user.slice. The relevant point here is that this change now includes
> user-*.slice/session-*.scope which is the critical session bits
> you're seeing killed here.
>
> That session scope should be omitted. The config that I intended
> with the initial PR was for all slices under
> user.slice/user-*.slice/user@.service to be monitored, not for all
> slices under user.slice.
With the file removed:
$ oomctl | rg Path | sort
Path: /system.slice
Path: /user.slice/user-1000.slice/user@1000.service/app.slice
Path: /user.slice/user-1000.slice/user@1000.service/session.slice
See https://github.com/systemd/systemd/pull/26641.
This will allow upstream pull request (and the main branch after the pull
request has been merged) to be built with the new code. This doesn't do
anything for official rpm builds until the new code is part of the sources.
[skip changelog]
