Hello,
I tried to install nextcloud-client-l10n_2.5.0-20181111.015125~bionic1_all.deb from the PPA repository:
deb http://ppa.launchpad.net/nextcloud-devs/client/ubuntu cosmic main
I got an error about a failing dependancy: libgnome-keyring0
Searching for this package, I found this bugreport:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892359
It's not released with Debian 10 (buster/testing) because it is deprecated. In the bug report it is advised to use Libsecret instead.
I was able to install the nextcloud client by downloading both dependancies (libgnome-keyring0 and libgnome-keyring-common) from Debian 9. But this is an ugly workaround.
Client version: 2.5.0-20181111.015125
Operating system: Debian 10 (Buster)
OS language: NL
Qt version used by client package (Linux only, see also Settings dialog): 5.11.2+dfsg-4 amd64
Client package (From Nextcloud or distro) (Linux only): http://ppa.launchpad.net/nextcloud-devs/client/ubuntu cosmic main
Installation path of client: default
I think that issues #883 and #990 are addressing the same problem which is that nextcloud-client should use libsecret instead of libgnome-keyring and the package(s) of course depend on this new library.

FWIW, some folks at Debian are working on packaging this in Debian itself:
Maybe you want to join forces? :wink:
nextcloud-desktop was uploaded to unstable last week, of course without depends to gnome-keyring.
For me, with libsecret installed, the automation unlock doesn't work, I have to insert the credentials on every start, which is really anoying.
@Micha-Btz Indeed, nextcloud-desktop is not built against libsecret (is libsecret support even implemented in nextcloud client).
Here is a report tracking the issue on Debian side : https://bugs.debian.org/920984
I guess the point here is to have nextcloud-desktop to drop libgnome-keyring0 in favor of libsecret.
@mxjeff Thanks, this would be easy solved when only libsecret is needed to build.
@Micha-Btz Indeed, nextcloud-desktop is not built against libsecret (is libsecret support even implemented in nextcloud client).
Here is a report tracking the issue on Debian side : https://bugs.debian.org/920984I guess the point here is to have nextcloud-desktop to drop libgnome-keyring0 in favor of libsecret.
But nextcloud-desktop nor owncloud-client depend on libgnome-keyring0 nor libsecret. So how this replace should taking place? The credential support is done in libqtkeyring and this is using libsecret.
See also the build log:
https://buildd.debian.org/status/fetch.php?pkg=nextcloud-desktop&arch=i386&ver=2.5.1-1&stamp=1548676710&raw=0
Then you probably need libqtkeyring-dev and libsecret-dev while compiling. Can you make a test and compile it from debian git?
Then you probably need libqtkeyring-dev and libsecret-dev while compiling. Can you make a test and compile it from debian git?
As I'm not affected by this bug (using KDE) - this all does not make sense for me to test. I'm still arguing, that this all will not help. As nextcloud-desktop does not depend on libsecret. IMO you need to search why qtkeyring do not connect via libsecret. Maybe 0.9.1 fixes this issue:
https://github.com/frankosterfeld/qtkeychain/blob/master/ChangeLog#L6
I would recommed for affected people to try out built qtkeychain 0.9.1 and if the issue is gone with that, that we fould the source of the issue.
I have tried it aft the update to libqt5keychain1 0.9.1-1 in unstable today. Makes no difference.
And I also get no output with dbus-monitor
Can give someone some hints how to debug this? Logdebug from client is also not really helpfull.
[OCC::WebFlowCredentials::fetchFromKeychain Fetch from keyhchain!
[OCC::AccountState::slotCredentialsFetched Fetched credentials for "https://owncloud.mdomann.tk" attempting to connect
[OCC::WebFlowCredentials::createQNAM Get QNAM
[OCC::ConnectionValidator::systemProxyLookupDone No system proxy set by OS
[OCC::AccessManager::createRequest 2 "" "https://xxxxxx/status.php" has X-Request-ID "xxxxxxxxxxxxxxxxxxxxxxxxxxx"
[OCC::AbstractNetworkJob::start OCC::CheckServerJob created for "https://owncloud.mdomann.tk" + "status.php" "OCC::ConnectionValidator"
[OCC::WebFlowCredentials::slotFinished request finished
[OCC::WebFlowCredentials::stillValid Still valid?
[OCC::WebFlowCredentials::stillValid QNetworkReply::NetworkError(NoError)
[OCC::WebFlowCredentials::stillValid "Unbekannter Fehler"
[OCC::CheckServerJob::finished No SSL session identifier / session ticket is used, this might impact sync performance negatively.
[OCC::CheckServerJob::finished status.php returns: QJsonDocument({"edition":"","installed":true,"maintenance":false,"needsDbUpgrade":false,"productname":"Nextcloud","version":"15.0.4.0","versionstring":"15.0.4"}) QNetworkReply::NetworkError(NoError) Reply: QNetworkReplyHttpImpl(0x55932c384830)
@Micha-Btz: well you need to use standard linux debug tools like strace and gdb. I used those and for Debian I found a workaround:
ln -s /usr/lib/x86_64-linux-gnu/libsecret-1.so.0 /usr/lib/x86_64-linux-gnu/libsecret-1.so
but why the hell qtkeychain is trying to access libsecret-1.so instead of libsecret-1.so.0, I have no idea. An application should never access a .so lib.
For me it is working now. I have to install and run seahore, before nc client starts.
https://linuxconfig.org/how-to-install-nextcloud-client-on-debian-10-buster
In Debian 10 Buster, the Nextcloud client is actually available straight from the default repositories.
sudo apt install nextcloud-desktop
Most helpful comment
By referring to Don't Make a FrankenDebian
I'm a little bit concern on how Nextcloud suggest to install their client through PPA for Debian User
I hope in the future Nextcloud will change this practice.