Subject: bug#19780: 13 failing tests

From: [email-masked] (Ludovic Courtès)
Date: Tue, 03 Mar 2015 09:04:06 +0100

Ricardo Wurmus <[email-masked]> skribis:

> Ludovic Courtès writes:
>
>> Ricardo Wurmus <[email-masked]> skribis:
>>
>>> 17814 execve("/localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash", ["nakn26p520psw7jawgfv74wm34dn6kxj"..., "/localhome/rwurmus-tmp/guix/test"...], [/* 11 vars */]) = 0
>>
>> [...]
>>
>>> 17814 connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
>>> 17814 close(3)                          = 0
>>> 17814 open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
>>> 17814 fstat(3, {st_mode=S_IFREG|0644, st_size=1861, ...}) = 0
>>> 17814 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fed42e86000
>>> 17814 read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1861
>>> 17814 read(3, "", 4096)                 = 0
>>> 17814 close(3)                          = 0
>>> 17814 munmap(0x7fed42e86000, 4096)      = 0
>>> 17814 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
>>> 17814 fstat(3, {st_mode=S_IFREG|0644, st_size=33941, ...}) = 0
>>> 17814 mmap(NULL, 33941, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fed42e7e000
>>> 17814 close(3)                          = 0
>>> 17814 open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
>>
>> And from there we’re doomed.
>>
>> Could you download
>> <ftp://alpha.gnu.org:/gnu/guix/bootstrap/x86_64-linux/20131110/static-binaries.tar.xz>
>> and replace ‘gnu/packages/bootstrap/x86_64-linux/bash’ with the ‘bash’
>> file from that tarball (make it executable), and then try again?
>>
>> I believe the problem is that these binaries date from before commit
>> d3b59727 (Jan. 2013), which disabled dynamic NSS support in bootstrap
>> binaries.
>
> With the bash from that tarball I no longer get a segfault related to
> NSS, but I still get a segfault :-/

[...]

> The segfault seems to be in tar.  After replacing both tar and xz with
> the versions from the tarball, however, the segfault disappears.  I'm
> now running "make check" again.  So far it looks good as it takes longer
> than before.

Ah, good.

In the next ‘core-updates’ round, we’ll update those binaries, then.

Thanks for testing!

Ludo’.