GNU bug report logs - #52710
[PATCH 0/2] Update Disarchive

Previous Next

Package: guix-patches;

Reported by: Timothy Sample <samplet <at> ngyro.com>

Date: Tue, 21 Dec 2021 18:21:02 UTC

Severity: normal

Tags: patch

Done: Timothy Sample <samplet <at> ngyro.com>

Bug is archived. No further changes may be made.

Full log


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

From: Timothy Sample <samplet <at> ngyro.com>
To: guix-patches <at> gnu.org
Subject: [PATCH 0/2] Update Disarchive
Date: Tue, 21 Dec 2021 13:20:42 -0500
Hello,

These two patches update Disarchive to 0.4.0.  This version of Disarchive has
support for XZ, which requires Guile-LZMA.  Since Disarchive is a dependency
of the Guix package, I’m hoping someone else can look over the patches before
I push them.

I made sure to check the following things:

  • Building the Guix package
  • Running ‘guix pull’
  • Recovering a GZip-compressed tarball from Guix
  • Recovering a XZ-compressed tarball from Guix
  • Cross-compiling Guile-LZMA, Disarchive, and Guix itself
  • Running Guix from a cross-built Hurd image

I couldn’t use Disarchive recovery from the Hurd, but I’m inclined to
assume that it’s not a regression [1].  Other than that, everything seemed
okay to me.

If you want to test recovering an XZ source, you can use (amusingly)
the ‘gzip’ package source code (as of writing it’s the only XZ spec
available).  You need to run the Guix daemon in an environment that
provides the new Disarchive and Guile-LZMA (I used ‘./pre-inst-env
guix shell -D guix’).  Then, you can run

  $ GUIX_DOWNLOAD_FALLBACK_TEST=disarchive-mirrors \
        ./pre-inst-env guix build --check -S gzip

Thanks in advance!

[1]: AFAICS, it fails when the SWH downloader tries to pipe the tarball
it’s downloading into ‘tar’ to extract it.


-- Tim




This bug report was last modified 3 years and 149 days ago.

Previous Next


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