GNU bug report logs -
#28694
gnu: p11-kit: Update to 0.23.9 fails test.
Previous Next
Reported by: Oleg Pykhalov <go.wigust <at> gmail.com>
Date: Wed, 4 Oct 2017 02:52:02 UTC
Severity: normal
Done: Oleg Pykhalov <go.wigust <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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. :-)
This bug report was last modified 7 years and 291 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.