gpgme python bindings release plans?

[Ben McGinnes]

On Sun, Aug 26, 2018 at 09:21:31PM +0200, Jasper Spaans wrote:
> On 20/08/2018 14:02, Peter Lebbing wrote:
>> The gist of it is that the bindings are spread by upstream bundled with
>> GPGME, rather than through PyPi. This is because the bindings are
>> tightly coupled to the GPGME library, so they should be built and
>> installed together.
>>
>> But that's all I can tell you, I'm not well acquainted with it.
>
> Thanks Peter! That is a bit unusual for Python packages,

Most Python packages, certainly those on PyPI, are also written
entirely or almost entirely in Python as well.  These bindings are
generated with SWIG from header files which are generated when GPGME
itself is compiled.  In order to dynamically generate the bindings, we
must have the location of gpgme.h for that specific architecture,
operating system and build.

This is why in this case the PyPI copy or copies are never recommended
and, unlike so many other projects, should only be used if it's not
possible to compile GPGME and generate the bindings directly, even as
a regular user.  If someone is in that position, though, there's a
much higher probability that even the PyPI option won't help them
anyway.

> but I guess there's not much to do about it for now.

Perhaps not, but I recommend you read the HOWTO for the bindings; it's
the lang/python/docs/GPGMEpythonHOWTOen.org org-mode file.

> Anyway, I followed your advice and made some packages for gpgme and
> python, but they somehow failed when trying to load the python
> module (based on current git head of gpgme):
> 
>   user at testing-gpg:~$ python3 -m gpg

Don't check the bindings using this method, it won't work because this
module is not an executable program in that sense.  A better check
from a shell w=is this:

bash-4.4$ python3.7 -c "import gpg; print(gpg.version.versionstr)"
1.11.2-beta257
bash-4.4$

The output of which should match the installed library version:

bash-4.4$ gpgme-config --version
1.11.2-beta257
bash-4.4$ 

>   Traceback (most recent call last):
>   ...
>   ImportError:
> /usr/local/lib/python3.5/dist-packages/gpg/_gpgme.cpython-35m-x86_64-linux-gnu.so:
> undefined symbol: gpgme_data_new_from_estream

Interestingly enough, I hadn't seen this error at all until this
commit: 08cd34afb762975b0273575035dacf69449ef241

I'd had up to commit 138e1dde027338358a8da19ff8592b7369494534 running
live for nearly a week (that's the commit immediately prior to your
patch).

> This was on a ubuntu 16.04 vm, stock packages, except libgpg-error which
> I created and installed a 1.32 package for.

Oh dear, mixing and matching between whatever modifications Canonical
have made with parts of current source.  I guess that explains why it
broke on OS X and possibly other BSDs.

> Doing a git bisect, the commit that causes the Python module to fail is
> 
> commit f42cd70f18d53df47cc2d027bade736377d39b71
> Author: Werner Koch <wk at gnupg.org>
> Date:   Thu Jul 19 09:50:30 2018 +0200
> 
> core: New interface gpgme_data_new_from_estream.
> 
> which seems to be a reasonable commit given the ImportError missing symbol.

I'd be surprised if it really caused the error if that were to be
tested on any Linux system which either stuck entirely with that
distributions packages *or* entirely with building the GnuPG software
from source (yes, all of it), but *not* mixing and matching between
the two.

On Sun, Aug 26, 2018 at 10:03:31PM +0200, Jasper Spaans wrote:
> On 26/08/2018 21:21, Jasper Spaans wrote:
> > Let me see if I can create my first patch :)
> Here it is, it was just a symbol that was not being exported. Verified
> that with this change applied the Python bindings work again for me.

Maybe so, but it broke for others, whether that was due to the
exported symbols conflicting with the inner API module name
(i.e. _gpgme) or the lack of defined functions for the estream in the
core, could go either way, but I'm leaning towards it being caused by
the exported symbol not lining up with _gpgme.

I've fixed those conflicts with this commit:

1d00fb987b903e245d484bddfe3c0a0aba670ac1

That, however, required changing both of your updates, so you should
test it ASAP to see if it still works or whether Ubuntu is going to be
a point of pain in future.


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180830/40c72f86/attachment-0001.sig>