Hi! csanchez...@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’.
