For some reason, update notifications aren't currently working on Fedora 38 KDE. They *are* working on Rawhide. I kept expecting this to shake out as F38 updates got pushed stable, but it just...hasn't.
The test boots to a console, installs a dummy low-versioned python3-kickstart package, then logs into the desktop and waits, expecting to see an update notification (because there should always now be an update at least for python3-kickstart).
On Rawhide, we reliably see the little 'bell' icon indicating there's a notification:
and then we open the notification panel and see an update notification:
on F38, we don't see the little 'bell' icon, and when we open the notification panel we see nothing:
the test did randomly pass just *once*, on Fedora-38-20230308.n.0, but other than that it has failed on every run since Fedora-38-20230222.n.0 . (The test also failed on the composes for the week before that, but the earlier failures were needle mismatches that I hadn't yet got around to fixing, from the screenshots it looks like there *was* an update notification on those composes.) On Rawhide it's a little hard to tell because of some other bugs that confuse things, but it *looks* like it was broken in Fedora-Rawhide-20230210.n.2 but fixed from Fedora-Rawhide-20230213.n.0 onwards.
Proposing as a Final blocker: violates Final criterion "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image."
The Dorian Gray part of this appears when you download the affected ISO from koji and you install that ISO in a virtual machine. Then the notifications work normally and updates are announced in several minutes after the boot. So it seems to be failing in openQA only. However I should mention, that I have always taken a little older ISOs where there were updates to be expected and I did not try to replicate the exact one test case with the python package. I guess I will try to do it, too.
Locally, in a VM, this also works with the python3-kickstart package stragety with otherwise fully updated KDE, so I believe that the culprit will be somewhere else, I just do not have an idea where it could be.
Created attachment 1950948 [details]
Notifications show that updates are ready.
Created attachment 1950949 [details]
When a lower version of python3-kickstart is installed, updates are ready, too
Testing a Fedora-KDE-Live-x86_64-38-20230301.n.0.iso installed on VM (qemu/virt-manager) notifications show up just fine.
Fedora-KDE-Live-x86_64-38_Beta-1.3.iso installed on virt-manager VM works correctly too, notifications pop-up and bell is present.
Huh, that's interesting. Thanks for the testing, guys. Can anyone attach logs from a 'success' case so we can compare them with the logs from the openQA 'failure' case?
Since this seems to work in real-world cases, unproposing as a blocker.
(In reply to Adam Williamson from comment #8)
> Huh, that's interesting. Thanks for the testing, guys. Can anyone attach
> logs from a 'success' case so we can compare them with the logs from the
> openQA 'failure' case?
> Since this seems to work in real-world cases, unproposing as a blocker.
I am attaching the whole journactl for you to go over, but the only relevant line I was able to find that mentioned PackageKit, except for those saying that it was starting and so on) was this one:
Mar 16 09:50:27 fedora PackageKit: get-updates transaction /733_abeebbae from uid 1000 finished with success after 1517ms
Created attachment 1951206 [details]
Journalctl from the virtual machine.
Since this doesn't seem to be a general issue, removing the CommonBugs nomination.
You can see Discover knows that there are updates available by the systray icon.
Discover doesn't show an update notification if it remembers it has shown one recently. I believe the notification might be getting shown during some other test phase, so here it is not shown again, and instead you only get the systray icon.
You can see in the desktop_login test that the notification is indeed being shown for the fresh users: https://openqa.fedoraproject.org/tests/1849840/video?filename=video.ogv&t=32.46,32.50 @ 2023-03-25T19:47:40
For a logged in user you can retrieve the last time discover has shown a notification with: `kreadconfig5 --file PlasmaDiscoverUpdates --group Global --key LastNotificationTime`, then you might be able to understand at what point it is being shown.
Well, the only "previous test phase" is install_default_upload, which only logs in and checks it reaches the desktop:
the video of that test doesn't show the update notification appearing. Still, it's plausible something along those lines is the issue; there *is* a difference between Branched and Rawhide there - there will be updates available 'naturally' on Branched because updates-testing will have newer packages than the compose; on Rawhide, when the compose is tested it has all the latest packages, so no updates will be 'naturally' available. I guess it's possible the notification is being "shown" after the test switches to a VT to do some data collection; we wouldn't see it in the video then...
Is there a way we can *unset* the last time the notification was shown as part of the test's setup phase? We already do that sort of thing for GNOME, but have not previously had to do it for KDE - is this a new mechanism?
Ah, it looks like just `kwriteconfig5 --file PlasmaDiscoverUpdates --group Global --key LastNotificationTime --delete` does the job. And it does fix the problem! First time I tried, at least. From the timestamp shown by kreadconfig5 it looks like, indeed, the notification was "shown" during the install_default_upload test, right after we switched away to a VT after confirming we reached the desktop.