[12:13] gary_poster: Dublin expense report comin' atcha [12:13] cool [12:29] benji, could you give me a summary of how you calculated your per diem--what days got what meals? This makes it easier for me to see where the money is coming from and if it matches up with the schedule I know about. I'll paste whatever yu give me in the expense claim [12:30] bac benji danilos call momentarily [12:31] gary_poster: sure: 1st Saturday: 1 dinner; Sunday: lunch & dinner; M T W F: dinner; last saturday: lunch and dinner [12:31] please double-check me, but I think that's "right" [12:32] the hotel per diem is 80 euro per night, six nights [12:32] benji, when was yellow team dinner? I paid for that for everybody else, and I think for you too? [12:32] oh! [12:32] you're right [12:32] thanks for catching that [12:33] if you can fix it, please do, if not reject it and I'll take care of it [12:45] benji, (1) that was Wed., right? (2) what was our dinner per diem again? :-P [12:45] 1) IIRC, 2) 20 euro [12:45] thanks [12:56] gary_poster: I can't find the no downtime deploy instructions, do you have a pointer [12:56] benji, it's something like ProductionChangePolicy [12:56] benji https://wiki.canonical.com/Launchpad/PolicyandProcess/ProductionChange [12:57] thanks guys [12:57] np [15:02] benji, please no rush to answer this, but for https://bugs.launchpad.net/launchpadlib/+bug/752282, would the change in comment 7 be sufficient? [15:02] <_mup_> Bug #752282: terminates python with "cannot connect to X server" < https://launchpad.net/bugs/752282 > [15:03] * benji looks [15:04] benji, also, would that be a super easy one to fix? Would you like me to try to do it, with your guidance, so that you feel someone is helping with that stuff, or would you rather just fix it yourself for speed's sake? [15:05] gary_poster: for the life of me, I don't see a fix suggested in comment 7 [15:06] benji sorry :-( comment 6 from Markus Korn [15:07] I guess that's actually a modification of your comment 5 [15:07] so it would be comment 5 + 6 [15:07] re. ease of fix: the "sniff the environment" fix shouldn't be too bad [15:08] then we have to roll it out though, right? [15:09] gary_poster: re. comment 6: I don't think it'll be that easy. keyringlib is structured in a stupid way, the client has no choice over which backend will be chosen and is given no notice of which will be chosen either, so backend-specific bits like that will have to be done in the keyring library itself (i.e., not in launchpadlib) [15:10] benji, yeah, that's what I understood. Make small change in keyring library; publish it to Ubuntu; declare success [15:10] right, once we change keyringlib we'll have to get that revision into Ubuntu; I don't think that'll be hard, just prolonged [15:10] right [15:10] * gary_poster wonders when oneiric closes [15:11] benji, if you'll coach me on this, I'll do it; or I can leave it for you. [15:12] go get'em tiger! (that's me coaching) [15:12] heh [15:12] ok [15:15] gary_poster: to check it out you do hg clone https://bitbucket.org/kang/python-keyring-lib [15:15] benji, wow, so this is easy but annoying, eh? Yeah, I was just working that out [15:19] benji, tests are very noisy with lots of tests that seem like they are spewing failures, but end with "Ran 34 tests with 0 failures and 0 errors in 0.255 seconds." That's as you expect? [15:21] there will be lots of noise, and several skipped tests (unless you have the right crypto libraries installed (or KDE) for example) [15:21] ok benji, cool. So...can I do this with TDD? Looking at keyring/tests/test_backend.py no [15:21] w [15:22] yep, you should be able to TDD it; I added some test infrastructure that should make that route not too painful [15:23] no downtime deploy done [15:23] benji, great [15:24] that was really easy; more people should be forced to do that, a little aversion therapy for deployments [15:24] benji, :-) it's nice if you go through the bugs you deployed and change their statuses [15:25] ok; is that something I should add to the procedure? [15:26] benji, dunno. wgrant did it and I appreciated it, so I was reciprocating. uh, pay it forward, uh. [15:26] I'll add it then. [15:28] ok, 19 bugs marked Fix Released [15:30] gary_poster: I just realized that that probably wouldn't be a good policy; a single revision might not actually fix a bug, we could prematurly mark them as fix released [15:31] I doubt I just marked any prematurely because they were all "Fix Comitted" before I marked them, but I don't think this is actually something we should do [15:31] benji, we have different statuses for this [15:32] * gary_poster doesn't recall off-hand [15:32] but in theory it should be something we can do deterministically and correctly, if the people working on the branch have done the right thing. [15:32] so the rule should be: mark all fix-committed bugs as fix-released and leave the rest alone? [15:32] it'd really be nice if the qa bot (or similar) did this [15:33] benji, I think so. I'm not sure if qa bot moves bugs to fix-committed if the commit is regarded as partial, but I don't think so... So, "yes" :-) people can correct it later if needed [15:34] k, I'll add that rule [15:38] I'm hungry. [15:49] benji, kwalitee: [15:49] def test_supported(self): [15:49] """Test the keyring's supported value. [15:49] """ [15:49] self.assertEqual(self.keyring.supported(), self.supported()) [15:49] return self.keyring.supported() [15:50] sorry that last line was supposed to be two [15:50] def supported(self): [15:50] return self.keyring.supported() [15:51] so IOW for gnome keyring, we are asserting that self.keyring.supported() == self.keyring.supported() . Mm, yeah, I'm keen to use this. :-P [16:36] heh, I hadn't noticed that one; unfortunately I'm not surprised [17:34] lunch [18:47] benji, I'm confused about bitbucket. I have a mercurial branch with changes I want. I now have an account at bitbucket. What now? I've tried various incantations, most recently "hg push ssh://garyposter@bitbucket.org/garyposter/python-keyring-lib" [18:48] Also tried "hg push ssh://hg@bitbucket.org/garyposter/python-keyring-lib" [18:48] two things: first, this is the command you want: hg push ssh://hg@bitbucket.org/kang/python-keyring-lib (it took me *forever* to figure that out) [18:49] benji, even though I don't want to mutate his branch yet? [18:49] second, unless you've been given committer access that won't work [18:49] benji I just wanted to put the branch up somewhere for review [18:49] and then make a pull request and all that [18:49] I've never done that. I just got committer privaleges. ;) [18:50] If you can figure it out, I can act on your pull request. [18:51] ok cool benji thx [19:02] benji https://bitbucket.org/kang/python-keyring-lib/pull-request/3/do-not-try-to-connect-to-the-gnome-keyring [19:05] gary_poster: did you note what Markus Korn said about DBUS_SESSION_BUS_ADDRESS and DISPLAY? Some values of DBUS_SESSION_BUS_ADDRESS are valid even if there is no DISPLAY. [19:06] so... hmm; we might just leave out the DISPLAY check and be good [19:06] benji, I must have misread. I thought he was saying that DBUS... will only be true of DISPLAY is true, so this was overkill [19:06] * gary_poster goes to reread [19:07] benji, "some value in DBUS_SESSION_BUS_ADDRESS implies a non empty DISPLAY." [19:07] benji, so my inclusion of DISPLAY is paranoia from his perspective [19:07] which was my intent :-) [19:08] right, and it's not logically required, but implies to me that some other values of DBUS_SESSION_BUS_ADDRESS are still fine even though DISPLAY is empty [19:08] in other words a non-empty DBUS_SESSION_BUS_ADDRESS is all we need to check for (and can ignore DISPLAY alltogether) [19:08] benji, what implies to you? his message, or my code? [19:08] his message [19:09] benji, I agree, but my intent was to be paranoid. [19:09] benji, I have no personal knowledge that what he said is correct [19:09] we can relax the requirement for DISPLAY later if need be I guess [19:09] benji, I am pretty comfortable saying, on a personal knowledge basis, that DISPLAY is necessary [19:10] benji, I don't feel strongly about it actually, but I am clarifying that this was my intent [19:10] if you feel strongly the other way, eh, I can remove it [19:10] obviously I prefer it the way it is [19:10] but...eh. :-) [19:13] gary_poster: here's an experiment that shows that what I read through the lines seems to be true: http://pastebin.ubuntu.com/657425/ [19:14] since we are talking about server systems, I can't decide if it is more or less important to allow the gnome keyring stuff to work without a DISPLAY [19:14] benji...that implies to me that what I've done is what we want, yeah? We don't want the gnome keyring to pop up in that case, right? [19:14] see above, I can't decide :) [19:14] benji, does the gnome keyring work on server systems? [19:15] that's a good question [19:15] I would think not [19:15] what with the GUI and all [19:15] I'm persuaded that the code as you have it is the way to go. [19:15] cool [19:46] heh, Tarek beat me to accepting your pull request [19:50] benji, they call me Firstname Lastname around these parts [19:51] gary_poster: what? [19:51] benji, see https://bitbucket.org/kang/python-keyring-lib/overview [19:51] LOL! [19:51] pretty clearly I didn't set up hg properly somehow [19:51] that is hilarious [19:52] benji, yeah I think I was glazing over some of the set up instructions--this is my .hgrc: [19:52] [ui] [19:52] username = Firstname Lastname [19:52] verbose = True [19:52] oops [19:53] I figured it was something like that. I bet that happens a lot. They should have code to reject that user name. [19:53] I'm still laughing about that. [19:53] yeah [19:53] :-) [20:08] benji, what do I do to get that python-keyring change in oneiric? [20:08] hmm, let me check my notes [20:08] gary_poster: The Debian maintainer/packager of python-keyring is Carl Chenet [20:09] also, Barry maintains the launchpadlib packages in Debian, so he might be useful at some point [20:10] Carl was very helpful last time I communicated with him (although Debian was frozen at the time so there wasn't much he could do for me). [20:11] also, I can do a keyring release, which I think Carl will want to feed into the packaging machinery [20:11] benji, so I just write him a nice email saying, hey, could you please get this in Debian? And then hope that...oh ok [20:11] benji, if it is not in Debian then Ubuntu can't get it, or at least it is a much bigger pain? [20:12] gary_poster: i'm trying to find where an event gets handled but can't find the registration. [20:12] notify(BugBecameQuestionEvent(self, question, person)) [20:12] that's my understanding; last time Leonard suggested/encouraged/something the Debian to Ubuntu route [20:12] ack benji [20:13] bac, ok lemme look [20:13] gary_poster: i expected to find a in the zcml for IBugBecameQuestionEvent but don't see one [20:13] bac: notifications to subscribers are handled synchronously, so you can pdb into the notify call and the looping over and calling the actual subscribers isn't too far down that rabbit hole [20:14] benji: i've done that in the past...but figured this should be discoverable by looking in the zcml [20:15] bac, this doesn't look there is a listener, I agree [20:15] some times inheritance stymies the grep-the-zcml approach [20:15] urgh. i guess rabbit hole diving it is [20:15] bac, I would be paranoid enough to do what benji describes, I must admit [20:16] but my guess is that it is a no-op [20:16] gary_poster: really? that's hard to believe [20:16] b/c i don't see the actions wired elsewhere [20:16] and very few admit to being as paranoid as I [20:16] :-) [20:16] but let me go pdb-ing [20:16] gary_poster: i told you benji would say that! [20:17] heh [20:19] :-) [20:23] gary_poster: looks like it is a noop [20:24] cool [20:24] we've got considerable code supporting that no-op [20:34] heh [20:35] rip it out! [20:36] I really want to get ec2 land chugging on this branch, anyone want a small (and possibly even slightly fun) JS review? https://code.launchpad.net/~benji/launchpad/bug-809511/+merge/70219 [20:52] I'll do it benji [20:53] gary_poster: great, thanks [20:53] :-) [20:57] benji, feel free to ignore this bikeshed color, but I suggest that you make the digit limit for a bug number 5, not 6. We do have branches to fix older bugs. Launchpad has three five digit bugs that are still open (https://bugs.launchpad.net/launchpad/+bugs). [20:57] https://bugs.launchpad.net/ubuntu/+bugs has 1 (not counting bug 1). [20:57] It's not a big deal, but my suggestion. [20:57] <_mup_> Bug #1: Microsoft has a majority market share mm, I got the branch to try and look at it locally, but I'd have to hack the code to make that two [20:58] benji, is there a way to check it out locally, or should I just stare at code? :-) [20:59] by "check it out" in this case I mean "look at it" [20:59] ...in action... [20:59] gary_poster: unfortunately the test data isn't condusive to actually trying it [20:59] yeah [20:59] ok [20:59] you could hack it just a little and see it work [21:00] eh, it's about EoD and I'm tired. I'll see it on qastaging :-) [21:00] :) [21:02] benji, did you consider updating "Y.DOM.byId('field.bug')" to "Y.one('#field.bug")"? [21:06] benji, approved, with the two questions I asked. Answer them as you see fit. :-) [21:06] * gary_poster runs away now. Bye! [21:06] gary_poster: I did, but it didn't work; I was too lazy to figure out why [21:06] thanks!