[00:49] good luck cjwatson [01:49] s390x builders back up; took a bit longer than expected, but there were no builds to be delayed [09:49] 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. === pkern_ is now known as pkern [11:16] Where could I file that problem? Answers? Bugs? === JanC is now known as Guest23785 === JanC_ is now known as JanC [11:27] pkern: Answers to start with, please [11:32] 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] The one on ppa.launchpad.net is simply truncated [11:38] Absolutely no indication of a problem in the publisher log, which is pretty worrying! [11:38] 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] wgrant: ^- [11:39] Oh for diskless PPAs ... [12:01] cjwatson: Filed it as https://answers.launchpad.net/launchpad/+question/293939 -- thanks. :) [12:08] 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] 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] It's not truncated at any sort of plausible boundary [12:15] And I see no dodgy exception handling on this path at the client end [12:52] cjwatson: Have you checked the librarianserver swift stuff? [12:53] 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] 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] It does now. [12:56] But it could have shown a wrong one before, or it could be constructed by squid or apache. [12:57] True. Also I'm not sure what in the client would crash; urllib2 doesn't check. [12:58] Really? [12:58] httplib might though. [12:58] Or not. [12:58] if not s and amt: [12:58] # Ideally, we would raise IncompleteRead if the content-length [12:58] # wasn't satisfied, but it might break compatibility. [12:58] self.close() [12:59] Unless you're using CTE: chunked, surely it has to complain, or a connection closed early will result in a truncated read. [12:59] hah [12:59] well then. [12:59] We might have multiple bugs. [13:00] I'm not even very convinced that requests checks Content-Length. [13:01] Seems weird. [13:02] Surely every client can't be supposed to check? [13:02] 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] 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] 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] I think. [13:16] librarianserver does seem to set the C-L. [13:16] (via twisted.web.static.File) [17:50] 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] there is a deleted_date, but I'm more interested in the original published date