all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#32347: gzip cannot be patched
@ 2018-08-02 11:32 Marius Bakke
  2018-08-02 11:57 ` Efraim Flashner
  0 siblings, 1 reply; 5+ messages in thread
From: Marius Bakke @ 2018-08-02 11:32 UTC (permalink / raw)
  To: 32347


[-- Attachment #1.1: Type: text/plain, Size: 166 bytes --]

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:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: Type: text/x-patch, Size: 410 bytes --]

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]

[-- Attachment #1.3: Type: text/plain, Size: 148 bytes --]


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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#32347: gzip cannot be patched
  2018-08-02 11:32 bug#32347: gzip cannot be patched Marius Bakke
@ 2018-08-02 11:57 ` Efraim Flashner
  2018-08-19 13:48   ` Ludovic Courtès
  0 siblings, 1 reply; 5+ messages in thread
From: Efraim Flashner @ 2018-08-02 11:57 UTC (permalink / raw)
  To: Marius Bakke; +Cc: 32347

[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]

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@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#32347: gzip cannot be patched
  2018-08-02 11:57 ` Efraim Flashner
@ 2018-08-19 13:48   ` Ludovic Courtès
  2018-10-03  8:01     ` Efraim Flashner
  0 siblings, 1 reply; 5+ messages in thread
From: Ludovic Courtès @ 2018-08-19 13:48 UTC (permalink / raw)
  To: Efraim Flashner; +Cc: 32347

Hello,

Efraim Flashner <efraim@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’.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#32347: gzip cannot be patched
  2018-08-19 13:48   ` Ludovic Courtès
@ 2018-10-03  8:01     ` Efraim Flashner
  2023-08-29 12:44       ` Maxim Cournoyer
  0 siblings, 1 reply; 5+ messages in thread
From: Efraim Flashner @ 2018-10-03  8:01 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 32347


[-- Attachment #1.1: Type: text/plain, Size: 2273 bytes --]

On Sun, Aug 19, 2018 at 03:48:05PM +0200, Ludovic Courtès wrote:
> Hello,
> 
> Efraim Flashner <efraim@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@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

[-- Attachment #1.2: 0001-gnu-glibc-utf8-locales-final-Wrap-inputs-with-packag.patch --]
[-- Type: text/plain, Size: 1462 bytes --]

From a3b7f9851e121fd3eb5f52ff4197923553032ec7 Mon Sep 17 00:00:00 2001
From: Efraim Flashner <efraim@flashner.co.il>
Date: Wed, 3 Oct 2018 10:33:23 +0300
Subject: [PATCH] gnu: glibc-utf8-locales-final: Wrap inputs with
 'package-with-bootstrap-guile'.

* gnu/packages/commencement.scm (glibc-utf8-locales-final)[inputs]: Wrap
gzip with 'package-with-bootstrap-guile'.
---
 gnu/packages/commencement.scm | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index 30a0ffcec..6c0f4e310 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -870,9 +870,10 @@ exec ~a/bin/~a-~a -B~a/lib -Wl,-dynamic-linker -Wl,~a/~a \"$@\"~%"
     (inherit glibc-utf8-locales)
     (inputs `(("glibc" ,glibc-final)
               ("gzip"
-               ,(package-with-explicit-inputs gzip %boot4-inputs
-                                              (current-source-location)
-                                              #:guile %bootstrap-guile))))))
+               ,(package-with-bootstrap-guile
+                  (package-with-explicit-inputs gzip %boot4-inputs
+                                                (current-source-location)
+                                                #:guile %bootstrap-guile)))))))
 
 (define-public ld-wrapper
   ;; The final 'ld' wrapper, which uses the final Guile and Binutils.
-- 
2.19.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* bug#32347: gzip cannot be patched
  2018-10-03  8:01     ` Efraim Flashner
@ 2023-08-29 12:44       ` Maxim Cournoyer
  0 siblings, 0 replies; 5+ messages in thread
From: Maxim Cournoyer @ 2023-08-29 12:44 UTC (permalink / raw)
  To: Efraim Flashner; +Cc: Ludovic Courtès, Marius Bakke, 32347

Hi Efraim,

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

> On Sun, Aug 19, 2018 at 03:48:05PM +0200, Ludovic Courtès wrote:
>> Hello,
>> 
>> Efraim Flashner <efraim@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




^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-08-29 12:45 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-08-02 11:32 bug#32347: gzip cannot be patched Marius Bakke
2018-08-02 11:57 ` Efraim Flashner
2018-08-19 13:48   ` Ludovic Courtès
2018-10-03  8:01     ` Efraim Flashner
2023-08-29 12:44       ` Maxim Cournoyer

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.