[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: hash mismatch on permanently moved URL
From: |
Giovanni Biscuolo |
Subject: |
Re: hash mismatch on permanently moved URL |
Date: |
Thu, 02 Jul 2020 19:21:16 +0200 |
zimoun <zimon.toutoune@gmail.com> writes:
> On Thu, 2 Jul 2020 at 15:38, Giovanni Biscuolo <g@xelera.eu> wrote:
>
>> Actually this is a in-place *displacement* (with HTML) :-O
>
> I do not know what is an "inplace displacement (with HTML)".
Just a nonsense of mine :-)
[...]
> Redirection should not be an issue. The important point is the
> integrity of the data (the sha256 field).
> And here, there is a mismatch
Yes I go it, the very unusual thing is that the (double) redirection is
pointing to a web page (AFAIU) and *not* to the tgz source file
[...]
>> Problems like this one are very bad for our time machine, I'm just
>> thinking if Guix can do something to prevent them.
>
> I agree. But Guix cannot fix the world. :-)
...unfortunately not: it can fix *almost* all that is software related
> What is currently done seems The Right Thing:
>
> 1. fetch from the Guix farm
> 2. try with the current upstream
> 2b. try a mirror if any
> 3. fallback to SWH
>
> You hit the problem because you turn off the fallback to the Guix
> farm,
Yes I see, and actually it's a very specific use case
> BTW, the fallback to SWH is not ready yet for 2 main reasons:
>
> a) SWH has not yet ingested all the source tarballs in existence of
> Guix; and it is not ready. What is ready is to ingest the current
> source tarballs but nothing has been done to feed with all the past
> source tarballs.
> b) It is not clear how to fetch back the raw tarball from SWH since
> they do not store the checksum but their own hash id (SWHID). Some
> discussion about correspondence and so on is happening right now. :-)
I was not aware of this second point: thanks!
[...]
Happy hacking! Gio'
--
Giovanni Biscuolo
Xelera IT Infrastructures
signature.asc
Description: PGP signature