[00:07] 'make schema' is failing for me w/ CSS errors. [00:11] ahh, but it's fixed by a 'make clean' [00:14] make ajax-clean? (har har) [00:26] spm, *snrk* [04:16] thumper, around? [05:03] rockstar: no [05:03] thumper, :( [05:04] thumper, could you take a look at this really quick? I made the changes you asked for, but I guess I should have pinged you after I did them. https://code.edge.launchpad.net/~rockstar/launchpad/branch-scanner-prep/+merge/16260 [05:05] rockstar: not tonight, going to see avatar, I'll look tomorrow morning when I start work [05:05] thumper, okay. I have a branch dependent on it that I was hoping to land. I'll just blame you for not landing it in tomorrows stand up. :) [05:05] ok [05:06] thumper, have fun at the movie. [08:15] good morning [08:20] Good morning adeuring, alles Gute im neuen Jahr :) [08:29] al-maisan: hi al-maisan! auch Dir eine frohes neues Jahr! [08:33] :) [08:48] adeuring, al-maisan: Auch von mir ein Frohes Neues! ;) [08:49] henninge: danke, Dir auch! [08:49] henninge: hallo, Frohes Neues Jahr :-) [09:12] Hello all [11:04] Morning, all. === noodles775_ is now known as noodles775 [12:02] hi, in the latest launchpad/devel , if I run the full test suite, 1 test is with errors (lp.translations.tests.test_translationbranchapprover.TestTranslationBranchApprover.test_approveNewSharingTemplate) and there are 53 import errors [12:03] is this ok? [12:04] adiroiban: Can you pastebin the full error output? [12:04] I only know of one test (xx-sso-resetpassword.txt, or something of the sort) that should be failing for non-Canonical people. [12:05] http://paste.ubuntu.com/351210/ [12:06] adiroiban: You need to reset your DB permissions. [12:06] 'make schema' will do that for you. [12:07] (and wipe out the rest of the data, but it's the easiest way) [12:08] The import warnings are probably just because jml unbroke the importfascist not long ago. Ignore them. [12:08] or fix them. === mrevell is now known as mrevell-lunch [12:10] thanks [12:29] jtv: hi. Can you please take a look at the last comment from bug 127171. If everthing is ok I will create a MP [12:29] Bug #127171: Rosetta experts not allowed to "Change translators" [12:30] adiroiban: hi, happy new year! Looking... [12:41] adiroiban: I posted a comment [12:49] jtv: thanks. as far as I know, right now translation group owners don't have access to products/projects translations settings? Should I go and implement it, or we need to gather more answers for this new question? [12:51] adiroiban: my knowledge matches yours. :) The only _good_ reason I can think of not to allow this is if we decide to add a bunch of other translations settings to that same page. Then it might potentially be a bad thing. [12:51] Technically the translation grou [12:51] p owner probably shouldn't mess with the access model (open/structured/...) [12:52] but this is the group owners we're talking about, not a wet-behind-the-ears translator who isn't aware of some special arrangement for the project. [12:52] true [12:55] jtv: can you think of some new translations settings that in the near future can land on this pag [12:55] not very near future, no... I've been suggesting breaking down _all_ the project/distro settings by app, but we never did get around to that [12:56] (so you'd have a Settings page with the usual overview/branches/bugs/... tabs, and conversely, each of those pages for the project would have a Settings link [12:56] ) [12:57] Anything else? Something related to upstream connections, I guess. Maybe it's all in the name this page has. [12:58] You've been playing with giving it a more generic name, but maybe we should consider the opposite. [12:58] e.g. "+translation-access" [12:59] that way we definitely wouldn't move anything unrelated onto the page that we don't want to give group owners access to. [13:00] well right now we have +setting (for a product) and +translations-settings (for a product series) [13:00] group owners should not care about +translations-settings [13:01] for a productseries [13:01] adiroiban: in that case I mis-remembered; I'd better go refresh my recollection [13:02] I got that the other way around [13:02] adiroiban: hmm... I see +changetranslators on the product, which actually sounds just right for what we want here [13:03] deryck: morning! [13:03] hi kfogel! [13:03] jtv: hey there, happy new year [13:03] same to you—happy 2553 [13:03] BE [13:03] jtv: "2553 BE" ? [13:04] Buddhist Era. [13:04] jtv: true. but last time we talked about this topic, we decided to rename +changetranslators to +settings [13:04] Morning kfogel! [13:04] kfogel: and no, I have _no_ idea whether there's a BB as well [13:04] adiroiban: absolutely right... but what I'm saying is you might have uncovered a reason for not doing that after all [13:04] jtv: heh! never heard that before. [13:05] deryck: what time's standup? [13:05] :_ [13:05] :) [13:05] jtv: ok. then I will leave +changetranslators [13:06] and allow translation group owners to edit that page for both product and distribution [13:06] adiroiban: also has the advantage of less work. :) [13:07] kfogel, you know we already did it. We didn't change it yet. I thought you were unavailable today for some reason. [13:07] deryck: whoa -- I forgot it currently started that early. No problem. [13:07] adiroiban: I do think this'll spread some unexpected happiness, as group owners gain a bit more control over their relationship with projects [13:09] yep. but appart from Ubuntu and Launchpad Translations groups, I think all other product specific translations groups are owned by the product owner/developer [13:12] adiroiban: even so, imagine someone assigning an arbitrary, unrelated project-specific translation group to their project. As things stand, the group owner just goes "wtf" but can't do much. Now, they can just change the setting. And they can keep each other happy for days toggling the switch until they decide to talk to each other. :-) [13:13] :) [14:02] jtv1: i have one more question for bug 127171. Since this is a special edit/admin case, I can not reuse launchpad.Edit or launchpad.TranslationsAdmin permissions. It is ok if I'll create launchpad.ChangeTranslators permission ? === jtv1 is now known as jtv [14:02] Bug #127171: Rosetta experts not allowed to "Change translators" [14:03] adiroiban: thin ice for me, so it's worth getting e.g. sinzui (hi sinzui :) into the discussion [14:04] adiroiban: yes that is a difficult issue [14:04] I suppose the alternative would be to have a separate object with regular Edit or Admin rights granted to these groups [14:05] yep [14:05] but as things stand now, I'd be hard-pressed to answer questions like "then should this be edit or admin," or "if this is Edit, what would Admin mean for that object" [14:05] we already have IHasTranslations [14:05] so IHasTranslators [14:05] can add some confusion [14:06] confusion adds spice to life [14:06] but anyway :) [14:06] adiroiban: jtv: consider separating the classes, or using a marker interface. You can also create launchpad.Moderate because that is what rosetta-experts does in many cases [14:06] well.. for a IProduct/IProject/IDistribution this is neither Edit or Admin for [14:07] sinzui: note that in this case, there are 2 additional classes of people that would have these rights [14:07] —the owners of the translation group (one side of a relationship) and the owners of the project (other side of the same relationship) [14:09] sinzui: prima facie this doesn't sound like a case for Moderate, but you do remind me that we can have a look for appropriate existing permissions before we consider adding new ones [14:11] jtv: I added marker interfaces to distinguish better Ubuntu and other distros so that they could have different permissions in security.py. It is a pain to add [14:11] sinzui: interesting approach... not something I would have come up with given my background in static languages [14:12] sinzui: or wait... are you saying "to better distinguish distributions from e.g. projects," or "to better distinguish Ubuntu from other distributions"? [14:13] henninge, do you have any suggestions for a launchpad.* permission we might use for setting a project or distro's translation group & access model? [14:13] yes: IBaseDistribution and IDerivativeDistribution are added on Distribution.__init__ so that is clear how the instance uses Launchpad. [14:13] ^ jtv [14:14] cool [14:14] jtv: is launchpad.Moderate already used? [14:15] jtv: launchpad.Special would be the other option. [14:15] henninge, jtv launchpad.Moderate is not used in translations [14:15] There was a mailing list thread about Special ages ago, which I probably didn't bother to read [14:16] we have launchpad.TranslationsAdmin for edit/admin translations settings for objects [14:16] Moderate seems to be used only in Answers [14:16] jtv: it is now used in registry, too, once my branch is finally landed ... [14:17] oh? [14:17] whare are the drowback of having launchpad.ChangeTranslators ? [14:17] adiroiban: just that we should stop and think before multiplying permission types. [14:18] jtv, adiroiban: And we need special blessings from on high to be allowed to add it . [14:18] no biggie really, just a checkpoint [14:18] henninge: oh my, it's been so long since I added one that I'd forgotten that :) [14:18] there is the man to ask for it ^ ;-) [14:18] yup :) [14:19] flacoste: you come at just the right time === salgado_ is now known as salgado [14:19] morning launchpadders [14:19] (and hi, btw :) [14:19] and happy new year! [14:19] but I don't think we need to, we can just re-use one of the existing once. [14:19] hi jtv [14:19] jtv: what can i do? [14:19] flacoste: and a good one to you, too. [14:19] flacoste: we're just discussing whether adding a new permission is the right thing to do for a particular case [14:20] jtv: it usually is not, but there are exceptions [14:20] flacoste: is related to bug 127171 [14:20] Bug #127171: Rosetta experts not allowed to "Change translators" [14:21] we have „translationgroup translationpermission” atrributes for IProduct, IProject and IDistribution [14:21] and we can not reuse launchpad.Edit, launchpad.Admin or launchpad.TranslationsAdmin permission [14:22] as this is a special edit/admin case [14:24] adiroiban, jtv: what is it you want to protect? [14:24] these two attributes on product, project? [14:24] flacoste: More generally: a project/distro/project-group can pick one translation group to manage its translations, but we'd like to give 4 classes of users the right to edit this relationship: [14:24] and distribution [14:24] yes [14:24] * owners of the project/distro/project-group [14:24] * owners of the translation group [14:24] * rosetta admins [14:24] flacoste: well, in fact we want to protect all the others attributes [14:24] * full admins [14:25] adiroiban: what other attributes? [14:25] adiroiban: i assume those are allrday protected [14:25] right [14:25] other edit and admin attributes for project/distribution [14:25] flacoste: yes. they are protected [14:25] I think the confusion is because we're actually talking about un-protecting something :) [14:26] adiroiban: instead of defining a new permission, why not refactor these aspects into a separate object? and use launchpad.Edit / launchpad.Admin there [14:26] adiroiban, jtv: i don't think these attribuets are really part of the IProduct, IProject, IDistribution interface [14:26] we were discussing that against the alternative of adding a permission [14:27] jtv: i'd rather refactor into separate object instead of adding to permission proliferation [14:27] it brings other advantages has it reduce the interface [14:29] ok. then I will use launchpad.Edit on TranslationPermission [14:29] from lp.translations.interfaces.translationgroup [14:30] sorry. IHasTranslationGroup [14:30] flacoste: this is oddly reminiscent of something we discussed in Dallas... basically a "compound attribute" or "inline object" [14:33] one thing I'm far too rusty on: can you do this on the interface, as opposed to the object? [14:34] I mean, is just moving these two attributes into a new interface enough? [14:36] adiroiban, jtv: you can declare security on an interface, but you have to have a separate object providing that interface [14:36] adiroiban, jtv: if you simply use IHasTranslationGroup and IProduct defines it, the it's kind of undefined which checker will be used to get launchpad.Edit [14:36] s/defines it/provides it/ [14:36] since you'll have a checker for launchpad.Edit on IProduct [14:36] and one launchpad.Edit for IHasTranslationGroup [14:36] but Product will provide both [14:36] which checker should be used for launchpad.Edit on a product? [14:36] flacoste: so that would be "no" to my question. Thank God you're here. :-) [14:37] flacoste: launchpad.Edit for a Product should stay exactly as it is === Guest17810 is now known as Joey [14:39] so yes, we would need to take steps to avoid "polluting" the existing permissions for the existing objects [14:42] a new class wouldn't really "do" anything though, apart from apply this permission—you'd basically have either launchpad.Edit on it or nothing [14:50] jtv, flacoste : what would be you suggestion for solving this problem? [14:51] I know I'm the one who said "consider a new class before adding a permission," but In this particular case, I don't think it'd pull its weight [14:51] francis..? [14:51] jtv: well, not creating a new permission pulls its weight for me [14:52] i'd call it TranslationPolicy [14:52] isn't it what it is? [14:52] it defines the translation policy for the IHasTranslationGroup? [14:52] is translationpolicy + translationgroup [14:53] meaning it's the translationgroup itself? [14:53] note that there is no IHasTranslationGroup yet; that's just something we're considering as part of an alternative to a new permission [14:53] do you have a ITranslationGroup already? [14:53] yes [14:54] jtv: hm... what is IHasTranslationGroup from lp.translations.interfaces.translationgroup [14:54] ? [14:54] i'd say create a ITranslationPolicy [14:54] which has permission and group has members [14:54] adiroiban: oh, we do have one? oops! === salgado is now known as salgado-afk [14:55] the new interface is definitely a nice idea... I'm more worried about a new implementing class === salgado-afk is now known as salgado-lunch [14:56] * jtv checks out IHasTranslationGroup [14:56] you can then define an adapter that will map the attributes to the underlying db object [14:56] so to get to the translationgroup or permission for an object you'D use [14:57] ITranslationPolicy(product).translationgroup [14:57] ah, ok, we do have the separate interface already [14:57] why do you need IHasTranslationGroup? [14:57] it turns out that's the interface that these attributes are already in [14:58] right, so I'd say rename the interface and use an adapter [14:58] because a product wouldn't have a translation group anymore [14:58] it could be adapted into one [14:58] that'd be another way of doing it actually [14:59] move the permission attribute to the translationgroup itself [14:59] and adapt directly to ITranslationGroup [14:59] that doesn't work if you can change the translation group though [14:59] which i think is what you want here [14:59] in that case, renaming it has a TranslationPolicy sounds better [14:59] the permissions were moved to IHasTranslationGroup [15:00] right [15:00] flacoste: adapting to ITranslationGroup wouldn't be appropriate here, but adapting to the separate interface does look good [15:01] And then there'd be a launchpad.Edit on the class that provides the adapter? [15:02] deryck, hi. I woke up today thinking about Launchpad bugs Q&A [15:03] flacoste: and I guess setters, to shunt changes back to the actual Product/Project/Distribution [15:05] jtv: yes, there'd be a launchpad.Edit checker for ITranslationPolicy [15:05] jtv, adiroiban: i'd check if lazr.delegates allow delegating setter also? [15:05] beuno, ok, cool. I'm all ears. :-) [15:06] * jtv checks [15:06] jtv, adiroiban: declare the adapter as trusted, that way you'll always get an unproxied object has the adpater context (so the raw DB object) [15:07] deryck, it wasn't a bright idea as much as "that would be very cool" :) [15:07] do we know when we're going to sink our teeth into the feature? [15:08] flacoste: raw model object I understand... but what db object? [15:08] oh, the context—sorry [15:08] jtv: well, the raw model object is a db object, no [15:10] flacoste: is there no risk of leaking when we do that? I would've thought to use rSP() in the setters [15:10] (although of course that means we lose the convenience of delegating them, if that is possible) [15:10] jtv: no, the security framework will proxy it back [15:10] ah ok [15:11] so we're really just allowing access for the purpose of delegating [15:15] I know there was a doctest for delegates _somewhere_... === matsubara is now known as matsubara-lunch [15:25] adiroiban: I'm checking whether delegating settings will work [15:26] beuno, sorry, locked up system. we'll continue work on q&a when checkwatches work is done. I'd guess a couple months out. [15:26] beuno, just a guess though :) [15:29] jtv: OK. Right now I'm lost and I'm looking at the LP code to understand the required changes [15:29] flacoste: bless your little toes, yes, setters get delegated! [15:31] adiroiban: instead of making IProduct/IProject/IDistribution inherit from IHasTranslationGroup, you'd give them adapters to IHasTranslationGroup [15:31] (I'm ignoring the matter of renaming the interface here, since it's entirely orthogonal to the rest of it) [15:33] adiroiban: the adapted object implements IHasTranslationGroup, but simply by delegating it to self.context using lazr.delegates. [15:34] so it contains nothing but self.context, which is a reference to the real Project, Product, or Distribution [15:34] jtv: ok. I'll ignore the renaming for now. So one adapter for each attribute === mpt_ is now known as mpt [15:35] adiroiban: no, the adapter produces an object that implements the entire IHasTranslationGroup (so both the TranslationGroup reference and the permissions setting)_ [15:36] jtv: can you point me to a similar code that is already implemented in LP. [15:36] adiroiban: I tried to find back the documentation for delegates that I seem to recall reading, but little luck so far. :/ [15:36] I think an example will help me understand what are these lazr.delegates, why and how should I use them [15:37] you're very right to ask for it though! [15:38] (I'm still searching :) [15:39] adiroiban: ah! it's been turned into a README.txt in lazr.delegates [15:44] jtv: is this an external project? i could not find the README.txt for lazr.delegates [15:44] adiroiban: right, it's outside of the lp tree; look in lp-sourcedeps/eggs/lazr.delegates* [15:44] thanks [15:45] meanwhile I'm cooking up a very schematic example [15:45] of the delegation part [15:53] jtv: yep. reading the documentation... [15:53] jtv: getting back to IHasTranslationGroup [15:53] it should be renamed to ITranslationsPolicy, right? [15:53] Does this error look familiar to anyone? [15:53] Getting distribution for 'distribute'. [15:53] Error: Couldn't find a distribution for 'distribute'. [15:53] That's while running bootstrap.py [16:00] adiroiban: http://paste.ubuntu.com/351305/ [16:00] flacoste, UI call? [16:01] beuno: yep [16:01] EdwinGrubbs? [16:01] noodles775? [16:01] jtv? [16:01] beuno: I'm dialing in now [16:02] beuno: same here === matsubara-lunch is now known as matsubara === beuno is now known as beuno-lunch === salgado-lunch is now known as salgado [16:32] adeuring: hey, I think you dropped out on the canonical irc network [16:32] kfogel: i should be back. [16:33] (that was the daily connection reset from my ISP... Need to disconnect the DSL modem explicitly later this evening) [16:34] adeuring: not back yet (at least according my nick completion). But anyway, no big deal. I was going to say "call now?", but need to have a quick conversation with my girlfriend Winnie about coordinating travel later today, so let me do that first then ping you. [16:34] kfogel: sure, np [16:37] adiroiban: I'm leaving for the night... what's your impression of Francis' suggestion so far? [16:37] jtv: still reading about delegates [16:37] I don't know if this should be part of the model or the view [16:38] adeuring: okay, ready [16:38] adeuring: I'm "karl.fogel" on skype [16:39] kfogel: ok,. I'll call you [16:39] adiroiban: did my example help? One thing beyond the delegates part is that the TranslationPolicy class can serve as an adapter factory (look for "adapter" in lib/lp/translations/configure.zcml) to produce TranslationPolicy objects. [16:41] jtv: right now I don't know how to plug the TranslationPolicy into the current views [16:42] adeuring: https://dev.launchpad.net/Bugs/PatchTracking [16:42] jtv: but with more reading I should get my way. Thanks! Have a good evening [16:43] adiroiban: from a brief look at ProjectChangeTranslatorsView, I'd guess you could use the generic form for TranslationPolicy. [16:43] whoops... evening? almost midnight. See you tomorrow! :-) [16:43] jtv: :) [16:44] see you tomorrow! ... or in the morning :) [16:45] gah :) [16:45] sinzui: thanks for your bug retargeting work [16:46] bigjools: your welcome. [16:52] adeuring: https://wiki.ubuntu.com/Specs/LaunchpadUpstreamImprovements === abentley1 is now known as abentley === abentley1 is now known as abentley === abentley1 is now known as abentley === abentley1 is now known as abentley === abentley1 is now known as abentley === abentley1 is now known as abentley [17:06] adeuring: https://bugs.edge.launchpad.net/malone/+bug/231023 [17:06] Bug #231023: on status change, show new status in Subject: [17:13] adeuring: did you read https://bugs.edge.launchpad.net/malone/+bug/172501/comments/6 and Emmet's followup comment to it? [17:13] Bug #172501: reject non-code patch attachements

