GNU bug report logs - #64708
[PATCH 0/8] Fix cross build and native build for the Hurd.

Previous Next

Package: guix-patches;

Reported by: Janneke Nieuwenhuizen <janneke <at> gnu.org>

Date: Tue, 18 Jul 2023 13:13:02 UTC

Severity: normal

Tags: patch

Done: Janneke Nieuwenhuizen <janneke <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Janneke Nieuwenhuizen <janneke <at> gnu.org>
Cc: 64708 <at> debbugs.gnu.org
Subject: [bug#64708] [PATCH 0/8] Fix cross build and native build for the Hurd.
Date: Tue, 18 Jul 2023 23:13:58 +0200
Janneke Nieuwenhuizen <janneke <at> gnu.org> skribis:

> From: Ludovic Courtès <ludo <at> gnu.org>
>
> * gnu/packages/commencement.scm (git-fetch-from-tarball): New procedure.

I guess this one is very weird so it deserves an explanation.

The problems we’re trying to solve are:

  1. We cannot use ‘git-fetch’ at this point because that’d introduce a
     circular dependency: <https://issues.guix.gnu.org/63331>.

  2. Downloading a cgit-generated tarball is unsafe: the tarball might
     be modified when cgit is updated or whatever, leading to a hash
     mismatch that we wouldn’t be able to resolve (well,
     disarchive.guix.gnu.org might be able to add an entry for that
     tarball, but then there’s currently no fallback in case of hash
     mismatch: <https://issues.guix.gnu.org/28659>).

So we need to obtain our Git checkouts by some other mean.  There are
further complications:

  3. We could use (web client), but without (gnutls) since it’s
     unavailable at this stage.

  4. We cannot use (guix swh) as is because Guile-JSON doesn’t build
     with Guile 2.0, which is what we have here.

The trick below is the only way I could think of to reconcile these
issues: it essentially stacks two fixed-output derivation.  The first
one downloads that auto-generated tarball (bad!), and the second one
extracts the contents of that tarball using ‘tar’ from
‘%bootstrap-coreutils&co’.  The output of the second one is identical to
what ‘git-fetch’ would give us (or ‘swh-download’).

That makes it more robust.  It also allows ‘guix lint -c archival’ to do
its work and similarly (well, almost) for ‘build-package-metadata.scm’,
the program that builds <https://guix.gnu.org/sources.json>, which SWH
periodically ingests.

Pfeww, long story.

> +(define* (git-fetch-from-tarball tarball)

Maybe add this docstring:

    "Return an <origin> method equivalent to 'git-fetch', except that it
  fetches the checkout from TARBALL, a tarball containing said
  checkout.

  The purpose of this procedure is to work around bootstrapping issues:
  'git-fetch' depends on Git, which is much higher in the dependency
  graph."

> +             (setenv "PATH"
> +                     #+(file-append %bootstrap-coreutils&co "/bin"))
> +             (invoke (string-append #+tar "/bin/tar")
> +                     "xf" #$tarball)

This should be: (invoke "tar" "xf" #$tarball).
Otherwise we’d get a cyclic dependency with ‘tar’.

(I didn’t notice because there’s a bug where ‘-s’ is ignored here:

  ./pre-inst-env guix build -e '(@@ (gnu packages commencement) mig-boot0)' \
    -s i586-gnu -Sd

)

OK with these changes!

Ludo’.




This bug report was last modified 2 years and 2 days ago.

Previous Next


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