all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Oleg Pykhalov <go.wigust@gmail.com>
Cc: 28694-done@debbugs.gnu.org
Subject: bug#28694: gnu: p11-kit: Update to 0.23.9 fails test.
Date: Fri, 06 Oct 2017 08:42:40 +0200	[thread overview]
Message-ID: <87y3oosrof.fsf@gnu.org> (raw)
In-Reply-To: <87r2ugopz8.fsf@gmail.com> (Oleg Pykhalov's message of "Fri, 06 Oct 2017 07:32:59 +0300")

Hi Oleg,

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

> 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!

> 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@debbugs.gnu.org, not done-NNN.  :-)

  reply	other threads:[~2017-10-06  6:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-04  2:50 bug#28694: gnu: p11-kit: Update to 0.23.9 fails test Oleg Pykhalov
2017-10-04  6:21 ` Oleg Pykhalov
2017-10-04 14:34 ` Ludovic Courtès
2017-10-05  0:45   ` Oleg Pykhalov
2017-10-05  8:55     ` Ludovic Courtès
2017-10-06  4:32       ` Oleg Pykhalov
2017-10-06  6:42         ` Ludovic Courtès [this message]
2017-10-06  4:40 ` bug#28694: Status: " Oleg Pykhalov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y3oosrof.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=28694-done@debbugs.gnu.org \
    --cc=go.wigust@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.