Control: tags -1 pending On Sat, 7 Jan 2017 18:59:30 +0100 Lucas Nussbaum <[email protected]> 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
