[09:56] You get impressively confusing errors if you accidentally declare a field as allow_none=False, default=None [09:57] I mean, "NoneError: None isn't acceptable as a value" which is fair enough, but had to disable C extensions to figure out which column was involved ... [09:58] Could anyone review https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/380593 and https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/380594 please? [09:58] And maybe https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/380616 to remove some old bzr stuff we no longer need to carry around [09:59] wgrant: Is https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/380059 possibly something you need to look at? Removes the XPI importer, involved some moderately involved test rearrangements as a preliminary step [10:01] Also also, https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/380475 is a simple bug-fix [10:02] cjwatson: I don't necessarily think so, unless you do [10:04] OK, will see if I can find a vic^Wvolunteer [10:04] Translations is in a slightly weird position where changes aren't generally DB or security or anything like that but it's also the main bit that not even I know [10:42] https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/380594 (thanks ilasc for the review) was sort of amusing; I don't think I've ever seen pre-2.2 compat in the wild before [10:43] :) [10:43] Trying to remember whether I started learning Python at 2.3 or 2.4. I think it must have been 2.3 - I vaguely recall having to write compatibility code for set not being in the stdlib yet [10:44] Ah yes, https://launchpad.net/ubuntu/+source/python-defaults/+publishinghistory?batch=75&direction=backwards&start=150 says warty had 2.3 [10:45] (The dates are kind of lies there - even if you expand the bottom row, it only says 2005-12-20, which I presume was when warty was first imported into Launchpad; the first few Ubuntu releases ran on Debian's archive management code instead) [10:48] Oh wow, I'd forgotten about that [10:48] (First Python version for me was 1.5) [10:49] Ah yeah, you were writing linda back then weren't you? [10:51] Yup [10:51] We didn't even have list comprehensions! [10:53] uphill, both ways, in the snow [10:53] You, off my lawn :-P [12:26] Could I have a review of https://code.launchpad.net/~cjwatson/launchpad-mojo-specs/+git/launchpad-mojo-specs/+merge/380678 to fix a CI failure please? [12:26] For the YAML-lovers among you [12:29] :-) [12:29] on it [15:28] pappacena: I think you possibly forgot to push your allocation to lp:~launchpad/+junk/dbpatches ? [15:28] (for https://code.launchpad.net/~pappacena/launchpad/+git/launchpad/+merge/380254) [15:31] Ah, sadly, yes. I forgot. I am out for lunch now. I will do it as soon as I get back [15:37] np, just wanted to make sure it wasn't forgotten [17:28] Commited the allocation, cjwatson [17:28] (Or do we usually make MP for this too?) [17:30] No, just commit [17:31] Upgrading dogfood for your proxy change now. I might just about have time to help with a bit of QA there ... [17:31] Ok! Thanks! [17:49] pappacena: https://dogfood.launchpadlibrarian.net/412902206/mirrors.edge.kernel.org-archive-probe-logfile.txt looks good; lots of 404s but it's a partial mirror (and dogfood's DB is behind production, which also confounds things a bit) [17:50] pappacena: https://dogfood.launchpadlibrarian.net/412902207/mirror.cse.unsw.edu.au-release-probe-logfile.txt looks odd. Why is it apparently trying to talk to port 80? [17:50] uhm... really strange [17:52] let me see if I can find something on the code. I don't remember seeing any hardcoded port anywhere (the tests we have even open random ports for testing...) [17:53] Maybe something to do with _parse defaulting to 80? [17:53] I haven't worked out the relevant code paths though, will leave it to you [17:54] " _parse defaulting to 80?" it could be... I'm checking [18:02] Right, so for HTTPS we don't use _parse when doing the request (since treq receives the unparsed URL), but to show the error message we use parse. That's why it's showing port 80. I'll submit a MP to properly set the default port on _parse to 443 if scheme is https. [18:02] And it failed because this server doesn't seem to support TLS v1.1; only 1.2 and 1.3 [18:02] Aha [18:02] Is that due to old OpenSSL? [18:03] (I mean, the fact that we're demanding 1.1) [18:03] Or is it more in our control? We don't want to be discouraging 1.2+ [18:04] No specific reason for using 1.1... I neede to explicitly set the version, and I assumed the protocol would be backward compatible, but it seems that I'm wrong... [18:04] Oh, I'd missed that you set it explicitly [18:05] I think we should at least say 1.2, yes [18:05] Yep... I set it in a kind of hacky way, because Twisted has a kind of strange interface for the HTTPS policy. It's missing a method in the default "browser-like" policy, apparently... [18:05] `contextFactory.getContext = lambda: Context(TLSv1_1_METHOD)` [18:06] Yeah, I'm not totally familiar with that stuff [18:06] Me neither... I was fixing one exception at a time, until it eventually worked fine... :-( [18:07] :-) [18:07] I'll submit a MP upgrading this context to version 1.2 and "calculating" the port on _parse depending on the scheme in half an hour. I need to pick my daughter at school now. [18:08] Thanks. No great rush, I'm about to finish for the day [18:08] This looks like a good improvement so far [18:08] Well, at least is mostly working (and what is not working seems to be easily fixable) :-) [18:09] Yep [18:09] Haven't had time for the change-override-log re-reviews today as too much production debugging, but I have them open [18:09] No problem. I still need to fix the copied_from_archive with the previous feedbacks. [18:35] * cjwatson EODs, I'm not going to make significant progress on Built-Using at this point [18:36] Have a good weekend [18:37] Take care! [18:53] Have a good weekend!