[08:04] <wgrant> Oops.
[09:40] <intellectronica> NCommander: is your change really that big, or is the diff in the MP wrong?
[09:40] <intellectronica> i see most of it is sample data changes
[10:14] <wgrant> intellectronica: Thanks. Can you land it?
[10:16] <intellectronica> wgrant: yup, submitting it for tests now.
[10:17] <StevenK> intellectronica: https://code.edge.launchpad.net/~stevenk/launchpad/fixes-bug-503258/+merge/21710 is the MP
[10:20] <intellectronica> StevenK: on it
[10:24] <wgrant> intellectronica: Thanks.
[10:28] <intellectronica> wgrant: why is your merge target db-devel? do you depend on anything not in devel?
[10:29] <wgrant> intellectronica: All the previous work is still only in db-devel.
[10:29] <wgrant> (there was a new table required)
[10:29] <intellectronica> ok
[10:31] <intellectronica> StevenK: why the call to debug in lib/lp/soyuz/model/queue.py? is that a leftover, or something you really want merged?
[10:32] <StevenK> intellectronica: It matches the previous call -- the bit I added is just for custom files associated with the upload
[10:33] <intellectronica> StevenK: also, the import in packagecopier.py is not alphabetically sorted. if you're using emacs or vi, b.t.w, there are helpers on the wiki to make sorting easy
[10:33] <intellectronica> ok
[10:34] <StevenK> intellectronica: Right, I can re-order them
[10:35] <intellectronica> cool
[10:36] <intellectronica> StevenK: you can use assertFalse instead of assertEquals(False, ... no?
[10:37] <StevenK> intellectronica: My unit testing memory is a little rusty, I'll do that too
[10:38] <intellectronica> StevenK: great. other than these two comments the branch is all goodness. make the changes and ping me and i'll land it.
[10:39] <StevenK> intellectronica: Changes pushed.
[10:39] <intellectronica> StevenK: lovely, thanks
[10:39] <StevenK> intellectronica: Thank you :-)
[10:39] <intellectronica> StevenK: oh, can you also please set the commit message?
[10:41] <StevenK> intellectronica: Done
[10:41] <intellectronica> cheers
[10:42] <StevenK> intellectronica: I'll land it after bigjools sorts out access
[10:42] <intellectronica> StevenK: oh, even better :)
[10:42]  * StevenK coughs in bigjools's general direction ;-)
[10:43]  * bigjools nods
[10:43] <wgrant> StevenK: I wonder if you should XXX the security change? Details on hacks are handy years later.
[10:45] <intellectronica> bigjools: r=me
[10:45] <bigjools> intellectronica: easy one huh? :)
[10:45] <bigjools> thanks
[10:45] <intellectronica> nothing's easy on a monday morning
[11:33] <noodles775> intellectronica: another one for you when you've time: https://code.edge.launchpad.net/~michael.nelson/launchpad/fix-buildd-slave-test/+merge/21847
[11:35] <intellectronica> noodles775: sure. also, can i bother you now for that ui review? should be pretty straightforward.
[11:36] <noodles775> intellectronica: yeah, that'd be great... I'll get mine ready for you too (a UI review).
[11:36] <intellectronica> cool
[11:47] <intellectronica> noodles775: https://code.edge.launchpad.net/~intellectronica/launchpad/bug-531963/+merge/21628 for my ui review
[11:48] <intellectronica> noodles775: and r=me on your branch
[11:49] <noodles775> Thanks intellectronica.
[12:01] <noodles775> intellectronica: why is it that if I'm logged in as cprov (celso.providelo@canonical.com:cprov) I'm unable to modify the bug status (the mouse-over tells me "Changeable only by a project maintainer or a bug supervisor"), yet I can as no-privs? Is no-privs a bug supervisor without privs in the project?
[12:02] <intellectronica> noodles775: are you sure that's status and not importance?
[12:02]  * noodles775 checks
[12:02] <intellectronica> let me see if i can get that effect locally
[12:03] <noodles775> intellectronica: right, the mouseover is from the importance icon, but I still can't change the status as Celso, but can as no-privs?
[12:04] <intellectronica> noodles775: cprov and no-priv behave the same for me. you can't change the importance, you can change the status, but asked to confirm.
[12:05] <noodles775> intellectronica: wierd... this is the bug I'm looking at: https://bugs.launchpad.dev/thunderbird/+bug/15
[12:05] <mup> Bug #15: PO file import errors should be more verbose <feature> <Launchpad Translations:Fix Released by carlos> <https://launchpad.net/bugs/15>
[12:06] <noodles775> intellectronica: on that page, clicking on the status for Mozilla Thunderbird always redirects to the +editstatus page, whereas Redfish works as expected.
[12:07] <intellectronica> noodles775: that's because that bug is assigned to a bugwatch
[12:07] <noodles775> Ah ok. Thanks. Two more things:
[12:07] <intellectronica> bugs that are tracked by a bugwatch can't have their metadata set by users
[12:08] <noodles775> First, I think the wording might be missing "whether"? eg. "If you're not certain whether changing the status of this bug is correct,..." What you you think?
[12:09] <noodles775> And second, how difficult would it be to first close the overlay before popping up the confirmation?
[12:09] <intellectronica> noodles775: as a non-native speaker i'll have to trust you on that. both some equally good to me
[12:09] <noodles775> I think that's quite important (a popup within a popup is really bad).
[12:09] <intellectronica> noodles775: very difficult
[12:09] <noodles775> :(
[12:09] <noodles775> intellectronica: couldn't in just be hidden with CSS when you bring up the confirmation?
[12:10] <noodles775> (ie. you shouldn't need to change the behaviour of the widget?)
[12:10] <intellectronica> that would be a great solution, and even better one would be to handle it within the widget itself. unfortunately both require a complete restructuring of that widget which we can't afford right now
[12:11] <intellectronica> noodles775: the problem is the way the widget interacts with the web service. it saves before closing, and changing that would require changing the widget, and quite possibly changing other widgets that use the api patch plugin
[12:40]  * intellectronica --> lunch
[15:12] <adiroiban> EdwinGrubbs: hi. I have updated my branch https://code.edge.launchpad.net/~adiroiban/launchpad/bug-540105/+merge/21552
[15:13] <adiroiban> it looks like the try/catch can still act as sandboxes
[15:13] <EdwinGrubbs> adiroiban: I'll check it after I get off of a call.
[15:30] <jml> does someone want to review https://code.edge.launchpad.net/~jml/launchpad/visible-dependencies/+merge/21807 ?
[15:31] <intellectronica> jml: sure, i'll review it
[15:31] <jml> intellectronica, thanks.
[16:38] <EdwinGrubbs> adiroiban: I'm wondering how you were able to cause some of the domready handlers to fail to run. This test page worked fine in chrome and firefox. http://pastebin.ubuntu.com/399378
[16:40] <EdwinGrubbs> adiroiban: I started looking at pofile.js to see if there was anything in there that would cause one error to affect another function. I didn't find anything conclusive, but I did find some global variables that should be made local, and that could have unexpected results.
[16:40] <adiroiban> http://paste.ubuntu.com/399381/
[16:41] <adiroiban> without try/catch, the Y.lp.pofile.initializeKeyBindings(); is not  called
[17:24] <adiroiban> EdwinGrubbs: if you think the try/catch are not needed, I can remove them :)
[17:26] <EdwinGrubbs> adiroiban: I am able to confirm the problem you were getting, but I'm still trying to understand why this is not happening in my simple example. I'll let you know in a few minutes.
[17:27] <EdwinGrubbs> adiroiban: while you are waiting, here are some problems in pofile.js that could lead to very hard to diagnose errors. http://pastebin.ubuntu.com/399412
[17:31] <EdwinGrubbs> adiroiban: ok, I think I've figured out why my example yielded different results. Since the html was so simple, the dom was immediately ready. Therefore, Y.on(domready) would immediately run the handler and the exception would cancel anything that was already registered, but there wasn't anything.
[17:32] <EdwinGrubbs> then, the next Y.on(domready) would get called from the html file and run the handler immediately.
[17:33] <EdwinGrubbs> adiroiban: therefore, your try/catch blocks are perfectly fine. However, there is no reason to have them in separate Y.on('domready') blocks, so you can combine them into a single Y.on(domready)
[17:36] <adiroiban> EdwinGrubbs: right. I will put them in a singly 'domready' block and will fix the errors from your previous pastebin. I'm just running the tests and then I will push the changes. Thanks!