's [06:16] The Calendar docs do say parent node, but I'm not clear if that's immeadiate parent or up the chain [06:17] StevenK: I make that 0.95%, not 9.5% [06:17] Oh [06:18] Missed a zero [06:24] StevenK: Fixed [06:25] wgrant: What is the fix? [06:25] StevenK: The main CSS is in calendar-base, not calendar [06:25] + [06:25] + [06:26] It's still ugly and the nav buttons are oddly unthemed, but it's a bit of an improvement [06:26] wgrant: We can include them directly in combo.css if you wish [06:26] that might need calendarnavigator stuff [06:27] StevenK: Yes, that's what we'll want to do eventuall [06:27] Once we work out which bits we need. [06:27] Or we could comboload them somehow [06:28] Ah [06:28] wgrant: It's an extra 130 lines [06:29] They get merged. [06:29] 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] So we probably just want to include all the calendar stuff under yui/assets [06:29] Oh, only the skin bits end up under there [06:30] So we need calendar-core.css and calendar-base-core.css from elsewhere [06:31] assets/skins/sam/calendar{,-base,navigator}.css ? [06:31] I assume navigator is needed for the month switching arrows [06:31] Checking now [06:33] The -skin variants seem to be minified [06:33] I should probably read some documentation [06:34] I wonder if the stuff in yui/assets/skins/sam is concatenated core and skin [06:34] Yeah [06:35] I think it's tiny enough to go into combo.css [06:35] [06:35] [06:35] [06:35] That should be all we need [06:35] Though the navigator buttons have now entirely disappeared, that's possibly because they're not enabled? [06:40] Ah, no, the skin replaces the < and > with background images that don't display, because the nodes end up contentless [06:40] StevenK: Are you more on track now? [06:40] 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] Right [06:42] Why don't the background images display? [06:43] I suspect because the sole node inside them is display: none, so the node has no size. [06:44] It may work better if the core sam stuff is loaded [06:44] But it's not clear whether we actually want to use that. [06:52] StevenK: Ah [06:52] I think it's our obsolete grid CSS [06:52] Setting display: inline-block gets the images to show [06:53] Are they both on the left and cut off? [06:53] (we're still using 3.0.0preSOMETHING grids, I assume because 3.0.0 final changed them incompatibly) [06:53] StevenK: Not if you set display: inline-block on the header [06:53] You're hacking that in using firebug? [06:55] StevenK: Using Chromium's dev tools I added .yui3-u { display: inline-block } [06:55] Ah. [06:56] 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] StevenK: Yes, due to how inline-block works it needs to be on the parent. [06:57] I think the only yui3-u might be the "April 2013" header text [06:57] So try setting it there. [06:58] No, the two a's are also yui3-u [07:00] So they are. [07:01] Oh [07:01] We can probably include the modern CSS [07:01] The modern cssgrids CSS, that is [07:01] Since it's all yui3-* [07:01] Whereas our old embedded copy is YUI2-style cssgrids, with yui-* [07:02] Huh, so it is [07:02] I thought they were incompatible [07:02] But it seems not [07:03] * StevenK sprinkles in yui/cssgrids/cssgrids.css [07:03] A significant improvement [07:04] BAH [07:04] I had a make run backgrounded [07:05] Caught it early enough that it didn't spew processes [07:05] wgrant: Indeed, that looks great [07:07] StevenK: It's still obese, but that might just be the overlay being too wide to start with? [07:07] It looks pretty much exactly like the example [07:08] Yeah, setting a width on the yui3-calendar-content makes it much more sensible. [07:08] To what? [07:08] 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] StevenK: I just set it to 300px to see if it worked. [07:09] wgrant: The width can be set for the widget on creation [07:09] Ah, right [07:10] Indeed, I now see width: 340px on the example. [08:09] StevenK: thanks [08:10] cjwatson: Happy to help [08:39] 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] cjwatson: Did you leave the combo_url hack in place? [09:00] yes [09:04] cjwatson: Restart the webapp, the JS should work [09:05] cjwatson: The combo_url hack includes a revision number which qas doesn't have any more [09:06] thanks, I did wonder if it might be something like that but wasn't sure what the correct target would be [09:06] also: lxc is actually rather tasty once I've got it set up for testing in place of schroot [09:06] I expected it to be more work but more accurate/better; I didn't expect it to actually be less work [09:07] I've ignored lxc. My only experience has been with fiddling the Jenkins setup to make use of it [09:08] Maybe we should just get +combo configured on mawson [09:08] Then we can drop that horrid hack [09:10] ok, why am I getting 503 on everything after restarting the server ... [09:11] ah, I just didn't wait long enough [09:11] yep, expanders back, thanks [09:12] cjwatson: Yes, mawson's webapp takes an eon to actually start serving requests [09:13] cjwatson: I tend to tail -f the nohup file just so I can know when it's actually going to answer [09:35] when do deployments lock down for Ubuntu release? [09:36] (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] cjwatson: We tend to not want to deploy during release week [09:49] But given it's NDT, it might be okay [09:55] Deployments are safe now [09:55] I wouldn't even suggest avoiding fdts during release week [09:55] It's been a very long time since something broke badly [09:55] wgrant: lets not jinx it ;) [09:55] cjwatson: Did you use /Running/LXC? [09:55] wgrant: Yes [09:56] wgrant: I seem to recall you objecting to +combo on mawson [09:56] wgrant: No hitches at all [09:56] StevenK: Only in that I needed it working earlier than I could convince ops to set up convoy [09:57] cjwatson: Great, wasn't sure if that still worked [09:57] wgrant: convoy is on mawson [09:57] StevenK: Installed [09:57] With a raring host, for the record [09:57] But not configured in apache [09:57] wgrant: Right, but we can probably just get the snippet from qas clagged into mawson [09:57] cjwatson: btw, I think that any Ubuntu developer who isn't using LXC is probably missing out [09:57] With a path change or two [09:58] StevenK: Probably [09:58] Feel free to convince ops to do it :) [09:58] 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] stgraber has been pimping it at us for a year or more [09:59] Until 9 months ago or so it was dreadfully buggy and unstable [09:59] But it's great now [10:01] wgrant: Sure, but I've forgotten how qas is set up :-) [10:48] cjwatson: the bug you just commented on that seb128 filed is that something you will be working on [10:48] if so waht way do you want it triaged [10:48] not immediately since it has some complex dependencies [10:49] feel free to triage as you would normally do [10:49] That's Low at highest [10:49] It's tempting to introduce a new priority just to use that :) [10:49] A new, lower priority :) [10:49] it's not entirely unimportant for us [10:49] since it just caused a big argument on -release :) [10:50] 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] there are a few other possibilities but I think that's the least broken [10:51] Quite possibly, but the auto-superseding before the publisher bit will be problematic. [10:57] I assumed it wasn't easy or we'd already be doing it [10:57] But even so :) === olli__ is now known as olli === wedgwood_away is now known as wedgwood === deryck is now known as deryck[lunch] === deryck[lunch] is now known as deryck [23:14] wgrant: The overlay seems very attached to being wide === wedgwood is now known as wedgwood_away