From mboxrd@z Thu Jan 1 00:00:00 1970 From: zimoun Subject: bug#39575: guix time-machine fails when a tarball was modified in-place Date: Wed, 12 Feb 2020 15:55:27 +0100 Message-ID: References: <87y2t7j54n.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:50432) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j1tQp-0005tg-Tn for bug-guix@gnu.org; Wed, 12 Feb 2020 09:56:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j1tQo-0005RO-Je for bug-guix@gnu.org; Wed, 12 Feb 2020 09:56:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:52941) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j1tQo-0005RK-Fx for bug-guix@gnu.org; Wed, 12 Feb 2020 09:56:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j1tQo-0002Nr-FH for bug-guix@gnu.org; Wed, 12 Feb 2020 09:56:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87y2t7j54n.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane-mx.org@gnu.org Sender: "bug-Guix" To: Jan Nieuwenhuizen Cc: 39575@debbugs.gnu.org Hi, On Wed, 12 Feb 2020 at 14:44, Jan Nieuwenhuizen 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 > Date: Sat May 4 18:01:12 2019 +0200 > > gnu: harfbuzz: Update source hash. > > The previous tarball was modified in-place; see > . > > * 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