D'oh - this actually breaks the openQA live image build test still, but I never noticed, and now you pushed it stable it's broken for all updates :(

Error can be seen here - it's complaining about not finding an indented block where it expects to in /usr/share/lorax/templates.d/99-generic/live/x86.tmpl. Can you take a look? Thanks!

Seems to work fine for openQA. Thanks.

Note to self: this depends on the CommonMark update. Don't push it stable till that one is stable.

For the record, @lruzicka 's problem appears to have been down to the perl client now defaulting to https rather than http.

It's been running on the staging instance since a bit before I submitted the update, and hasn't shown any such problem there. Bit hard to tell what's going on in your instance without more details...

for the record: openQA tests failed initially due to UI rework in this release. I updated the openQA needles and now all tests pass.

The backtrace I posted was completely wrong, sorry, because I had a different libdnf on the system where I got it. The correct backtrace should be the one at .


openQA testing indicates that this is causing crashes in PackageKit. This happens in the test which tests enrolling to a FreeIPA domain using Cockpit (which does some package installs via PK, IIRC) and in the GNOME desktop update test, when refreshing available updates. Tarballs of /var/log and the crash dump directories can be found in affected tests, like this one - coredump.tar.gz is the coredumpctl-captured dump, spoolabrt.tar.gz is the ABRT-captured crash directory, and var_log.tar.gz has the entire contents of /var/log .

Note this update breaks bodhi updates download for updates containing more than one build: only packages from one build will be downloaded, then the command will quit (but exit code will be 0). This is my fault, sorry. I'm sending a fix.

openQA testing shows the service fails to start on reboot after the update is installed. A /var/log tarball is available here. Note, the test is run on a BIOS VM.

Note, the test is run on a BIOS VM.

openQA testing shows the service fails to start on reboot after the update is installed. A /var/log tarball is available here.

And not submit and then push them stable within like 13 hours, so that I have time to notice the failure in openQA testing and -1 the update? Thanks.

Yeah, I think we shouldn't be pulling this in on Fedora at all, but that's a separate issue. I'll file a bug on that.

@mattf yeah, that's correct, the %postun of 5.1.0-7 was also broken and of course that can't be helped once it's installed. I just checked and it is fixed in both places in -8.

@mattf @kparal can you check this now? thanks!

Aha. That's a fun one. Pre-existing bug, it only shows up when firewalld_zone is disabled in the spec...I'll fix it.


It should be pushable right now, but for some reason Bodhi claims it isn't. The required wait time is 14 days, and it was pushed to testing 24 days ago, but if you try and push it, Bodhi says:

"This critical path update has not yet been approved for pushing to the stable repository. It must first reach a karma of 2, consisting of 0 positive karma from proventesters, along with 2 additional karma from the community. Or, it must spend 14 days in testing without any negative feedback Additionally, it must pass automated tests."

@bowlofeggs ^^^

since this is causing real problems for real people, I'm gonna change my karma to +1 to see if that will fix it. Next time I really wish people would submit updates properly. :(