[00:15] lifeless, fun idea. I added it to the bug [00:16] night all [00:27] 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] That's huge. [00:32] But nice res. [00:33] wgrant: huge? you mean screen size? [00:33] Yeah [00:33] i wouldn't go smaller [00:34] 15.6" is the smallest i've had ever [00:34] I guess if you're using it as a desktop without an external monitor it might make sense. [00:34] i have an external monitor too [00:34] OK, so it doesn't make sense :) [00:35] i like to move about a bit sometimes [01:23] 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] thank you! [01:24] * gary_poster disappears again [01:24] Bah [01:24] Disappeared before I could tease him. [01:35] StevenK: are you going to update factory methods to use info_type for branches? [01:36] Down the line, yes. [01:36] It's a bit premature right now. [01:36] StevenK: ok. i've got some tests with placeholders for when that happens [01:37] wallyworld__: I'm happy to sprinkle in information_type into makeBranch() in the current branch I'm doing. [01:37] I just won't remove private yet [01:37] StevenK: that would be nice, thanks [01:37] wallyworld__: Aye, I shall. [01:38] you ocr? [01:38] I should be. === StevenK changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: StevenK | Firefighting: - | Critical bugs: 3.47*10^2 [01:38] i will have a mp soon :-) [01:39] I'll be sure to give it the appropiate amount of attention. [01:39] (IE, none at all.) [01:43] 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] wgrant: have you read the browserid spec? [01:53] lifeless: Not in depth, but I know roughly how it works. [01:55] lifeless: Assuming it becomes semi-standardised and gains some widespread support, I see no technical reason to forbid it. [01:55] the thing I wonder, quite apart from whether its a good idea [01:56] is whether someone can create an openid thunk [01:56] and we can avoid supporting it entirely [01:56] wgrant: overhead is overhead [01:57] Sure, one could pretty easily implement an OpenID provider which effectively proxies BrowserID. [01:57] wgrant: I skimmed it about 6 months ago [01:57] but the details are paged out [01:58] so, if you can do that, one wonders my mozilla didn't just do that instead. [02:01] lifeless: Well [02:01] lifeless: Part of the idea of BrowserID is that browsers will implement it. [02:01] So there'll be no bouncing around. [02:01] The browser will authenticate directly with its keypair and a time-limited certificate signed by the provider. [02:02] One could implement an OpenID gateway, but it would still involving hideous redirects and ugliness. [02:09] wgrant: yes, I'm aware of that [02:09] wgrant: my HTTP nazi hate just loooves that [02:12] It does mean that you have to trust the browser, and you can't really seamlessly integrate server-side 2FA. [02:13] But it in all otherwise a tonne less hideous, sick and wrong. [04:18] * wallyworld__ -> computer shop @#$%%$#! [04:19] Hahaahaha [04:19] bastard :-( [05:34] 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] We might be able to, yeah. [05:37] It's getting hard to single out culprits now, but IIRC this was a relatively big one. [06:04] wallyworld__: Are you back yet? [06:46] StevenK: back. bloody traffic accident. took 1 hour for a 15 minute trip :-( [06:50] haha [06:50] wgrant: interested in reviewing the scrubber change? https://code.launchpad.net/~jtv/launchpad/bug-994650-scrub-faster/+merge/105169 [06:51] jtv: It would be my pleasure. [06:51] \o/ [06:54] I think I'll grab some food, meanwhile. [07:15] jtv: Looks good. [07:15] jtv: I'm not sure if avoiding loading the POFiles is a useful optimisation at this stage, but it can't hurt. [08:24] StevenK: Have you run the garbo job over dev and test sampledata? [08:26] wgrant: Nope, I was going to do that with the db patch [08:26] StevenK: Sounds reasonable. [08:27] Just means you have to practice a bit of necromancy. [08:27] Meh, the garbo job is still in db-devel ... :-) [08:27] True [08:28] Should garbo tasks become celery tasks, or should we keep the garbo infrastructure? [08:34] I think it'll all become celery once that's stable. [09:01] wgrant: are you well? [09:02] You approved my branch without comments. Naturally I'm concerned. [09:07] Heh [09:12] hahahahah [09:12] jtv: remember to make some pep8 violations so you both can breathe easy :D [09:13] Thanks. I'll try to remember that. [09:13] And if I don't, then wgrant can point out that I forgot. [09:13] Heh. [09:14] 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] good morning [11:16] morning adeuring [11:16] morning rick_h_ [12:09] Any reviewers about? If so, have an MP! https://code.launchpad.net/~jtv/launchpad/bug-994650-scrub-in-batches [13:29] morning [13:31] morning czajkowski early out west isn't it? [13:32] yes [13:32] 6:35 === abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugs: 3.47*10^2 [14:00] any advice folks https://answers.launchpad.net/launchpad/+question/196568 [14:17] adeuring: is "name.find('/eggs') >= 0" equivalent to "'/eggs' in name" ? [14:17] abentley: ah, sure... [14:17] adeuring: I find the latter more intuitive. [14:18] right [14:20] 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] abentley: yes [14:22] 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] abentley: I haven't tested it yet. But why should it break? [14:24] 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] 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] abentley: Have a look at the scripts in /bin. Most of them are thin wrappers around a real script and just configure sys.path. Take celeryd as an example [14:27] abentley: celeryd starts fine [14:27] adeuring: Sure, but most of them specify a giant load of paths. I thought yours was just about adding one path. [14:27] abentley: no: extended_path = [name for name in sys.path if '/eggs' in name] [14:27] that adds the whole bunch [14:28] abentley: the extra steps with this_path is about the development environment [14:28] where lazr.jobrunner is not W"eggified" [14:29] adeuring: Is there any need to configure CELERYD_PREFETCH_MULTIPLIER now that we're using CELERY_ACKS_LATE? [14:30] 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] adeuring: r=me [14:35] abentley: cool, thanks [14:47] 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] 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] cjwatson: done [14:51] adeuring: BranchScanJob. [14:51] abentley: thanks [14:53] rick_h_: ta [15:15] abentley: https://code.launchpad.net/~rharding/launchpad/ga_combo/+merge/105219 for you when you get a sec pls [15:16] abentley: note that there's a lot of qualifications and such with it [15:16] looks worse than it is because of the file move/copy of the ga.js around :/ [15:16] rick_h_: "a diff'd version"? [15:17] 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] rick_h_: I don't think that copyright statement is correct. They don't nest like that. [15:25] abentley: yea, wasn't sure about that. I tried to state the "Code below" to help clarify [15:28] 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] abentley: ok, sounds reasonable to me. Is there someone I should run this by/check officially you know of? [15:31] rick_h_: You could try Amanda Brock. The dept is https://wiki.canonical.com/LegalServices [15:31] abentley: ty [15:34] rick_h_: Where was this file before now? [15:34] abentley: icing/google-analytics/ga.js [15:35] rick_h_: So with this change, do we have it in three places? [15:35] abentley: yes, for the moment [15:36] we have to support both combo loader/non-combo loader users [15:36] I guess we could get rid of the copy in the app/js/google-analytics directory, only the .diff file is *required* [15:37] rick_h_: If we can get rid of a copy, that would be good. [15:37] abentley: yea, I don't think we'd lose anything. Will do. === salgado is now known as salgado-lunch === matsubara is now known as matsubara-lunch === deryck is now known as deryck[lunch] [17:44] Ursinha, czajkowski said you were looking for me. [17:44] gmb, yeah, I have a lot of questions about launchpad code... but will enter a session in a few minutes :/ [17:49] Ursinha, Okay, let's try and catch up later on then. Some time after lunch if you're free. === matsubara-lunch is now known as matsubara === salgado-lunch is now known as salgado === deryck[lunch] is now known as deryck [18:30] morning [18:30] allenap: hi [18:33] sinzui: \o/ \o/ [18:33] lifeless, I am glad you are happy [18:38] sinzui: contact-this-team [18:38] I was sure you were tracking that [18:39] :) [18:40] sinzui: nice blog post have posted in all the places. [18:40] 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] 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] nods I know tis fine [18:40] sinzui: thats a shame [18:41] yes. barry and I over-specialised the recipient set object. I need to make it behave more like a normal object. === cr3_ is now known as cr3 [19:33] lifeless: Hi there. [19:34] allenap: hi, if you'd like some voice time, I'd be delighted to do so. [19:34] lifeless: Cool, that sounds good. I've just seen your reply, so I'll read that. [19:37] allenap: skype ? [19:41] lifeless: Is G+ okay? I don't have Skype installed right now. [19:41] tis fine [19:42] it has nearly as good echo cancellation [19:42] which is, for high latency, esssssential [19:43] lifeless: Okay, invited. [20:01] lifeless: ping, when you get a sec [20:48] rick_h_: pong; afk for a sec, but write here and I'll reply in a few === gmb` is now known as gmb [20:48] 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] 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] czajkowski, about? [20:49] 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] 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] lifeless: see https://code.launchpad.net/~rharding/launchpad/ga_combo [20:53] interesting [20:53] * lifeless runs screaming === abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2 [20:54] 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] http://bazaar.launchpad.net/~rharding/launchpad/ga_combo/view/head:/lib/lp/app/javascript/google-analytics/google-analytics.js [21:00] rick_h_: [21:00] http://support.google.com/analytics/bin/answer.py?hl=en-GB&answer=1032389 [21:00] I believe flacoste checked with Google when we first put it in the tree [21:01] 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] rick_h_: so why do you need to convert it to yui ? is it a combo loader limitation ? [21:01] gmb: looking for me ? [21:02] 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] 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] rick_h_: keeping the unaltered google file and unaltered async-loading snippet from google [21:02] that would keep the delta lower too [21:02] so it's benifit of -1 request per page done, and servied via our combo loader removing one more thing in icing [21:02] http://support.google.com/analytics/bin/answer.py?hl=en&answer=1008080 [21:02] - goes in the end of [21:03] you can serve via the combo loader just by using a combo loader url [21:03] so its solely -1 request, per the very first page they land on [21:04] rick_h_: or am I misunderstanding something about combo loader internals ? [21:04] 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 === _mup__ is now known as _mup_ [21:04] lifeless: but we could manually muck with/modify that I think [21:04] rick_h_: nono, *not* yui [21:04] right, I gotcha [21:04] if we use http://support.google.com/analytics/bin/answer.py?hl=en&answer=1008080 [21:04] which we probably do today [21:05] and replace the url in it with one pointing at the combo loader [21:05] we'll get back unaltered content. [21:05] right ? [21:05] yes [21:05] so just moving the url - trivial. No delta vs google's authoratitive copy. [21:05] and still async, nonblocking on the page. [21:06] ok, so we can work with the async version, our old one just wasn't using that one? [21:06] I don't know, you're the one doing the debugging :) [21:06] k, I'll pull down and compare tomorrow [21:06] rick_h_: I gotta run, TL meeting; will pick this up after that. [21:06] rgr [21:06] if we're blocking today, I'd say keep blocking, do the minimal work [21:07] move the url to the combo loader, add a bug saying we should be async, move on :) [21:23] jcsackett: hey, have you been testing out/using the auto reloader for the JS? [21:24] * rick_h_ is curious === Ursinha is now known as Guest64056 [21:28] rick_h_: i have not. [21:28] how does one use that? [21:29] make jsbuild_watch [21:29] then just edit the js files and on save it'll auto jsbuild them [21:29] i will have to check that out. [21:29] that's the idea at least [21:29] that would make somethings *way* easier. [21:30] yea, I got wondering, I've not done a ton of JS since adding it, but seems you are [21:30] and the more i do, the more it seems i need to do. :-P [21:30] ruh roh [21:30] ah, the life of cleaning up old bad code. [21:30] :-P [21:30] that's the truth [21:30] give it a try next time and let me know if you hit issues [21:30] so, by "next time" you mean tomorrow? :-P [21:31] :) [21:31] I didn't want to presume [21:31] just deeper than you thuoght it was or issues you're hitting? [21:31] more things making use of it than i thought. [21:31] 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] ah, gotcha k [21:32] quick thought? know any reason that a BuiltClass from Y.Base.create might barf when it's constructor.NAME is grabbed? [21:32] in that, it's constructor has no .NAME. [21:32] 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] I think you'd have to get it from your instance? [21:33] hm. wonder why Banner was fine but something derived from Banner dies ... [21:33] not sure, honestly, never used the NAME bit :/ [21:33] i'm not either, YUI throws the error. [21:33] i'll keep poking. [21:33] well that NAME should change to the Base.create('ISNAME'... right? [21:33] make sure your requires is correct [21:33] the error I got today on that was waaay out of left field [21:34] already checked requires. would that it was that easy. [21:34] i'll keep poking. :-) [21:34] k [21:38] 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] As in is it worth landing a follow-up commit? [21:38] rick_h_: just realized. no `new` call. :-P [21:38] it's always the little things. [21:38] jcsackett: ah, yea that one bites me all the time. I've learned that error hard core [22:00] wallyworld, how goes the morning? What is your preferred means of voice today? === matsubara is now known as matsubara-afk [22:03] jcsackett, mumble? [22:03] sinzui: yup. signing on. [22:04] wallyworld, wgrant_ look at https://bugs.launchpad.net/launchpad/+bug/702429 [22:04] <_mup_> Bug #702429: Pillar owners and private non-security bug visibility

< https://launchpad.net/bugs/702429 > [22:05] cjwatson: Not really, but you can if you want. [22:09] cjwatson: it is worth it, jfdi it, and it can land on devel [22:09] the comments are only used for dev machines anyhow === Guest64056 is now known as Ursinha [22:18] damn thunderstorms... === elmo_ is now known as elmo [23:53] wallyworld_: wgrant_ is stealing your thing! [23:54] * wallyworld_ wants it back