stable

systemd-245.6-2.fc32

FEDORA-2020-dd43dd05b1 created by zbyszek 3 years ago for Fedora 32

Updates to latest stable version.

No need to log out or reboot.

How to install

Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:

sudo dnf upgrade --refresh --advisory=FEDORA-2020-dd43dd05b1

This update has been submitted for testing by zbyszek.

3 years ago

This update's test gating status has been changed to 'waiting'.

3 years ago

This update's test gating status has been changed to 'ignored'.

3 years ago
User Icon mpreston commented & provided feedback 3 years ago
karma

also fixes bug 1842067

zbyszek edited this update.

3 years ago
User Icon adamwill commented & provided feedback 3 years ago

openQA failure here needs a bit of investigation. It's probably some kind of bug somewhere, not sure if it's an issue with the package deps or with dnf. I'm going to disable autopush on this update so it doesn't get autopushed tonight, and will look into it tomorrow if no-one else beats me to it.

adamwill edited this update.

3 years ago
User Icon zbyszek commented & provided feedback 3 years ago

Problem: package systemd-udev-245.6-1-fc32.x86_64 requires systemd(x86-64) = 245.6-1-fc32.x86_64, but none of the providers can be installed - both package systemd-245.4-1-fc32.x86_64 and systemd-udev-245.6-1-fc32.x86_64 obsolete u2f-hidraw-policy < 1.0.2-40 ...

Hmm, Obsoletes was moved between subpackages because of https://bugzilla.redhat.com/show_bug.cgi?id=1823002#c2. But this change was done a while back. I'm not sure why it suddenly is a problem. And even if it is actually a problem.

User Icon zbyszek commented & provided feedback 3 years ago

Problem: package systemd-udev-245.6-1-fc32.x86_64 requires systemd(x86-64) = 245.6-1-fc32.x86_64, but none of the providers can be installed - both package systemd-245.4-1-fc32.x86_64 and systemd-udev-245.6-1-fc32.x86_64 obsolete u2f-hidraw-policy < 1.0.2-40 ...

Hmm, Obsoletes was moved between subpackages because of https://bugzilla.redhat.com/show_bug.cgi?id=1823002#c2. But this change was done a while back. I'm not sure why it suddenly is a problem. And even if it is actually a problem.

This update has been pushed to testing.

3 years ago
User Icon atim provided feedback 3 years ago
karma

This update can be pushed to stable now if the maintainer wishes

3 years ago
User Icon adamwill commented & provided feedback 3 years ago

The change was made a while back, but there's been no update in the interim. The last systemd to hit Bodhi was systemd-245.4-1.fc32, which is the build that's in the frozen stable F32 repo, the one this update is conflicting with. No other systemd update has been issued for F32 since.

I think the problem is that dnf can "see" both systemd-245.4-1.fc32 and systemd-udev-245.6-1.fc32 - the former in the fedora repo, the latter in updates-testing (or in the openQA test, in the repo called advisory, which is where we put the update under test). If the update was pushed stable this would still be the case - systemd-245.4-1.fc32 would not disappear, it would still be in the fedora repo and still visible to dnf. I believe dnf's behaviour for obsoletes is "greedy": it will try to pull in every different package it can see that obsoletes an installed package. So it tries to pull in the older systemd as well as the newer systemd-udev, and that's obviously problematic.

We don't see this problem in Rawhide because we don't have this "two different builds available in different repos" wrinkle there. We always only have the one main repo for Rawhide, dnf only sees one build of systemd at a time there.

I'm going to test if having the newer systemd-udev explicitly conflict with or obsolete the older systemd will help here...

User Icon adamwill commented & provided feedback 3 years ago

OK, so I played around with this locally, using a couple of test packages, foo and bar. I built a foo-1-1 which is just a completely empty package. bar has bar and bar-udev binary packages (also completely empty), with bar-udev requiring bar = %{version}-%{release}.

I built a bar-1-1 where the bar subpackage obsoletes foo < 2-1 and provides foo = %{version}-%{release}, and a bar-1-2 where the obsoletes and provides are in the bar-udev subpackage. I put those packages in a side repo and ran dnf update, and it reproduces the problem: dnf refuses to do anything because it can't install both bar-1-1 and bar-udev-1-2.

