Re: guix time-machine, broken hash in an old package definition, a workaround?

[zimoun]

Hi,

Sadly, nothing can be done.  Well, I hope that someone will show me I am
wrong. :-)

--8<---------------cut here---------------start------------->8---
$ guix time-machine --commit=d81fb2ae9443994ae5dd1cb5837276fad63f842c \
       -- weather r-foreign \
       --substitute-urls="https://ci.guix.gnu.org https://bayfront.guix.gnu.org 
https://guix.cbaines.net https://guix.tobias.gr 
https://builds.guix-patches.cbaines.net";
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
guile: warning: failed to install locale
hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' package
and defining `GUIX_LOCPATH', along these lines:

     guix package -i glibc-utf8-locales
     export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"

See the "Application Setup" section in the manual, for more info.

computing 1 package derivations for x86_64-linux...
looking for 1 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org
  .0% substitutes available (0 out of 1)
  unknown substitute sizes
  0.0 MiB on disk (uncompressed)
  0.000 seconds per request (0.0 seconds in total)
  2770.1 requests per second

  0.0% (0 out of 1) of the missing items are queued
  660 queued builds
      i586-gnu: 5 (.8%)
      aarch64-linux: 634 (96.1%)
      armhf-linux: 1 (.2%)
      x86_64-linux: 18 (2.7%)
      i686-linux: 2 (.3%)
  build rate: 111.65 builds per hour
      x86_64-linux: 37.52 builds per hour
      aarch64-linux: 70.38 builds per hour
      i686-linux: 4.14 builds per hour
looking for 1 store items on https://bayfront.guix.gnu.org...
updating substitutes from 'https://bayfront.guix.gnu.org'... 100.0%
https://bayfront.guix.gnu.org
  .0% substitutes available (0 out of 1)
  unknown substitute sizes
  0.0 MiB on disk (uncompressed)
  0.176 seconds per request (0.2 seconds in total)
  5.7 requests per second

  0.0% (0 out of 1) of the missing items are queued
  93 queued builds
      x86_64-linux: 93 (100.0%)
  'https://bayfront.guix.gnu.org/api/latestbuilds?nr=1000' returned 504 
("Gateway Time-out")
looking for 1 store items on https://guix.cbaines.net...
updating substitutes from 'https://guix.cbaines.net'... 100.0%
https://guix.cbaines.net
  .0% substitutes available (0 out of 1)
  unknown substitute sizes
  0.0 MiB on disk (uncompressed)
  1.751 seconds per request (1.8 seconds in total)
  0.6 requests per second
  (continuous integration information unavailable)
looking for 1 store items on https://guix.tobias.gr...
updating substitutes from 'https://guix.tobias.gr'... 100.0%
https://guix.tobias.gr
  .0% substitutes available (0 out of 1)
  unknown substitute sizes
  0.0 MiB on disk (uncompressed)
  0.210 seconds per request (0.2 seconds in total)
  4.8 requests per second
  (continuous integration information unavailable)
looking for 1 store items on https://builds.guix-patches.cbaines.net...
updating substitutes from 'https://builds.guix-patches.cbaines.net'... 100.0%
https://builds.guix-patches.cbaines.net
  .0% substitutes available (0 out of 1)
  unknown substitute sizes
  0.0 MiB on disk (uncompressed)
  0.182 seconds per request (0.2 seconds in total)
  5.5 requests per second
  (continuous integration information unavailable)
--8<---------------cut here---------------end--------------->8---

Well, maybe someone has the tarball in their personal store and could
share it.  Otherwise, it is game over.

The story about “guix time-machine” and tarball is far to be complete
and robust.  It is impossible to fix the upstream in-place replacement.
The only thing the Guix project can do is store these tarballs on their
machine; it is what it is commonly done but time to time edge cases
happen, sadly.

Instead of archiving the upstream source code on machines from Guix
projects, the idea is to use Software Heritage infrastructure as
archivist.  It works pretty well for Git source because the mapping
(content-address) between Git ID, SWH-ID, and NAR hash is almost
straightforward.  But, this mapping is not as straightforward for
tarballs because of metadata.  That’s the aim of the project Disarchive;
still experimental.

https://git.ngyro.com/disarchive-db/


One way to locally fix is: checkout the Guix repo at commit
d81fb2ae9443994ae5dd1cb5837276fad63f842c, then tweak the checksum, build
from this source, and use:

  ./pre-inst-env guix environment -C -m manifest.scm


All the best,
simon