[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#39699: [core-updates] gash-boot0 fails on i686-linux
From: |
Ludovic Courtès |
Subject: |
bug#39699: [core-updates] gash-boot0 fails on i686-linux |
Date: |
Fri, 21 Feb 2020 21:38:36 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
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’.
bug#39699: [core-updates] gash-boot0 fails on i686-linux, Timothy Sample, 2020/02/21