Bug 430812 - Installation of "stuff" which has sub-packages, where one need to be select, made that update of system is stopped
Summary: Installation of "stuff" which has sub-packages, where one need to be select, ...
Alias: None
Product: Discover
Classification: Applications
Component: discover (show other bugs)
Version: unspecified
Platform: Neon Linux
: NOR normal
Target Milestone: ---
Assignee: Dan Leinir Turthra Jensen
: 428423 (view as bug list)
Depends on:
Reported: 2020-12-25 21:36 UTC by Piotr Mierzwinski
Modified: 2021-02-04 12:42 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.21


Note You need to log in before you can comment on or make changes to this bug.
Description Piotr Mierzwinski 2020-12-25 21:36:58 UTC
Today 24/12/2020 I started update in Neon DEV version, so unstable version of Neon distribution. Unfortunately update stopped at 66% - since 15 minutes progress didn't change. I discovered that installation of package like in subject caused this problem. Obviously this is really annoying when user cannot update system. I think issue seems to be related with KNewStuff backend.

In drive I had over 500MB free space.

Note I clicked into "Tasks" which shows progress of installation for package. Trying to stop it I clicked into "x" present in line "View updates - Installing" and happened nothing.

1. Having updates start Discover
2. Click "Update all"
3. Wait till will be installed any package coming from "KNewStuf"

Installation of system is stopped

Should be able to skip installation of package which has no progress since couple minutes or better any package should not block update.

Linux/KDE Plasma: YES
(available in About System)
KDE Plasma Version: 5.20.80
KDE Frameworks Version: 5.78.0
Qt Version: 5.15.2

Comment 1 Piotr Mierzwinski 2020-12-25 21:46:20 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
Comment 2 Piotr Mierzwinski 2020-12-29 23:04:41 UTC
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.
Comment 3 Piotr Mierzwinski 2021-01-06 21:41:52 UTC
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.
Comment 4 Dan Leinir Turthra Jensen 2021-01-15 11:46:19 UTC
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 ;)
Comment 5 Dan Leinir Turthra Jensen 2021-01-15 13:03:15 UTC
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.
Comment 6 Dan Leinir Turthra Jensen 2021-01-17 14:17:26 UTC
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

Comment 7 Bug Janitor Service 2021-01-18 13:54:07 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/discover/-/merge_requests/63
Comment 8 Dan Leinir Turthra Jensen 2021-01-19 13:21:59 UTC
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

Comment 9 Dan Leinir Turthra Jensen 2021-01-26 09:20:06 UTC
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

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

Comment 10 Piotr Mierzwinski 2021-02-04 12:42:13 UTC
*** Bug 428423 has been marked as a duplicate of this bug. ***