[16:00] <tomwardill> surprise, it's iptables!
[16:01] <SpecialK|Canon> lol
[16:18] <tomwardill> \\ø/ finally done it
[16:18] <tomwardill> for future travellers: lxd has a defualt forward accept policy that deliberatly preceeds ufw rules
[16:20] <tomwardill> which is obvious, in retrospect
[16:21] <SpecialK|Canon> nicely found
[16:22] <SpecialK|Canon> most things are obvious in retrospect - that's how retrospect works ;)
[16:22] <tomwardill> iptables -S shows the FORWARD rules, which are higher in the list than the ufw ones
[16:23] <tomwardill> `lxc network set lxdbr0 ipv4.routing false` will change it to a DENY
[16:23] <tomwardill> or you can manually delete the rules
[16:23] <tomwardill> I think there's config somewhere, but not found it yet
[17:14] <cjwatson> Sigh, first breezy regression (issue with inline comments containing unicode)
[17:15] <cjwatson> Well not a regression in breezy itself, regression caused by a bit of my port
[17:19] <tomwardill> Build log: sendto(ntp.buildd): Operation not permitted
[17:19]  * tomwardill gradually finds all the things that are now failing
[17:22] <cjwatson> tomwardill: I usually set "ntphost =" in /etc/launchpad-buildd/default for a local builder
[17:22] <cjwatson> Since you probably don't have an ntp.buildd anyway
[17:22] <tomwardill> I just /etc/host'd it to ntp.ubuntu.com
[17:22] <cjwatson> Can't be proxied though
[17:23] <cjwatson> So either allow it or change config to not use it
[17:23] <tomwardill> yeah, I've also allowed it in ufw
[17:42] <cjwatson> Aha, tests didn't catch this because they tried to use \u inside a str
[17:42] <cjwatson> Python 2 string (bytes) literal that is
[17:42] <cjwatson> Where \u1234 corresponds to the bytes \ u 1 2 3 4
[17:44] <SpecialK|Canon> I...yikes
[17:44] <cjwatson> Nice landmine
[17:52] <cjwatson> https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378414
[17:57]  * SpecialK|Canon does some obligatory Hypothesis flag-waving
[17:58] <cjwatson> I've occasionally thought about it, yes.  Would need to take some care to apply it only to true unit tests though - it would probably get prohibitively slow for anything that talks to the database
[17:59] <SpecialK|Canon> Oh absolutely
[17:59] <tomwardill> Temporary failure resolving 'archive.ubuntu.com'
[17:59] <tomwardill> no.
[17:59] <tomwardill> networks.
[17:59] <SpecialK|Canon> hugops
[17:59] <tomwardill> stop it.
[17:59] <cjwatson> (Well, maybe.  If the database tests were in the happy path that can just ROLLBACK between tests rather than having to clone a fresh template then maybe.
[17:59] <cjwatson> )
[17:59] <cjwatson> .oO( PITR for the test suite )
[18:00] <SpecialK|Canon> ooh
[18:00] <cjwatson> Would that work I wonder?  I don't know enough about how PITR works
[18:01] <SpecialK|Canon> I only know of it as a concept (so sure, if we can, then yay) but it sounds like you're thinking of a specific impl?
[18:02] <cjwatson> Probably not actually faster though.  I think if you're doing PITR then you have to replay WAL forwards, not backwards
[18:03] <cjwatson> So the situation that requires cloning a fresh template is when a test has committed a transaction, since then you can't just roll back to get to a clean state
[18:04]  * tomwardill -> EOD to somewhere that doesn't involve computers :)
[18:04] <cjwatson> If we could rewind time using WAL on disk then that would be faster
[18:04] <cjwatson> But I think that isn't really how it works, sadly
[18:09] <SpecialK|Canon> something something time travel something
[18:11] <cjwatson> https://www.postgresql.org/docs/10/app-pgrewind.html is a thing ...
[18:12] <cjwatson> May be worth experimenting at some point to see if it's faster
[18:27] <SpecialK|Canon> Will have a read next week - sounds neat!
[18:27]  * SpecialK|Canon EOWs, take care y'all
[18:31] <pappacena> See ya, Kristian
[19:23] <roadmr> SpecialK|Canon ????