[05:25] <ricotz> hi, I guess this one needs a little pinch https://launchpad.net/ubuntu/+source/libreoffice/1:5.1.3-0ubuntu1/+build/9771317
=== gkadam is now known as Guest57576
=== Guest57576 is now known as gkadam
[07:02] <stub> cjwatson, wgrant: I wonder what happens if you request a file from Swift that is still being uploaded?
[07:02] <wgrant> stub: Hm, I'd hope nothing. eg. multipart files don't exist until the whole manifest makes it there, so there's some attempt at atomicity throughout the whole thing
[07:11] <stub> And it will barf if you provide an MD5 hash when uploading and it doesn't match, so I guess it must be buffered
[07:13]  * stub wonders about other edge cases, such as requesting a partially replicated file
[07:16] <stub> I think the client confirms the md5 when downloading, so that shouldn't matter.
[07:20] <wgrant> I'm pretty sure partial replication is impossible.
[07:20] <wgrant> It's certainly meant to be.
[09:55] <Laney> We have https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/1579712 going on currently, which makes 'apt update' hang
[09:55] <ubot5> Launchpad bug 1579712 in appstream (Ubuntu Xenial) "Refresh hangs indefinitely, appstreamcli using 100% CPU" [High,Fix released]
[09:55] <Laney> A backport that got published in xenial-backports/main has made it happen for ~everybody
[09:55] <Laney> I've just mitigated it by re-publishing the other components in xenial-backports
[09:55] <Laney> but the archive's not going to get it until a package is published there, is it?
[10:02] <wgrant> You've updated the appstream metadata in a way that fixes the hang, and now need the affected suites republished so they pick up the new metadata?
[10:04] <Laney> Yeah
[10:04] <Laney> I'm guessing that just having dep11 be newer isn't enough to get it republished
[10:13] <cjwatson> Laney: This is from memory, but I think it is in fact enough
[10:29] <Laney> cjwatson: 'k, guess we'll find out soon enough
[10:56] <Laney> cjwatson: your memory was correct, thanks
[19:01] <heydrick> i've been getting intermittent 503's from launchpad PPAs on a daily basis. where's the best place to report that?
[19:01] <teward> that'd be here I think
[19:09] <heydrick> i'm seeing this on the API https://launchpad.net/api/1.0. the client is requesting the signing_key_fingerprint
[19:09] <heydrick> that returns a 503 Service Temporarily Unavailable several times a day
[19:14] <dobey> you need to get the oops id from the http headers
[19:16] <heydrick> ok I will try to get that
[22:56] <heydrick> dobey: just got a bunch of 503's from the launchpad API. i don't see anything interesting in the headers
[22:57] <heydrick> happened between Fri, 20 May 2016 22:47:26 GMT and Fri, 20 May 2016 22:48:41
[22:57] <heydrick> anything interesting in the launchpad logs?
[22:58] <teward> heydrick: they can't find that without an OOPS code
[22:58] <teward> [2016-05-20 15:14:32] <dobey> you need to get the oops id from the http headers
[22:59] <teward> ^ as dobey said a while ago
[23:02] <heydrick> teward: there is no oops id in the headers
[23:04] <heydrick> the headers I get are:
[23:04] <heydrick> {'Content-Length': '742', 'Content-Encoding': 'gzip', 'Accept-Ranges': 'bytes', 'Vary': 'Accept-Encoding', 'Server': 'Apache', 'Last-Modified': 'Wed, 19 Nov 2014 16:06:07 GMT', 'Connection': 'close', 'ETag': '"6ca"', 'Date': 'Fri, 20 May 2016 22:48:41 GMT', 'Content-Type': 'text/html'}
=== nacc is now known as Guest64822
=== nacc_ is now known as nacc
=== JanC is now known as Guest59129
=== JanC_ is now known as JanC