Bug 1930401 - No update notifications shown when updates available (F34, Rawhide)
Summary: No update notifications shown when updates available (F34, Rawhide)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-software
Version: 34
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa AcceptedFreezeException Accept...
Depends On:
Blocks: F34BetaFreezeException F34FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2021-02-18 19:51 UTC by Adam Williamson
Modified: 2021-03-16 00:28 UTC (History)
7 users (show)

Fixed In Version: gnome-software-40~beta-2.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-03-16 00:28:32 UTC
Type: Bug


Attachments (Terms of Use)
/var/log tarball from the failed test (1.48 MB, application/octet-stream)
2021-02-18 19:53 UTC, Adam Williamson
no flags Details

Description Adam Williamson 2021-02-18 19:51:06 UTC
Current F34 and Rawhide composes (with GNOME 40) don't seem to be showing notifications when system updates are available - openQA test desktop_notifications_postinstall fails consistently. This test boots to runlevel 3, installs a dummy low-versioned python3-kickstart package so we can be sure at least one update should be "available", pokes some magic GNOME settings to try and prevent heuristics suppressing the notification, then logs into the desktop and waits ten minutes, expecting the notification to show up. It doesn't. Example failure: https://openqa.fedoraproject.org/tests/782305

Proposing as a Final blocker, per criterion "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_34_Final_Release_Criteria#Update_notification

Comment 1 Adam Williamson 2021-02-18 19:53:15 UTC
Created attachment 1757887 [details]
/var/log tarball from the failed test

This is a tarball of /var/log from the above test. Nothing immediately jumps out to me, but maybe it will to you. You can use journalctl --file to examine the journal files in var/log/journal .

Comment 2 Milan Crha 2021-02-19 06:54:26 UTC
The times had been changed within:
https://gitlab.gnome.org/GNOME/gnome-software/-/issues/182
https://gitlab.gnome.org/GNOME/gnome-software/-/issues/947
following the new design:
https://gitlab.gnome.org/GNOME/gnome-software/-/issues/182#note_970125
which is also discussed here:
https://pagure.io/fedora-workstation/issue/107

How to get some useful information out of the gnome-software can be seen for example here:
https://pagure.io/fedora-workstation/issue/107#comment-713574

Comment 3 Milan Crha 2021-02-19 06:55:24 UTC
Direct design URL:
https://wiki.gnome.org/Design/Apps/Software/Updates#Tentative_Design

