Looks good. Doesn't let you remove core stuff, does let you remove non-core stuff, removing and reinstalling a package works OK.
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.
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.
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 ibm-p8-kvm-03-guest-02.virt.pnr.lab.eng.rdu2.redhat.com systemd: 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 ibm-p8-kvm-03-guest-02.virt.pnr.lab.eng.rdu2.redhat.com systemd: fwupd.service: Failed at step NAMESPACE spawning /usr/libexec/fwupd/fwupd: No such file or directory Oct 01 04:39:34 ibm-p8-kvm-03-guest-02.virt.pnr.lab.eng.rdu2.redhat.com systemd: fwupd.service: Main process exited, code=exited, status=226/NAMESPACE Oct 01 04:39:34 ibm-p8-kvm-03-guest-02.virt.pnr.lab.eng.rdu2.redhat.com systemd: 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.
@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
184.108.40.206-1.fc30 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.
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 libLLVM-9.so()(64bit) needed by mesa-dri-drivers-19.2.0-1.fc31.x86_64 var/log/dnf.log: - nothing provides libLLVM-9.so(LLVM_9)(64bit) 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.