Comments

1137 Comments

This update has been unpushed.

karma

Yup, broken. openQA hit the same crash dwmw2 hit, in FreeIPA server deployment.

BZ#1831086 softhsm use-after-free on process exit
karma

yup, openQA caught the same crash.

BZ#1831086 softhsm use-after-free on process exit

Looks like my fix worked, tests are passing now.

@dvdhrm - additionally, you write in the commit message of this change as if it would not be backported to existing stable releases...but then you went ahead and submitted this update to F32. You also seem to have gotten everything one release cycle wrong in that commit message: we just released 32, not 33, and Rawhide at present is tracking 33, not 34.

I caught an error in the spec file that may have caused the problem. I've sent a fix and new builds are running now, I will edit this update with the new F32 build when it's done and see how the tests go.

karma

openQA is showing installer images built with this dbus failing to boot, and live image build failing when this dbus is included in the transaction. I'm running a meeting right now and then my power is going to be cut for a few hours, so I'm getting an initial negative karma in, will investigate in more detail later.

I think this update is a mistake. This build, webkit2gtk3-2.28.1-3.fc32, is from 2020-04-17. A newer build, webkit2gtk3-2.28.2-1.fc32, has already been submitted as an update and gone stable, 11 days ago.

I'm revoking this one.

Tracking the issue openQA hit at https://bugzilla.mozilla.org/show_bug.cgi?id=1635833 . Disabling the password manager seems to work around it, I have re-run the tests with that workaround and they all pass now.

karma

Looks to fix the bug from -1 in openQA testing.

There are multiple test failures in openQA for all three Firefox 76 updates (F30, F31, F32). It seems like, somehow, the update makes openQA much worse at typing passwords: all the failures are for password creation, where the two passwords that are typed don't match.

This only very very rarely goes wrong in other tests, somehow this build of Firefox is making it much worse, but I'm not sure how yet.

Figured out some more details of the problem in this bug report. Seems like pipewire is bodging an attempt to replace Pulseaudio. I think installed F32 systems may be OK on update (as they'll already have pulseaudio-libs-glib2 installed and the broken pipewire-libpulse package won't replace it on update), but the bug would likely affect F32 network installs if this update went stable, and would also affect the semi-official live respins.

It also seems like a fundamentally inappropriate thing to backport to F32, to me. pipewire shouldn't be attempting to replace pulseaudio after the fact in a stable release. This should be F33 only stuff, I think.

Booting an affected Rawhide image and examining it locally - https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200430.n.1/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-Rawhide-20200430.n.1.iso - the logs show multiple occurrences of this error:

"Failed to load shared library 'libgvc.so' referenced by the typelib: libpulse-mainloop-glib.so.0: cannot open shared object file: No such file or directory"

this seems to break both gnome-shell and gsd-media-keys.

The bug is also affecting Rawhide today: https://openqa.fedoraproject.org/tests/590517

I re-ran the openQA test on an earlier update, just to check if some other package which went stable or some kickstarts change or something is the cause, but it worked, so that's a strong indication that this update really is the problem.

Since multiple people have reported serious problems with this, I've unpushed it to ensure no-one else hits those problems till we know what's going on.

This update has been unpushed.

karma

A couple of openQA tests seem to be failing consistently on this update. The tests that fail are tests of Workstation live images built with this update included: we boot the live image and try to install from it and boot the installed system, the two tests are the same but one is UEFI and one BIOS.

What seems to be happening is that there's no window manager running in the booted live session. We get the 'Welcome' window with no chrome, then when the test clicks on the button to launch anaconda, we get it in a window about a quarter the size of the screen, at top left, also with no chrome, like this:

https://openqa.stg.fedoraproject.org/tests/837735#step/_boot_to_anaconda/4

in the background you can see the 'GNOME didn't manage to start properly' screen. So this is clearly throwing off GNOME startup somehow.

I'll grab the live image that was built and throw it up somewhere for manual testing. @mcatanzaro for info

@clime it requires "python(abi) = 3.6", which does the same job. that is all autogenerated by the packaging system.

karma

works.

BZ#1826286 "reset all" doesn't work in blivet partitioning
karma

we're shipping RC 1.6. openQA UEFI tests all passed.

BZ#1826864 libefivar fails to parse the emmc path if just a disk is specified, breaking anaconda bootloader install on eMMC-s