Comment 4 Adam Williamson 2021-02-19 18:54:42 UTC
Well, for the record, all this incredibly clever behaviour makes it really annoyingly hard to test that *any of it* is actually *working properly* :( It already took me two freaking days to figure out the previous heuristics and the most minimal and appropriate change to make the test handle them. Now I get to do it all again, apparently? That's great.

Comment 5 Adam Williamson 2021-02-19 18:57:42 UTC
It would help me immensely if someone could just summarize what, in concrete terms, was actually changed, instead of me having to dig through a veritable forest of tickets, PRs and design documents to figure it out. The design flowchart thing is somewhat understandable but did the actual changes exactly implement that?

Comment 6 Milan Crha 2021-02-22 08:24:59 UTC
(In reply to Adam Williamson from comment #5)
> ... instead of me having to dig through a veritable forest of tickets,
> PRs and design documents to figure it out.

Ah, right, I'm sorry. I wanted to give you a complete picture behind the reason of the changes.

> The design flowchart thing is somewhat understandable
> but did the actual changes exactly implement that?

Yes, the change follows the design chart.

What is your test supposed to test, please? Maybe I can give you some values to store to gsettings (and restart gnome-software) to trigger your test conditions (the update notification?).

Comment 7 Adam Williamson 2021-02-22 17:01:08 UTC
OK, if the change follows the design chart, then that's useful, but it begs an important question: how does Software / Shell decide whether an update is "critical"? Since that seems to heavily impact the behaviour.

The test is supposed to test that, when an update is definitely available, the user is shown a notification of that fact. As the Fedora release criteria require: "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image."

Comment 8 Milan Crha 2021-02-22 17:33:07 UTC
Looking into the code, the update is considered important when its urgency is critical or high. Which means, in case of PackageKit, that the update is marked either as a security update or as an important update, whatever that means for bodhi.

Comment 9 Geoffrey Marr 2021-02-22 20:15:21 UTC
Discussed during the 2021-02-22 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug was made as this may not be broken but rather the test may need updating for new heuristics in GNOME 40, we are delaying the decision while we work that out.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-02-22/f34-blocker-review.2021-02-22-17.07.txt

Comment 10 Geoffrey Marr 2021-03-01 21:27:25 UTC
Discussed during the 2021-03-01 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug was made as we're still waiting on adamw to check the new heuristics and update the openQA test here.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-03-01/f34-blocker-review.2021-03-01-17.01.txt

Comment 11 Adam Williamson 2021-03-04 00:41:05 UTC
Well, I tried adjusting the test to set all these gsettings keys to a value that should be three weeks before the current date:

update-notification-timestamp
online-updates-timestamp
upgrade-notification-timestamp
install-timestamp

as well as setting check-timestamp to two days previous, which it already did. I'm still not seeing any notifications with those changes. Do I need to do something even beyond this?

Comment 12 Milan Crha 2021-03-04 08:34:37 UTC
Could you point me to the test steps, please? I suppose it's a set of commands. I can try it here to see what it does and what not.

Comment 13 Adam Williamson 2021-03-05 01:55:37 UTC
well i just had it hacked up live on the staging server so far, I didn't commit it anywhere. Currently the test does this, before it logs in:

            # Also reset the 'last update notification check' timestamp
            # to >24 hours ago (as that matters too)
            my $now = script_output 'date +%s';
            my $yday = $now - 48*60*60;
            # have to log in as the user to do this
            script_run 'exit', 0;
            console_login(user=>get_var('USER_LOGIN', 'test'), password=>get_var('USER_PASSWORD', 'weakpassword'));
            script_run "gsettings set org.gnome.software check-timestamp ${yday}", 0;

so it figures out when 48 hours ago was as a timestamp, and sets org.gnome.software check-timestamp to that. I enhanced it to this:

            # Also reset the 'last update notification check' timestamp
            # to >24 hours ago (as that matters too)
            my $now = script_output 'date +%s';
            my $yday = $now - 2*24*60*60;
            my $longago = $now - 14*24*60*60;
            # have to log in as the user to do this
            script_run 'exit', 0;
            console_login(user=>get_var('USER_LOGIN', 'test'), password=>get_var('USER_PASSWORD', 'weakpassword'));
            script_run "gsettings set org.gnome.software check-timestamp ${yday}", 0;
            script_run "gsettings set org.gnome.software update-notification-timestamp ${longago}", 0;
            script_run "gsettings set org.gnome.software online-updates-timestamp ${longago}", 0;
            script_run "gsettings set org.gnome.software upgrade-notification-timestamp ${longago}", 0;
            script_run "gsettings set org.gnome.software install-timestamp ${longago}", 0;

but it still doesn't show any notifications after we subsequently log in to the desktop as the user "test".

Comment 14 Milan Crha 2021-03-05 12:42:17 UTC
I see. I debugged this and there is a bug in the code, which your test uncovered. I filled a merge request for it [1]. Once it's fixed, you can simply:

   $ gsettings reset-recursively org.gnome.software

and then start gnome-software. It'll check for the updates and ~a minute later a notification will show up. Or it did for me at least.

I would provide you a (scratch) build with this change, but it's failing in koji [2] due to unresolved dependencies, which is kinda out of my knowledge (and expectation, because I see a successful build of the missing package in koji).

[1] https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/643
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=63131694

Comment 15 Kalev Lember 2021-03-05 15:42:24 UTC
I created a buildroot override for the sysprof build that it needs, if you want to try again: https://bodhi.fedoraproject.org/overrides/sysprof-3.39.94-1.fc34

Comment 16 Adam Williamson 2021-03-06 00:50:02 UTC
We need to test that notifications appear without the user doing anything explicitly; basically we need to create as realistic as possible a scenario without leaving the test running for two weeks :D I think I'll stick to backdating the key values, it seems like the least worst choice. But thanks for fixing the bug. I'll see if I can get the build to work.

Comment 17 Adam Williamson 2021-03-06 01:39:08 UTC
The build failed because there wasn't a buildroot override for the newer sysprof build (with the subpackage name change) in place at the time. There is now, so I ran it again and it worked. Testing it now.

Comment 18 Adam Williamson 2021-03-06 01:52:39 UTC
OK, with that scratch build it does work. Thanks. Proposing as a Beta FE so we can get it fixed for Beta, seems worth fixing.

Comment 19 Milan Crha 2021-03-08 07:45:08 UTC
(In reply to Adam Williamson from comment #16)
> We need to test that notifications appear without the user doing anything
> explicitly

I'm not sure of the preconditions of your test environment, but if it's like running gnome-shell's update check for the first time, similar to getting the machine online after install, then you do not need to play with the GSettings at all, the things will work. The trick is to not get the updates "too early".

Comment 20 Geoffrey Marr 2021-03-08 19:55:15 UTC
Discussed during the 2021-03-08 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedFreezeException (Beta)" was made as it is a noticeable issue that cannot be fixed with an update.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-03-08/f34-blocker-review.2021-03-08-17.00.txt

Comment 21 Geoffrey Marr 2021-03-08 19:56:49 UTC
Discussed during the 2021-03-08 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion:

"Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image."

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-03-08/f34-blocker-review.2021-03-08-17.00.txt

Comment 22 Michael Catanzaro 2021-03-09 14:41:57 UTC
(In reply to Milan Crha from comment #8)
> Looking into the code, the update is considered important when its urgency
> is critical or high. Which means, in case of PackageKit, that the update is
> marked either as a security update or as an important update, whatever that
> means for bodhi.

That would be a bug then, because we explicitly requested that security updates *not* be tracked as critical. We have security updates every single day, and all your work was for nothing if it still results in daily update notifications.

The approved policy is that only updates marked "Urgent" in bodhi should be considered critical.

Comment 23 Milan Crha 2021-03-10 08:43:08 UTC
(In reply to Michael Catanzaro from comment #22)
> The approved policy is that only updates marked "Urgent" in bodhi should be
> considered critical.

I guess it had been requested in a different upstream bug then, or it had been overlooked. The new design discusses only times, not kinds of the updates.

Do you have a link to the upstream bug for the change of the update importance, please? Eventually, could you file one upstream, please?

Comment 24 Michael Catanzaro 2021-03-10 14:21:37 UTC
We were tracking this in https://pagure.io/fedora-workstation/issue/107, specifically https://pagure.io/fedora-workstation/issue/107#comment-700311 is a recent comment summarizing the approved policy. I'll reopen that issue now.

Comment 25 Fedora Update System 2021-03-10 18:41:08 UTC
FEDORA-2021-94a121ce8a has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-94a121ce8a

Comment 26 Fedora Update System 2021-03-11 19:51:06 UTC
FEDORA-2021-94a121ce8a has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-94a121ce8a`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-94a121ce8a

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 27 Fedora Update System 2021-03-16 00:28:32 UTC
FEDORA-2021-94a121ce8a has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.


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