GNU bug report logs - #55258
Icedove, external OpenGPG configuration and ld path

Previous Next

Package: guix;

Reported by: Josselin Poiret <dev <at> jpoiret.xyz>

Date: Wed, 4 May 2022 08:44:01 UTC

Severity: normal

To reply to this bug, email your comments to 55258 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#55258; Package guix. (Wed, 04 May 2022 08:44:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Josselin Poiret <dev <at> jpoiret.xyz>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Wed, 04 May 2022 08:44:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Josselin Poiret <dev <at> jpoiret.xyz>
To: bug-guix <at> gnu.org
Subject: Icedove, external OpenGPG configuration and ld path
Date: Wed, 04 May 2022 10:43:30 +0200
Hello everyone,

Currently, if you want to use a smart card with icedove, you have to
enable mail.openpgp.allow_external_gnupg in the config editor, but on
Guix, icedove will still not find the key that's on your smart card,
because it's unable to dlopen the GPGME library (understandably).

For now, my workaround is to launch icedove via

`LD_LIBRARY_PATH="$(guix build gpgme)/lib" icedove`

I outlined something similar to get icecat to be able to share desktops
under wayland [1], this time with the pipewire libraries.  This doesn't
seem like a great out-of-the-box experience for users, especially since
nothing indicates that this is the root of the problem.  Is there
anything we could do about this?

Adding all possible optional deps to LD_LIBRARY_PATH in a wrapper seems
a bit overkill, since for example PipeWire's closure is ~800 MiB,
depending for example on X libraries, and packagers won't always be able
to find 100% of the optional deps that are dlopen'd.

WDYT?

[1] https://lists.gnu.org/archive/html/guix-devel/2022-04/msg00205.html
(8735hx74qw.fsf <at> jpoiret.xyz)

-- 
Josselin Poiret




Information forwarded to bug-guix <at> gnu.org:
bug#55258; Package guix. (Wed, 04 May 2022 12:20:01 GMT) Full text and rfc822 format available.

Message #8 received at 55258 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
To: Josselin Poiret <dev <at> jpoiret.xyz>, 55258 <at> debbugs.gnu.org
Subject: Re: Icedove, external OpenGPG configuration and ld path
Date: Wed, 04 May 2022 14:19:50 +0200
Am Mittwoch, dem 04.05.2022 um 10:43 +0200 schrieb Josselin Poiret:
> Hello everyone,
> 
> Currently, if you want to use a smart card with icedove, you have to
> enable mail.openpgp.allow_external_gnupg in the config editor, but on
> Guix, icedove will still not find the key that's on your smart card,
> because it's unable to dlopen the GPGME library (understandably).
> 
> For now, my workaround is to launch icedove via
> 
> `LD_LIBRARY_PATH="$(guix build gpgme)/lib" icedove`
> 
> I outlined something similar to get icecat to be able to share
> desktops under wayland [1], this time with the pipewire libraries. 
> This doesn't seem like a great out-of-the-box experience for users,
> especially since nothing indicates that this is the root of the
> problem.  Is there anything we could do about this?
Rather than adjusting LD_LIBRARY_PATH, we typically patch the dlopen()
call to point to the store.  Would this be a workable solution for your
problem?

> Adding all possible optional deps to LD_LIBRARY_PATH in a wrapper
> seems a bit overkill, since for example PipeWire's closure is ~800
> MiB, depending for example on X libraries, and packagers won't always
> be able to find 100% of the optional deps that are dlopen'd.
True, in the general case we do rely on both rgrep and the package
developer making sane decisions, which might not always work out in our
favour.  As for debugging, strace might be useful to see what the
program is trying to do and should be able to detect a failing dlopen
call.

Cheers




Information forwarded to bug-guix <at> gnu.org:
bug#55258; Package guix. (Wed, 28 Sep 2022 22:26:02 GMT) Full text and rfc822 format available.

Message #11 received at 55258 <at> debbugs.gnu.org (full text, mbox):

From: Jonathan Brielmaier <jonathan.brielmaier <at> web.de>
To: 55258 <at> debbugs.gnu.org
Subject: Icedove, external OpenGPG configuration and ld path
Date: Thu, 29 Sep 2022 00:25:10 +0200
In case of gpgme the size isn't a real problem as it increases the
closure of Icedove by about 2-3 MiB.

Does it help to set `mail.openpgp.alternative_gpg_path` to something
meaningful?




Information forwarded to bug-guix <at> gnu.org:
bug#55258; Package guix. (Thu, 29 Sep 2022 09:32:01 GMT) Full text and rfc822 format available.

Message #14 received at 55258 <at> debbugs.gnu.org (full text, mbox):

From: Josselin Poiret <dev <at> jpoiret.xyz>
To: Jonathan Brielmaier <jonathan.brielmaier <at> web.de>, 55258 <at> debbugs.gnu.org
Subject: Re: bug#55258: Icedove, external OpenGPG configuration and ld path
Date: Thu, 29 Sep 2022 11:31:29 +0200
Hi Jonathan,

Jonathan Brielmaier <jonathan.brielmaier <at> web.de> writes:
> In case of gpgme the size isn't a real problem as it increases the
> closure of Icedove by about 2-3 MiB.
>
> Does it help to set `mail.openpgp.alternative_gpg_path` to something
> meaningful?

IIUC, this variable only denotes the location of the gpg executable, not
of the gpgme library itself.  I think the only option would be to add
LD_LIBRARY_PATH=/gnu/store/xxx-gpgme/lib/:$LD_LIBRARY_PATH to the
wrapper unfortunately.

Best,
-- 
Josselin Poiret




This bug report was last modified 1 year and 218 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.