[00:55] <sinzui> StevenK, I am tempted to write a an enum class that is feature flag aware, but I see your vocab is pretty complicated...have you explored removing the only two asserts in our code? i do not see why the vocabs have to be enums
[01:00] <sinzui> StevenK, I do not see why LaunchpadRadioWidgetWithDescription need to be IEnumeratedType, maybe we can make an exception for the special voab
[01:00] <sinzui> vocab
[01:02] <sinzui> EnumChoiceWidget's might also get an exception to the rule because it passes to vocabulary_to_choice_edit_items which  can take extra functions to render the items.
[01:11] <StevenK> sinzui: And here I was thinking the vocab was simple-ish
[01:12] <StevenK> sinzui: I hadn't thought about changing itemwidget, TBH.
[01:15] <sinzui> I am thinking with it. I still do not see what it needs...it is not calling any of the four attrs that IEnumeratedType define :(
[01:19] <StevenK> sinzui: I'm currently knee-deep in tests for the next pipe, are you trying, or do you want me to dump state and look with you?
[01:20] <sinzui> I am playing with it. Don't loose focus
[01:21] <StevenK> wgrant: Can you join #ubuntu-arm on freenode?
[01:22] <StevenK> wgrant: Unping
[01:23] <wgrant> StevenK: I was there already, just noticed slightly too late :)
[01:23] <StevenK> No ubuntu/member for me :-/
[01:24] <wgrant> Odd
[01:24]  * StevenK stabs official_malone
[01:40]  * StevenK tries to work out how to get the bug that was just filed from the +filebug view
[01:40] <StevenK> (In a test, so I have a initialized view)
[01:44] <wgrant> StevenK: It should have returned a redirect to it
[01:46] <StevenK> Oh, I have to call the view
[01:53] <StevenK> wgrant: It does indeed.
[02:36] <sinzui> StevenK, Here is your fix in as few lines as possible: http://pastebin.ubuntu.com/936319/
[02:39] <sinzui> StevenK, There were three things that needed consideration: 1. Enums are classes that act like instances...they do not need to be instantiated. 2. vocabularies are either instantiated by you, or you register a factory in zcml to do it for you. 3. The test was passing what the user sees, not what the browser posts, so the form always has errors that were not checked
[02:39]  * sinzui tends to children
[02:48] <StevenK> sinzui: Thanks, that's awesome
[02:59] <StevenK> wgrant: Have you seen anything like http://pastebin.ubuntu.com/936341/ ?
[03:03] <wgrant> StevenK: data is None
[03:04] <wgrant> StevenK, wallyworld: https://code.launchpad.net/~wgrant/launchpad/bugtaskflat-search-3/+merge/102615
[03:05] <StevenK> wgrant: Yeah, looks like zope does not love it when initial_values returns None
[03:05]  * wallyworld looking
[03:06] <wgrant> wallyworld: Thanks.
[03:06] <wgrant> StevenK: Yeah, should probably return {}
[03:06] <StevenK> wallyworld: Thanks, I'm trying to polish off this branch before lunch.
[03:06] <wallyworld> np
[03:18] <wallyworld> wgrant: 'BugTaskFlat.information_type IN (1, 2)' - can we use enum.value here instead
[03:19] <wallyworld> wgrant: also, i'm not sure we should turn on the ff if assignees cannot see their bugs. is it intended this will be fixed before we turn this on?
[03:20] <wgrant> wallyworld: It's probably a misfeature that has been deliberately used about twice ever.
[03:20] <wgrant> I don't consider it to be a significant concern. It's not documented anywhere.
[03:21] <wgrant> wallyworld: And yes, I meant to fix that enum thing but forgot.
[03:21]  * wgrant fixes.
[03:21] <wallyworld> wgrant: i think assignees should be able to see all the bugs assigned to them. what am i missing?
[03:22] <wgrant> wallyworld: Documentation and history says that you can tell who has access to a bug by looking at the subscriber list.
[03:23] <wallyworld> what do we indent to do when someone assigns a user to a bug but that user cannot see it?
[03:23] <wgrant> Same as we did until 6 months ago.
[03:23] <wgrant> They can't see it.
[03:23] <wgrant> Until we make these rules consistent, so assignment requires a grant.
[03:23] <wallyworld> that sucks
[03:24] <wgrant> Rather than what it does now: exist as a horrible undocumented special case that kills performance
[03:24] <wallyworld> we should automatically create a grant then
[03:24] <wgrant> Yes.
[03:24] <wgrant> That's the intention.
[03:24] <lifeless> wallyworld: we should have visibility and assignment matched
[03:25] <wgrant> But it's going to be far far easier to do that once we've made bug visibility not insane.
[03:25] <lifeless> wallyworld: however, its better, I think, to special case assignment (force unassigns) than to special case visibility
[03:25] <wallyworld> sure. my concern was reverting the existing behaviour ie taking something away that's now there
[03:26] <wgrant> It's existing undocumented inconsistent behaviour.
[03:26] <wgrant> That isn't fully implemented.
[03:26] <lifeless> wgrant: you may find http://vimeo.com/2723800 interesting
[03:26] <wallyworld> but there could be people who are working on bugs that all of a sudden they can't see
[03:26] <lifeless> their supervisors can fix that
[03:27] <wgrant> There's going to be a bit of that at various points throughout the migration.
[03:27] <wgrant> It's unfortunate, but I'm not sure it's worth working around it.
[03:27] <wgrant> We can check how many cases there are.
[03:27] <wgrant> My guess is "not many at all"
[03:27] <wgrant> And most of the cases that do exist will be unintentional leaks/
[03:28] <wallyworld> hmmm. alright. my objections have been raised. we'll see what happens
[03:29] <wallyworld> i wouldn't have said anything if the behaviour wasn't there and we weren't removing it all of a sudden
[03:29] <wgrant> This behaviour has an interesting history.
[03:29] <wgrant> For several months it was partially implemented.
[03:29] <wgrant> You could see the bugs in listings.
[03:29] <wgrant> But the bug page would OOPS
[03:29] <wgrant> We had a total of two bugs filed about that.
[03:29] <wallyworld> sure, but now it's fixed and people may rely on it
[03:29] <wgrant> Then for a while the bug page would render, but had no tasks.
[03:29] <wgrant> We had one bug about that.
[03:29] <lifeless> wgrant: you could add grants for all current non-accessible asasignees
[03:29] <wgrant> Then a few months ago it was fixed properly and we didn't tell anyone.
[03:30] <wgrant> lifeless: I could, but that makes the temporary mirroring triggers slower and more complicated.
[03:30] <lifeless> wgrant: nono
[03:30] <lifeless> wgrant: so, a) make assigning add a grant if the person doesn't already have access
[03:30] <lifeless> b) do a one-off check and add
[03:30] <lifeless> c) profit
[03:31] <wgrant> That's the final solution.
[03:31] <wgrant> Could add a *subscription* now.
[03:31] <wgrant> But can't add a grant directly.
[03:31] <lifeless> what stops it being used now ?
[03:31] <lifeless> isn't the schema live?
[03:31] <wgrant> It is.
[03:31] <wgrant> But the mirror triggers own all grants related to bugs.
[03:31] <lifeless> so what stops that solution being used now ?
[03:31] <wgrant> Every time the bug is touched, they will force the mirrored data into compliance.
[03:31] <wgrant> ie. delete the manual assignee grants
[03:31] <lifeless> ah
[03:31] <lifeless> kk
[03:32] <wgrant> (bugtaskflat's triggers are permanent, so they're a bit more selective. but the legacy mirroring stuff is not)
[03:38] <wgrant> erm
[03:38] <wgrant> https://lpstats.canonical.com/graphs/PPR/
[03:41] <lifeless> yay registry
[03:43] <wgrant> :)
[03:45] <wgrant> Hmm
[03:45] <wgrant> I might delete 2/3 of the bug search tests, I think
[03:45] <wgrant> Or 7/8, even
[04:15] <mwhudson> lifeless: the main lesson from that zed shaw talk is "i'm very glad i work for canonical"
[04:15] <wgrant> Yep
[04:15] <mwhudson> much as the main lesson from "release it" is "i'm glad i don't program in java"
[04:23] <nigelb> mwhudson: where was this talk? Video or in person?
[04:23] <mwhudson> nigelb: video, lifeless posted a link
[04:23] <lifeless> mwhudson: hah
 wgrant: you may find http://vimeo.com/2723800 interesting
