Subject: Re: bug#28694: gnu: p11-kit: Update to 0.23.9 fails test.

From: [email-masked] (Ludovic Courtès)
Date: Fri, 06 Oct 2017 08:42:40 +0200

Hi Oleg,

Oleg Pykhalov <[email-masked]> skribis:

> [email-masked] (Ludovic Courtès) writes:
>
>> Hi Oleg,
>>
>> Oleg Pykhalov <[email-masked]> skribis:
>>
>>> [email-masked] (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 [email-masked], not done-NNN.  :-)