From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#28694: gnu: p11-kit: Update to 0.23.9 fails test. Date: Fri, 06 Oct 2017 08:42:40 +0200 Message-ID: <87y3oosrof.fsf@gnu.org> References: <87zi9739u6.fsf@gmail.com> <87vajv6kyg.fsf@gnu.org> <8760butoam.fsf@gmail.com> <87efqi9dok.fsf@gnu.org> <87r2ugopz8.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41477) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e0MLi-0004L8-LZ for bug-guix@gnu.org; Fri, 06 Oct 2017 02:43:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e0MLe-0005Tk-Im for bug-guix@gnu.org; Fri, 06 Oct 2017 02:43:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:43375) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e0MLe-0005TS-DY for bug-guix@gnu.org; Fri, 06 Oct 2017 02:43:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e0MLe-00011R-43 for bug-guix@gnu.org; Fri, 06 Oct 2017 02:43:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87r2ugopz8.fsf@gmail.com> (Oleg Pykhalov's message of "Fri, 06 Oct 2017 07:32:59 +0300") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Oleg Pykhalov Cc: 28694-done@debbugs.gnu.org Hi Oleg, Oleg Pykhalov skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> Hi Oleg, >> >> Oleg Pykhalov skribis: >> >>> ludo@gnu.org (Ludovic Court=C3=A8s) 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) =3D 5 >>> calling secure_getenv(BLAH) getenv(BLAH) =3D 5 >>> 1..4 >>> ok 1 /compat/strndup >>> not ok 2 /compat/getauxval >>> # assertion failed (ret !=3D 0): (0 !=3D 0) >>> # in test_getauxval() at test-compat.c:79 >>> not ok 3 /compat/secure_getenv >>> # assertion failed (ret =3D=3D 0): (5 =3D=3D 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 =3D=3D 18): (33 =3D=3D 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=3D16777216k > > (file-systems (cons* ;; =E2=80=A6 > (file-system > (device "tmpfs") > (mount-point "/tmp") > (type "tmpfs") > (flags '(no-suid no-dev)) > (options "mode=3D1777,size=3D16G") > (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=E2=80=99ve 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=E2=80=99d have to run builds in VMs, so that we can also choose which kernel we use. But that=E2=80=99s much more heavyweight. Thanks, Ludo=E2=80=99. PS: The address is NNN-done@debbugs.gnu.org, not done-NNN. :-)