[00:28] <StevenK> cjwatson: r=me. I'll land it if you haven't already when I return from breakfast.
[02:33] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/dump-top-level-yui/+merge/158837 I can't see anything in the deployment stuff that needs the top-level directory
[02:33] <StevenK> Unsure about buildbot
[02:36] <wgrant> StevenK: That seems fine, if anything breaks then we'll fix it.
[02:38] <wgrant> StevenK: You'll want to check that the tree on carob doesn't have it
[02:38] <wgrant> But I think clean_buildout should remove it, so that'll be fine
[02:45]  * wgrant disappears for lunch for an hour or so
[02:58] <StevenK> wgrant: Added a clean_js rule to remove it, with a comment
[03:36] <StevenK> wgrant: Not landed it yet, I don't know where the built tree on carob is
[04:03] <wgrant> StevenK: /home/warthogs/archives/rocketfuel-built
[04:03] <wgrant> IIRC
[04:05] <StevenK> Right, it has an empty yui directory
[04:06] <StevenK> wgrant: Strangely, there's a full LP tree under ~lpqateam
[04:06] <StevenK> Revision 108xx
[04:07] <wgrant> StevenK: That was used to run the PPR until yesterday
[04:07] <wgrant> I think it's unused now
[04:08] <wgrant> It had to be out of date because the PPR was moved to lp-dev-utils
[04:08] <StevenK> Ah
[04:08] <wgrant> Yesterday I fixed the lp-dev-utils version and changed the crontab to use it
[04:10] <StevenK> Ah
[04:10] <StevenK> wgrant: Should I remove it, or that can wait a few days?
[04:10] <wgrant> StevenK: Check that nothing in the crontab uses it, and then kill it I guess
[04:11] <StevenK> DBR=/home/lpqateam/launchpad/utilities/report-database-stats.py -U devpadreports -d launchpad_prod_master -H lp-prod-pgbouncer.internal --limit=30
[04:11] <StevenK> Not exactly
[04:11] <wgrant> Ah, that is unfortunate.
[04:11] <wgrant> So leave it, I guess :)
[04:12] <StevenK> Yeah, it's not like carob is currently begging for space
[04:14] <StevenK> wgrant: How does a branch to promote 3.9.1 sound?
[04:16] <wgrant> StevenK: It's been almost 48 hours, so sounds good.
[04:54] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/391-by-default/+merge/159546 trivial
[04:55] <wgrant> StevenK: k
[05:33] <StevenK> I do not get why the CSS rules are not applied
[05:55] <wgrant> StevenK: Do you have a branch?
[05:56] <StevenK> wgrant: For this YUI calendar? Nope
[05:56] <StevenK> wgrant: I can push one up if you'd like to have a play and hopefully fix some of it
[05:56] <wgrant> I can hopefully at least fix the CSS
[05:57] <StevenK> "Note: be sure to add the yui3-skin-sam classname to the page's <body> element or to a parent element of the widget in order to apply the default CSS skin."
[05:57] <StevenK> Which I've done, but it doesn't help
[06:00] <StevenK> wgrant: lp:~stevenk/launchpad/new-yui3-calendar it's based off devel as of last week, so you'll likely get an easy to resolve conflict in Makefile
[06:05] <wgrant> StevenK: I'd avoid destroying yui2 in the same branch, simply to avoid confusing things, but let's see.
[06:06] <StevenK> I can probably do that pretty easily
[06:06] <StevenK> wgrant: So we continue building it, but drop it from the combo loader and yuixhr?
[06:08] <wgrant> StevenK: I'd drop it all in one hit
[06:08] <wgrant> Dropping it is not a prereq for adding the new calendar.
[06:08] <StevenK> True
[06:08] <wgrant> If I want to see what your calendar changes were in a year, I don't want to have to wade through 30000 lines of YUI2 diff that are in the same rev for no reason :)
[06:09] <StevenK> But I live to make your life hard ... :-P
[06:12] <wgrant> I know :)
[06:12] <StevenK> wgrant: Right, done. I can delete current branch and push this small and clean up if you wish
[06:12] <wgrant> I imagine it's about 1% of the size :)
[06:12] <wgrant> But I've got your existing one running now
[06:13] <StevenK> 9.5%
[06:13] <StevenK> 257 lines versus 26808
[06:16] <StevenK> wgrant: In the depths of calendar.js, I create a container_div where I set the classes. That was testing a theory, which turned out to be false, but I'm not certain if we care about another level of <div>'s
[06:16] <StevenK> The Calendar docs do say parent node, but I'm not clear if that's immeadiate parent or up the chain
[06:17] <wgrant> StevenK: I make that 0.95%, not 9.5%
[06:17] <StevenK> Oh
[06:18] <StevenK> Missed a zero
[06:24] <wgrant> StevenK: Fixed
[06:25] <StevenK> wgrant: What is the fix?
[06:25] <wgrant> StevenK: The main CSS is in calendar-base, not calendar
[06:25] <wgrant> +    <link rel="stylesheet" type="text/css" href="/+icing/yui/calendar-base/assets/skins/sam/calendar-base.css" />
[06:25] <wgrant> +    <link rel="stylesheet" type="text/css" href="/+icing/yui/calendar-base/assets/skins/sam/calendar-base-skin.css" />
[06:26] <wgrant> It's still ugly and the nav buttons are oddly unthemed, but it's a bit of an improvement
[06:26] <StevenK> wgrant: We can include them directly in combo.css if you wish
[06:26] <wgrant> that might need calendarnavigator stuff
[06:27] <wgrant> StevenK: Yes, that's what we'll want to do eventuall
[06:27] <wgrant> Once we work out which bits we need.
[06:27] <wgrant> Or we could comboload them somehow
[06:28] <wgrant> Ah
[06:28] <StevenK> wgrant: It's an extra 130 lines
[06:29] <wgrant> They get merged.
[06:29] <wgrant> build/js/yui/assets/skins/sam/calendar-base.css and build/js/yui/calendar-base/assets/skins/sam/calendar-base.css are the same file
[06:29] <wgrant> So we probably just want to include all the calendar stuff under yui/assets
[06:29] <wgrant> Oh, only the skin bits end up under there
[06:30] <wgrant> So we need calendar-core.css and calendar-base-core.css from elsewhere
[06:31] <StevenK> assets/skins/sam/calendar{,-base,navigator}.css ?
[06:31] <wgrant> I assume navigator is needed for the month switching arrows
[06:31] <wgrant> Checking now
[06:33] <wgrant> The -skin variants seem to be minified
[06:33] <wgrant> I should probably read some documentation
[06:34] <wgrant> I wonder if the stuff in yui/assets/skins/sam is concatenated core and skin
[06:34] <wgrant> Yeah
[06:35] <StevenK> I think it's tiny enough to go into combo.css
[06:35] <wgrant>     <link rel="stylesheet" type="text/css" href="/+icing/yui/assets/skins/sam/calendar-base.css" />
[06:35] <wgrant>     <link rel="stylesheet" type="text/css" href="/+icing/yui/assets/skins/sam/calendar.css" />
[06:35] <wgrant>     <link rel="stylesheet" type="text/css" href="/+icing/yui/assets/skins/sam/calendarnavigator.css" />
[06:35] <wgrant> That should be all we need
[06:35] <wgrant> Though the navigator buttons have now entirely disappeared, that's possibly because they're not enabled?
[06:40] <wgrant> Ah, no, the skin replaces the < and > with background images that don't display, because the nodes end up contentless
[06:40] <wgrant> StevenK: Are you more on track now?
[06:40] <wgrant> StevenK: And do you understand how skins work now? Each component's -core and -skin files are combined into a single file that ends up under yui/assets/skins/foo
[06:42] <StevenK> Right
[06:42] <StevenK> Why don't the background images display?
[06:43] <wgrant> I suspect because the sole node inside them is display: none, so the node has no size.
[06:44] <wgrant> It may work better if the core sam stuff is loaded
[06:44] <wgrant> But it's not clear whether we actually want to use that.
[06:52] <wgrant> StevenK: Ah
[06:52] <wgrant> I think it's our obsolete grid CSS
[06:52] <wgrant> Setting display: inline-block gets the images to show
[06:53] <StevenK> Are they both on the left and cut off?
[06:53] <wgrant> (we're still using 3.0.0preSOMETHING grids, I assume because 3.0.0 final changed them incompatibly)
[06:53] <wgrant> StevenK: Not if you set display: inline-block on the header
[06:53] <StevenK> You're hacking that in using firebug?
[06:55] <wgrant> StevenK: Using Chromium's dev tools I added .yui3-u { display: inline-block }
[06:55] <StevenK> Ah.
[06:56] <StevenK> If I edit the header div to add style="display: inline-block" I get both buttons, but they're both on the left
[06:57] <wgrant> StevenK: Yes, due to how inline-block works it needs to be on the parent.
[06:57] <wgrant> I think the only yui3-u might be the "April 2013" header text
[06:57] <wgrant> So try setting it there.
[06:58] <StevenK> No, the two a's are also yui3-u
[07:00] <wgrant> So they are.
[07:01] <wgrant> Oh
[07:01] <wgrant> We can probably include the modern CSS
[07:01] <wgrant> The modern cssgrids CSS, that is
[07:01] <wgrant> Since it's all yui3-*
[07:01] <wgrant> Whereas our old embedded copy is YUI2-style cssgrids, with yui-*
[07:02] <StevenK> Huh, so it is
[07:02] <wgrant> I thought they were incompatible
[07:02] <wgrant> But it seems not
[07:03]  * StevenK sprinkles in yui/cssgrids/cssgrids.css
[07:03] <wgrant> A significant improvement
[07:04] <StevenK> BAH
[07:04] <StevenK> I had a make run backgrounded
[07:05] <StevenK> Caught it early enough that it didn't spew processes
[07:05] <StevenK> wgrant: Indeed, that looks great
[07:07] <wgrant> StevenK: It's still obese, but that might just be the overlay being too wide to start with?
[07:07] <StevenK> It looks pretty much exactly like the example
[07:08] <wgrant> Yeah, setting a width on the yui3-calendar-content makes it much more sensible.
[07:08] <StevenK> To what?
[07:08] <wgrant> The main difference is the background colour and the centred ths, and at least the latter is CSS specific to the example page
[07:08] <wgrant> StevenK: I just set it to 300px to see if it worked.
[07:09] <StevenK> wgrant: The width can be set for the widget on creation
[07:09] <wgrant> Ah, right
[07:10] <wgrant> Indeed, I now see width: 340px on the example.
[08:09] <cjwatson> StevenK: thanks
[08:10] <StevenK> cjwatson: Happy to help
[08:39] <cjwatson> Hmm, is it intentional that, after I upgraded dogfood, https://dogfood.launchpad.net/ubuntu/raring/+queue?queue_state=1 no longer has expanders?
[09:00] <StevenK> cjwatson: Did you leave the combo_url hack in place?
[09:00] <cjwatson> yes
[09:04] <StevenK> cjwatson: Restart the webapp, the JS should work
[09:05] <StevenK> cjwatson: The combo_url hack includes a revision number which qas doesn't have any more
[09:06] <cjwatson> thanks, I did wonder if it might be something like that but wasn't sure what the correct target would be
[09:06] <cjwatson> also: lxc is actually rather tasty once I've got it set up for testing in place of schroot
[09:06] <cjwatson> I expected it to be more work but more accurate/better; I didn't expect it to actually be less work
[09:07] <StevenK> I've ignored lxc. My only experience has been with fiddling the Jenkins setup to make use of it
[09:08] <StevenK> Maybe we should just get +combo configured on mawson
[09:08] <StevenK> Then we can drop that horrid hack
[09:10] <cjwatson> ok, why am I getting 503 on everything after restarting the server ...
[09:11] <cjwatson> ah, I just didn't wait long enough
[09:11] <cjwatson> yep, expanders back, thanks
[09:12] <StevenK> cjwatson: Yes, mawson's webapp takes an eon to actually start serving requests
[09:13] <StevenK> cjwatson: I tend to tail -f the nohup file just so I can know when it's actually going to answer
[09:35] <cjwatson> when do deployments lock down for Ubuntu release?
[09:36] <cjwatson> (I actually think that caution is rather less necessary now than it used to be, but perhaps now isn't the time for that debate)
[09:49] <StevenK> cjwatson: We tend to not want to deploy during release week
[09:49] <StevenK> But given it's NDT, it might be okay
[09:55] <wgrant> Deployments are safe now
[09:55] <wgrant> I wouldn't even suggest avoiding fdts during release week
[09:55] <wgrant> It's been a very long time since something broke badly
[09:55] <czajkowski> wgrant: lets not jinx it ;)
[09:55] <wgrant> cjwatson: Did you use /Running/LXC?
[09:55] <cjwatson> wgrant: Yes
[09:56] <StevenK> wgrant: I seem to recall you objecting to +combo on mawson
[09:56] <cjwatson> wgrant: No hitches at all
[09:56] <wgrant> StevenK: Only in that I needed it working earlier than I could convince ops to set up convoy
[09:57] <wgrant> cjwatson: Great, wasn't sure if that still worked
[09:57] <StevenK> wgrant: convoy is on mawson
[09:57] <wgrant> StevenK: Installed
[09:57] <cjwatson> With a raring host, for the record
[09:57] <wgrant> But not configured in apache
[09:57] <StevenK> wgrant: Right, but we can probably just get the snippet from qas clagged into mawson
[09:57] <wgrant> cjwatson: btw, I think that any Ubuntu developer who isn't using LXC is probably missing out
[09:57] <StevenK> With a path change or two
[09:58] <wgrant> StevenK: Probably
[09:58] <wgrant> Feel free to convince ops to do it :)
[09:58] <cjwatson> Well, it depends what you're doing, but it does seem pretty useful.  I used it seriously for the first time yesterday to debug an Upstart problem
[09:58] <cjwatson> stgraber has been pimping it at us for a year or more
[09:59] <wgrant> Until 9 months ago or so it was dreadfully buggy and unstable
[09:59] <wgrant> But it's great now
[10:01] <StevenK> wgrant: Sure, but I've forgotten how qas is set up :-)
[10:48] <czajkowski> cjwatson: the bug you just commented on that seb128 filed is that something you will be working on
[10:48] <czajkowski> if so waht way do you want it triaged
[10:48] <cjwatson> not immediately since it has some complex dependencies
[10:49] <cjwatson> feel free to triage as you would normally do
[10:49] <wgrant> That's Low at highest
[10:49] <wgrant> It's tempting to introduce a new priority just to use that :)
[10:49] <wgrant> A new, lower priority :)
[10:49] <cjwatson> it's not entirely unimportant for us
[10:49] <cjwatson> since it just caused a big argument on -release :)
[10:50] <cjwatson> as I say I personally think we should do this by (a) get build cancellation working reliably (b) make builds auto-supersede cleanly even before the new source publishes, which would be lovely anyway both for Ubuntu and PPAs (c) change our queue handling policy to accept all the uploads for a source at once
[10:50] <cjwatson> there are a few other possibilities but I think that's the least broken
[10:51] <wgrant> Quite possibly, but the auto-superseding before the publisher bit will be problematic.
[10:57] <cjwatson> I assumed it wasn't easy or we'd already be doing it
[10:57] <cjwatson> But even so :)
[23:14] <StevenK> wgrant: The overlay seems very attached to being wide