bug#39699: [core-updates] gash-boot0 fails on i686-linux

[Ludovic Courtès]

Hi!

Jan Nieuwenhuizen <address@hidden> skribis:

> Ludovic Courtès writes:
>
> Hi!
>
>> I can see two solutions:
>>
>>   1. Remove bzip2 support from bootar (it’s not actually needed, is it?).
>
> Ugly but easiest fix for me, see attached.
>
>>   2. Modify (compression bzip2) so that it errors out on first use
>>      rather than at load time.
>
> Or
>     3. Port bzip2 to to 32bit.

Indeed!

> I would prefer 3., with the fix going upstream.  This opens the path to
> really using bzip2 in the bootstrap.  2. could be a nice intermediate
> step, but I would not know how to do that nicely, as we fetch
> (compression bzip2) from upstream.  Timothy?

I don’t think we’ll introduce new uses of bzip2 on the bootstrap path.
So if it’s unnecessary today, it may remain unnecessary in the
foreseeable future.

> From 06bc492cdc1f476f0caa558546290ceafde357b1 Mon Sep 17 00:00:00 2001
> From: Jan Nieuwenhuizen <address@hidden>
> Date: Fri, 21 Feb 2020 07:46:16 +0100
> Subject: [PATCH] gnu: commencement: bootar: Build fix for i686-linux.
>
> See #39699

Nitpick: “Fixes <https://bugs.gnu.org/39699>.”  :-)

> * gnu/packages/commencement.scm (bootar)[i686-linux]: Stub bzip2.

[...]

>                   (chdir "bootar")
> +                 (when ,(equal? (%current-system) "i686-linux")
> +                   (delete-file "scripts/bzip2.in")
> +                   (delete-file "compression/bzip2.scm")
> +                   (with-output-to-file "compression/bzip2.scm"
> +                     (lambda _
> +                       (display "(define-module (compression bzip2))
> +(define-public is-bzip2-file? (const #f))
> +(define-public make-bzip2-input-port (const #f))
> +"))))

Perhaps you can write it in a way that avoids rebuilds on x86_64:

  ,@(if (equal? …)
        '((…))
        '())

Or actually, we can just remove the functionality unconditionally for
now since it could be error-prone to have different features depending
on the platform.

WDYT?

Timothy Sample <address@hidden> skribis:

> Both of those are good options.  The 32-bit fixnum limit is a something
> of a development artifact.  I think I can remove it without problems.
> If not, I will just remove BZip2 support for now, since I think you’re
> right that we don’t use it.

For now I guess we can apply something as discussed above, but in the
longer run, it’d be nice to have that 32-bit limit waived!

> Sorry for the little hiccup!

No problem, it’s really great that we got these binary seeds further
reduced!

Ludo’.