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 <didro...@ubuntu.com > <mailto:didro...@ubuntu.com>> wrote: > > Le 05/12/2016 à 15:38, Gustavo Niemeyer a écrit : >> >> >> On Mon, Dec 5, 2016 at 12:23 PM, Didier Roche >> <didro...@ubuntu.com <mailto:didro...@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@lists.snapcraft.io <mailto:Snapcraft@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 > >
-- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
