Bug 1725412 - Geary doesn't run without gnome-keyring
Summary: Geary doesn't run without gnome-keyring
Alias: None
Product: Fedora
Classification: Fedora
Component: libsecret
Version: 30
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Kalev Lember
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2019-06-30 14:46 UTC by Petr Czepiec
Modified: 2019-09-06 09:02 UTC (History)
6 users (show)

Fixed In Version: libsecret-0.19.0-2.fc32
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-09-06 09:02:35 UTC
Type: Bug

Attachments (Terms of Use)

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

Note You need to log in before you can comment on or make changes to this bug.