KDE provider is ready and available from version >=kde-frameworks/kwallet-5.97 See ebuild TODO. https://bugs.kde.org/show_bug.cgi?id=313216
Did you check that it works fine for you? See latest comment in the linked bug.
(In reply to Andreas Sturmlechner from comment #1) > Did you check that it works fine for you? My reason is install vscodium without gnome-keyring. It works. I am using gpg-agent for ssh and git. Kwallet used by NetworkManager to keep wifi credentials. It is normal non-GPG wallet, so i am not affected by deadlock bug.
Just as an extra word, I can also confirm kwallet works quite well for all the secret-service apps I have.
It seems - see the linked KDE bug - there are still problems with this, could someone who uses that desktop environment have a look into it? Detaching the PR from the ticket for now so that it does not get accidentally merged by someone doing house cleaning.
Maybe the union of providers should adopt it (+ kde@)?
Kwallet is apready installed here so it makes no sense for the package to want to install gnome-keyring. Just add kwallet to the list. Its not the fault of the virtual that kwallet has issues pinentry.
(In reply to C. Wijtmans from comment #6) > Kwallet is apready installed here so it makes no sense for the package to > want to install gnome-keyring. Just add kwallet to the list. Its not the > fault of the virtual that kwallet has issues pinentry. I found the phrasing of this confusing and "no sense" isn't right. However, secret service is indeed about the secret service API, not gpg integration. Therefore, the key question is whether https://bugs.kde.org/show_bug.cgi?id=313216 is fixed (not sure why Marecki dropped that one from the list).
I think, the question is that kwallet is an 'official' secret-service provider of KDE. It may (or may not) have issues with some configuration setup, such as when using GNuPG, but should the option to use it be closed for the users at the virtual level ? Especially when we now have a brand new KDE. As it stands, KDE users using anything requiring libsecret (such as Skype for instance) have to install third-party secret-service provider. I would think they should have chance to go with KDE option as KDE people felt fit to release - and take the bugs, if they still exist, to KDE upstream. of kwallet could be the least prioritized choice in virtual/secret-service
> (In reply to C. Wijtmans from comment #6) > > Kwallet is apready installed here so it makes no sense for the package to > > want to install gnome-keyring. Just add kwallet to the list. Its not the > > fault of the virtual that kwallet has issues pinentry. > > I found the phrasing of this confusing and "no sense" isn't right. > > However, secret service is indeed about the secret service API, not gpg > integration. > > Therefore, the key question is whether > https://bugs.kde.org/show_bug.cgi?id=313216 is fixed (not sure why Marecki > dropped that one from the list). Ksecretservice won't happen and bug 314216 is 13 years old (and issued under KDE4). I'm on KDE6 with 2 only Gnome apps; gimp and evolution. The only reason why I got Evolution is because dependencies of kmail are absolutely ridiculous for everyday home use. Kwallet authenticates my Outlook account in a way that is working perfectly in Evolution. Keepassxc also kind of works but I started to get issues with it with now almost dead Qt5.
Upcoming kwallet embraces libsecret finally (asturm added the relevant MR to the See Also list in this bug in 2023). But it'll still need another secret service provider/daemon, which for many may end up being keepass if they don't want gnome-keyring. (In reply to Francois Chenier from comment #9) I'm not sure what this adds to the bug other than the first sentence (but even then, I think we could all see that).
