[GPGME] python t-quick-key-manipulation.py fails

Justus Winter justus at g10code.com
Tue Apr 11 12:29:59 CEST 2017


Andre Heinecke <aheinecke at intevation.de> writes:

> Hi,
>
> On Tuesday 11 April 2017 12:29:51 Alon Bar-Lev wrote:
>> How can it be user fault if gnupg formally supports --disable-tofu?
>> Tests should succeeded or skipped based on enabled features of gnupg.
>> In Gentoo we are trying to support package configuration to allow
>> choice of what features to enable, gnupg is included.
>> Please skip tests and not fail if a valid supported feature is disabled.
>
> Well you can configure all kinds of stuff in GnuPG or worse, just install some
> parts of it (like gpg but no gpg-agent) to create broken setups. So I'm kind
> of wondering if GPGME's testsuite is not supposed to fail in cases where the
> GnuPG system is missing features. If you decide to live with that breakage /
> missing features then you just have to accept that the tests will fail. But
> the information that the features are missing is conveyed at build time
> instead of users facing Problems at runtime.
>
> For this specific point, disabled tofu, I agree that it truly should
> be

Agreed.  Done.

> optional but I'm starting to rethink / question if our approach to make the
> tests work against any GnuPG version is the right one or if it would be better
> for GPGME's test suite to fail and complain if something will not work with
> this GnuPG version. It's more about the problems we had regarding 2.0.x
> support for the test suite so maybe that should be a different thread.
>
> E.g. Kleopatra has a selftest to check some basic GnuPG functionality on
> startup and if that fails it tells the user what's wrong and why it can't work
> with that and bails out. Instead of trying to handle every special
> installation that might be conceivable.

I'd go even further.  I believe GnuPG has way too many knobs, both in
the programs as well as in the build system.  I strongly believe that
any configuration that we do not test as part of our continous
integration setup is simply broken.


Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20170411/d7f46bdb/attachment.sig>


More information about the Gnupg-devel mailing list