Since gnome-software-44~beta-1 landed in F38 and Rawhide, update notifications are not being shown when they should be in openQA. There's an openQA test that boots, makes sure an update is available, sets a bunch of gsettings and so on to try and make sure an update notification should appear, then waits ten minutes for one to appear. It hasn't seen a notification on Rawhide or F38 since gnome-software 44-beta landed. Not sure yet what change might be the cause. This would appear to be 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.", unless it's just that some heuristic got added or changed and now the test needs to do more messing around to defeat it.
Created attachment 1945809 [details] /var/log tarball from a failed run of the test
Is the update prepared? i.e. are all updates already downloaded, GNOME Software shows a button to reboot and install updates rather than a button to download updates, and checkbox to install updates visible on gnome-shell shutdown dialog? Update notifications were broken from F34 through F37 GA and only recently fixed. It's never supposed to notify unless an update is actually prepared. That fix could have broken your test.
Alternatively, if you turn off the Automatic Updates setting so that it never downloads updates automatically, then it should notify you. Flipping that setting might work to fix your test, although you'd then be testing a non-default configuration.
I've no idea. It gets ten minutes, which should be long enough to download the updates (the server it would use is on the same network). What do the logs say? I always find them rather hard to interpret. Is there any kind of artificial delay between an update being "available" and g-s "preparing" it which I need to whack with a hammer?
also, what it's expecting is a notification to show up in the notification area that shows up when you click the clock. That's the kind of 'notification' we're expecting. If you only find out that an update has been prepared by running g-s and looking at what the update tab says, the test is not going to see that.
Thanks for a bug report. Unfortunately, I do not know how to open the journal log from the attached archive. I doubt there's logged the `--verbose` run of the gnome-software, is there? With respect of the latest changes, there had been merged Michael's proposed change related to the notifications. As he mentions above, it notifies now only if the update is prepared. It works like this: - gnome-software is started - the repo/remote info is updated (when automatic updates are on) - the GUI populates (can be in background), including check for the Updates page - a minute after gnome-software's start the update-monitor refreshes information about the updates (meaning real refresh, checking for new updates as well) - once done, the online (Flatpak) updates are installed and offline (PackageKit) updates are downloaded - once done, the notification is or is not shown When having the `gnome-software --verbose` log, one can search it for "should_notify_about_pending_updates" (quotes for clarity only), around which is printed some information related to the notification.
I forgot to mention, there had been done a giant change [1] just before the 44.beta release, which changes these update-related actions heavily. Michael's change [2] is part of the 44.alpha. [1] https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/1616 [2] https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/1565
Okay, it's a regression from the giant last minute change. I opened a fix for it here: https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/1635
Thanks! Since we have a fix I'll propose this as a Beta FE, it would be good to have this fixed for Beta. For the record, journalctl has a `--file` option: you can do `journalctl --file var/log/journal/(press tab here)/system.journal`. Caveats: occasionally upstream changes the format such that an older journalctl can't read a newer journal file - there was such a change either between 36 and 37 or 37 and 38, I forget which. In that case you need to run a newer journalctl somehow, e.g. from a mock root or toolbox container. Sometimes some weird file rotation thing happens and you also get files with names like `system` (as in this tarball) - you can open those files the same and they'll contain the messages from a different time period, you just have to open each file till you hit the relevant time period.
FEDORA-2023-e71fa85ef5 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-e71fa85ef5
FEDORA-2023-e71fa85ef5 has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-e71fa85ef5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
openQA confirmed the fix works, thanks.
There is planned an official gnome-software release by the end of this week, I guess on Friday 03/03.
Discussed in ticket: https://pagure.io/fedora-qa/blocker-review/issue/1049 The decision to classify this bug as an FreezeException was made: "it would be good to have this fixed for Beta as it would be Final Blocker."
FEDORA-2023-e71fa85ef5 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.