This update is inter-dependent with this pam update, which is not allowed by policy. The new authselect and the pam it depends on should be in the same update, or this update should not have been submitted until after the pam update went stable.

This is why most of the openQA tests fail.


Seems to have an issue with styling of the buttons on the update page:


Seems to have an issue with styling of the buttons on the update page:


I've been running a previous scratch build version of the fix, but just rebooted with this and things still look good so far.

BZ#1801820 [abrt] gnome-shell: js::gc::TenuredCell::writeBarrierPre(js::gc::TenuredCell*)(): gnome-shell killed by SIGSEGV

Note this includes a change which can potentially break existing configs. If you have a config that inherits from a Fedora 31, 32 or Rawhide config, or a RHEL 8 config, and adds to the yum.conf section - something like this, from openQA, which does exactly this:

config_opts['plugin_conf']['bind_mount_enable'] = True
config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/opt/update_repo', '/opt/update_repo'))
config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/dev/ttyS0', '/dev/ttyS0'))
config_opts['yum.conf'] += """
name=Advisory repo

it will suddenly stop working with this version of mock, with an error KeyError: 'yum.conf'. This is because of this commit, which changes these configs from having a yum.conf section to having a dnf.conf section.

These updates do seem to be somewhat against the Fedora and EPEL update policies, which discourage shipping major releases with incompatible changes as updates for stable releases.


I believe this has a regression in libdnf which causes PackageKit crashes (as some folks also noted on the F31 update, but didn't -1 it so it went stable :<). The crash is . This is frequently happening in the openQA Cockpit update test for F31 and Rawhide. I'll -1 this so it doesn't go stable for F30 at least until this is investigated.


openQA tests all look good now.

BZ#1783676 Optimize Overview page for narrow screens around 1024 px

openQA failures are due to UI changes requiring needle updates. I'm working on that now (over very slow conference wifi :<)

openQA failures are due to UI changes requiring needle updates. I'm working on that now (over very slow conference wifi :<)

This wasn't pushed stable? It was obsoleted. For Rawhide I spotted some later fixes and backported those too...hopefully it should be OK.

ah, no, it's just a straight-up error. src/lib389/lib389/instance/ added some uses of ensure_list_str, but neglected to import it from lib389.utils, where it's defined.

According to openQA, this breaks FreeIPA server deployment, with error name 'ensure_list_str' is not defined. Perhaps it needs some other bit to be updated alongside it.


This drops the epoch from 2 to 1. That is not allowed, and means the update doesn't actually install.

openQA showed issues on the previous update but not this one, interestingly. All the openQA tests passed for this update on both stg and prod. So it seems like, unless we got very 'lucky', the problem was fixed in openQA's environment in 72.0.1, but broken in some other environments instead...


This seems to be failing openQA tests (whereas the F31 update worked fine). Several of the tests that use a browser - both the desktop_browser tests for KDE and GNOME, and the test which enrols to FreeIPA via Cockpit then tests the FreeIPA webUI - had issues. It seems that in each case, navigating to a page just sometimes apparently failed, showing an entirely grey pane, like this. The browser is not still trying to contact the server at that point, it thinks the operation has completed and does not show any error, but it also doesn't show any page.

On the desktop_browser tests, openQA types the URL into a running Firefox and hits enter; on the FreeIPA/Cockpit test, it seems to have failed in the same way when launching Firefox with the URL as an argument (startx /usr/bin/firefox -width 1024 -height 768 https://ipa001.domain.local).

I see these failures in both staging and production, and F31 passed in both staging and production, so it doesn't seem like a blip, it seems like some kind of genuine issue.

There have been some ongoing issues with Koji and Bodhi lately which are causing issues with updates actually being tagged correctly and making it to testing, so you'll probably want to keep an eye on it manually to make sure it actually gets out. If it doesn't, contact whoever's on call for releng...

As part of the 5.4 rebase, this update backported a bug from master without backporting the fix: it's missing , so its kernel-modules-extra subpackage is 7x as big as it should be because it includes the kernel header files. This is the root cause of the openqa test failure - took me a bit of digging to figure it out, but that's why :)

zdzichu points out this commit as the likely suspect, and indeed I think he's right. That commit missed changing at least one place to catch a dnsutil.DNSZoneAlreadyExists exception instead of a ValueError: the bit of ipaserver/install/ where it checks the reverse zone. Here's the relevant bit of the traceback:

  File "/usr/lib/python3.7/site-packages/ipaserver/install/server/", line 562, in main
  File "/usr/lib/python3.7/site-packages/ipaserver/install/server/", line 276, in decorated
  File "/usr/lib/python3.7/site-packages/ipaserver/install/server/", line 673, in install_check
    dns.install_check(False, api, False, options, host_name)
  File "/usr/lib/python3.7/site-packages/ipaserver/install/", line 145, in install_check
  File "/usr/lib/python3.7/site-packages/ipapython/", line 383, in check_zone_overlap
    raise DNSZoneAlreadyExists(zone=zone.to_text(), ns=ns)

the block with the dnsutil.check_zone_overlap(reverse_zone) call isn't touched by that commit, but obviously should have been.