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
