') and then calendar.render(), the div gets added to [05:24] StevenK:

won't work in some browsers [05:25] But I want the

inside the overlay :-( [05:27] StevenK:

is more compatible. [05:28] wgrant: Sure, but the issue is where it is [05:28] StevenK: That might not be irrelevant [05:29] I don't remember which browser it was [05:29] Maybe IE8 [05:29] but it did really really strange shit when trying to create a void div [05:29] I've switched to

, but it still gets added right at the top [05:29] :( [06:26] wallyworld_, wgrant: Getting closer: http://wedontsleep.org/~steven/new-calender-1.jpg [06:26] http://wedontsleep.org/~steven/new-calendar-1.jpg even [06:26] E404 [06:26] looking better [06:26] needs sone css lovin' [06:26] some [06:27] * Too wide, and needs to be positioned correctly [06:27] * Need to handle time input [06:27] * The selection function does not fire [06:28] :) [06:28] selection function - did you debug in fb? [06:28] I tried [06:28] Setting a break inside it doesn't fire [06:29] i reckon there would be an onclick inside the calendar js [06:29] which then fires the onselect event [06:29] perhaps debugging in there will be useful [06:29] And in calendar-base: this.fire("selectionChange", {newSelection: this._getSelectedDatesList()}); [06:29] is this line called? [06:32] Doesn't seem to be [06:32] Still digging [06:33] wallyworld_: If calendar says it requires calendar-base, does my module also need to pull in calendar-base? [06:34] no, bit calendar base should be added to the combo loader config [06:34] but [06:34] i forget exactly what needs doing for that [06:35] Yeah, -base is dragged in [06:36] i would expect errors on the console if there were any dependency issues [06:37] i can't see any other option other than to look at the calendar js source and see how the button click is transformed to the firing of the selection event [06:37] and start debugging from there [06:56] StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-1169441/+merge/159086 [07:17] wgrant: One niggle is to change the AccountStatus.DEACTIVATED, AccountStatus.NOACCOUNT wrapping, but if you don't want to, it's fine. r=me. [07:19] StevenK: Thanks [07:19] I've been seeing these oopses for a while, but thought I'd caught all the cases [07:19] Evidently not. [07:52] good morning [13:22] I could use some help with query optimisation (happy to wait until .au is around). I have http://paste.ubuntu.com/5713139/ so far, but lp.soyuz.browser.tests.test_queue.TestQueueItemsView.test_query_count is giving me "queries do not match: 54 != 59", and I can't see how to optimise that. You can see my attempt at optimisation in lib/lp/soyuz/browser/queue.py in that diff, but that change made no difference. === wedgwood_away is now known as wedgwood [13:50] cjwatson: so the template change caused the test failure, and you tried the code change to adjust? [13:53] Yes [13:53] I was expecting the template change to cause that particular test failure initially [13:53] ah, ok [13:54] it didn't look like a change that would affect the queries [13:54] cjwatson: Isn't it likely that those extra 5 queries are your preloading queries? [13:54] Which is fine [13:54] As long as the query count doesn't scale with the batch size. [13:55] wgrant: That seems odd given that there were an extra five before I did any preloading [13:55] cjwatson: Not at all odd if the test only showed one PCJ row [13:55] I suppose it's possible no preloading is necessary and I just misfired [13:55] You'd expect there to be the same number of queries. [13:55] Ah, I should check that [13:56] If one row has to grab data from 10 tables, you're probably going to have to preload from 10 tables still [13:56] You just do it all in one hit. [13:56] Not once per row. [13:56] hi wgrant [13:57] wgrant: is there a tarmac instance for oops stuff? [13:57] I'm about to disappear again, but I suspect that if you add an extra PCJ to the queue you'll see that it's fine [13:57] james_w: I don't remember if it ever ended up working... [13:57] But I'm gone [13:57] Will be back in an hoursh [13:58] so I should land https://code.launchpad.net/~james-w/python-oops-datedir-repo/new-publisher-api/+merge/152924 by hand? [14:33] james_w: The last few commits to trunk aren't even merges. [14:33] james_w: I think python-oops-tools is (was?) tarmac-managed, but datedir-repo isn't. [14:33] In general, if you're able to modify the branch then it's not managed by PQM or Tarmac. [14:34] ok [14:34] I'll land manually [14:34] Great [14:34] wgrant: would you then do a release or give me pypi rights please? [14:38] james_w: What's your PyPI username? [14:38] wgrant: jamesw [14:41] james_w: Done [14:41] thanks === mbarnett` is now known as mbarnett [23:40] Hmm. Bug 851562 is harder than it looks. Generating the diff in time is easy (actually easier than doing it in its current position, I think), but showing it is hard because diffs are linked to SPRs and PCJs don't have a fixed SPR. Would it be terrible to just add an SPR reference to the PCJ table? I've never quite understood why we mess about with the source package name and version when we already have the SPR in hand.