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