Bug 2178311 - Update notifications not shown on Fedora 38 KDE in openQA testing (work in manual testing)
Summary: Update notifications not shown on Fedora 38 KDE in openQA testing (work in ma...
Alias: None
Product: Fedora
Classification: Fedora
Component: plasma-discover
Version: 38
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
Whiteboard: openqa https://discussion.fedoraproje...
Depends On:
TreeView+ depends on / blocked
Reported: 2023-03-14 19:18 UTC by Adam Williamson
Modified: 2023-03-28 00:38 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2023-03-28 00:38:35 UTC
Type: Bug

Attachments (Terms of Use)
When a lower version of python3-kickstart is installed, updates are ready, too (518.77 KB, image/png)
2023-03-15 12:03 UTC, Lukas Ruzicka
no flags Details
Journalctl from the virtual machine. (349.23 KB, text/plain)
2023-03-16 08:59 UTC, Lukas Ruzicka
no flags Details

Description Adam Williamson 2023-03-14 19:18:27 UTC
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.

Comment 1 Adam Williamson 2023-03-14 19:20:12 UTC
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."

Comment 2 Lukas Ruzicka 2023-03-15 11:28:03 UTC
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.

Comment 3 Lukas Ruzicka 2023-03-15 11:58:58 UTC
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. 

See screenshots.

Comment 4 Lukas Ruzicka 2023-03-15 12:02:37 UTC
Created attachment 1950948 [details]
Notifications show that updates are ready.

Comment 5 Lukas Ruzicka 2023-03-15 12:03:35 UTC
Created attachment 1950949 [details]
When a lower version of python3-kickstart is installed, updates are ready, too

Comment 6 Geraldo Simião 2023-03-15 13:32:57 UTC
Testing a Fedora-KDE-Live-x86_64-38-20230301.n.0.iso installed on VM (qemu/virt-manager) notifications show up just fine.

Comment 7 Geraldo Simião 2023-03-15 13:54:43 UTC
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.

Comment 8 Adam Williamson 2023-03-15 15:49:56 UTC
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.

Comment 9 Lukas Ruzicka 2023-03-16 08:57:02 UTC
(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[1969]: get-updates transaction /733_abeebbae from uid 1000 finished with success after 1517ms

Comment 10 Lukas Ruzicka 2023-03-16 08:59:26 UTC
Created attachment 1951206 [details]
Journalctl from the virtual machine.

Comment 11 Kamil Páral 2023-03-17 15:31:50 UTC
Since this doesn't seem to be a general issue, removing the CommonBugs nomination.

Comment 12 Alessandro Astone 2023-03-27 23:01:07 UTC
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.

Comment 13 Adam Williamson 2023-03-27 23:34:20 UTC
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?

Comment 14 Adam Williamson 2023-03-28 00:38:35 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.