Subject: bug#55258: Icedove, external OpenGPG configuration and ld path

From: Liliana Marie Prikler <[email-masked]>
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