Indeed, tests now pass, thanks.

@jpenala do you still have issues in KDE with this build? Thanks!

The openQA failure here is because of a version problem with rgb. The rgb package in this update is rgb-1.0.6-1.fc34. However, the current xorg-x11-server-utils already has a rgb subpackage, which is version rgb-1.0.6-38.fc34. The newly split-out package should be versioned higher than the current subpackage of xorg-x11-server-utils, I think.

BZ#1934383 Review Request: rgb - X color name database

@stransky is there anything that can be done to fix the issues @jpenala noted without regressing the other bug?

openQA tests are passing, so...

The openQA test failure here is I think happening because this fixes a bug I had worked around in the openQA tests. Will fiddle with that tomorrow.

BZ#1932447 plasma systemdBoot: autostart items not launched (xdg-user-dirs)

@stransky please combine interdependent updates together correctly. If you need a provenpackager to help with this I or @kevin would be happy to do it. Not doing that causes test failures, and when the next Bodhi version is deployed to production, you will not be able to push updates stable without a waiver if tests fail.

This passes all openQA tests, seems to also fix though it's not currently marked.

BZ#1908653 CVE-2020-35518 389-ds-base: information disclosure during the binding of a DN [fedora-all]

Looks correct by eyeball.

BZ#1856098 Obsolete packages that used to require Python 3.8 but are gone in Fedora 34

Welp, it seems to load now.

BZ#1931972 Fix loading language chooser dialog in Region & Language panel

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