Since GNOME Software moved to the dnf5 backend, update notifications are broken, at least in openQA testing. The openQA test does these steps to try and reliably trigger an update notification: 1. Force the system clock to 6am (to defeat the 'no update check before 6am' heuristic) 2. Set gsettings set org.gnome.software check-timestamp to a timestamp for the day before yesterday 3. Set org.gnome.software update-notification-timestamp to a timestamp for two weeks ago 4. Set org.gnome.software online-updates-timestamp to a timestamp for two weeks ago 5. Set org.gnome.software upgrade-notification-timestamp to a timestamp for two weeks ago 6. Set org.gnome.software install-timestamp to a timestamp for two weeks ago 7. Remove the acpica-tools package 8. Install a dummy, low-versioned acpica-tools package It does all this from multi-user.target. It then starts graphical.target, logs in to a desktop, and waits for an update notification to appear. This has been a very reliable procedure for years, and I don't see immediately any reason it should not be valid for the dnf5 plugin. But the test is consistently failing - we never see an update notification. Proposing as a Final blocker per "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_43_Final_Release_Criteria#Update_notification - and also as a Beta FE, as obviously it would be good for this to work in Beta if possible.
From the verbose log: 08:07:56:413 Gs got 1 updates 08:07:56:414 Gs Received 1 apps to update, 0 are online and 1 offline updates; will download online updates 08:07:56:414 Gs should_notify_about_pending_updates: last_test_days:365 n-apps:1 should_download:1 can_download:1 has_important:0 all_downloaded:0 any_downloaded:0 res:0 08:07:56:414 Gs No update notification needed when it found several package updates. I'll see what changed it, possibly something in the upstream gnome-software (aka not related to the dnf5 plugin).
Weird, I get the same with gnome-software-48.4-1.fc42.x86_64 PackageKit-glib-1.2.8-9.fc42.x86_64 11:49:25:225 Gs should_notify_about_pending_updates: last_test_days:0 n-apps:1 should_download:1 can_download:1 has_important:0 all_downloaded:1 any_downloaded:1 res:0 11:49:25:226 Gs No update notification needed
I suppose you expect a notification: Updates Ready to Install Software updates are ready and waiting Looking how it works, it's shown only if the updates are locally downloaded, which does not happen in my case (both rawhide and f42). I see the problem with rawhide is also because I abuse "install-timestamp" GSettings key. The gnome-software uses it to set when it notified about past updates. I set it to the current date/time to avoid the bug #2391893 , but I see I should do it differently. Let me think about some other approach.
The Fedora quality expectation is that, when updates are available for the system, a notification of them should be shown. Whether they should be auto-downloaded and a notification about *that* shown, or just a notification shown that an update is *available for download*, is an implementation detail that does not matter so far as the criteria are concerned. But we do want there to be a notification. There's some subtlety here, I think - like some prior effort to 'batch' update notifications is the reason the test sets various timestamps to more than two weeks ago (to make sure any such 'batching' mechanism thinks it's long enough since the last one happened that it should create a new one). We can extend the test to work around other reasonable complications of a given desktop's approach that still meet the spirit of the criteria, if necessary. Before the PK->dnf5 switch, the notification we got was indeed "ready and waiting", yeah. https://openqa.fedoraproject.org/tests/3514468#step/desktop_notifications/42
+4 Final blocker / +5 Beta FE in https://pagure.io/fedora-qa/blocker-review/issue/1893 , marking accepted as both.
Okay, thanks for the confirmation. I've something ready, which worked here (in my setup), I'll create an update for it.
FEDORA-2025-167d00534c (gnome-software-49~rc-2.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-167d00534c
FEDORA-2025-167d00534c has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-167d00534c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-167d00534c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-167d00534c (gnome-software-49~rc-2.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
It doesn't look like that update actually fixed the missing notifications: https://openqa.fedoraproject.org/tests/3711653#step/desktop_notifications/35 I guess the revert to PK ought to, so I'll mark that update as fixing this.
FEDORA-2025-7f21f13867 (gnome-software-49~rc-3.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-7f21f13867
FEDORA-2025-7f21f13867 (gnome-software-49~rc-3.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
The revert to PK was only done on F43. Rawhide is still on dnf5. And, from the latest Rawhide test - https://openqa.fedoraproject.org/tests/3727103#step/desktop_notifications/43 - this is still broken there. Re-opening.
Moving the FE/blocker statuses to F44.
While trying to reproduce in my rawhide machine using the steps from the description: > 4. Set org.gnome.software online-updates-timestamp to a timestamp for two weeks ago There is no `online-updates-timestamp`, available keys for gnome-software-49.0-1.fc44 are: $ gsettings list-keys org.gnome.software | grep timestamp check-timestamp flatpak-purge-timestamp install-timestamp packagekit-historical-updates-timestamp security-timestamp update-notification-timestamp upgrade-notification-timestamp I did not touch the clock, it was past 6am already. Then I used (in bash): gsettings set org.gnome.software check-timestamp $((`date --utc "+%s"`-(24*60*60*2))) gsettings set org.gnome.software update-notification-timestamp $((`date --utc "+%s"`-(24*60*60*15))) gsettings set org.gnome.software upgrade-notification-timestamp $((`date --utc "+%s"`-(24*60*60*15))) gsettings set org.gnome.software install-timestamp $((`date --utc "+%s"`-(24*60*60*15))) using 15 days, not 14. I downgraded vim and Epiphany. Then I started gnome-software and I've been notified that "Software updates had been installed" and the Updates tab showed system updates and Epiphany (both RPM). A minute after start the verbose log of the gnome-software showed: 12:42:12:349 Gs got 2 updates 12:42:12:349 Gs Received 2 apps to update, 0 are online and 2 offline updates; will download online updates 12:42:12:349 Gs should_notify_about_pending_updates: last_test_days:0 n-apps:2 should_download:1 can_download:1 has_important:0 all_downloaded:0 any_downloaded:0 res:0 12:42:12:349 Gs No update notification needed The `last_test_days` corresponds to `update-notification-timestamp` key. This key is reset also when `Software Updates Installed` notification is shown. This is in the core gnome-software, not in the dnf5 plugin. What the dnf5 plugin does differently is that it notifies about the past updates, which are in my case those downgrades I did few minutes ago, when preparing the test. The dnf5 plugin uses `packagekit-historical-updates-timestamp` key as a key date since which to report about the past updates. It's because the dnf5 can report about changes since some time, examining its own log, while the PackageKit has only a single file for a single offline update where it stores either what had been updated in the offline or why it failed. The file changes every update and it can hold only the last change/update, which is rather limiting. When I also reset the PackageKit key with: gsettings set org.gnome.software packagekit-historical-updates-timestamp `date --utc "+%s"` , thus the dnf5 plugin does not report any past updates, and then I run gnome-software, then the verbose log says this time: 12:56:15:320 Gs got 2 updates 12:56:15:320 Gs Getting updates, because install timestamp is more than 14 days ago . . . 12:56:16:540 Gs running UpdateApps job, elapsed time since creation 1219ms 12:56:16:540 Gs should_notify_about_pending_updates: last_test_days:15 n-apps:2 should_download:1 can_download:1 has_important:0 all_downloaded:1 any_downloaded:1 res:1 reason:Updates Ready to Install|Software updates are ready and waiting 12:56:16:540 Gs Notify about update: 'Updates Ready to Install' 12:56:16:540 Gs updates-changed and the notification is shown. The dnf5 plugin uses also the packagekit-historical-updates-timestamp key, but the dnf5 plugin code does nothing when this timestamp key is not set (is set to 0), thus fresh newly installed machine should not notify about any past updates. I tried that and using: gsettings reset org.gnome.software packagekit-historical-updates-timestamp also does not notify about the past updates and I receive "Updates Ready to Install" notification, as expected. The dnf5 plugin changes value of this PackageKit plugin key only if offline updates are scheduled by the dnf5 plugin - it's needed to have a consistent list of the past updates. Is it possible something in the tests touches the packagekit-historical-updates-timestamp key? I do not know why the notification about the past updates also resets the notification time stamp key. I think it's in error, but I need to check why it was added. If it'll turn as a bad thing, I'll propose a change to the gnome-software upstream.