SUMMARY Lately, Kasts just gets disconnected from Nextcloud gpodder, and refuses to reconnect. Within the Kasts synchronization settings, it says "synchronization disabled" (or something like that, it's not in English). If I then click "Log in", enter my nextcloud credentials, and click OK, the login window closes, but absolutely nothing seems to happen in Kasts. In the nginx log I see one call to /index.php/apps/gpoddersync/subscriptions?since=0 (returning a 200), and nothing more. I could get sync working again by removing the Kasts settings and re-logging in, but it soon got disconnected again. SOFTWARE/OS VERSIONS Operating System: openSUSE Leap 15.5 KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 5.14.21-150500.55.39-default (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 1700X Eight-Core Processor Memory: 62.7 Gibyte of RAM Graphics Processor: AMD Radeon RX 6500 XT ADDITIONAL INFORMATION I recently updated from
> ADDITIONAL INFORMATION > I recently updated from I recently updated from the plasma/kwin/frameworks in the main repos to the latest version in the KDE:Frameworks5 repo.
Could you perhaps run kasts from the command line with QT_LOGGING_RULES=org.kde.kasts.sync=true kasts or, if it doesn't produce too much output, with QT_LOGGING_RULES=org.kde.kasts.*=true kasts This should give some additional debug output that could point to why it's not syncing anymore. PS: Most of the issues that I have encountered so far that are showing these symptoms, are due to kasts not being able to connect to the keychain application that has stored the password.
*** Bug 479907 has been marked as a duplicate of this bug. ***
Another question: are you using the native distro package or the flatpak (or something else)? This really matters due to the potential problems with sandboxing of flatpaks.
Created attachment 164970 [details] QT_LOGGING_RULES=org.kde.kasts.*=true flatpak run org.kde.kasts It's the flatpak version. Here's the output from "QT_LOGGING_RULES=org.kde.kasts.*=true flatpak run org.kde.kasts", when I start Kasts and try to log into sync. I don't see the password being added to Kwallet, so that indeed probably is the issue.
If I run "secret-tool lookup user <username>" within flatpak on that machine I get: "secret-tool: user interaction failed". Running the exact same command outside flatpak on that machine, or inside flatpak on a different machine that doesn't have this problem, returns the correct password.
(In reply to Linus Kardell from comment #6) > If I run "secret-tool lookup user <username>" within flatpak on that machine > I get: "secret-tool: user interaction failed". Running the exact same > command outside flatpak on that machine, or inside flatpak on a different > machine that doesn't have this problem, returns the correct password. It indeed looks like that's the main issue. It seems that the issues are not directly related to Kasts, but rather to something having changed in either the flatpak runtime or your specific keychain tool (on the non-flatpak, system side). Unfortunately, there's not much I can do right now, since I'm not able to reproduce it on my side (which would suggest that the flatpak runtime is probably not the culprit, because then it would be reproducible everywhere).
Tried downgrading kasts ("flatpak update --commit=00b9854e9cca35d723abf6c0a98a21be21471a327f661f8406b533f1d86d69f1 org.kde.kasts"), and then secret-tool starts working, and sync gets reenabled in Kasts. But if I update to the latest (a9e7321ffeb9b1685caca8a8d53f6fb51c3d23d6359baf1a41ec9c29744d4b36) again, secret-tool/sync stops working again.
Looks like that commit (https://github.com/flathub/org.kde.kasts/commit/e8901209ab3e50eee090ad9d2c506fb80db57f1e), undid the change from https://github.com/flathub/org.kde.kasts/pull/7/commits/6c12efef965cdb0cf17fccd15f5b42291c845fbb that worked around the issue at https://bugs.kde.org/show_bug.cgi?id=451836.
(In reply to Linus Kardell from comment #9) > Looks like that commit > (https://github.com/flathub/org.kde.kasts/commit/ > e8901209ab3e50eee090ad9d2c506fb80db57f1e), undid the change from > https://github.com/flathub/org.kde.kasts/pull/7/commits/ > 6c12efef965cdb0cf17fccd15f5b42291c845fbb that worked around the issue at > https://bugs.kde.org/show_bug.cgi?id=451836. Thanks for reminding me of my own workarounds from the past. :facepalm: I had forgotten the underlying reason for the -Dgcrypt=false. Having said that, I had to remove it from the flatpak manifest, because that option simply doesn't exist anymore with libsecret > 0.21. So it was necessary for the flatpak to build. The puzzling thing is that it works perfectly fine for me with multiple keychain backends, while in the past it would consistently fail without -Dgcrypt=false. It would be nice to have a problem which is reproducible everywhere. Going through the libsecret documentation, I think I've found the replacement option. So let me try to set up a PR with those changes. Would you be ok testing the automatic build generated by that PR to see if it helps?
>Would you be ok testing the automatic build generated by that PR to see if it helps? The build has finished: see https://github.com/flathub/org.kde.kasts/pull/50 You can install the test build with (instructions also in the PR mentioned above): flatpak install --user https://dl.flathub.org/build-repo/77255/org.kde.kasts.flatpakref
>flatpak install --user https://dl.flathub.org/build-repo/77255/org.kde.kasts.flatpakref Yes, sync does appear to work correctly on that branch
Closing because bug was resolved through flatpak manifest. Feel free to re-open if it's not solved yet.