With gnome-base/libgnome-keyring masked for removal the only way for nextcloud-client to use a keyring is via qtkeychain (already a dependency) but only when the latter is built with USE=gnome-keyring . IIUC that's the only way for the client to store/retrieve secrets rather than prompting the user on every startup.
I hit this bug, too. Thank you Eduard for reporting this issue and providing a working solution!
Sigh, this keyring dependency continues to generate a lot of head scratching (bug 618032 and its duplicates/PR for example) I guess it is for historical reasons, but the gnome-keyring flag in qtkeychain is now misleading: it actually controls libsecret (freedesktop.org Secret Service API), not gnome-keyring anymore. With dependencies brought in being DE-agnostic libecret and glib, I guess depending on dev-libs/qtkeychain[gnome-keyring] is fine. It also avoids a potential libsecret USE-flag on nextcloud-client that would need to set another flag name on qtkeychain (or use incorrect gnome-keyring USE flag in nextcloud-client)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=05b920210417aadb353f7c5556d53372ddf055eb commit 05b920210417aadb353f7c5556d53372ddf055eb Author: Bernard Cafarelli <voyageur@gentoo.org> AuthorDate: 2021-01-07 13:29:23 +0000 Commit: Bernard Cafarelli <voyageur@gentoo.org> CommitDate: 2021-01-07 13:30:18 +0000 net-misc/nextcloud-client: depend on qtkeychain with USE=gnome-keyring Closes: https://bugs.gentoo.org/756772 Package-Manager: Portage-3.0.12, Repoman-3.0.2 Signed-off-by: Bernard Cafarelli <voyageur@gentoo.org> .../nextcloud-client-3.1.1-r1.ebuild | 90 ++++++++++++++++++++++ 1 file changed, 90 insertions(+)
