StevenKwgrant: https://code.launchpad.net/~stevenk/launchpad/xmlexport-all-specs/+merge/15906101:45
wgrantStevenK: k01:47
StevenKIf I Y.Node.create('<div/>') and then calendar.render(), the div gets added to <body>05:23
wgrantStevenK: <div/> won't work in some browsers05:24
StevenKBut I want the <div> inside the overlay :-(05:25
wgrantStevenK: <div></div> is more compatible.05:27
StevenKwgrant: Sure, but the issue is where it is05:28
wgrantStevenK: That might not be irrelevant05:28
wgrantI don't remember which browser it was05:29
wgrantMaybe IE805:29
wgrantbut it did really really strange shit when trying to create a void div05:29
StevenKI've switched to <div></div>, but it still gets added right at the top05:29
StevenKwallyworld_, wgrant: Getting closer: http://wedontsleep.org/~steven/new-calender-1.jpg06:26
StevenKhttp://wedontsleep.org/~steven/new-calendar-1.jpg even06:26
wallyworld_looking better06:26
wallyworld_needs sone css lovin'06:26
StevenK     * Too wide, and needs to be positioned correctly06:27
StevenK     * Need to handle time input06:27
StevenK     * The selection function does not fire06:27
wallyworld_selection function - did you debug in fb?06:28
StevenKI tried06:28
StevenKSetting a break inside it doesn't fire06:28
wallyworld_i reckon there would be an onclick inside the calendar js06:29
wallyworld_which then fires the onselect event06:29
wallyworld_perhaps debugging in there will be useful06:29
StevenKAnd in calendar-base:         this.fire("selectionChange", {newSelection: this._getSelectedDatesList()});06:29
wallyworld_is this line called?06:29
StevenKDoesn't seem to be06:32
StevenKStill digging06:32
StevenKwallyworld_: If calendar says it requires calendar-base, does my module also need to pull in calendar-base?06:33
wallyworld_no, bit calendar base should be added to the combo loader config06:34
wallyworld_i forget exactly what needs doing for that06:34
StevenKYeah, -base is dragged in06:35
wallyworld_i would expect errors on the console if there were any dependency issues06:36
wallyworld_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 event06:37
wallyworld_and start debugging from there06:37
wgrantStevenK: https://code.launchpad.net/~wgrant/launchpad/bug-1169441/+merge/15908606:56
StevenKwgrant: One niggle is to change the AccountStatus.DEACTIVATED, AccountStatus.NOACCOUNT wrapping, but if you don't want to, it's fine. r=me.07:17
wgrantStevenK: Thanks07:19
wgrantI've been seeing these oopses for a while, but thought I'd caught all the cases07:19
wgrantEvidently not.07:19
adeuringgood morning07:52
cjwatsonI 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.13:22
=== wedgwood_away is now known as wedgwood
james_wcjwatson: so the template change caused the test failure, and you tried the code change to adjust?13:50
cjwatsonI was expecting the template change to cause that particular test failure initially13:53
james_wah, ok13:53
james_wit didn't look like a change that would affect the queries13:54
wgrantcjwatson: Isn't it likely that those extra 5 queries are your preloading queries?13:54
wgrantWhich is fine13:54
wgrantAs long as the query count doesn't scale with the batch size.13:54
cjwatsonwgrant: That seems odd given that there were an extra five before I did any preloading13:55
wgrantcjwatson: Not at all odd if the test only showed one PCJ row13:55
cjwatsonI suppose it's possible no preloading is necessary and I just misfired13:55
wgrantYou'd expect there to be the same number of queries.13:55
cjwatsonAh, I should check that13:55
wgrantIf one row has to grab data from 10 tables, you're probably going to have to preload from 10 tables still13:56
wgrantYou just do it all in one hit.13:56
wgrantNot once per row.13:56
james_whi wgrant13:56
james_wwgrant: is there a tarmac instance for oops stuff?13:57
wgrantI'm about to disappear again, but I suspect that if you add an extra PCJ to the queue you'll see that it's fine13:57
wgrantjames_w: I don't remember if it ever ended up working...13:57
wgrantBut I'm gone13:57
wgrantWill be back in an hoursh13:57
james_wso I should land https://code.launchpad.net/~james-w/python-oops-datedir-repo/new-publisher-api/+merge/152924 by hand?13:58
wgrantjames_w: The last few commits to trunk aren't even merges.14:33
wgrantjames_w: I think python-oops-tools is (was?) tarmac-managed, but datedir-repo isn't.14:33
wgrantIn general, if you're able to modify the branch then it's not managed by PQM or Tarmac.14:33
james_wI'll land manually14:34
james_wwgrant: would you then do a release or give me pypi rights please?14:34
wgrantjames_w: What's your PyPI username?14:38
james_wwgrant: jamesw14:38
wgrantjames_w: Done14:41
=== mbarnett` is now known as mbarnett
cjwatsonHmm.  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.23:40

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!