We shipped this in RC 1.2 so it needs to go stable. It was not intended to fix the kglobalaccel crash (only to try and stop it breaking logout/login so much), and while it doesn't entirely resolve the logout/login problem, it should at least make it better.

I vaguely remember the whole -gnu thing being some kind of hot debate years ago, but I don't recall the details at all :/

so that'll work just so long as we don't have any lurking packages anywhere that redefine any of those things...:)


I see the problem here.

In the rpm package itself, %_target_platform is defined for each platform in a file under /usr/lib/rpm/platform/, always the same:

[adamw@adam nightlies]$ rpm -ql rpm | grep -v rpmdb.sqlite | xargs strings -f 2>/dev/null | grep -s target_platform
/usr/lib/rpm/platform/aarch64-linux/macros: %_target_platform   %{_target_cpu}-%{_vendor}-%{_target_os}
/usr/lib/rpm/platform/alpha-linux/macros: %_target_platform %{_target_cpu}-%{_vendor}-%{_target_os}
/usr/lib/rpm/platform/alphaev5-linux/macros: %_target_platform  %{_target_cpu}-%{_vendor}-%{_target_os}
/usr/lib/rpm/platform/alphaev56-linux/macros: %_target_platform %{_target_cpu}-%{_vendor}-%{_target_os}
/usr/lib/rpm/platform/alphaev6-linux/macros: %_target_platform  %{_target_cpu}-%{_vendor}-%{_target_os}
/usr/lib/rpm/platform/alphaev67-linux/macros: %_target_platform %{_target_cpu}-%{_vendor}-%{_target_os}

etc. etc. etc. But there is another definition that overrides that one, which may or may not be present on any given system. It's in /usr/lib/rpm/redhat/macros, which is part of the redhat-rpm-config package:

[adamw@adam nightlies]$ grep target_platform /usr/lib/rpm/redhat/macros 
%_target_platform   %{_target_cpu}-%{_vendor}-%{_target_os}%{?_gnu}
[adamw@adam nightlies]$ rpm -qf /usr/lib/rpm/redhat/macros

That's where the -gnu on the end comes from. If you have redhat-rpm-config package installed, %_target_platform will evaluate to something like x86_64-redhat-linux-gnu. If you don't have it installed, %_target_platform will evaluate to something like x86_64-redhat-linux.

I'm pretty sure that package is always installed during package builds, hence during the build of the package we get the -gnu form and the binaries get installed using that form, as /usr/bin/x86_64-redhat-linux-gnu-pkg-config etc. But the wrapper script is running on the local system, and we can't be sure that the redhat-rpm-config package is installed there; it's not a dependency of anything very critical. In general packagers will have it installed, but otherwise it may very well not be installed.

So the wrapper script cannot really be reliable as written. An ugly hack would be to add the -gnu to the end of the string if it's not there already :/

OK, while there are issues with this I'm not gonna include it in any stable push requests.

Giving this positive karma again as we know it works (though openQA may fail since it won't test this and the other update together).

The dnf and libdnf builds in this update needed some minor fixes that got submitted as a separate update, so I'm removing them from this update and we will submit both updates for stable together.


Didn't test the security issue is fixed, but boots fine, bluetooth works OK (can pair and stream audio), suspend/resume is OK.


I don't have nvidia, but no regressions with boot and login, openQA tests passed.

BZ#1887976 should update to 3.38.1

No regressions noted, tried changing timezone twice and it seemed to work properly.

BZ#1888424 Timezones are broken

Don't see any issues with metadata in gnome-software.

BZ#1882521 Generate appstream-data for F33

We now have a fix for the problem on the anaconda side, but this update should not go stable until an anaconda build for F33 with that fix is done and edited into this update.

tests are failing here because the fedora-repos-33-1 update hasn't made a compose yet.

This is the diff, for the convenience of other eyeballs.

Tested with the trusty ol' Mk. 1 Eyeball, looks good.

BZ#1887891 add Recommends: nm-connection-editor

I'd kind of like someone to try a Windows dual install with this...

With feedback from @kparal and upstream ticket I think we can reasonably push this.


With some tweaks to the test code (especially not touching resolv.conf) the replica tests do pass, so changing my feedback to positive. Let's just push this stable and pretend everything's fine!

BZ#1880628 FreeIPA server doesn't get along well with systemd-resolved (need to manually disable it)
BZ#1886205 FreeIPA server upgrade from F32 to F33 doesn't work any more because F32's FreeIPA is newer

Per FEDORA-2020-7cfc885657 this was unnecessary, -5 was already rebuilt.