sha3-384 mismatch

[Didier Roche]

Le 05/12/2016 à 13:57, Gustavo Niemeyer a écrit :
>
>
> On Mon, Dec 5, 2016 at 5:23 AM, Didier Roche <didrocks at ubuntu.com
> <mailto:didrocks at ubuntu.com>> wrote:
>
>     Le 03/12/2016 à 16:01, Gustavo Niemeyer a écrit :
>>     Hi Xavier,
>>
>>     There's definitely a problem interrupting the connection with the
>>     server. The fact it works sometimes means it's inconsistent.
>>
>>     Can you please try to download such files several times out of
>>     snap and snapd, to see what the error is?
>>
>>     Per my note above, we had a bug in snapd which prevents the real
>>     error from being shown. We're always showing the digest mismatch
>>     instead, which will of course happen if the download is
>>     interrupted before its end.
>>
>>
>     As written on the bug report + some part feedback emails you
>     received some weeks earlier, it seems you ignored one part of the
>     issue. Yes, it seems the network is failing. However, snapd
>     consistenly fails in my case for downloading, while other tools,
>     like wget and curl can download bigger files, many times, without
>     ever getting one failure. They are more robust in difficult
>     network situations it seems.
>
>
> Neither this thread nor the bug report mentioned that wget/curl worked
> consistently across several tries.

I did though write on the bug: "contrary to curl or wget which both
supports large downloads."
The feedback thread mentioned as well "while same assets can be
successfully downloaded via curl or wget".

I thought that was really obvious that they worked consistently and that
I did rerun then multiple times or I wouldn't have opened the bug report
+ write this feedback. Sorry if that wasn't clear enough, let's move on :)
>
> Is it the case?  Did you ever get a failure with them?  Are they
> retrying while they work? Do you have a verbose dumb of the process?
Yes, as mentioned. I never got any failure with any of them and I did
retry multiple times in loop when I saw the snapd failures.
wget is in verbose mode by default and I never got any hint that it was
retrying (just getting the normal download output).

I did just try a verbose download in curl (here, an ubuntu 300M image).
Here is the output: http://paste.ubuntu.com/23583568/. It seems that
curl doesn't complain of any reconnect.

>
>     So either the store connection side is fragile or snapd isn't
>     robust enough while other tools cope with those conditions just
>     fine (without any warning/debug message telling that they are
>     retrying).
>
>
> Yes, something is wrong. :)

Right, I have the feeling this is related to some timeout when the
connexion hangs without any data for a very short period of time (as the
failure happens in ~1s or 2s each time after downloading 1 or 2Mb).

Cheers,
Didier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20161205/b754b59b/attachment.html>