I played around with some possible solutions. An explicit Conflicts: bar < 1-2 in bar-udev-1-2 doesn't help. But an explicit Obsoletes: bar < 1-2 in bar-udev-1-2 does help: it makes the upgrade work in the intended way, by only installing bar-udev-1-2.

I was worried it would cause a problem if you have bar-1-1 but not bar-udev-1-1 installed - I was worried it would pull in bar-udev-1-2 on update. But it doesn't seem to:

[root@adam noarch]# dnf --disablerepo=* install /home/adamw/local/repo/x86_64/bar-1-1.noarch.rpm ... Installed: bar-1-1.noarch

Complete!
[root@adam noarch]# dnf --disablerepo=* --enablerepo=side --refresh update
Private side repo                                                                     2.9 MB/s | 3.0 kB     00:00    
Dependencies resolved.
======================================================================================================================
 Package                   Architecture                 Version                      Repository                  Size
======================================================================================================================
Upgrading:
 bar                       noarch                       1-2                          side                       6.1 k

Transaction Summary
======================================================================================================================
Upgrade  1 Package

Total size: 6.1 k

so I think this is a plausible solution: adding Obsoletes: systemd < 245.6-1 to the systemd-udev subpackage. Can you see any other possible issues with that? If not, do you mind if I try it? Thanks!

User Icon adamwill commented & provided feedback 3 years ago

I did a scratch build with the proposed change and tested it. It passed.

User Icon bojan commented & provided feedback 3 years ago
karma

Worked for me on two machines, so I'll give +1, notwithstanding packaging problems.

User Icon adamwill commented & provided feedback 3 years ago
karma

the bug affects upgrades from F31. working on update within F32 doesn't mean the bug isn't a problem. Since I'm fairly clear on what's going on now and it does seem like a reason not to push this update stable as-is, gonna give it -1 now.

Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.

3 years ago
User Icon renault commented & provided feedback 3 years ago
karma

Works fine, no regressions found

zbyszek edited this update.

New build(s):

  • systemd-245.6-2.fc32

Removed build(s):

  • systemd-245.6-1.fc32

Karma has been reset.

3 years ago

This update has been submitted for testing by zbyszek.

3 years ago
User Icon zbyszek commented & provided feedback 3 years ago

The only difference is the Obsoletes change, which should only matter for upgrades from F31.

User Icon adamwill commented & provided feedback 3 years ago
karma

indeed openQA tests are passing now, looking good.

This update has been pushed to testing.

3 years ago
User Icon atim commented & provided feedback 3 years ago
karma

Seems all OK.

User Icon atim commented & provided feedback 3 years ago
karma

Seems all OK.

This update can be pushed to stable now if the maintainer wishes

3 years ago
User Icon danniel commented & provided feedback 3 years ago
karma

Works

User Icon pwalter commented & provided feedback 3 years ago
karma

Works

This update has been submitted for stable by zbyszek.

3 years ago

This update has been pushed to stable.

3 years ago

Please login to add feedback.

Metadata
Type
bugfix
Severity
medium
Karma
4
Signed
Content Type
RPM
Test Gating
Settings
Unstable by Karma
-3
Stable by Karma
disabled
Stable by Time
disabled
Dates
submitted
3 years ago
in testing
3 years ago
in stable
3 years ago
modified
3 years ago
BZ#1800875 systemctl --no-wall asks for permissions to set wall message
0
0
BZ#1815412 Login to Gnome with AD fully qualified user name fails after upgrade to F32
0
0
BZ#1815605 resolvctl does not update /etc/resolv.conf
0
0
BZ#1819313 [DOC] journalctl --no-hostname option leaks hostname
0
0
BZ#1827467 systemd-nspawn -U changes owner of host's /sys/fs/selinux
0
0
BZ#1842067 systemd: Bad user or group name when it contains a dot
0
0

Automated Test Results

Test Cases

0 0 Test Case Services start
0 0 Test Case base service manipulation
0 0 Test Case base services start
0 0 Test Case base shutdown/reboot
0 0 Test Case User:Tablepc/Draft testcase reboot