GNU bug report logs -
#41669
Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible
Previous Next
Full log
Message #134 received at 41669 <at> debbugs.gnu.org (full text, mbox):
Hi Chris & all,
Apologies for taking so long to reply! Pinging me on IRC was the right
move. :-)
Chris Marusich <cmmarusich <at> gmail.com> skribis:
> I'm afraid I've hit a snag using what you've uploaded, though. It looks
> like we'll need to extract bash, mkdir, tar, and xz from
> static-binaries-0-powerpc64le-linux-gnu.tar.xz and place a copy of each
> in the following locations:
>
> - https://alpha.gnu.org/gnu/guix/bootstrap/powerpc64le-linux/20210106/bash
> - https://alpha.gnu.org/gnu/guix/bootstrap/powerpc64le-linux/20210106/mkdir
> - https://alpha.gnu.org/gnu/guix/bootstrap/powerpc64le-linux/20210106/tar
> - https://alpha.gnu.org/gnu/guix/bootstrap/powerpc64le-linux/20210106/xz
>
> Could you do that? The reason why it's necessary is described below.
I’ve uploaded these four files now.
> I've started making changes locally to (gnu packages bootstrap). So
> far, with the attached patch, I'm able to do the following things on my
> POWER9 machine running ppc64le Debian (unstable).
>
> I can successfully build Guix from source using Debian packages (and a
> manually-built copy of guile-avahi and guile-gnutls). With my patch, I
> still have to supply the "--with-courage" configure option. Although
> "make" succeeded, "make check" failed on the following tests:
>
> - tests/build-utils.scm
> - test/challenge.scm
> - tests/containers.scm
> - tests/debug-link.scm
>
> The failures fell into two categories:
>
> - Some tests couldn't download the bootstrap bash.
> - In tests/containers.scm, call-with-container evaluated to #f when it
> wasn't supposed to.
Perhaps we can investigate them later.
> Nevertheless, I created the necessary build users and started the
> guix-daemon via pre-inst-env. I then tried building a simple package:
>
> ./pre-inst-env guix build -e '(@@ (gnu packages bootstrap) %bootstrap-coreutils&co)'
[...]
> Starting download of /gnu/store/2phdifnfw6i989rqbav04zakxx7qb165-static-binaries-0-powerpc64le-linux-gnu.tar.xz
> From https://ftp.gnu.org/gnu/guix/bootstrap/powerpc64le-linux/20210106/static-binaries-0-powerpc64le-linux-gnu.tar.xz...
> failed to download "/gnu/store/0kaj6l1ccw0qd0289hii7qhr828s71sv-bash" from ("https://git.savannah.gnu.org/cgit/guix.git/plain/gnu/packages/bootstrap/powerpc64le-linux/20210106/bash" "http://lilypond.org/janneke/guix/powerpc64le-linux/20210106/bash")
> builder for `/gnu/store/ix4mpvzxfi1hrmvdmmpgqhm9x1cdh347-bash.drv' failed to produce output path `/gnu/store/0kaj6l1ccw0qd0289hii7qhr828s71sv-bash'
Note that for testing purposes, you could always work around this by
adding these four files to the store with the ‘add-to-store’ RPC (I
don’t think ‘guix download’ would work because you need the executable
bit.)
> By the way, I've noticed that the other architectures don't seem to have
> "raw" binaries at all on alpha.gnu.org. Maybe you already knew this,
> but it seems that the "raw" binaries are actually downloaded from this
> specific URL (see the bootstrap-executable-file-name procedure):
>
> https://git.savannah.gnu.org/cgit/guix.git/plain/gnu/packages/bootstrap/?id=44f07d1dc6806e97c4e9ee3e6be883cc59dc666e
>
> Is that intended?
Yes: these files used to be in version control, part of the Guix source
tarball, but now we just download them (commit
836a85da0e8609d40716581be00802ee43463038).
> I was surprised to discover that we store these four "raw" binaries in
> a totally separate place. That seems like it would make it easy for
> someone to accidentally forget to update the "raw" binaries when they
> update an architecture's bootstrap tarballs.
They’re visible in the dependency graph though, and they don’t need to
ever change.
Ludo’.
This bug report was last modified 4 years and 108 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.