Re: Boostrap tar cannot exec xz

[ludo@gnu.org (Ludovic Courtès)]

Hi!

csanchezdll@gmail.com (Carlos Sánchez de La Lama) skribis:

>> In ‘raw-build’ in bootstrap.scm, we run:
>>
>>   xz -dc thing.tar.xz | tar xv
>
> If I have understood correctly the code, raw-build is only used for
> %bootstrap-guile. However, the problem arises when building make (I do
> not have access to that machine righg now, so I am unsure of the exact
> package). i guess one option would be to create bootstrap versions of
> all packages on which tar depends (most probably already exist) and use
> xz | tar on them, until the requirements for a new non-bootstrap tar
> build can be met.

The question is how ‘tar’ in the ‘bootstrap-binaries’ we use on other
arches differs from the one you just built.

--8<---------------cut here---------------start------------->8---
$ guix build bootstrap-binaries --fallback
/gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0
ludo@pluto ~/src/guix$ /gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0/bin/tar --version
tar (GNU tar) 1.27
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.
$ strings /gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0/bin/tar |grep bin/sh
/bin/sh
$ touch foo.tar.xz
$ strace -e execve -f /gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0/bin/tar xf foo.tar.xz
execve("/gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0/bin/tar", ["/gnu/store/zh914iy23h97fwskh12vl"..., "xf", "foo.tar.xz"], [/* 63 vars */]) = 0
/gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0/bin/tar: This does not look like a tar archive
Process 28766 attached
[pid 28766] execve("/home/ludo/.guix-profile/bin/xz", ["xz", "-d"], [/* 63 vars */]) = 0
xz: (stdin): File format not recognized
[pid 28766] +++ exited with 1 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=28766, si_status=1, si_utime=0, si_stime=0} ---
/gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0/bin/tar: Child returned status 1
/gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0/bin/tar: Error is not recoverable: exiting now
+++ exited with 2 +++
--8<---------------cut here---------------end--------------->8---

So apparently, tar 1.27 did not execute xz via /bin/sh, but current tar
does not either:

--8<---------------cut here---------------start------------->8---
$ strace -e execve -f tar xf ~/src/guix/foo.tar.gz 
execve("/run/current-system/profile/bin/tar", ["tar", "xf", "/home/ludo/src/guix/foo.tar.gz"], [/* 63 vars */]) = 0
Process 29347 attached
[pid 29347] execve("/home/ludo/soft/bin/gzip", ["gzip", "-d"], [/* 63 vars */]) = -1 ENOENT (No such file or directory)
[pid 29347] execve("/home/ludo/.opam/system/bin/gzip", ["gzip", "-d"], [/* 63 vars */]) = -1 ENOENT (No such file or directory)
[pid 29347] execve("/home/ludo/.guix-profile/bin/gzip", ["gzip", "-d"], [/* 63 vars */]) = -1 ENOENT (No such file or directory)
[pid 29347] execve("/home/ludo/.guix-profile/sbin/gzip", ["gzip", "-d"], [/* 63 vars */]) = -1 ENOENT (No such file or directory)
[pid 29347] execve("/run/setuid-programs/gzip", ["gzip", "-d"], [/* 63 vars */]) = -1 ENOENT (No such file or directory)
[pid 29347] execve("/run/current-system/profile/bin/gzip", ["gzip", "-d"], [/* 63 vars */]) = 0
[pid 29347] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=29347, si_status=0, si_utime=0, si_stime=0} ---
+++ exited with 0 +++
$ tar --version
tar (GNU tar) 1.29
Copyright (C) 2015 Free Software Foundation, Inc.
Permeso GPLv3+: GNU GPL versio 3 aŭ posta <http://gnu.org/licenses/gpl.html>.
Tio ĉi estas libera programaro: vi estas libera por ŝanĝi kaj redisdoni ĝin.
Ekzistas NENIU GARANTIO, laŭ plej amplekse permesate de la leĝoj.

Verkita de John Gilmore kaj Jay Fenlason.
--8<---------------cut here---------------end--------------->8---

Could you check exactly what’s going on and send more details?

> Another option that just csme to my mind is replacing all the nuked
> store referenced in the static binaries with references to the unpacked
> store path after extraction. As the nuked references can be easily
> identified by the "eeeeee..." fake path, this should be doable.

That’s not doable because we don’t know the hash in advance.

Thanks,
Ludo’.