GNU bug report logs - #28694
gnu: p11-kit: Update to 0.23.9 fails test.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28694 in the body.
You can then email your comments to 28694 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Oleg Pykhalov <go.wigust <at> gmail.com>
To: bug-guix <at> gnu.org
Subject: gnu: p11-kit: Update to 0.23.9 fails test.
Date: Wed, 04 Oct 2017 05:50:25 +0300

[Message part 1 (text/plain, inline)]

Hello Guix,

Latest p11-kit update fails to test and build.

--8<---------------cut here---------------start------------->8---
…
FAIL: test-compat
1..2
ok 1 /hash/murmur3
ok 2 /hash/murmur3-incr
…
1..16
ok 1 /conf/test_parse_conf_1
ok 2 /conf/test_parse_ignore_missing
ok 3 /conf/test_parse_fail_missing
ok 4 /conf/test_merge_defaults
ok 5 /conf/test_load_globals_merge
ok 6 /conf/test_load_globals_no_user
ok 7 /conf/test_load_globals_system_sets_only
ok 8 /conf/test_load_globals_user_sets_only
ok 9 /conf/test_load_globals_system_sets_invalid
ok 10 /conf/test_load_globals_user_sets_invalid
ok 11 /conf/test_load_modules_merge
ok 12 /conf/test_load_modules_no_user
ok 13 /conf/test_load_modules_user_only
ok 14 /conf/test_load_modules_user_none
ok 15 /conf/test_parse_boolean
not ok 16 /conf/setuid
# assertion failed (ret == 18): (33 == 18)
# in test_setuid() at test-conf.c:421
FAIL: test-conf
…
2 of 47 tests failed
…
--8<---------------cut here---------------end--------------->8---

2a6e049a2f850aaa11e0ccabd94415e695e32c81

[Message part 2 (text/plain, attachment)]

Message #8 received at 28694 <at> debbugs.gnu.org (full text, mbox):

From: Oleg Pykhalov <go.wigust <at> gmail.com>
To: 28694 <at> debbugs.gnu.org
Subject: Re: bug#28694: gnu: p11-kit: Update to 0.23.9 fails test.
Date: Wed, 04 Oct 2017 09:21:38 +0300

Oleg Pykhalov <go.wigust <at> gmail.com> writes:

[...]

> Latest p11-kit update fails to test and build.

[...]

By the way, it succeeded on Hydra.  

But on my machine build fails on origin/master checkout.
$ guix build --check --no-grafts p11-kit

Does anybody have this issue?

Message #11 received at 28694 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Oleg Pykhalov <go.wigust <at> gmail.com>
Cc: 28694 <at> debbugs.gnu.org
Subject: Re: bug#28694: gnu: p11-kit: Update to 0.23.9 fails test.
Date: Wed, 04 Oct 2017 16:34:15 +0200

Oleg Pykhalov <go.wigust <at> gmail.com> skribis:

> Latest p11-kit update fails to test and build.
>
> …
> FAIL: test-compat
> 1..2
> ok 1 /hash/murmur3
> ok 2 /hash/murmur3-incr
> …
> 1..16
> ok 1 /conf/test_parse_conf_1
> ok 2 /conf/test_parse_ignore_missing
> ok 3 /conf/test_parse_fail_missing
> ok 4 /conf/test_merge_defaults
> ok 5 /conf/test_load_globals_merge
> ok 6 /conf/test_load_globals_no_user
> ok 7 /conf/test_load_globals_system_sets_only
> ok 8 /conf/test_load_globals_user_sets_only
> ok 9 /conf/test_load_globals_system_sets_invalid
> ok 10 /conf/test_load_globals_user_sets_invalid
> ok 11 /conf/test_load_modules_merge
> ok 12 /conf/test_load_modules_no_user
> ok 13 /conf/test_load_modules_user_only
> ok 14 /conf/test_load_modules_user_none
> ok 15 /conf/test_parse_boolean
> not ok 16 /conf/setuid
> # assertion failed (ret == 18): (33 == 18)
> # in test_setuid() at test-conf.c:421
> FAIL: test-conf
> …
> 2 of 47 tests failed

Do the failures happen reproducibly for you?  Is there a test log or
code giving a hint as to what is being tested and how it fails?

Thanks,
Ludo’.

