zimoun writes: > On Thu, 2 Jul 2020 at 15:38, Giovanni Biscuolo 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