Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1930401
Summary: | No update notifications shown when updates available (F34, Rawhide) | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> | ||||
Component: | gnome-software | Assignee: | Richard Hughes <rhughes> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 34 | CC: | gmarr, gnome-sig, klember, mcatanza, mcrha, rhughes, robatino | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | openqa AcceptedFreezeException AcceptedBlocker | ||||||
Fixed In Version: | gnome-software-40~beta-2.fc34 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2021-03-16 00:28:32 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 1829023, 1829024 | ||||||
Attachments: |
|
Description
Adam Williamson
2021-02-18 19:51:06 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 .
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 Direct design URL: https://wiki.gnome.org/Design/Apps/Software/Updates#Tentative_Design 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. 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? (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?). 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." 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. 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 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 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? 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. 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". 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 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 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. 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. 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. (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". 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 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 (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. (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? 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. FEDORA-2021-94a121ce8a has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-94a121ce8a 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. 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. |