gpgme python bindings release plans?

[Jasper Spaans]

On 30/08/2018 08:44, Ben McGinnes wrote:
> 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.
Indeed your fix has broken my build instead.

(I don't know what Ubuntu has to do with this; and in case my previous
message was not clear enough: I did not use any Ubuntu-provided versions
of libgpg-error or gpgme. I wouldn't be surprised if this will cause
breakage on Debian as well.)

Anyway, looking at the binary objects that were generated when building
from git head (a9863717b1b82b3077edd0db85454ba801eac9bd , one version
ahead of your commit):

$ nm
/usr/local/lib/python3.5/dist-packages/gpg/_gpgme.cpython-35m-x86_64-linux-gnu.so
| grep gpgme_data_new_from_estream
                 U gpgme_data_new_from_estream
000000000004c350 t _wrap_gpgme_data_new_from_estream

The U means the symbol is undefined here and needs to be provided by
another shared library. If that is nonsense, something on the Python
side should stop referring to it.

$ nm /usr/lib/libgpgme.so | grep gpgme_data_new_from_estream
000000000000b3a0 t gpgme_data_new_from_estream

Where the small t indicates that it is a symbol known inside this
library, but not exported.
This is similar to the situation before my (now reverted) patch was applied.


Random thoughts:
- there are some traces of Jenkins in the ticket system, but is it still
actively being used? I just tried accessing jenkins.gnupg.org but that
returns "service not available"? If that Jenkins is being maintained
though, I wouldn't mind setting up some jobs to test for these kinds of
regressions.
- what version of swig are you using?


Cheers,
Jasper