Message #14 received at 28694 <at> debbugs.gnu.org (full text, mbox):

From: Oleg Pykhalov <go.wigust <at> gmail.com>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 28694 <at> debbugs.gnu.org
Subject: Re: bug#28694: gnu: p11-kit: Update to 0.23.9 fails test.
Date: Thu, 05 Oct 2017 03:45:53 +0300

[Message part 1 (text/plain, inline)]

Hello Ludovic,

Thanks for hitting this issue!

ludo <at> gnu.org (Ludovic Courtès) writes:

[...]

> Do the failures happen reproducibly for you?  Is there a test log or
> code giving a hint as to what is being tested and how it fails?

I attached one log in the first message, but here is another one.

I'm on 46cf31868c1b12eec50bc9b8dda64604dd81f986

[Message part 2 (text/plain, attachment)]

[Message part 3 (text/plain, inline)]

I also checked 0.23.8.  It fails.  I think that I didn't notice this
because it was substituted in past.  So bug report subject is wrong now.

I'm on 79ed92be6fb99af36f4173acade384c21acbbd90

[Message part 4 (text/plain, attachment)]

[Message part 5 (text/plain, inline)]

Just for a note I did those tests on Guix checkout without making a new
Git Worktree, but with running make with no errors.  I guess this is OK.

Message #17 received at 28694 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Oleg Pykhalov <go.wigust <at> gmail.com>
Cc: 28694 <at> debbugs.gnu.org
Subject: Re: bug#28694: gnu: p11-kit: Update to 0.23.9 fails test.
Date: Thu, 05 Oct 2017 10:55:23 +0200

Hi Oleg,

Oleg Pykhalov <go.wigust <at> gmail.com> skribis:

> ludo <at> gnu.org (Ludovic Courtès) writes:
>
> [...]
>
>> Do the failures happen reproducibly for you?  Is there a test log or
>> code giving a hint as to what is being tested and how it fails?
>
> I attached one log in the first message, but here is another one.
>
> I'm on 46cf31868c1b12eec50bc9b8dda64604dd81f986

[...]

> calling secure_getenv(BLAH) getenv(BLAH) = 5
> calling secure_getenv(BLAH) getenv(BLAH) = 5
> 1..4
> ok 1 /compat/strndup
> not ok 2 /compat/getauxval
> # assertion failed (ret != 0): (0 != 0)
> # in test_getauxval() at test-compat.c:79
> not ok 3 /compat/secure_getenv
> # assertion failed (ret == 0): (5 == 0)
> # in test_secure_getenv() at test-compat.c:104
> ok 4 /compat/mmap
> FAIL: test-compat

[...]

> ok 1 /conf/test_parse_conf_1
> ok 2 /conf/test_parse_ignore_missing
> ok 3 /conf/test_parse_fail_missing
> ok 4 /conf/test_merge_defaults
> ok 5 /conf/test_load_globals_merge
> ok 6 /conf/test_load_globals_no_user
> ok 7 /conf/test_load_globals_system_sets_only
> ok 8 /conf/test_load_globals_user_sets_only
> ok 9 /conf/test_load_globals_system_sets_invalid
> ok 10 /conf/test_load_globals_user_sets_invalid
> ok 11 /conf/test_load_modules_merge
> ok 12 /conf/test_load_modules_no_user
> ok 13 /conf/test_load_modules_user_only
> ok 14 /conf/test_load_modules_user_none
> ok 15 /conf/test_parse_boolean
> not ok 16 /conf/setuid
> # assertion failed (ret == 18): (33 == 18)
> # in test_setuid() at test-conf.c:421
> FAIL: test-conf

Both failures have to do with setuid/setgid binaries.

Is there anything special about your system, like use of SELinux or
similar?  What are the mount options on /tmp?  What kernel do you use?

Could you run “guix build -K p11-kit”, and then:

  cd /tmp/guix-build-p11-kit*/p11-kit-0.*
  strace -f -s 234 -o log make check

and finally post the excerpt of ‘log’ around the “assertion failed”
messages?

TIA!

Ludo’.

Message #20 received at 28694 <at> debbugs.gnu.org (full text, mbox):

