[00:49] <karstensrage> good luck cjwatson
[01:49] <cjwatson> s390x builders back up; took a bit longer than expected, but there were no builds to be delayed
[09:49] <pkern_> Hi. I see a hash mismatch in a PPA: http://ppa.launchpad.net/canonical-kernel-team/ppa/ubuntu/pool/main/l/linux-lts-xenial/kernel-image-4.4.0-23-generic-di_4.4.0-23.41~14.04.1_amd64.udeb has a md5sum of 181736d1600569ed755b8b6236f1d60a, but it's refered to by debian-installer/binary-amd64/Packages.gz as 8b505d2bae4eed89d0f026b56bf5cd9b.
[11:16] <pkern> Where could I file that problem? Answers? Bugs?
[11:27] <cjwatson> pkern: Answers to start with, please
[11:32] <cjwatson> https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa/+files/kernel-image-4.4.0-23-generic-di_4.4.0-23.41~14.04.1_amd64.udeb has the correct version
[11:34] <cjwatson> The one on ppa.launchpad.net is simply truncated
[11:38] <cjwatson> Absolutely no indication of a problem in the publisher log, which is pretty worrying!
[11:38] <cjwatson> 2016-05-18 21:09:02 DEBUG   Added /srv/launchpad.net/ppa-archive/canonical-kernel-team/ppa/ubuntu/pool/main/l/linux-lts-xenial/kernel-image-4.4.0-23-generic-di_4.4.0-23.41~14.04.1_amd64.udeb from library
[11:38] <cjwatson> wgrant: ^-
[11:39] <cjwatson> Oh for diskless PPAs ...
[12:01] <pkern> cjwatson: Filed it as https://answers.launchpad.net/launchpad/+question/293939 -- thanks. :)
[12:08] <wgrant> cjwatson: Ugh, that happened to a file in the primary archive earlier. acamar was being pretty slow, so I wonder if something timed out but didn't notice.
[12:10] <cjwatson> Two worrying things here: (a) I can't think of a straightforward recovery path other than asking a webop to manually put the correct file in place (b) this suggests a rather foundational bug somewhere
[12:14] <cjwatson> It's not truncated at any sort of plausible boundary
[12:15] <cjwatson> And I see no dodgy exception handling on this path at the client end
[12:52] <wgrant> cjwatson: Have you checked the librarianserver swift stuff?
[12:53] <wgrant> Hopefully we're sending Content-Length from the librarian based on the DB, and clients should crash if the actual content is shorter, but that might not be the case.
[12:56] <cjwatson> The only hit for Content-Length in librarianserver is for uploading to swift.  "curl -I https://launchpadlibrarian.net/260241833/kernel-image-4.4.0-23-generic-di_4.4.0-23.41~14.04.1_amd64.udeb" shows a correct Content-Length though.
[12:56] <wgrant> It does now.
[12:56] <wgrant> But it could have shown a wrong one before, or it could be constructed by squid or apache.
[12:57] <cjwatson> True.  Also I'm not sure what in the client would crash; urllib2 doesn't check.
[12:58] <wgrant> Really?
[12:58] <cjwatson> httplib might though.
[12:58] <cjwatson> Or not.
[12:58] <cjwatson>         if not s and amt:
[12:58] <cjwatson>             # Ideally, we would raise IncompleteRead if the content-length
[12:58] <cjwatson>             # wasn't satisfied, but it might break compatibility.
[12:58] <cjwatson>             self.close()
[12:59] <wgrant> Unless you're using CTE: chunked, surely it has to complain, or a connection closed early will result in a truncated read.
[12:59] <wgrant> hah
[12:59] <wgrant> well then.
[12:59] <cjwatson> We might have multiple bugs.
[13:00] <cjwatson> I'm not even very convinced that requests checks Content-Length.
[13:01] <wgrant> Seems weird.
[13:02] <cjwatson> Surely every client can't be supposed to check?
[13:02] <wgrant> chunked and Content-Length both allow verification that the whole response was received. Seems sort of unbelievable that clients wouldn't do that by default.
[13:04] <cjwatson> It looks like httplib checks the length if you're doing an unbounded read, but not if you're reading in chunks.  If I'm reading this right.
[13:05] <cjwatson> Or rather, it checks in the actual C-T-E: chunked case, but not if you're doing bounded reads from a non-chunked resource.
[13:06] <cjwatson> I think.
[13:16] <cjwatson> librarianserver does seem to set the C-L.
[13:16] <cjwatson> (via twisted.web.static.File)
[17:50] <nacc> in, e.g., https://launchpad.net/ubuntu/+source/hello/+publishinghistory, what is the launchpadlib API to get to the original published date for 2.8-2 in raring? it is no longer published anywhere, so https://launchpad.net/ubuntu/+source/hello/2.8-2 indicates no publishing information and there is no longer a published_date field available?
[17:50] <nacc> there is a deleted_date, but I'm more interested in the original published date