SUMMARY *** The problem first occurred several months, probably almost a year ago (I know that I've written about it on KDE Forums in April, but then I have had it already for some time). It's a minor nuisance, so I've never reported a bug before, but as now I have time, I'm going to do so... When I install updates using Discover, the progress bar freezes at 49% (when the downloading ends and installation is supposed to start). The installation process goes just fine, and at the end all the updates are installed properly and finally Discover jumps directly from "49%" to "Your system is up to date", it's just that during that process I have no information about its progress. *** STEPS TO REPRODUCE 1. Open Discover when new updates are available 2. Launch the update process 3. OBSERVED RESULT The progress bar follows the progress in downloading the packages up to 49%, when download ends. Then it freezes at stays at 49% until the update installation and configuration is finished. EXPECTED RESULT The progress bar should follow the installation process smoothly from 49% up to 100%, indicating its, nomen omen, progress. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kde Neon 5.23 (available in About System) KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.89.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION n/a
When this happens, are there any Snap or Flatpak apps in the set of available updates? Or is everything from Neon?
It happens at each and every update or I have no apps installed from flatpak ("flatpak list" returns an empty string) "snap list" returns only six entries (bare, chromium, core18, gnome-3-28-1804, gtk-common-themes and snapd), so I would guess that it does not depend from snap nor flatpak...
Thanks. Does it happen if you run updates only from the distro itself by opening Discover from a terminal window like so: plasma-discover --backends packagekit-backend
I did what you had suggested, and let's say that - as this week there was 0.4 GB worth of updates - I've spent the longest 25 min in my life staring at the progress bar stuck at 49%... I have no clue if it will be of any use, but here is the konsole output of the whole operation: witwinowski@witwinowski-Aspire-X1930:~$ plasma-discover --backends packagekit-backend adding empty sources model QStandardItemModel(0x5634e32bd060) file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/private/PrivateActionToolButton.qml:74:5: QML Binding: Binding loop detected for property "value" file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/private/RefreshableScrollView.qml:175:13: QML Binding: Not restoring previous value because restoreMode has not been set. This behavior is deprecated. You have to import QtQml 2.15 after any QtQuick imports and set the restoreMode of the binding to fix this warning. In Qt < 6.0 the default is Binding.RestoreBinding. In Qt >= 6.0 the default is Binding.RestoreBindingOrValue. file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/BasicListItem.qml:261:18: QML QQuickItem*: Binding loop detected for property "implicitWidth" file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/private/RefreshableScrollView.qml:175:13: QML Binding: Not restoring previous value because restoreMode has not been set. This behavior is deprecated. You have to import QtQml 2.15 after any QtQuick imports and set the restoreMode of the binding to fix this warning. In Qt < 6.0 the default is Binding.RestoreBinding. In Qt >= 6.0 the default is Binding.RestoreBindingOrValue. took really long to fetch PackageKitBackend(0x5634e33431d0) Hspell: can't open /usr/share/hspell/hebrew.wgz.sizes. kf.sonnet.clients.hspell: HSpellDict::HSpellDict: Init failed file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/private/globaltoolbar/ToolBarPageHeader.qml:83:13: QML Binding: Binding loop detected for property "value" file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/private/globaltoolbar/ToolBarPageHeader.qml:88:13: QML Binding: Binding loop detected for property "value" witwinowski@witwinowski-Aspire-X1930:~$
Thanks you for your patience, it's much appreciated. :) It wasn't for nothing; now we know it's an issue with the PackageKit backend, or how PackageKit itself communicates progress to Discover when using the apt-specific backend. We have gotten other similar reports of this in the past from users of Ubuntu-based distros, so marking this as confirmed.