Bug#846728: gcr: FTBFS: Test failures

[Emilio Pozuelo Monfort]

Control: tags -1 pending

On Sat, 7 Jan 2017 18:59:30 +0100 Lucas Nussbaum <lucas at debian.org> wrote:
> 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 test is called test_reload(), so it's trying to connect/start, then ensuring
that it can connect again.

Fix coming, increasing the timeout.

Cheers,
Emilio