[00:10] also, it seems oops-tools only shows a fixed set of things from the report? [00:11] if you put interesting things in to wsgi_environ['oops.report'] you look at the raw oops to get the information? [00:13] anyway, http://ec2-107-20-69-109.compute-1.amazonaws.com/?oopsid=OOPS-163ddd75a28f733d833626ba08f80c9d shows the sql logging working too [00:13] james_w: there is a bug open on that [00:14] oh good, glad it's not desired :-) [00:14] james_w: looking good [00:14] I'll install django-timeline on lp-oops.c.c once you release it :) [00:14] lifeless, do you think that oops_wsgi should get something like ++oops++ ? [00:15] that could be nice [00:15] it needs a bit of cleanup before it can be released [00:16] I haven't implement executemany yet, as I wasn't sure what it should put for the detail, given that it's not one statement [00:16] but nothing in django core calls it, so I guess it's not too important :-) [00:16] plus we still need to figure out how to get the oops id to the user for it to be excellent [00:16] allocating the id early should be pretty easy I think, but would that break the amqp/datedir fallback? [00:18] time for dinner, thanks for your help [01:03] so, getting id to the user; ideally the fixed django that lets oops-wsgi take over, but failing that we can allocate early, yes. [01:56] isnotforpasswordsyouidiot [23:04] \o/ all non-launchpad projects retriaged. [23:37] meep [23:37] 127 operational bugs (losa tagged) [23:37] don't look at how old some of those are, fwiw. :-P [23:39] indeed [23:39] just noting that we have things that are costing us sysadmin time [23:39] 127 distinct such things. [23:39] 'aieeeee' [23:54] lifeless: Can we remove targetnamecache now? [23:54] Search has been disabled since around this time last year. [23:58] bah, still used for sorting by location.