GNU bug report logs - #32347
gzip cannot be patched

Previous Next

To reply to this bug, email your comments to 32347 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: bug-guix <at> gnu.org
Subject: gzip cannot be patched
Date: Thu, 02 Aug 2018 13:32:02 +0200

[Message part 1 (text/plain, inline)]

Hello!

I'm trying to add a patch to 'gzip', but it causes an infinite loop and
eventually the system runs out of memory.

It can be reproduced by adding this hunk:

[Message part 2 (text/x-patch, inline)]

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"))))

[back]

[Message part 3 (text/plain, inline)]

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?

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 32347 <at> debbugs.gnu.org (full text, mbox):

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Marius Bakke <mbakke <at> fastmail.com>
Cc: 32347 <at> debbugs.gnu.org
Subject: Re: bug#32347: gzip cannot be patched
Date: Thu, 2 Aug 2018 14:57:18 +0300

[Message part 1 (text/plain, inline)]

On Thu, Aug 02, 2018 at 01:32:02PM +0200, Marius Bakke wrote:
> Hello!
> 
> I'm trying to add a patch to 'gzip', but it causes an infinite loop and
> eventually the system runs out of memory.
> 
> It can be reproduced by adding this hunk:
> 

> 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"))))
> 
> [back]
> 
> 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".


-- 
Efraim Flashner   <efraim <at> flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[signature.asc (application/pgp-signature, inline)]

Message #11 received at 32347 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: Marius Bakke <mbakke <at> fastmail.com>, 32347 <at> debbugs.gnu.org
Subject: Re: bug#32347: gzip cannot be patched
Date: Sun, 19 Aug 2018 15:48:05 +0200

Hello,

Efraim Flashner <efraim <at> flashner.co.il> skribis:

> On Thu, Aug 02, 2018 at 01:32:02PM +0200, Marius Bakke wrote:
>> Hello!
>> 
>> I'm trying to add a patch to 'gzip', but it causes an infinite loop and
>> eventually the system runs out of memory.
>> 
>> It can be reproduced by adding this hunk:
>> 
>
>> 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"))))
>> 
>> [back]
>> 
>> 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 ‘bootstrap-origin’ procedure, defined in (gnu packages
bootstrap), arranges to use the bootstrap binaries of gzip, patch,
guile, etc. when patching origins.

Perhaps we’re missing a use of ‘bootstrap-origin’ somewhere in (gnu
packages commencement)?

HTH,
Ludo’.

Message #14 received at 32347 <at> debbugs.gnu.org (full text, mbox):

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Marius Bakke <mbakke <at> fastmail.com>, 32347 <at> debbugs.gnu.org
Subject: Re: bug#32347: gzip cannot be patched
Date: Wed, 3 Oct 2018 11:01:41 +0300

[Message part 1 (text/plain, inline)]

On Sun, Aug 19, 2018 at 03:48:05PM +0200, Ludovic Courtès wrote:
> Hello,
> 
> Efraim Flashner <efraim <at> flashner.co.il> skribis:
> 
> > On Thu, Aug 02, 2018 at 01:32:02PM +0200, Marius Bakke wrote:
> >> Hello!
> >> 
> >> I'm trying to add a patch to 'gzip', but it causes an infinite loop and
> >> eventually the system runs out of memory.
> >> 
> >> It can be reproduced by adding this hunk:
> >> 
> >
> >> 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"))))
> >> 
> >> [back]
> >> 
> >> 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 ‘bootstrap-origin’ procedure, defined in (gnu packages
> bootstrap), arranges to use the bootstrap binaries of gzip, patch,
> guile, etc. when patching origins.
> 
> Perhaps we’re missing a use of ‘bootstrap-origin’ somewhere in (gnu
> packages commencement)?
> 

Looks like it in the end. the gzip for glibc-utf8-locales-final uses the
bootstrap guile for its building, but doesn't get the input rewriting
that comes from package-with-bootstrap-guile. With this patch adding the
trivial snippet to gzip doesn't cause an infinite loop anymore. Since
the patch doesn't change the hash of glibc-utf8-locales-final it should
be OK for master.

-- 
Efraim Flashner   <efraim <at> flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[0001-gnu-glibc-utf8-locales-final-Wrap-inputs-with-packag.patch (text/plain, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #17 received at 32347 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: Ludovic Courtès <ludo <at> gnu.org>,
 Marius Bakke <mbakke <at> fastmail.com>, 32347 <at> debbugs.gnu.org
Subject: Re: bug#32347: gzip cannot be patched
Date: Tue, 29 Aug 2023 08:44:31 -0400

Hi Efraim,

Efraim Flashner <efraim <at> flashner.co.il> writes:

> On Sun, Aug 19, 2018 at 03:48:05PM +0200, Ludovic Courtès wrote:
>> Hello,
>> 
>> Efraim Flashner <efraim <at> flashner.co.il> skribis:
>> 
>> > On Thu, Aug 02, 2018 at 01:32:02PM +0200, Marius Bakke wrote:
>> >> Hello!
>> >> 
>> >> I'm trying to add a patch to 'gzip', but it causes an infinite loop and
>> >> eventually the system runs out of memory.
>> >> 
>> >> It can be reproduced by adding this hunk:
>> >> 
>> >
>> >> 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"))))
>> >> 
>> >> [back]
>> >> 
>> >> 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 ‘bootstrap-origin’ procedure, defined in (gnu packages
>> bootstrap), arranges to use the bootstrap binaries of gzip, patch,
>> guile, etc. when patching origins.
>> 
>> Perhaps we’re missing a use of ‘bootstrap-origin’ somewhere in (gnu
>> packages commencement)?
>> 
>
> Looks like it in the end. the gzip for glibc-utf8-locales-final uses the
> bootstrap guile for its building, but doesn't get the input rewriting
> that comes from package-with-bootstrap-guile. With this patch adding the
> trivial snippet to gzip doesn't cause an infinite loop anymore. Since
> the patch doesn't change the hash of glibc-utf8-locales-final it should
> be OK for master.

If you have verified the patch doesn't cause a world rebuild (guix build
libreoffice), feel free t opush and close this old bug!

-- 
Thanks,
Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.