[gpgme] 1.7 build experience and issues

[Alon Bar-Lev]

On 23 September 2016 at 16:21, Justus Winter <justus at g10code.com> wrote:
> Hi :)
>
> Alon Bar-Lev <alon.barlev at gmail.com> writes:
>> I am the Gentoo maintainer of gpgme.
>
> thanks for the feedback.
>
>> FAILING TESTS
>>
>> t-sig-notation fails due to Unexpected notation data
>
> What version of GnuPG are you using as backend?
>
> We fixed a bug in GnuPG recently to properly report a notation flag, and
> tightened the test case accordingly.  To support older versions of
> GnuPG, the test tries to detect that an older version is used, but that
> test might fail for some reason.

$ gpg --version
gpg (GnuPG) 2.0.28
libgcrypt 1.7.3


>
>> PYTHON
>>
>> If not absolutely required to have this in the same package, maybe it would
>> be better to split it into a separate one that is to be used post
>> installation of pgpme using pure python tools.
>
> Surely gentoo can produce several binary packages from one source
> package?

Well, it is not that simple.
When you build several binary packages, each with several binary
python you end up with somekind of deadlock.
Either build the C bindings over and over for each python version or
hack the package.
Usually, there is no value in mixing the build of the C library and
the python bindings into same build process and package. It is much
easier to package both as separate packages that are built on after
the other, without the need to hack the in-tree and multiple variants
issues.

> We are in fact using the python tools to build the bindings.  The checks
> in configure merely try to detect which versions are available, and if
> everything is in place to produce python modules with SWIG.

Correct, however, the combination of autotools and distutils is what
makes it more difficult.

I sent a patch to clean this a bit to enable portage usage, however, I
think that for generating the version into setup.py it is an overkill
to use autoconf. You may consider taking this a bit farther to include
version.py to be imported by setup.py, generate version.py as
generated distributed source, this will skip the need to use configure
and make, with the exception of data.h which should have its own
solution (moving away from in-tree build).

>> The autoconf ignores PYTHON override or any other attempt to use explicit
>> environment.
>> Please enable override to enable the packaging system to build the bindings
>> to the supported python interpreters of the system.
>
> Gladly.  Can you please be more specific how that would look like?

Oh... this is simple... if you use AM_PATH_PYTHON in autoconf, never
unset its macros... :)

>
> Cheers,
> Justus