Comments
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
2 days 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.
Sigh, so, latest problem: gnome-shell is crashing on aarch64 due to an undefined symbol:
Feb 05 10:34:26 fedora gnome-shell[1221]: JS ERROR: GIRepository.InvokeError: Could not locate meta_backend_set_keymap_layout_group_async: 'meta_backend_set_keymap_layout_group_async': /lib64/libmutter-18.so.0: undefined symbol: meta_backend_set_keymap_layout_group_async
_promisify@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:468:9
@resource:///org/gnome/shell/ui/environment.js:37:5
Feb 05 10:34:26 fedora gnome-shell[1221]: Execution of main.js threw exception: Module resource:///org/gnome/shell/ui/init.js threw an exception
no idea as of yet why it's undefined on aarch64 only (apparently). Can't debug ATM because Koji is down for branching.
Fix for the aarch64 gdm issue building on this side tag as https://koji.fedoraproject.org/koji/taskinfo?taskID=141935681 . It'll be pulled in whenever @xhorak is ready to re-generate the update with other new builds.
yeah, confirmed. I've filed an upstream issue for now. Can poke more on this tomorrow.
Aha. With gdm debug logging I'm seeing this:
Feb 04 21:06:22 ibm-p8-kvm-03-guest-02.virt.pnr.lab.eng.rdu2.redhat.com gdm[1362]: Gdm: GdmLocalDisplayFactory: Checking if udev has settled enough to support graphics.
Feb 04 21:06:22 ibm-p8-kvm-03-guest-02.virt.pnr.lab.eng.rdu2.redhat.com gdm[1362]: Gdm: GdmLocalDisplayFactory: Found secondary PCI graphics adapter, not proceeding yet.
Feb 04 21:06:22 ibm-p8-kvm-03-guest-02.virt.pnr.lab.eng.rdu2.redhat.com gdm[1362]: Gdm: GdmLocalDisplayFactory: Found secondary PCI graphics adapter, not proceeding yet.
Feb 04 21:06:22 ibm-p8-kvm-03-guest-02.virt.pnr.lab.eng.rdu2.redhat.com gdm[1362]: Gdm: GdmLocalDisplayFactory: udev has not settled enough for graphics.
Feb 04 21:06:22 ibm-p8-kvm-03-guest-02.virt.pnr.lab.eng.rdu2.redhat.com gdm[1362]: Gdm: GdmLocalDisplayFactory: udev is still settling, so not creating display yet
so I'm suspecting this is gonna be https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/343 . I'm just re-confirming ATM (I've only seen this after a 'systemctl restart gdm.service' so far, confirming now that it happens even on the normal automatic start of gdm).
Missing a dependent rebuild: