| Summary: | Discover doesn't properly handle case where system is configured to prompt for authentication for updating Flatpaks | ||
|---|---|---|---|
| Product: | [Applications] Discover | Reporter: | Ilya Bizyaev <bizyaev> |
| Component: | Flatpak Backend | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | adam, aleixpol, andrea.ippo, jgrulich, nate, postix, sitter, travier, tustamido, ugur.alekperov, whyhow+tech |
| Priority: | HI | ||
| Version: | 6.0.2 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/discover/-/commit/90f329899d67924c5c3c392a528c87251cd1b7c9 | Version Fixed In: | 6.2.0 |
| Sentry Crash Report: | |||
| Attachments: | Discover error during flatpak update | ||
|
Description
Ilya Bizyaev
2023-02-27 21:10:55 UTC
seems bad I think what actually happens there is that it throws up an auth dialog for package0 and then moves on to package1 and that also needs an auth dialog but instead of waiting it just moves on with access denied. Seems a very niche way to setup flatpak since one basically has to individually authenticate every single update I think I wouldn't call it niche when it's the default in one of the major distros Ok I can confirm similar behaviour on openSuse tumbleweed. I just had to update approx 23 flatpaks and had to enter a password far too many times, it also failed after each one and had to re-start the update several times. While the password prompt was up, it was failing other packages in the background. Created attachment 160504 [details]
Discover error during flatpak update
Same here, also opensuse Tumbleweed. This is a long standing issue and quite annoying TBH A possibly relevant merge request was started @ https://invent.kde.org/plasma/discover/-/merge_requests/850 Git commit 90f329899d67924c5c3c392a528c87251cd1b7c9 by Harald Sitter. Committed on 30/08/2024 at 05:36. Pushed by sitter into branch 'master'. flatpak: merge transactions into a single transaction with multiple operations this change is comprised of two parts: This is a new object that seeks to merge multiple discover transactions into a single flatpak transaction (with multiple operations as part of it). The way this works is that instead of starting FlatpakJobTransactions right away we schedule them in the merger. The merger will then dispatch all transactions that have been made in a single eventloop run into one backing transaction. The threading code has been largely redone to deal with it being comprised of multiple operations on the backing side. The most interesting bit of code here is inside setCurrentRef and handles the transition from one ref to another. FlatpakTransactionThread holds a reference to all associated FlatpakJobTransaction and on-demand connnects/disconnects signals as necessary when the flatpak-side refs change. i.e. to the UI code it seems as though each FlatpakJobTransaction stands on its own because we direct signal emission accordingly. Talking about signals: to simplify locking concerns all interaction between the Thread and its current Transaction is done through signals. This goes so far that the current Transaction is only held as a void* such that one doesn't accidentally call it directly. M +111 -53 libdiscover/backends/FlatpakBackend/FlatpakJobTransaction.cpp M +6 -9 libdiscover/backends/FlatpakBackend/FlatpakJobTransaction.h M +195 -92 libdiscover/backends/FlatpakBackend/FlatpakTransactionThread.cpp M +52 -18 libdiscover/backends/FlatpakBackend/FlatpakTransactionThread.h https://invent.kde.org/plasma/discover/-/commit/90f329899d67924c5c3c392a528c87251cd1b7c9 |