[10:57] cjwatson: Why "except Exception" in merge-conflicts? [11:04] wgrant: Because pygit2 can raise a cluster of exceptions and I can't think of a better response to any of them than just leaving the file in a dodgy unresolved conflicted state. Although I guess we could just decline to handle that exception at all and let it 500. [11:05] cjwatson: Crashing rather than giving a bogus diff seems reasonable to me, unless we discover otherwise later on. [11:06] OK, done. [11:11] Hm. It's a bug that PreviewDiff.fromBranchMergeProposal doesn't set preview.prerequisite_revision_id, isn't it? [11:12] Quite likely. [11:12] Seems like that means that we won't notice when a preview diff is stale due to a changed prereq. [11:12] Well, we don't consider diffs stale unless the source branch has changed, usually. [11:14] I'm not actually sure stale affects anything much anyway ... [11:14] The comments claim there's a stale-diff CSS class, but that's never set by anything. [11:15] And I don't think whatever updates preview diffs has much to do with the stale property definition per se. [11:15] It may have been more relevant in the MAD days. [11:15] MAD? [11:15] Merge Analysis Daemon [11:15] From the good old days when you had to run a script to generate preview diffs yourself because reasons. [11:15] I don't remember that. [11:16] 2008ish, I think. [12:34] wgrant: I think that https://code.launchpad.net/~cjwatson/rabbitfixture/work-around-stop-hang/+merge/257361 should work around quite a few of the pesky buildbot hangs, although we'd need to reclaim PyPI access. [12:52] cjwatson: Bah, I thought I'd caught all those packages apart from sidnei's. [12:53] bac: ^^ can we have rabbitfixture PyPI access? [12:56] wgrant: you want access to rabbitfixture on pypi? what account? [12:56] wgrant: i had no idea i had access but i'm glad to add you. [12:57] bac: wgrant and cjwatson, pls. [12:58] okey doke. [12:59] bac: Thanks. [13:01] wgrant: Ta. subprocess32 was a nice discovery. [13:01] I had no idea of it. [13:13] wgrant: are lazr.* & launchpadlib reclaimed as well? [13:13] * xnox wants to release those on pypi [13:13] xnox: Yes, I have access to all lazr packages except two that nobody cares about. [13:13] Yell if you want some. [13:13] * xnox checks which ones i care about [13:15] lazr.restful, lazr.restfulclient, launchpadlib, lazr.delegates, lazr.authentication - you seemed to have access to all of them [13:15] * xnox never did pypi releases [13:15] so I'll ping you to do some of them ;-) [13:15] unless it's automated [13:15] twine IYF [13:16] gpg --armor -b dist/foo.tar.gz && twine upload dist/foo.tar.gz{,.asc} [13:18] assuming you already have a suitable .pypirc [13:24] Right, rabbitfixture upgrade landing in devel, so hopefully that's the end of the spurious hangs. [13:24] At least that relatively common species of them. [14:37] wgrant: Have you had a chance to try out mojo locally recently? [14:40] cjwatson: I like having my containers working. [14:40] So no mojo since I left home; juju 1.23 is iffy enough [14:40] Mm, I was trying to do the apache2/haproxy unhulksmashing task, but it's pretty tough to do blind ... [14:40] cjwatson: Does it not work? [14:40] Ah yeah [14:41] Well I never solved the problem I had last Saturday. [14:41] Was that the share-netns? [14:41] Yeah [14:42] Let's see if I can make it work ish. [14:42] Hm. Do we actually need apache2 at all if haproxy is doing SSL termination, I wonder? [14:42] All it's doing is logging, proxying to turnip, and getting in the way [14:43] (I ask because the stock apache2 charm doesn't support the relation stuff it'd need to be frontended by haproxy) [14:43] We don't currently make much use of it, indeed. [14:43] I suspect that we will in future, but it could be removed for now if it's awkward. [14:44] What for? Routing hacks or something? [14:46] Or serving any static content, redirecting / rather than returning uselessness, etc. [14:49] It'd be tempting to just do that in turnip directly. [14:49] We already have a few static bits there for cgit. [14:49] (Which, OK, are kind of in the wrong place but it shows it's not hard) [14:49] Heh [14:49] Sure. [15:15] The HTTP -> HTTPS redirection is reasonably easy with haproxy 1.5. [15:16] orly [15:16] I'm used to LP's haproxy which requires error pages to include HTTP headers... [15:16] "redirect scheme https code 301 if !{ ssl_fc }" [15:17] I think the only difficult bit is that we probably have to change the charm and the spec at once due to using relation-driven proxying, unless perhaps we add something to turnip's config.yaml to let it know whether it's being frontended directly by a modern haproxy [15:17] (Because then haproxy has to listen on ports 80/443, not the same ports as turnip) [15:19] I'm not sure that using sensible relations here is sensible. [15:19] But do what seems sensible. [15:19] Thanks for the detailed advice. :P [15:20] I don't know. Could put the redirect bit directly in the spec, but there isn't really a good way to override the smart-http port at spec level AFAICS. [15:20] Thinking of something like http://paste.ubuntu.com/10879298/ [15:21] ew [15:21] But that would indeed work, I think. [15:21] It's kind of weird to have this in turnip. [15:21] The lack of relation config bites us again [15:22] I guess an alternative is to put the 80/443 logic in the spec and have haproxy proxy to itself [15:22] So haproxy:443 -> haproxy:9419 -> turnip:9419 [15:22] (Which I'm assuming one can do, but it's kind of shuffling bytes around for no production benefit) [21:44] Seriously? My random-buildbot-hang fix has failed buildbot twice in succession with different random errors? [21:44] buildbot has a sense of humour. [21:46] It certainly does. [21:53] Now it's failing in a different bit of rabbitfixture, but it doesn't look related [21:53] Must do something about attaching that log as a test detail