Aha, looks like this was actually caused by disk space exhaustion. The openQA installer image build test sets the root FS size to 2GiB, and with this update it was completely full and there was no space to write to when X startup reached this stage.
Our Pungi config has used a root FS size of 3GiB for all installer images since F32, so I've updated the openQA test to match that and re-run it. There's no point in openQA expecting things to fit in 2GiB if our official builder doesn't. Still, it does look like this update caused more space to be used up in the installer root FS, which is never a good thing; we may need to identify the extra bits and update the lorax template file trimming stuff to remove them if they're not needed. Will reverse feedback if re-run tests pass.
This is a very odd result, but it seems to be a true one: a network install image built with this update fails to boot to the graphical installer environment because X start fails, with keyboard-related errors.
[ 34.291] (EE) Error compiling keymap (server-1) executing '"/usr/bin/xkbcomp" -w 1 "-R/usr/share/X11/xkb" -xkm "-" -em1 "The XKEYBOARD keymap compiler (xkbcomp) reports:" -emp "> " -eml "Errors from xkbcomp are not fatal to the X server" "/var/lib/xkb/server-1.xkm"' [ 34.291] (EE) XKB: Couldn't compile keymap [ 34.291] (EE) XKB: Failed to load keymap. Loading default keymap instead. [ 34.338] (EE) Error compiling keymap (server-1) executing '"/usr/bin/xkbcomp" -w 1 "-R/usr/share/X11/xkb" -xkm "-" -em1 "The XKEYBOARD keymap compiler (xkbcomp) reports:" -emp "> " -eml "Errors from xkbcomp are not fatal to the X server" "/var/lib/xkb/server-1.xkm"' [ 34.338] (EE) XKB: Couldn't compile keymap [ 34.338] XKB: Failed to compile keymap [ 34.338] Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config. [ 34.338] (EE) Fatal server error: [ 34.338] (EE) Failed to activate virtual core keyboard: 2(EE) [ 34.338] (EE)
it's hard to see how the changes in this update cause that, but...somehow they seem to. The failure has repeated 8 times across the two openQA servers, while the same tests run on a later update - FEDORA-2021-f85cec6472 - passed, suggesting this isn't just caused by something else having changed between the last time this test passed and the time this update was tested...
Leaving negative feedback at least till we figure out what's going on.
I revoked this update because it was queued for stable, but it seems to break openQA's ability to launch Fedora from a console - see https://openqa.fedoraproject.org/tests/762385#step/server_cockpit_default/14 . This is vital to how we do several openQA tests. I'm not sure what the problem is yet beyond the apparently cut-off error message "ldn't load XPCOM.xinit: connection t" we see at the console, but it is failing consistently for this update and working consistently without it.
This update changes the soname of libdns (in bind-libs-lite) and will render bind-dyndb-ldap uninstallable (that's the failures in the openQA tests). The update should at least include a rebuild of bind-dyndb-ldap , but really you should not change library APIs/ABIs in stable release updates at all unless it's necessary.
I don't really see any benefit to keeping the restriction in Rawhide. People are going to want to run Firefox add-ons. I mean, the two most prominent people using Rawhide on the desktop are probably me and @kevin and we both want to run Firefox add-ons. :)
All the restriction will do is cause people to set the entire system-wide policy to LEGACY (which reduces their security in all sorts of other areas) or try and hand-craft an exception for this specific case and possibly get it wrong and break stuff. There's no benefit for anyone there.
If Mozilla re-signs add-ons, great. Until then our default policy should accept SHA-1 signatures for Firefox add-ons, using as finely-grained as possible a policy exception for that purpose.