From: Oleg Pykhalov <go.wigust <at> gmail.com>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: done-28694 <at> debbugs.gnu.org, 28694 <at> debbugs.gnu.org
Subject: Re: bug#28694: gnu: p11-kit: Update to 0.23.9 fails test.
Date: Fri, 06 Oct 2017 07:32:59 +0300

Hello Ludovic,

ludo <at> gnu.org (Ludovic Courtès) writes:

> Hi Oleg,
>
> Oleg Pykhalov <go.wigust <at> gmail.com> skribis:
>
>> ludo <at> gnu.org (Ludovic Courtès) writes:
>>
>> [...]
>>
>>> Do the failures happen reproducibly for you?  Is there a test log or
>>> code giving a hint as to what is being tested and how it fails?
>>
>> I attached one log in the first message, but here is another one.
>>
>> I'm on 46cf31868c1b12eec50bc9b8dda64604dd81f986
>
> [...]
>
>> calling secure_getenv(BLAH) getenv(BLAH) = 5
>> calling secure_getenv(BLAH) getenv(BLAH) = 5
>> 1..4
>> ok 1 /compat/strndup
>> not ok 2 /compat/getauxval
>> # assertion failed (ret != 0): (0 != 0)
>> # in test_getauxval() at test-compat.c:79
>> not ok 3 /compat/secure_getenv
>> # assertion failed (ret == 0): (5 == 0)
>> # in test_secure_getenv() at test-compat.c:104
>> ok 4 /compat/mmap
>> FAIL: test-compat
>
> [...]
>
>> ok 1 /conf/test_parse_conf_1
>> ok 2 /conf/test_parse_ignore_missing
>> ok 3 /conf/test_parse_fail_missing
>> ok 4 /conf/test_merge_defaults
>> ok 5 /conf/test_load_globals_merge
>> ok 6 /conf/test_load_globals_no_user
>> ok 7 /conf/test_load_globals_system_sets_only
>> ok 8 /conf/test_load_globals_user_sets_only
>> ok 9 /conf/test_load_globals_system_sets_invalid
>> ok 10 /conf/test_load_globals_user_sets_invalid
>> ok 11 /conf/test_load_modules_merge
>> ok 12 /conf/test_load_modules_no_user
>> ok 13 /conf/test_load_modules_user_only
>> ok 14 /conf/test_load_modules_user_none
>> ok 15 /conf/test_parse_boolean
>> not ok 16 /conf/setuid
>> # assertion failed (ret == 18): (33 == 18)
>> # in test_setuid() at test-conf.c:421
>> FAIL: test-conf
>
> Both failures have to do with setuid/setgid binaries.
>
> Is there anything special about your system, like use of SELinux or
> similar?  What are the mount options on /tmp?  What kernel do you use?

No, I use pretty much default GNU GuixSD.

    No SELinux or similar.

