[21:06] <blr> cjwatson: thanks for those MPs, hope the charm wasn't too painful to work with.
[21:07] <cjwatson> Tolerable :)
[21:07] <cjwatson> More juju unfamiliarity than anything else.
[21:08] <cjwatson> There are one or two other things I'd like to fix up when I get a moment, but it's looking pretty close.  Did you get a stagingstack tenant?
[21:11] <thomi> hey cjwatson, I don't suppose you know where I can find buildbot logs for launchpad?
[21:12] <cjwatson> thomi: like http://lpbuildbot.canonical.com/waterfall ?
[21:12] <thomi> cjwatson: perfect - thanks!
[21:12] <cjwatson> n
[21:12] <cjwatson> p
[21:12] <cjwatson> maximal irc inefficiency, whee
[21:13] <thomi> heh
[21:13] <blr> cjwatson: see ops
[21:18] <thomi> cjwatson: hmmm, I'm really looking for the importfascist logs. I expected them to appear in the test stdout (as they do when running ./bin/test), but I don't see them there
[21:19] <cjwatson> that I don't know
[21:19] <cjwatson> the seven (I think) failures there have been there as long as I can remember though
[21:20] <thomi> yeah, I wont to see if I can fix at least one of them
[21:20] <thomi> but without a log of them.... and running the tests is slow :D
[21:20] <cjwatson> They show up even when running just a single test IIRC.
[21:20] <thomi> plus, I don't know how many tests to run before the message will be triggered
[21:20] <cjwatson> So just pick something and use -t.
[21:20] <thomi> ...oh
[21:20] <thomi> well, that'd be faster
[21:21] <thomi> hah - they get printed when you Ctrl+c a test run as well :D
[21:23] <cjwatson> Something in the unit test layer is quick enough, so say bin/test -vvct TestDpkgArchitectureCache.test_any
[21:55] <wgrant_> thomi: The importfascist isn't a test, as such.
[21:55] <wgrant> It's just an import wrapper which reports warnings, so any non-subunit bin/test invocation that imports the entire codebase (ie. pretty much anything without -m) will give you them all.
[21:58] <thomi> wgrant: ahh ok.
[21:58] <thomi> wgrant: if you upgraded to subunit v2 you could report that even on test results :D
[21:58] <thomi> actually, that's not strictly true
[22:05] <wgrant> blr: How'd you fix the routing issue?
[22:12] <blr> wgrant: oh, it was stupidly easy, a pyramid regex matcher works.
[22:14] <blr> e.g. {ref:.*}
[22:14] <wgrant> blr: I guess that's not a problem if there are no segments afterwards, true.
[22:14] <blr> yep, in that case the ref is always the last var to match
[22:15] <wgrant> :)
[22:15] <blr> always nice when things are easier than you anticipate.
[22:17] <blr> wgrant: thomi was showing me testtool's matchers this morning, it might be nice to have some custom matchers for git objects or ref collections
[22:18] <wgrant> blr: Yeah, that will make a lot of sense once we start introducing lots of functionality that writes to repos.
[22:38] <thomi> woooo! there's now only *6* import policy violations :D
[22:43] <wgrant> thomi: Yay!
[22:43] <wgrant> You worked out the ZCML etc?
[22:43] <thomi> wgrant: I think so. Just proposing a merge so you can tell me what I did wrong :D
[22:43] <wgrant> blr: What's left of the initial API server work?
[22:43] <thomi> then I'll feel more confident about handling the others
[22:44] <blr> wgrant: the hairy ones, diff and merge
[22:44] <blr> err diff and clone
[22:44] <blr> rather
[22:44] <wgrant> Yeah, they're not quite obvious. I suspect we'll need to redesign them a few times as their uses become clearer.
[22:45] <blr> was thinking I would start in on diff
[22:47] <wgrant> Yeah, diffing two specified commits directly is probably a good place to start. We'll work from there.
[22:48] <blr> that sounds sensible
[23:20] <wgrant> cjwatson: python-pygit2 doesn't seem to actually work for me without libgit2-dev and python-dev, and doesn't depend on them. Does that affect Debian too?
[23:20] <wgrant> oh derp
[23:21] <wgrant> I was trying to import it while inside a clone of it.
[23:21] <thomi> wgrant: any chance I could get some feedback on https://code.launchpad.net/~thomir/launchpad/devel-fix-import-violations-specificationworkitem/+merge/251395 please?
[23:22] <wgrant> thomi: Ah, looked before but it had no diff.
[23:22] <thomi> wgrant: yeah, I had to poke the branch scanner a few times :(
[23:22] <wgrant> 'tis Monday :(
[23:22] <thomi> I thought that'd make it better though
[23:22] <thomi> Monday == few users?
[23:23] <wgrant> Monday == 48 hours of no LP branch pushes, so caches get cold.
[23:24] <wgrant> thomi: Any chance of a quick test of that new method?
[23:24] <thomi> wgrant: on the *Set class?
[23:24] <thomi> good idea..
[23:25] <wgrant> Yep
[23:49] <blr> wgrant: thanks for the review, will tidy that up.
[23:50] <wgrant> blr: I hunted around for a built-in pygit2 map of object types to their normal identifiers, but I couldn't find one.
[23:50] <wgrant> Other than, like, using obj.__class__.__name__.lower()
[23:50] <blr> wgrant: I know, weird eh, I did the same
[23:50] <blr> wgrant: was thinking I should send them a pull request for that.
[23:51] <wgrant> We're gooing to need to do a bit of that, particularly around MPs.
[23:51] <wgrant> There are features in libgit2 that they've wrapped too deeply.
[23:51] <blr> yeah, some of the library doesn't strike me as very pythonic.
[23:53] <wgrant> It's better than it was 18 months ago.
[23:54] <wgrant> thomi: I'd create say three workitems, two with one milestone and one with another, then unlinkMilestone(milestone_with_two_items) and assert that all three now have the correct state.
[23:55] <wgrant> 'cause that test is passed by a trivial "UPDATE specificationworkitem SET milestone = NULL" :)
[23:55] <wgrant> Also, we normally use assertIs with None, though it doesn't matter on CPython.
[23:55] <thomi> wgrant: good point - changing now...
[23:56] <wgrant> thomi: Fortunately the factory makes that quite painless.
[23:56] <thomi> yeah :D
[23:57] <wgrant> You'll see a lot of older tests do awkward stuff or use sampledata when they could easily use the factory. It's always appropriate to fix those in a driveby if you feel the need.
[23:57] <thomi> wgrant: do you mind the asserts that ensure that the factory created things correctly? I add them to assure myself that it's doing what I think it is, and I'm never sure if I should remove them afterwards or not...
[23:58] <thomi> I like the kind of "asserts to demonstrate prior state > ACTION > asserts to demonstrate resulting state" pattern
[23:59] <wgrant> thomi: No, I usually do that myself.