On Sun, Aug 19, 2018 at 03:48:05PM +0200, Ludovic Courtès wrote: > Hello, > > Efraim Flashner 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 אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted