Bug 1659231 - No update notifications in current Fedora Rawhide (3.31.2)
Summary: No update notifications in current Fedora Rawhide (3.31.2)
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-software
Version: rawhide
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa
Depends On:
Blocks: F30FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2018-12-13 20:49 UTC by Adam Williamson
Modified: 2018-12-17 18:22 UTC (History)
3 users (show)

Fixed In Version: gnome-software-3.31.1-2.fc30
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-12-17 18:22:00 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Adam Williamson 2018-12-13 20:49:02 UTC
In current Fedora Rawhide, update notifications do not seem to appear. I installed from a recent live image - 20181211.n.0 - completed initial setup and so on, and waited for half an hour; no update notification appeared. However, if I run Software and go to the Updates tab, it immediately (without refreshing) shows 4 updates. So at some level update checking is happening and working, but for some reason, no notification is being displayed...

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

Comment 1 Adam Williamson 2018-12-13 22:03:34 UTC
To be clear here - openQA tests are showing this, but I also reproduced it manually by just doing a clean fresh live install. It has always been the case that, if any updates are available the very first time you boot a freshly-installed system and log in as a new user, a notification will show. *After* that, all GNOME's weird rules about not checking for another X days and not showing notifications for another Y days and all the rest of it kick in.

The openQA test history is quite interesting, actually. It seems like this passed pretty consistently from like April 2018 up till Fedora-Rawhide-20180707.n.2 , when it failed; it then failed occasionally until Fedora-Rawhide-20180813.n.0 (4 out of 15 tries between those two composes). The next compose where the test actually ran was Fedora-Rawhide-20180906.n.0 (that means the composes in between failed, or they succeeded but were so broken openQA didn't get to the point of running this test); the test failed in that compose. From then on it's failed *nearly* every time, but it succeeds *occasionally* - 5 passes from 39 attempts.

I'm not immediately seeing anything in the gnome-software git history that lines up nicely with those dates, though there definitely *have* been quite a lot of changes in gs-update-monitor.c over that overall timespan.

Comment 2 Kalev Lember 2018-12-14 08:18:51 UTC
This should be already fixed upstream in commit https://gitlab.gnome.org/GNOME/gnome-software/commit/23f0f57fdf8c6d7c0cddb3db00283ac8226803e6 . The commit message is a bit misleading because I didn't realize the full extent of what this was fixing up until now.

I'll go and backport that fix to rawhide now.

Comment 3 Kalev Lember 2018-12-14 08:25:40 UTC
OK, gnome-software-3.31.1-2.fc30 build is under way. I'll put the ticket ON_QA, can you verify the fix in openQA please and close it if it works?

Comment 4 Adam Williamson 2018-12-14 16:32:24 UTC
Hah - yeah, I went through the commits, and yeah, I didn't spot that that was a fix for this :)

Sure, I'll keep an eye on the results from the next compose.

Comment 5 Adam Williamson 2018-12-17 18:22:00 UTC
Yup, test passed in most recent compose: https://openqa.fedoraproject.org/tests/320293#step/desktop_notifications/38 . Thanks!


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