seems to fix the bug in a quick test here.

no regressions noted here in a quick test.

Looks good here.

Looks good here.

is there a reason this update isn't marked as fixing the bug?

@zpytela yeah, I saw that too, the interesting question is why that happened I guess; I don't do anything particularly odd to these base images, their state should be a fairly "normal" one. Perhaps a missing dependency or ordering issue or something, somewhere?

So, just a note here: the openQA tests for this initially failed, the test of using GNOME Software to update the system failed as Software got stuck during startup. The journal (see /var/log tarball) showed quite a lot of AVCs.

The base disk image the update tests were using yesterday was quite old (nearly two weeks old, the cutoff for an automatic rebuild), so the update was going from selinux-policy -31.fc32 straight to -35.fc32 , it wasn't updating from -32 (which is currently in stable). This may have had something to do with it.

I regenerated the base disk image manually and ran the test again and it passed, so now the test shows a pass (well, a soft failure on a known bug not to do with this update). But I thought I'd mention the issue just in case anyone wants to take a look at the logs and see if they can see what happened.

the openQA test failures here are spurious, the tests don't cope well with builds that have no x86_64 or noarch packages. This is actually annoyingly difficult to fix, so if you don't mind I'm just going to leave it at least for now :)

FEDORA-2020-8bc645d09f has been created as an alternative to this: it is only 3.24.16 with the specific fixes for the Evolution crash backported, rather than the whole of 3.24.17. Can folks test that instead and check it doesn't produce any of the bugs reported here? Thanks!

Fix looks good, openQA tests pass.

Fix for my text selection crasher looks good, openQA tests also look good.

So, I'm working on this, but the build repos are not being correctly regenerated ATM, so I'm stuck waiting for the overrides to show up. Working with releng on it.

Ah, OK, so, it seems:

1. freeipa-server requires 389-ds-base
2. 389-ds-base requires perl-Archive-Tar
3. perl-Archive-Tar requires perl(IO::Compress::Xz) and perl(IO::Uncompress::UnXz)
4. perl-IO-Compress-Lzma provides those, and requires perl(Compress::Raw::Lzma)
5. perl-Compress-Raw-Lzma provides that, and requires xz-libs(x86-64) = 5.2.4

and so we have solved our mystery! It seems perl-Compress-Raw-Lzma will need to be rebuilt and added to this update. If that's straightforward I can do it, I'll have a look. Pinging @pghmcfc for info.

Ah, OK, so, it seems:

freeipa-server requires 389-ds-base 389-ds-base requires perl-Archive-Tar perl-Archive-Tar requires perl(IO::Compress::Xz) and perl(IO::Uncompress::UnXz) perl-IO-Compress-Lzma provides those, and requires perl(Compress::Raw::Lzma) perl-Compress-Raw-Lzma provides that, and requires xz-libs(x86-64) = 5.2.4

and so we have solved our mystery! It seems perl-Compress-Raw-Lzma will need to be rebuilt and added to this update. If that's straightforward I can do it, I'll have a look. Pinging @pghmcfc for info.

There's some kind of dependency issue here which the openQA tests are catching: something in the FreeIPA tests does not want to have xz 5.2.5, for some reason. It's getting stuck at 5.2.4. There doesn't seem to be a library soname bump in the package, or anything, I can only assume something has a "< 5.2.5" dependency or something like that. I'm currently poking through the package collection trying to find out what, but until I can figure it out, leaving -1.

There's some kind of dependency issue here which the openQA tests are catching: something in the FreeIPA tests does not want to have xz 5.2.5, for some reason. It's getting stuck at 5.2.4. There doesn't seem to be a library soname bump in the package, or anything, I can only assume something has a "< 5.2.5" dependency or something like that. I'm currently poking through the package collection trying to find out what, but until I can figure it out, leaving -1.

openQA tests failed because this depends on FEDORA-2020-32711482f7 - that's been pushed stable so that should be OK, but in fact for Branched the packages from an update aren't truly stable until the next nightly compose after the update is pushed stable, and the most recent Branched compose failed.

Once a compose gets through, I'll re-run the tests and they should pass.

yeah, that's happening on all tests, so this LGTM to now. Thanks!