| Summary: | Overall update progress reporting is jumpy and inaccurate | ||
|---|---|---|---|
| Product: | [Applications] Discover | Reporter: | Michael <michael.hmich> |
| Component: | Updates (interactive) | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | 4wy78uwh, aleixpol, bugseforuns, david.cortes.rivera, dougshaw77, luca.pedrielli, nate, null, postix, yvan |
| Priority: | HI | ||
| Version: | 5.21.3 | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=411827 | ||
| Latest Commit: | https://invent.kde.org/plasma/discover/commit/336becd3ad0f8aa5b18d3c61b38c15d81a3f3544 | Version Fixed In: | 5.26.1 |
| Sentry Crash Report: | |||
| Attachments: |
discover upgrade bundle
neon discover upgrade "offline upgrade" attachment-2084-0.html |
||
|
Description
Michael
2021-04-07 07:37:17 UTC
Yes, this is a problem, especially when you have items from multiple backends. For example when you have one update for a Flatpak app and 900 package updates from PackageKit, Discover will first update the one Flatpak app and report the overall progress percentage to be 50%! It seems like the overall percentage is simply the sum of each individual backend's average progress, divided by the number of backends. This is wrong; it should be the average of all individual items' progress aggregated from all backends. Fixing this would probably provide a huge boost in users' perception of Discover's quality. *** Bug 416624 has been marked as a duplicate of this bug. *** *** Bug 431701 has been marked as a duplicate of this bug. *** Created attachment 137426 [details]
discover upgrade bundle
Created attachment 137427 [details]
neon discover upgrade "offline upgrade"
fortunately there was an upgrade now but it got worse the upgrade packages are bundled into 1, you can expand and see what is in there but apparently no change is possible then in good old windows fashion a reboot is required and the packages are installed before reaching graphical target, finishing it reboots again ... For offline updates, it's a different matter. Is that what you were talking about all along, or is this a new thing you're reporting? Created attachment 137437 [details] attachment-2084-0.html there is no choice for online or offline, all this pkgs in the blue frame are one bundle, I haven't seen this before and the last neon mega update was last week I think it is part of this issue even if it wasn't there before today's update On Thu, Apr 8, 2021 at 1:14 PM Nate Graham <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=435450 > > --- Comment #7 from Nate Graham <nate@kde.org> --- > For offline updates, it's a different matter. Is that what you were talking > about all along, or is this a new thing you're reporting? > > -- > You are receiving this mail because: > You reported the bug. Neon very recently changed to do offline updates by default. So it looks like this changed for you as a part of that switcheroo. This bug report is about interactive updates; can you please file a new bug report for offline updates? Thanks! I understand, the new issue is #435525 thanks *** Bug 441926 has been marked as a duplicate of this bug. *** *** Bug 411827 has been marked as a duplicate of this bug. *** actually, the process is running visibly much better now with Plasma 5.24.4 the progress bar of each individual package is working, showing something I mean the upgrade itself is working fine, but is still dark matter the overall progress is not exactly tranquilizing because it's hard to say what is going on, I believe the download should complete before the next begins, now the threads are running all together, not sure if this is really a good thing, for us normal users it is voodoo we can not follow, whatsoever it is working and never gave me any problem what is really missing is the option setting packages on hold, when comes the bunch of upgrades it is quite annoying going through the list and unclick one or another, I know I can set the hold from CLI, but it could be an unnecessary step A possibly relevant merge request was started @ https://invent.kde.org/plasma/discover/-/merge_requests/386 Git commit 8226ddf15fd7f04b18fc2d2f571215b695a9b2bb by Aleix Pol Gonzalez, on behalf of Aleix Pol. Committed on 13/10/2022 at 15:52. Pushed by apol into branch 'master'. flatpak: Address transaction progress skipping Flatpak transaction progress skips back and forth as it is reported according its different operations. Report the progress according equally split among the different operations. Related: bug 404819, bug 434948, bug 448280 M +10 -4 libdiscover/backends/FlatpakBackend/FlatpakTransactionThread.cpp M +3 -0 libdiscover/backends/FlatpakBackend/FlatpakTransactionThread.h M +6 -0 libdiscover/backends/FlatpakBackend/tests/FlatpakTest.cpp https://invent.kde.org/plasma/discover/commit/8226ddf15fd7f04b18fc2d2f571215b695a9b2bb Git commit 336becd3ad0f8aa5b18d3c61b38c15d81a3f3544 by Nate Graham, on behalf of Aleix Pol. Committed on 13/10/2022 at 16:07. Pushed by ngraham into branch 'Plasma/5.26'. flatpak: Address transaction progress skipping Flatpak transaction progress skips back and forth as it is reported according its different operations. Report the progress according equally split among the different operations. Related: bug 404819, bug 434948, bug 448280 (cherry picked from commit 8226ddf15fd7f04b18fc2d2f571215b695a9b2bb) M +10 -4 libdiscover/backends/FlatpakBackend/FlatpakTransactionThread.cpp M +3 -0 libdiscover/backends/FlatpakBackend/FlatpakTransactionThread.h M +6 -0 libdiscover/backends/FlatpakBackend/tests/FlatpakTest.cpp https://invent.kde.org/plasma/discover/commit/336becd3ad0f8aa5b18d3c61b38c15d81a3f3544 |