[00:15] <gary_poster> lifeless, fun idea.  I added it to the bug
[00:16] <gary_poster> night all
[00:27] <wallyworld__> StevenK: i can get a asus with i7-2670QM and 16GB RAM and 1920x1080 15.6" display for $1300. sounds ok i think
[00:32] <wgrant> That's huge.
[00:32] <wgrant> But nice res.
[00:33] <wallyworld__> wgrant: huge? you mean screen size?
[00:33] <wgrant> Yeah
[00:33] <wallyworld__> i wouldn't go smaller
[00:34] <wallyworld__> 15.6" is the smallest i've had ever
[00:34] <wgrant> I guess if you're using it as a desktop without an external monitor it might make sense.
[00:34] <wallyworld__> i have an external monitor too
[00:34] <wgrant> OK, so it doesn't make sense :)
[00:35] <wallyworld__> i like to move about a bit sometimes
[01:23] <gary_poster> lifeless, I was shutting down my juju instances and realized I forgot to give the new subunit/testtools/testrepository packages a whirl.  I just replaced everything on the master and slave and started a new run.  Everything seems great.  Once that packaging snafu is dealt with for subunit, everything looks good for a release from what I can tell.
[01:23] <gary_poster> thank you!
[01:24]  * gary_poster disappears again
[01:24] <StevenK> Bah
[01:24] <StevenK> Disappeared before I could tease him.
[01:35] <wallyworld__> StevenK: are you going to update factory methods to use info_type for branches?
[01:36] <StevenK> Down the line, yes.
[01:36] <StevenK> It's a bit premature right now.
[01:36] <wallyworld__> StevenK: ok. i've got some tests with placeholders for when that happens
[01:37] <StevenK> wallyworld__: I'm happy to sprinkle in information_type into makeBranch() in the current branch I'm doing.
[01:37] <StevenK> I just won't remove private yet
[01:37] <wallyworld__> StevenK: that would be nice, thanks
[01:37] <StevenK> wallyworld__: Aye, I shall.
[01:38] <wallyworld__> you ocr?
[01:38] <StevenK> I should be.
[01:38] <wallyworld__> i will have a mp soon :-)
[01:39] <StevenK> I'll be sure to give it the appropiate amount of attention.
[01:39] <StevenK> (IE, none at all.)
[01:43] <StevenK> cjwatson: Re your db branch, don't worry about the +8, it's a DB patch, and I don't think it should count.
[01:48] <lifeless> wgrant: have you read the browserid spec?
[01:53] <wgrant> lifeless: Not in depth, but I know roughly how it works.
[01:55] <wgrant> lifeless: Assuming it becomes semi-standardised and gains some widespread support, I see no technical reason to forbid it.
[01:55] <lifeless> the thing I wonder, quite apart from whether its a good idea
[01:56] <lifeless> is whether someone can create an openid thunk
[01:56] <lifeless> and we can avoid supporting it entirely
[01:56] <lifeless> wgrant: overhead is overhead
[01:57] <wgrant> Sure, one could pretty easily implement an OpenID provider which effectively proxies BrowserID.
[01:57] <lifeless> wgrant: I skimmed it about 6 months ago
[01:57] <lifeless> but the details are paged out
[01:58] <lifeless> so, if you can do that, one wonders my mozilla didn't just do that instead.
[02:01] <wgrant> lifeless: Well
[02:01] <wgrant> lifeless: Part of the idea of BrowserID is that browsers will implement it.
[02:01] <wgrant> So there'll be no bouncing around.
[02:01] <wgrant> The browser will authenticate directly with its keypair and a time-limited certificate signed by the provider.
[02:02] <wgrant> One could implement an OpenID gateway, but it would still involving hideous redirects and ugliness.
[02:09] <lifeless> wgrant: yes, I'm aware of that
[02:09] <lifeless> wgrant: my HTTP nazi hate just loooves that
[02:12] <wgrant> It does mean that you have to trust the browser, and you can't really seamlessly integrate server-side 2FA.
[02:13] <wgrant> But it in all otherwise a tonne less hideous, sick and wrong.
[04:18]  * wallyworld__ -> computer shop @#$%%$#!
[04:19] <StevenK> Hahaahaha
[04:19] <wallyworld__> bastard :-(
[05:34] <jtv> StevenK, wgrant: just had another silly idea… one of the more expensive parts of publishing is now the “ls -lR.”  Could we maybe kick that off earlier, using the MF?
[05:35] <wgrant> We might be able to, yeah.
[05:37] <jtv> It's getting hard to single out culprits now, but IIRC this was a relatively big one.
[06:04] <StevenK> wallyworld__: Are you back yet?
[06:46] <wallyworld__> StevenK: back. bloody traffic accident. took 1 hour for a 15 minute trip :-(
[06:50] <bigjools> haha
[06:50] <jtv> wgrant: interested in reviewing the scrubber change?  https://code.launchpad.net/~jtv/launchpad/bug-994650-scrub-faster/+merge/105169
[06:51] <wgrant> jtv: It would be my pleasure.
[06:51] <jtv> \o/
[06:54] <jtv> I think I'll grab some food, meanwhile.
[07:15] <wgrant> jtv: Looks good.
[07:15] <wgrant> jtv: I'm not sure if avoiding loading the POFiles is a useful optimisation at this stage, but it can't hurt.
[08:24] <wgrant> StevenK: Have you run the garbo job over dev and test sampledata?
[08:26] <StevenK> wgrant: Nope, I was going to do that with the db patch
[08:26] <wgrant> StevenK: Sounds reasonable.
[08:27] <wgrant> Just means you have to practice a bit of necromancy.
[08:27] <StevenK> Meh, the garbo job is still in db-devel ... :-)
[08:27] <wgrant> True
[08:28] <stub> Should garbo tasks become celery tasks, or should we keep the garbo infrastructure?
[08:34] <wgrant> I think it'll all become celery once that's stable.
[09:01] <jtv> wgrant: are you well?
[09:02] <jtv> You approved my branch without comments.  Naturally I'm concerned.
[09:07] <wgrant> Heh
[09:12] <nigelb> hahahahah
[09:12] <nigelb> jtv: remember to make some pep8 violations so you both can breathe easy :D
[09:13] <jtv> Thanks.  I'll try to remember that.
[09:13] <jtv> And if I don't, then wgrant can point out that I forgot.
[09:13] <nigelb> Heh.
[09:14] <StevenK> Oh, sure. "You forgot to make some silly mistakes in this branch so I can comment. Oh wait, I just did comment. Damn it!"
[09:40] <adeuring> good morning
[11:16] <rick_h_> morning adeuring
[11:16] <adeuring> morning rick_h_
[12:09] <jtv> Any reviewers about?  If so, have an MP!  https://code.launchpad.net/~jtv/launchpad/bug-994650-scrub-in-batches
[13:29] <czajkowski> morning
[13:31] <rick_h_> morning czajkowski early out west isn't it?
[13:32] <czajkowski> yes
[13:32] <czajkowski> 6:35
[14:00] <czajkowski> any advice folks https://answers.launchpad.net/launchpad/+question/196568
[14:17] <abentley> adeuring: is "name.find('/eggs') >= 0" equivalent to "'/eggs' in name" ?
[14:17] <adeuring> abentley: ah, sure...
[14:17] <abentley> adeuring: I find the latter more intuitive.
[14:18] <adeuring> right
[14:20] <abentley> adeuring: So most of this code is about determining whether the src directory is sys.path, and adding it if it's not?
[14:21] <adeuring> abentley: yes
[14:22] <abentley> adeuring: Have you tested this with lazr.jobrunner installed as an egg?  Seems like this kind of thing could easily break in that environment.
[14:23] <adeuring> abentley: I haven't tested it yet. But why should it break?
[14:24] <abentley> adeuring: I find the whole eggs/buildout thing magical, and I never know what's going to break it, so I would want to test it.
[14:25] <abentley> adeuring: In particular, I'd worry that /usr/bin/python -m celery.bin.celeryd_detach is not going to pick up all the other eggs that Launchpad installs.
[14:26] <adeuring> abentley: Have a look at the scripts in <lp-branch>/bin. Most of them are thin wrappers around a real script and just configure sys.path. Take celeryd as an example
[14:27] <adeuring> abentley: celeryd starts fine
[14:27] <abentley> adeuring: Sure, but most of them specify a giant load of paths.  I thought yours was just about adding one path.
[14:27] <adeuring> abentley: no: extended_path = [name for name in sys.path if '/eggs' in name]
[14:27] <adeuring> that adds the whole bunch
[14:28] <adeuring> abentley: the extra steps with this_path is about the development environment
[14:28] <adeuring> where lazr.jobrunner is not W"eggified"
[14:29] <abentley> adeuring: Is there any need to configure CELERYD_PREFETCH_MULTIPLIER now that we're using CELERY_ACKS_LATE?
[14:30] <adeuring> abentley: I am not 100% sure but don't want to test it either. I must admit that I did not understand the related docs fully...
[14:35] <abentley> adeuring: r=me
[14:35] <adeuring> abentley: cool, thanks
[14:47] <cjwatson> https://code.launchpad.net/~cjwatson/launchpad/db-packageset-score/+merge/105113 looks like it has sufficient review now - could somebody mark the MP as Approved for me and then I can land it?
[14:51] <adeuring> abentley: what were the jobs again which we wanted to run via celery on stanging/qastaging? i.e., which classs names should appear in jobs.celery.enabled_classes ?
[14:51] <rick_h_> cjwatson: done
[14:51] <abentley> adeuring: BranchScanJob.
[14:51] <adeuring> abentley: thanks
[14:53] <cjwatson> rick_h_: ta
[15:15] <rick_h_> abentley: https://code.launchpad.net/~rharding/launchpad/ga_combo/+merge/105219 for you when you get a sec pls
[15:16] <rick_h_> abentley: note that there's a lot of qualifications and such with it
[15:16] <rick_h_> looks worse than it is because of the file move/copy of the ga.js around :/
[15:16] <abentley> rick_h_: "a diff'd version"?
[15:17] <rick_h_> abentley: in the google-analytics directory is a diff to the raw google provided js file so that it strips the things against our 'outside js/css' policy
[15:25] <abentley> rick_h_: I don't think that copyright statement is correct.  They don't nest like that.
[15:25] <rick_h_> abentley: yea, wasn't sure about that. I tried to state the "Code below" to help clarify
[15:28] <abentley> rick_h_: I believe that including Google's code makes the whole file a derived work, so the header should be "Copyright 2012 Canonical Ltd, Copyright Google Inc." or similar.
[15:29] <rick_h_> abentley: ok, sounds reasonable to me. Is there someone I should run this by/check officially you know of?
[15:31] <abentley> rick_h_: You could try Amanda Brock.  The dept is https://wiki.canonical.com/LegalServices
[15:31] <rick_h_> abentley: ty
[15:34] <abentley> rick_h_: Where was this file before now?
[15:34] <rick_h_> abentley: icing/google-analytics/ga.js
[15:35] <abentley> rick_h_: So with this change, do we have it in three places?
[15:35] <rick_h_> abentley: yes, for the moment
[15:36] <rick_h_> we have to support both combo loader/non-combo loader users
[15:36] <rick_h_> I guess we could get rid of the copy in the app/js/google-analytics directory, only the .diff file is *required*
[15:37] <abentley> rick_h_: If we can get rid of a copy, that would be good.
[15:37] <rick_h_> abentley: yea, I don't think we'd lose anything. Will do.
[17:44] <gmb> Ursinha, czajkowski said you were looking for me.
[17:44] <Ursinha> gmb, yeah, I have a lot of questions about launchpad code... but will enter a session in a few minutes :/
[17:49] <gmb> Ursinha, Okay, let's try and catch up later on then. Some time after lunch if you're free.
[18:30] <lifeless> morning
[18:30] <lifeless> allenap: hi
[18:33] <lifeless> sinzui: \o/ \o/
[18:33] <sinzui> lifeless, I am glad you are happy
[18:38] <lifeless> sinzui: contact-this-team
[18:38] <sinzui> I was sure you were tracking that
[18:39] <lifeless> :)
[18:40] <czajkowski> sinzui: nice blog post have posted in all the places.
[18:40] <lifeless> I'm sure we'll still get admins of casual 'groups' making the same mistake, but hopefully at a much lower incident rate
[18:40] <sinzui> I wish I could have solved the Cc sender issue too, but the the objects need restructuring. I reverted aft 3 hours so that I could get your bug fixed
[18:40] <czajkowski> nods I know tis fine
[18:40] <lifeless> sinzui: thats a shame
[18:41] <sinzui> yes. barry and I over-specialised the recipient set object. I need to make it behave more like a normal object.
[19:33] <allenap> lifeless: Hi there.
[19:34] <lifeless> allenap: hi, if you'd like some voice time, I'd be delighted to do so.
[19:34] <allenap> lifeless: Cool, that sounds good. I've just seen your reply, so I'll read that.
[19:37] <lifeless> allenap: skype ?
[19:41] <allenap> lifeless: Is G+ okay? I don't have Skype installed right now.
[19:41] <lifeless> tis fine
[19:42] <lifeless> it has nearly as good echo cancellation
[19:42] <lifeless> which is, for high latency, esssssential
[19:43] <allenap> lifeless: Okay, invited.
[20:01] <rick_h_> lifeless: ping, when you get a sec
[20:48] <lifeless> rick_h_: pong; afk for a sec, but write here and I'll reply in a few
[20:48] <rick_h_> lifeless: working on wrapping the ga.js code into a YUI module so I can combo load it and drop the request/icing/etc.
[20:49] <rick_h_> lifeless: in code review, dealing with the copyright notice stuff came up and trying to figure out how to handle documenting the "This is a LP YUI module, all this code inside here is Copyright Google" as it is now
[20:49] <gmb> czajkowski, about?
[20:49] <rick_h_> lifeless: so came up to ping legal on it and legal is asking me " How do we get permission from Google to modify and redistribute their code?" and can't find anything atm
[20:50] <rick_h_> lifeless: think you were involved and wondered if you 1) know how to handle it or 2) know the info I can give legal about how we got/get permission from google to mod/distribute the ga.js script
[20:50] <rick_h_> lifeless: see https://code.launchpad.net/~rharding/launchpad/ga_combo
[20:53] <lifeless> interesting
[20:53]  * lifeless runs screaming
[20:54] <rick_h_> lifeless: so in particular looking at lib/lp/app/javascript/google-analytics/google-analytics.js commenting
[20:54]  * rick_h_ is waiting for bzr.lp.net to finish thinking
[20:54] <rick_h_> http://bazaar.launchpad.net/~rharding/launchpad/ga_combo/view/head:/lib/lp/app/javascript/google-analytics/google-analytics.js
[21:00] <lifeless> rick_h_:
[21:00] <lifeless> http://support.google.com/analytics/bin/answer.py?hl=en-GB&answer=1032389
[21:00] <lifeless> I believe flacoste checked with Google when we first put it in the tree
[21:01] <rick_h_> lifeless: rgr, I understood there was some conversation but wasn't sure if it was you someone else and didn't find any reference in the docs/code
[21:01] <lifeless> rick_h_: so why do you need to convert it to yui ? is it a combo loader limitation ?
[21:01] <czajkowski> gmb: looking for me ?
[21:02] <lifeless> rick_h_: or is it because you're going to batch it with all the other modules needed? Could we not not do that and just reference that one file via a combo loader url ?
[21:02] <rick_h_> lifeless: well, it was blocking/hanging when I was doing combo loader testing. If I make it a YUI module I can combo load it in the same request with the other JS on every page
[21:02] <lifeless> rick_h_: keeping the unaltered google file and unaltered async-loading snippet from google
[21:02] <lifeless> that would keep the delta lower too
[21:02] <rick_h_> so it's benifit of -1 request per page done, and servied via our combo loader removing one more thing in icing
[21:02] <lifeless> http://support.google.com/analytics/bin/answer.py?hl=en&answer=1008080
[21:02] <lifeless> - goes in the end of <head>
[21:03] <lifeless> you can serve via the combo loader just by using a combo loader url
[21:03] <lifeless> so its solely -1 request, per the very first page they land on
[21:04] <lifeless> rick_h_: or am I misunderstanding something about combo loader internals ?
[21:04] <rick_h_> lifeless: well in order for YUI to know how to request it from the combo loader we parse the YUI modules (make jsbuild) and it's listed
[21:04] <rick_h_> lifeless: but we could manually muck with/modify that I think
[21:04] <lifeless> rick_h_: nono, *not* yui
[21:04] <rick_h_> right, I gotcha
[21:04] <lifeless> if we use http://support.google.com/analytics/bin/answer.py?hl=en&answer=1008080
[21:04] <lifeless> which we probably do today
[21:05] <lifeless> and replace the url in it with one pointing at the combo loader
[21:05] <lifeless> we'll get back unaltered content.
[21:05] <lifeless> right ?
[21:05] <rick_h_> yes
[21:05] <lifeless> so just moving the url - trivial. No delta vs google's authoratitive copy.
[21:05] <lifeless> and still async, nonblocking on the page.
[21:06] <rick_h_> ok, so we can work with the async version, our old one just wasn't using that one?
[21:06] <lifeless> I don't know, you're the one doing the debugging :)
[21:06] <rick_h_> k, I'll pull down and compare tomorrow
[21:06] <lifeless> rick_h_: I gotta run, TL meeting; will pick this up after that.
[21:06] <rick_h_> rgr
[21:06] <lifeless> if we're blocking today, I'd say keep blocking, do the minimal work
[21:07] <lifeless> move the url to the combo loader, add a bug saying we should be async, move on :)
[21:23] <rick_h_> jcsackett: hey, have you been testing out/using the auto reloader for the JS?
[21:24]  * rick_h_ is curious
[21:28] <jcsackett> rick_h_: i have not.
[21:28] <jcsackett> how does one use that?
[21:29] <rick_h_> make jsbuild_watch
[21:29] <rick_h_> then just edit the js files and on save it'll auto jsbuild them
[21:29] <jcsackett> i will have to check that out.
[21:29] <rick_h_> that's the idea at least
[21:29] <jcsackett> that would make somethings *way* easier.
[21:30] <rick_h_> yea, I got wondering, I've not done a ton of JS since adding it, but seems you are
[21:30] <jcsackett> and the more i do, the more it seems i need to do. :-P
[21:30] <rick_h_> ruh roh
[21:30] <jcsackett> ah, the life of cleaning up old bad code.
[21:30] <jcsackett> :-P
[21:30] <rick_h_> that's the truth
[21:30] <rick_h_> give it a try next time and let me know if you hit issues
[21:30] <jcsackett> so, by "next time" you mean tomorrow? :-P
[21:31] <rick_h_> :)
[21:31] <rick_h_> I didn't want to presume
[21:31] <rick_h_> just deeper than you thuoght it was or issues you're hitting?
[21:31] <jcsackett> more things making use of it than i thought.
[21:31] <rick_h_> going to be hacking at the coffee house tonight if you need a second set of eyes on anything
[21:31]  * jcsackett nods.
[21:31] <rick_h_> ah, gotcha k
[21:32] <jcsackett> quick thought? know any reason that a BuiltClass from Y.Base.create might barf when it's constructor.NAME is grabbed?
[21:32] <jcsackett> in that, it's constructor has no .NAME.
[21:32] <rick_h_> yea, you didn't create the formal constructor. You'd have to inspect it and try to see if it even has a NAME property
[21:33] <rick_h_> I think you'd have to get it from your instance?
[21:33] <jcsackett> hm. wonder why Banner was fine but something derived from Banner dies ...
[21:33] <rick_h_> not sure, honestly, never used the NAME bit :/
[21:33] <jcsackett> i'm not either, YUI throws the error.
[21:33] <jcsackett> i'll keep poking.
[21:33] <rick_h_> well that NAME should change to the Base.create('ISNAME'... right?
[21:33] <rick_h_> make sure your requires is correct
[21:33] <rick_h_> the error I got today on that was waaay out of left field
[21:34] <jcsackett> already checked requires. would that it was that easy.
[21:34] <jcsackett> i'll keep poking. :-)
[21:34] <rick_h_> k
[21:38] <cjwatson> I forgot to add a COMMENT in db-devel r11582.  I guess since stub didn't comment on that during review it's not the end of the world; but is there anything I should do?
[21:38] <cjwatson> As in is it worth landing a follow-up commit?
[21:38] <jcsackett> rick_h_: just realized. no `new` call. :-P
[21:38] <jcsackett> it's always the little things.
[21:38] <rick_h_> jcsackett: ah, yea that one bites me all the time. I've learned that error hard core
[22:00] <sinzui> wallyworld, how goes the morning? What is your preferred means of voice today?
[22:03] <sinzui> jcsackett, mumble?
[22:03] <jcsackett> sinzui: yup. signing on.
[22:04] <sinzui> wallyworld, wgrant_ look at https://bugs.launchpad.net/launchpad/+bug/702429
[22:04] <_mup_> Bug #702429: Pillar owners and private non-security bug visibility <bugs> <disclosure> <qa-ok> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/702429 >
[22:05] <wgrant_> cjwatson: Not really, but you can if you want.
[22:09] <lifeless> cjwatson: it is worth it, jfdi it, and it can land on devel
[22:09] <lifeless> the comments are only used for dev machines anyhow
[22:18] <jcsackett> damn thunderstorms...
[23:53] <StevenK> wallyworld_: wgrant_ is stealing your thing!
[23:54]  * wallyworld_ wants it back