[04:23] <lifeless> mwhudson: release spends -maybe- 10% on java disfunction
[04:24] <lifeless> mwhudson: as for that talk, the discussion on addressing acls was why I linked it
[04:24] <mwhudson> lifeless: yeah, but all the case studies were "this external service fell over and our thread pool ran out of threads and everything gummed up"
[04:24] <mwhudson> or at least, enough of them were that it made quite an impression
[04:24] <mwhudson> re: acls, yes, i realize
[04:24] <lifeless> mwhudson: applies to non-java, applies to non-java
[04:26] <nigelb> mwhudson: thanks :)
[04:27] <mwhudson> lifeless: sure, to a large extent
[04:27] <lifeless> mwhudson: e.g. blog.launchpad.net failing, and the concurrency limit we hit in one of the twisted services a while back
[04:28] <nigelb> bah. 1 hour talk. My connection is being throtled this week :/
[04:29] <mwhudson> nigelb: it's not /amazingly/ interesting, i'd say
[04:29] <lifeless> moderately entertaining
[04:29] <lifeless> about a 1/2 page on how to do scalable things that look a bit like ACLs
[04:29] <lifeless> which has some relevance to the work purple are doing
[04:29] <nigelb> Interesting. I'll queue it up for next week when I'm slated to do some boring stuff.
[04:30] <spm> o/ nigelb
[04:30] <lifeless> nigelb: moved yet ?
[04:30] <nigelb> Evening spm o/
[04:30] <nigelb> lifeless: Nope. Just send in all the documents to the consultant.
[04:30] <nigelb> Another 8 to 12 weeks at least :(
[04:31] <nigelb> lifeless: I hear you'll be keynoting at kiwipycon? :)
[04:32] <StevenK> Sigh. That vimeo video isn't available for download.
[04:33] <mwhudson> nigelb: where are you (trying to?) moving to?
[04:33] <nigelb> mwhudson: Near you! (sory of) Auckland.
[04:33] <nigelb> *sort of
[04:33] <lifeless> nigelb: yes, I should get onto my talk
[04:33] <mwhudson> ah heh
[04:33] <mwhudson> nigelb: nice :)
[04:33] <nigelb> :)
[04:34] <nigelb> lifeless: \o/ Hopefully, I can make it :)
[04:37] <StevenK> wgrant: I'm getting a failure in xx-bug-privacy.txt with - Mark Shuttleworth (Unsubscribe), is that related to jcsackett's change?
[04:39] <wgrant> StevenK: Yes
[04:39] <wgrant> StevenK: That rev is reverted now
[04:42] <StevenK> wgrant: Excellent.
[04:43] <StevenK> Hmmm, the feature flags don't seem to impact the vocab :-(
[04:45]  * StevenK blames the class-inside-another-class definition
[04:48] <wgrant> StevenK: When is the flag evaluated?
[04:58] <StevenK> wgrant: In __init__ of the vocab
[05:01] <wgrant> That's where
[05:01] <wgrant> When is the vocab instantiated?
[05:02] <StevenK> wgrant: In the class information_type_schema in BugSecrecyEditView
[05:03] <wgrant> Is the class defined directly inside BugSecrecyEditView, not in a method?
[05:03] <StevenK> wgrant: Yes
[05:03] <wgrant> Remember that the class body is executed immediately.
[05:03] <StevenK> I had inside the schema method, and you said it could be outside.
[05:03]  * StevenK moves it back
[05:04] <wgrant> Not if you're evaluating the flag in the class definition.
[05:04] <wgrant> My statement yesterday relied on the flag being used to select a class.
[05:04] <StevenK> It's okay, I wrote a test for it.
[05:06] <StevenK> wgrant: I'm more comfortable about the vocab use that I have a test for all 3 feature flags.
[05:16] <StevenK> wgrant, wallyworld: https://code.launchpad.net/~stevenk/launchpad/bugs-information_type-ui-secrecy/+merge/102624
[05:16] <StevenK> Finally!
[05:17] <StevenK> What the hell? I've managed to create 3 MPs?
[05:17] <StevenK> This button down thing is idiotic
[05:27]  * wallyworld looks
[05:28] <StevenK> wallyworld: Thanks.
[05:36] <wallyworld> StevenK: self.assertIn('Private', html) etc - i think that's too generic. can we use BeautifulSoup and search for a tag with content
[05:37] <StevenK> wallyworld: Sure, with the slight problem that I think BeautifulSoup is terrible. :-)
[05:37] <wgrant> It can't be terrible!
[05:37] <wallyworld> it's all we have though
[05:37] <wgrant> We only have 4 copies of it.
[05:37] <StevenK> Where are the 4?
[05:38] <wgrant> lib/, we used to have an egg (possibly not any more), the system one, and one in mechanize.
[05:38] <StevenK> Why it is in lib? :-(
[05:38] <wgrant> Because someone is strange.
[05:42] <StevenK> I'm tempted to remove it in a different branch, toss it at ec2 and see what happens.
[05:43] <StevenK> wallyworld: Do you have any other comments while I work out HTF to use BeautifulSoup?
[05:44] <wallyworld> StevenK: no, looks pretty good. the only other nitpicky thing is i would define a string constant for the ff names but i was going to ignore that
[05:45] <StevenK> wallyworld: I'm hoping the flags are short lived.
[05:45] <wallyworld> yeah, me too :-)
[05:45] <wallyworld> so don't do anything
[05:48] <wgrant> Anyone up for reducing some test coverage? :)
[05:49] <StevenK> ... and doing what?
[05:49] <StevenK> wallyworld: Does you approve? http://pastebin.ubuntu.com/936472/
[05:49]  * wallyworld looks
[05:50] <wallyworld> StevenK: i think you should be able to use find() and compare to None or a single object rather than a list
[05:52] <StevenK> wallyworld: http://pastebin.ubuntu.com/936477/
[05:53] <wallyworld> StevenK: looks ok, thanks for doing the change
[05:53] <wgrant> https://code.launchpad.net/~wgrant/launchpad/trim-bugtask-search-tests/+merge/102628 is a pretty simple one if someone has a sec
[05:54] <StevenK> At +180/-161 ?
[05:54] <wgrant> Mostly moved tests
[05:55] <wgrant> The real diff is about 40 lines
[05:55] <wgrant> Everything else is just splitting one base class into two.
[05:55] <wgrant> With no code changes.
[05:56] <StevenK> wgrant: r=me
[05:57] <wgrant> Thanks.
[05:57] <wgrant> Tomorrow I'll cut it by another 60% :)
[06:00] <StevenK> wallyworld: Can haz approve?
[06:00] <wallyworld> diff there? let me look
[06:00] <StevenK> wallyworld: Yes, it's updated.
[06:01] <wallyworld> it's been really slow of late
[06:01] <StevenK> It did the initial diff very quick
[06:02] <StevenK> I'm still slightly annoyed that I somehow managed to create 3 MPs
[06:02] <wallyworld> i reckon my last few mps have taken aaaaggges
[06:02] <wallyworld> r=me anyway
[06:07] <StevenK> wallyworld: Are the changes in http://pastebin.ubuntu.com/936490/ actually testable?
[06:08] <wallyworld> StevenK: for starters i'd move all the js to a yui module and out of the tal
[06:09] <wallyworld> then you may be able to test something
[06:09] <wallyworld> otherwise no
[06:09] <wallyworld> what i've seen done (/me shudders) is to test that the tal/generated html contains a specific js snippet
[06:10] <wallyworld> but, ew
[06:10] <wgrant> That makes people like me very sad :)
[06:10] <wallyworld> yep, me too :-(
[06:10] <StevenK> wallyworld: It deserves a large refactor, but I don't want to do it now.
[06:11] <StevenK> The filebug macros template is disgusting
[06:11] <wallyworld> StevenK: sure, but at least put the js in a js file
[06:11] <wallyworld> even if no tests are added etc
[06:11] <StevenK> wallyworld: Sorry, but I don't want to. Bug:+filebug is a house of cards on a bed of quicksand.
[06:12] <wallyworld> ok, you're the one doing the work so i can't make you :-)
[06:12] <wallyworld> i would have
[06:12] <wallyworld> better get it done before tomorrow when i'm ocr :-P
[06:14] <StevenK> Hah
[06:18] <wallyworld> StevenK: i'm putting up a branch which fixes those DBType JSON errors so hopefully those oops will disappear soon. gotta get the new lazr.json code reviewed also so it won't hit prod till next week
[06:19] <StevenK> \o/
[07:53] <adeuring> good morning
[08:03] <StevenK> Hmm, where am I supposed to get rabbitmq-server 2.6.1?
[08:15] <lifeless> 2.7.1?
[08:24] <czajkowski> morning all
[08:26] <czajkowski> lifeless: the blessed juju charm bug is back - https://bugs.launchpad.net/launchpad/+bug/983530
[08:26] <_mup_> Bug #983530: "charms" needs branch name consistency <juju:Invalid> <Launchpad itself:New> < https://launchpad.net/bugs/983530 >
[08:51] <maxb> czajkowski: But we've got ~6 months before anyone needs to run branch-distro again, so no rush :-)
[08:52] <StevenK> Unlikely
[08:52] <maxb> ?
[08:53] <maxb> oh, the version question
[08:53] <StevenK> maxb: Won't we run it for q?
[08:53] <StevenK> In two weeks
[08:53] <maxb> oh, perhaps I'm extrapolating wrongly
[08:54] <maxb> It seemed that juju only branched for precise recently
[08:54] <maxb> It's still no big deal, I already wrote them a 5 line launchpadlib script to fix things up after branch-distro
[09:23] <jml> hey ho
[09:23] <czajkowski> herro
[09:30] <jml> my branch failed buildbot: https://lpbuildbot.canonical.com/builders/lucid_lp/builds/1994/steps/shell_6/logs/summary
[09:30] <wgrant> jml: There was an intermittent failure
[09:30] <jml> I haven't done any serious probing yet, but I've got no idea how that failure is related to my change
[09:30] <wgrant> jml: It should be on qastaging now
[09:30] <jml> wgrant: oh. hmm.
[09:30] <wgrant> I reverted the problematic revision several hours ago
[09:30] <wgrant> With the minor issue that qastaging appears to be down
[09:30] <wgrant> Like, not accepting connections
[09:30] <wgrant> It worked a minute ago..
[09:31] <wgrant> There we are
[09:32] <jml> are you guys going to serialize landings again once parallel testing is up?
[09:32]  * jml is guessing not, but you know, a boy can dream
[09:32] <wgrant> Not initially
[09:32] <wgrant> It wouldn't have helped this time, either.
[09:32] <wgrant> The first two test runs passed.
[09:33] <wgrant> But my 6 ec2 runs hit various combinations of the two flaky tests failing.
[09:33] <jml> wgrant: right. intermittent failures are the devil.
[09:33] <wgrant> jml: qastaging's apidoc says createPPA has a commercial argument, so it looks to be there
[09:33] <wgrant> Yeah
[09:33] <jml> oh hey, I wrote a script
[09:34] <wgrant> No idea how these are happening; need to poke jcsackett.
[09:37] <jml> .huh
[09:38] <jml> as best as I can tell, createPPA() returns a dict of the attributes of the person that the ppa is being created on
[09:38] <jml> which, uhh, is weird
[09:39] <wgrant> jml: You can't say lp.me.foomethod
[09:39] <wgrant> Because lp.me is a redirect
[09:39] <wgrant> And POSTs aren't allowed to follow redirects
[09:39] <wgrant> So lp.me is reasonably useless.
[09:39] <jml> yes.
[09:39] <jml> but only marginally more so than the rest of lazr.rest*
[09:39] <wgrant> :)
[09:41] <jml> jml is not allowed to make commercial PPAs
[09:41] <jml> \o/
[09:41] <wgrant> Oh, I thought you were already a commercial-admin
[09:42] <jml> ok. now I need to go away before I start thinking too hard about createPPA's brokenness
[09:44] <wgrant> What's borked?
[09:44] <jml> You had to ask.
[09:45] <jml>             role = IPersonRoles(person)
[09:45] <jml>             if not (role.in_admin or role.in_commercial_admin):
[09:45] <jml> does that work if 'person' is a team?
[09:46] <jml> If 'person' is in admin but the team they are creating the ppa for is not then presumably that check won't pass
[09:46] <wgrant> It should always be checking on the current user, not the person who is being operated on.
[09:46] <jml> as validatePPA() is called by createPPA with the person being operated on
[09:46] <wgrant> Now, it probably isn't, because a lot of our code is fucking moronic.
[09:46] <wgrant> But it *should* be.
[09:46] <jml> wgrant: yeah, that's the brokenness I was talking about
[09:46] <jml> wgrant: and, uhh, well put.
[09:48] <jml> another part of the problem is that there are all of these rules, but they are expressed imperatively (not great), spread out in a bunch of different places (worse), and often partially and imperfectly duplicate one another (rotten, but a natural consequence of the first two)
[09:49] <wgrant> Mmm
[09:49] <wgrant> Being imperative isn't the problem. Being inconsistent and distributed and buggy and otherwise generally horrid is.
[09:50] <jml> it's not *the* problem, no.  but if you could express your permission rules as data, I'm pretty sure a lot of other things would fall into place
[09:50] <wgrant> That's true.
[09:51] <jml> we were talking a bit about this when we did one of these recent branches
[09:51] <jml> zcml security has no way of expressing "passing in private as True to this method is restricted"
[09:51] <wgrant> Right.
[09:52] <wgrant> That has plagued us forever.
[09:52] <jml> and even if you kludged around it by having a createPrivate method, that wouldn't be enough
[09:52] <wgrant> And then there are things like "privilege X must be held on this argument"
[09:52] <jml> because you would need a new permission
[09:53] <wgrant> Traditional Zope security is pretty much useless for anything.
[09:53] <wgrant> Counterproductive, even.
[09:53] <jml> e.g. I can create branches in ~jml/+junk, but no one else can. I cannot create private branches.
[09:53] <wgrant> Because it is based entirely on the (object, attrname)
[09:53] <jml> it's a good type checker? maybe?
[09:53]  * jml doesn't really believe that.
[09:55] <jml> wgrant: can I get commercial-admin on qastaging?
[09:56] <wgrant> webops: please add jml to commercial-admins on qastaging
[09:56] <jml> ta
[09:56] <jml> (although, huh, what a colossal waste of their time when they could be deploying my software)
[09:56] <mthaddon> jml, wgrant: done
[09:56] <wgrant> Heh
[09:56] <wgrant> mthaddon: Thanks
[09:56] <jml> mthaddon: thanks.
[09:59] <jml> and there was much rejoicing.
[10:00] <jml> wgrant: did you watch the "Simple made easy" talk that Gary shopped around?
[10:01] <wgrant> jml: No. Should I?
[10:02] <jml> wgrant: I think so.
[10:02] <wgrant> I think I recall the email
[10:02] <jml> wgrant: although reading my blog post about it is probably an almost acceptable alternative.
[10:03] <wgrant> Your blog posts are often quite acceptable indeed.
[10:03] <jml> personally I'd rather digest things as text rather than audio
[10:03] <jml> wgrant: thank you :)
[10:03] <jml> but it is a pretty good talk.
[10:03] <wgrant> Yeah, reading is a tad faster than listening to an hour of waffling..
[10:03] <wgrant> I wish everything came with transcripts :)
[10:04] <wgrant> jml: Care to leave commercial-admins now you're done?
[10:04] <jml> +1
[10:04] <wgrant> It's a reasonably powerful team, so the fewer unneeded members the better.
[10:04] <jml> wgrant: sure.
[10:04] <wgrant> Thanks.
[10:04] <jml> the whole point of this exercise is to reduce the need to be a member.
[11:58] <jml> \o/
[11:58] <jml> I think I've just isolated this bug.
[11:59] <benji> jml: would that be the tag leakage?
[11:59] <jml> gary_poster: hi
[12:00] <jml> benji: yes indeed.
[12:00] <benji> cool
[12:00] <gary_poster> hey jml
[12:00] <gary_poster> sounds like you have addressed both of y concerns from last night :-) thank you
[12:00] <jml> well, the tag filtering thing is still wip
[12:00] <benji> I'm a little jealous, it looked like a fun one to tackle.  The downside of multi-timzone cooperation, I guess. ;)
[12:01] <jml> I have to page it back in and remember what needs to be done for that.
[12:01] <jml> lp:~jml/testrepository/tag-leakage/ has my steps to isolation
[12:01] <jml> going to knock up a patch to testtools now
[12:01] <jml> benji: I probably should have left it. :\
[12:01] <gary_poster> jml, for tag filtering, we're happy to help, as you'd expect.  I'd love to see if we can get a rough version in our PPA though, if it works
[12:01] <jml> gary_poster: cool.
[12:11] <benji> jml: do you think your branch is suitable for us to play with in our PPA
[12:11] <jml> benji: no idea, I'm afraid.
[12:11] <jml> benji: I didn't deliberately put any remote root exploits in it.
[12:13] <benji> heh
[12:17] <benji> jml: do you want us to pick up the torch on the tag leakage or are you just about done?
[12:17] <jml> benji: just finishing up.
[12:17] <benji> great!
[12:18] <jml> am going to merge without review.
[12:18] <jml> hmm.
[12:21] <jml> merge and pushed
[12:25] <jml> :(
[12:25] <jml> ok, I think filter-tags will need a little bit of work.
[12:26] <jml> the ideal thing to do is release testtools and then burn subunit.TestResultDecorator
[12:26] <gary_poster> heh
[12:26] <jml> but that would mean a lock-step upgrade and we don't like those
[12:27] <gary_poster> though doable
[12:27] <jml> I'm not sure if it makes sense for you guys to pick up on it, tbh.
[12:27] <jml> yeah
[12:27] <jml> I'd like to spend a bit more time paging all of this in so I'm clearer on the release/dependency issues
[12:28] <gary_poster> ok, understood.  it's blocking us, which I hate to admit. um.
[12:30] <jml> gary_poster: sure. I'll get to it post food then.
[12:31] <gary_poster> jml, wow, thank you.  I was contemplating nasty hacks.
[12:31] <gary_poster> that would be fabulous.
[12:31] <jml> gary_poster: my pleasure.
[12:31] <jml> gary_poster: somewhat relatedly, I'm sure my manager always enjoys hearing nice things about me.
[12:31] <gary_poster> jml, lol, can do
[12:32] <jml> leaving this cafe for another one with better food.
[13:04] <deryck> Morning, everyone.
[13:29] <benji> jml: am I reading your comment at https://code.launchpad.net/~benji/testrepository/add-worker-id-tagging/+merge/102574/comments/221132 correctly in that without the ExtendedToOriginalDecorator you get correctly-tagged output?  I'm trying to figure out if ExtendedToOriginalDecorator is needed, and it doesn't look like it.
[13:30] <jml> benji: I get that test failure without it. Because addSuccess() is passed details but LoggingResult doesn't implement it.
[13:31] <benji> jml: right, I've fixed the test failure (I had hacked the testtools I was using, but I now have a test fix that doesn't require that hack).  I'm now interested in whether or not I'll need the ExtendedToOriginalDecorator to get correct output.  I don't think we do.
[13:34] <jml> benji: basically only use it if you don't control the result that goes in.
[13:34] <benji> jml: right, that's what I was thinking; since we control the entire stack of results there, we should be good
[13:36] <jml> benji: ok.
[13:36] <jml> benji: if the tests pass.
[13:36] <benji> indeed they do
[13:51] <rick_h> jcsackett: bah, sorry completely missed it was thurs
[13:52] <jcsackett> rick_h: all good. :-)
[14:27] <sinzui> jcsackett, do you have a few minutes to talk?
[14:27] <jcsackett> sinzui: sure. lemme go find my phone and i'll get on G+.
[14:30] <jcsackett> sinzui: ready when you are.
[14:30] <deryck> abentley, hi.  chat time now ok?
[14:30] <abentley> deryck: sure.
[14:31] <sinzui> jcsackett, I an in the g messenger hangout
[14:32] <jcsackett> huh. so am i. i'll quit and come back in.
[14:32] <deryck> abentley, https://plus.google.com/hangouts/_/extras/d030c97575c1cc09b3ba584164c3d8e5baf17a0e
[14:35] <sinzui> jcsackett, http://pastebin.ubuntu.com/936950/
[14:54] <sinzui> jcsackett, r=me for the privacy adapter branch
[16:35] <benji> jml: any hints on running the subunit tests?  runtests.py gives me an import error and I don't see anything in the README about any neccesary setup
[16:42] <jelmer> benji: have you tried 'make check' ?
[16:43] <benji> jelmer: yep, not a make target
[16:45] <benji> there is a Makefile.am and configure.ac that look tantalizing, if I knew what they wanted me to do with them
[16:45] <jelmer> benji: autoreconf -i && ./configure && make && make check
[16:52] <benji> jelmer: ah, autoreconf
[17:33] <bac> has launchpad-developer-dependencies gone away?
[17:40] <bac> nm, i see it is built as part of launchpad-dependencies in the ppa
[18:05] <sinzui> rick_h, do you have time to review https://code.launchpad.net/~sinzui/launchpad/project-notify-5/+merge/102734
[18:10] <rick_h> sinzui: sure thing
[18:33] <rick_h> sinzui: ping, question for you
[18:33] <sinzui> hi rick_h
[18:33] <rick_h> sinzui: so shuoldn't there be some code that creates these jobs?
[18:34] <rick_h> or is that a follow up?
[18:34] <rick_h> I would imagine there's something that queries for upcoming expiring projects to deactivate via a query somewhere?
[18:34] <sinzui> per the cover letter, I ran out of room and time
[18:34] <sinzui> My next branch will deal with that
[18:35] <rick_h> ah gotcha, sorry. Read that but thuoght of it as something different
[20:09]  * deryck heads home now
[20:29] <sinzui> Instead of fixing a trivial bug that affects a few users, I found a non-trivial bug that indicates our sprites will break in all browsers in the future.
[20:30] <sinzui> I am going to look for something to delete instead
[22:15] <lifeless> sinzui: sounds fun ?
[23:13] <lifeless> sinzui: you found a dupe
[23:23] <sinzui> well. I pleased to have accomplished something
[23:23] <lifeless> sinzui: \o/
[23:24] <sinzui> This issue is not about asymeteric packing though. It really is about the size of the image. I agree it can be a dupe because one fix is needed.
[23:49] <wgrant> StevenK, wallyworld: A quick one if someone has a sec: https://code.launchpad.net/~wgrant/launchpad/bugtaskflat-join-removal/+merge/102780
[23:49] <wgrant> 39 lines (+8/-7) 1 file modified
[23:51] <nigelb> Morning.
[23:51] <wgrant> Morning nigelb.
[23:52] <nigelb> 0430 is awfully early to be awake :/
[23:54]  * wallyworld looks
[23:55] <wallyworld> wgrant: all the tests pass?
[23:57] <wgrant> wallyworld: Yes.
[23:58] <wallyworld> wgrant: was flat_bug_join already defined?
[23:58] <wgrant> wallyworld: Yeah, it's used in the sorts higher up.
[23:58] <wgrant> flat_bug_join = (Bug, Join(Bug, Bug.id == BugTaskFlat.bug_id))
[23:58] <wgrant> flat_bugtask_join = ( BugTask, Join(BugTask, BugTask.id == BugTaskFlat.bugtask_id))
[23:59] <wallyworld> ok, r=me
[23:59] <wgrant> Thanks.