From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Subject: bug#39699: [core-updates] gash-boot0 fails on i686-linux Date: Fri, 21 Feb 2020 21:38:36 +0100 Message-ID: <87h7zj3cc3.fsf@gnu.org> References: <87y2sx41f2.fsf@devup.no> <87zhdc9b1e.fsf@gnu.org> <87mu9c81z9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:54090) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j5F4h-0004vp-Re for bug-guix@gnu.org; Fri, 21 Feb 2020 15:39:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j5F4g-0001xd-Gq for bug-guix@gnu.org; Fri, 21 Feb 2020 15:39:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:42239) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j5F4g-0001xV-DJ for bug-guix@gnu.org; Fri, 21 Feb 2020 15:39:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j5F4g-0004h1-AO for bug-guix@gnu.org; Fri, 21 Feb 2020 15:39:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87mu9c81z9.fsf@gnu.org> (Jan Nieuwenhuizen's message of "Fri, 21 Feb 2020 15:11:06 +0100") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane-mx.org@gnu.org Sender: "bug-Guix" To: Jan Nieuwenhuizen Cc: 39699@debbugs.gnu.org Hi! Jan Nieuwenhuizen skribis: > Ludovic Court=C3=A8s writes: > > Hi! > >> I can see two solutions: >> >> 1. Remove bzip2 support from bootar (it=E2=80=99s 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=E2=80=99t think we=E2=80=99ll introduce new uses of bzip2 on the boot= strap path. So if it=E2=80=99s unnecessary today, it may remain unnecessary in the foreseeable future. > From 06bc492cdc1f476f0caa558546290ceafde357b1 Mon Sep 17 00:00:00 2001 > From: Jan Nieuwenhuizen > Date: Fri, 21 Feb 2020 07:46:16 +0100 > Subject: [PATCH] gnu: commencement: bootar: Build fix for i686-linux. > > See #39699 Nitpick: =E2=80=9CFixes .=E2=80=9D :-) > * 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? =E2=80=A6) '((=E2=80=A6)) '()) 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 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=E2=80= =99re > right that we don=E2=80=99t use it. For now I guess we can apply something as discussed above, but in the longer run, it=E2=80=99d be nice to have that 32-bit limit waived! > Sorry for the little hiccup! No problem, it=E2=80=99s really great that we got these binary seeds further reduced! Ludo=E2=80=99.