[03:35] <StevenK> wallyworld: Want to review https://code.launchpad.net/~stevenk/launchpad/information_type-bugs-garbo/+merge/97335 ?
[03:35] <wallyworld> StevenK: give me a few minutes
[03:43] <StevenK> And hopefully wgrant and wallyworld don't hate me, but: https://code.launchpad.net/~stevenk/launchpad/destroy-ie-regression/+merge/97337
[03:43] <wallyworld> StevenK: bug._setInformationType is already committed?
[03:44] <StevenK> wallyworld: It's in the pre-req branch. As is the comment in test_bug, but I hadn't pushed so it polluted the diff
[03:46] <wallyworld> StevenK: r=me
[03:47] <nigelb> feels very silent today.
[03:48] <wallyworld> StevenK: with the other one, i think we need to commit to testing any affected pages on qas in IE before qa-ok. or even test before landing
[03:49] <StevenK> wallyworld: I think I'll just reply to the thread with the MP and see what happens.
[03:49] <wallyworld> ok :-)
[03:50] <StevenK> wallyworld: Main reason I linked it to you was not for review, but to hope I wasn't treading on toes.
[03:51] <wallyworld> StevenK: oh not at all. any of that stuff that I may have checked in would have been due to copy and paste from elsewhere, not deliberately doing it
[03:53] <wgrant> Needs to be tested before landing.
[03:55] <StevenK> Oh, WCPGW
[03:56] <StevenK> :-P
[03:57] <wgrant> Bah
[03:57] <wgrant> IE8 doesn't support last-child
[03:57] <wgrant> IE9 does, though.
[04:03] <wgrant> Windows XP font rendering is the worst thing in the world, apart from IE6.
[04:03] <lifeless> wgrant: brainfuk
[04:03] <StevenK> Haha
[04:04] <lifeless> wgrant: intercal
[04:06] <wgrant> Bah
[04:06] <StevenK> Ruby
[04:07]  * StevenK ducks
[04:07] <nigelb> ruby is old. node.js is the new hawtness
[04:12] <wgrant> "Unknown runtime error"
[04:12] <wgrant> Thanks, IE8, that's really helpful.
[04:12] <StevenK> Hahaha
[04:12] <StevenK> IE8 against what?
[04:12] <wgrant> Trying to run Launchpad's JS.
[04:13] <StevenK> Using my branch, or LP in general?
[04:13] <wgrant> devel + a few unrelated changes
[04:14] <wgrant> StevenK: How do I use the comboloader these days?
[04:14] <wgrant> hopefully it will make the JS file small enough that IE's debugger can render it.
[04:16] <StevenK> wgrant: You need to make sure your Apache is set up -- does 'combo' appear twice in your local-apache-launchpad config?
[04:19] <wgrant> StevenK: I have the WSGIScriptAlias
[04:19] <wgrant> And yes.
[04:19] <StevenK> Does /srv/launchpad.net exist?
[04:20] <StevenK> s/net/dev/, sorry
[04:20] <wgrant> Ewwwwww
[04:21] <wgrant> But yes
[04:21]  * wgrant must take an axe to this later.
[04:21] <StevenK> Is /srv/launchpad.dev/convoy a symlink into the correct tree + build/js?
[04:22] <StevenK> If so, enable the feature flag js.combo_loader.enabled
[04:22] <StevenK> wgrant: I can't use /var/tmp
[04:23] <StevenK> You can't follow symlinks you don't own, and if $USER creates the symlink then www-data can not follow it.
[04:23] <StevenK> We had this argument already.
[04:23] <StevenK> And I refuse to edit the Apache config on every build
[04:23] <wgrant> That doesn't make it valid for rocketfuel-setup to shit all over /srv
[04:23] <wgrant> :)
[04:24] <StevenK> rf-setup does far worse already
[04:24] <StevenK> And the evil is in our Makefile, not rf-setup
[04:24] <wgrant> Hm
[04:24] <wgrant> Can I disable minimisation in combobuild?
[04:25] <StevenK> Hmmm
[04:25] <StevenK> I thought I had
[04:25] <wgrant> Oh
[04:25] <wgrant> Someone is trying to set innerHTML of a table.
[04:25] <wgrant> Bad $someone.
[04:33] <StevenK> lifeless: You should watch Damien Conway's talk "Temporally Quaquaversal Virtual Nanomachine Programming in Multiple Topologically Connected Quantum-Relativistic Parallel Timespaces... Made Easy"
[04:34] <StevenK> wgrant: Is http://www.globalnerdy.com/2012/02/16/how-to-tell-html-from-html5-or-microsofts-image-problem/ still true?
[04:35] <wgrant> wtf
[04:35] <wgrant> some of our JS is awful
[04:35] <StevenK> Some?
[04:36] <wgrant> Well, for example, the "oh, this JS needs to know a URL. let's stick a contentless <a href="someurl" id="something" /> in the page somewhere and hope nobody notices it's there"
[04:36] <StevenK> Bwahjaha
[04:43] <lifeless> StevenK: what did keyring-maint say?
[04:44] <StevenK> lifeless: So it seems keyring-maint is as much a blockhead as me.
[04:44] <StevenK> The first RT was signed with the new key, and the second RT was signed with the current key.
[04:44] <StevenK> Gunnar approved the first RT and said it's been done.
[04:45] <StevenK> He then comment on the second RT with effectively, "DOH! Did I just ... yes, I did."
[04:52] <lifeless> StevenK: rotfl
[04:56]  * StevenK stabs ec2.
[04:56] <StevenK> It failed, and didn't send me a mail
[05:19]  * StevenK stabs ec2, and then twists the knife.
[05:21] <wgrant> wut
[05:22] <wgrant> why on earth are all collapsibles done with a <legend> not necessarily inside a <fieldset>?
[05:22] <wgrant> When a <legend> can only exist in a <fieldset>..
[05:22] <wgrant> Also it makes no sense.
[05:22] <StevenK> wgrant: Did you get the combo-loader working, or you gave up?
[05:23] <wgrant> Got it working.
[05:23] <wgrant> Had to hack base-layout.pt to remove minimisation
[05:23] <wgrant> But it works.
[05:23] <StevenK> Ah yes, I was going to look at that
[05:24] <wgrant> It's pretty simple, really.
[05:24] <wgrant> http://pastebin.ubuntu.com/882822/
[05:24] <StevenK> "If your membership does expire, we'll send you one more message to let
[05:24] <StevenK> you know it's happened.
[05:24] <StevenK> RAHHH
[05:24] <StevenK> SMASH
[05:25] <StevenK> wgrant: Ah, but only want raw there if devmode
[05:26] <wgrant> Sure
[05:26] <huwshimi> Has anyone here worked with publishing custom events with YUI?
[05:27] <rick_h_> huwshimi: what do you need?
[05:28] <huwshimi> rick_h_: I have a widget that I want to publish events from. I have things set up the way I think they should work, but I can't seem to see the events...
[05:28] <StevenK> rick_h_: WTF, isn't it like 6am?
[05:28] <rick_h_> StevenK: in CA for pycon sprints
[05:28] <huwshimi> StevenK: Pycon
[05:29] <rick_h_> So it's 10:30pm and I'm sprinting
[05:29] <StevenK> Ah
[05:29] <huwshimi> rick_h_: Want to see some code?
[05:29] <rick_h_> huwshimi: sure
[05:29] <StevenK> rick_h_: Can I borrow you for a sec?
[05:29] <rick_h_> StevenK: maybe, beware, I'm 3/4 a bottle of wine in :)
[05:29] <StevenK> rick_h_: wgrant had to add filter: 'raw' for no minified JS from the combo-loader in the pastebin he linked
[05:29] <rick_h_> right
[05:29] <StevenK> I'm just wondering what it should be for qas/prod
[05:30] <rick_h_> I thought we picked that up in our dev settings
[05:30] <rick_h_> I think qas and prod should both be min
[05:30] <rick_h_> chrome dev tools can un-minify it if required
[05:30] <StevenK> Which is filter 'min' ?
[05:30] <rick_h_> but they should both be running without hte raw
[05:30] <rick_h_> it defaults to min, just remove the raw setting
[05:30] <rick_h_> bah, see...qas and prod should both be min, which is the default
[05:31] <StevenK> Right
[05:31] <rick_h_> so just leave off the filter all together and it should default sanely
[05:31] <StevenK> Yeah, I'm trying to figure out how to codify that given our TAL.
[05:31] <rick_h_> StevenK: remember, you can edit the config after it's setup
[05:32] <rick_h_> so YUI_Config... all that
[05:32] <rick_h_> and then "if dev mode, YUI_Config.groups.... tweak the value after the fact
[05:32] <rick_h_> I guess I should pull up the file
[05:33] <StevenK> base-layout-macros.py
[05:33] <StevenK> pt
[05:33] <wgrant> Intriguing
[05:33] <StevenK> Damn muscle memory
[05:33] <StevenK> wgrant: ?
[05:33] <rick_h_> StevenK: ah right, the whole script block is one script tag, well just add another I guess
[05:33] <wgrant> IE8 doesn't complain about broken JS on https://launchpad.net/launchpad
[05:34] <wgrant> But it also doesn't execute much or any of it.
[05:34] <huwshimi> rick_h_: I'm not sure how useful this mess is to you: http://paste.ubuntu.com/882825/
[05:34] <wgrant> And it's not disabled, because when I run it locally without removing any anti-IE guards it breaks.
[05:34] <huwshimi> rick_h_: If you search for xxx on that page it'll show you where the event stuff is
[05:34] <rick_h_> StevenK: https://pastebin.canonical.com/62277/
[05:38] <rick_h_> huwshimi: your JS scope on your hover (non custom) event is wrong
[05:38] <rick_h_> this in there is the ev
[05:38] <rick_h_> either add the this as the third argument or run a that=this in there
[05:40] <huwshimi> rick_h_: Oh, perfect!
[05:40] <StevenK> wgrant: Will <script type="text/javascript" tal:condition="devmode" tal:content="string: YUI.GlobalConfig.groups.lp.filter = 'raw';" /> do what I want?
[05:40] <huwshimi> rick_h_: I was looking for a much bigger problem :)
[05:40] <rick_h_> http://paste.ubuntu.com/882833/
[05:40] <rick_h_> or something like that
[05:41] <rick_h_> huwshimi: let me know if that helps. I haven't done a ton of custom events and know they can get complicated with event facades and such, but hopefullythat's all it is
[05:41] <huwshimi> rick_h_: Yup, working. Thanks for your help :)
[05:42] <rick_h_> huwshimi: np
[05:42] <wgrant> StevenK: No point using tal:content there
[05:43] <wgrant> StevenK: Unless TAL's special <script> mangler kills you.
[05:43] <wgrant> But assume it won't unless proven otherwise.
[05:44] <StevenK> wgrant: So <script type="text/javascript" tal:condition="devmode">YUI.GlobalConfig.groups.lp.filter = 'raw';</script> with some vertical whitespace sprinkled in would be fine?
[05:44] <wgrant> StevenK: Probably.
[05:49] <rick_h_> ok, I'm out, have fun all
[05:50] <wgrant> Night rick_h_.
[06:19] <wgrant> lifeless: bugs.statistics_portlet.hide_fixed_elsewhere_count default 0 true?
[06:25] <wallyworld> wgrant: StevenK: has ec2 land failed for you today or recently with a bzrlib error?
[06:26] <wgrant> Not for me, but apparently everyone else
[06:26] <wallyworld> :-(
[06:26] <wallyworld> workaround?
[06:36] <bigjools> pqm-submit? :)
[06:40] <wallyworld> bigjools: i want it to run tests first though
[06:41] <bigjools> who needs those
[06:41] <wallyworld> me
[06:51] <StevenK> wallyworld: I had it fail, you need to update lp-dev-utils
[06:51] <wallyworld> ah thanks
[06:52] <StevenK> And my garbo job branch has checkwatches.txt fail? Le sigh
[07:02] <lifeless> wgrant: yes, but also put it on the blog / lp-users or something ?
[07:05] <wgrant> lifeless: The premise of the change is that nobody will notice if it disappears.
[07:07] <lifeless> indeed
[07:07] <lifeless> so there is a balance to strike :)
[07:08] <wgrant> That balance is to hide it and watch nobody complain.
[07:16]  * StevenK is tempted to make a twitter joke
[07:20]  * StevenK has fun breaking wallyworld's mockup
[07:20] <wallyworld> StevenK: it's only POC :-)
[07:20] <wallyworld> what broke?
[07:20] <StevenK> wallyworld: Click logout, it's funny
[07:20] <wallyworld> StevenK: ah, that was never meant to work
[07:21] <StevenK> That much is obvious. :-)
[07:21] <wallyworld> the point of the mockup for this iteration is the disclosure picker chamges
[07:21] <wallyworld> anything else that works is not guaranteed
[07:21] <StevenK> wallyworld: However, hitting the expander for large commercial doesn't show anything and the button that displays isn't wired up
[07:21] <StevenK> Er
[07:21] <StevenK> *everything, not anything
[07:22] <wallyworld> which expander?
[07:23] <StevenK> The filter one
[07:23] <wallyworld> StevenK: the filter is not implemented
[07:23] <wallyworld> it was last revised weeks/months ago
[07:24] <wallyworld> the thing to focus on for this iteration is the picker :-)
[07:25]  * wallyworld has to reboot his router. stupid voip port locked up :-(
[07:25] <huwshimi> wallyworld: You know, flat mockups for the radio buttons, lozenge etc. will do just fine for deciding which direction to go in.
[07:27] <wallyworld> huwshimi: yeah. but i when we do decide, all the plumbing has to change anyway so i can just reuse what i did there. not much will be wasted
[07:28] <huwshimi> wallyworld: So you're going to be creating the lozenge etc in javascript as well then?
[07:28] <wallyworld> huwshimi: not sure. i might hust do a static mockup. but i do think people will want to click and see how they like it etc
[07:29] <wallyworld> huwshimi: and i thought i'd see the reaction to the radio buttons first
[07:30] <huwshimi> wallyworld: We need to do flat mockups first. If we need to see interactive ones to be able to decide then we can do those once we've narrowed down the options.
[07:30] <huwshimi> wallyworld: Doing them at this stage is wasted effort
[07:30] <wallyworld> i didn't waste much. 80% of the work was in the plumbing which can be resued regardless of what choice we make
[07:31] <wgrant> Mmmmmm, delicious delicious tag soup.
[07:33]  * wallyworld is off to soccer
[07:38] <wgrant> wow
[08:46] <adeuring> good morning
[09:08] <czajkowski> aloha
[09:09] <danhg> morning all
[12:33] <StevenK> mabac: Hai, your revision of r14942 is up on qastaging and ready for QA, if you can do it soon.
[12:34] <salgado> StevenK, we're doing it now
[12:34] <StevenK> salgado: Excellent, thank you.
[12:35] <mabac> StevenK, yup, shouldn't take much longer
[12:35] <StevenK> I wasn't going to care about deploying until tomorrow morning my time, so you have about ten hours. :-)
[12:35] <mabac> StevenK, thank you :)
[12:54] <czajkowski> mrevell: salgado with bugs that are coming into lp for triaging that are blueprint issues what way do you want me to handle them ?
[12:56] <salgado> czajkowski, don't know, tbh.  what are the options?
[12:59] <czajkowski> well two are yours and others are linaro issues. so just wondering will they be considered for development
[13:00] <czajkowski> or do i traige the all low and add you as the assingee or critical :)
[13:00] <czajkowski> or opinion :)
[13:11] <salgado> czajkowski, we just filed 3 or 4 that would be very nice to have fixed, so we'll definitely take care of those.  there are at least another 2 which are wishlists I'd say.  I'll collect them all in an email and state our plans
[13:15] <jcsackett> and the day begins with a development machine that won't boot from disk errors...
[13:16] <jcsackett> morning, all. :-)
[13:45]  * mpt wonders why sinzui changed "private" to "proprietary" in bug 136937
[13:45] <_mup_> Bug #136937: Cannot file a non-security proprietary bug in Launchpad <bug> <disclosure> <lp-bugs> <privacy> <Launchpad itself:Triaged> < https://launchpad.net/bugs/136937 >
[13:50] <sinzui> mpt, private could mean embargoed security information, Personal user data information, or proprietary information
[13:50] <sinzui> mpt proprietary means the information belongs to an organisation any probably will not ever become public
[13:52] <mpt> sinzui, sometimes. A big counterexample was Launchpad itself when it was proprietary. :-) Then our bug reports were private only when they referred to detailed architecture or source code.
[13:52] <mpt> but I understand what you mean now, proprietary is the main use case for non-security privacy
[13:52] <sinzui> mpt yes, and we decided to make them all public when the code became public
[13:53] <sinzui> There are still proprietary bugs though...we wanted to make all public, but company information is in some comments
[13:54] <sinzui> mpt, right. Most private bugs in Lp are user-data because apport includes personal user information that requires cleaning before the bug is made visible to Ubuntu's bug squad
[14:32] <sinzui> abentley, I am pondering job system for projects that send emails or maintainers and possibly updates the project. I need a daily script that create job if one has not already been created within a time frame (week or months). Project reviewers could also use the UI to create jobs (send an email about licensing problems). Does this sound doable?
[14:32] <sinzui> s/emails or maintainers/emails to maintainers/
[14:33] <abentley> sinzui: Yes, it sounds very doable.  It's a little like how we create recipe builds.
[14:33] <sinzui> oh, I will look at that.
[14:34] <sinzui> abentley, we only autobuild once per day right?
[14:35] <abentley> sinzui: We used to only autobuild once per day, I'm not sure if that was changed.
[14:35] <sinzui> My plans might require that jobs in the jobs table not be deleted or actually remain in the job table for up to 6 months. I do not think we delete job.
[14:36]  * sinzui has to find more plurals and tenses
[14:37] <abentley> sinzui: That's correct.
[14:37] <sinzui> fab
[14:38] <abentley> sinzui: I and adeuring are currently working on https://dev.launchpad.net/CeleryJobRunner so if you need to change code in lp.services.job, please let me/adeuring know.
[14:40] <sinzui> okay. I doubt I will. I was thinking of a new table+model for project jobs that references the exising job object. (dates and statues)
[14:41] <abentley> sinzui: Right. I didn't think so either.
[14:41] <sinzui> still one s short
[14:41] <sinzui> thanks abentley. I will start sketching this in code
[14:42] <abentley> sinzui: Once we've migrated to celery, we'll have the option of using celerybeat, rather than cron, for scheduling periodic tasks.
[14:44] <sinzui> abentley, Oh. I do want that
[14:45] <abentley> sinzui: The way we do recipe builds is we periodically look for recipes to build, and then schedule those recipes to be built.
[14:45] <sinzui> Looks like my session is knackered by an update. I am restarting.
[14:45] <abentley> sinzui: ACK.
[14:55] <sinzui> oh dear, Starting a window kill the indicators/menus in Unity. starting a terminal is insane as the UI refreshes and the window shrinks by one line each loop until the terminal is just a window frame
[14:57] <wgrant> Hmm
[14:57] <wgrant> I've seen a similar sort of thing with qemu for a few weeks.
[14:57] <wgrant> When run under precise's compiz it has seizures
[14:57] <wgrant> resizing up and down for 20s or so
[14:57] <wgrant> Until it contracts to ~1x20px
[15:00] <sinzui> I think I will not use the indicators for the next day.
[15:00] <abentley> sinzui: Anyhow, pre-celery, you'd have a cron script that looks at projects and creates jobs, and another that actually runs the jobs.
[15:01] <sinzui> abentley, indeed that is what I was thinking
[15:02] <deryck> abentley, hey, sorry running a tad late.  give me 5 minutes to grab a coffee and we can chat.
[15:02] <abentley> sinzui: post-celery, celerybeat could run a Task that creates Jobs, which would then run in celeryd.
[15:02] <abentley> deryck: sure.
[15:02] <sinzui> abentley, how many weeks are we from celerybeat?
[15:03] <abentley> sinzui: I think at least two.
[15:04] <abentley> sinzui: This almost sounds like a straight cron script would do the trick, though.  If you had a field on the project to track the last execution.
[15:06] <sinzui> abentley, I do not want to change project because there can be many reasons a job is in the queue, and there could be several, but I want to avoid duplicate jobs (a job type that I need to create) or jobs that spam users too frequently
[15:07] <sinzui> I want my process to look at the most recent jobs for a time frame and if the type is not present, create one
[15:07] <abentley> sinzui: I guess you could have one script that created the jobs and then ran them immediately.
[15:08] <sinzui> That might be th effective out come. since the task is short
[15:09] <sinzui> I am separating how the job is created from the job since I already know of two very different ways that the job would need to be created
[15:09] <deryck> abentley, https://plus.google.com/hangouts/extras/talk.google.com/orange-catchup (when you're ready)
[15:39] <cr3> what's the difference between login.launchpad.net/$id/+decide and /two_factor_auth?
[15:45] <stub> cr3: Dunno - login.launchpad.net is the SSO server ISD runs, despite it being on our domain.
[15:56] <deryck> adeuring, hey, just finished my chat with abentley and we updated the board to better reflect the multiple branches you have going.
[15:56] <adeuring> deryck: ok, thanks
[15:58] <deryck> adeuring, also, were you getting something up for review today or tomorrow?  Or you're not sure yet?
[15:58] <adeuring> deryck: things are nearly ready
[15:59] <deryck> adeuring, awesome!
[15:59] <deryck> thanks!
[16:58] <adeuring> abentley:  https://code.launchpad.net/~adeuring/launchpad/lp-lazr.jobrunner/+merge/97458 (plus  lp:~adeuring/launchpad/lazr.jobrunner-more-tests -- no MP for that branch)
[16:58] <abentley> adeuring: Cool.   Looking.
[17:05] <abentley> adeuring: I don't think we can land this with "develop =../lazr.jobrunner".  We need lazr.jobrunner to be an egg in download-cache.
[17:10] <abentley> adeuring: It looks like lp.services.job.model.job.Job is not derived from lazr.jobrunner.jobrunner.BaseJob.  Should it be?
[17:11] <adeuring> abentley: It can't hurt, I think, but it's not strictly necessary either. IOW: I don't have any opinion on it ;)
[17:12] <abentley> adeuring: I think it will be clearer if we do it, so we should, but we can do it in a follow-up.
[17:13] <adeuring> abentley: right; there are anyway a few things to clean up, like the change to buildout.cfg
[17:14] <adeuring> (together iwh bureaucracy, like adding lazr.jobrunner to the download cache)
[17:15] <abentley> adeuring: The purpose of lp.services.job.jobrunner.BaseJobRunner.runJob is to adapt the input to IJob?
[17:16] <adeuring> abentley: I think so. That was your change, IIRC ;)
[17:16] <abentley> adeuring: Yes, I believe so.  It almost looked redundant.
[17:18] <adeuring> abentley: Well, it is a way to "mix" any run() method (i.e., the core of a job) with the "Bureaucratic" stuff, like start(), fail() etc
[17:19] <abentley> adeuring: It looked redundant with lazr.jobrunner.jobrunner.BaseJobRunner.runJob
[17:21] <abentley> adeuring: Do you know whether the removeSecurityProxy in job_str is still necessary?
[17:21] <adeuring> abentley: I did not check...
[17:22] <abentley> adeuring: I think I did that before I made job_id a part of IJob.
[17:22] <adeuring> abentley: ok, let's try it. Also, you are right: we can drop BaseJobRunner.runJob(); at least, the tests pass
[17:27] <abentley> adeuring: How does makeOopsReport access the oops messages?
[17:28] <adeuring> abentley: makeOopsReport() does net "see" these messages. Adding them is done via a callback in oops_config.
[17:29] <adeuring> abentley: but makeOopsReport could be used instead of the context manager to add this extra data. (with a small drawbacks.)
[17:30] <abentley> adeuring: Okay, I see where that's done now.  That's fine.
[17:43] <abentley> adeuring: By deriving BaseRunnableJob from BaseJob, you'll eliminate a little redundancy: user_error_types, retry_error_types
[17:43] <adeuring> abentley: right
[17:47] <abentley> adeuring: You should also specify a version of lazr.jobrunner in versions.cfg
[17:47] <adeuring> abentley: yes
[17:47] <deryck> abentley, hey they.  I have one for review when you're available.
[17:48] <abentley> deryck: ACK.  With you in a few minutes.
[17:49] <deryck> abentley, no problem.  Thanks
[17:52] <adeuring> abentley: if we derive BaseRunnableJob from BaseJob, the delegaton mechanism to lp.services.job.model.job.Job.start() etc fails; instead, the "dumb" methods from BaseJob are used. And these are not aware of the DBEnum values of the status property.
[17:53] <abentley> adeuring: Okay, let's leave it alone for now.
[17:55] <abentley> adeuring: Okay, so that's everything I see there.  I'm going to mark it "needs fixing" because it needs to specify a proper egg for lazr.jobrunner.
[17:55] <adeuring> abentley: right
[17:55] <abentley> adeuring: But don't get me wrong, this is great progress.
[17:56] <adeuring> thanks
[17:56] <abentley> deryck: I can look at your review now.
[17:57] <deryck> abentley, thanks!  https://code.launchpad.net/~deryck/launchpad/buglistings-preload-people-901122/+merge/97041
[18:05] <abentley> deryck: In getBugTaskPeople, can you just use Bug.owner directly, instead of getting Person.id?  It should be the same value, and it reduces the number of tables involved.
[18:06] <deryck> abentley, but I need to return the people themselves.
[18:07] <abentley> deryck: right.  I mean use bug.owner and bug.assignee to generate your person_ids.
[18:08] <deryck> abentley, ah, right.  Well I could use bugtask.assignee, but I can't use bug.owner without issuing another query to get Bugs. That's why I did the big join.
[18:08] <abentley> deryck: e.g. http://pastebin.ubuntu.com/883667/
[18:09]  * deryck looks closely
[18:10] <deryck> abentley, ah right! I see what you mean now.  yes, I can do that.  thanks
[18:10] <abentley> deryck: np
[18:11] <lifeless> deryck: bug.ownerID ?
[18:11] <deryck> abentley, it's a hold over from the first iteration of this, where I just had a union and selected people, not subselects to get ids.
[18:11] <deryck> lifeless, that's what I thought abentley was suggesting.  he's talking about simplifying the way I wrote a subselect.
[18:13] <abentley> deryck: I guess the advantage of your version is that it handles NULL assignee/owner automatically.
[18:13] <lifeless> deryck: I think you will get much better results using the Person eager load helper.
[18:13] <deryck> abentley, yeah
[18:13] <lifeless> deryck: which knows how to get related assets; you know that bugtask is loaded, and bugtask.bug is already loaded.
[18:13] <deryck> lifeless, where is the person helper?
[18:13] <lifeless> deryck: so you have no need to do any DB work in this helper at all: just assemble the ids you need and hand off to the person helper.
[18:14] <deryck> lifeless, I thought doing this would issue more queries:  [task.bug.ownerID for task in bugtasks] ?  Local testing seemed to say so.
[18:14] <lifeless> deryck: getPrecachedPersonsFromIDs
[18:14] <lifeless> deryck: if bugtasks is a storm collection, yes it will
[18:15] <deryck> lifeless, right.  so that's why I made my own query.
[18:15] <lifeless> thats why you need to listify anything you get from storm before you start wrking with it
[18:15] <lifeless> slice it first, then materialise and cache
[18:15] <deryck> ah
[18:16] <deryck> so I could listify the batch, get the owner ids and hand off to the person helper?
[18:16] <lifeless> deryck: right, though if it is a batch, not storm, it has a caching layer in it already
[18:17] <lifeless> deryck: I suggest, grab the ids, hand off, and if you get extra queries, show me the backtrace leading up to the first one and I will help you sort it out
[18:17] <deryck> lifeless, ok, that's fair.  thanks
[18:17] <deryck> abentley, so never mind then. :) see ^^.  I'll rework it.
[18:18] <abentley> deryck: Okay.  Happy hacking!
[18:18] <deryck> abentley, thanks :)
[18:18] <deryck> shouldn't be too big a change really.
[18:18]  * deryck steps away briefly to get food
[19:14] <benji> abentley: hi, I have a very small MP that I'd like to get on your review docket: https://code.launchpad.net/~benji/launchpad/bug-954319/+merge/97491
[19:16] <abentley> benji: sure thing.
[19:16] <benji> cool
[19:17] <abentley> benji: r=me.
[19:17] <benji> abentley: thanks
[19:18] <benji> I am in a state of kanban conflict: the board is now not over the limit (with me moving my branch into landing) but we can't add anything else without going back over
[19:19] <benji> oops, wrong chan
[20:18] <benji> deryck: were you ever able to get LP running on a new precise box?  I'm trying to set one up and am apparently having the same problems you wrote to the list about.
[20:19] <deryck> benji, I did.  I had to install postgresql from oneiric packages. I downloaded them from launchpad individually by hand....
[20:19] <deryck> benji, and then I'd run make run and install packages individually via apt-get install until it quit erroring.
[20:20] <lifeless> wgrant: btw, there is demand for a public API for openid->teamsetc
[20:20] <deryck> benji, I think I've got everything installed now except launchpad-messageque-dependencies.
[20:20] <lifeless> wgrant: wondering if you want to make it a full fledged thing at the same time
[20:21] <benji> deryck: I'm glad you got it working.  I guess I'll go the same route.
[20:21] <deryck> benji, yeah, it was a slow and steady pain, but fixable given time and will power.
[20:22] <benji> This seems like it should be a priority for us to fix.  I would attempt to do so, but given my knowlege of packaging, it would be a bigger waste of time than I'm already facing.
[21:52] <wgrant> lifeless: Need to try to push XMLRPC duration variance down a bit first
[21:52] <wgrant> It's possibly not possible with the current setup, though.
[21:53] <wgrant> Since we're going to be GILled sometimes no matter what I do.
[21:53] <wgrant> And really these should complete in tens of milliseconds.
[21:53] <lifeless> wgrant: I was thinking xmlrpc for sso, API for u1 etc
[21:58] <lifeless> only sso with its special casing needs to bypass visibility rules
[21:58] <wgrant> lifeless: Well
[21:58] <wgrant> lifeless: The others would need to run under service accounts.
[21:58] <wgrant> Which we don't really do.
[21:59] <wgrant> And we would need to have extended private team visibility rules.
[21:59] <wgrant> Or have the service accounts as members of the teams...
[21:59] <wgrant> ew
[22:00] <lifeless> the latter is pragmatic
[23:27] <sinzui> wgrant,  I see I misunderstood Y.Array(my_array). I though it returned a YUI Array, not a native array. I do not see anything I have written in your diff, but I think code I have written for disclosure and teams must be wrong
[23:27] <wgrant> Test results: bugfilters-ie8 => devel: SUCCESS
[23:27] <wgrant> Success
[23:27] <wgrant> sinzui: Oh yes, I initially tried to use it as a constructor too
[23:27] <wgrant> sinzui: One of the more braindead YUI decisions I've seen...
[23:28] <wgrant> I think I fixed everything except for some of the derived distros widgets.
[23:28] <wgrant> I'll recheck.
[23:32] <wgrant> sinzui: Thanks
[23:48] <wgrant> wallyworld, sinzui, StevenK, jcsackett: ec2 is fixed if you want to pull lp:lp-dev-utils
[23:48] <wallyworld> cool thanks :-)
[23:58] <nigelb> Mornin
[23:58] <wgrant> Hi nigelb