Hi Oleg,
Oleg Pykhalov <go.wigust@gmail.com> skribis:
Toggle quote (82 lines)
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Hi Oleg,
>>
>> Oleg Pykhalov <go.wigust@gmail.com> skribis:
>>
>>> ludo@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!
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@debbugs.gnu.org, not done-NNN. :-)
