guix http downloads don't resume

Package: guix

By now, guix reconfigure has tried to download the same texlive binary from hydra at least 5 times to the same machine, unsuccessfully breaking after about 1 GB each, for a total of 5 GB, always starting from the beginning.

Would it be possible to just resume?

Additionally, it doesn't seem like it checks the Content-Length in order to find out whether the connection broke before the file was done. Why doesn't it?

The http-client seems to handle chunked encoding - so not sure whether it's a problem with hydra or with guix.

----

Found valid signature for /gnu/store/36wqhbch45x055wj6gfsng00zkwfqg6n-texlive-20150523-texmf.tar.xz

From http://hydra.gnu.org/nar/36wqhbch45x055wj6gfsng00zkwfqg6n-texlive-20150523-texmf.tar.xz

Downloading 36wqhb...-texlive-20150523-texmf.tar.xz (1.76GiB installed)...

http://hydra.gnu.org/nar/36wqhbch45x055wj6gfsng00zkwfqg6n-texlive-20150523-texmf.tar.xz1.1MiB/s 13:24 | 893.9MiB transferred

bzip2: Data integrity error when decompressing.

http://Inputfile = (stdin), output file = (stdout)wfqg6n-texlive-20150523-texmf.tar.xz 1.1MiB/s 13:24 | 893.9MiB transferred

It is possible that the compressed file(s) have become corrupted.

You can use the -tvv option to test integrity of such files.

You can use the `bzip2recover' program to attempt to recover

data from undamaged sections of corrupted files.

guix substitute: error: corrupt input while restoring '/gnu/store/36wqhbch45x055wj6gfsng00zkwfqg6n-texlive-20150523-texmf.tar.xz' from #{read pipe}#

killing process 3867g/nar/36wqhbch45x055wj6gfsng00zkwfqg6n-texlive-20150523-texmf.tar.xz 1.1MiB/s 13:24 | 893.9MiB transferred

guix system: error: build failed: some substitutes for the outputs of derivation `/gnu/store/83nkdyp9wl6zwflcm416xf1imppp7v9f-texlive-20150523-texmf.tar.xz.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source

---

Also, downloading it by wget right afterwards, it works just fine, all 1.77 GB of it. Wtf?

Danny Milosavljevic <dannym@scratchpost.org> skribis:

There does not seem to be an easy way to achieve this.

For archives (the /nar/foo URLs), there is currently no ‘Content-Length’

header at all (this is because Hydra, the software, generates those

files on the fly; we should tweak nginx to add a ‘Content-Length’

header, but this seems to require an external nginx plugin.)

However, the {mirror.,}hydra.gnu.org use chunked encoding, indeed, which

allows the HTTP client to detect truncated transfers.

Ludo’.

severity 22745 wishlist

Hi

Is this still a problem after Pierres work on texlive and when using the

mirror?

--

Cheers

Swedebugia