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