@mreynolds so what's the plan? do we need to @ somebody to fix dogtag? I don't see any movement on that.

I think this is hitting the same problem as the F32 update, FreeIPA deployment is broken.

Here's the log tarball from the same test passing on a different F32 update:

As you can see from the Automated Tests tab, this appears to break server deployment. Logs at .


By eyeball, this LGTM. We need it in ASAP to make some tests pass.

Tests passed with 3GiB rootfs size.

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.

Example failure: , logs on the "Logs & Assets" tab, the keyboard error is visible in the X log.

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.

@stransky so I figured it out: it seems firefox doesn't run unless dbus-glib is installed. This is new, it worked before.

I guess it should be added as a dependency, or you can figure out what's requiring and if it can be made optional?

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 . 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.

openQA failure here is the other bug we're dealing with ATM, I have set up openQA to work around that and re-run the test. Logs from server deployment test show the dependency bug is resolved.

BZ#1920198 389-ds-base breaks on upgrade from F32 to F33 because F32 build had gost support but F33 build doesn't

openQA results show the gost bug is fixed. Editing update to mark it as fixing that.

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.


This update bumped the soname of libdns, and broke bind-dyndb-ldap . This shouldn't have been pushed stable. This is a good reason why I'm proposing update gating...

If this is supposed to go with the nss, they should have been put in the same update.

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.