Bug 1640701
Summary: | GNOME Software "update and restart" button appears to do nothing | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Stephen Gallagher <sgallagh> | ||||||
Component: | gnome-software | Assignee: | Richard Hughes <rhughes> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 29 | CC: | carl, gmarr, klember, kparal, lruzicka, mattdm, rhughes, robatino, sgallagh, sgraf, yulinux | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | AcceptedBlocker | ||||||||
Fixed In Version: | gnome-software-3.30.5-1.fc29 | Doc Type: | If docs needed, set a value | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2018-10-26 11:51:05 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: | 1517013 | ||||||||
Attachments: |
|
Proposed as a Blocker for 29-final by Fedora user sgallagh using the blocker tracking app because: "The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type in all release-blocking desktops (e.g. default graphical package manager)." While it's possible that this will work if left alone long enough, most users are going to assume after several minutes that this is broken. Discussed during the 2018-10-18 Fedora 29 Go/No-Go meeting: [1] The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criteria: "The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type in all release-blocking desktops." [1] https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2018-10-18/f29-final-go_no_go-meeting.2018-10-18-17.00.log.txt I can confirm this behavior. When you click Update&Restart, the repos are getting refreshed and packages are getting downloaded, which takes a long time (perhaps if updates are downloaded in background, this is not needed, but if you manually refresh the updates, this is what happens). However, the progress bar is somehow bugged and doesn't update properly (seems to be at 100% almost all the time), and on top of that, the progress bar is almost invisible (a single pixel line at the bottom of the Cancel button). All together it seems like gnome-software is stuck and not doing anything. Yes, I agree with Comment 3. This bug is not about functionality, rather about usability. Upstream merge request: https://gitlab.gnome.org/GNOME/gnome-software/merge_requests/128 On my system right now, with gnome-software-3.30.3-1.fc29.x86_64, when I push the Restart & Update, I get the restart dialog after several minutes, but then when I push "Restart & Isntall", I am returned to the desktop with nothing happening. libappstream-glib-0.7.14-2.fc29 gnome-software-3.30.5-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-b5a870dcff The update works for me, however, this does not solve the bug #1640701. The button changed to Download, which makes sense, but then I still see no progress or activity and I do not know whether packages are being downloaded or gnome-software got stalled. @frantisekz told me he would see the progress bar under the Cancel button in adwaita dark theme. I did not see anything in standard gnome theme. This should be fixed to work for everyone. gnome-software-3.30.5-1.fc29, libappstream-glib-0.7.14-2.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-b5a870dcff I can also confirm the progress bar is not fixed for me with the new version. It behaves the same as before, an almost complete progress bar is just a few pixels wide. I'll attach a screenshot. Furthermore, the refresh button doesn't refresh the repos, just reloads the existing caches (probably). After enabling updates-testing (to see some updates), I had to run "pkcon refresh force", because the refresh button took just a few seconds and didn't display the new updates. I don't know whether this is a recent regression, though, or even an expected behavior. I've also seen a case where gnome-software showed no available updates even after "pkcon refresh force", but dnf update showed many more available. I was only able to solve that by completely pruning /var/cache/PackageKit. Unfortunately I'm not able to reproduce it right now. Created attachment 1497140 [details]
progress bar in gnome-software
Tested by installing "System Updates" through gnome-software. Hit the "Update" button, was presented with a cancel button with a progress bar underneath, indicating progress. Then was presented with a "Restart and Install" button, which worked as expected. Note that I am using the standard gnome theme. However, I have just noticed that the "Refresh" button does not actually refresh the packages in the repos, like Kamil's experience in comment 10. Unlike Kamil's experience though, my progress bar is a full-button-wide progress bar and behaves as one would expect it to. Thanks for the testing! I'll see how many of those I can fix in a few days :) Richard is on vacation so it's just me working on this right now. I think of all the issues reported, pschindl's issue in the Bodhi ticket seems the most worrying as it can actually break updates without any way out: "I updated gnome-software and libappstream-glib and restarted. I downgraded gnome-calculator. Gnome-software updated updates and found update for g-c, but when I click on Download button it just blinks and nothing happens (even pkmon shows no action). So I can't update because there is still Download button and there is no 'Restart & update' button. With this version I'm unable to update." If it came to a question "is this good enough to ship in F29 GA", I think I could close an eye to the progress bar issues, but not pschindl's issue, I think that needs investigating/fixing. This seems a bit too fragile right now. I found a graphical glitch in gnome-software that causes extra packages to be displayed in available updates, see bug 1642878. I'm not sure whether it explains some of those errors mentioned here. I know for a fact that I had the opposite problem twice, gnome-software showing fewer (or no) updates than actually available, even after "pkconf refresh force". But I can't reproduce that right now. (In reply to Kamil Páral from comment #10) > Furthermore, the refresh button doesn't refresh the repos, just reloads the > existing caches (probably). After enabling updates-testing (to see some > updates), I had to run "pkcon refresh force", because the refresh button > took just a few seconds and didn't display the new updates. I don't know > whether this is a recent regression, though, or even an expected behavior. This should be fixed in https://gitlab.gnome.org/GNOME/gnome-software/commit/4e3dd2e94917742b111bbf860d0059116de7c973 (just a branch now, I'll play with this some more before pushing to master) (In reply to Kalev Lember from comment #13) > "I updated gnome-software and libappstream-glib and restarted. I downgraded > gnome-calculator. Gnome-software updated updates and found update for g-c, > but when I click on Download button it just blinks and nothing happens (even > pkmon shows no action). So I can't update because there is still Download > button and there is no 'Restart & update' button. With this version I'm > unable to update." I've seen this as well, Download going to Cancel (downloading) and then back to Download. After I rebooted, it was immediately changed to Restart&Update. However, I saw this with older dnf (dnf 3.6.1) and Petr was also using an older dnf. So it's possible this was caused by some bug in libdnf that was already fixed (there have been many fixes since then). I'd be concerned about this only if somebody could reproduce it with latest dnf. This shouldn't have anything to do with the dnf version. If it fails to transition from "Download" to "Restart & Update" then it's some kind of state keeping inside gnome-software going wrong. The core issue here has been fixed by gnome-software-3.30.5-1.fc29. There is now a Download button for the downloading phase. The other issues mentioned in this report have been split into individual reports here: https://bugzilla.redhat.com/show_bug.cgi?id=1643059 https://bugzilla.redhat.com/show_bug.cgi?id=1643444 https://bugzilla.redhat.com/show_bug.cgi?id=1643446 https://bugzilla.redhat.com/show_bug.cgi?id=1642878 gnome-software-3.30.5-1.fc29, libappstream-glib-0.7.14-2.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. |
Created attachment 1495315 [details] Screenshot of the cancel button Description of problem: Version-Release number of selected component (if applicable): gnome-software-3.30.3-1.fc29.x86_64 How reproducible: Every time Steps to Reproduce: 1. Have a Fedora 29 Workstation 2. Have some updates waiting to be applied. 3. Open GNOME Software and navigate to the updates tab. 4. Click on the "update and restart" button. Actual results: The button changes to a "cancel" button. Nothing happens for at least a few minutes. Clicking cancel aborts whatever it was doing. Expected results: Some sort of progress should be indicated and the system should reboot to apply updates. Additional info: Kalev tells me that it's a UX problem and that if I waited long enough, it would eventually complete. I waited at least five minutes; that's long enough for a user to assume that the process has hung.