Hi Chris & all, Apologies for taking so long to reply! Pinging me on IRC was the right move. :-)
Chris Marusich <cmmarus...@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’.
