bug#39575: guix time-machine fails when a tarball was modified in-place

[zimoun]

Hi,


On Wed, 12 Feb 2020 at 14:44, Jan Nieuwenhuizen <address@hidden> wrote:

> Trying to travel back to Sun Apr 7 22:07:14 2019 +0200 (commit
> 56e95d54d209c2428f970d65d9b27ae4168449ad) to re-create mcrl2-minimal by
> doing
>
> --8<---------------cut here---------------start------------->8---
> guix time-machine --commit=56e95d54d209c2428f970d65d9b27ae4168449ad -- 
> environment --ad-hoc mcrl2-minimal
> --8<---------------cut here---------------end--------------->8---

Even the simple:

--8<---------------cut here---------------start------------->8---
guix time-machine --commit=56e95d54d209c2428f970d65d9b27ae4168449ad -- help
--8<---------------cut here---------------end--------------->8---

> fails with
>
> --8<---------------cut here---------------start------------->8---
> building 
> /gnu/store/cjim33x0q1bv1ppkv3qijvr1pvsn4y0q-harfbuzz-2.4.0.tar.bz2.drv...
> downloading from 
> https://www.freedesktop.org/software/harfbuzz/release/harfbuzz-2.4.0.tar.bz2...
> |offloading build of 
> /gnu/store/6fgg1irkcvqyb4f9f8n0nzi5gknyqhfn-gcc-mesboot1-4.7.4.drv to 
> 'kluit.dezyne.org'
> - 'build' phasesha256 hash mismatch for 
> /gnu/store/b4cdp9sp44848348lrpzbfafhmjqf8nr-harfbuzz-2.4.0.tar.bz2:
>   expected hash: 1mpah6kwqid1kxsj4rwqsniivqbrx231j65v51yncx6s0dch0dch
>   actual hash:   0vrkvdlmihdg62a4c6h5kx27khc33xmb95l50zgnwnavvpwyyw5l
> hash mismatch for store item 
> '/gnu/store/b4cdp9sp44848348lrpzbfafhmjqf8nr-harfbuzz-2.4.0.tar.bz2'
> build of 
> /gnu/store/cjim33x0q1bv1ppkv3qijvr1pvsn4y0q-harfbuzz-2.4.0.tar.bz2.drv failed
> View build log at 
> '/var/log/guix/drvs/cj/im33x0q1bv1ppkv3qijvr1pvsn4y0q-harfbuzz-2.4.0.tar.bz2.drv.bz2'.
> cannot build derivation 
> `/gnu/store/p6gfcdacjcqf2br0zwsyzx1chfvg9gxi-harfbuzz-2.4.0.drv': 1 
> dependencies couldn't be built
> killing process 5083
> --8<---------------cut here---------------end--------------->8---

same for e.g., this commit:

--8<---------------cut here---------------start------------->8---
 guix time-machine --commit=ae528aaf19f3828d3d7d204b15570800e1bbf100 -- help
--8<---------------cut here---------------end--------------->8---


> The recipe for harfbuzz has a sha256 that used to be valid in April, but
> hasn't been valid anymore since May, as this fix
>
> --8<---------------cut here---------------start------------->8---
> commit a8bb8fccd82a10a46f127b2235675b4f6cbaaf98
> Author: Marius Bakke <address@hidden>
> Date:   Sat May 4 18:01:12 2019 +0200
>
>     gnu: harfbuzz: Update source hash.
>
>     The previous tarball was modified in-place; see
>     <https://github.com/harfbuzz/harfbuzz/issues/1641>.
>
>     * gnu/packages/gtk.scm (harfbuzz)[source](sha256): Update.
> --8<---------------cut here---------------end--------------->8---
>
> shows.  Thoughts?

Therefore, all the commits between the introduction of harfbuzz with
the old sha256 (commit 2da9b81837fd1e6f08a10952784d3358be982855) and
the commit updating to the new sha256 should be broken.
Roughly speaking, all the commits between April, 7th and the May, 4th;
i.e., 1100+ commits, isn't it?


Well, this ask an interesting question: how Guix can fallback when
upstream is doing wrong?


Considering this 'harbuzz' issue, is it possible to rebuild the old
tarball and push it to SoftWare Heritage? Then when a sha mismatch
happens, fallback and try to fetch it from SWH?


WDYT?

Cheers,
simon