=== almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [09:34] Is lifeless back tomorrow or next monday? [11:00] Project db-devel build #855: FAILURE in 0.28 sec: https://lpci.wedontsleep.org/job/db-devel/855/ [12:15] ouch, build failure in 0.28 sec, that is fast [15:41] its going to get opened anyway :) [15:42] (bah, wrong channel) [16:01] Yippie, build fixed! [16:01] Project db-devel build #856: FIXED in 4 hr 41 min: https://lpci.wedontsleep.org/job/db-devel/856/ === aldeka is now known as aldeka-mobi [19:15] morning [19:15] nigelb: I am back now [19:16] lifeless: GOOD Morning! [19:16] I just wrapped up a db-devel patch [19:16] I have to run the entire *tests* before I submit an MP? [19:17] no [19:17] they *have* to be run before landing ;) [19:17] Ah. Instructions said so. [19:17] 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] I can start a test run, but I'm afraid it might take quite a while on my core 2 duo :) [19:17] how much memory do you have? [19:18] 2Gigs [19:18] the process is less likely to get restarted if you've run them all, but I consider that 'must' a 'should' :P [19:18] you might like looking into the lxc parallel stuff and run 2 test runners with 1/2 the tests each [19:18] ok, I'll start a test run and head to bed. [19:19] lifeless: Family doing okay now? :) [19:20] we're still learning, but the medical stuff seems to have settled down. [19:20] :) [19:20] That's good to hear [19:22] Oh. [19:23] db-devel test != devel tests. [19:29] nigelb: are you running oneiric? [19:29] Nope. Old School! Lucid [19:32] hah, ok [19:32] Hrm, one error so far. Looks unrelated. http://paste.ubuntu.com/687111/ [19:33] nigelb: looks like you might be missing a copy of pgbouncer [19:35] Isn't that a dep? [19:35] Or rather, shouldn't it be a dep? [19:42] webapp-authorization.txt is failing as well. [19:46] woah.*lots* of fail :( [19:52] ARGH. [19:52] How often does devel get merged into db-devel? [19:52] I may have made a *big* mistake :| [19:52] devel->db-devel - every time devel passes buildbot [19:53] makeBugTasks() in tests are failing because that field doesn't exit. [19:53] *exist [19:53] * nigelb looks at models [19:53] GRAR. [19:53] Yep. Its here. [19:53] that means the process worked :P - we've just shown that we haven't (yet) removed deps on the field completely. [19:54] Well, technically, no. [19:54] I removed these deps the other day. [19:54] I sense my db-devel is out of date. [19:56] \o/ Yes. Stabbing myself in the foot++ [20:04] ftw, ftw, ftw [20:10] 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] doing teaches well :) [20:12] Yeah. The DB process is neat. Taught a bit of postgres as well. [20:19] lifeless: Is there already a bug about JS OOPS or do you want me to file one and assign to myself? [20:19] I don't know [20:20] A quick google search doesn't give me anything. But I might be phrasing it wrong. [20:20] I wonder if we've fixed bug 294656 yet [20:20] <_mup_> Bug #294656: Every page requests two JavaScript libraries (remove MochiKit)

