[10:07] <adeuring> henninge: could you please review this branch: https://code.edge.launchpad.net/~adeuring/launchpad/hwdb-class-udev-device-8/+merge/13554 ?
[10:22] <adeuring> intellectronica: ^^^?
[10:28] <intellectronica> adeuring: yes, looking at it now
[10:28] <adeuring> intellectronica: thanks!
[10:33] <henninge> I am here now ...
[10:33] <henninge> HI intellectronica! ;)
[10:33] <intellectronica> hi henninge, happy new week!
[11:06] <intellectronica> adeuring: wouldn't it be better to use path expressions to find the nodes you want? less likely to make this sort of mistake
[11:07] <adeuring> intellectronica: I'm doing this now, I believe. Or do I miss something?
[11:08] <intellectronica> adeuring: i'm looking at parent.parent.parent.parent and thinking out loud how we can avoid it
[11:09] <adeuring> intellectronica: that's hard... We simply need the grandparent of a device, in UdevDevice.scsi_controller
[11:09] <intellectronica> adeuring: the code in general looks fine, but i find it hard to follow, so i'm wondering if there's anything that can be done to improve it
[11:09] <intellectronica> yes
[11:10] <adeuring> intellectronica: yes, I know that it is not that simple. That's the reason for the sometimes long-winded comments ;)
[11:33] <intellectronica> adeuring: r=me. i find the code quite hard to wrap my head around, but i guess that's mostly just because it's a complex document that's being parsed. i couldn't think of any way to improve on that with small changes. and yes, the commentary does help a lot
[11:34] <intellectronica> henninge: would you like me to review your branch?
[11:34] <adeuring> intellectronica: thanks!
[11:36] <jtv> henninge: your fix looks good.  The comment for the test is lacking the word "entry" after "an," and the test method is confusingly named; I'd suggest test_approve_only_if_needs_review.  Ceterum censeo r=me.
[11:38] <henninge> intellectronica: thanks but I was impatient and asked jtv. He is familiar with the problem, anyway.
[11:38] <jtv> henninge: also, w.r.t. your test plan, not that it matters much but I don't think the date shown in the UI will be updated.  AFAIK we have a bug open for that.
[11:38] <intellectronica> cool bananas
[11:42] <henninge> jtv: thank you
[11:46] <jml> al-maisan, I'll look at that branch now.
[11:58] <al-maisan> jml: thanks
[11:59] <henninge> jtv: http://paste.ubuntu.com/296752/
[12:00] <jtv> henninge: fine
[12:31] <adeuring> intellectronica, henninge: fancy to reveiw a sequel of my previous branch: https://code.edge.launchpad.net/~adeuring/launchpad/hwdb-class-udev-device-9/+merge/13562 (~650 lines, but ca 40%...50% is the definition of test data)
[12:32] <intellectronica> adeuring: i'm reviewing a branch of edwin's i picked off the reviews queue, but can pick your branch when i finish, it won't be long
[12:32] <adeuring> intellectronica: thanks!
[12:47] <intellectronica> maaan, those hwdb branches are starting to feel like soyuz to me. i have to work so much out just in order to be able to understand what they do
[12:49] <bigjools> lies
[13:33] <intellectronica> adeuring: r=me
[13:42] <adeuring> intellectronica: thanks!
[15:06] <adeuring> intellectronica: fancy another sequel of this HWDB submissions stuff (a bit shorter this time: 177 lines diff)? 
[15:06] <intellectronica> adeuring: sure
[15:06] <adeuring> intellectronica: thanks!
[15:06] <adeuring> https://code.edge.launchpad.net/~adeuring/launchpad/hwdb-class-udev-device-10/+merge/13567
[16:28] <allenap> abentley: Can you review a short lpbuildbot branch for me please? There is some bzrlib stuff in there so I'd like you to check my assumptions. https://code.edge.launchpad.net/~allenap/lpbuildbot/explicitly-disconnect-transports-bug-419421/+merge/13575
[16:28] <abentley> allenap: sure.
[16:28] <allenap> Thanks.
[16:36] <abentley> allenap: The transports variable isn't doing a lot for you.  I'm not sure what disconnecting two transports with the same underlying connection does.
[16:37] <allenap> abentley: I don't follow.
[16:38] <abentley> allenap: transports is an optional parameter to Branch.open_containing.
[16:38] <abentley> allenap: It's only valuable if you pass it into another call later.
[16:39] <allenap> abentley: I was relying on the fact that reusable transports get appended to it, so I could disconnect them.
[16:40] <abentley> allenap: I don't think we provide a strong guarantee that passing it into open_containing will append all transports that were opened in the process of opening the branch.
[16:40] <allenap> abentley: Ah, okay.
[16:41] <abentley> allenap: Are you sure you need to disconnect all the transports?
[16:43] <allenap> abentley: Well, no, but from the bug report it seems that ssh processes are not getting reaped all the time. I'm assuming that they are related to bzr operations. If that's a correct assumption, then I want to try explicitly reaping them.
[16:43] <allenap> abentley: It may be that the assumption is wrong, but I want to try this because I don't have any better ideas :)
[16:44] <abentley> allenap: Right, but are you sure you need to disconnection all the *transports*?  Because I would have thought you only needed to disconnect all the *connections*.
[16:45] <allenap> abentley: I didn't understand the distinction before. All the connections I would say. Calling transport.disconnect() closes the connection, so I'm relying on that.
[16:47] <abentley> allenap: Right, so I think you can just do branch.bzrdir.root_transport.disconnect()
[16:49] <allenap> abentley: Okay. I assume that will basically disconnect everything that bzrlib has done from everything. I think that'll be fine for our buildbot configuration as it stands, but it's bad behaviour if we ever add more pollers to the configuration.
[16:50] <abentley> allenap: No, that will just disconnect the ssh connection related to the branch you just opened.
[16:52] <allenap> abentley: Ah, I read that wrong! I read bzrlib.bzrdir.root_transport.disconnect, and I assumed root_transport was a module global.
[16:52] <allenap> abentley: Okay, thanks for that, I'll use that approach.
[16:52] <abentley> allenap: Cool.
[16:54] <abentley> allenap: Also, you should pull the "branch =" statement out of the try block.  If that were to fail, you wouldn't want to go to the finally block.
[16:54] <allenap> abentley: Yeah, agreed.
[16:56] <abentley> I can't say whether this approach will actually solve the zombie problem, but it looks fine otherwise.
[16:56] <jml> al-maisan, hello
[16:56] <al-maisan> hello jml , just read your email
[16:57] <al-maisan> thanks very much for clarifying things
[16:57] <jml> al-maisan, my pleasure.
[16:57] <al-maisan> so, the branch-sourcepackage relation is 1-on-1 .. but
[16:58] <jml> al-maisan, there are two kinds of relationships between a branch and a sourcepackage
[16:58] <al-maisan> aha
[16:58] <sinzui> intellectronica: henninge, abentley: Can one of you take https://code.edge.launchpad.net/~sinzui/launchpad/package-link-validation-1/+merge/13578 ?
[16:58] <jml> al-maisan, a branch can *belong* to a source package
[16:58] <jml> al-maisan, (or a product, or be a junk branch)
[16:58] <al-maisan> yes...
[16:58] <jml> al-maisan, alternatively, a branch can be the *official branch* for a (sourcepackage, pocket)
[16:59] <intellectronica> sinzui: sure, i'll review it
[16:59] <jml> the two concepts are independent.
[16:59] <jml> al-maisan, furthermore, a branch can be the official branch for more than one (sourcepackage, pocket) ISTR
[16:59] <al-maisan> jml: can be the can be the *official branch* for a number of (sourcepackage, pocket) items?
[17:00] <al-maisan> ah
[17:00] <abentley> allenap: AIUI, this method is called in a thread from a long-running process.  Correct?
[17:00] <allenap> abentley: Yes.
[17:01] <abentley> allenap: Have you considered passing a transports parameter into it from the long-running process?
[17:01] <jml> al-maisan, this is deliberate. I'm beginning to think it's also misguided.
[17:01] <al-maisan> jml: is it correct to assume that in such a (sourcepackage, pocket) collection a sourcepackage.distroseries only appears once?
[17:01] <intellectronica> sinzui: i don't understand the way you structured that conditional around line 32 of the diff
[17:01] <abentley> allenap: That would presumably limit you to one SSH connection per long-running process.
[17:01] <jml> al-maisan, I'm afraid not.
[17:01] <intellectronica> sinzui: why do you need an extra if?
[17:02]  * sinzui should have annotated the cover letter
[17:02] <al-maisan> jml: how's that beneficial?
[17:02] <allenap> abentley: That's certainly a possibility, quite an easy one to do. The transports will go for no more than 10 minutes without being used. Is that likely to cause problems? What happens if bazaar.launchpad.net goes down? Will bzrlib cope?
[17:02] <jml> al-maisan, that's all you have to work with in terms of assumptions: http://pastebin.ubuntu.com/296938/
[17:02] <al-maisan> ah
[17:02] <jml> al-maisan, I'm not sure it _is_ beneficial :)
[17:02] <al-maisan> aha :)
[17:03] <jml> al-maisan, but the code you write here has to work with our current model
[17:03] <al-maisan> jml: that's understod.
[17:03] <abentley> allenap: I'm not sure how bzrlib reacts if the host goes away while a connection is open.
[17:03] <sinzui> intellectronica: There are two kinds of errors the user can get when setting a sourcepackage for a series: the first rule that exists is that you cannot reuse the the exact combination of distroseries, sourcepackage, and productseries.
[17:04] <al-maisan> jml: hmm .. this looks a bit funny:  UNIQUE, btree (distroseries, sourcepackagename, pocket)
[17:04] <abentley> allenap: I'm more worried about the fact that transports weren't designed to be thread-safe, so you'd have to take care of that yourself.
[17:04] <sinzui> intellectronica: The error gets its own message because the problem is locale to the series being edits
[17:04] <jml> al-maisan, that means...
[17:05] <intellectronica> sinzui: but why `message="..."\n if message:...`? you don't need that if
[17:05] <jml> al-maisan, I'm on a call I want to keep short. you'll have my full attention in a minute
[17:05] <al-maisan> jml: sure
[17:05] <sinzui> intellectronica:sorry. I have the plague and I and thinking is a challenge
[17:06] <allenap> abentley: I think gary_poster must have had that problem because the custom BzrPoller we use overrides buildbot's to avoid concurrency already.
[17:06] <al-maisan> jml: well, if I am to check whether we can upload to a pocket and a number of (distroseries, pocket) combination can appear in that storm result set, the question is which one should I check..
[17:06] <sinzui> intellectronica: That is crack I should have removed when I refacteded the branch between commits
[17:06] <allenap> abentley: Meaning: gary_poster wrote the custom poller afaict.
[17:06] <gary_poster> riht
[17:06] <gary_poster> right
[17:06] <al-maisan> maybe all of them and be satisfied when I hit the first one that "passes"
[17:07] <intellectronica> sinzui: also, when you have a multiline conditional (like around line 38), it's nice if you can add a comment immediately before the then clause, so that it's clearer where the condition stops and the statements to execute begin
[17:08] <intellectronica> sinzui: ditto near line 46
[17:08] <al-maisan> jml: I guess I am a bit confused since there can be one "current" source package release in a distro series and I assumed that an official branch would be linked to that ..
[17:08] <sinzui> intellectronica: okay
[17:08] <sinzui> I can add comments
[17:08] <intellectronica> cool
[17:09] <abentley> allenap: I don't think Launchpad PQM Bot should be subscribed to code review email.
[17:09] <allenap> abentley: No, that seems odd.
[17:09] <intellectronica> sinzui: it's a bit strange when you set next_url to the value of cancel_url, becuase even though it's the correct url, it implies that you're canceling
[17:09] <sinzui> indeed
[17:10] <intellectronica> sinzui: i would add another property, even though it's inefficient, just for readability
[17:10] <allenap> abentley: I don't have the power to fix that. You?
[17:10] <sinzui> I can define next_url and and set cancel_url from it.
[17:11] <abentley> allenap: Yes.  I've left it subscribed, so it can see the branch, but with no email options set.
[17:11] <intellectronica> sinzui: yeah, i think that's the best solution
[17:12] <allenap> abentley: The code that calls getRawChanges catches all exceptions, so wouldn't crash if bzrlib went awry due to a failed transport being passed in. But I wonder if (a) keeping those transports around would cause problems on all subsequent runs (so requiring a restart of buildbot), or (b) if we emptied the list of transports after an exception would we leak processes again?
[17:13] <intellectronica> sinzui: i'm not sure about the improved description for the packaging field. it's a lot nicer, but i wonder if users will find the concrete examples helpful. i, for example, have no idea what cadaver and libneon do, so mentioning them only serves as a distraction
[17:13] <intellectronica> i know what apache is, though sometimes i wish i didn't
[17:13] <sinzui> intellectronica: yes. I struggled with that example
[17:14] <sinzui> intellectronica: INCLUDE is a rare condition. upstreams rarely need to know about that
[17:14] <abentley> I don't think a is true.  Transports are meant to be reused.  b might be true.
[17:14] <intellectronica> sinzui: i would cut right after the question. i think it's formed clearly enough that users will be able to rely on it alone to understand
[17:15] <jml> al-maisan, back. really sorry about that. team standup.
[17:15] <sinzui> oh, good. I was tempted to do that, but thought saying more would help
[17:15] <jml> al-maisan,  UNIQUE, btree (distroseries, sourcepackagename, pocket) just means that each SuiteSourcePackage has exactly one official branch.
[17:16] <jml> al-maisan, the goal is for there to be official branches for every SuiteSourcePackage
[17:16] <intellectronica> sinzui: i find the way you format the call to dict on line 222 a bit strange. i think that if you use the function call, you should avoid the trailing coma
[17:17] <jml> al-maisan, as for which one to check
[17:17] <jml> al-maisan, I think you should check all of them and the real question becomes whether the results are ANDed or ORed.
[17:18] <sinzui> intellectronica: I agree with you. I should not have use a trailing comma.
[17:20] <jml> al-maisan, Really, you're right and the model is wonky here. I'd recommend ANDing them (since it's more restrictive) and we can chase up a more restrictive model w/ james_w and cjwatson.
[17:21] <al-maisan> jml: I am trying to think whether OR'ing them would be OK as well
[17:22] <intellectronica> sinzui: the rest looks great, so r=me with these changes
[17:23] <sinzui> intellectronica: Here is the incremental: http://pastebin.ubuntu.com/296953/
[17:23] <jml> al-maisan, if a distroseries is closed for a pocket then it should be impossible to upload to the associated branch, I think.
[17:24] <al-maisan> jml: I agree, however, there's that one-branch-to-many (sourcepackage, pocket) relationship
[17:24] <intellectronica> sinzui: perfect
[17:25] <jml> al-maisan, fwiw, with the real data, the relationship is in fact 1:1
[17:25] <al-maisan> so, if any of the (sourcepackage, pocket) combinations become non-valid i.e. karmic/release after Nov. 1st
[17:25] <al-maisan> jml: that's good news
[17:25] <al-maisan> in which case we should reconsider the following constraint:
[17:25] <al-maisan>     "seriessourcepackagebranch__ds__spn__pocket__key" UNIQUE, btree (distroseries, sourcepackagename, pocket)
[17:26] <jml> umm, don't you mean, "add a uniqueness constraint to branch"?
[17:27] <al-maisan> I thought a seriessourcepackagebranch contraint like (distroseries, sourcepackagename) probably makes more sense 
[17:28] <jml> no, because that would make it impossible to have an lp:ubuntu/karmic-security/openssh branch and an lp:ubuntu/karmic/openssh branch
[17:28] <al-maisan> but then it depends how seriessourcepackagebranch will be used
[17:28] <al-maisan> jml: maybe we could have brief voice call
[17:28] <jml> al-maisan, sure.
[17:28]  * al-maisan fires up skype
[17:31] <jml> al-maisan, ?
[17:31] <al-maisan> jml: just a second
[17:32] <intellectronica> bac: need a reivew?
[17:33] <bac> intellectronica: yes, please.  i was waiting for the MP to show up before asking but got distracted.
[17:33] <bac> intellectronica: it'll be your easiest of the day
[17:33] <intellectronica> bac: so that's just an old test reinstated, right?
[17:33] <bac> indeedy
[17:33] <bac> intellectronica: and a smidgen of drive-by
[17:35] <intellectronica> bac: looks fine, r=me. thanks for remembering to reactivate that test
[17:35] <bac> intellectronica: thanks
[18:06] <leonardr> intellectronica, henninge, or abentley: a very simple branch for one of you
[18:07] <leonardr> https://code.edge.launchpad.net/~leonardr/lazr.authentication/correct-scheme/+merge/13586
[18:07] <henninge> leonardr: I am on it
[18:14] <henninge> leonardr: looks nice!
[18:15] <henninge> leonardr: shouldn't the base class do some check if self.AUITH_SCHEME actually exists or provide a default value?
[18:15] <henninge> Or am I being over-paranoid?
[18:15] <leonardr> hmm
[18:15] <leonardr> there's no sensible default value
[18:16] <leonardr> if you forget it with a new authentication class, the crash will happen at the appropriate time (when you try to use the authentication for the first time, before you commit anything)
[18:16] <leonardr> so i think it's ok
[18:17] <henninge> leonardr: ok, but please add a comment to the base class saying that derived classes need to implement this.
[18:17] <henninge> to the doc string
[18:20] <henninge> leonardr: r=me
[18:31] <rockstar> henninge, can I hop into your queue?
[18:32] <henninge> rockstar: no queue, just forgot to update the topic
[18:32] <henninge> ;)
[18:32] <rockstar> henninge, okay, I'll send it directly to you then.
[18:32] <henninge> rockstar: show me the mp
[18:32] <rockstar> henninge, sending now.
[18:34] <leonardr> henninge, abentley: even more trivial than my last branch: https://code.edge.launchpad.net/~leonardr/lazr.restful/0.9.13/+merge/13588
[18:38] <henninge> leonardr: r=me
[18:41] <rockstar> henninge, https://code.edge.launchpad.net/~rockstar/launchpad/code-import-cvs-oops/+merge/13589
[18:48] <rockstar> henninge, how's it going?
[18:48] <henninge> rockstar: done, r=me
[18:49] <rockstar> henninge, thanks!
[18:58] <barry> henninge, abentley-lunch ping.  i have a very simple branch
[18:58] <henninge> barry: bring it on
[18:58] <barry> henninge: thanks! mp'ing it now
[19:18] <barry> henninge: it's almost ridiculously trivial :)  https://code.launchpad.net/~barry/launchpad/mm2112/+merge/13591
[19:20] <henninge> barry: the trivality is soothing at this hour ... ;-)
[19:20] <henninge> barry: r=me
[19:21] <barry> henninge: thanks! :)
[20:53] <EdwinGrubbs> sinzui: can you do a UI review of this MP (screenshot links in the last comment). https://code.edge.launchpad.net/~edwin-grubbs/launchpad/bug-426899-ppa-links/+merge/13505 
[20:56] <sinzui> EdwinGrubbs: I really think that the link to "PPA packages related to Curtis Hovey" should be (i) Related PPA packages
[20:56] <EdwinGrubbs> sinzui: sounds good
[20:57] <sinzui> hmm. My page is wrong too
[20:57] <sinzui> Has my hate for these pages evolved to apathy. I am not even surprised that they are wrong
[20:57] <sinzui> Why would motus trust these page?
[21:04] <EdwinGrubbs> sinzui: which piece of information is wrong on your page?
[21:05] <sinzui> EdwinGrubbs: That package in my ppa is superseded. I expected to see the one that users can download.
[21:06] <sinzui> EdwinGrubbs: have you looked at my related projects. I weep every time I see that page
[21:06]  * sinzui thinks team participation has no place in related projects or packages
[21:08] <EdwinGrubbs> sinzui: I don't think that is as big of a problem for people that are not in the Registry Administrators team.
[21:09] <EdwinGrubbs> rockstar: can you do a secondary ui review of https://code.edge.launchpad.net/~edwin-grubbs/launchpad/bug-426899-ppa-links/+merge/13505
[21:10] <sinzui> I found a bug relating to it. jml had agreed with the issue. And scottk was concerned too. All 3 of us are concerned. rarely can one issue unite three disparate personalities like this one
[21:11] <rockstar> EdwinGrubbs, sure.
[21:13] <rockstar> EdwinGrubbs, looks good.
[23:41] <jml> sinzui, huh what?