| karstensrage | good luck cjwatson | 00:49 |
|---|---|---|
| cjwatson | s390x builders back up; took a bit longer than expected, but there were no builds to be delayed | 01: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. | 09:49 |
| === pkern_ is now known as pkern | ||
| pkern | Where could I file that problem? Answers? Bugs? | 11:16 |
| === JanC is now known as Guest23785 | ||
| === JanC_ is now known as JanC | ||
| cjwatson | pkern: Answers to start with, please | 11:27 |
| 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:32 |
| cjwatson | The one on ppa.launchpad.net is simply truncated | 11:34 |
| 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:38 |
| cjwatson | Oh for diskless PPAs ... | 11:39 |
| pkern | cjwatson: Filed it as https://answers.launchpad.net/launchpad/+question/293939 -- thanks. :) | 12:01 |
| 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:08 |
| 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:10 |
| cjwatson | It's not truncated at any sort of plausible boundary | 12:14 |
| cjwatson | And I see no dodgy exception handling on this path at the client end | 12:15 |
| wgrant | cjwatson: Have you checked the librarianserver swift stuff? | 12:52 |
| 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:53 |
| 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:56 |
| cjwatson | True. Also I'm not sure what in the client would crash; urllib2 doesn't check. | 12:57 |
| 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:58 |
| 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. | 12:59 |
| cjwatson | I'm not even very convinced that requests checks Content-Length. | 13:00 |
| wgrant | Seems weird. | 13:01 |
| 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:02 |
| 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:04 |
| 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:05 |
| cjwatson | I think. | 13:06 |
| cjwatson | librarianserver does seem to set the C-L. | 13:16 |
| cjwatson | (via twisted.web.static.File) | 13:16 |
| 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 | 17:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!