sha3-384 mismatch

Mon Dec 5 15:44:23 UTC 2016

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/rFpKbTdZ31LyAxWF6RpcerZov1TdtDly_24.snap
> <https://public.apps.ubuntu.com/anon/download-snap/rFpKbTdZ31LyAxWF6RpcerZov1TdtDly_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
> <mailto: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 <mailto: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/
>>         <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/
>     <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
>     <http://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
>     <http://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 <http://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 <http://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 <mailto:Snapcraft at lists.snapcraft.io>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/mailman/listinfo/snapcraft
>     <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/928be5fb/attachment.html>