Bug#846728: gcr: FTBFS: Test failures

[Lucas Nussbaum]

On 07/01/17 at 17:00 +0100, Michael Biebl wrote:
> Am 07.01.2017 um 08:16 schrieb Lucas Nussbaum:
> > 
> > On 07/01/17 at 01:15 +0100, Michael Biebl wrote:
> 
> >> I just tried to reproduce this in an up-to-date sid chroot and the
> >> package built fine. The built was using gnupg_2.1.16-2 whereas my chroot
> >> has 2.1.17-3. I wonder if that makes a difference.
> >>
> >> Can you try to reproduce the issue?
> > 
> > I just did a rebuild of testing. Yes, I can reproduce it, see attached
> > log.
> 
> Hm, odd. Any idea how your build chroot differs from a newly created
> pbuilder chroot?
> Any help appreciated with finding out what exactly triggers the
> test-suite / gnupg failure.

It also fails with gnupg 2.1.17-3 here.

In test-suite.org, the failing test has:
# Gcr-DEBUG: running command: /usr/bin/gpg --homedir /tmp/gcr-tests.5I3XTY --list-secret-keys --fixed-list-mode --with-colons --with-fingerprint
# Gcr-DEBUG: process environment: LOCALE=C
# Gcr-DEBUG: process started: 6231
# Gcr-DEBUG: closing fd: 8
gpg: starting migration from earlier GnuPG versions
# Gcr-DEBUG: received error line: gpg: starting migration from earlier GnuPG versions
gpg: porting secret keys from '/tmp/gcr-tests.5I3XTY/secring.gpg' to gpg-agent
# Gcr-DEBUG: received error line: gpg: porting secret keys from '/tmp/gcr-tests.5I3XTY/secring.gpg' to gpg-agent
**
ERROR:gcr/test-gnupg-collection.c:214:test_reload: assertion failed: (test->result)
# ERROR:gcr/test-gnupg-collection.c:214:test_reload: assertion failed: (test->result)
not ok 3 /gcr/gnupg-collection/reload


The failing lines seem to be: (./gcr/test-gnupg-collection.c:214)
        _gcr_gnupg_collection_load_async (test->collection, NULL, on_async_ready, test);
        egg_test_wait_until (2500);
        g_assert (test->result);
        _gcr_gnupg_collection_load_finish (test->collection, test->result, &error);
        g_assert_no_error (error);

Increasing the timeout value (2500) to something big (250000) makes the test pass.

I don't understand the logic in this test.  It seems to do something
(with a short timeout), then doing it again (with a larger timeout).
What's the point?

The machine I'm using for the tests is not slow. 63 cores
with Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz (Amazon m4.16xlarge instance).

Lucas