[11:54] * gmb lunches [13:30] are we chatting? [13:30] bac: Gary's out until 10. [13:31] (I think). [13:31] (And I'm assuming that it's 08:30 for you) [13:31] bac: heh, apparently you and I have the same taste in bugs [13:32] benji: did you grab 211830 too? [13:32] almost ;) [13:32] gmb: yes, gary's out but his email ends with "agree among yourselves as to whether to actually have the call." [13:33] Oh. [13:33] i vote a strong -0 [13:33] Yeah, I'm firmly -0. [13:33] benji: the fix for that will be easy...generating the test data not so much [13:36] * danilos abstains [15:36] danilos: Do you have any idea why I'd be seeing this: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1980STAGING71 when looking at this: https://bugs.staging.launchpad.net/ubuntu/+source/bash-completion/+bug/752193 as an anonymous user? [15:36] <_mup_> Bug #752193: Installation of the acroread package causes completion to treat directories like files with some commands

< https://launchpad.net/bugs/752193 > [15:37] Wait... this makes no sense whatever. [15:37] danilos: Ignore me, I think something's broken with the OOPS machinery. [15:37] gmb, yeah, I think it seems to be the wrong oops prefix setting somewhere [15:38] gmb, actually, it seems as if staging is missing some oops configuration [15:38] Ah. [15:38] Botheration. [15:38] I shall talk to t'LOSAs. [15:39] gmb, I always get baffled when I see OOPSes like these, unfortunately, making sure that all the scripts have right oops prefixes is tedious :/ [15:39] danilos, approved expenses [15:39] gary_poster, cool, thanks (and welcome back :) [15:39] gmb, could talk to matsubara too [15:39] thanks :-) [15:39] danilos: Yeah. It's especially annoying since it seems to be a reproduction of the unreproducible bug. [15:40] gary_poster, I am sure you'd like to hear that with your and my branches merged, bugtask_index_portlets.js is entirely gone (along with subscriber.js) [15:40] yaay!!! [15:40] :-) [15:40] subscriberlist too, or is that used somewhere? [15:41] subscribers_list.js [15:41] gary_poster, I need to do a few more cleanups in my branches and then it's all up for review (6 branches total, not counting yours) [15:41] gary_poster, that's where I'm moving my stuff, but yes, existing methods from it are gone [15:41] cool :-) [15:41] danilos, how do you think we should get the review? I was thinking about this. When we actually merge, AIUI we'll be merging to devel [15:42] but setting that in the MP will create insane diffs [15:42] we could also review each other's branches outside of the MP system beforehand [15:42] gary_poster, right, I was thinking of getting branch-by-branch review; for me, it's going to be easy since lpreview DTRT with pipelines [15:43] (and then copy over the reviews when its actually time to merge) [15:43] danilos, well...you [15:43] gary_poster, that's an option as well :) [15:43] gary_poster, I'd be happy to review your branch [15:44] will need to get an MP based on my branch... [15:44] (I assume) [15:44] gary_poster, well, when does db-stable get merged into devel? On Monday? [15:45] I think so--maybe even Robert's Monday [15:45] gary_poster, (fwiw, I am not going to review your branch today, so if it's Monday, you can propose a merge against devel and it should become clean on Monday) [15:46] it would become clean once I merged Monday-merged-devel and pushed it [15:47] Which would be easy to do... [15:47] so yeah [15:47] I'll make an MP today [15:47] against devel [15:47] mark it as not ready for review [15:48] then my Sunday evening I'll see if db-devel has been merged with devel [15:48] and if it is [15:48] I'll merge devel in and push it and mark the MP as ready [15:48] gary_poster, shouldn't LP do this automatically? [15:48] I don't think so [15:48] gary_poster, (i.e. when the merge-target branch changes, it should recalculate the diff) [15:49] I could be wrong [15:49] we can find out :-) [15:49] gary_poster, ok then, you might not even have to merge anything but just do a "bzr ci --unchanged" to trigger a rescan [15:49] maybe so [15:49] danilos, the last part of this is merging in benji's rip-out-the-flag branch [15:49] I can do that today [15:50] gary_poster, well, than one is... "interesting"... I'd prefer to leave it for last [15:50] yeah, that's fine [15:50] gary_poster, (just because it's easier to re-do stuff in that branch if we get a weird conflict, then in other branches) [15:50] that was one of my options: make a new branch based on your last one [15:50] and then merge in benji [15:50] 's [15:51] benji probably doesn't want to be merged in; his family would be surprised [15:52] oh, btw danilos, I ran ec2 test last night on my branch. There were two errors. I didn't look at them closely, but I think they will be easy. So you'll need to get those fixes, maybe [15:53] so anyway, danilos, you ok with that plan for ripping out the feature flags? (1) you point me to the last branch of your work; (2) I branch it; (3) I merge in benji's branch and fix stuff up [15:54] gary_poster, right, I can re-merge your branch into the "base" of my branch [15:54] gary_poster, as for benji's branch, that'd be fine, but I'd like to do the remaining cleanups first [15:55] gary_poster, you can still get it merged with db-stable locally, but I'd only prefer not to have it landed first [15:56] danilos, completely agreed that it would be landed last [15:56] I just want us to have already handled the big changes that we have introduced [15:57] gary_poster, right, but considering we have not feature-flagged anything, I'd say that's pretty much a given [15:57] sorry, which part is a given? [15:58] gary_poster, big changes we have introduced should not cause too much complex merging issues with benji's branch [15:59] mm, maybe so. Probably just lots of those "yes, I *really* want to delete these parts, thanks" conflict resolutions [16:01] gary_poster, right, but sure, I'm pushing my final branch (well, all of them together) to lp:~danilo/launchpad/bug-772754-other-subscribers-remove-cruft [16:01] cool [17:00] danilos, if you are still around, are you planning on removing lib/lp/bugs/stories/bugs/xx-bug-personal-subscriptions.txt or on trying to make it sane in the new context? I've made it so it passes locally, but it shows how +subscribe only kinda sorta makes sense in the new world. I'm OK with that myself, and I'm inclined to check in as is, but it will affect you too, at the very least because there are "Subscribe [17:00] My current plan: check it in as is, have you deal with it :-P [17:01] gary_poster, sounds good to me, I am pretty sure I've still got a few tests to remove which are for all the removed views that gathered bits and pieces of all the subscriptions data [17:01] danilos, cool. I just pushed test fixes to lp:~gary/launchpad/bug-772754-2 . Going for walk/lunch now, so will talk to you Monday (and should have MP waiting for you then). Have a great weekend! [17:03] * benji now knows how to copy the Firefox saved password DB from one profile to another. [17:18] gary_poster, thanks, so do you! [17:24] Is it an unproductive day if you spent it mostly fixing other peoples' problems? [17:26] gmb, it's not unproductive for them! [17:27] Fair point. [17:27] anyway, out, enjoy all [17:51] gary_poster: I just submitted my EC2 expenses for April and May. I think they need approving before the weekend, but I can't remember what the cutoff is. [18:11] * gmb EODs. [18:47] gmb, benji, I approved your canonicaladmin requests [21:08] bac, you there? If so, do you happen to know how to look at the emails that launchpad.dev has sent out directly, via sendmail? In particular, I'm trying to validate a team's contact address so I can qa something locally that requires a team with a contact address [21:08] benji: hi gary_poster [21:09] hi [21:09] gary_poster: on my system, emails to bac@canonical.com get redirected to root@localhost [21:09] so i can read them locally [21:09] but bad emails don't leave a log anywhere? [21:09] i'm not sure what mechanism is actually doing that [21:09] yeah ok [21:17] gary_poster: after lots of investigation i closed a couple of bugs related to OOPS and email processing [21:17] cool, bac [21:18] gary_poster: examining the code i don't see how it is possible for an OOPS to be generated due to fixes abentley and mbp did a while back [21:18] great [21:18] though we have seen OOPS as recent as january...so it is a bit befuddling [21:18] I take it abentley/mbp fixes were before then? [21:19] yes but not by much [21:19] hm [21:19] no idea :-/ [21:20] authenticateEmail is called from exactly one place and it is now in a try/except InvalidSignature...the exception shown in the OOPS [21:20] heh [21:20] so, fingers crossed it is actually fixed [21:20] yeah, sounds reasonable to just wipe your hands [22:16] bac, are you @ EoD? [22:16] gary_poster: still here [22:16] finishing up a review then turning to a pumpkin [22:16] bac, how much longer? I'm seeing if I can get a branch reviewed [22:16] oh ok [22:16] cool, nm then [22:17] have a great weekend [22:17] no, i don't mind. [22:17] send it on [22:17] really really? [22:17] ok I will thanks [22:17] np [22:23] bac, https://code.launchpad.net/~gary/launchpad/bug792493/+merge/63431 [22:25] thx [22:26] I'll be back in about 15 [22:26] gary_poster: hey do you know if we have a preference in the for either en_US or en_GB ? [22:34] bac: Do you have a second to give me a quick review for this: https://code.launchpad.net/~gmb/launchpad/bug-772609-hopefully-without-breaking-anything-this-time/+merge/63432 [22:34] Fixes a bug with the fix for 772609 [22:36] gmb: done. late night! [22:36] bac: Yeah, it annoying me, so I thought I'd better fix it now rather than fixate on it over the weekend. [22:37] Thanks. [22:37] gmb: while you're here... [22:37] Yarp? [22:37] initialise vs. initialize in the UI? [22:37] bac: IIRC we use American English for the UI, so *ize. [22:37] i mean, written on the web page [22:37] there was some flip-flopping a while back and i wasn't sure where it landed [22:38] I'd go with initialize. [22:38] thanks. bye. [22:38] Np. [22:38] * gmb -> exeunt, in pursuit of beer [22:44] bac, I think it is US [22:45] yes, that's what i went with [22:45] cool [22:45] i do recall matthew saying something about en_GB being preferred...perhaps in the dev wiki? [22:45] I dunno [22:45] it confused me then and i haven't gotten over it [22:45] heh [22:46] If we are supposed to use GB, I haven't gotten the memo...ever. [22:48] gary_poster: the main part of your branch looks good and i don't have any comments on it. [22:48] cool bac. What's the non-main part of my branch? :-) [22:49] but on the handler detaching, previously we thought there might be multiple handlers and your code now reads as if we know there is exactly one [22:49] is that right? [22:49] bac, yeah [22:49] no one ever fires that event with multiple [22:49] ok [22:49] and it did not handle the case of single [22:49] ugh [22:49] cool, let me mark it approved. [22:49] (which was what was actually happening, so the detach was never happening) [22:50] cool. thank you much, bac. have a great weekend! [22:50] you too. [22:50] bye