Hi!
I'm playing around with the bootstrapping of Guix. I figured out that at the
very beginning executables for bash, mkdir, xz, tar, get downloaded into the
store, which is done by some Guile, I think it is (default-guile). Then a
guile-*.tar.xz file is downloaded and extracted into the sto
rk through some of the
options. It looks like a variable was mis-initialized as -1, causing
that branch of the code to always fail. I've pushed an update to the
glibc-bootstrap-system.patch on core-updates that produces working
bootstrap binaries.
--
Efraim Flashner אפרים פלשנר
GPG k
I have an ongoing project to finish the port of Guix to 32-bit PowerPC
and it looks like we're almost there. I ran into a snag with glibc-2.31
since it gave all sorts of problems on PPC but core-updates now has
2.32. Unfortunately the patch glibc-bootstrap-system.patch didn't apply
cleanly anymore
On Mon, Jun 01, 2020 at 07:56:43PM -0700, Chris Marusich wrote:
> Hi everyone!
>
> Thanks to Léo's help, as of commit
> 8159ce1970d91567468cf1bacac313099a009d2a, the master branch now contains
> all the changes necessary to cross-compile powerpc64-linux bootstrap
> bi
On Tue, 2 Jun 2020, Chris Marusich wrote:
I have opened up a bug report for this issue, so we can continue the
discussion there:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41669
I will try on my end to obtain a differing gcc to see if I can analyze
the difference. In the meantime, could yo
Hi Vincent, Jack, and Maxim,
Thank you for the quick replies! OK, so gcc differs for each of us:
* Chris:
8aca7f332a1ba8e3c2225c161a7545b0a04ddd690d164dc97afee9c9ea067b0c49bc155e9f06d285c22e24cdd16d91e59730af5f1dd9efcda13a26bede5948a2
* Vincent:
87f7583cf483ac3ba0ab978862873e68757bc4ddd10f739a
On Tue, 2 Jun 2020, Vincent Legoll wrote:
Hello,
On 02/06/2020 04:56, Chris Marusich wrote:
Hopefully, you'll get identical results! You don't have to run "guix
gc" if you don't want to, but doing so will increase the likelihood of
catching nondeterminism issues propagated from dependencies (
Hi Chris!
Chris Marusich writes:
> Hi everyone!
>
> Thanks to Léo's help, as of commit
> 8159ce1970d91567468cf1bacac313099a009d2a, the master branch now contains
> all the changes necessary to cross-compile powerpc64-linux bootstrap
> binaries. I've done this withou
Hello,
On 02/06/2020 04:56, Chris Marusich wrote:
Hopefully, you'll get identical results! You don't have to run "guix
gc" if you don't want to, but doing so will increase the likelihood of
catching nondeterminism issues propagated from dependencies (which seem
unlikely, but you never know). I
Hi everyone!
Thanks to Léo's help, as of commit
8159ce1970d91567468cf1bacac313099a009d2a, the master branch now contains
all the changes necessary to cross-compile powerpc64-linux bootstrap
binaries. I've done this without substitutes by running the following
commands on an x86_64-liin
se for all the non-Intel arches and for GNU/Hurd.
>
> Is that what you meant?
My question was more about: why do we check in bootstrap binaries for
different architectures, instead of checking in bootstrap binaries for
one "base" architecture and then generating the bootstrap binaries
l...@gnu.org (Ludovic Courtès) writes:
>> For efraim and for myself,
>>
>> guix build --target=mips64el-linux-gnu bootrap-tarballs
>>
>> got broken with commit
>>
>> b9bc6e842066b066ebdf9eaf75d41753598d75b5
>>
This still fails. The error I see today, using commit
5aa6e0d04a3f9dea06b9d35f04fa709b
Hello,
In practice, apart from x86_64-linux which was bootstrapped on NixOS, we
always cross-compile to bootstrap new architectures:
https://www.gnu.org/software/guix/manual/html_node/Porting.html
That was the case for all the non-Intel arches and for GNU/Hurd.
Is that what you meant?
Ludo’.
On Thu, Nov 23, 2017 at 04:47:51PM -0800, Chris Marusich wrote:
> Hi,
>
> We have bootstrap binaries for various platforms. For example, commit
> 3b88f3767d9f3ad2cc64173525cd53d429bfe7e7 adds bootstrap binaries for
> aarch64-linux. Judging by the commit message, my gues
Hi,
We have bootstrap binaries for various platforms. For example, commit
3b88f3767d9f3ad2cc64173525cd53d429bfe7e7 adds bootstrap binaries for
aarch64-linux. Judging by the commit message, my guess is that these
bootstrap binaries were built (cross-compiled, I presume) using Guix at
commit
Hi Ludo,
> Ricardo Wurmus skribis:
>
>> we have some Makefile rules that download some bootstrap binaries for
>> us. Why is this necessary? Could we ship these bootstrap binaries
>> instead?
>
> These makefile rules were here mostly so that the tarball is not too
Hello,
Ricardo Wurmus skribis:
> we have some Makefile rules that download some bootstrap binaries for
> us. Why is this necessary? Could we ship these bootstrap binaries
> instead?
These makefile rules were here mostly so that the tarball is not too big.
They are gone now in ‘cor
Hi Guix,
we have some Makefile rules that download some bootstrap binaries for
us. Why is this necessary? Could we ship these bootstrap binaries
instead?
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
4
> (I’m afraid you’ll be mad at me for asking you that ;-)) because it’s
> bit-reproducible.
>
> How does that sound?
That actually sounds like a great idea. I started by copying Mark's
armhf patch, and I was wondering which commit he used. As far as
rebuilding the bootstrap-binaries
Efraim Flashner skribis:
> * gnu/packages/bootstrap/aarch64-linux/bash,
> gnu/packages/bootstrap/aarch64-linux/mkdir,
> gnu/packages/bootstrap/aarch64-linux/xz,
> gnu/packages/bootstrap/aarch64-linux/tar: New files.
>
> * gnu/local.mk (bootstrap_aarch64_linuxdir)
> (dist_bootstrap_aarch64_linux_D
n~%"
;; This is where the initial binaries come from.
'("ftp://alpha.gnu.org/gnu/guix/bootstrap";
"http://alpha.gnu.org/gnu/guix/bootstrap";
-"http://www.fdn.fr/~lcourtes/software/guix/packages";))
+"h
ix-system->gnu-triplet’
instead.
> +(inputs
> + ;; FIXME: Use system gcc:lib. Does gcc "lib" need to be
> + ;; added to %final-inputs?
> + `(("gcc:lib" ,gcc "lib")
Use (canonical-package gcc).
> +(define-public rust-boot
ersion.
+(define %rust-bootstrap-binaries-version "1.12.1")
+
+(define %rust-bootstrap-binaries
+ (origin
+(method url-fetch)
+(uri (string-append
+ "https://static.rust-lang.org/dist/";
+ ;; TODO: Maybe use the i686 binary for bootstrapping rustc on i686
Hi Carlos,
csanchez...@gmail.com (Carlos Sánchez de La Lama) skribis:
>> Regardless, cross-building ‘bootstrap-tarballs’ to one of the supported
>> target triplets works on master:
>>
>> --8<---cut here---start->8---
>> $ ./pre-inst-env guix build bootstrap-tar
Hi!
> Regardless, cross-building ‘bootstrap-tarballs’ to one of the supported
> target triplets works on master:
>
> --8<---cut here---start->8---
> $ ./pre-inst-env guix build bootstrap-tarballs --target=mips64el-linux-gnu -n
> substitute: updating list of subs
Hello!
csanchez...@gmail.com (Carlos Sánchez de La Lama) skribis:
> with current master (1dc30f92320c5e1b528a7eec2b0a4ce529f70c56), trying
>
> guix build --target=i686-linux bootstrap-tarballs
As discussed on IRC, --target expect a “GNU triplet” such as
“i686-linux-gnu”, so the above thing canno
On Thu, Oct 20, 2016 at 11:07:14AM +0200, Carlos Sánchez de La Lama wrote:
> Hi all,
>
> with current master (1dc30f92320c5e1b528a7eec2b0a4ce529f70c56), trying
>
> guix build --target=i686-linux bootstrap-tarballs
>
> fails with
>
> --8<---cut here---start->8
Hi all,
with current master (1dc30f92320c5e1b528a7eec2b0a4ce529f70c56), trying
guix build --target=i686-linux bootstrap-tarballs
fails with
--8<---cut here---start->8---
starting phase `unpack'
In execvp of tar: No such file or directory
phase `unpack' failed
Jookia <166...@gmail.com> skribis:
> On Sun, Feb 28, 2016 at 04:08:00PM +0100, Ludovic Courtès wrote:
>> We would have to update them every time we change GCC, Guile, Coreutils,
>> etc. or one of their dependencies, which sounds impractical or even
>> infeasible to me.
>
> Perhaps there's some mis
Jookia writes:
> On Sun, Feb 28, 2016 at 04:08:00PM +0100, Ludovic Courtès wrote:
>> We would have to update them every time we change GCC, Guile, Coreutils,
>> etc. or one of their dependencies, which sounds impractical or even
>> infeasible to me.
>
> Perhaps there's some miscommunication here-
On Sun, Feb 28, 2016 at 04:08:00PM +0100, Ludovic Courtès wrote:
> We would have to update them every time we change GCC, Guile, Coreutils,
> etc. or one of their dependencies, which sounds impractical or even
> infeasible to me.
Perhaps there's some miscommunication here- the problem right now is
s wrt. Ken Thompson attacks.
>
> I'm not sure about that, if we could establish the binaries could be
> reproducibly built using the current bootstrap binaries it sounds like it
> could
> be fine. Having reproducible bootstrap binaries seems like something
> incredibly
> use
t, if we could establish the binaries could be
reproducibly built using the current bootstrap binaries it sounds like it could
be fine. Having reproducible bootstrap binaries seems like something incredibly
useful especially for packagers that for whatever reason want to verify that the
binaries can be b
t;>>> process like when we have the core-updates? If we bootstrap away enough
>>>> times
>>>> would we end up with the bootstrap binaries we have now?
>>>
>>> From what I understand the bootstrap binaries aren't reproducible yet.
>&g
we bootstrap away enough
>>> times
>>> would we end up with the bootstrap binaries we have now?
>>
>> From what I understand the bootstrap binaries aren't reproducible yet.
>
> Depends on what kind of reproducibility we’re talking about. It’s
> simpl
e end up with the bootstrap binaries we have now?
>
> From what I understand the bootstrap binaries aren't reproducible yet.
Depends on what kind of reproducibility we’re talking about. It’s
simple to build bootstrap binaries:
https://www.gnu.org/software/guix/manual/html_node/Boo
31 Dec 2014 03:41:50 -0500
> Subject: [PATCH 2/2] gnu: bootstrap: Fix egrep and fgrep after unpacking
> bootstrap binaries.
>
> * gnu/packages/bootstrap.scm (%bootstrap-coreutils&co): Add #:snippet argument
> to 'package-from-tarball' that calls 'patch-shebang' on egrep and fgrep
> after unpacking. Test 'fgrep' instead of 'true'.
OK.
Thanks!
Ludo’.
,@(if snippet (list snippet) '())
(zero? (system* (string-append "bin/" ,program-to-test)
"--version"
(inputs
--
2.1.2
>From 34412a7202cabafd25daaa045f70aa567e867d3b Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date:
38 matches
Mail list logo