< https://launchpad.net/bugs/294656 > [20:21] bug 741991 [20:21] <_mup_> Bug #741991: launchpad users have to manually report javascript failures < https://launchpad.net/bugs/741991 > [20:23] lifeless: nope, not fixed yet. Still see it. [20:24] need to start figuring out where to start. [20:25] on mochikit or oopses ? [20:25] oopses [20:26] make sure you have read https://dev.launchpad.net/ArchitectureGuide/ServicesRequirements [20:27] if you would like some ahead-of-time design, create a technical LEP (I don't think it needs one) [20:27] I think you handed me a technical LEP the other day :) [20:29] then, bring up a microservice for it - involves making a new project - https://dev.launchpad.net/CreatingNewProjects [20:29] "Don't be overly cute." HA. [20:29] you may need 2 projects - one for the js, one for the server. [20:30] So, just start a separate project on Launchpad? [20:30] that will depend on how you plan to get the js into lp pages [20:31] I might need some help there, because I'm not sure how to do that. [20:31] sure [20:31] I've only touched Launchpad-related JS once. [20:32] I wouldn't make the project until you've a handle on that then. [20:32] cause you won't know if you're making 1 or 2. [20:33] anyhow the microservice needs to be truely self contained, tested, etc. [20:33] I guess the sensible approach is to just start writing the server-side code in a +junk branch and finish that off. [20:34] 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] nigelb: sure, thats what I did with gpgverifyd [20:34] cool, so once I get this db patch done, I'll start writing the wsgi app. [20:35] wallyworld: hi [20:35] lifeless: hello. how's parenthood? [20:35] wallyworld: you seem to be the closest working js person :) [20:35] wallyworld: *intense* :) [20:35] hah, you must be desperate :-) [20:36] how can i help? [20:36] wallyworld: nigelb is planning on working on bug 741991. [20:36] <_mup_> Bug #741991: launchpad users have to manually report javascript failures < https://launchpad.net/bugs/741991 > [20:36] * wallyworld looks [20:36] wallyworld: architecturally we're fine - but there is a pragmatic question around the (small) js needed. [20:36] wallyworld: big picture this is a microservice that translates crafted GET requests into oops reports. [20:37] 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] 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] 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 /+jsoops) [20:39] is curtis hovey around? [20:39] dont know his nick [20:39] m4n1sh: its sinzui and he's around US timings I believe. [20:39] he is not. It is sinzui. [20:39] lifeless: nigelb thanks [20:39] UTC-0400 to be more precise. [20:40] lifeless: we could hook something in using base-layout-macros.pt. i'm not 100% familair with yui's error hooks though [20:40] wanted some help on lp-release-manager-tools [20:41] 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] wallyworld: this doesn't need to be sorted $now, just when nigelb is getting close to done on the service. [20:42] (I'm just planning on starting the service this week) [20:43] 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] inlining it but not having it in the LP tree itself would also avoid the page load [20:44] and perhaps be easier to maintain (can't forget to do something you don't need to do) [20:45] yes. i didn't account for the fact that you want to have this as generic code outside of the lp tree? [20:45] thats right [20:45] if we do this well, u1, landscape, sso and perhaps others can use it. [20:46] Hrm, I hadn't thought that far. [20:46] we could do what we do for yui - pack it with our stuff into a launchpad.js [20:46] yui is now a tarball which is versioned using buildout [20:46] yeah [20:46] ok [20:47] so this microservice can be released as a tarball [20:47] and we can unpack the tarball and yank out the js [20:47] i added a buildout recipe for yui [20:47] yes [20:47] great [20:47] nigelb: I think one project [20:48] and pack the js into launchpad.js and include it inline where required [20:49] it will be nice to have this client error reporting functionality [20:49] lifeless: excellent, okay. [20:49] nigelb: how does js-oopsd grab you as a project name ? [20:50] Not cute, fits the bill :) [20:50] would you like me to set it up ? [20:51] Yes, please. I'm guessing a lot of it need Canonical powers [20:51] it shouldn't [20:51] but I have it memorised :P [20:51] HA [20:54] You used http://pypi.python.org/pypi/web for gpgverifyd? [20:55] I did. I used even less for lp:gpgfixtures [20:56] erm python-gpgfixtures. Something. [20:56] Yeah, I saw. [20:56] But it seems to be alpha. [20:56] its not integrated to LP yet, but neither is gpgverifyd [20:56] I am planning on dropping web.py from gpgverifyd for just plain ol wsgi [20:57] or wsgi + paste [20:57] I'm looking at paste as wel. [20:57] It seems simple enough but too much work. [20:57] paste is now webob [20:57] *not too [20:58] but the bits I needed from paste for the gpg keyserver were -tiny- [20:58] Gah, I wish documentation was updated on the wsgi website. [20:58] its 99% plain wsgi [20:58] there is an updated PEP [20:58] 3333? [20:59] yes [21:01] ok [21:01] js-oopsd is all ready to go except for trunk having *content* [21:01] you can branch it though [21:01] \o/ [21:02] 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] checking with 'bzr diff' that I've caught every occurence I need to worry about :) === aldeka-mobi is now known as aldeka [21:06] lifeless: Ah, the wsgiref.simple_server is the plain ol wsgi way? [21:06] yes [21:06] Now, I'm less confused. :) [21:06] wsgiref is in the standard library [21:07] I was thinking you wanted me to first implement a library based on the PEP and then use it. [21:07] And I kept wondering what I got myself into :P [21:07] -lol- [21:11] lifeless: This will be a stateless server right? Acting only on the parameters in GET. [21:11] yes [21:11] and the options passed to the command line :) [21:11] Oh. [21:12] (like --oops-dir and --oops-prefix) [21:12] What kind of options? Oh wait. Let me write iteration 1 tomorrow. [21:12] ah, right. those. [21:12] the gpgverifyd __main__ should show you how to configure that up [ except you will need *two* prefixes ] [21:12] one prefix for failures in this wsgi app itself [21:13] failures? [21:13] one prefix to use for failures generated from js pages [21:13] unexpected exceptions :) [21:13] Ah, that prefix. [21:15] Woah, 3 am. *heads to sleep* [21:39] so I finally got LP to run again on my laptop, it was of course a simple PEBKAC... [21:40] the appserver can't talk to the openid provider when http_proxy/https_proxy is set [22:06] ajmitch: :P [22:07] lifeless: the exception wasn't being displayed or apparantly logged somewhere, so it took a little while to find [22:07] I didn't expect that it would be looking at proxy settings [22:08] ajmitch: not logged? thats surprising. [22:08] what were the symptoms you had ? [22:08] an error page about OpenID provider discovery [22:08] did it have an oops id ? [22:09] not that I recall, let me start it again & try [22:11] no OOPS, just "OpenID Provider Is Unavailable at This Time" [22:12] 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] ajmitch: -> file a bug ('failure to talk to do provider discovery on the Ubuntu SSO does not OOPS') [22:14] from what I can see, it just uses lib/lp/app/templates/launchpad-discoveryfailure.pt [22:14] at least I can start looking at other stuff now instead of just being blocked on login :) [22:16] indeed. [22:16] you'll filed that bug ? [22:16] in the process of doing so [22:18] bug 847823 [22:18] thanks! [22:18] s/823/423/ [22:25] mwhudson: 120 lines. Really? [22:25] mwhudson: as in, can't hatchet it down to size ? [22:25] lifeless: as in, this was presented to me as the way to do the query using our current data model [22:25] >< [22:26] which we kinda knew was wrong, but this is a new illustration :) [22:26] pgsql will probably have a hernia optimising it [22:26] and degrade to to a genetic optimiser [22:26] really we should be using a kv store for this (i suspect) [22:26] what thing? [22:27] http://validation.linaro.org/lava-server/dashboard/reports/kernel-ci-data/ [22:28] wow [22:28] I don't see how you can get to 120 lines for that :) [22:29] well, using django's contenttypes thingy is part of it [22:29] (and that wasn't my fault) [22:30] thats a horrible name in a web app [22:30] truely inspired [22:31] you'd have to search quite hard to find something more ambiguous with a different default association [22:31] the horror does not stop with the name [22:37] did you mean 120 lines of python that generates sql, or 120 lines in the resulting sql ? [22:39] i mean 120 lines of hand written sql [22:41] wow [22:41] how does that related to the contenttypes thingy? [22:43] hey lifeless, welcome back [22:44] thanks [22:50] flacoste: horrible name, but http://pypi.python.org/pypi/RunningCalcs/0.1 - online algorithms; might be able to simplify the PPR using this