Re: hash mismatch on permanently moved URL

[Giovanni Biscuolo <g@xelera.eu>]

[-- Attachment #1: Type: text/plain, Size: 1805 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]