Comments
See discussion on the Rawhide update. SELinux issues.
This breaks the deps of python3-apt:
Dependencies of other packages that would be BROKEN by the tested packages:
package: python3-apt-2.3.0-12.fc42.x86_64 from https://kojipkgs.fedoraproject.org/repos/f42-build/latest/x86_64
libapt-pkg.so.6.0()(64bit)
libapt-pkg.so.6.0(APTPKG_6.0)(64bit)
bumping sonames in stable releases is discouraged, but there should at least be a rebuild of the dep as part of this update.
This breaks the deps of python3-apt:
Dependencies of other packages that would be BROKEN by the tested packages:
package: python3-apt-2.3.0-16.fc43.x86_64 from https://kojipkgs.fedoraproject.org/repos/f43-build/latest/x86_64
libapt-pkg.so.6.0()(64bit)
libapt-pkg.so.6.0(APTPKG_6.0)(64bit)
bumping sonames in stable releases is discouraged, but there should at least be a rebuild of the dep as part of this update.
Missing a dependent rebuild:
Dependencies of other packages that would be BROKEN by the tested packages:
package: perl-Alien-pkgconf-0.21-2.fc44.x86_64 from https://kojipkgs.fedoraproject.org/repos/f45-build/latest/x86_64
libpkgconf-devel(x86-64) = 2.3.0
Missing a dependent rebuild:
Dependencies of other packages that would be BROKEN by the tested packages:
package: perl-Alien-pkgconf-0.21-2.fc44.x86_64 from https://kojipkgs.fedoraproject.org/repos/f44-build/latest/x86_64
libpkgconf-devel(x86-64) = 2.3.0
It looks like this is crashing on startup on KDE (where akonadi uses it) on F44 and Rawhide, so I'm -1ing this update and the F42 one to ensure we don't push the bug there.
It looks like this is crashing on startup on KDE (where akonadi uses it) on F44 and Rawhide, so I'm -1ing this update and the F42 one to ensure we don't push the bug there.
adamwill
commented & provided feedback
on kernel-6.20.0-0.rc0.260212g37a93dd5c49b5.4.fc45
3 weeks ago
This is failing tests because of a version problem. The previous update was kernel-6.20.0-0.rc0.260212gc22e26bd0906e.3.fc45 . You didn't bump the 0 before rc0, or rc0 itself, and this was built on the same day, so the date component is the same. That means we wind up just comparing the git commit, and it looks like 'c' is considered newer than '3', so this is 'older' than the current stable update.
Either fix the NVR (bump the initial 0?) or do another snapshot tomorrow, I guess.
aha, well that'd certainly explain the test failures, I guess. Didn't know bind depended on libuv!
I'm curious: what's wrong with it? In openQA it seems the FreeIPA replication tests fail consistently, but that seems a bit odd. I was assuming it must be a blip as I thought libuv likely had nothing to do with FreeIPA replication, but it was a very consistent result, failed five times across prod and stg...
I've re-run the tests now, let's see what happens.
So the test failures here are to do with the lua change, I think. It seems like what happens is:
- We set up a buildroot repo and a side repo with this rpm-6.0.1-4.fc45 build in it, and update the system; it correctly updates to this version of rpm and lua-libs 5.5.0-1.fc45
- Later in the test we do
dnf -y group install base-xand, for some reason, that decides to downgrade lua-libs to 5.4.8-5.fc44 and hence rpm to 6.0.1-3.fc45 - The 'check no package from the update has an older version than what's in the update install' step of the test fails because rpm was downgraded
The tricky bit is why does dnf decide to downgrade lua-libs. I suspect it's because something in base-x requires lua 5.4 (probably liblua-5.4.so()(64bit)). dnf has two choices how to solve that:
- Keep lua-libs-5.5.0 and rpm-6.0.1-4, install lua5.4-libs-5.5.0
- Downgrade lua-libs to 5.4.8-5 (which it can still find in the 'rawhide' repo, currently, as there's been no compose since it was pushed stable) and rpm to 6.0.1-3
...and it picks 2) because it involves installing fewer packages, which dnf's (well, libsolv's) heuristics tend to like, I think.
If I'm right about that it's probably not a genuine problem, because once there's a new Rawhide compose and the older lua disappears from the rawhide repo, option 2 won't be available and it'll have to do option 1. So I think the thing to do would be to re-run the tests after the next Rawhide compose is done and synced, and see what happens.
pygobject3 was rebuilt separately with the tuned fix, so removing the older build from this update.
oh, we have f44-backgrounds, but this didn't update the deps of the package from f43-backgrounds to f44-backgrounds so it doesn't work.
I guess we also need f44-backgrounds.
This seems to be missing gnome-session:
Dependency problems in the tested packages themselves:
package: gdm-1:50~beta-1.fc45.x86_64 from file:///mnt/update_repo
gnome-session >= 50~alpha
gnome-session-wayland-session >= 50~alpha
This got pushed because critpath generation for F44 is broken so it wasn't considered critpath any more so it wasn't gated :| we'll have to hope it works OK. openQA tests on 44 are a bit busted right now, I will try to fix things up in the morning and re-run tests to find out where we stand.
OK, we figured that out too. The fix is pushed and ready to build once branching is done, at least if we can figure out any signing issues or whatever.
We'll have to rebuild everything for Rawhide too as a separate update, of course.
OK, we (mainly @catanzaro) figured that out. Koji is down for branching ATM. Once it's back up we need to backport that, and also do an xdg-desktop-portal-gnome build with the crash fix in it - either backport the subproject update somehow (additional source tarball, I guess) or get a 50.beta release of x-d-p-g.
"Do not allow VT switching by default" is a problem. gnome-kiosk is used in the Fedora installer and we expect to be able to switch VTs there. This causes the test failures (openQA needs to be able to switch to a VT during install).
We either need to revert this, or if (as 'by default' implies) it's configurable, have anaconda do whatever's necessary to enable it.