Package: guix-patches;
Reported by: Jan Nieuwenhuizen <janneke <at> gnu.org>
Date: Tue, 26 Nov 2019 16:39:01 UTC
Severity: important
Tags: patch
Done: Jan Nieuwenhuizen <janneke <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38390 in the body.
You can then email your comments to 38390 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Tue, 26 Nov 2019 16:39:01 GMT) Full text and rfc822 format available.Jan Nieuwenhuizen <janneke <at> gnu.org>:guix-patches <at> gnu.org.
(Tue, 26 Nov 2019 16:39:01 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Jan Nieuwenhuizen <janneke <at> gnu.org> To: guix-patches <at> gnu.org Cc: Timothy Sample <samplet <at> ngyro.com> Subject: [core-updates] Scheme-only bootstrap: merge wip-bootstrap Date: Tue, 26 Nov 2019 17:38:39 +0100
Hi!
With the release of Mes 0.21, the wip-bootstrap branch is ready for a
first review. This is a big one, so I am opening this bug to discuss
and keep track of things.
Please note that wip-bootstrap uses development snapshots of Gash and
Gash Core Utils; we still expect some changes here and probably hard
resets of `wip-bootstrap'.
Gash has now reached pretty good posix compliance, which really helps to
run configure scripts and sh snippets in autotool-generated Makefiles.
Gash Core Utils currently comes with
[, awk, basename, cat, chmod, cmp, compress, cp, cut, diff, dirname,
egrep, expr, false, fgrep, find, gawk, grep, gzip, head, ln, ls,
mkdir, mv, pwd, reboot, rm, rmdir, sed, sleep, sort, tar, test,
touch, tr, true, uname, uniq, wc, and which.
that in comparison with Gash are much flakier. While basic
functionality is generally OK, most Gash tools cannot be used to
bootstrap the entire system yet. This holds especially for awk, grep,
and sed.
Between autoconf 2.61 (2006) and autoconf-2.63 (2008), much
functionality that was written in sed was moved to awk. The NEWS file
states performance reasons. Gash's sed is much mature than Gash's awk,
so currently it makes sense to target C versions of around 2004.
However, some of the 2004 C tools are not good enough anymore to
bootstrap the entire system; so we need a second round for them. The
Mes C Library is another constraint. With Mes 0.21 it gained support
for many early C tools; but more recent tools have C library
requirements that are not yet covered.
Another thing to note is that we do not have bzip2, lzip or xz and that
after 2009 some crucial tools (coreutils, diffutils, grep, sed, ...)
start shipping .xz or .lz tarballs only. While bzip2 can be built early
in the bootstrap, I only managed to build xz with a fairly recent gcc
(4.6).
Even with these considerations, there still is quite some room to change
build order and versions of the C versions of coreutils&co. The current
choices are mostly made by "what works". We could invest in fixing
Gash's awk or sed or enrich the Mes C library or ..., if that seems a
helpful thing to do.
When we manage to merge this, we will have halved the bootstrap seed
again, reducing the bootstrap seed to under 60MB.
--8<---------------cut here---------------start------------->8---
10:40:02 janneke <at> dundal:~/tmp [env]
$ cd guix-sob/
10:40:04 janneke <at> dundal:~/tmp/guix-sob [env]
$ du -schx $(readlink $(~/src/guix/wip-bootstrap/pre-inst-env guix build bootstrap-tarballs)/*)
388K /gnu/store/49giv6b94zbv2pjl6a9ycgy5ny9x3jbc-gash-bootstrap-guile-tarball-0.1-9.32188ac/gash-bootstrap-guile-0.1-9.32188ac-x86_64-linux.tar.xz
5.7M /gnu/store/47qxvqs7rm7agdp86lxr2jzvval5hkqc-guile-static-stripped-tarball-2.2.6/guile-static-stripped-2.2.6-x86_64-linux.tar.xz
80K /gnu/store/l6m2rmqs31mc9w7rl99xxl6m35x7fg6v-linux-libre-headers-stripped-tarball-4.19.56/linux-libre-headers-stripped-4.19.56-x86_64-linux.tar.xz
280K /gnu/store/gnz5mlnzcb0nkaiyad5smblalfjvi8xc-mescc-tools-static-stripped-tarball-0.6.1/mescc-tools-static-stripped-0.6.1-x86_64-linux.tar.xz
352K /gnu/store/p32p46x5iic0sff2wcf5gilddvfibb19-mes-minimal-stripped-tarball-0.21/mes-minimal-stripped-0.21-x86_64-linux.tar.xz
6.7M total
10:40:14 janneke <at> dundal:~/tmp/guix-sob [env]
$ for i in $(readlink $(~/src/guix/wip-bootstrap/pre-inst-env guix build bootstrap-tarballs)/*); do sudo tar xf $i; done
10:45:29 janneke <at> dundal:~/tmp/guix-sob [env]
$ du -schx *
6.2M bin
988K include
42M lib
8.3M share
58M total
--8<---------------cut here---------------end--------------->8---
Just when I thought the branch was functionally done; I already found one
small problem; I have pushed this ugly workaround
--8<---------------cut here---------------start------------->8---
bootstrap: ACL: disable tests. FIXME: LD_PRELOAD.
Running
./pre-inst-env build hello
fails to build acl:
ERROR: ld.so: object '/tmp/guix-build-acl-2.2.53.drv-0/acl-2.2.53/.libs/libtestlookup.so' from LD_PRELOAD cannot be preloaded: ignored. != ~
ERROR: ld.so: object '/tmp/guix-build-acl-2.2.53.drv-0/acl-2.2.53/.libs/libtestlookup.so' from LD_PRELOAD cannot be preloaded: ignored. != ~
ERROR: ld.so: object '/tmp/guix-build-acl-2.2.53.drv-0/acl-2.2.53/.libs/libtestlookup.so' from LD_PRELOAD cannot be preloaded: ignored. != ~
ERROR: ld.so: object '/tmp/guix-build-acl-2.2.53.drv-0/acl-2.2.53/.libs/libtestlookup.so' from LD_PRELOAD cannot be preloaded: ignored. != ~
[7] $ rm large-file -- failed
ERROR: ld.so: object '/tmp/guix-build-acl-2.2.53.drv-0/acl-2.2.53/.libs/libtestlookup.so' from LD_PRELOAD cannot be preloaded: ignored. != ~
4 commands (2 passed, 2 failed)
FAIL test/getfacl-lfs.test (exit status: 2)
* gnu/packages/acl.scm (acl): Disable tests.
--8<---------------cut here---------------end--------------->8---
It looks like a coreutils is getting built with a too early bootstrap
gcc/glibc, but I could use some help here.
Greetings,
janneke
--
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Sun, 01 Dec 2019 14:02:02 GMT) Full text and rfc822 format available.Message #8 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: Jan Nieuwenhuizen <janneke <at> gnu.org> Cc: Timothy Sample <samplet <at> ngyro.com>, 38390 <at> debbugs.gnu.org Subject: Re: [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap Date: Sun, 01 Dec 2019 15:01:25 +0100
Hello Janneke & Timothy! Jan Nieuwenhuizen <janneke <at> gnu.org> skribis: > Gash has now reached pretty good posix compliance, which really helps to > run configure scripts and sh snippets in autotool-generated Makefiles. > > Gash Core Utils currently comes with > > [, awk, basename, cat, chmod, cmp, compress, cp, cut, diff, dirname, > egrep, expr, false, fgrep, find, gawk, grep, gzip, head, ln, ls, > mkdir, mv, pwd, reboot, rm, rmdir, sed, sleep, sort, tar, test, > touch, tr, true, uname, uniq, wc, and which. Woow, excellent! Do I get it right that “Gash Core Utils” refers to the ‘gash-core-utils’ branch at <https://gitlab.com/janneke/gash>? So this is meant to be a Gash extension but separate from Gash. Looks really cool! Do you plan to eventually merge it on Savannah? (I expected to find the code there. :-) BTW, I posted (unimportant) patches to <https://lists.gnu.org/archive/html/gash-devel/2019-06/threads.html>.) > that in comparison with Gash are much flakier. While basic > functionality is generally OK, most Gash tools cannot be used to > bootstrap the entire system yet. This holds especially for awk, grep, > and sed. (gash core-utils awk *) look quite fancy though! I thought ‘configure’ only used a couple of trivial Awk snippets and after checking, I see that there are in fact relatively fancy Awk programs in there. Bah. > Between autoconf 2.61 (2006) and autoconf-2.63 (2008), much > functionality that was written in sed was moved to awk. The NEWS file > states performance reasons. Gash's sed is much mature than Gash's awk, > so currently it makes sense to target C versions of around 2004. > > However, some of the 2004 C tools are not good enough anymore to > bootstrap the entire system; so we need a second round for them. The > Mes C Library is another constraint. With Mes 0.21 it gained support > for many early C tools; but more recent tools have C library > requirements that are not yet covered. How much work would be necessary at first sign to implement what’s missing from (gash core-utils awk) to cover what modern-time ‘configure’ scripts need? I suppose having a good(-enough) Awk implementation in Gash would be more fruitful in the long run than reviving old C packages. Notably, I think you’d rather keep Mes’ libc as small as possible IMO, because it’s cumbersome to write and maintain, which means more Scheme and less C. But obviously, this all depends on the difficulty of implementing the missing bits of Awk. > Another thing to note is that we do not have bzip2, lzip or xz and that > after 2009 some crucial tools (coreutils, diffutils, grep, sed, ...) > start shipping .xz or .lz tarballs only. While bzip2 can be built early > in the bootstrap, I only managed to build xz with a fairly recent gcc > (4.6). At worst, we could host gzipped versions of these tarballs (or ask the maintainers to do so). Or we could have a fixed-output derivation that does the lzip->gzip conversion (creating a “soft” circular dependency), which is kinda equivalent to hosting a gzipped versions when substitutes are available. Longer-term, we could also consider having a derivation built-in that would allow us to “cheat” (i.e., take gz/lzip/xz/bzip2 for granted), though it’s not so nice. > Even with these considerations, there still is quite some room to change > build order and versions of the C versions of coreutils&co. The current > choices are mostly made by "what works". We could invest in fixing > Gash's awk or sed or enrich the Mes C library or ..., if that seems a > helpful thing to do. > > When we manage to merge this, we will have halved the bootstrap seed > again, reducing the bootstrap seed to under 60MB. Woohoo! > Just when I thought the branch was functionally done; I already found one > small problem; I have pushed this ugly workaround > > bootstrap: ACL: disable tests. FIXME: LD_PRELOAD. > > Running > > ./pre-inst-env build hello > > fails to build acl: > > ERROR: ld.so: object '/tmp/guix-build-acl-2.2.53.drv-0/acl-2.2.53/.libs/libtestlookup.so' from LD_PRELOAD cannot be preloaded: ignored. != ~ We should have a debugging session for this one. :-) What about building the ‘core’ subset of ‘wip-bootstrap’ on berlin? That would allow others to experiment (and debug!) without having to build it all by themselves. At some point we should consider “cleaning up” the history of that branch. For instance, I see commit “326d45561c gnu: Add gash. WIP”, which adds ‘guile-gash’ when there’s already a ‘gash’ package (and it also modifies ‘jupyter-guile-kernel’). We’ll also have to collectively review the new bootstrap tarballs. Anyway, great perspectives and much excitement! :-) Thank you, Ludo’.
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Sun, 01 Dec 2019 16:26:02 GMT) Full text and rfc822 format available.Message #11 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Timothy Sample <samplet <at> ngyro.com> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 38390 <at> debbugs.gnu.org, Jan Nieuwenhuizen <janneke <at> gnu.org> Subject: Re: [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap Date: Sun, 01 Dec 2019 11:25:03 -0500
Hi Ludovic, Ludovic Courtès <ludo <at> gnu.org> writes: > Hello Janneke & Timothy! > > Jan Nieuwenhuizen <janneke <at> gnu.org> skribis: > >> Gash has now reached pretty good posix compliance, which really helps to >> run configure scripts and sh snippets in autotool-generated Makefiles. >> >> Gash Core Utils currently comes with >> >> [, awk, basename, cat, chmod, cmp, compress, cp, cut, diff, dirname, >> egrep, expr, false, fgrep, find, gawk, grep, gzip, head, ln, ls, >> mkdir, mv, pwd, reboot, rm, rmdir, sed, sleep, sort, tar, test, >> touch, tr, true, uname, uniq, wc, and which. > > Woow, excellent! Do I get it right that “Gash Core Utils” refers to the > ‘gash-core-utils’ branch at <https://gitlab.com/janneke/gash>? For now (see below). > So this is meant to be a Gash extension but separate from Gash. Looks > really cool! My long term plan for it is to be a really, really souped-up version of “(guix build utils)”. Hopefully we can get reasonably nice Scheme interfaces for common shell idioms and then build the utilities on top of those interfaces. Then, the library could be useful independent of the external utilities, Gash, and bootstrapping. It’s nowhere near there yet, but that’s the goal. > Do you plan to eventually merge it on Savannah? (I expected to find the > code there. :-) Yes! I plan to add another repo as part of the Gash project. This will happen when it’s closer to an initial release. (I’ll have to audit all of the copyright notices, etc., which I find easier to do while getting ready for a release.) > BTW, I posted (unimportant) patches to > <https://lists.gnu.org/archive/html/gash-devel/2019-06/threads.html>.) I was not subscribed to gash-devel! :P I was an admin, but that doesn’t mean I was subscribed. Sorry! I noticed the install path patch that you added to the Guix package, so it’s already fixed. So far I’ve been too busy to test on Guile 3.... > [...] > How much work would be necessary at first sign to implement what’s > missing from (gash core-utils awk) to cover what modern-time ‘configure’ > scripts need? > > I suppose having a good(-enough) Awk implementation in Gash would be > more fruitful in the long run than reviving old C packages. Notably, I > think you’d rather keep Mes’ libc as small as possible IMO, because it’s > cumbersome to write and maintain, which means more Scheme and less C. > But obviously, this all depends on the difficulty of implementing the > missing bits of Awk. I agree this is the right way to go in the long run. I’m pretty sure we’ll get there, but I haven’t worked on the Awk implementation yet. In around one week (with the usual caveats around software estimates), I will make another release of Gash, at which point it will be “good enough” for the bootstrapping task. After that, I plan to turn my attention to the other utilities. There’s a lot of administrative work and cleaning to do there, so it will take some time to get a release out. Once that happens I’ll move on to removing some intermediate bootstrapping packages like early versions of Gawk, etc. -- Tim
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Sun, 01 Dec 2019 16:57:01 GMT) Full text and rfc822 format available.Message #14 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Jan Nieuwenhuizen <janneke <at> gnu.org> To: Timothy Sample <samplet <at> ngyro.com> Cc: Ludovic Courtès <ludo <at> gnu.org>, 38390 <at> debbugs.gnu.org Subject: Re: [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap Date: Sun, 01 Dec 2019 17:55:57 +0100
Timothy Sample writes: Hi Ludo, Timothy, >>> Gash Core Utils currently comes with >>> >>> [, awk, basename, cat, chmod, cmp, compress, cp, cut, diff, dirname, >>> egrep, expr, false, fgrep, find, gawk, grep, gzip, head, ln, ls, >>> mkdir, mv, pwd, reboot, rm, rmdir, sed, sleep, sort, tar, test, >>> touch, tr, true, uname, uniq, wc, and which. >> >> Woow, excellent! Do I get it right that “Gash Core Utils” refers to the >> ‘gash-core-utils’ branch at <https://gitlab.com/janneke/gash>? > > For now (see below). Right. I think that while Timothy mostly worked on the Gash core to make it a full sh alternative, I have been working in parallel to add all utilities that are needed during bootstrap. That worked out pretty OK, but now things need to come together again. >> So this is meant to be a Gash extension but separate from Gash. Looks >> really cool! > > My long term plan for it is to be a really, really souped-up version of > “(guix build utils)”. Hopefully we can get reasonably nice Scheme > interfaces for common shell idioms and then build the utilities on top > of those interfaces. Then, the library could be useful independent of > the external utilities, Gash, and bootstrapping. It’s nowhere near > there yet, but that’s the goal. Yes, a nice shell library for Guile was Rutger's initial goal for the pre-merger Gash. I have diverged quite a bit from that path by focussing on the actual shell tools -- so while some of the library functionality is starting to fall in place, an actual nice library interface is still mostly missing... >> Do you plan to eventually merge it on Savannah? (I expected to find the >> code there. :-) > > Yes! I plan to add another repo as part of the Gash project. This will > happen when it’s closer to an initial release. (I’ll have to audit all > of the copyright notices, etc., which I find easier to do while getting > ready for a release.) Great! >> BTW, I posted (unimportant) patches to >> <https://lists.gnu.org/archive/html/gash-devel/2019-06/threads.html>.) > > I was not subscribed to gash-devel! :P I was an admin, but that > doesn’t mean I was subscribed. Sorry! > > I noticed the install path patch that you added to the Guix package, so > it’s already fixed. So far I’ve been too busy to test on Guile 3.... Oh, I only subscribed in September 22nd...oops! >> I suppose having a good(-enough) Awk implementation in Gash would be >> more fruitful in the long run than reviving old C packages. Notably, I >> think you’d rather keep Mes’ libc as small as possible IMO, because it’s >> cumbersome to write and maintain, which means more Scheme and less C. >> But obviously, this all depends on the difficulty of implementing the >> missing bits of Awk. > > I agree this is the right way to go in the long run. I’m pretty sure > we’ll get there, but I haven’t worked on the Awk implementation yet. I think the parser is OK, and I also thought the Awk we needed was only assignments and printing columns. I started with a naive AST-interpreter that worked a bit too well but has a flawed design (I don't remember the details). We need some good tests and probably a re-thinking and re-implementatation of the `run-commands' and `awk-expression' functions. > In around one week (with the usual caveats around software estimates), I > will make another release of Gash, at which point it will be “good > enough” for the bootstrapping task. After that, I plan to turn my > attention to the other utilities. There’s a lot of administrative work > and cleaning to do there, so it will take some time to get a release > out. Once that happens I’ll move on to removing some intermediate > bootstrapping packages like early versions of Gawk, etc. Great! janneke -- Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Sun, 01 Dec 2019 17:15:02 GMT) Full text and rfc822 format available.Message #17 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: Timothy Sample <samplet <at> ngyro.com> Cc: 38390 <at> debbugs.gnu.org, Jan Nieuwenhuizen <janneke <at> gnu.org> Subject: Re: [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap Date: Sun, 01 Dec 2019 18:14:23 +0100
Hi, Timothy! Timothy Sample <samplet <at> ngyro.com> skribis: > Ludovic Courtès <ludo <at> gnu.org> writes: [...] >> So this is meant to be a Gash extension but separate from Gash. Looks >> really cool! > > My long term plan for it is to be a really, really souped-up version of > “(guix build utils)”. Hopefully we can get reasonably nice Scheme > interfaces for common shell idioms and then build the utilities on top > of those interfaces. Then, the library could be useful independent of > the external utilities, Gash, and bootstrapping. It’s nowhere near > there yet, but that’s the goal. I agree with the goal! Having a nice Scheme interface for all these things, perhaps with inspiration from scsh, would be great, and certainly nicer than the very ad-hoc (guix build utils). >> Do you plan to eventually merge it on Savannah? (I expected to find the >> code there. :-) > > Yes! I plan to add another repo as part of the Gash project. This will > happen when it’s closer to an initial release. (I’ll have to audit all > of the copyright notices, etc., which I find easier to do while getting > ready for a release.) Alright! >> BTW, I posted (unimportant) patches to >> <https://lists.gnu.org/archive/html/gash-devel/2019-06/threads.html>.) > > I was not subscribed to gash-devel! :P I was an admin, but that > doesn’t mean I was subscribed. Sorry! > > I noticed the install path patch that you added to the Guix package, so > it’s already fixed. So far I’ve been too busy to test on Guile 3.... Heheh, no problem. :-) > In around one week (with the usual caveats around software estimates), I > will make another release of Gash, at which point it will be “good > enough” for the bootstrapping task. After that, I plan to turn my > attention to the other utilities. There’s a lot of administrative work > and cleaning to do there, so it will take some time to get a release > out. Once that happens I’ll move on to removing some intermediate > bootstrapping packages like early versions of Gawk, etc. Sounds good, thanks a lot for all the work! Ludo’.
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Sun, 01 Dec 2019 17:22:02 GMT) Full text and rfc822 format available.Message #20 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Jan Nieuwenhuizen <janneke <at> gnu.org> To: Ludovic Courtès <ludo <at> gnu.org> Cc: Timothy Sample <samplet <at> ngyro.com>, 38390 <at> debbugs.gnu.org Subject: Re: [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap Date: Sun, 01 Dec 2019 18:21:05 +0100
Ludovic Courtès writes: > (gash core-utils awk *) look quite fancy though! I thought ‘configure’ > only used a couple of trivial Awk snippets and after checking, I see > that there are in fact relatively fancy Awk programs in there. Bah. Yeah, that's what I thought...and then it grew. > How much work would be necessary at first sign to implement what’s > missing from (gash core-utils awk) to cover what modern-time ‘configure’ > scripts need? > > I suppose having a good(-enough) Awk implementation in Gash would be > more fruitful in the long run than reviving old C packages. Notably, I > think you’d rather keep Mes’ libc as small as possible IMO, because it’s > cumbersome to write and maintain, which means more Scheme and less C. > But obviously, this all depends on the difficulty of implementing the > missing bits of Awk. > >> Another thing to note is that we do not have bzip2, lzip or xz and that >> after 2009 some crucial tools (coreutils, diffutils, grep, sed, ...) >> start shipping .xz or .lz tarballs only. While bzip2 can be built early >> in the bootstrap, I only managed to build xz with a fairly recent gcc >> (4.6). > > At worst, we could host gzipped versions of these tarballs (or ask the > maintainers to do so). Hmm. Yes. Somehow I would prefer if we could convince upstream to help us bootstrap their package (dare I say to "do the right thing"?). > Or we could have a fixed-output derivation that does the lzip->gzip > conversion (creating a “soft” circular dependency), which is kinda > equivalent to hosting a gzipped versions when substitutes are available. > > Longer-term, we could also consider having a derivation built-in that > would allow us to “cheat” (i.e., take gz/lzip/xz/bzip2 for granted), > though it’s not so nice. Okay, that's many options. Maybe we could brainstorm a bit about possible attack vectors against the different "solutions", WDYT? >> When we manage to merge this, we will have halved the bootstrap seed >> again, reducing the bootstrap seed to under 60MB. > > Woohoo! Yes, I feel so too; thanks! >> ERROR: ld.so: object '/tmp/guix-build-acl-2.2.53.drv-0/acl-2.2.53/.libs/libtestlookup.so' from LD_PRELOAD cannot be preloaded: ignored. != ~ > > We should have a debugging session for this one. :-) I would love that; I looked into it today but there is some dependency that I do not grok yet... > What about building the ‘core’ subset of ‘wip-bootstrap’ on berlin? > That would allow others to experiment (and debug!) without having to > build it all by themselves. Yes, that would be great! > At some point we should consider “cleaning up” the history of that > branch. For instance, I see commit “326d45561c gnu: Add gash. WIP”, > which adds ‘guile-gash’ when there’s already a ‘gash’ package (and it > also modifies ‘jupyter-guile-kernel’). Hmm, I cannot find that commit; are you looking at `wip-bootstrap' on savannah? I remember something like that and probably rewrote it. Anyway, the Gash and Gash Core Utils commits are marked WIP because I want to replace them with a proper release by Timothy :-) > We’ll also have to collectively review the new bootstrap tarballs. Yes, sure. > Anyway, great perspectives and much excitement! :-) Very happily enjoying the excitement you share, thanks :-) Greetings, janneke -- Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Fri, 06 Dec 2019 16:16:02 GMT) Full text and rfc822 format available.Message #23 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Jan Nieuwenhuizen <janneke <at> gnu.org> To: Ludovic Courtès <ludo <at> gnu.org> Cc: Timothy Sample <samplet <at> ngyro.com>, 38390 <at> debbugs.gnu.org Subject: Re: [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap Date: Fri, 06 Dec 2019 07:53:32 +0100
Jan Nieuwenhuizen writes:
>>> ERROR: ld.so: object
>>> '/tmp/guix-build-acl-2.2.53.drv-0/acl-2.2.53/.libs/libtestlookup.so'
>>> from LD_PRELOAD cannot be preloaded: ignored. != ~
>>
>> We should have a debugging session for this one. :-)
>
> I would love that; I looked into it today but there is some dependency
> that I do not grok yet...
Just a heads-up: In a productive and fun debugging session yesterday in
Marrakech Ludo and I got a fix in for this! This means that I now
consider `wip-bootstrap' functionally correct.
Earlier this week, Ludo and I found a way to not add Gash or Gash Core
Utils to the Bootstrap Seed and instead build them as first packages
using %bootstrap-guile.
We will be working on a rewrite of wip-bootstrap to have it use Gash
wip-0.2.0+ and include a number of cleanups.
Here is my current TODO list
* base bootstrap on Gash wip-0.20.0 (plus janneke's 2 patches)
* remove %bootstrap-gash (with gash core utils) from bootstrap seed
* look at possibility/cost to avoid updating the mescc-tools and mes
bootstrap binaries
* remove any generated (gitlab/github) tarballs
* look into awkward combined bash+gash dependency of glibc-mesboot0
* add some %bootX-input stages, at least when reached gcc-mesboot1
* commit messages: Use "Use Gash instead of coretutils&co." rather than
"Scheme-only bootstrap."
* some smaller cleanups and nitpicks here and there
Greetings,
janneke
--
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Sun, 08 Dec 2019 03:01:01 GMT) Full text and rfc822 format available.Message #26 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: Jan Nieuwenhuizen <janneke <at> gnu.org> Cc: Timothy Sample <samplet <at> ngyro.com>, 38390 <at> debbugs.gnu.org Subject: Re: [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap Date: Sat, 07 Dec 2019 23:31:37 +0100
Hello! Jan Nieuwenhuizen <janneke <at> gnu.org> skribis: > Just a heads-up: In a productive and fun debugging session yesterday in > Marrakech Ludo and I got a fix in for this! This means that I now > consider `wip-bootstrap' functionally correct. > > Earlier this week, Ludo and I found a way to not add Gash or Gash Core > Utils to the Bootstrap Seed and instead build them as first packages > using %bootstrap-guile. > > We will be working on a rewrite of wip-bootstrap to have it use Gash > wip-0.2.0+ and include a number of cleanups. It looks like this is all shaping up nicely, and I’m happy to see we’ve already (!) reached that point where we can again strip some of the binary seeds! Kudos, comrades! Ludo’.
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Sun, 08 Dec 2019 20:09:01 GMT) Full text and rfc822 format available.Message #29 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Jan Nieuwenhuizen <janneke <at> gnu.org> To: Timothy Sample <samplet <at> ngyro.com> Cc: 38390 <at> debbugs.gnu.org Subject: Re: Gash 0.2.0 Date: Sun, 08 Dec 2019 21:08:27 +0100
Timothy Sample writes:
[cc: 38390 <at> debbugs.gnu.org]
Hi Timothy,
> There’s one last thing I need from you (besides an OK on your test
> whenever you get to it).
I just found two things I'm not too happy about. Both stem from using
our bootstrap guile-2.0.9. Previously, I used guile-2.0 (= 2.0.14) to
compile the .go files that were later used during bootstrap.
When I build `gash-boot' on my real experimental `wip-boot' guix branch
at gitlab (https://gitlab.com/janneke/guix/tree/wip-boot) like so
./pre-inst-env guix build -e '(@@ (gnu packages commencement) gash-boot)'
and run gash, I get:
--8<---------------cut here---------------start------------->8---
20:44:25 janneke <at> dundal:~/src/guix/wip-boot [env]
$ ./pre-inst-env guix build -e '(@@ (gnu packages commencement) gash-boot)'
/gnu/store/hihv59xdpqfnijb5i2mi0g8wg09qphi4-gash-boot-0.1.50-c1b8
20:44:32 janneke <at> dundal:~/src/guix/wip-boot [env]
$ /gnu/store/8bl7iqln6qaajr3d6kwbyvkzy2gvr4rf-gash-boot-0.1.50-c1b8/bin/gash --version
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 242
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 241
%% Shift/Reduce conflict (shift 25, reduce 50) on 'LESS' in state 236
%% Shift/Reduce conflict (shift 24, reduce 50) on 'GREAT' in state 236
%% Shift/Reduce conflict (shift 23, reduce 50) on 'LPAREN' in state 236
%% Shift/Reduce conflict (shift 241, reduce 50) on 'DSEMI' in state 236
%% Shift/Reduce conflict (shift 22, reduce 50) on 'DLESS' in state 236
%% Shift/Reduce conflict (shift 21, reduce 50) on 'DGREAT' in state 236
%% Shift/Reduce conflict (shift 20, reduce 50) on 'LESSAND' in state 236
%% Shift/Reduce conflict (shift 19, reduce 50) on 'GREATAND' in state 236
%% Shift/Reduce conflict (shift 18, reduce 50) on 'LESSGREAT' in state 236
%% Shift/Reduce conflict (shift 17, reduce 50) on 'DLESSDASH' in state 236
%% Shift/Reduce conflict (shift 16, reduce 50) on 'CLOBBER' in state 236
%% Shift/Reduce conflict (shift 15, reduce 50) on 'If' in state 236
%% Shift/Reduce conflict (shift 14, reduce 50) on 'Case' in state 236
%% Shift/Reduce conflict (shift 13, reduce 50) on 'While' in state 236
%% Shift/Reduce conflict (shift 12, reduce 50) on 'Until' in state 236
%% Shift/Reduce conflict (shift 11, reduce 50) on 'For' in state 236
%% Shift/Reduce conflict (shift 10, reduce 50) on 'Lbrace' in state 236
%% Shift/Reduce conflict (shift 9, reduce 50) on 'Bang' in state 236
%% Shift/Reduce conflict (shift 8, reduce 50) on 'WORD' in state 236
%% Shift/Reduce conflict (shift 7, reduce 50) on 'ASSIGNMENT-WORD' in state 236
%% Shift/Reduce conflict (shift 6, reduce 50) on 'NAME' in state 236
%% Shift/Reduce conflict (shift 5, reduce 50) on 'IO-NUMBER' in state 236
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 234
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 233
%% Shift/Reduce conflict (shift 180, reduce 60) on 'Else' in state 232
%% Shift/Reduce conflict (shift 179, reduce 60) on 'Elif' in state 232
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 231
%% Shift/Reduce conflict (shift 25, reduce 48) on 'LESS' in state 228
%% Shift/Reduce conflict (shift 24, reduce 48) on 'GREAT' in state 228
%% Shift/Reduce conflict (shift 23, reduce 48) on 'LPAREN' in state 228
%% Shift/Reduce conflict (shift 233, reduce 48) on 'DSEMI' in state 228
%% Shift/Reduce conflict (shift 22, reduce 48) on 'DLESS' in state 228
%% Shift/Reduce conflict (shift 21, reduce 48) on 'DGREAT' in state 228
%% Shift/Reduce conflict (shift 20, reduce 48) on 'LESSAND' in state 228
%% Shift/Reduce conflict (shift 19, reduce 48) on 'GREATAND' in state 228
%% Shift/Reduce conflict (shift 18, reduce 48) on 'LESSGREAT' in state 228
%% Shift/Reduce conflict (shift 17, reduce 48) on 'DLESSDASH' in state 228
%% Shift/Reduce conflict (shift 16, reduce 48) on 'CLOBBER' in state 228
%% Shift/Reduce conflict (shift 15, reduce 48) on 'If' in state 228
%% Shift/Reduce conflict (shift 14, reduce 48) on 'Case' in state 228
%% Shift/Reduce conflict (shift 13, reduce 48) on 'While' in state 228
%% Shift/Reduce conflict (shift 12, reduce 48) on 'Until' in state 228
%% Shift/Reduce conflict (shift 11, reduce 48) on 'For' in state 228
%% Shift/Reduce conflict (shift 10, reduce 48) on 'Lbrace' in state 228
%% Shift/Reduce conflict (shift 9, reduce 48) on 'Bang' in state 228
%% Shift/Reduce conflict (shift 8, reduce 48) on 'WORD' in state 228
%% Shift/Reduce conflict (shift 7, reduce 48) on 'ASSIGNMENT-WORD' in state 228
%% Shift/Reduce conflict (shift 6, reduce 48) on 'NAME' in state 228
%% Shift/Reduce conflict (shift 5, reduce 48) on 'IO-NUMBER' in state 228
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 226
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 219
%% Shift/Reduce conflict (shift 25, reduce 67) on 'LESS' in state 216
%% Shift/Reduce conflict (shift 24, reduce 67) on 'GREAT' in state 216
%% Shift/Reduce conflict (shift 22, reduce 67) on 'DLESS' in state 216
%% Shift/Reduce conflict (shift 21, reduce 67) on 'DGREAT' in state 216
%% Shift/Reduce conflict (shift 20, reduce 67) on 'LESSAND' in state 216
%% Shift/Reduce conflict (shift 19, reduce 67) on 'GREATAND' in state 216
%% Shift/Reduce conflict (shift 18, reduce 67) on 'LESSGREAT' in state 216
%% Shift/Reduce conflict (shift 17, reduce 67) on 'DLESSDASH' in state 216
%% Shift/Reduce conflict (shift 16, reduce 67) on 'CLOBBER' in state 216
%% Shift/Reduce conflict (shift 5, reduce 67) on 'IO-NUMBER' in state 216
%% Shift/Reduce conflict (shift 25, reduce 66) on 'LESS' in state 183
%% Shift/Reduce conflict (shift 24, reduce 66) on 'GREAT' in state 183
%% Shift/Reduce conflict (shift 22, reduce 66) on 'DLESS' in state 183
%% Shift/Reduce conflict (shift 21, reduce 66) on 'DGREAT' in state 183
%% Shift/Reduce conflict (shift 20, reduce 66) on 'LESSAND' in state 183
%% Shift/Reduce conflict (shift 19, reduce 66) on 'GREATAND' in state 183
%% Shift/Reduce conflict (shift 18, reduce 66) on 'LESSGREAT' in state 183
%% Shift/Reduce conflict (shift 17, reduce 66) on 'DLESSDASH' in state 183
%% Shift/Reduce conflict (shift 16, reduce 66) on 'CLOBBER' in state 183
%% Shift/Reduce conflict (shift 5, reduce 66) on 'IO-NUMBER' in state 183
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 180
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 179
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 164
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 157
%% Shift/Reduce conflict (shift 25, reduce 30) on 'LESS' in state 156
%% Shift/Reduce conflict (shift 24, reduce 30) on 'GREAT' in state 156
%% Shift/Reduce conflict (shift 23, reduce 30) on 'LPAREN' in state 156
%% Shift/Reduce conflict (shift 22, reduce 30) on 'DLESS' in state 156
%% Shift/Reduce conflict (shift 21, reduce 30) on 'DGREAT' in state 156
%% Shift/Reduce conflict (shift 20, reduce 30) on 'LESSAND' in state 156
%% Shift/Reduce conflict (shift 19, reduce 30) on 'GREATAND' in state 156
%% Shift/Reduce conflict (shift 18, reduce 30) on 'LESSGREAT' in state 156
%% Shift/Reduce conflict (shift 17, reduce 30) on 'DLESSDASH' in state 156
%% Shift/Reduce conflict (shift 16, reduce 30) on 'CLOBBER' in state 156
%% Shift/Reduce conflict (shift 15, reduce 30) on 'If' in state 156
%% Shift/Reduce conflict (shift 14, reduce 30) on 'Case' in state 156
%% Shift/Reduce conflict (shift 13, reduce 30) on 'While' in state 156
%% Shift/Reduce conflict (shift 12, reduce 30) on 'Until' in state 156
%% Shift/Reduce conflict (shift 11, reduce 30) on 'For' in state 156
%% Shift/Reduce conflict (shift 10, reduce 30) on 'Lbrace' in state 156
%% Shift/Reduce conflict (shift 9, reduce 30) on 'Bang' in state 156
%% Shift/Reduce conflict (shift 8, reduce 30) on 'WORD' in state 156
%% Shift/Reduce conflict (shift 7, reduce 30) on 'ASSIGNMENT-WORD' in state 156
%% Shift/Reduce conflict (shift 6, reduce 30) on 'NAME' in state 156
%% Shift/Reduce conflict (shift 5, reduce 30) on 'IO-NUMBER' in state 156
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 149
%% Shift/Reduce conflict (shift 25, reduce 71) on 'LESS' in state 146
%% Shift/Reduce conflict (shift 24, reduce 71) on 'GREAT' in state 146
%% Shift/Reduce conflict (shift 22, reduce 71) on 'DLESS' in state 146
%% Shift/Reduce conflict (shift 21, reduce 71) on 'DGREAT' in state 146
%% Shift/Reduce conflict (shift 20, reduce 71) on 'LESSAND' in state 146
%% Shift/Reduce conflict (shift 19, reduce 71) on 'GREATAND' in state 146
%% Shift/Reduce conflict (shift 18, reduce 71) on 'LESSGREAT' in state 146
%% Shift/Reduce conflict (shift 17, reduce 71) on 'DLESSDASH' in state 146
%% Shift/Reduce conflict (shift 16, reduce 71) on 'CLOBBER' in state 146
%% Shift/Reduce conflict (shift 97, reduce 71) on 'If' in state 146
%% Shift/Reduce conflict (shift 96, reduce 71) on 'Then' in state 146
%% Shift/Reduce conflict (shift 95, reduce 71) on 'Else' in state 146
%% Shift/Reduce conflict (shift 94, reduce 71) on 'Elif' in state 146
%% Shift/Reduce conflict (shift 93, reduce 71) on 'Fi' in state 146
%% Shift/Reduce conflict (shift 92, reduce 71) on 'Do' in state 146
%% Shift/Reduce conflict (shift 91, reduce 71) on 'Done' in state 146
%% Shift/Reduce conflict (shift 90, reduce 71) on 'Case' in state 146
%% Shift/Reduce conflict (shift 89, reduce 71) on 'Esac' in state 146
%% Shift/Reduce conflict (shift 88, reduce 71) on 'While' in state 146
%% Shift/Reduce conflict (shift 87, reduce 71) on 'Until' in state 146
%% Shift/Reduce conflict (shift 86, reduce 71) on 'For' in state 146
%% Shift/Reduce conflict (shift 85, reduce 71) on 'Lbrace' in state 146
%% Shift/Reduce conflict (shift 84, reduce 71) on 'Rbrace' in state 146
%% Shift/Reduce conflict (shift 83, reduce 71) on 'Bang' in state 146
%% Shift/Reduce conflict (shift 82, reduce 71) on 'In' in state 146
%% Shift/Reduce conflict (shift 81, reduce 71) on 'WORD' in state 146
%% Shift/Reduce conflict (shift 80, reduce 71) on 'ASSIGNMENT-WORD' in state 146
%% Shift/Reduce conflict (shift 79, reduce 71) on 'NAME' in state 146
%% Shift/Reduce conflict (shift 5, reduce 71) on 'IO-NUMBER' in state 146
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 143
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 135
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 134
%% Shift/Reduce conflict (shift 127, reduce 29) on 'AND' in state 131
%% Shift/Reduce conflict (shift 126, reduce 29) on 'SEMI' in state 131
%% Shift/Reduce conflict (shift 1, reduce 29) on 'NEWLINE' in state 131
%% Shift/Reduce conflict (shift 25, reduce 105) on 'LESS' in state 130
%% Shift/Reduce conflict (shift 24, reduce 105) on 'GREAT' in state 130
%% Shift/Reduce conflict (shift 23, reduce 105) on 'LPAREN' in state 130
%% Shift/Reduce conflict (shift 22, reduce 105) on 'DLESS' in state 130
%% Shift/Reduce conflict (shift 21, reduce 105) on 'DGREAT' in state 130
%% Shift/Reduce conflict (shift 20, reduce 105) on 'LESSAND' in state 130
%% Shift/Reduce conflict (shift 19, reduce 105) on 'GREATAND' in state 130
%% Shift/Reduce conflict (shift 18, reduce 105) on 'LESSGREAT' in state 130
%% Shift/Reduce conflict (shift 17, reduce 105) on 'DLESSDASH' in state 130
%% Shift/Reduce conflict (shift 16, reduce 105) on 'CLOBBER' in state 130
%% Shift/Reduce conflict (shift 15, reduce 105) on 'If' in state 130
%% Shift/Reduce conflict (shift 14, reduce 105) on 'Case' in state 130
%% Shift/Reduce conflict (shift 13, reduce 105) on 'While' in state 130
%% Shift/Reduce conflict (shift 12, reduce 105) on 'Until' in state 130
%% Shift/Reduce conflict (shift 11, reduce 105) on 'For' in state 130
%% Shift/Reduce conflict (shift 10, reduce 105) on 'Lbrace' in state 130
%% Shift/Reduce conflict (shift 9, reduce 105) on 'Bang' in state 130
%% Shift/Reduce conflict (shift 8, reduce 105) on 'WORD' in state 130
%% Shift/Reduce conflict (shift 7, reduce 105) on 'ASSIGNMENT-WORD' in state 130
%% Shift/Reduce conflict (shift 6, reduce 105) on 'NAME' in state 130
%% Shift/Reduce conflict (shift 51, reduce 105) on 'NEWLINE' in state 130
%% Shift/Reduce conflict (shift 5, reduce 105) on 'IO-NUMBER' in state 130
%% Shift/Reduce conflict (shift 25, reduce 6) on 'LESS' in state 128
%% Shift/Reduce conflict (shift 24, reduce 6) on 'GREAT' in state 128
%% Shift/Reduce conflict (shift 23, reduce 6) on 'LPAREN' in state 128
%% Shift/Reduce conflict (shift 22, reduce 6) on 'DLESS' in state 128
%% Shift/Reduce conflict (shift 21, reduce 6) on 'DGREAT' in state 128
%% Shift/Reduce conflict (shift 20, reduce 6) on 'LESSAND' in state 128
%% Shift/Reduce conflict (shift 19, reduce 6) on 'GREATAND' in state 128
%% Shift/Reduce conflict (shift 18, reduce 6) on 'LESSGREAT' in state 128
%% Shift/Reduce conflict (shift 17, reduce 6) on 'DLESSDASH' in state 128
%% Shift/Reduce conflict (shift 16, reduce 6) on 'CLOBBER' in state 128
%% Shift/Reduce conflict (shift 15, reduce 6) on 'If' in state 128
%% Shift/Reduce conflict (shift 14, reduce 6) on 'Case' in state 128
%% Shift/Reduce conflict (shift 13, reduce 6) on 'While' in state 128
%% Shift/Reduce conflict (shift 12, reduce 6) on 'Until' in state 128
%% Shift/Reduce conflict (shift 11, reduce 6) on 'For' in state 128
%% Shift/Reduce conflict (shift 10, reduce 6) on 'Lbrace' in state 128
%% Shift/Reduce conflict (shift 9, reduce 6) on 'Bang' in state 128
%% Shift/Reduce conflict (shift 8, reduce 6) on 'WORD' in state 128
%% Shift/Reduce conflict (shift 7, reduce 6) on 'ASSIGNMENT-WORD' in state 128
%% Shift/Reduce conflict (shift 6, reduce 6) on 'NAME' in state 128
%% Shift/Reduce conflict (shift 5, reduce 6) on 'IO-NUMBER' in state 128
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 125
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 124
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 123
%% Shift/Reduce conflict (shift 25, reduce 19) on 'LESS' in state 122
%% Shift/Reduce conflict (shift 24, reduce 19) on 'GREAT' in state 122
%% Shift/Reduce conflict (shift 22, reduce 19) on 'DLESS' in state 122
%% Shift/Reduce conflict (shift 21, reduce 19) on 'DGREAT' in state 122
%% Shift/Reduce conflict (shift 20, reduce 19) on 'LESSAND' in state 122
%% Shift/Reduce conflict (shift 19, reduce 19) on 'GREATAND' in state 122
%% Shift/Reduce conflict (shift 18, reduce 19) on 'LESSGREAT' in state 122
%% Shift/Reduce conflict (shift 17, reduce 19) on 'DLESSDASH' in state 122
%% Shift/Reduce conflict (shift 16, reduce 19) on 'CLOBBER' in state 122
%% Shift/Reduce conflict (shift 5, reduce 19) on 'IO-NUMBER' in state 122
%% Shift/Reduce conflict (shift 25, reduce 74) on 'LESS' in state 119
%% Shift/Reduce conflict (shift 24, reduce 74) on 'GREAT' in state 119
%% Shift/Reduce conflict (shift 22, reduce 74) on 'DLESS' in state 119
%% Shift/Reduce conflict (shift 21, reduce 74) on 'DGREAT' in state 119
%% Shift/Reduce conflict (shift 20, reduce 74) on 'LESSAND' in state 119
%% Shift/Reduce conflict (shift 19, reduce 74) on 'GREATAND' in state 119
%% Shift/Reduce conflict (shift 18, reduce 74) on 'LESSGREAT' in state 119
%% Shift/Reduce conflict (shift 17, reduce 74) on 'DLESSDASH' in state 119
%% Shift/Reduce conflict (shift 16, reduce 74) on 'CLOBBER' in state 119
%% Shift/Reduce conflict (shift 97, reduce 74) on 'If' in state 119
%% Shift/Reduce conflict (shift 96, reduce 74) on 'Then' in state 119
%% Shift/Reduce conflict (shift 95, reduce 74) on 'Else' in state 119
%% Shift/Reduce conflict (shift 94, reduce 74) on 'Elif' in state 119
%% Shift/Reduce conflict (shift 93, reduce 74) on 'Fi' in state 119
%% Shift/Reduce conflict (shift 92, reduce 74) on 'Do' in state 119
%% Shift/Reduce conflict (shift 91, reduce 74) on 'Done' in state 119
%% Shift/Reduce conflict (shift 90, reduce 74) on 'Case' in state 119
%% Shift/Reduce conflict (shift 89, reduce 74) on 'Esac' in state 119
%% Shift/Reduce conflict (shift 88, reduce 74) on 'While' in state 119
%% Shift/Reduce conflict (shift 87, reduce 74) on 'Until' in state 119
%% Shift/Reduce conflict (shift 86, reduce 74) on 'For' in state 119
%% Shift/Reduce conflict (shift 85, reduce 74) on 'Lbrace' in state 119
%% Shift/Reduce conflict (shift 84, reduce 74) on 'Rbrace' in state 119
%% Shift/Reduce conflict (shift 83, reduce 74) on 'Bang' in state 119
%% Shift/Reduce conflict (shift 82, reduce 74) on 'In' in state 119
%% Shift/Reduce conflict (shift 81, reduce 74) on 'WORD' in state 119
%% Shift/Reduce conflict (shift 80, reduce 74) on 'ASSIGNMENT-WORD' in state 119
%% Shift/Reduce conflict (shift 79, reduce 74) on 'NAME' in state 119
%% Shift/Reduce conflict (shift 5, reduce 74) on 'IO-NUMBER' in state 119
%% Shift/Reduce conflict (shift 25, reduce 72) on 'LESS' in state 116
%% Shift/Reduce conflict (shift 24, reduce 72) on 'GREAT' in state 116
%% Shift/Reduce conflict (shift 22, reduce 72) on 'DLESS' in state 116
%% Shift/Reduce conflict (shift 21, reduce 72) on 'DGREAT' in state 116
%% Shift/Reduce conflict (shift 20, reduce 72) on 'LESSAND' in state 116
%% Shift/Reduce conflict (shift 19, reduce 72) on 'GREATAND' in state 116
%% Shift/Reduce conflict (shift 18, reduce 72) on 'LESSGREAT' in state 116
%% Shift/Reduce conflict (shift 17, reduce 72) on 'DLESSDASH' in state 116
%% Shift/Reduce conflict (shift 16, reduce 72) on 'CLOBBER' in state 116
%% Shift/Reduce conflict (shift 97, reduce 72) on 'If' in state 116
%% Shift/Reduce conflict (shift 96, reduce 72) on 'Then' in state 116
%% Shift/Reduce conflict (shift 95, reduce 72) on 'Else' in state 116
%% Shift/Reduce conflict (shift 94, reduce 72) on 'Elif' in state 116
%% Shift/Reduce conflict (shift 93, reduce 72) on 'Fi' in state 116
%% Shift/Reduce conflict (shift 92, reduce 72) on 'Do' in state 116
%% Shift/Reduce conflict (shift 91, reduce 72) on 'Done' in state 116
%% Shift/Reduce conflict (shift 90, reduce 72) on 'Case' in state 116
%% Shift/Reduce conflict (shift 89, reduce 72) on 'Esac' in state 116
%% Shift/Reduce conflict (shift 88, reduce 72) on 'While' in state 116
%% Shift/Reduce conflict (shift 87, reduce 72) on 'Until' in state 116
%% Shift/Reduce conflict (shift 86, reduce 72) on 'For' in state 116
%% Shift/Reduce conflict (shift 85, reduce 72) on 'Lbrace' in state 116
%% Shift/Reduce conflict (shift 84, reduce 72) on 'Rbrace' in state 116
%% Shift/Reduce conflict (shift 83, reduce 72) on 'Bang' in state 116
%% Shift/Reduce conflict (shift 82, reduce 72) on 'In' in state 116
%% Shift/Reduce conflict (shift 81, reduce 72) on 'WORD' in state 116
%% Shift/Reduce conflict (shift 80, reduce 72) on 'ASSIGNMENT-WORD' in state 116
%% Shift/Reduce conflict (shift 79, reduce 72) on 'NAME' in state 116
%% Shift/Reduce conflict (shift 5, reduce 72) on 'IO-NUMBER' in state 116
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 98
%% Shift/Reduce conflict (shift 135, reduce 106) on 'SEMI' in state 76
%% Shift/Reduce conflict (shift 134, reduce 106) on 'Do' in state 76
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 76
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 50
%% Shift/Reduce conflict (shift 127, reduce 7) on 'AND' in state 48
%% Shift/Reduce conflict (shift 126, reduce 7) on 'SEMI' in state 48
%% Shift/Reduce conflict (shift 25, reduce 18) on 'LESS' in state 43
%% Shift/Reduce conflict (shift 24, reduce 18) on 'GREAT' in state 43
%% Shift/Reduce conflict (shift 22, reduce 18) on 'DLESS' in state 43
%% Shift/Reduce conflict (shift 21, reduce 18) on 'DGREAT' in state 43
%% Shift/Reduce conflict (shift 20, reduce 18) on 'LESSAND' in state 43
%% Shift/Reduce conflict (shift 19, reduce 18) on 'GREATAND' in state 43
%% Shift/Reduce conflict (shift 18, reduce 18) on 'LESSGREAT' in state 43
%% Shift/Reduce conflict (shift 17, reduce 18) on 'DLESSDASH' in state 43
%% Shift/Reduce conflict (shift 16, reduce 18) on 'CLOBBER' in state 43
%% Shift/Reduce conflict (shift 5, reduce 18) on 'IO-NUMBER' in state 43
%% Shift/Reduce conflict (shift 25, reduce 75) on 'LESS' in state 32
%% Shift/Reduce conflict (shift 24, reduce 75) on 'GREAT' in state 32
%% Shift/Reduce conflict (shift 22, reduce 75) on 'DLESS' in state 32
%% Shift/Reduce conflict (shift 21, reduce 75) on 'DGREAT' in state 32
%% Shift/Reduce conflict (shift 20, reduce 75) on 'LESSAND' in state 32
%% Shift/Reduce conflict (shift 19, reduce 75) on 'GREATAND' in state 32
%% Shift/Reduce conflict (shift 18, reduce 75) on 'LESSGREAT' in state 32
%% Shift/Reduce conflict (shift 17, reduce 75) on 'DLESSDASH' in state 32
%% Shift/Reduce conflict (shift 16, reduce 75) on 'CLOBBER' in state 32
%% Shift/Reduce conflict (shift 97, reduce 75) on 'If' in state 32
%% Shift/Reduce conflict (shift 96, reduce 75) on 'Then' in state 32
%% Shift/Reduce conflict (shift 95, reduce 75) on 'Else' in state 32
%% Shift/Reduce conflict (shift 94, reduce 75) on 'Elif' in state 32
%% Shift/Reduce conflict (shift 93, reduce 75) on 'Fi' in state 32
%% Shift/Reduce conflict (shift 92, reduce 75) on 'Do' in state 32
%% Shift/Reduce conflict (shift 91, reduce 75) on 'Done' in state 32
%% Shift/Reduce conflict (shift 90, reduce 75) on 'Case' in state 32
%% Shift/Reduce conflict (shift 89, reduce 75) on 'Esac' in state 32
%% Shift/Reduce conflict (shift 88, reduce 75) on 'While' in state 32
%% Shift/Reduce conflict (shift 87, reduce 75) on 'Until' in state 32
%% Shift/Reduce conflict (shift 86, reduce 75) on 'For' in state 32
%% Shift/Reduce conflict (shift 85, reduce 75) on 'Lbrace' in state 32
%% Shift/Reduce conflict (shift 84, reduce 75) on 'Rbrace' in state 32
%% Shift/Reduce conflict (shift 83, reduce 75) on 'Bang' in state 32
%% Shift/Reduce conflict (shift 82, reduce 75) on 'In' in state 32
%% Shift/Reduce conflict (shift 81, reduce 75) on 'WORD' in state 32
%% Shift/Reduce conflict (shift 80, reduce 75) on 'ASSIGNMENT-WORD' in state 32
%% Shift/Reduce conflict (shift 79, reduce 75) on 'NAME' in state 32
%% Shift/Reduce conflict (shift 5, reduce 75) on 'IO-NUMBER' in state 32
%% Shift/Reduce conflict (shift 25, reduce 73) on 'LESS' in state 31
%% Shift/Reduce conflict (shift 24, reduce 73) on 'GREAT' in state 31
%% Shift/Reduce conflict (shift 22, reduce 73) on 'DLESS' in state 31
%% Shift/Reduce conflict (shift 21, reduce 73) on 'DGREAT' in state 31
%% Shift/Reduce conflict (shift 20, reduce 73) on 'LESSAND' in state 31
%% Shift/Reduce conflict (shift 19, reduce 73) on 'GREATAND' in state 31
%% Shift/Reduce conflict (shift 18, reduce 73) on 'LESSGREAT' in state 31
%% Shift/Reduce conflict (shift 17, reduce 73) on 'DLESSDASH' in state 31
%% Shift/Reduce conflict (shift 16, reduce 73) on 'CLOBBER' in state 31
%% Shift/Reduce conflict (shift 8, reduce 73) on 'WORD' in state 31
%% Shift/Reduce conflict (shift 113, reduce 73) on 'ASSIGNMENT-WORD' in state 31
%% Shift/Reduce conflict (shift 112, reduce 73) on 'NAME' in state 31
%% Shift/Reduce conflict (shift 5, reduce 73) on 'IO-NUMBER' in state 31
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 26
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 15
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 13
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 12
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 10
%% Shift/Reduce conflict (shift 25, reduce 3) on 'LESS' in state 2
%% Shift/Reduce conflict (shift 24, reduce 3) on 'GREAT' in state 2
%% Shift/Reduce conflict (shift 23, reduce 3) on 'LPAREN' in state 2
%% Shift/Reduce conflict (shift 22, reduce 3) on 'DLESS' in state 2
%% Shift/Reduce conflict (shift 21, reduce 3) on 'DGREAT' in state 2
%% Shift/Reduce conflict (shift 20, reduce 3) on 'LESSAND' in state 2
%% Shift/Reduce conflict (shift 19, reduce 3) on 'GREATAND' in state 2
%% Shift/Reduce conflict (shift 18, reduce 3) on 'LESSGREAT' in state 2
%% Shift/Reduce conflict (shift 17, reduce 3) on 'DLESSDASH' in state 2
%% Shift/Reduce conflict (shift 16, reduce 3) on 'CLOBBER' in state 2
%% Shift/Reduce conflict (shift 15, reduce 3) on 'If' in state 2
%% Shift/Reduce conflict (shift 14, reduce 3) on 'Case' in state 2
%% Shift/Reduce conflict (shift 13, reduce 3) on 'While' in state 2
%% Shift/Reduce conflict (shift 12, reduce 3) on 'Until' in state 2
%% Shift/Reduce conflict (shift 11, reduce 3) on 'For' in state 2
%% Shift/Reduce conflict (shift 10, reduce 3) on 'Lbrace' in state 2
%% Shift/Reduce conflict (shift 9, reduce 3) on 'Bang' in state 2
%% Shift/Reduce conflict (shift 8, reduce 3) on 'WORD' in state 2
%% Shift/Reduce conflict (shift 7, reduce 3) on 'ASSIGNMENT-WORD' in state 2
%% Shift/Reduce conflict (shift 6, reduce 3) on 'NAME' in state 2
%% Shift/Reduce conflict (shift 5, reduce 3) on 'IO-NUMBER' in state 2
%% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 0
Backtrace:
In ice-9/boot-9.scm:
3966: 19 [#<procedure 152f880 at ice-9/boot-9.scm:3961:3 ()>]
1645: 18 [%start-stack load-stack ...]
1650: 17 [#<procedure 1534540 ()>]
In unknown file:
?: 16 [primitive-load "/gnu/store/8bl7iqln6qaajr3d6kwbyvkzy2gvr4rf-gash-boot-0.1.50-c1b8/bin/gash"]
In ice-9/eval.scm:
505: 15 [#<procedure 13fba20 at ice-9/eval.scm:499:4 (exp)> (define # # #)]
In ice-9/psyntax.scm:
1101: 14 [expand-top-sequence ((define (main args) (setenv "SHELL" #) ...)) () ...]
1259: 13 [#<procedure 1488120 at ice-9/psyntax.scm:1067:36 ()>]
1605: 12 [expand-simple-lambda (# . #) () (()) ...]
1509: 11 [parse ((# . #) (# . #)) () () ...]
In ice-9/boot-9.scm:
625: 10 [map #<procedure 1538f60 at ice-9/psyntax.scm:1510:50 (x)> (# #)]
In ice-9/psyntax.scm:
1257: 9 [#<procedure 1538f60 at ice-9/psyntax.scm:1510:50 (x)> (# . #)]
1186: 8 [syntax-type (# #) (# #) (# # #) ...]
579: 7 [syntax-type main (# #) (#) ...]
293: 6 [get-global-definition-hook main (public gash gash)]
In ice-9/boot-9.scm:
2708: 5 [#<procedure 14a3f20 at ice-9/boot-9.scm:2696:4 (name #:optional autoload version #:key ensure)> # ...]
2981: 4 [try-module-autoload (gash gash) #f]
2320: 3 [save-module-excursion #<procedure 15389f0 at ice-9/boot-9.scm:2982:17 ()>]
3001: 2 [#<procedure 15389f0 at ice-9/boot-9.scm:2982:17 ()>]
In unknown file:
?: 1 [primitive-load-path "gash/gash" ...]
?: 0 [setlocale 6 ""]
ERROR: In procedure setlocale:
ERROR: In procedure setlocale: Invalid argument
[1]20:44:45 janneke <at> dundal:~/src/guix/wip-boot [env]
$
--8<---------------cut here---------------end--------------->8---
If I set LC_ALL=C
LC_ALL=C /gnu/store/8bl7iqln6qaajr3d6kwbyvkzy2gvr4rf-gash-boot-0.1.50-c1b8/bin/gash --version
then I (of course) still get the Shift/Reduce warnings and everything
"seems" to work. It seems that the empty locale is problematic for
guile 2.0.9 or our bootstrap environment. I just tried a patch and
pushed to my wip-0.2.0.
I am less cheerful about the Shift/Reduce warnings; I am afraid they
might break something somewhere during the bootstrap build. Any ideas
why these surface at this time? I'll play some more with
lalr.upstream.scm versions...
> Assuming all of the above is okay, Gash 0.2.0 is ready. \o/
Yay, scheme-only bootstrap, here we come \o/
Thanks for all your amazing work!
janneke
--
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Sun, 08 Dec 2019 22:12:01 GMT) Full text and rfc822 format available.Message #32 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Timothy Sample <samplet <at> ngyro.com> To: Jan Nieuwenhuizen <janneke <at> gnu.org> Cc: 38390 <at> debbugs.gnu.org Subject: Re: Gash 0.2.0 Date: Sun, 08 Dec 2019 17:11:10 -0500
[Message part 1 (text/plain, inline)]
Hi Jan, Jan Nieuwenhuizen <janneke <at> gnu.org> writes: > Timothy Sample writes: > > [cc: 38390 <at> debbugs.gnu.org] > > Hi Timothy, > >> There’s one last thing I need from you (besides an OK on your test >> whenever you get to it). > > I just found two things I'm not too happy about. Both stem from using > our bootstrap guile-2.0.9. Previously, I used guile-2.0 (= 2.0.14) to > compile the .go files that were later used during bootstrap. I did all of my bootstrapping tests with the bootstrap Guile. I’ve attached my package definition for reference (it belongs in “commencement.scm”). The reason I say this is to reassure you that going from 2.0.14 to 2.0.9 shouldn’t be too disruptive. > When I build `gash-boot' on my real experimental `wip-boot' guix branch > at gitlab (https://gitlab.com/janneke/guix/tree/wip-boot) like so > > ./pre-inst-env guix build -e '(@@ (gnu packages commencement) gash-boot)' > > and run gash, I get: > > 20:44:25 janneke <at> dundal:~/src/guix/wip-boot [env] > $ ./pre-inst-env guix build -e '(@@ (gnu packages commencement) gash-boot)' > /gnu/store/hihv59xdpqfnijb5i2mi0g8wg09qphi4-gash-boot-0.1.50-c1b8 > 20:44:32 janneke <at> dundal:~/src/guix/wip-boot [env] > $ /gnu/store/8bl7iqln6qaajr3d6kwbyvkzy2gvr4rf-gash-boot-0.1.50-c1b8/bin/gash --version > %% Shift/Reduce conflict (shift 1, reduce 106) on 'NEWLINE' in state 242 > Snipping a thousand more “Shift/Reduce” warnings.... > > Backtrace: > In ice-9/boot-9.scm: > 3966: 19 [#<procedure 152f880 at ice-9/boot-9.scm:3961:3 ()>] > 1645: 18 [%start-stack load-stack ...] > 1650: 17 [#<procedure 1534540 ()>] > In unknown file: > ?: 16 [primitive-load "/gnu/store/8bl7iqln6qaajr3d6kwbyvkzy2gvr4rf-gash-boot-0.1.50-c1b8/bin/gash"] > In ice-9/eval.scm: > 505: 15 [#<procedure 13fba20 at ice-9/eval.scm:499:4 (exp)> (define # # #)] > In ice-9/psyntax.scm: > 1101: 14 [expand-top-sequence ((define (main args) (setenv "SHELL" #) ...)) () ...] > 1259: 13 [#<procedure 1488120 at ice-9/psyntax.scm:1067:36 ()>] > 1605: 12 [expand-simple-lambda (# . #) () (()) ...] > 1509: 11 [parse ((# . #) (# . #)) () () ...] > In ice-9/boot-9.scm: > 625: 10 [map #<procedure 1538f60 at ice-9/psyntax.scm:1510:50 (x)> (# #)] > In ice-9/psyntax.scm: > 1257: 9 [#<procedure 1538f60 at ice-9/psyntax.scm:1510:50 (x)> (# . #)] > 1186: 8 [syntax-type (# #) (# #) (# # #) ...] > 579: 7 [syntax-type main (# #) (#) ...] > 293: 6 [get-global-definition-hook main (public gash gash)] > In ice-9/boot-9.scm: > 2708: 5 [#<procedure 14a3f20 at ice-9/boot-9.scm:2696:4 (name #:optional autoload version #:key ensure)> # ...] > 2981: 4 [try-module-autoload (gash gash) #f] > 2320: 3 [save-module-excursion #<procedure 15389f0 at ice-9/boot-9.scm:2982:17 ()>] > 3001: 2 [#<procedure 15389f0 at ice-9/boot-9.scm:2982:17 ()>] > In unknown file: > ?: 1 [primitive-load-path "gash/gash" ...] > ?: 0 [setlocale 6 ""] > > ERROR: In procedure setlocale: > ERROR: In procedure setlocale: Invalid argument > [1]20:44:45 janneke <at> dundal:~/src/guix/wip-boot [env] > $ > > If I set LC_ALL=C > > LC_ALL=C > /gnu/store/8bl7iqln6qaajr3d6kwbyvkzy2gvr4rf-gash-boot-0.1.50-c1b8/bin/gash > --version > > then I (of course) still get the Shift/Reduce warnings and everything > "seems" to work. It seems that the empty locale is problematic for > guile 2.0.9 or our bootstrap environment. I just tried a patch and > pushed to my wip-0.2.0. I added (at the last minute) the call to “setlocale” to normalize some differences between Guile 2 and Guile 2.2 (I was getting test failures without it). From reading Guile’s NEWS, version 2.2 started initializing the locale automatically, so I “backported” that to Guile 2 by calling “setlocale” with an empty string (as discussed in the manual). Anyway, this is definitely my fault! Perhaps it should try that and then fall back on “(setlocale LC_ALL "C")” if there is a problem. I’ll figure it out before releasing. > I am less cheerful about the Shift/Reduce warnings; I am afraid they > might break something somewhere during the bootstrap build. Any ideas > why these surface at this time? I'll play some more with > lalr.upstream.scm versions... My understanding is that these are spurious. There is upstream commit 92b64f9b3c02b0086a4aea7cbe7dc38376768150 which is not included in Guile 2.0.9 but included in later versions (maybe starting with 2.0.10 – I don’t recall). The commit message is “No more unexpected shift-reduce conflicts with LR driver.” See <https://github.com/schemeway/lalr-scm>. Since the newer versions are fine with the parser, and I have parsed oodles of shell script using Guile 2.0.9, I think the these warnings are just the result of a bug. :) -- Tim
[gash-boot.scm (text/plain, attachment)]
Ludovic Courtès <ludo <at> gnu.org>
to control <at> debbugs.gnu.org.
(Sun, 08 Dec 2019 22:21:02 GMT) Full text and rfc822 format available.Ludovic Courtès <ludo <at> gnu.org>
to control <at> debbugs.gnu.org.
(Sun, 08 Dec 2019 22:21:02 GMT) Full text and rfc822 format available.guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Mon, 09 Dec 2019 06:38:02 GMT) Full text and rfc822 format available.Message #39 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Jan Nieuwenhuizen <janneke <at> gnu.org> To: Timothy Sample <samplet <at> ngyro.com> Cc: 38390 <at> debbugs.gnu.org Subject: Re: Gash 0.2.0 Date: Mon, 09 Dec 2019 07:37:29 +0100
Timothy Sample writes: Hi Timothy, >> I just found two things I'm not too happy about. Both stem from using >> our bootstrap guile-2.0.9. Previously, I used guile-2.0 (= 2.0.14) to >> compile the .go files that were later used during bootstrap. > > I did all of my bootstrapping tests with the bootstrap Guile. I’ve > attached my package definition for reference (it belongs in > “commencement.scm”). The reason I say this is to reassure you that > going from 2.0.14 to 2.0.9 shouldn’t be too disruptive. Ah, that's great. >> then I (of course) still get the Shift/Reduce warnings and everything >> "seems" to work. It seems that the empty locale is problematic for >> guile 2.0.9 or our bootstrap environment. I just tried a patch and >> pushed to my wip-0.2.0. > > I added (at the last minute) the call to “setlocale” to normalize some > differences between Guile 2 and Guile 2.2 (I was getting test failures > without it). From reading Guile’s NEWS, version 2.2 started > initializing the locale automatically, so I “backported” that to Guile 2 > by calling “setlocale” with an empty string (as discussed in the > manual). Anyway, this is definitely my fault! Perhaps it should try > that and then fall back on “(setlocale LC_ALL "C")” if there is a > problem. I’ll figure it out before releasing. OK, thanks. >> I am less cheerful about the Shift/Reduce warnings; I am afraid they >> might break something somewhere during the bootstrap build. Any ideas >> why these surface at this time? I'll play some more with >> lalr.upstream.scm versions... > > My understanding is that these are spurious. That's what I was hoping...although > There is upstream commit > 92b64f9b3c02b0086a4aea7cbe7dc38376768150 which is not included in Guile > 2.0.9 but included in later versions (maybe starting with 2.0.10 – I > don’t recall). The commit message is “No more unexpected shift-reduce > conflicts with LR driver.” See <https://github.com/schemeway/lalr-scm>. > Since the newer versions are fine with the parser, and I have parsed > oodles of shell script using Guile 2.0.9, I think the these warnings are > just the result of a bug. :) ...if something in our bootstrap build is asserting that stderr is empty, they might break on these spurious warnings? Would it be a good idea to include this fixed lalr when the guile version is too old? Note that in the bootstrap build, I am using the `guile-build-system' (no sh or make yet when bootstrapping our first gash :-). > -- Tim > > (define gash-boot Ah, nice; thanks. Greetings, janneke -- Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Wed, 11 Dec 2019 18:26:02 GMT) Full text and rfc822 format available.Message #42 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Jan Nieuwenhuizen <janneke <at> gnu.org> To: Ludovic Courtès <ludo <at> gnu.org> Cc: Timothy Sample <samplet <at> ngyro.com>, 38390 <at> debbugs.gnu.org Subject: Re: [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap Date: Wed, 11 Dec 2019 19:25:01 +0100
Jan Nieuwenhuizen writes:
Hi!
> We will be working on a rewrite of wip-bootstrap to have it use Gash
> wip-0.2.0+ and include a number of cleanups.
I have just hard-reset wip-bootstrap for the next iteration!
> Here is my current TODO list
>
> * base bootstrap on Gash wip-0.20.0 (plus janneke's 2 patches)
Done. I just built `hello', so Gash 0.2.0 here we come (afaic).
> * remove %bootstrap-gash (with gash core utils) from bootstrap seed
Done; thanks to Ludo's insights about %boostrap-guile+guild, we were
able to do this. The `gash-boot' and `gash-core-utils-boot' packages no
longer appear in shells.scm; they are built during bootstrap using the
guile-build-system. I currently add lalr.upstream as an extra origin
to gash core utils from
--8<---------------cut here---------------start------------->8---
"http://git.savannah.gnu.org/cgit/guile.git/plain/module/system/base/lalr.upstream.scm?h=v2.0.9"
--8<---------------cut here---------------end--------------->8---
> * look at possibility/cost to avoid updating the mescc-tools and mes
> bootstrap binaries
This proved possible (dare I say feasible?). What was needed is
- allow mescc (0.21+) to work with old mescc-tools 0.5.2
- add %bootstrap-mes-rewired, to remove MesCC from mes-0.19 and
enable it to run 0.21+ MesCC
%bootstrap-mes-rewired uses this hack
--8<---------------cut here---------------start------------->8---
(add-after 'unpack 'patch-%moduledir
(lambda _
(copy-file "module/mescc.scm" "module/mescc.scm.orig")
(substitute* "module/mescc.scm"
(("^ \\(mes-use-module \\(mescc mescc\\)" all)
(string-append "
;; MesCC from mes-0.21
(let* ((self (car (command-line)))
(prefix (dirname (dirname self))))
(set! %moduledir (string-append prefix \"/mes/module/\"))
(setenv \"%numbered_arch\" \"true\"))
;; A fixed map, from mes-0.21
(define (map f h . t)
(if (or (null? h)
(and (pair? t) (null? (car t)))
(and (pair? t) (pair? (cdr t)) (null? (cadr t)))) '()
(if (null? t) (cons (f (car h)) (map f (cdr h)))
(if (null? (cdr t))
(cons (f (car h) (caar t)) (map f (cdr h) (cdar t)))
(if (null? (cddr t))
(cons (f (car h) (caar t) (caadr t)) (map f (cdr h) (cdar t) (cdadr t)))
(if (null? (cdddr t))
(cons (f (car h) (caar t) (caadr t) (car (caddr t))) (map f (cdr h) (cdar t) (cdadr t) (cdr (caddr t))))
(error 'unsupported (cons* 'map-5: f h t))) )))))
" all)))
#t))
--8<---------------cut here---------------end--------------->8---
...not particularly nice/clean/auditable; but "it works". WDYT?
On a related note, should mescc 0.21 include some kind of `hook' make
this kind of change easier to make?
This snippet could also be pushed "upstream", to mes-0.21+...but meh...
> * remove any generated (gitlab/github) tarballs
Done (but please check!).
> * look into awkward combined bash+gash dependency of glibc-mesboot0
Haven't addressed this. I quickly looked with Ludo at this, not really
into it though. WYDT?
> * add some %bootX-input stages, at least when reached gcc-mesboot1
Done. Numbering of bootX, mesbootX could possibly made to make more
sense. However, I also would like to get rid of the whole 2.95 story
some time soon and then many things change again. I could do with some
help/inspiration here.
> * commit messages: Use "Use Gash instead of coretutils&co." rather than
> "Scheme-only bootstrap."
Done.
> * some smaller cleanups and nitpicks here and there
Removed "ed-1.4" again (using a revert commit, that we can drop).
I kept most earlier commits that add to the bootstrap seed and added
revert commits. If we like what we have, we can remove both the commits
that introduced these and their reverts.
We are really getting there! I would like to do a rewrite once Gash
0.2.0 is out. What to do about Gash Core Utils? I also plan to do a
rewrite once MES 0.22 is out.
Greetings,
janneke
--
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Sun, 15 Dec 2019 21:34:01 GMT) Full text and rfc822 format available.Message #45 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: Jan Nieuwenhuizen <janneke <at> gnu.org> Cc: Timothy Sample <samplet <at> ngyro.com>, 38390 <at> debbugs.gnu.org Subject: Re: [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap Date: Sun, 15 Dec 2019 22:33:47 +0100
[Message part 1 (text/plain, inline)]
Howdy! Jan Nieuwenhuizen <janneke <at> gnu.org> skribis: >> We will be working on a rewrite of wip-bootstrap to have it use Gash >> wip-0.2.0+ and include a number of cleanups. > > I have just hard-reset wip-bootstrap for the next iteration! Yay! >> Here is my current TODO list >> >> * base bootstrap on Gash wip-0.20.0 (plus janneke's 2 patches) > > Done. I just built `hello', so Gash 0.2.0 here we come (afaic). > >> * remove %bootstrap-gash (with gash core utils) from bootstrap seed > > Done; thanks to Ludo's insights about %boostrap-guile+guild, we were > able to do this. The `gash-boot' and `gash-core-utils-boot' packages no > longer appear in shells.scm; they are built during bootstrap using the > guile-build-system. I currently add lalr.upstream as an extra origin > to gash core utils from > > "http://git.savannah.gnu.org/cgit/guile.git/plain/module/system/base/lalr.upstream.scm?h=v2.0.9" Awesome. BTW, I’d suggest this for clarity:
[Message part 2 (text/x-patch, inline)]
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index 9e3cecc174..d4cf58a7eb 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -266,6 +266,7 @@
,(origin
(method url-fetch)
(uri (string-append "http://git.savannah.gnu.org/cgit/guile.git/plain/module/system/base/lalr.upstream.scm?h=v2.0.9"))
+ (file-name "lalr.upstream.scm")
(sha256
(base32
"0h7gyjj8nr2qrgzwma146s7l22scp8bbcqzdy9wqf12bgyhbw7d5"))))))
[Message part 3 (text/plain, inline)]
>> * look at possibility/cost to avoid updating the mescc-tools and mes
>> bootstrap binaries
>
> This proved possible (dare I say feasible?). What was needed is
>
> - allow mescc (0.21+) to work with old mescc-tools 0.5.2
> - add %bootstrap-mes-rewired, to remove MesCC from mes-0.19 and
> enable it to run 0.21+ MesCC
>
> %bootstrap-mes-rewired uses this hack
>
> (add-after 'unpack 'patch-%moduledir
> (lambda _
> (copy-file "module/mescc.scm" "module/mescc.scm.orig")
> (substitute* "module/mescc.scm"
> (("^ \\(mes-use-module \\(mescc mescc\\)" all)
> (string-append "
> ;; MesCC from mes-0.21
> (let* ((self (car (command-line)))
> (prefix (dirname (dirname self))))
> (set! %moduledir (string-append prefix \"/mes/module/\"))
> (setenv \"%numbered_arch\" \"true\"))
>
> ;; A fixed map, from mes-0.21
> (define (map f h . t)
> (if (or (null? h)
> (and (pair? t) (null? (car t)))
> (and (pair? t) (pair? (cdr t)) (null? (cadr t)))) '()
> (if (null? t) (cons (f (car h)) (map f (cdr h)))
> (if (null? (cdr t))
> (cons (f (car h) (caar t)) (map f (cdr h) (cdar t)))
> (if (null? (cddr t))
> (cons (f (car h) (caar t) (caadr t)) (map f (cdr h) (cdar t) (cdadr t)))
> (if (null? (cdddr t))
> (cons (f (car h) (caar t) (caadr t) (car (caddr t))) (map f (cdr h) (cdar t) (cdadr t) (cdr (caddr t))))
> (error 'unsupported (cons* 'map-5: f h t))) )))))
> " all)))
> #t))
>
> ...not particularly nice/clean/auditable; but "it works". WDYT?
‘caddr’, loooove it! ;-)
It seems to me that mescc.scm in 0.21 only use the two-argument ‘map’,
no? In that case I guess we could go with a two-argument, fixed-arity
version that would have fewer cdadrs caddrs and caadrs? Just sayin’.
:-)
> On a related note, should mescc 0.21 include some kind of `hook' make
> this kind of change easier to make?
Good question! During the summit, Vagrant (I think?) asked whether Mes
and MesCC should be separated. I think in this case it would have been
beneficial to have them distributed separately, no? It might be worth
looking at which parts change frequently to determine what to keep as
part of the ‘mes’ package itself.
Thoughts?
>> * remove any generated (gitlab/github) tarballs
>
> Done (but please check!).
LGTM!
>> * look into awkward combined bash+gash dependency of glibc-mesboot0
>
> Haven't addressed this. I quickly looked with Ludo at this, not really
> into it though. WYDT?
Hmm, dunno. I can take a look later.
>> * add some %bootX-input stages, at least when reached gcc-mesboot1
>
> Done. Numbering of bootX, mesbootX could possibly made to make more
> sense. However, I also would like to get rid of the whole 2.95 story
> some time soon and then many things change again. I could do with some
> help/inspiration here.
I think it’s good to have ‘%bootX-inputs’ for when we’re going to reuse
more or less the same input set several times, because it clarifies that
there’s a “plateau” of sorts, but I guess it’s not always appropriate
early on in the graph.
Another thing we discussed was the growth of the dependency graph:
--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix graph -e '(@@ (gnu packages commencement) coreutils-final)' | grep 'label =' | wc -l
177
$ guix graph -e '(@@ (gnu packages commencement) coreutils-final)' | grep 'label =' | wc -l
76
--8<---------------cut here---------------end--------------->8---
Clearly we’re adding way more nodes than we mean to.
For example, you can remove the call to ‘package-with-bootstrap-guile’
for ‘bash-mesboot’ (down to 153 nodes) and the one for
‘gcc-core-mesboot1’ (down to 121) and the one for ‘binutils-mesboot’
(down to 87), and I think at this point we’re done and the graph has a
lovely shape. :-)
It makes a noticeable difference from a performance viewpoint (see
<https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00350.html>.)
Also, you can leave out calls to ‘bootstrap-origin’ for origins without
a snippet and without patches (it’s purely stylistic though.)
> We are really getting there! I would like to do a rewrite once Gash
> 0.2.0 is out. What to do about Gash Core Utils? I also plan to do a
> rewrite once MES 0.22 is out.
I think we should probably wait for the Gash and Gash Core Utils
releases so we can refer to them directly. How does that sound to you,
Timothy?
Thanks!
Ludo’.
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Sun, 15 Dec 2019 22:40:02 GMT) Full text and rfc822 format available.Message #48 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Timothy Sample <samplet <at> ngyro.com> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 38390 <at> debbugs.gnu.org, Jan Nieuwenhuizen <janneke <at> gnu.org> Subject: Re: [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap Date: Sun, 15 Dec 2019 17:39:28 -0500
Hi Ludo, Ludovic Courtès <ludo <at> gnu.org> writes: > Jan Nieuwenhuizen <janneke <at> gnu.org> skribis: > >> We are really getting there! I would like to do a rewrite once Gash >> 0.2.0 is out. What to do about Gash Core Utils? I also plan to do a >> rewrite once MES 0.22 is out. > > I think we should probably wait for the Gash and Gash Core Utils > releases so we can refer to them directly. How does that sound to you, > Timothy? I’m planning on releasing Gash tonight, so that should be okay. :D For the utilities, it might take some time (especially since we are running up against the holidays). My current plan is to do it as quickly as possible, meaning that I will focus on the bare minimum for a first release. Even then, it won’t be speedy: besides cleaning up what’s there and setting up the build scripts, I will have to coordinate with the folks at Savannah to get another Git repo. Even if it takes a few weeks for a release, I think it makes sense to wait. This whole project has taken years! What’s a couple of weeks? :) -- Tim
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Sun, 15 Dec 2019 22:47:02 GMT) Full text and rfc822 format available.Message #51 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Brett Gilio <brettg <at> posteo.net> To: Timothy Sample <samplet <at> ngyro.com> Cc: Ludovic Courtès <ludo <at> gnu.org>, 38390 <at> debbugs.gnu.org, Jan Nieuwenhuizen <janneke <at> gnu.org> Subject: Re: [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap Date: Sun, 15 Dec 2019 16:45:44 -0600
Timothy Sample <samplet <at> ngyro.com> writes: > > I’m planning on releasing Gash tonight, so that should be okay. :D Yes! -- Brett M. Gilio Homepage -- https://scm.pw/ GNU Guix -- https://guix.gnu.org/
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Mon, 16 Dec 2019 06:36:01 GMT) Full text and rfc822 format available.Message #54 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Jan Nieuwenhuizen <janneke <at> gnu.org> To: Timothy Sample <samplet <at> ngyro.com> Cc: Ludovic Courtès <ludo <at> gnu.org>, 38390 <at> debbugs.gnu.org Subject: Re: [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap Date: Mon, 16 Dec 2019 07:34:50 +0100
Timothy Sample writes: Hi All, >> Jan Nieuwenhuizen <janneke <at> gnu.org> skribis: >> >>> We are really getting there! I would like to do a rewrite once Gash >>> 0.2.0 is out. What to do about Gash Core Utils? I also plan to do a >>> rewrite once MES 0.22 is out. >> >> I think we should probably wait for the Gash and Gash Core Utils >> releases so we can refer to them directly. How does that sound to you, >> Timothy? > > I’m planning on releasing Gash tonight, so that should be okay. :D \o/ > For the utilities, it might take some time (especially since we are > running up against the holidays). My current plan is to do it as > quickly as possible, meaning that I will focus on the bare minimum for a > first release. Even then, it won’t be speedy: besides cleaning up > what’s there and setting up the build scripts, I will have to coordinate > with the folks at Savannah to get another Git repo. > > Even if it takes a few weeks for a release, I think it makes sense to > wait. This whole project has taken years! What’s a couple of weeks? > :) I agree; no need to hurry, there is time. Greetings, janneke -- Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Mon, 16 Dec 2019 19:29:01 GMT) Full text and rfc822 format available.Message #57 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Jan Nieuwenhuizen <janneke <at> gnu.org> To: Ludovic Courtès <ludo <at> gnu.org> Cc: Timothy Sample <samplet <at> ngyro.com>, 38390 <at> debbugs.gnu.org Subject: Re: [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap Date: Mon, 16 Dec 2019 20:28:02 +0100
Ludovic Courtès writes: Hi! >> I have just hard-reset wip-bootstrap for the next iteration! > > Yay! and I did it again. > Awesome. > > BTW, I’d suggest this for clarity: > + (file-name "lalr.upstream.scm") Ah, yes. Added. >>> * look at possibility/cost to avoid updating the mescc-tools and mes >>> bootstrap binaries >> >> This proved possible (dare I say feasible?). What was needed is >> >> - allow mescc (0.21+) to work with old mescc-tools 0.5.2 >> - add %bootstrap-mes-rewired, to remove MesCC from mes-0.19 and >> enable it to run 0.21+ MesCC >> >> %bootstrap-mes-rewired uses this hack >> ;; MesCC from mes-0.21 >> (set! %moduledir (string-append prefix \"/mes/module/\")) >> >> ;; A fixed map, from mes-0.21 >> (define (map f h . t) > > ‘caddr’, loooove it! ;-) > > It seems to me that mescc.scm in 0.21 only use the two-argument ‘map’, > no? In that case I guess we could go with a two-argument, fixed-arity > version that would have fewer cdadrs caddrs and caadrs? Just sayin’. > :-) Ah yes...well almost. MesCC uses map3; so I cut only map4. >> On a related note, should mescc 0.21 include some kind of `hook' make >> this kind of change easier to make? > > Good question! During the summit, Vagrant (I think?) asked whether Mes > and MesCC should be separated. I think in this case it would have been > beneficial to have them distributed separately, no? It might be worth > looking at which parts change frequently to determine what to keep as > part of the ‘mes’ package itself. > > Thoughts? I've been "struggling" with this question a bit myself. In this particular instance it would not have helped much, since map was broken and I would not have wanted to add a fix for that in mescc. It would have helped switching to the newer mescc. Keeping them in one archive for now is a bit less work for me I think; it saves me managing another dependency. Possibly until mes can boot guile modules. Until mes can do that, mes needs to come with a "shadow *.mes" tree for module inclusion, like it has for Nyacc too. That's less than great, but works... I am open to other perspectives, though. >>> * look into awkward combined bash+gash dependency of glibc-mesboot0 >> >> Haven't addressed this. I quickly looked with Ludo at this, not really >> into it though. WYDT? > > Hmm, dunno. I can take a look later. Okay, great. This issue still remains. I will try to create a bug report for Gash, I think Gash hangs while running configure, while bash-mesboot* have trouble running make-syscalls.sh correctly. I just realise that the mixture of bash/gawk/sed here is possibly one of the things that was replaced by Python. Bootstrapping-wise that seemed like a very bad idea, but I may be starting to see the sanity in such a choice. It would be great if it were Guile, though, or else if Guile could run this Python. > Another thing we discussed was the growth of the dependency graph: > > $ ./pre-inst-env guix graph -e '(@@ (gnu packages commencement) coreutils-final)' | grep 'label =' | wc -l > 177 > $ guix graph -e '(@@ (gnu packages commencement) coreutils-final)' | grep 'label =' | wc -l > 76 > > Clearly we’re adding way more nodes than we mean to. > > For example, you can remove the call to ‘package-with-bootstrap-guile’ > for ‘bash-mesboot’ (down to 153 nodes) and the one for > ‘gcc-core-mesboot1’ (down to 121) and the one for ‘binutils-mesboot’ > (down to 87), and I think at this point we’re done and the graph has a > lovely shape. :-) Oh, thank you! Incorporated those changes and verified I got the 87 nodes too. > Also, you can leave out calls to ‘bootstrap-origin’ for origins without > a snippet and without patches (it’s purely stylistic though.) Ah, I didn't realise that. Removed most, if not all of them. > I think we should probably wait for the Gash and Gash Core Utils > releases so we can refer to them directly. How does that sound to you, > Timothy? Incoroprated Gash 0.2.0! Greetings, janneke -- Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Wed, 18 Dec 2019 22:56:02 GMT) Full text and rfc822 format available.Message #60 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Jan Nieuwenhuizen <janneke <at> gnu.org> To: Ludovic Courtès <ludo <at> gnu.org> Cc: Timothy Sample <samplet <at> ngyro.com>, 38390 <at> debbugs.gnu.org Subject: Re: [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap Date: Wed, 18 Dec 2019 23:55:13 +0100
Jan Nieuwenhuizen writes:
Hi,
A new step forward.
>>>> * look into awkward combined bash+gash dependency of glibc-mesboot0
>>>
>>> Haven't addressed this. I quickly looked with Ludo at this, not really
>>> into it though. WYDT?
>>
>> Hmm, dunno. I can take a look later.
>
> Okay, great. This issue still remains. I will try to create a bug
> report for Gash, I think Gash hangs while running configure, while
> bash-mesboot* have trouble running make-syscalls.sh correctly.
Good news. bash-mesboot0 now compiles with either gash+gash-core-utils,
or with bash-mesboot0.
Gash' "test -L FILE" used to crash on non-existing files, not sure why
that made configure hang; but that's how I found and fixed it.
The problem with bash-mesboot0 turned out to be a Mes C Library problem,
related to buffered reads. Buffered reads were introduced when working
on the Hurd.
Not clearing the read buffer on lseek, when lseek is not allowed (bash
uses the same: lseek (FD, 0, SEEK_CUR) to find out if it may seek),
fixes the problem. That took me a couple of days to find, but very
happy
--8<---------------cut here---------------start------------->8---
diff --git a/lib/linux/lseek.c b/lib/linux/lseek.c
index 94f2f9f7a..f71af59f5 100644
--- a/lib/linux/lseek.c
+++ b/lib/linux/lseek.c
@@ -24,9 +24,21 @@
#include <stdio.h>
#include <sys/types.h>
+#if !__MESC__ /* FIXME: We want bin/mes-mescc's x86-linux sha256sum to stay the same. */
+off_t
+_lseek (int filedes, off_t offset, int whence)
+{
+ return _sys_call3 (SYS_lseek, (int) filedes, (long) offset, (int) whence);
+}
+#endif
+
off_t
lseek (int filedes, off_t offset, int whence)
{
+#if !__MESC__ /* FIXME: We want bin/mes-mescc's x86-linux sha256sum to stay the same. */
+ if (_lseek (filedes, 0, SEEK_CUR) == -1)
+ return -1;
+#endif
size_t skip = __buffered_read_clear (filedes);
if (whence == SEEK_CUR)
offset -= skip;
--8<---------------cut here---------------end--------------->8---
Greetings,
janneke
--
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Thu, 19 Dec 2019 11:10:02 GMT) Full text and rfc822 format available.Message #63 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: Jan Nieuwenhuizen <janneke <at> gnu.org> Cc: Timothy Sample <samplet <at> ngyro.com>, 38390 <at> debbugs.gnu.org Subject: Re: [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap Date: Thu, 19 Dec 2019 12:08:54 +0100
Hi! Jan Nieuwenhuizen <janneke <at> gnu.org> skribis: > Good news. bash-mesboot0 now compiles with either gash+gash-core-utils, > or with bash-mesboot0. > > Gash' "test -L FILE" used to crash on non-existing files, not sure why > that made configure hang; but that's how I found and fixed it. > > The problem with bash-mesboot0 turned out to be a Mes C Library problem, > related to buffered reads. Buffered reads were introduced when working > on the Hurd. > > Not clearing the read buffer on lseek, when lseek is not allowed (bash > uses the same: lseek (FD, 0, SEEK_CUR) to find out if it may seek), > fixes the problem. That took me a couple of days to find, but very > happy Woow, wild! Great that you found out! Thank you, Ludo’.
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Mon, 03 Feb 2020 17:38:02 GMT) Full text and rfc822 format available.Message #66 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Timothy Sample <samplet <at> ngyro.com> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 38390 <at> debbugs.gnu.org, Jan Nieuwenhuizen <janneke <at> gnu.org> Subject: [bug #38390] Building bootstrap Gash and Gash-Utils Date: Mon, 03 Feb 2020 12:37:04 -0500
[Message part 1 (text/plain, inline)]
Hi Ludo, (CC’ing Jan and bug#38390.) We’re nearing a release for Gash-Utils, and while working on it I made some changes to how the bootstrap Gash and Gash-Utils are built (on the wip-bootstrap branch.) Jan suggested that we get your opinion on the changes, as you are behind the current '%bootstrap-guile+guild' approach. The very short story is that I found that the Scheme GZip code is being maintained and works out-of-the-box on Guile 2.0.9 [1]. This made me unsure about copying the code into Gash-Utils when maybe we could just use it as a dependency. Then, I realized that the library included a simple Tar reader, and wondered how simple a program could be that could handle 'tar xvf gash.tar.gz'. It turns out pretty simple! So I put the program and all its dependencies in an a-list with a little loop that writes them to disk, and made a self-extracting Scheme script that can unpack compressed tarballs [2]. [1] https://github.com/weinholt/compression [2] https://git.ngyro.com/bootar/ The other thing is that I always intended for Gash and Gash-Utils to be built with a loop calling “compile-file”. This avoids the need for “guild” which in turn avoids “bash” (AIUI). These patches update Gash-Utils, replace the binary “tar” with my self-extracting Scheme implementation, and replace “guild” with “compile-file”. I think this simplifies the bootstrap processes, and I really like getting rid of the references to “tar”, “bash”, and “xz” (even though they are needed for the bootstrap Guile, it feels nice to quarantine them there). WDYT? -- Tim
[0001-Rename-gash-core-utils-to-gash-utils.patch (text/x-patch, attachment)]
[0002-Simplify-bootstrap-Gash-and-Gash-Utils.patch (text/x-patch, attachment)]
[0003-Remove-bootstrap-guile-guild.patch (text/x-patch, attachment)]
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Wed, 05 Feb 2020 09:00:02 GMT) Full text and rfc822 format available.Message #69 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: Timothy Sample <samplet <at> ngyro.com> Cc: 38390 <at> debbugs.gnu.org, Jan Nieuwenhuizen <janneke <at> gnu.org> Subject: Re: [bug #38390] Building bootstrap Gash and Gash-Utils Date: Wed, 05 Feb 2020 09:58:50 +0100
Hello Timothy! Timothy Sample <samplet <at> ngyro.com> skribis: > We’re nearing a release for Gash-Utils, and while working on it I made > some changes to how the bootstrap Gash and Gash-Utils are built (on the > wip-bootstrap branch.) Jan suggested that we get your opinion on the > changes, as you are behind the current '%bootstrap-guile+guild' > approach. Thanks for reaching out to me! > The very short story is that I found that the Scheme GZip code is being > maintained and works out-of-the-box on Guile 2.0.9 [1]. This made me > unsure about copying the code into Gash-Utils when maybe we could just > use it as a dependency. Then, I realized that the library included a > simple Tar reader, and wondered how simple a program could be that could > handle 'tar xvf gash.tar.gz'. It turns out pretty simple! So I put the > program and all its dependencies in an a-list with a little loop that > writes them to disk, and made a self-extracting Scheme script that can > unpack compressed tarballs [2]. Woow, that is very nice! So all of a sudden there’s an extra bunch of binary seeds we can get rid of, woohoo! I didn’t expect that even bzip2 and xz would be implemented. > [2] https://git.ngyro.com/bootar/ Clean, short, and elegant; brilliant! > The other thing is that I always intended for Gash and Gash-Utils to be > built with a loop calling “compile-file”. This avoids the need for > “guild” which in turn avoids “bash” (AIUI). > > These patches update Gash-Utils, replace the binary “tar” with my > self-extracting Scheme implementation, and replace “guild” with > “compile-file”. I think this simplifies the bootstrap processes, and I > really like getting rid of the references to “tar”, “bash”, and “xz” > (even though they are needed for the bootstrap Guile, it feels nice to > quarantine them there). > > WDYT? I think it’s perfect. One comment that can be addressed later: > From 2cec50928a4ff67df363322d2adfb6aaa5aedc83 Mon Sep 17 00:00:00 2001 > From: Timothy Sample <samplet <at> ngyro.com> > Date: Mon, 3 Feb 2020 10:51:07 -0500 > Subject: [PATCH 2/3] Simplify bootstrap Gash and Gash-Utils. > > This change does three things. First Gash-Utils is updated to > 0.1.0-preview. Then, the bootstrap Gash and Gash-Utils packages are > arranged to be built without using 'guild'. Finally, instead of > using a binary 'tar' via 'bootstrap-executable' to extract Gash and > Gash-Utils, a self-extracting Scheme implementation of 'tar' and > 'gzip' is used instead. [...] > +(define (make-bootstrap-phases version scripts modules) > + "Create a form that modifies the standard GNU build phases so that > +they build simple Guile programs using only the bootstrap Guile. The > +'.in' files in the directory MODULES are configured with VERSION, the > +'.in' files in the directory SCRIPTS are configured with the bootstrap > +Guile and its module and object directories, and the Scheme files in the > +directory MODULES are compiled and installed." > + `(modify-phases %standard-phases > + (replace 'configure Should this be factorized out in a (guix build gnu-bootstrap) module or similar? That would keep build-side code separate and would avoid making ‘commencement.scm’ bigger. I guess the only thing that remains to be done is changing the temporary URLs to the self-extracting script & co., right? Thanks a lot! Ludo’.
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Wed, 05 Feb 2020 14:34:02 GMT) Full text and rfc822 format available.Message #72 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Timothy Sample <samplet <at> ngyro.com> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 38390 <at> debbugs.gnu.org, Jan Nieuwenhuizen <janneke <at> gnu.org> Subject: Re: [bug #38390] Building bootstrap Gash and Gash-Utils Date: Wed, 05 Feb 2020 09:32:59 -0500
Hello, Ludovic Courtès <ludo <at> gnu.org> writes: > Timothy Sample <samplet <at> ngyro.com> skribis: > > [...] > >> So I put the program and all its dependencies in an a-list with a >> little loop that writes them to disk, and made a self-extracting >> Scheme script that can unpack compressed tarballs [2]. > > Woow, that is very nice! So all of a sudden there’s an extra bunch of > binary seeds we can get rid of, woohoo! I didn’t expect that even bzip2 > and xz would be implemented. I don’t think we could get rid of any binaries just yet. We need Guile to run Bootar and we can’t get Guile without the statically linked “tar”, “xz”, “mkdir”, and “bash”. This just removes some references to them. Although, it occurred to me that we could get something like Bootar (perhaps further simplified) to run on Mes, in which case we could use a statically linked Mes to unpack and wrap Guile. That would let us get rid of “%bootstrap-executables”. (Note however that I tried running Bootar in Mes for fun, and the extractor script – once it was simplified – caused a segfault.) BZip2 and XZ just barely work, by the way. I implemented BZip2, but I skipped over all the CRC checking. XZ has a bug when called with input from stdin, which is how Gash-Utils tries to call it. >> [2] https://git.ngyro.com/bootar/ > > Clean, short, and elegant; brilliant! Thanks! >> [...] >> >> WDYT? > > I think it’s perfect. \o/ > One comment that can be addressed later: > >> From 2cec50928a4ff67df363322d2adfb6aaa5aedc83 Mon Sep 17 00:00:00 2001 >> From: Timothy Sample <samplet <at> ngyro.com> >> Date: Mon, 3 Feb 2020 10:51:07 -0500 >> Subject: [PATCH 2/3] Simplify bootstrap Gash and Gash-Utils. >> >> This change does three things. First Gash-Utils is updated to >> 0.1.0-preview. Then, the bootstrap Gash and Gash-Utils packages are >> arranged to be built without using 'guild'. Finally, instead of >> using a binary 'tar' via 'bootstrap-executable' to extract Gash and >> Gash-Utils, a self-extracting Scheme implementation of 'tar' and >> 'gzip' is used instead. > > [...] > >> +(define (make-bootstrap-phases version scripts modules) >> + "Create a form that modifies the standard GNU build phases so that >> +they build simple Guile programs using only the bootstrap Guile. The >> +'.in' files in the directory MODULES are configured with VERSION, the >> +'.in' files in the directory SCRIPTS are configured with the bootstrap >> +Guile and its module and object directories, and the Scheme files in the >> +directory MODULES are compiled and installed." >> + `(modify-phases %standard-phases >> + (replace 'configure > > Should this be factorized out in a (guix build gnu-bootstrap) module or > similar? That would keep build-side code separate and would avoid > making ‘commencement.scm’ bigger. I would be happy to do that. It’s nice having everything in one place, but having a bootstrap build system would certainly make the packages clearer. I suppose it could also get rid of the implicit inputs for us and use “%bootstrap-guile” by default. > I guess the only thing that remains to be done is changing the temporary > URLs to the self-extracting script & co., right? Yup. I’ll release both packages soon. > Thanks a lot! My pleasure! -- Tim
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Wed, 05 Feb 2020 21:35:01 GMT) Full text and rfc822 format available.Message #75 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: Timothy Sample <samplet <at> ngyro.com> Cc: 38390 <at> debbugs.gnu.org, Jan Nieuwenhuizen <janneke <at> gnu.org> Subject: Re: [bug #38390] Building bootstrap Gash and Gash-Utils Date: Wed, 05 Feb 2020 22:33:53 +0100
Hello! Timothy Sample <samplet <at> ngyro.com> skribis: > Ludovic Courtès <ludo <at> gnu.org> writes: [...] >> Woow, that is very nice! So all of a sudden there’s an extra bunch of >> binary seeds we can get rid of, woohoo! I didn’t expect that even bzip2 >> and xz would be implemented. > > I don’t think we could get rid of any binaries just yet. We need Guile > to run Bootar and we can’t get Guile without the statically linked > “tar”, “xz”, “mkdir”, and “bash”. This just removes some references to > them. Although, it occurred to me that we could get something like > Bootar (perhaps further simplified) to run on Mes, in which case we > could use a statically linked Mes to unpack and wrap Guile. That would > let us get rid of “%bootstrap-executables”. (Note however that I tried > running Bootar in Mes for fun, and the extractor script – once it was > simplified – caused a segfault.) Oh cool. Being able to run Guile code on Mes sounds like a worthy goal longer-term anyway, so hopefully we’ll get there! > BZip2 and XZ just barely work, by the way. I implemented BZip2, but I > skipped over all the CRC checking. XZ has a bug when called with input > from stdin, which is how Gash-Utils tries to call it. Heh, not so bad. >>> +(define (make-bootstrap-phases version scripts modules) >>> + "Create a form that modifies the standard GNU build phases so that >>> +they build simple Guile programs using only the bootstrap Guile. The >>> +'.in' files in the directory MODULES are configured with VERSION, the >>> +'.in' files in the directory SCRIPTS are configured with the bootstrap >>> +Guile and its module and object directories, and the Scheme files in the >>> +directory MODULES are compiled and installed." >>> + `(modify-phases %standard-phases >>> + (replace 'configure >> >> Should this be factorized out in a (guix build gnu-bootstrap) module or >> similar? That would keep build-side code separate and would avoid >> making ‘commencement.scm’ bigger. > > I would be happy to do that. It’s nice having everything in one place, > but having a bootstrap build system would certainly make the packages > clearer. I suppose it could also get rid of the implicit inputs for us > and use “%bootstrap-guile” by default. I doesn’t have to be a full-blown build system, because there might be as much boilerplate as actual code, but simply moving the definitions of phases in a separate file could help keep commencement.scm clear. >> I guess the only thing that remains to be done is changing the temporary >> URLs to the self-extracting script & co., right? > > Yup. I’ll release both packages soon. Great, thank you! Ludo’.
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Thu, 06 Feb 2020 22:59:01 GMT) Full text and rfc822 format available.Message #78 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Jan Nieuwenhuizen <janneke <at> gnu.org> To: Ludovic Courtès <ludo <at> gnu.org> Cc: Timothy Sample <samplet <at> ngyro.com>, 38390 <at> debbugs.gnu.org Subject: Re: [bug#38390] [bug #38390] Building bootstrap Gash and Gash-Utils Date: Thu, 06 Feb 2020 23:58:28 +0100
Ludovic Courtès writes: Hello! I have rebased wip-bootstrap on core-updates that include your commencements updates. With your explanations on irc and studying your patch, I was able to keep using your cleanups and do without the most ugly 'setenv stages. So, wip-bootstrap on savannah is reset once again. > Timothy Sample <samplet <at> ngyro.com> skribis: > >> Ludovic Courtès <ludo <at> gnu.org> writes: >> I would be happy to do that. It’s nice having everything in one place, >> but having a bootstrap build system would certainly make the packages >> clearer. I suppose it could also get rid of the implicit inputs for us >> and use “%bootstrap-guile” by default. > > I doesn’t have to be a full-blown build system, because there might be > as much boilerplate as actual code, but simply moving the definitions of > phases in a separate file could help keep commencement.scm clear. > >>> I guess the only thing that remains to be done is changing the temporary >>> URLs to the self-extracting script & co., right? >> >> Yup. I’ll release both packages soon. > > Great, thank you! Yes, that's great! @Timothy: I haven't included your previous patches on `wip-bootstrap', feel free to push them to wip-bootstrap. We are getting real close to merging this, I think. Greetings, janneke -- Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Fri, 07 Feb 2020 11:01:02 GMT) Full text and rfc822 format available.Message #81 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: Jan Nieuwenhuizen <janneke <at> gnu.org> Cc: Timothy Sample <samplet <at> ngyro.com>, 38390 <at> debbugs.gnu.org Subject: Re: [bug#38390] [bug #38390] Building bootstrap Gash and Gash-Utils Date: Fri, 07 Feb 2020 12:00:08 +0100
Hi, Jan Nieuwenhuizen <janneke <at> gnu.org> skribis: > I have rebased wip-bootstrap on core-updates that include your > commencements updates. > > With your explanations on irc and studying your patch, I was able to > keep using your cleanups and do without the most ugly 'setenv stages. > > So, wip-bootstrap on savannah is reset once again. Great, thanks for taking the time to rebase and adjust the code, and apologies for all the trouble! (Actually making this change to commencement.scm wasn’t on my agenda, it’s one of the things that pop up and give you a good excuse to avoid more boring stuff, I suppose…) > @Timothy: I haven't included your previous patches on `wip-bootstrap', > feel free to push them to wip-bootstrap. > > We are getting real close to merging this, I think. This is exciting. Let’s synchronize with Marius once the branch has stabilized to see if this can go in ‘core-updates’ this time. Thanks, Ludo’.
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Sat, 08 Feb 2020 17:34:02 GMT) Full text and rfc822 format available.Message #84 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Timothy Sample <samplet <at> ngyro.com> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 38390 <at> debbugs.gnu.org, Jan Nieuwenhuizen <janneke <at> gnu.org> Subject: Re: [bug#38390] [bug #38390] Building bootstrap Gash and Gash-Utils Date: Sat, 08 Feb 2020 12:33:12 -0500
Hello, Ludovic Courtès <ludo <at> gnu.org> writes: > Jan Nieuwenhuizen <janneke <at> gnu.org> skribis: > >> @Timothy: I haven't included your previous patches on `wip-bootstrap', >> feel free to push them to wip-bootstrap. >> >> We are getting real close to merging this, I think. > > This is exciting. Let’s synchronize with Marius once the branch has > stabilized to see if this can go in ‘core-updates’ this time. Indeed! I just pushed five commits to “wip-bootstrap”. They are a little different from the patches I sent. For one, I followed Ludo’s advice and added a “gnu-bootstrap” module for the build code. That means I got rid of “make-bootstrap-phases” and adjusted the packages accordingly. It’s a little janky, but it does clear up “commencement.scm”. Bootar is released and saw some cosmetic improvements. Notably, it disables “escape-newlines” and uses “pretty-print”, making the SES file easy to read for humans. The SES file is still hosted on my server, but at a stable URL. Is it worrisome that it’s on my server? I put a mirror on Gitlab <https://gitlab.com/samplet/bootar/-/tags/v1>, but the URL to the actual file is kinda ugly. Thoughts? Gash-Utils is released! The Git repo and tarball are on Savannah. I updated how the base package builds a little bit, and fiddled with the home-page, synopsis, and description. The bootstrap version was installing a useless “template” binary, which I fixed. I noticed a little issue with “%boot-mesboot1-inputs”, so I fixed it and made sure that “bootar” does not get propagated past that point. I have not tested the full bootstrap yet, but I did test “hello-mesboot” on basically this same code, and it was fine. Since almost nothing substantial has been changed, it should be OK, but you never know until you try! I’ll build the full thing as fast as my little computer can. :) -- Tim
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Sat, 08 Feb 2020 22:34:02 GMT) Full text and rfc822 format available.Message #87 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Jan Nieuwenhuizen <janneke <at> gnu.org> To: Timothy Sample <samplet <at> ngyro.com> Cc: Ludovic Courtès <ludo <at> gnu.org>, 38390 <at> debbugs.gnu.org Subject: Re: [bug#38390] [bug #38390] Building bootstrap Gash and Gash-Utils Date: Sat, 08 Feb 2020 23:32:59 +0100
Timothy Sample writes: Hello, > Ludovic Courtès <ludo <at> gnu.org> writes: > >> Jan Nieuwenhuizen <janneke <at> gnu.org> skribis: >> >>> @Timothy: I haven't included your previous patches on `wip-bootstrap', >>> feel free to push them to wip-bootstrap. >>> >>> We are getting real close to merging this, I think. >> >> This is exciting. Let’s synchronize with Marius once the branch has >> stabilized to see if this can go in ‘core-updates’ this time. > > Indeed! > > I just pushed five commits to “wip-bootstrap”. They are a little > different from the patches I sent. Very nice. > For one, I followed Ludo’s advice and added a “gnu-bootstrap” module for > the build code. That means I got rid of “make-bootstrap-phases” and > adjusted the packages accordingly. It’s a little janky, but it does > clear up “commencement.scm”. I like it! > Bootar is released and saw some cosmetic improvements. Notably, it > disables “escape-newlines” and uses “pretty-print”, making the SES file > easy to read for humans. The SES file is still hosted on my server, but > at a stable URL. Is it worrisome that it’s on my server? I put a > mirror on Gitlab <https://gitlab.com/samplet/bootar/-/tags/v1>, but the > URL to the actual file is kinda ugly. Thoughts? > > Gash-Utils is released! The Git repo and tarball are on Savannah. I > updated how the base package builds a little bit, and fiddled with the > home-page, synopsis, and description. The bootstrap version was > installing a useless “template” binary, which I fixed. Oh, congrats! > I noticed a little issue with “%boot-mesboot1-inputs”, so I fixed it and > made sure that “bootar” does not get propagated past that point. > > I have not tested the full bootstrap yet, but I did test “hello-mesboot” > on basically this same code, and it was fine. Since almost nothing > substantial has been changed, it should be OK, but you never know until > you try! I’ll build the full thing as fast as my little computer can. > :) I found that the new file-boot0 5.38 does not build with the new bzip feature; I added a squash! commit to disable that. janneke -- Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Mon, 10 Feb 2020 02:24:02 GMT) Full text and rfc822 format available.Message #90 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Timothy Sample <samplet <at> ngyro.com> To: Jan Nieuwenhuizen <janneke <at> gnu.org> Cc: 38390 <at> debbugs.gnu.org Subject: Re: [bug#38390] [bug #38390] Building bootstrap Gash and Gash-Utils Date: Sun, 09 Feb 2020 21:23:21 -0500
Hi Jan, Jan Nieuwenhuizen <janneke <at> gnu.org> writes: > I found that the new file-boot0 5.38 does not build with the new bzip > feature; I added a squash! commit to disable that. I managed to build GNU Hello, but I had to disable “bzlib” for the “file” package in “%final-inputs” as well. I assume that’s a problem. You may have already noticed, but I thought I would mention it just in case. -- Tim
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Tue, 11 Feb 2020 13:57:02 GMT) Full text and rfc822 format available.Message #93 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: Timothy Sample <samplet <at> ngyro.com> Cc: 38390 <at> debbugs.gnu.org, Jan Nieuwenhuizen <janneke <at> gnu.org> Subject: Re: [bug#38390] [bug #38390] Building bootstrap Gash and Gash-Utils Date: Tue, 11 Feb 2020 14:56:17 +0100
Hi Timothy, Timothy Sample <samplet <at> ngyro.com> skribis: > Ludovic Courtès <ludo <at> gnu.org> writes: > >> Jan Nieuwenhuizen <janneke <at> gnu.org> skribis: >> >>> @Timothy: I haven't included your previous patches on `wip-bootstrap', >>> feel free to push them to wip-bootstrap. >>> >>> We are getting real close to merging this, I think. >> >> This is exciting. Let’s synchronize with Marius once the branch has >> stabilized to see if this can go in ‘core-updates’ this time. > > Indeed! > > I just pushed five commits to “wip-bootstrap”. They are a little > different from the patches I sent. Awesome, thank you! > For one, I followed Ludo’s advice and added a “gnu-bootstrap” module for > the build code. That means I got rid of “make-bootstrap-phases” and > adjusted the packages accordingly. It’s a little janky, but it does > clear up “commencement.scm”. > > Bootar is released and saw some cosmetic improvements. Notably, it > disables “escape-newlines” and uses “pretty-print”, making the SES file > easy to read for humans. The SES file is still hosted on my server, but > at a stable URL. Is it worrisome that it’s on my server? I put a > mirror on Gitlab <https://gitlab.com/samplet/bootar/-/tags/v1>, but the > URL to the actual file is kinda ugly. Thoughts? We can host a copy at <https://ftp.gnu.org/gnu/guix/mirror>, which will be picked up by Software Heritage and archived for eternity. :-) Let’s do that when we merge the branch. > Gash-Utils is released! The Git repo and tarball are on Savannah. I > updated how the base package builds a little bit, and fiddled with the > home-page, synopsis, and description. The bootstrap version was > installing a useless “template” binary, which I fixed. > > I noticed a little issue with “%boot-mesboot1-inputs”, so I fixed it and > made sure that “bootar” does not get propagated past that point. > > I have not tested the full bootstrap yet, but I did test “hello-mesboot” > on basically this same code, and it was fine. Since almost nothing > substantial has been changed, it should be OK, but you never know until > you try! I’ll build the full thing as fast as my little computer can. > :) Thank you for all the great work! Ludo’.
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Thu, 13 Feb 2020 15:19:02 GMT) Full text and rfc822 format available.Message #96 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Jan Nieuwenhuizen <janneke <at> gnu.org> To: Marius Bakke <mbakke <at> fastmail.com> Cc: guix-devel <at> gnu.org, 38390 <at> debbugs.gnu.org Subject: Re: Starting 'core-updates'? Date: Thu, 13 Feb 2020 16:18:35 +0100
Marius Bakke writes: Hello Marius, > The 'core-updates' branch is starting to look pretty good, and I am > happy to report that it "works for me". :-) > > Some of the big changes include: > I suggest that we set a "freeze" date shortly after FOSDEM to start > integrating it. Are there other branches that should be included? > Maybe wip-bootstrap Definately maybe! I think that Timothy, Ludo and I have finally done what set out to do (see https://bugs.gnu.org/38390). I have squashed the remaining squash-commits and freshly rebased `wip-bootstrap' on core-updates, so I think that from our point of view we are ready for merge. WYDT? Greetings, janneke -- Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
guix-patches <at> gnu.org:bug#38390; Package guix-patches.
(Fri, 14 Feb 2020 15:19:02 GMT) Full text and rfc822 format available.Message #99 received at 38390 <at> debbugs.gnu.org (full text, mbox):
From: Marius Bakke <mbakke <at> fastmail.com> To: Jan Nieuwenhuizen <janneke <at> gnu.org> Cc: guix-devel <at> gnu.org, 38390 <at> debbugs.gnu.org Subject: Re: Starting 'core-updates'? Date: Fri, 14 Feb 2020 16:18:50 +0100
[Message part 1 (text/plain, inline)]
Jan Nieuwenhuizen <janneke <at> gnu.org> writes: > Marius Bakke writes: > > Hello Marius, > >> The 'core-updates' branch is starting to look pretty good, and I am >> happy to report that it "works for me". :-) >> >> Some of the big changes include: > >> I suggest that we set a "freeze" date shortly after FOSDEM to start >> integrating it. Are there other branches that should be included? > >> Maybe wip-bootstrap > > Definately maybe! I think that Timothy, Ludo and I have finally done > what set out to do (see https://bugs.gnu.org/38390). > > I have squashed the remaining squash-commits and freshly rebased > `wip-bootstrap' on core-updates, so I think that from our point of view > we are ready for merge. WYDT? Excellent, really looking forward to seeing this merged! Cutting the bootstrap seed down to ~60 MiB is nothing short of amazing. I think that with this branch merged as well as the glibc&binutils update from <https://issues.guix.gnu.org/issue/39456> we are ready to start the 'core-updates' branch. \o/ We still need to change the default Guile to 3.0. Any takers? :-)
[signature.asc (application/pgp-signature, inline)]
Jan Nieuwenhuizen <janneke <at> gnu.org>:Jan Nieuwenhuizen <janneke <at> gnu.org>:Message #104 received at 38390-done <at> debbugs.gnu.org (full text, mbox):
From: Jan Nieuwenhuizen <janneke <at> gnu.org> To: Marius Bakke <mbakke <at> fastmail.com> Cc: guix-devel <at> gnu.org, 38390-done <at> debbugs.gnu.org Subject: Re: [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap / Starting `core-updates' Date: Tue, 18 Feb 2020 07:25:03 +0100
Marius Bakke writes: > Jan Nieuwenhuizen <janneke <at> gnu.org> writes: > >> Marius Bakke writes: >> >> Hello Marius, >> >>> The 'core-updates' branch is starting to look pretty good, and I am >>> happy to report that it "works for me". :-) >>> >>> Some of the big changes include: >> >>> I suggest that we set a "freeze" date shortly after FOSDEM to start >>> integrating it. Are there other branches that should be included? >> >>> Maybe wip-bootstrap >> >> Definately maybe! I think that Timothy, Ludo and I have finally done >> what set out to do (see https://bugs.gnu.org/38390). >> >> I have squashed the remaining squash-commits and freshly rebased >> `wip-bootstrap' on core-updates, so I think that from our point of view >> we are ready for merge. WYDT? > > Excellent, really looking forward to seeing this merged! Cutting the > bootstrap seed down to ~60 MiB is nothing short of amazing. Thank you!! Pushed as e157ed72ec7b673b4204c84a7bf74f13afb44dc7 to core-updates. And a very big thank you to Ludo' and Timothy: let's keep pushing this bootstrapping thing forward! > I think that with this branch merged as well as the glibc&binutils > update from <https://issues.guix.gnu.org/issue/39456> we are ready to > start the 'core-updates' branch. \o/ \o/ Greetings, janneke -- Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Tue, 17 Mar 2020 11:24:05 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.