[17:13] adeuring: it seems Matt Z is suggesting that this whole automatic detection of patches plan is bogus, and instead bugsquad should just add "patch" flag manually when they see there's a patch there. [17:14] adeuring: to me, that sounds like unnecessary work for bugsquad, and we *should* be able to do better with automatic detection. But I'm not sure if there's perhaps some history here that I'm not aware of. [17:16] kfogel: right. but that perhaps also a hint that we should focus more on bzr branches than on attachments [17:16] adeuring: hmrm. Okay, adjusting comment accordingly. === beuno-lunch is now known as beuno [17:25] adeuring: added comments to bug #298099 and bug #172501 as discussed. I wish I knew a way to add a shorthand link to a particular comment (e.g., the way "bug #NNN" links to that bug, I want to link to "bug #NNN comment #8", but the only way I can see to do that is to just write out the full URL to that comment). [17:25] Bug #298099: patch flag for attachments not indicated as optional

[17:25] Bug #172501: reject non-code patch attachements

[17:25] kfogel: thanks! [17:27] adeuring: ah, that's bug #242420 [17:27] Bug #242420: should be possible to link to bug comments like 'bug 123' becomes a link === kfogel is now known as kfogel-lunch [17:48] curses, I've not been on lunch all this time... === mrevell-lunch is now known as mrevell [17:49] * mrevell --> reboot [17:52] bary, i have a python voodoo question [17:53] the code is here: http://pastebin.ubuntu.com/351352/ [17:54] entry_schema has a non-None value in class_dict, but when I create a type for it, the class's entry_schema is None. the attribute is present but its value is None [17:54] how can this be happening? [17:54] barry -^ [17:56] the superclass (BaseCollectionAdapter) does not define that attribute, so it's not that the superclass value is taking precedence [17:59] barry: i set class_dict['entry_schema'] to the string 'foobar', and that worked [18:01] ok, i think i see the problem... [18:11] g'night all :) === deryck is now known as deryck[lunch] === gary_poster is now known as gary-afk === deryck[lunch] is now known as deryck [19:24] barry: another voodoo question if you're around [19:28] hi leonardr [19:28] james_w: hi [19:28] barry: http://pastebin.ubuntu.com/351399/ [19:29] is it possible and zope's BrowserRequest interface does not have a metaclass of 'type'? [19:31] leonardr: lazr.restfulclient requires Resource A to be bound to know the Resource type for Resource B where B is a parameter of A. Is that a limitation of WADL, or just the way lazr.restfulclient is coded? [19:32] that sounds like a quirk of lazr.restfulclient or wadllib, probably restfulclient [19:32] it seems like more use could be made of resource_type references, but is there something that means you don't know exactly which resource type you will get? [19:32] e.g. team vs. person? [19:33] they would both be Entry, and I think it would be mad to have something which could be either a Collection/Entry, but Collection/CollectionWithKeyBasedLookup would be possible [19:33] good morning [19:33] james_w: there are cases where the wadl says you get a generic interface (eg. a pillar or a person) when you'll actually get a more specific type. in those cases you'll have to fetch the real object to see the type [19:34] but they would both be entry [19:34] they would be different subclasses (sub-interfaces) o f the same generic interface [19:34] I'm asking as I'm writing a lazier version which just instantiates dummy objects, it would be good if those dummy objects could at least know whether they should offer e.g. __getitem__ so that you could error earlier [19:35] ok, so it sounds like you could at least do the dance around RESOURCE_TYPE_CLASSES and the like, even if you aren't sure exactly which attributes the new Resource will present [19:36] morning mwhudson [19:36] thanks leonardr, I'll keep looking at this [19:36] james_w: yes, unless there are specific client-side classes for Team and Person, which shouldn't happen, you should be able to defer fetch to the moment at which the object's type is actually needed [19:36] but for all i know that will end up happening immediately [19:37] leonardr: hi, been on another machine. still need help? [19:41] leonardr: >>> from zope.publisher.browser import BrowserRequest [19:41] >>> type(BrowserRequest) [19:41] [19:41] [19:42] leonardr: >>> from lazr.restful.interfaces import IWebServiceConfiguration [19:42] >>> type(IWebServiceConfiguration) [19:42] [19:42] [19:46] crap [19:46] i have 1.5 times as much unread mail as i had this time yesterday [19:47] mwhudson, yeah, it's coming in faster than I can read it. [19:47] barry: so should i use InterfaceClass instead of type? this is not something i understand well [19:48] morning [19:51] thumper, not-so-subtle-harassment for reviewing https://code.edge.launchpad.net/~rockstar/launchpad/branch-scanner-prep/+merge/16260 [19:51] morning rockstar [19:51] thumper, morning. [19:51] :) [19:51] leonardr: i think so. the problem you're having is (iirc) zope's interface metaclass predates inheriting from type. it's a metaclass defined in C. === matsubara is now known as matsubara-afk === salgado is now known as salgado-afk === james_w` is now known as james_w === EdwinGrubbs is now known as Edwin-afk [21:49] * thumper running for real coffee, bbs [22:17] jelmer: I worked around that distribute issue by downgrading python-pkg-resources and python-setuptools to their Karmic versions. [22:39] * mwhudson afk for a bit [23:20] https://edge.launchpad.net/lazr.restfulclient.tx <- contributions welcome [23:33] oooh. [23:34] james_w, shiny [23:34] james_w, you going to mention it in #twisted? [23:42] jml: you think I should? [23:43] james_w, maybe. someone might be interested. [23:57] jml: junk branches biting us in the arse again with branch.product is None [23:58] thumper, I thought I fixed or XXXd all of those [23:58] jml: when someone fixed the getBranch for revision, it broke the revision karma allocator [23:59] thumper, what was the allocator doing? [23:59] (I bet it wasn't asking for what it actually wanted, but figuring out what it wanted from a bunch of implementation details) [23:59] jml: the query is broken asking for which revisions [23:59] jml: and the checker is broken in at least one place