seems fine in a quick test.

BZ#1761484 Update appstream-data after final freeze

Looks good. Doesn't let you remove core stuff, does let you remove non-core stuff, removing and reinstalling a package works OK.

BZ#1759193 "Installed" tab contains core system applications and allows uninstalling them

Don't know if I was affected by the bug before, but at least fiddled around with selecting different of my displays and display modes for a bit and it didn't crash.

Changes look good, packages install and look correct.

BZ#1760415 updates-testing is still enabled
BZ#1760474 Need finalized fedora-release for F31

Works OK on my desktop, and passed openQA tests.

BZ#1759186 Include GNOME 3.34.1 in Fedora 31 Final

That's probably this %postun line: %systemd_postun_with_restart pesign.service. That dates back to 2018, so it's not new with this update I don't think.

Looking at the spec this change looks good, let's get it out.

BZ#1757948 fwupd.service fails to start if /var/cache/fwupd doesn't exist (e.g. clean install)

You can do it with the bodhi CLI tool:

  • dnf -y install bodhi-client
  • bodhi updates download --updateid=FEDORA-2019-8f20f9e4e3

To get all the RPMs for your arch to the current directory.

openQA tests look good, and I also hand-triggered the universal tests for the ISO built by the netinst test: all pass except iscsi, which is known to fail on netinst images, it's a test issue not a bug with this update. So this looks good, thanks.


openQA tests look good.

This can never go stable now as later versions of both packages already did.

This update has been unpushed.


I think this broke on new installs, in fact. GNOME Software update tests in openQA are failing consistently with an fwupd-related error since this landed in stable:

the system logs show fwupd.service failing to start:

Oct 01 04:39:34 systemd[1991]: fwupd.service: Failed to set up mount namespacing: /run/systemd/unit-root/var/cache/fwupd: No such file or directory
Oct 01 04:39:34 systemd[1991]: fwupd.service: Failed at step NAMESPACE spawning /usr/libexec/fwupd/fwupd: No such file or directory
Oct 01 04:39:34 systemd[1]: fwupd.service: Main process exited, code=exited, status=226/NAMESPACE
Oct 01 04:39:34 systemd[1]: fwupd.service: Failed with result 'exit-code'.

We had an identical issue in iwd recently. The problem here is probably that the fwupd service file refers to /var/cache/fwupd but the package does not create it. This will cause problems until it is created manually.

CI is failing on the crun dep: "nothing provides crun >= 0.10-1 needed by buildah-1.11.2-3.git0bafbfe.fc31.x86_64". That's because FEDORA-2019-d2f808ac65 is not yet stable, though it's queued for it. We'll want to re-trigger the CI tests after that goes stable, somehow.

all openQA tests pass, so this is finally looking good!

all openQA tests pass, so this is finally looking good!

@kuosmanen if you have updates-testing enabled, it will seem fine because you will get both updates, because they are both in updates-testing. There would be a problem, though, if this update was pushed stable before the LLVM update, because then this would be in stable without the LLVM it required and suddenly half our image composes would probably fail.

@pwalter well, it doesn't need to be at the same time, just this one needs to go at the same time or later than the LLVM one.

This is not handling #1607633 correctly and thus 389-ds-base-legacy-tools is not installable. See this bug comment for more details. I'm pretty sure this is why the openQA upgrade_server_domain_controller test fails - it is failing on a check that the packages from the update were actually installed, which they were not (instead the system winds up with the current stable packages); I'm pretty sure this is because 389-ds-base-legacy-tools is installed in the F30 system and so when running the upgrade to F31, DNF does not include the packages from the update due to the dep issue with that package.

BZ#1607633 Auto-provides / requires for private perl modules should be filtered

This update seems to have a dependency issues with LLVM:

var/log/dnf.log: Problem 1: cannot install the best update candidate for package mesa-dri-drivers-19.2.0~rc4-1.fc31.x86_64
var/log/dnf.log:  - nothing provides needed by mesa-dri-drivers-19.2.0-1.fc31.x86_64
var/log/dnf.log:  - nothing provides needed by mesa-dri-drivers-19.2.0-1.fc31.x86_64

that's why a lot of the openQA tests failed - they are failing because they check that the update under test was actually installed if it should have been, and in this case it was not, because of this dependency issue.

It seems there is currently a buildroot override for LLVM 9, which is why this update got built against it. There is a pending update also. This update should either be unpushed and merged with the LLVM 9 update somehow, or should not be pushed stable until after that update is stable. I will -1 it to disable the autopushes and make sure it does not go stable too early.

OK, the comps PR is merged now so this should be OK.