As of e6a94d4, we use Guix's upstream git repo on https://git.savannah.gnu.org/git/guix.git for our guix time-machine-powered pinning.

However, it does seem that we occasionally will encounter problems with Guix's upstream repo which are not easily fixed using the Guix package transformation flags.

In particular:

1. A test of gnutls failed because of a chronological error whereby a certificate used in a test expired. (guix: gnutls-3.6.12 build failures when using --bootstrap --no-substitutes #21203)
   • We waited until Guix v1.3.0 was released to bump our time-machine to a Guix with a newer version of gnutls that had the test fixed.
2. A test of libgit2 failed because of a chronological error whereby a test relied on relative time calculations from the present, which needed to be bumped every year (Guix build w/o substitutes failing at libgit2 check #25082)

/me shakes fist at upstream packages writing tests that depend on the current time

Both of these problems are in packages that "underpin Guix", which means that

1. It is in the best interest of Guix (and its users) to keep testing these packages instead of turning off tests entirely
2. They are not subject to the Guix package transformation flags. (--without-tests=blah, etc.)
3. Changes to these packages will cause a mass-rebuild of almost all of Guix's packages, so these changes will be in Guix's "core-updates" branch for a while before hitting master (see the Guix Manual section on Submitting Patches).

I think the better way might be to just maintain our own fork of Guix, that is minimally patched compared to upstream, so that we have more flexibility when deploying fixes like these and not have to wait for upstream (Guix or the actual package itself) to take our patches, go through their branching process, and hit Guix master.

What do people think? @fanquake @hebasto @laanwj