[00:00] <lifeless> benji: around?
[00:00] <lifeless> benji: would like to briefly talk about 'logs' w/you.
[00:01] <lifeless> if not, thats fine too, we can sync another time, no rush.
[00:07] <lifeless> ahahhaha
[00:07] <lifeless> https://oops.canonical.com/oops/?oopsid=OOPS-c182f7f94210ede212ae5b835ef993c7#longstatements
[00:11] <wgrant> lifeless: Hm?
[00:14] <lifeless> 8.5 second query
[00:14] <lifeless> to grab products
[00:14] <lifeless> https://bugs.launchpad.net/launchpad/+bug/1016156
[00:14] <_mup_> Bug #1016156: ProjectGroup:+index timeout due to slow query of subprojects <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1016156 >
[00:15] <wgrant> lifeless: I don't think that's real
[00:15] <wgrant> lifeless: Given that the same query took 4ms 6ms earlier.
[00:15] <lifeless> indeed
[00:15] <wgrant> xmlrpc-private
[00:15] <lifeless> GIL interference is a possibility
[01:41] <lifeless> is there a faq / updated docs for the new ec2 land setup ?
[01:43] <StevenK> New as in lp-dev-utils?
[01:43] <lifeless> yeah
[01:43] <lifeless> time I fixed my landing setup
[01:43] <lifeless> so I can land bzr+ssh://bazaar.launchpad.net/~lifeless/launchpad/sourcecode-meta
[01:44] <StevenK> lifeless: Uses the same creds as when it was in bin/
[01:45] <StevenK> lifeless: I have a checkout of lp-dev-utils in ~/launchpad and a symlink into it from ~/bin
[01:45] <lifeless> I have questions like: is it a package, do we run it from source?
[01:45] <lifeless> StevenK: and I'm sure other folk who join the team will need to know, which is why my *first* question was on docs ;)
[01:46] <lifeless> StevenK: I do appreciate the direct help.
[01:46] <lifeless> StevenK: I guess I"m trying to do two separate but overlapping things.
[01:49] <StevenK> lifeless: https://dev.launchpad.net/EC2Test
[01:53] <lifeless> thanks
[01:57] <wgrant> lifeless' branch is cursed.
[01:58] <wgrant> With an early MP, again
[01:58] <wgrant> Hmmm
[01:58] <StevenK> I've been waiting for the scanner before proposing
[01:58] <StevenK> Which is annoying
[02:07] <StevenK> Does dev log oops into /var/tmp/lperr?
[02:07] <wgrant> If you kill rabbit, yep
[02:08] <StevenK> And if rabbit is running?
[02:08] <wgrant> You'll need to run an amqp2disk
[02:08] <wgrant> So kill rabbit
[02:09] <lifeless> or run an amqp2disk :P
[05:32] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/destroy-bprc/+merge/111542
[05:34] <wgrant> StevenK: Looking
[05:35] <wgrant> StevenK: yay
[05:56] <StevenK> wgrant: And https://code.launchpad.net/~stevenk/launchpad/drop-populate-branch-ap/+merge/111544
[05:59] <wgrant> StevenK: You ran it on DF?
[05:59] <StevenK> Running
[06:00] <wgrant> Great
[06:00] <wgrant> r=me
[06:02] <StevenK> wgrant: Hm, I'm not sure it is useful to change samepledata for it. There are two private branches in it.
[06:03] <wgrant> StevenK: Ah, indeed, that's a good point. Run it over both sets of sampledata.
[06:03] <wgrant> And manually delete the scriptactivity rows that it creates.
[06:03] <wgrant> (make sure you limit garbo to just that one job)
[06:03] <StevenK> I did so for DF too
[06:04] <wgrant> And do review the sampledata diff to make sure it's sensible.
[06:05] <StevenK> Oh, default LPCONFIG and the other is testrunner or something?
[06:05] <wgrant> LPCONFIG=development and LPCONFIG=test-playground
[06:05] <wgrant> development is usually the default
[06:14] <StevenK> wgrant: sampledata changes pushed to drop-populate-branch-ap
[06:17] <wgrant> StevenK: LGTM
[06:18]  * StevenK lp-lands
[06:34] <rick_h_> lifeless: commented on the bug, will try to get a branch that nukes it out in the morning
[07:17] <lifeless> rick_h_: \o/
[07:53] <adeuring> good morning
[08:41] <ivory> rick_h_: it's https://bugs.launchpad.net/launchpad/+bug/824292
[08:41] <_mup_> Bug #824292: DistroSeries page: "Show uploads" vs "All uploads" <confusing-ui> <easy> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/824292 >
[08:44] <cjwatson> StevenK: any further comments on https://code.launchpad.net/~cjwatson/launchpad/pcj-reupload/+merge/111124, or should it be "Status: Approved"?  I've given up on the removeSecurityProxy avoidance I wanted to do, although if you have any bright ideas on that I'm certainly listening.
[08:46] <cjwatson> QA might be exciting.  I guess I'll need ops to create me a p3a on qas or something, when the time comes
[08:47] <cjwatson> StevenK: I have http://paste.ubuntu.com/1053911/ in my local tree; but those are pre-existing bugs, I believe, and I think I might be better off fixing them in separate branches
[08:50] <StevenK> cjwatson: I'm not certain the package copier even supports custom uploads.
[08:51] <StevenK> cjwatson: However, I agree with you,the XXX's are fine for the moment, and you can address them in later branches.
[08:52] <cjwatson> Those are uncommitted XXXs, but maybe I should commit them
[08:54]  * cjwatson does so
[08:54] <cjwatson> Direct copies don't support custom uploads, but I think delayed copies do.
[08:54] <cjwatson> In fact I know they do.
[08:55] <cjwatson> So it's sort of technically a regression; but it only matters if they publish d-i or dist-upgrader updates.
[08:55] <cjwatson> Oh, hm, wait, does it matter for translation tarballs?
[08:56] <cjwatson> Maybe I need to fix these in a separate branch *first* :-(
[08:56] <cjwatson> Otherwise I can imagine hilarity if there's some kind of firedrill security update.
[09:03] <jml> hello
[09:04] <jml> with reference to my question yesterday,
[09:04] <jml> 'bzr branch https://code.launchpad.net/$FOO' works
[09:04] <cjwatson> Fortunately copying custom uploads was on my to-do list anyway, so I guess this just moves it around.
[09:07] <lifeless> jml: we have a fake bzr branch metadata served by LP at that location.
[09:08] <lifeless> jml: it will work for any series as well
[09:16] <jml> lifeless: thanks.
[09:22] <jam> cjwatson: I've been tasked with trying to clean up some space from the librarian, and it was recommended that I talk to you about space being used by the primary archive.
[09:32]  * cjwatson is on -ops too, so either way
[14:54] <sinzui> yo, deryck, jcsackett, rick_h_. I am looking at the bug tag editor. It flashes green on failure, I think this should be red. It flashed red on cancel...even though the UI is restored
[14:55] <sinzui> should I reverse the colours?
[14:55] <jcsackett> sinzui: red on fail sounds good to me.
[14:55] <jcsackett> was pretty sure that was our standard.
[14:55] <rick_h_> +1 sinzui
[14:56] <rick_h_> I think it's probably wired green because of successful ajax call or something like that. See that a lot
[14:56] <sinzui> rick_h_, that is my conclusion as well
[14:57] <deryck> yeah, agree with the above :)
[14:59] <sinzui> gentleman, I have some confidence that I will add tag completion to +filebug and search today
[14:59] <rick_h_> woot!
[15:00] <jcsackett> sinzui: you're a hero. :-)
[15:01] <sinzui> No, I am just tired is mis-spelling bug tags when I file and search for bugs
[15:45] <flacoste> rick_h_: do you have a link to the morph component you want to send to the YUI gallery%?
[15:45] <flacoste> rick_h_: codebrowse link would be fine
[15:47] <rick_h_> flacoste: sure, sec
[16:24] <mrevell> Hey deryck, got time for a quick call?
[16:24] <mrevell> no worries if not
[16:25] <deryck> mrevell, sure, I can.  Just you and I or someone else?
[16:25] <mrevell> Just me :)
[16:26] <deryck> mrevell, hangout?
[16:47] <sinzui> jcsackett, I don't see reviewer about. Could you review this branch since it follows up on the branch you reviews yesterday. https://code.launchpad.net/~sinzui/launchpad/bug-tag-enhacement/+merge/111639
[16:58] <jcsackett> sinzui: sure.
[17:06] <rick_h_> sinzui: commented, thanks for that cleanup. Makes a bunch of sense.
[17:06] <sinzui> thank you!
[17:07] <sinzui> rick_h_, I look for support for passing a list of nodes
[17:07] <sinzui> It did not seem to be supported
[17:07]  * sinzui is happy to pass a list
[17:09] <rick_h_> sinzui: yea, I thought you could just pass a list but I couldn't get that to work in the fiddle with 3.4, but a nodelist worked
[17:09] <rick_h_> sinzui: the one tricky bit is that &nbsp; you had, so I wrapped that into a span so it was a node
[17:09] <rick_h_> hopefully doesn't effect anything else
[17:10] <sinzui> the nbsp is a hack. Maybe I want a css rule input + button {padding-left: .5em;}
[17:10] <rick_h_> yea, probably better in the long run
[17:10] <sinzui> I will try that
[17:11] <rick_h_> so yea, if the NodeList works for you then you can also drop a bunch of the var XXXX at the top as well hopefully
[17:11] <rick_h_> since I think they were just for HIDDEN class bits and then for your .append()'s
[17:12] <sinzui> yep
[17:16] <rick_h_> sinzui: can I bug you to peek at: https://code.launchpad.net/~rharding/launchpad/remove_mustache/+merge/111633 and sanity check that's all I need to do for removing that sourcedep
[17:31] <jcsackett> sinzui: I see rick_h finished up whilst i was looking at it, but r=me.
[17:40] <rick_h_> abentley: can you peek at the above MP ^ if you have a chance?
[17:40] <abentley> rick_h_: sure.
[17:40] <rick_h_> ty
[17:41] <rick_h_> one liner ftw! but finding that one line...
[17:41] <replaceafill> sinzui, i asked you yesterday about LP: #210821
[17:41] <_mup_> Bug #210821: bug tracker list shows inactive projects <404> <bugwatch> <lp-bugs> <oops> <trivial> <Launchpad itself:Triaged> < https://launchpad.net/bugs/210821 >
[17:41] <replaceafill> sinzui, this is the test i wrote: http://pastebin.ubuntu.com/1054651/
[17:42] <abentley> rick_h_: Do you think that forking Mustache is a good long-term solution?
[17:44] <rick_h_> abentley: well, the long term solution is to replace handlebars with mustache in 3.5
[17:44] <rick_h_> abentley:  possibly pybars, but in order to do combo loading we have ot subsume mustache into our build dir
[17:45] <abentley> rick_h_: It was a symlink already.  There shouldn't be a problem putting a symlink into our build dir.
[17:45] <rick_h_> abentley: right, but it's not a YUI module
[17:45] <rick_h_> that's why we subsumed it, so it could be combo loaded/wrapped
[17:46] <abentley> rick_h_: But you can turn it into a module as part of the build phase, right?
[17:46] <rick_h_> I suppose we could generate the YUI file as a special case for that module.
[17:47] <rick_h_> abentley: but in talks with deryck the decision was to move towards taking over/owning the JS we use such as the accoridion widget, mustache, etc
[17:47] <abentley> rick_h_: I don't understand why that would apply to Mustache, but not to YUI, esp when YUI contains something some similar to Mustache.
[17:48] <gary_poster> jml, do you mind if I link publicly to the fabulous but depressingly large checklist you are working on? https://docs.google.com/a/canonical.com/document/d/1A8qTOYZd7p9dhjmlnnEKW46h38ydt9yNbmfgX3yhPGw/edit
[17:48] <jml> gary_poster: please go ahead
[17:48] <gary_poster> thanks
[17:48] <rick_h_> abentley: not following that last bit. Why we don't just copy YUI into tree?
[17:48] <abentley> rick_h_: If we have a bug that we've forked Mustache, then I'm fine with landing this.
[17:48] <jml> gary_poster: my desperate plea for help is only more likely to be answered for wider publicity
[17:49] <sinzui> replaceafill, That looks good. I think `login(ADMIN_EMAIL)` should be `login_celebrity('admins')` which avoids using the sampledata users that is more than an admin
[17:49] <gary_poster> jml, I thought as much. :-)
[17:49] <abentley> rick_h_: Why are we taking over/owning Mustache, when we're not taking over/owning YUI?  They are both libraries that we use.
[17:50] <sinzui> replaceafill, push your branch up and ask me to review it. I can land it with the change I requested
[17:50] <replaceafill> sinzui, great, thanks!
[17:50] <rick_h_> abentley: it's a matter of scope and YUI plays nice with the combo loader and mustache didn't. The original work to fork/take over mustache in tree is long gone/done. This just finishes the cleanup by removing the sourcedep
[17:51] <rick_h_> this was gone over when I originally added Y.app.mustache and got the green light after those discussions
[17:51] <rick_h_> abentley: I'll add a bug marking lp.app.mustache as needing to be deprecated as part of the yui 3.5 upgrade.
[17:51] <rick_h_> and XXX the current lp.app.mustache
[17:52] <abentley> rick_h_: I'd like a bug saying that we've forked mustache.
[17:54] <abentley> rick_h_: Because there aren't any meaningful changes in our fork.  It's all just packaging.
[17:55] <rick_h_> abentley: added 1016666
[17:55] <rick_h_> sorry #1016666
[17:55] <_mup_> Bug #1016666: launchpad contains a forked version of mustache.js <js> <yui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1016666 >
[17:56] <abentley> rick_h_: It may be a bug that mustache is used at all, but that's a different bug from the fact that we have a spurious fork.
[17:57] <rick_h_> abentley: sure, understand and added it. The two kind of fit together in my mind as I think about them together as a single issue
[17:57] <rick_h_> but understand, bug added that we've got the fork at all
[17:58] <abentley> rick_h_: to be clear: you've just now added two bugs?  What's the id of the second?
[17:58] <rick_h_> abentley: no, one bug, just iddn't add the # for the bot so repeated
[17:58] <rick_h_> I've only added a bug that we've forked handlebars and added a comment that there's a plan to move away from it.
[17:59] <abentley> rick_h_: I've changed your bug to "launchpad uses mustache.js" and I'm filing a new "launchpad has a spurious fork of mustache.js".
[18:02] <abentley> rick_h_: filed as #1016668
[18:02] <_mup_> Bug #1016668: launchpad has a spurious fork of mustache.js <Launchpad itself:Triaged> < https://launchpad.net/bugs/1016668 >
[18:05] <jcsackett> abentley, rick_h_: using mustache is a bug now?
[18:06] <abentley> jcsackett: rick_h_ thinks we should deprecate it and move to handlebars.
[18:07] <jcsackett> abentley: ah. okay, i'm down with that.
[18:07] <abentley> rick_h_: r=me
[18:07] <rick_h_> abentley: ty
[18:07] <rick_h_> jcsackett: eventually it's the master plan with YUI 3.5 having handlebars included. Combo loader, YUI upgrade, no more mustache is the goal
[18:10] <abentley> rick_h_: There's many a slip 'twixt the cup and the lip, i.e. we may not end up moving to handlebars.
[18:10] <rick_h_> abentley: understand, why I'm not arguing the two bugs with you. They are separate concerns.
[18:11] <abentley> rick_h_: Cool.
[18:13] <abentley> rick_h_: In fact, we could stay forked, but push it up as a branch of lp:mustache.js.  That would be cleaner IMO, but would make sourcecode necessary again.
[18:14] <rick_h_> abentley: right, this change is coming because lifeless wants to remove sourcecode and I'm working to help with that
[18:15] <abentley> rick_h_: What's the alternative to something like sourcecode?
[18:16] <rick_h_> abentley: I'm not sure tbh. package all the things?
[18:17] <abentley> rick_h_: We only have custom package for Python things, though.  I don't think we want python packaging of JS things.
[18:17] <rick_h_> abentley: https://code.launchpad.net/~lifeless/launchpad/sourcecode-meta/+merge/111527
[18:17] <rick_h_> abentley: well, there's work underway to package up yui itself, so that side will. Now outside of that yea, not sure how it'll be handled best
[18:19] <abentley> rick_h_: package it up as python or deb?
[18:19] <rick_h_> abentley: package yui 3.5 as a .deb
[18:20] <rick_h_> abentley: I'm trying to ec2 land this and getting an error https://pastebin.canonical.com/68740/
[18:20] <rick_h_> have you seen this with colo branches perhaps? It's my new dev setup though so might be something else I've not done right
[18:21] <abentley> rick_h_: I think if you specify a non-local branch, you have to use the merge proposal url.
[18:21] <rick_h_> I got the same error with the full url
[18:22] <rick_h_> hmm, maybe I gave it the branch url, let me look
[18:22] <rick_h_> ah yea, my bad
[18:30] <replaceafill> sinzui, merge requested
[18:30] <replaceafill> sinzui, let me know if you want me to change something
[18:31] <replaceafill> sinzui, i'll look for another trivial bug :)
[18:34] <sinzui> replaceafill, can you make a one line code change to login_celebrity('admin') so that sample data does not skew the results
[18:35] <replaceafill> sinzui, oops, i forgot that, sorry
[18:35] <replaceafill> will fix
[18:42] <replaceafill> sinzui, done
[18:44] <sinzui> replaceafill, I am landing the branch now
[18:44] <replaceafill> sinzui, thanks!
[18:58] <abentley> deryck: my mind is exploding because this assertion is failing: https://pastebin.canonical.com/68746/
[19:01] <deryck> abentley, let me look....
[19:02] <deryck> abentley, have you pdb'ed into it and looked at branch.unqiue_name vs what's in the keys?  maybe it's something as simple as one is unicode and one is a string, or some such?
[19:03] <abentley> deryck: I've only been able to reproduce it in script runs so far, but they are actually different URLs.
[19:04] <deryck> abentley, ah, hmmm, that is strange.
[19:04] <deryck> abentley, so it looks it up by what's in the keys list, but then doesn't match after the fact?  that makes literally no sense. :)
[19:05] <abentley> deryck: Here's an example: https://pastebin.canonical.com/68748/
[19:06] <abentley> deryck: So branch unique name is u'~person-name-100007/product-name-100002/branch-100008', but it matched '~person-name-100007/product-name-100002/unique-from-test-rewrite-py-line267-100043'
[19:11] <deryck> abentley, I'm not sure how that could happen. I'm sorry.  Maybe take a look at the entire result set rather than what is returned by the one call?  Just to get more ideas?
[19:12] <abentley> deryck: The resultset is one item long.  ResultSet.one errors if there is > 1 result.
[19:12] <abentley> deryck: (If you're expecting > 1, you use ResultSet.any)
[19:14] <abentley> deryck: Aha!  transaction.commit fixes it.
[19:17] <abentley> deryck: unique_name is kept up to date by a trigger, so I bet that's implicated.  Somehow.
[19:17] <deryck> abentley, ah, yeah, that makes sense.
[19:17] <deryck> changed out from under you.  yuck, that is hard to find.
[23:53] <cjwatson> StevenK: I've thought some more about https://code.launchpad.net/~cjwatson/launchpad/pcj-reupload/+merge/111124, and tracked down bug numbers for the remaining XXXes; I have another branch up for review that addresses copying of custom uploads, and I expect I'll be able to fix the P-a-s handling first thing next week since I now understand what's going on there.  Regarding the change of the delayed default, all the ...
[23:53] <cjwatson> ... non-test users are either explicit about what they want (in particular I was careful with Archive.syncSource(s)), are definitely OK with direct copies, or probably nobody has ever cared about whether they work with a private source archive (InitializeDistroSeries); so I'm confident at this point that the test suite will handle the rest.
[23:58] <cjwatson> StevenK: So, if you'd be happy to update Status, I'd be happy to land it at this point.  I think the chances of a security update in the interim that needs to include a debian-installer or dist-upgrader custom upload are negligible, and even if it does happen the worst case is that we need to publish those manually (which we're already doing a fair bit of anyway, until such time as my copy-custom-uploads branch lands).