My mount options on /tmp are:

    $ findmnt /tmp
    /tmp   tmpfs  tmpfs  rw,nosuid,nodev,relatime,size=16777216k

    (file-systems (cons* ;; …
                         (file-system
                           (device "tmpfs")
                           (mount-point "/tmp")
                           (type "tmpfs")
                           (flags '(no-suid no-dev))
                           (options "mode=1777,size=16G")
                           (needed-for-boot? #t)
                           (check? #f))
                         %base-file-systems))

Yes, there is a nosuid flag.  After removing this, success to build.
/me fills stupid.

Could we have a thing which will check for such flag before running
tests in package builds?  Or tell this after 'guix system reconfigure'.
Or maybe to mention in Guix documentation if such a flag present then
you could fail to build some packages?

    $ uname -a
    Linux magnolia 4.13.4-gnu #1 SMP 1 x86_64 GNU/Linux

[...]

Thanks,
Oleg.

Message #25 received at 28694-done <at> debbugs.gnu.org (full text, mbox):

From: Oleg Pykhalov <go.wigust <at> gmail.com>
To: bug#28694 <28694-done <at> debbugs.gnu.org>
Subject: Re: Status: gnu: p11-kit: Update to 0.23.9 fails test.
Date: Fri, 06 Oct 2017 07:40:20 +0300

Message #28 received at 28694-done <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Oleg Pykhalov <go.wigust <at> gmail.com>
Cc: 28694-done <at> debbugs.gnu.org
Subject: Re: bug#28694: gnu: p11-kit: Update to 0.23.9 fails test.
Date: Fri, 06 Oct 2017 08:42:40 +0200

Hi Oleg,

Oleg Pykhalov <go.wigust <at> gmail.com> skribis:

> ludo <at> gnu.org (Ludovic Courtès) writes:
>
>> Hi Oleg,
>>
>> Oleg Pykhalov <go.wigust <at> gmail.com> skribis:
>>
>>> ludo <at> gnu.org (Ludovic Courtès) writes:
>>>
>>> [...]
>>>
>>>> Do the failures happen reproducibly for you?  Is there a test log or
>>>> code giving a hint as to what is being tested and how it fails?
>>>
>>> I attached one log in the first message, but here is another one.
>>>
>>> I'm on 46cf31868c1b12eec50bc9b8dda64604dd81f986
>>
>> [...]
>>
>>> calling secure_getenv(BLAH) getenv(BLAH) = 5
>>> calling secure_getenv(BLAH) getenv(BLAH) = 5
>>> 1..4
>>> ok 1 /compat/strndup
>>> not ok 2 /compat/getauxval
>>> # assertion failed (ret != 0): (0 != 0)
>>> # in test_getauxval() at test-compat.c:79
>>> not ok 3 /compat/secure_getenv
>>> # assertion failed (ret == 0): (5 == 0)
>>> # in test_secure_getenv() at test-compat.c:104
>>> ok 4 /compat/mmap
>>> FAIL: test-compat
>>
>> [...]
>>
>>> ok 1 /conf/test_parse_conf_1
>>> ok 2 /conf/test_parse_ignore_missing
>>> ok 3 /conf/test_parse_fail_missing
>>> ok 4 /conf/test_merge_defaults
>>> ok 5 /conf/test_load_globals_merge
>>> ok 6 /conf/test_load_globals_no_user
>>> ok 7 /conf/test_load_globals_system_sets_only
>>> ok 8 /conf/test_load_globals_user_sets_only
>>> ok 9 /conf/test_load_globals_system_sets_invalid
>>> ok 10 /conf/test_load_globals_user_sets_invalid
>>> ok 11 /conf/test_load_modules_merge
>>> ok 12 /conf/test_load_modules_no_user
>>> ok 13 /conf/test_load_modules_user_only
>>> ok 14 /conf/test_load_modules_user_none
>>> ok 15 /conf/test_parse_boolean
>>> not ok 16 /conf/setuid
>>> # assertion failed (ret == 18): (33 == 18)
>>> # in test_setuid() at test-conf.c:421
>>> FAIL: test-conf
>>
>> Both failures have to do with setuid/setgid binaries.
>>
>> Is there anything special about your system, like use of SELinux or
>> similar?  What are the mount options on /tmp?  What kernel do you use?
>
> No, I use pretty much default GNU GuixSD.
>
>     No SELinux or similar.
>
> My mount options on /tmp are:
>
>     $ findmnt /tmp
>     /tmp   tmpfs  tmpfs  rw,nosuid,nodev,relatime,size=16777216k
>
>     (file-systems (cons* ;; …
>                          (file-system
>                            (device "tmpfs")
>                            (mount-point "/tmp")
>                            (type "tmpfs")
>                            (flags '(no-suid no-dev))
>                            (options "mode=1777,size=16G")
>                            (needed-for-boot? #t)
>                            (check? #f))
>                          %base-file-systems))
>
> Yes, there is a nosuid flag.  After removing this, success to build.
> /me fills stupid.

No problem, good that we found out!

> Could we have a thing which will check for such flag before running
> tests in package builds?  Or tell this after 'guix system reconfigure'.
> Or maybe to mention in Guix documentation if such a flag present then
> you could fail to build some packages?

There are many subtle ways in which package builds could fail.  It could
be this, it could be SELinux weirdness, it could be btrfs (we’ve had
several cases where btrfs behaved slightly differently from ext4,
leading to obscure failures), it could be changes in the kernel, etc.

These are issues that leak through the isolated environments that
guix-daemon creates.  If we wanted to avoid them, we’d have to run
builds in VMs, so that we can also choose which kernel we use.  But
that’s much more heavyweight.

Thanks,
Ludo’.

PS: The address is NNN-done <at> debbugs.gnu.org, not done-NNN.  :-)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.