[00:58] cjwatson: Particularly for things like the installer I think there is zero reason to be concerned about supporting python < 2.7. === micahg_ is now known as micahg === tkamppeter_ is now known as tkamppeter [13:11] bug 864618 - anyone else think this is RC? [13:11] Launchpad bug 864618 in lightdm (Ubuntu) "UTF-8 locale no longer set (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/864618 [13:13] cjwatson: Quite. [13:15] cjwatson: I'm curious why 'locale -a' returns *.utf8 rather than *.UTF-8, though. [13:16] cjwatson: Given that we use the other naming nearly universally, wouldn't we want that tool to output the same format? [13:17] s'always been like that ... [13:18] Not saying it hasn't. Just curious. :P [13:18] I think .utf8 is glibc's preferred internal naming but .UTF-8 is what you see in SUPPORTED [13:18] personally I see it as a good thing because it makes sure people NOTICE if they break locale aliases [13:18] Heh. [13:19] Well, hunting the bit that broke lightdm should be easy enough. [13:19] I see "[+6.73s] DEBUG: Failed to find locale for language en [13:19] As for the jasper thing, I think I might just sprinkle some syncs in and see if that magically fixes it. [13:20] - Add ability to set the language of a user from the greeter (LP: #803858) [13:20] - Set LANG variable based on the user language [13:20] - Add language selector into GTK greeter (disabled by default) [13:20] fairly significant set of additions [13:21] Just confuses me a tad that it's not trusting PAM's return and just going with it. [13:22] So, entirely off-topic, but does anyone know off-hand if 'mount -o remount,ro /foo' forces a sync? [15:11] ^--- accepted that libav upstream version bump with was basically just merging in the ~70 patches that were already in debian/patches, and then 2 or 3 small/isolated fixes. [15:12] Seemed like a sensible thing to do so the security team would have a stable version to play with, rather than a stable version plus 70 cherry-picks. [17:57] nvidia-graphics-drivers - hurrah [18:00] Those aren't words oft-uttered. [18:02] dude, console-setup, what's the deal [18:03] why does your build make my laptop overheat [18:04] yes, my ACPI tables are screwed up, but why is *console-setup* running hotter than running gcc? :P [18:09] slangasek: is your laptop shutting down because of overheat? [18:09] yes [18:09] is it also doing it when AC is unplugged? [18:09] I've got screwed up values in my ACPI, the critical threshold is lower than the passive cooling threshold [18:09] so the first time the kernel knows there's a problem is when ACPI tells it to panic-shutdown :P [18:11] yeah, I had a similar issue on my x201s until I noticed my power management setting was set to "performance" when on AC, setting that to the same value (don't remember) as when on battery "fixed" it [18:11] I can now happily 3 installs in kvm, do some other work and not have my laptop shutdown every 5 minutes [18:12] what "power management setting" do you mean? [18:13] some value in the BIOS power management section [18:13] it's ridiculous that there is any setting that would give this behavior [18:13] ok, next time it powers off I'll have a look :) [18:13] the other thing is that the fan fails to spin up appropriately [18:13] levels 0-7 are all "meh" [18:14] only disengaged/full-speed actually pushes any air :P [18:14] (and thinkfan doesn't support specifying full-speed :P) [18:16] fun. apparently that's one issue the x201s doesn't share with the x201, my fan seems to work fine (set to auto and running at 4531rpm according to /proc/acpi/ibm/fan) [18:31] apparently it's ckbcomp that chews the CPU up. Really efficient, or really inefficient? [18:39] yeah! just reinstalled my server at home on Oneiric (used to be Hardy) using a single stack IPv6 network. Only issue I noticed was archive.u.c not having a AAAA record so had to switch to uk.archive.u.c [18:55] whee, 'totextmode' works for bug #864466 [18:55] Launchpad bug 864466 in kbd (Ubuntu Oneiric) (and 3 other projects) "break=foo boot option incompatible with gfxpayload=keep (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/864466 [18:57] oh, doh, no it doesn't [18:57] it just looked like it did because plymouth was being helpful :P [19:05] ah right, because totextmode didn't actually get copied to the initramfs [19:26] slangasek: I tried to optimise ckbcomp earlier in the cycle, but ran out of time ... [19:27] argh, why does oneiric now want to suspend my laptop every time I step away from it for a while [19:27] Because GNOME knows best? [19:27] Don't question it. [19:29] cjwatson: because the GNOME3 default sleep policy is ridiculous - though fortunately we at least now have a setting to change the policy [19:29] I went into System Settings -> Power after the last time it happened and told it not to do this. It did it again. [19:30] hmm [19:30] perhaps the setting isn't wired up correctly then [19:30] I suppose it might be confused by apparently thinking I have two batteries [19:31] Do you? [19:32] No [19:32] cjwatson: http://paste.ubuntu.com/701188/ [19:33] I gave up trying to do it through the UI last time... [19:33] stgraber: ah, thanks! [19:33] I'm sure this won't bother any of our users at all [19:34] err. [19:35] well, the UI is supposed to address precisely those settings; if it's not doing so, I'd say that's a critical bug [19:35] I have these settings here: [19:35] org.gnome.settings-daemon.plugins.power sleep-inactive-ac false [19:35] org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 1800 [19:35] org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing' [19:37] Does the UI not touch all the settings that stgraber pastebinned? [19:37] If it's exposing them but not actually setting them, that's unpleasant. [19:38] slangasek: I had those values for sleep-inactive-ac and sleep-inactive-ac-timeout before, but sleep-inactive-ac-type was set to 'suspend' [19:39] is it possible that that was introduced after an upgrade and not migrated properly? maybe the UI would have done it if I'd changed to something else and back again [19:39] infinity: there's the "Suspend when inactive for:" in the power section of gnome-control-center but at least at some point this week it wasn't setting it properly... [19:39] Grand. [19:40] Perhaps we should be testing that control panel with some vigor on upgraded and fresh systems? [19:40] infinity: dunno, I haven't tested, I already set it by hand before the GUI existed [19:40] some actions are also missing from the UI. I kind of like my screen to just go blank when I close the lid but that option isn't in the drop down (though it's a valid value in the gsettings schema) [19:40] Surprising suspend behaviour is one of the nastier user experiences. :/ [19:41] if I change sleep-inactive-ac-type to 'nothing' and then tell it to suspend after 1 hour in the UI, it remains at 'nothing' [19:41] bug 864479 [19:41] Launchpad bug 864479 in gnome-control-center (Ubuntu) "System goes to hibernate or suspend even when set to "Don't suspend" (affects: 4) (heat: 20)" [Undecided,Confirmed] https://launchpad.net/bugs/864479 [19:42] shall I crank the priority on that and milestone it? [19:42] IMHO yes [19:42] (though probably -updates material at this point?){ [19:42] depends how big a change it is? [19:43] I'd like to see the schema fixed as well to give a sensible default policy on AC :P [19:44] that would be a separate bug I think ... [19:44] (though I agree) [19:44] slangasek / cjwatson: Can I get one of you to review 'bzr diff /home/adconrad/debian-cd/' on antimony? [19:46] Should fix the short image bugs I was seeing. [19:46] um, well, the code's OK, I really can't vouch for accuracy of what it's intended to do ... [19:46] And then I can get back to fixing jasper. :P [19:46] cjwatson: The problem, in both cases, was that no one was accounting for the "reserved blocks" before the boot/ext partitions. [19:47] cjwatson: On mx5, that's 1 sector, on omap, that's one track (32 sectors). [19:47] Represented by these two errors: [19:48] [164532.491847] EXT4-fs (sdb3): bad geometry: block count 1580032 exceeds size of device (1580031 blocks) [19:48] [145254.594400] EXT4-fs (sdb2): bad geometry: block count 1505280 exceeds size of device (1505264 blocks) [19:48] (Note those are in 1k blocks, not 512 byte, hence the count being a bit confusing) [19:49] That is EXT4 is whining in 1k blocks, but the debian-cd code is in 512 byte sectors. [19:50] looking at the code of the power configuration plugin, the state of sleep-inactive-battery seems to change the value of sleep-inactive-battery-timeout but not the other way around. So having sleep-inactive-battery=False will set sleep-inactive-battery-timeout=0 but choosing sleep-inactive-battery-timeout=0 in the drop-down won't set sleep-inactive-battery=False [19:51] infinity: seems plausible, then [19:51] cjwatson: I can live with plausible. [19:51] stgraber: sleep-inactive-battery was set to false for me, so I don't think that's my problem [19:52] stgraber: but is sleep-inactive-{ac,battery} even the right key, or does it need sleep-inactive-{ac,battery}-type? [19:52] cjwatson: It can't actually make it more broken to add more space. I'm just hoping all the cross-eyed reading made me get the right amount. ;) [19:52] stgraber: (well, -ac) [19:52] infinity: right, makes sense [19:53] * infinity wonders if checking to see if /usr/lib/klibc/bin/reboot takes a --help argument will lead to his system rebooting. [19:53] ... and maybe I'll try on another computer. :P [19:54] cjwatson: Poking through the UI I actually see both sleep-inactive-battery and sleep-inactive-battery-timeout being updated to the right value ... that gsettings stuff is way too magical. The only key that's not changed is sleep-inactive-battery-type but it shouldn't need to be changed anyway... [19:54] infinity: I think it might actually give you a usage message by coincidence [19:55] looking at the code [19:55] slangasek: I'd have expected timeout=0 + option being set to False to be enough for it not to do anything but maybe that's where the bug actually is :) [19:55] stgraber: well, -type is what your paste changes [19:55] stgraber: I guess I'll find out after the next time I come back to my laptop [19:56] cjwatson: It did, yes. Not a terribly helpful one. [19:56] * infinity goes to look at the code instead. [19:57] ok, grabbing gnome-settings-daemon's code then as gnome-control-center seems to do what it's supposed to [20:15] bug 864787 - d'oh [20:15] Launchpad bug 864787 in ntfs-3g (Ubuntu Oneiric) (and 1 other project) "Cannot mmap file /usr/lib/libntfs-3g.so (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/864787 [20:15] will fix tomorrow [22:23] slangasek / ScottK / anyone: Around for a quick review of jasper-initramfs for me? [22:23] Maybe I should have asked that when we weren't horribly netsplit. :P [22:24] slangasek / ScottK / anyone: Around for a quick review of jasper-initramfs for me? [22:26] cjwatson: Or you, if you're not asleep or otherwise occupied? :) [22:30] We really need a way to make cron.daily not run for a day after installation. I have it running right now during oem-config-remove (yeah, I don't even have a login yet) and apt-xapian-destroyer-of-worlds is pretty much just telling me where to go and how to get there. [22:40] infinity: 'service cron stop' during the install maybe? [22:41] slangasek: Maybe. Would be nice to avoid it for some undetermined amount of time post-install too, though. [22:41] If your very first user experience is "everything is slow", it kinda sucks. [22:42] I assume it's anacron going "holy crap, we haven't booted in FOREVER" and just firing everything. [22:42] hmm [22:44] I'd rather we figure out if we're running things we shouldn't need to and stop doing that, than just deferring everything 24h and leaving stuff out of date [22:44] See -devel too. [22:45] But yeah, I don't think a universal defer is sane. [22:45] And I think that if you happen to install at 4am, or whenever daily is MEANT to happen, sucks to be you. [22:45] But anacron running daily unconditionally after install is broken. [22:46] Or during install, even. [22:47] oem-config-remove-gtk timed out a dbus call due to apt-xapian. Oh dear. [22:47] So, part of the problem here is installing a desktop OS to an SD card on a cell phone. [22:48] But still, this can't be pleasant on desktop hardware either, just less awful. [22:48] Don't we run under {,io}nice? [22:49] We, being.. The installer? [22:49] Niced up or down? [22:49] Jobs spawned from anacron. Niced to be ... nice [22:49] Oh, yes. [22:49] Generally. [22:50] But on slow systems, now amount of nice can fix this sort of thing. [22:50] s/now/no/ [22:51] "nice ionice -c3 update-apt-xapian-index -q" (from cron.daily/apt) but that's probably not enough on a system with very slow I/Os [22:52] It's really not. [22:52] I guess, yeah. [22:52] update-apt-xapian-index is vicious. [22:52] It brings some of my laptops and netbooks with real hard drives to their knees. [22:52] On SD, it's... Well... Hahaha is the only real description. [22:53] And part of that is mvo needing to profile the heck out of it, and he knows. [22:53] But I still think the general idea of "anacron running cron.daily within seconds of the install completing" is never going to be the best user experience. [22:53] infinity: touching /var/lib/apt/periodic/update-stamp should be enough to delay it for a while [22:54] stgraber: That would solve the update-apt-xapian-index one, I guess? [22:54] stgraber: Which is the big one for now. [22:54] Still, having it delayed just long enough for you to get down to some real work also sucks. [22:54] (anacron is still the actual complaint for me, I think, but that workaround might be lightweight enough to even be doable for release) [22:54] yep, that's the one being checked just before calling update-apt-xapian-index [22:55] you can probably touch /var/spool/anacron/cron.daily [22:56] I might do one or both of these as an ARM-only hack, if people aren't keen on doing it to, say, ubiquity. But I'll toss it around tomorrow when people are "at work". [22:57] Thanks for the ideas and digging. [22:57] I guess touching /var/spool/anacron/cron.daily just before unmounting /target in ubiquity would be a good way of avoiding most of the pain [22:58] Might need to happen earlier than that for the oem-config case. [22:59] What's the default delay for cron.daily? [22:59] Aaaargh. Why has my compose key mapping disappeared and where has the UI gone? [22:59] * Laney wonders why these things are breaking after final freeze [23:00] It'll fire 5 minutes after boot. [23:00] Yeah. Maybe I'll just hack around it in jasper for ARM for now. [23:01] And revisit it in ubiquity later, when I can generalise an oem-config/live-install solution that works for both. [23:01] (Well, okay, I guess it's just touching it early if oem-config mode, and later if not, but whatever) [23:01] I have gin and tonic calling me. Beckoning, even.