From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#32347: gzip cannot be patched Date: Sun, 19 Aug 2018 15:48:05 +0200 Message-ID: <87a7piii22.fsf@gnu.org> References: <87muu56m31.fsf@fastmail.com> <20180802115718.GD13776@macbook41> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frO4l-0001n0-2W for bug-guix@gnu.org; Sun, 19 Aug 2018 09:49:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1frO4k-0003qH-Fj for bug-guix@gnu.org; Sun, 19 Aug 2018 09:49:03 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:49461) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1frO4k-0003q9-CS for bug-guix@gnu.org; Sun, 19 Aug 2018 09:49:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1frO4k-0007gb-5r for bug-guix@gnu.org; Sun, 19 Aug 2018 09:49:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <20180802115718.GD13776@macbook41> (Efraim Flashner's message of "Thu, 2 Aug 2018 14:57:18 +0300") 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.org@gnu.org Sender: "bug-Guix" To: Efraim Flashner Cc: 32347@debbugs.gnu.org Hello, Efraim Flashner skribis: > On Thu, Aug 02, 2018 at 01:32:02PM +0200, Marius Bakke wrote: >> Hello! >>=20 >> I'm trying to add a patch to 'gzip', but it causes an infinite loop and >> eventually the system runs out of memory. >>=20 >> It can be reproduced by adding this hunk: >>=20 > >> modified gnu/packages/compression.scm >> @@ -215,6 +215,7 @@ adding and extracting files to/from a tar archive.") >> (method url-fetch) >> (uri (string-append "mirror://gnu/gzip/gzip-" >> version ".tar.xz")) >> + (snippet '(#t)) >> (sha256 >> (base32 >> "16h8g4acy7fgfxcjacr3wijjsnixwsfd2jhz3zwdi2qrzi262l5f")))) >>=20 >> [back] >>=20 >> I guess this is because gzip itself is a patch input. Is this something >> that can be fixed, or do we have to use "patching phases" in these cases? > > Its also in commencement.scm, so that might be the loop instead. You > could try "unpatching" it there. It looks like it has a pseudo-package > inside of glibc-utf8-locales-final, with grep-final a few packages lower > being potential inspiration for undoing the modifications in "real > gzip". Indeed. The =E2=80=98bootstrap-origin=E2=80=99 procedure, defined in (gnu = packages bootstrap), arranges to use the bootstrap binaries of gzip, patch, guile, etc. when patching origins. Perhaps we=E2=80=99re missing a use of =E2=80=98bootstrap-origin=E2=80=99 s= omewhere in (gnu packages commencement)? HTH, Ludo=E2=80=99.