This is missing a whole ton of dependent rebuilds:
Dependencies of other packages that would be BROKEN by the tested packages:
package: baresip-vp8-4.5.0-1.fc45.x86_64 from https://kojipkgs.fedoraproject.org/repos/f45-build/latest/x86_64
libvpx.so.9()(64bit)
package: baresip-vp9-4.5.0-1.fc45.x86_64 from https://kojipkgs.fedoraproject.org/repos/f45-build/latest/x86_64
libvpx.so.9()(64bit)
package: firefox-148.0-1.fc45.x86_64 from https://kojipkgs.fedoraproject.org/repos/f45-build/latest/x86_64
libvpx.so.9()(64bit)
package: godot3-3.6.2-1.fc45.x86_64 from https://kojipkgs.fedoraproject.org/repos/f45-build/latest/x86_64
libvpx.so.9()(64bit)
package: godot3-headless-3.6.2-1.fc45.x86_64 from https://kojipkgs.fedoraproject.org/repos/f45-build/latest/x86_64
libvpx.so.9()(64bit)
package: godot3-runner-3.6.2-1.fc45.x86_64 from https://kojipkgs.fedoraproject.org/repos/f45-build/latest/x86_64
libvpx.so.9()(64bit)
package: godot3-server-3.6.2-1.fc45.x86_64 from https://kojipkgs.fedoraproject.org/repos/f45-build/latest/x86_64
libvpx.so.9()(64bit)
package: gstreamer1-plugins-good-1.28.1-1.fc45.x86_64 from https://kojipkgs.fedoraproject.org/repos/f45-build/latest/x86_64
libvpx.so.9()(64bit)
package: icecat-4:140.8.0-1.rh1.fc45.x86_64 from https://kojipkgs.fedoraproject.org/repos/f45-build/latest/x86_64
libvpx.so.9()(64bit)
package: libavcodec-free-8.0.1-4.fc45.x86_64 from https://kojipkgs.fedoraproject.org/repos/f45-build/latest/x86_64
libvpx.so.9()(64bit)
package: qt5-qtwebengine-5.15.19-6.fc44.x86_64 from https://kojipkgs.fedoraproject.org/repos/f45-build/latest/x86_64
libvpx.so.9()(64bit)
package: scummvm-2.9.1-3.fc44.x86_64 from https://kojipkgs.fedoraproject.org/repos/f45-build/latest/x86_64
libvpx.so.9()(64bit)
package: seamonkey-2.53.23-2.fc44.x86_64 from https://kojipkgs.fedoraproject.org/repos/f45-build/latest/x86_64
libvpx.so.9()(64bit)
package: toxcore-0.2.20-2.fc43.x86_64 from https://kojipkgs.fedoraproject.org/repos/f45-build/latest/x86_64
libvpx.so.9()(64bit)
package: utox-0.18.1-17.fc44.x86_64 from https://kojipkgs.fedoraproject.org/repos/f45-build/latest/x86_64
libvpx.so.9()(64bit)
package: vlc-plugins-base-1:3.0.23-4.fc45.x86_64 from https://kojipkgs.fedoraproject.org/repos/f45-build/latest/x86_64
libvpx.so.9()(64bit)
package: xine-lib-1.2.13-29.fc44.x86_64 from https://kojipkgs.fedoraproject.org/repos/f45-build/latest/x86_64
libvpx.so.9()(64bit)
package: xpra-1:6.4.3-3.fc45.x86_64 from https://kojipkgs.fedoraproject.org/repos/f45-build/latest/x86_64
libvpx.so.9()(64bit)
that causes all the other openQA failures, because various of those packages are in default package sets so we fail when attempting to update the system with this package.
Same problem as the Fedora 44 update and the other two F45 updates that exist for some reason: the new gnome-kiosk build breaks VT switch in dedicated installer images. A matching anaconda build must be in the same update. See https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages for details on how to do this.
Same problem as the other update which now has no builds in it: it breaks VT switch in dedicated installer images. A matching anaconda build must be in the same update. See https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages for details on how to do this.
Oh, er, and now this update appears to have no builds in it?
This update has the same problem as the Fedora 45 gnome-kiosk update: it changes gnome-kiosk's default behavior to disallow VT switches, which breaks both openQA tests and human expectations when running a Fedora install from a dedicated installer image. Those images use gnome-kiosk and it is certainly expected that you are able to switch to a VT to debug installation issues or check log files.
The update needs to contain an anaconda build that passes the argument to gnome-kiosk that enables VT switching.
Still the same problem. VT switch broken in anaconda. This update needs to contain both packages, or else the change in gnome-kiosk needs to be made more conservatively so existing behavior is not broken.
This update has been unpushed.
The gating failure here is a blip, but I am intentionally not restarting it because this is known to break rpm-ostree installs and should not go stable. See discussion at https://src.fedoraproject.org/rpms/dracut/pull-request/90 .
This is missing a rebuild 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)
Why are we updating to a new version that bumps an soname anyway? This generally should not be done on stable releases, especially the older stable release, without clear justification.
This is missing a rebuild 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)
This is missing flang:
Dependencies of other packages that would be BROKEN by the tested packages:
package: flang-21.1.8-2.fc44.x86_64 from https://kojipkgs.fedoraproject.org/repos/f44-build/latest/x86_64
clang-resource-filesystem = 21.1.8
libMLIR.so.21.1()(64bit)
This seems to have been missing a rebuild of flang and pocl:
Dependencies of other packages that would be BROKEN by the tested packages:
package: flang-21.1.8-2.fc44.x86_64 from https://kojipkgs.fedoraproject.org/repos/f45-build/latest/x86_64
clang-resource-filesystem = 21.1.8
libMLIR.so.21.1()(64bit)
package: pocl-7.1-5.fc45.x86_64 from https://kojipkgs.fedoraproject.org/repos/f45-build/latest/x86_64
libLLVMSPIRVLib.so.21.1()(64bit)
I note from the waiver:
"The test failure is caused by a breaking change in the kernel:\n\nhttps://lore.kernel.org/all/20260104032357.38555-1-yuhuang@redhat.com/#r"
@bengal is the test going to be updated/fixed? Because if not, this will keep happening...
https://bugzilla.redhat.com/show_bug.cgi?id=2418196#c3 reports that this version broke remote desktop for Jerry James...
This is gated because it failed its own CI tests. Someone who understands what they're testing and why they failed should look at it.
It looks like switching to any VT other than 1 gives a blank screen, in openQA testing.
I will note that, as with the F43 update, the waiver message here - "Looks like an infra issue as all FreeIPA tests passed well" - is wrong. The failure is a genuine one:
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: Run GEF got-audit
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [ 19:59:03 ] :: [ PASS ] :: Command 'systemctl restart krb5kdc.service' (Expected 0, got 0)
:: [ 19:59:04 ] :: [ PASS ] :: Command 'systemctl restart kadmin.service' (Expected 0, got 0)
:: [ 19:59:04 ] :: [ PASS ] :: Command 'systemctl --no-pager status krb5kdc.service' (Expected 0, got 0)
:: [ 19:59:04 ] :: [ PASS ] :: Command 'systemctl --no-pager status kadmin.service' (Expected 0, got 0)
:: [ 19:59:04 ] :: [ PASS ] :: Command 'SERVICE_PID=$( systemctl show --property=MainPID krb5kdc.service | cut -f2 -d= )' (Expected 0, got 0)
:: [ 19:59:04 ] :: [ PASS ] :: Command 'echo SERVICE_PID is '9083'' (Expected 0, got 0)
:: [ 19:59:06 ] :: [ PASS ] :: Command 'gdb-gef --pid '9083' --command='/var/ARTIFACTS/work-tests7r_w5n62/plans/tests/discover/default-0/tests/tests/got-audit'/got-audit.gdb --batch > '/tmp/tmp.Am74Mu5Qnf/tmp.AQJCvVx3iE'' (Expected 0, got 0)
:: [ 19:59:06 ] :: [ PASS ] :: File '/tmp/tmp.Am74Mu5Qnf/tmp.AQJCvVx3iE' should contain ' : /.*/libc.so'
:: [ 19:59:06 ] :: [ FAIL ] :: File '/tmp/tmp.Am74Mu5Qnf/tmp.AQJCvVx3iE' should not contain ' :: ERROR'
:: [ 19:59:06 ] :: [ PASS ] :: Command 'cp '/tmp/tmp.Am74Mu5Qnf/tmp.AQJCvVx3iE' '/var/ARTIFACTS/work-tests7r_w5n62/plans/tests/execute/data/guest/default-0/tests/got-audit-1/data'/krb5kdc-got-audit.txt' (Expected 0, got 0)
:: [ 19:59:06 ] :: [ PASS ] :: Command 'SERVICE_PID=$( systemctl show --property=MainPID kadmin.service | cut -f2 -d= )' (Expected 0, got 0)
:: [ 19:59:06 ] :: [ PASS ] :: Command 'echo SERVICE_PID is '9113'' (Expected 0, got 0)
:: [ 19:59:08 ] :: [ PASS ] :: Command 'gdb-gef --pid '9113' --command='/var/ARTIFACTS/work-tests7r_w5n62/plans/tests/discover/default-0/tests/tests/got-audit'/got-audit.gdb --batch > '/tmp/tmp.Am74Mu5Qnf/tmp.AQJCvVx3iE'' (Expected 0, got 0)
:: [ 19:59:08 ] :: [ PASS ] :: File '/tmp/tmp.Am74Mu5Qnf/tmp.AQJCvVx3iE' should contain ' : /.*/libc.so'
:: [ 19:59:08 ] :: [ PASS ] :: File '/tmp/tmp.Am74Mu5Qnf/tmp.AQJCvVx3iE' should not contain ' :: ERROR'
:: [ 19:59:08 ] :: [ PASS ] :: Command 'cp '/tmp/tmp.Am74Mu5Qnf/tmp.AQJCvVx3iE' '/var/ARTIFACTS/work-tests7r_w5n62/plans/tests/execute/data/guest/default-0/tests/got-audit-1/data'/kadmin-got-audit.txt' (Expected 0, got 0)
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
however, @abbra looked into it on the F43 update and thinks it's an sssd issue, not caused by this update.
OK, we took the evil way out of the situation (lil' light production database editing without a safety net, don't worry, everything is totally normal and under control, return to your homes, citizens)
This update is now sorta stuck. I can't submit it for stable because there's a newer gthumb in stable now. But I can't take gthumb out of it because the side tag has been garbage collected so it's no longer possible to re-generate the update.
I can't see a good way out of this situation.
Seems fine in Beta-1.2 testing so far.