[09:34] <nigelb> Is lifeless back tomorrow or next monday?
[11:00] <LPCIBot> Project db-devel build #855: FAILURE in 0.28 sec: https://lpci.wedontsleep.org/job/db-devel/855/
[12:15] <Nigel> ouch, build failure in 0.28 sec, that is fast
[15:41] <nigelb> its going to get opened anyway :)
[15:42] <nigelb> (bah, wrong channel)
[16:01] <LPCIBot> Yippie, build fixed!
[16:01] <LPCIBot> Project db-devel build #856: FIXED in 4 hr 41 min: https://lpci.wedontsleep.org/job/db-devel/856/
[19:15] <lifeless> morning
[19:15] <lifeless> nigelb: I am back now
[19:16] <nigelb> lifeless: GOOD Morning!
[19:16] <nigelb> I just wrapped up a db-devel patch
[19:16] <nigelb> I have to run the entire *tests* before I submit an MP?
[19:17] <lifeless> no
[19:17] <lifeless> they *have* to be run before landing ;)
[19:17] <nigelb> Ah. Instructions said so.
[19:17] <lifeless> if you don't run them all then ec2 may find a missing change and you'll need to get reviewed etc again.
[19:17] <nigelb> I can start a test run, but I'm afraid it might take quite a while on my core 2 duo :)
[19:17] <lifeless> how much memory do you have?
[19:18] <nigelb> 2Gigs
[19:18] <lifeless> the process is less likely to get restarted if you've run them all, but I consider that 'must' a 'should' :P
[19:18] <lifeless> you might like looking into the lxc parallel stuff and run 2 test runners with 1/2 the tests each
[19:18] <nigelb> ok, I'll start a test run and head to bed.
[19:19] <nigelb> lifeless: Family doing okay now? :)
[19:20] <lifeless> we're still learning, but the medical stuff seems to have settled down.
[19:20] <nigelb> :)
[19:20] <nigelb> That's good to hear
[19:22] <nigelb> Oh.
[19:23] <nigelb> db-devel test != devel tests.
[19:29] <jelmer> nigelb: are you running oneiric?
[19:29] <nigelb> Nope. Old School! Lucid
[19:32] <jelmer> hah, ok
[19:32] <nigelb> Hrm, one error so far. Looks unrelated. http://paste.ubuntu.com/687111/
[19:33] <jelmer> nigelb: looks like you might be missing a copy of pgbouncer
[19:35] <nigelb> Isn't that a dep?
[19:35] <nigelb> Or rather, shouldn't it be a dep?
[19:42] <nigelb> webapp-authorization.txt is failing as well.
[19:46] <nigelb> woah.*lots* of fail :(
[19:52] <nigelb> ARGH.
[19:52] <nigelb> How often does devel get merged into db-devel?
[19:52] <nigelb> I may have made a *big* mistake :|
[19:52] <lifeless> devel->db-devel - every time devel passes buildbot
[19:53] <nigelb> makeBugTasks() in tests are failing because that field doesn't exit.
[19:53] <nigelb> *exist
[19:53]  * nigelb looks at models
[19:53] <nigelb> GRAR.
[19:53] <nigelb> Yep. Its here.
[19:53] <lifeless> that means the process worked :P - we've just shown that we haven't (yet) removed deps on the field completely.
[19:54] <nigelb> Well, technically, no.
[19:54] <nigelb> I removed these deps the other day.
[19:54] <nigelb> I sense my db-devel is out of date.
[19:56] <nigelb> \o/ Yes. Stabbing myself in the foot++
[20:04] <lifeless> ftw, ftw, ftw
[20:10] <nigelb> On a more positive note, now I know why I should land the changes to not use fields first and then start the db patch.
[20:11] <lifeless> doing teaches well :)
[20:12] <nigelb> Yeah. The DB process is neat. Taught a bit of postgres as well.
[20:19] <nigelb> lifeless: Is there already a bug about JS OOPS or do you want me to file one and assign to myself?
[20:19] <lifeless> I don't know
[20:20] <nigelb> A quick google search doesn't give me anything. But I might be phrasing it wrong.
[20:20] <lifeless> I wonder if we've fixed bug 294656 yet
[20:20] <_mup_> Bug #294656: Every page requests two JavaScript libraries (remove MochiKit) <lp-bugs> <lp-translations> <lp-web> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/294656 >
[20:21] <lifeless> bug 741991
[20:21] <_mup_> Bug #741991: launchpad users have to manually report javascript failures <javascript> <Launchpad itself:Triaged> < https://launchpad.net/bugs/741991 >
[20:23] <nigelb> lifeless: nope, not fixed yet. Still see it.
[20:24] <nigelb> need to start figuring out where to start.
[20:25] <lifeless> on mochikit or oopses ?
[20:25] <nigelb> oopses
[20:26] <lifeless> make sure you have read https://dev.launchpad.net/ArchitectureGuide/ServicesRequirements
[20:27] <lifeless> if you would like some ahead-of-time design, create a technical LEP (I don't think it needs one)
[20:27] <nigelb> I think you handed me a technical LEP the other day :)
[20:29] <lifeless> then, bring up a microservice for it - involves making a new project - https://dev.launchpad.net/CreatingNewProjects
[20:29] <nigelb> "Don't be overly cute." HA.
[20:29] <lifeless> you may need 2 projects - one for the js, one for the server.
[20:30] <nigelb> So, just start a separate project on Launchpad?
[20:30] <lifeless> that will depend on how you plan to get the js into lp pages
[20:31] <nigelb> I might need some help there, because I'm not sure how to do that.
[20:31] <lifeless> sure
[20:31] <nigelb> I've only touched Launchpad-related JS once.
[20:32] <lifeless> I wouldn't make the project until you've a handle on that then.
[20:32] <lifeless> cause you won't know if you're making 1 or 2.
[20:33] <lifeless> anyhow the microservice needs to be truely self contained, tested, etc.
[20:33] <nigelb> I guess the sensible approach is to just start writing the server-side code in a +junk branch and finish that off.
[20:34] <lifeless> finally to integrate with LP, need to have a test that js failures in LP do reach out to the url with a GET, and that the url is correct
[20:34] <lifeless> nigelb: sure, thats what I did with gpgverifyd
[20:34] <nigelb> cool, so once I get this db patch done, I'll start writing the wsgi app.
[20:35] <lifeless> wallyworld: hi
[20:35] <wallyworld> lifeless: hello. how's parenthood?
[20:35] <lifeless> wallyworld: you seem to be the closest working js person :)
[20:35] <lifeless> wallyworld: *intense* :)
[20:35] <wallyworld> hah, you must be desperate :-)
[20:36] <wallyworld> how can i help?
[20:36] <lifeless> wallyworld: nigelb is planning on working on bug 741991.
[20:36] <_mup_> Bug #741991: launchpad users have to manually report javascript failures <javascript> <Launchpad itself:Triaged> < https://launchpad.net/bugs/741991 >
[20:36]  * wallyworld looks
[20:36] <lifeless> wallyworld: architecturally we're fine - but there is a pragmatic question around the (small) js needed.
[20:36] <lifeless> wallyworld: big picture this is a microservice that translates crafted GET requests into oops reports.
[20:37] <lifeless> wallyworld: with a couple of small bits of JS to turn errors in the page into GET requests to the url that that service is running on.
[20:38] <lifeless> wallyworld: some of that js is about encoding stuff to the service. The rest is about how to trap errors - baseline js, and then after yui loads a yui last resort handler.
[20:39] <lifeless> wallyworld: so the question is, how should we make that js available to LP pages?. The microservice URL can be mapped into our namespace (e.g. at <root>/+jsoops)
[20:39] <m4n1sh> is curtis hovey around?
[20:39] <m4n1sh> dont know his nick
[20:39] <nigelb> m4n1sh: its sinzui and he's around US timings I believe.
[20:39] <lifeless> he is not. It is sinzui.
[20:39] <m4n1sh> lifeless: nigelb  thanks
[20:39] <nigelb> UTC-0400 to be more precise.
[20:40] <wallyworld> lifeless: we could hook something in using base-layout-macros.pt. i'm not 100% familair with yui's error hooks though
[20:40] <m4n1sh> wanted some help on lp-release-manager-tools
[20:41] <lifeless> wallyworld: I kindof meant - do we copy the js in (to avoid another page load), or do we have a combo loader that can talk across projects, or do we inline the code (and reference it via an egg or something?)
[20:41] <lifeless> wallyworld: this doesn't need to be sorted $now, just when nigelb is getting close to done on the service.
[20:42] <nigelb> (I'm just planning on starting the service this week)
[20:43] <wallyworld> lifeless: first thought is that if the code is small which i expect it will be it would be nice to copy it in to avoid another page load, hence the base-layout-macro suggestion
[20:44] <lifeless> inlining it but not having it in the LP tree itself would also avoid the page load
[20:44] <lifeless> and perhaps be easier to maintain (can't forget to do something you don't need to do)
[20:45] <wallyworld> yes. i didn't account for the fact that you want to have this as generic code outside of the lp tree?
[20:45] <lifeless> thats right
[20:45] <lifeless> if we do this well, u1, landscape, sso and perhaps others can use it.
[20:46] <nigelb> Hrm, I hadn't thought that far.
[20:46] <wallyworld> we could do what we do for yui - pack it with our stuff into a launchpad.js
[20:46] <wallyworld> yui is now a tarball which is versioned using buildout
[20:46] <lifeless> yeah
[20:46] <lifeless> ok
[20:47] <lifeless> so this microservice can be released as a tarball
[20:47] <lifeless> and we can unpack the tarball and yank out the js
[20:47] <wallyworld> i added a buildout recipe for yui
[20:47] <wallyworld> yes
[20:47] <lifeless> great
[20:47] <lifeless> nigelb: I think one project
[20:48] <wallyworld> and pack the js into launchpad.js and include it inline where required
[20:49] <wallyworld> it will be nice to have this client error reporting functionality
[20:49] <nigelb> lifeless: excellent, okay.
[20:49] <lifeless> nigelb: how does js-oopsd grab you as a project name ?
[20:50] <nigelb> Not cute, fits the bill :)
[20:50] <lifeless> would you like me to set it up ?
[20:51] <nigelb> Yes, please. I'm guessing a lot of it need Canonical powers
[20:51] <lifeless> it shouldn't
[20:51] <lifeless> but I have it memorised :P
[20:51] <nigelb> HA
[20:54] <nigelb> You used http://pypi.python.org/pypi/web for gpgverifyd?
[20:55] <lifeless> I did. I used even less for lp:gpgfixtures
[20:56] <lifeless> erm python-gpgfixtures. Something.
[20:56] <nigelb> Yeah, I saw.
[20:56] <nigelb> But it seems to be alpha.
[20:56] <lifeless> its not integrated to LP yet, but neither is gpgverifyd
[20:56] <lifeless> I am planning on dropping web.py from gpgverifyd for just plain ol wsgi
[20:57] <lifeless> or wsgi + paste
[20:57] <nigelb> I'm looking at paste as wel.
[20:57] <nigelb> It seems simple enough but too much work.
[20:57] <lifeless> paste is now webob
[20:57] <nigelb> *not too
[20:58] <lifeless> but the bits I needed from paste for the gpg keyserver were -tiny-
[20:58] <nigelb> Gah, I wish documentation was updated on the wsgi website.
[20:58] <lifeless> its 99% plain wsgi
[20:58] <lifeless> there is an updated PEP
[20:58] <nigelb> 3333?
[20:59] <lifeless> yes
[21:01] <lifeless> ok
[21:01] <lifeless> js-oopsd is all ready to go except for trunk having *content*
[21:01] <lifeless> you can branch it though
[21:01] <nigelb> \o/
[21:02] <lifeless> What I've been doing for things like python-oops is copying everything but .bzr in from the project before and then tweaking
[21:02] <lifeless> checking with 'bzr diff' that I've caught every occurence I need to worry about :)
[21:06] <nigelb> lifeless: Ah, the wsgiref.simple_server is the plain ol wsgi way?
[21:06] <lifeless> yes
[21:06] <nigelb> Now, I'm less confused. :)
[21:06] <lifeless> wsgiref is in the standard library
[21:07] <nigelb> I was thinking you wanted me to first implement a library based on the PEP and then use it.
[21:07] <nigelb> And I kept wondering what I got myself into :P
[21:07] <lifeless> -lol-
[21:11] <nigelb> lifeless: This will be a stateless server right? Acting only on the parameters in GET.
[21:11] <lifeless> yes
[21:11] <lifeless> and the options passed to the command line :)
[21:11] <nigelb> Oh.
[21:12] <lifeless> (like --oops-dir and --oops-prefix)
[21:12] <nigelb> What kind of options? Oh wait. Let me write iteration 1 tomorrow.
[21:12] <nigelb> ah, right. those.
[21:12] <lifeless> the gpgverifyd __main__ should show you how to configure that up [ except you will need *two* prefixes ]
[21:12] <lifeless> one prefix for failures in this wsgi app itself
[21:13] <nigelb> failures?
[21:13] <lifeless> one prefix to use for failures generated from js pages
[21:13] <lifeless> unexpected exceptions :)
[21:13] <nigelb> Ah, that prefix.
[21:15] <nigelb> Woah, 3 am. *heads to sleep*
[21:39] <ajmitch> so I finally got LP to run again on my laptop, it was of course a simple PEBKAC...
[21:40] <ajmitch> the appserver can't talk to the openid provider when http_proxy/https_proxy is set
[22:06] <lifeless> ajmitch: :P
[22:07] <ajmitch> lifeless: the exception wasn't being displayed or apparantly logged somewhere, so it took a little while to find
[22:07] <ajmitch> I didn't expect that it would be looking at proxy settings
[22:08] <lifeless> ajmitch: not logged? thats surprising.
[22:08] <lifeless> what were the symptoms you had ?
[22:08] <ajmitch> an error page about OpenID provider discovery
[22:08] <lifeless> did it have an oops id ?
[22:09] <ajmitch> not that I recall, let me start it again & try
[22:11] <ajmitch> no OOPS, just "OpenID Provider Is Unavailable at This Time"
[22:12] <lifeless> ajmitch: so, in a multi provider world, thats fairly reasonable. However we're stil single provider, and if/when we go multiple we'll still want to take action if Ubuntu SSO is having issues.
[22:13] <lifeless> ajmitch: -> file a bug ('failure to talk to do provider discovery on the Ubuntu SSO does not OOPS')
[22:14] <ajmitch> from what I can see, it just uses lib/lp/app/templates/launchpad-discoveryfailure.pt
[22:14] <ajmitch> at least I can start looking at other stuff now instead of just being blocked on login :)
[22:16] <lifeless> indeed.
[22:16] <lifeless> you'll filed that bug ?
[22:16] <ajmitch> in the process of doing so
[22:18] <ajmitch> bug 847823
[22:18] <lifeless> thanks!
[22:18] <ajmitch> s/823/423/
[22:25] <lifeless> mwhudson: 120 lines. Really?
[22:25] <lifeless> mwhudson: as in, can't hatchet it down to size ?
[22:25] <mwhudson> lifeless: as in, this was presented to me as the way to do the query using our current data model
[22:25] <lifeless> ><
[22:26] <mwhudson> which we kinda knew was wrong, but this is a new illustration :)
[22:26] <lifeless> pgsql will probably have a hernia optimising it
[22:26] <lifeless> and degrade to to a genetic optimiser
[22:26] <mwhudson> really we should be using a kv store for this (i suspect)
[22:26] <lifeless> what thing?
[22:27] <mwhudson> http://validation.linaro.org/lava-server/dashboard/reports/kernel-ci-data/
[22:28] <lifeless> wow
[22:28] <lifeless> I don't see how you can get to 120 lines for that :)
[22:29] <mwhudson> well, using django's contenttypes thingy is part of it
[22:29] <mwhudson> (and that wasn't my fault)
[22:30] <lifeless> thats a horrible name in a web app
[22:30] <lifeless> truely inspired
[22:31] <lifeless> you'd have to search quite hard to find something more ambiguous with a different default association
[22:31] <mwhudson> the horror does not stop with the name
[22:37] <lifeless> did you mean 120 lines of python that generates sql, or 120 lines in the resulting sql ?
[22:39] <mwhudson> i mean 120 lines of hand written sql
[22:41] <lifeless> wow
[22:41] <lifeless> how does that related to the contenttypes thingy?
[22:43] <jelmer> hey lifeless, welcome back
[22:44] <lifeless> thanks
[22:50] <lifeless> flacoste: horrible name, but http://pypi.python.org/pypi/RunningCalcs/0.1 - online algorithms; might be able to simplify the PPR using this