This violates Final criterion "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image" - https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria#Update_notification - so proposing as a Final blocker.

so I guess to be specific here, the thing that's being tested is the update check that *should run on first log in to the desktop after system boot*.

I have tried an older PackageKit-1.2.2-1.fc33.x86_64 build on a F33 VM that I have here (that previously had 1.2.2-2 installed) and had the the same issue as with the 1.2.2-2 build: I did not get any new updates notification. When I manually opened GNOME Software, new updates were displayed correctly there, but that was also the case with 1.2.2-2 build.

I have also tried reverting the VM to a clean after-install (Fedora 33 Beta) state and got new updates notification. Then I have fully updated it to latest F33 state and tried manually downgrading some packages (gnome-boxes etc.), changing the check-timestamp gsettings (https://pagure.io/fedora-qa/os-autoinst-distri-fedora/blob/master/f/tests/desktop_notifications.pm#_28) and rebooting/relogging. But at this point, I was not able to get any new update notification at all although I have tried this multiple times. Available updates were displayed fine when I opened GNOME Software, but no update notifications appeared.

I am beginning to think that this is not an issue caused by the PackageKit pk_dbus_get_uid() crash fix PR and probably also not a PackageKit issue at all (older PackageKit-1.2.1-1 that had no notification issues is still used on latest F33).

Would it be possible to run the desktop notification test again, this time on a fully updated Rawhide system using latest packages, but with a slightly older PackageKit build (1.2.2-1 or 1.2.1-1)?

I did more testing again and not sure what I did wrong before, but I now seem to get new update notifications without any issue in my F33 testing VM with latest updates (and gnome-boxes/podman/etc. manually downgraded to test the update notifications). Even when using latest libdnf-0.54.2-3.fc33.x86_64 and PackageKit-1.2.2-2.fc33.x86_64.

So, it seems that there is probably no regression (although I am still not 100% sure), just some issue with the Rawhide test.

There's definitely a bug in something, but I agree it doesn't seem as clear-cut any more. I ran the test multiple times yesterday on various Rawhide builds and we see the issue across all of them, sometimes we get a notification, sometimes we don't - including builds before 20201110.n.0. I'm going to see if I can figure out anything more concrete today.

I think I have a new suspect here: fwupd 1.5.0. A few factors:

* That arrived around the time the test *really* first failed in openQA. The first failure I can see in openQA where we got no update notification was https://openqa.fedoraproject.org/tests/708601#step/desktop_notifications/31 , on 2020-10-28. fwupd 1.5.0 landed on 2020-10-26.

* We've started getting problems with a test in F32 and F33 update tests now too. There's a test which makes an update available (same dodge with python3-kickstart) then runs GNOME Software and checks it can update the system. In the last day, that test has started failing quite often on F32 and F33. When it fails, GNOME Software is just stuck saying "Software catalog is being downloaded": https://openqa.stg.fedoraproject.org/tests/966265#step/desktop_update_graphical/35 . What happened in the last day? The base disk image that the test uses was updated, meaning packages that went stable in the last two weeks got baked into it. What went stable for both F32 and F33 in the last two weeks and is relevant to GNOME Software? fwupd: https://bodhi.fedoraproject.org/updates/FEDORA-2020-4cda00ea06 and https://bodhi.fedoraproject.org/updates/FEDORA-2020-e327f9f270

* Check out https://openqa.stg.fedoraproject.org/tests/overview?distri=fedora&version=Rawhide&build=Fedora-Rawhide-20201107.n.1-notetest-NOREPORT&groupid=1 . The tests with _mod_ in their name downgraded fwupd to 1.4.6. The ones without _mod_ in their name didn't...

I wonder if the problem might be https://github.com/fwupd/fwupd/issues/2600 ?

So I do think that was the problem - I backported the fix for that in fwupd 1.5.1-2 , and the openQA tests since then all seem to be passing. However, pbrobinson pointed out that I probably broke fwupd on Secure Boot-enabled systems since I'm not on the SB signing list. fwupd should be on the list of things that only people with SB signing privileges can tag, but apparently it wasn't. nirik is adding it.

hughsie has built an fwupd 1.5.2 today which should be SB signed *and* have this bug fixed. We hope. I'm going to close it for now, will re-open if it turns out we still have problems. It'd be good to get the fwupd 1.5.2 updates for f32 and f33 pushed stable ASAP (assuming they actually work OK).