sha3-384 mismatch

Mon Dec 5 16:32:14 UTC 2016

Okay, so curl is not retrying. That means the problem is specific to
something snapd is doing with the server.. might still be a problem on the
client or the server under those particular conditions.

Can I hand you a binary for you to try out?

On Mon, Dec 5, 2016 at 1:44 PM, Didier Roche <didrocks at ubuntu.com> wrote:

> Le 05/12/2016 à 16:05, Gustavo Niemeyer a écrit :
>
> Xavier posted the exact URL of the failing snap in this thread:
>
> Note it's not *the* failing snap but *a* failing snap. Every "snap
> install" here is failing on my setup when they are more than a couple of
> MB. This is why I posted as such in the instructions on the bug.
>
> So, with curl -v -L, with the same snap than on the bug report, here are
> the results: http://paste.ubuntu.com/23583801/
> I did 10 successful downloads in a row. This snap is 23MB.
>
> I did retry with the new revision (49), 32MB.
> Tried 10 times with curl, 10 successful and complete downloads (one is
> http://paste.ubuntu.com/23583847/), with expected size and checksum.
> Tried 10 times with snapd, got hashsum mismatch 10 times. Download stops
> after few KBs up to few MBs.
>
> Cheers,
> Didier
>
>
>
> "[1] - https://public.apps.ubuntu.com/anon/download-snap/rFpKbTdZ
> 31LyAxWF6RpcerZov1TdtDly_24.snap (extracted from the log file)"
>
> Bret also posted another one above (thanks!).
>
>
> On Mon, Dec 5, 2016 at 12:52 PM, Didier Roche <didrocks at ubuntu.com> wrote:
>
>> Le 05/12/2016 à 15:38, Gustavo Niemeyer a écrit :
>>
>>
>>
>> On Mon, Dec 5, 2016 at 12:23 PM, Didier Roche <didrocks at ubuntu.com>
>> wrote:
>>
>>> 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 :)
>>>
>>
>> If you file a bug and a developer asks for specific information that
>> wasn't provided, it means the specific information is not obvious.
>>
>> 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.
>>>
>>
>> You are downloading an image from an arbitrary server on the internet
>> unrelated to the problem we're trying to debug.
>>
>> Can you please attempt these several curl downloads while using the exact
>> same URL that failed for snapd?
>>
>>
>> As a developer asking for more debug information, can you please paste
>> the exact instructions on how to get those?
>>
>> I'm trying the https://public.apps.ubuntu.com/anon/download-snap/ based
>> url with the .snap showing up in the logs to get the exact same assets I
>> pasted snapd information on. However, curl -v returns (output stripped out):
>> *   Trying 162.213.33.92...
>> * Connected to public.apps.ubuntu.com (162.213.33.92) port 443 (#0)
>> * found 173 certificates in /etc/ssl/certs/ca-certificates.crt
>> * found 692 certificates in /etc/ssl/certs
>> * ALPN, offering http/1.1
>> * SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
>> *      server certificate verification OK
>> *      server certificate status verification SKIPPED
>> *      common name: public.apps.ubuntu.com (matched)
>> *      server certificate expiration date OK
>> *      server certificate activation date OK
>> *      certificate public key: RSA
>> *      certificate version: #3
>> *      subject: C=GB,L=London,O=Canonical Group Ltd,CN=
>> public.apps.ubuntu.com
>> *      start date: Mon, 30 May 2016 00:00:00 GMT
>> *      expire date: Wed, 21 Jun 2017 12:00:00 GMT
>> *      issuer: C=US,O=DigiCert Inc,CN=DigiCert SHA2 Secure Server CA
>> *      compression: NULL
>> * ALPN, server did not agree to a protocol
>> > GET /anon/download-snap/YZ7LshLxDQQIrhAL6DMLub2yTVUA2DIK_15.snap
>> HTTP/1.1
>> > Host: public.apps.ubuntu.com
>> > User-Agent: curl/7.47.0
>> > Accept: */*
>> >
>> < HTTP/1.1 302 FOUND
>>
>> I guess that's due to the macaroon exchanged system and I'm not
>> authorized or something else?
>> Thanks for helping debugging.
>>
>> Cheers,
>> Didier
>>
>> --
>> Snapcraft mailing list
>> Snapcraft at lists.snapcraft.io
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/snapcraft
>>
>>
>
>
> --
>
> gustavo @ http://niemeyer.net
>
>
>
>
> --
> Snapcraft mailing list
> Snapcraft at lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/snapcraft
>
>

-- 

gustavo @ http://niemeyer.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20161205/f4534799/attachment.html>