Bug 1725412

Summary:	Geary doesn't run without gnome-keyring
Product:	[Fedora] Fedora	Reporter:	Petr Czepiec <petr>
Component:	libsecret	Assignee:	Kalev Lember <klember>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	30	CC:	debarshir, ego.cordatus, klember, michel, stefw, thomas.moschny
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	libsecret-0.19.0-2.fc32	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-09-06 09:02:35 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Petr Czepiec 2019-06-30 14:46:01 UTC

Description of problem:
On environment without package gnome-keyring (e.g. Basic Desktop or Minimal Install) execution of Geary ends with error:

![???] 21:11:42 0.144103 geary: geary-controller.vala:349: Error opening libsecret: The name is not activatable
Trace/breakpoint trap (core dumped)

After installing package gnome-keyring, Geary runs OK. Geary also runs after uninstalling gnome-package (when I install gnome-keyring before).

Not sure if it's problem with Geary package or libsecret, maybe gnome-keyring can be replaced with another package. At any rate, there can be some package in dependency list to run Geary properly after pcakage installation.


Version-Release number of selected component (if applicable):
geary 3.32.1


Steps to Reproduce:
1. Install Fedora 30 (netinst), in Software Selection select Basic Desktop
2. Run terminal, install Geary with "sudo dnf install geary"
3. Run Geary (e.g. from terminal)

Comment 1 Thomas Moschny 2019-08-31 15:27:42 UTC

geary-3.32.2-1.fc30.x86_64 depends on 'libsecret-1.so.0()(64bit)', so maybe that's indeed a libsecret issue.

Re-assigning, maybe the libsecret maintainers can comment.

Comment 2 Kalev Lember 2019-09-02 12:27:58 UTC

libsecret can work with different backends. It doesn't talk to gnome-keyring specifically but instead uses the freedesktop Secret Service DBus API: https://specifications.freedesktop.org/secret-service/

I suspect KDE is implementing this API as well. https://community.kde.org/KDE_Utils/ksecretsservice seems to say so if I understand that right.

If the above is right, I think it would be wrong for the libsecret package to require gnome-keyring, as it can also work with the KDE secret service implementation.

Comment 3 Thomas Moschny 2019-09-02 13:29:25 UTC

Nonetheless, we should have a mechanism to ensure that one provider is installed alongside libsecret.

I am not sure however, which mechanism that would be - rich dependencies, comps, ...?

Comment 4 Kalev Lember 2019-09-02 13:49:10 UTC

I'd say it has to be a package level dependency. Comps seems like a wrong layer.

Comment 5 Kalev Lember 2019-09-06 09:02:35 UTC

I looked around a bit to see what's actually packaged for Fedora and failed to find any other implementations of org.freedesktop.Secrets API beyond gnome-keyring. https://community.kde.org/KDE_Utils/ksecretsservice appears to not be packaged for Fedora. If it were, I think we should be able to do in libsecret.spec:

Recommends: (gnome-keyring or ksecretsservice)
Suggests: gnome-keyring

... which should have the effect of preferring gnome-keyring, but also if ksecretsservice is already installed, satisfy the dep.

Anyway, since we don't have ksecretsservice, I went ahead and just added a plain "Recommends: gnome-keyring" to libsecret in https://src.fedoraproject.org/rpms/libsecret/c/4976bb03f9ee7c767eda779ed0937575927d0525