see https://bugs.gentoo.org/756772 - please undo this. nextcloud works fine with kde wallet without gnome-keyring. I had never gnome-keyring installed and I don't want to install it.
You are aware that the "gnome-keyring" USE flag of dev-libs/qtkeychain package does not pull in gnome-base/gnome-keyring package as dependecy but app-crypt/libsecret?
nextcloud (In reply to Lars Wendler (Polynomial-C) from comment #1) > You are aware that the "gnome-keyring" USE flag of dev-libs/qtkeychain > package does not pull in gnome-base/gnome-keyring package as dependecy but > app-crypt/libsecret? app-crypt/libsecret pull as depency gnome-base/gnome-keyring. this message in bug 756772 is completly wrong: „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“ Let's look at https://github.com/frankosterfeld/qtkeychain: „Linux/Unix: If running, GNOME Keyring is used, otherwise QtKeychain tries to use KWallet (via D-Bus), if available.“ It works perfect without libsecret and It works perfect without gnome-keyring. Please remove this dependecy.
Ah, it's in PDEPEND. I was only looking in (R)DEPEND... Bernard, what do you think?
how about: # diff nextcloud-client-3.1.1-r1.ebuild nextcloud-client-3.1.1-r2.ebuild 15c15 < IUSE="doc dolphin libressl nautilus test" --- > IUSE="doc dolphin libressl nautilus test kwallet gnome-keyring" 16a17 > REQUIRED_USE="^^ ( gnome-keyring kwallet )" 18c19,21 < dev-libs/qtkeychain[gnome-keyring,qt5(+)] --- > dev-libs/qtkeychain[qt5(+)] > gnome-keyring? ( dev-libs/qtkeychain[gnome-keyring,qt5(+)] ) > kwallet? ( kde-frameworks/kwallet )
Oh nice catch with the dependency hiding in PDEPEND... I browsed the code quickly and there is no real dependency on kwallet or gnome-keyring, everything goes through qtkeyring. Then in qtkeyring itself, gnome-keyring dependency seems moving to be only through libsecret. kwallet support seems a bit mysterious/automagic. I did not find any link that libsecret has KDE support (though claiming to be "neutral" API). Adding johu for opinion on qtkeychain itself, where the fix would be better situated Also comment 4 may be a partial fix, but what about occasional users who do not want passwords stored in keyrings? (or not using gnome/KDE)
nextcloud-client-3.1.2.ebuild has the same problem
nextcloud-client-3.1.3.ebuild has the same problem
I can confirm that gnome-keyring is not needed. Plus, the code in qtkeychain shows that it works very much without it: https://github.com/frankosterfeld/qtkeychain/blob/master/keychain_unix.cpp (look for "Plasma5"). So I second the plead, please remove this useless dependency which was not needed until now.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=87cf5e2d8663fd2916077f7c82dcfd00507934ea commit 87cf5e2d8663fd2916077f7c82dcfd00507934ea Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2021-05-25 20:30:56 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2021-05-25 20:37:40 +0000 net-misc/nextcloud-client: bump to v3.2.1 Closes: https://bugs.gentoo.org/765220 Closes: https://bugs.gentoo.org/788754 Package-Manager: Portage-3.0.18, Repoman-3.0.3 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> net-misc/nextcloud-client/Manifest | 1 + .../nextcloud-client/nextcloud-client-3.2.1.ebuild | 92 ++++++++++++++++++++++ 2 files changed, 93 insertions(+)
