[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap

From: Jan Nieuwenhuizen
Subject: [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap
Date: Sun, 01 Dec 2019 18:21:05 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

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: object 
>> '/tmp/guix-build-acl-2.2.53.drv-0/acl-2.2.53/.libs/' 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 :-)

Jan Nieuwenhuizen <address@hidden> | GNU LilyPond
Freelance IT | Avatar®

reply via email to

[Prev in Thread] Current Thread [Next in Thread]