Summary: | Installation of "stuff" which has sub-packages, where one need to be select, made that update of system is stopped | ||
---|---|---|---|
Product: | [Applications] Discover | Reporter: | Piotr Mierzwinski <piotr.mierzwinski> |
Component: | discover | Assignee: | Dan Leinir Turthra Jensen <leinir> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | admin, aleixpol, alexander.lohnau, nate, piotr.mierzwinski |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Neon | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/plasma/discover/commit/44e73b4eeab2bf0222ad93349d03b72f1817a61a | Version Fixed In: | 5.21 |
Description
Piotr Mierzwinski
2020-12-25 21:36:58 UTC
After restart of Discover turned out that all is up-to-date. I also checked this by in command line. Seems this was false alarm, only the problem is that application stopped work correctly in the middle of installation of NewStuff package Today this happened again. And stopper was the same package, so "Flat Remix ICON theme". This time update stopped on 50%. Trying to install this package by KNewStuff I discovered that this "stuff" points into couple packages where user needs to select one. I suppose this made that Discover stops of it looks like stops installation of updates. I noticed that when I update such stuff (here: "Flat Remix ICON theme") by "Get New Stuff" tool then Discover magically refresh view of installed packages and turns out that all packages are updated, whilst before I saw "50%" of progress. Right, thanks for spotting this. This is due to Discover not currently allowing users to make that decision you noticed the KNewStuff dialog asking about. I'll mark this as confirmed, and then poke at trying to sort it out :) The view refreshing magically (like you noticed) is because we try and make sure the views in different applications onto the same KNewStuff entries are kept in sync, which... frankly has been a little undertested perhaps, so thanks for confirming that that bit works ;) This MR is a partial fix - https://invent.kde.org/frameworks/knewstuff/-/merge_requests/90 It doesn't quite fix the underlying problem of not letting you pick which thing to actually do the update with and ends up with you having un-updateable entries in Discover, but it does result in Discover not having that never-ending update sat in tasks. Git commit 5e288f617f94fa29097ba12d2b020279e98d8bc8 by Dan Leinir Turthra Jensen. Committed on 17/01/2021 at 14:17. Pushed by leinir into branch 'master'. Reset entry to updateable when no payload is identified for updating As identified by Piotr in the bug mentioned below, Discover simply returns an invalid response for any Question forwarded to it. The result is that any update which fails to identify an update automatically will fail due to not having payload which should be used for updating identified. This patch fixes part of the issue, by resetting the entry for which no payload could be identified to Updateable rather than leaving it in limbo as Updating. This does not fix the bug in Discover, but it does at least alleviate the issue (it still leaves entries in Discover, rather than updating them, but without having a way to forward that question to the user, there's not a lot to be done about that other than output an error message with instructions to use the GHNS dialog to do that particular update, which of course is not exactly up to par... so, not closing the bug with this, the issue in Discover still needs sorting out... somehow). M +4 -0 src/core/engine.cpp M +1 -1 src/core/errorcode.h https://invent.kde.org/frameworks/knewstuff/commit/5e288f617f94fa29097ba12d2b020279e98d8bc8 A possibly relevant merge request was started @ https://invent.kde.org/plasma/discover/-/merge_requests/63 Git commit 44e73b4eeab2bf0222ad93349d03b72f1817a61a by Dan Leinir Turthra Jensen. Committed on 19/01/2021 at 13:21. Pushed by leinir into branch 'master'. Forward installer update error (so user is informed of their options) As discovered by Piotr, attempting to update some KNewStuff originated packages in Discover results in the update not in fact being updated, without anything happening in Discover apart from the update just staying around in the UI. This patch forwards an error from KNSCore::Engine which gives some further information as to what the user can do to perform this update. This is a half-solution to the problem, as the TODO added in here suggests, but it seems to me better to be explicit about the problem to our users, rather than just not doing anything, and informing them how they can fix it themselves. Until we have a full query system for Discover's transactions, this seems likely to be the best we can do (and actually implementing that system will take some time to get right, and we don't want to just ignore the problem until them). M +18 -1 libdiscover/backends/KNSBackend/KNSBackend.cpp https://invent.kde.org/plasma/discover/commit/44e73b4eeab2bf0222ad93349d03b72f1817a61a Git commit 365191346f0fd2d235fb33828056a48e7f3161ae by Dan Leinir Turthra Jensen. Committed on 26/01/2021 at 09:20. Pushed by leinir into branch 'master'. Add support for kns:/ urls to the knewstuff-dialog tool This adds in support for the kns URLs used in e.g. kpackagetool to canonically reference a specific entry found on a knewstuff provider. The result is that by passing in such a URL to the knewstuff-dialog tool, we interpret this as wanting to show the details for that specific entry. The origin of this functionality was a short discussion on https://invent.kde.org/plasma/discover/-/merge_requests/63 where the need for such functionality became obvious. M +24 -0 src/core/engine.cpp M +22 -2 src/core/engine.h M +12 -0 src/qtquick/qml/Button.qml M +12 -0 src/qtquick/qml/Dialog.qml M +12 -0 src/qtquick/qml/DialogContent.qml M +67 -0 src/qtquick/qml/Page.qml M +20 -0 src/qtquick/quickitemsmodel.cpp M +10 -0 src/qtquick/quickitemsmodel.h M +19 -1 src/tools/knewstuff-dialog/main.cpp M +4 -1 src/tools/knewstuff-dialog/qml/dialog.qml https://invent.kde.org/frameworks/knewstuff/commit/365191346f0fd2d235fb33828056a48e7f3161ae *** Bug 428423 has been marked as a duplicate of this bug. *** |