[00:58] <ScottK> cjwatson: Particularly for things like the installer I think there is zero reason to be concerned about supporting python < 2.7.
[13:11] <cjwatson> bug 864618 - anyone else think this is RC?
[13:11] <ubot4> 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] <infinity> cjwatson: Quite.
[13:15] <infinity> cjwatson: I'm curious why 'locale -a' returns *.utf8 rather than *.UTF-8, though.
[13:16] <infinity> cjwatson: Given that we use the other naming nearly universally, wouldn't we want that tool to output the same format?
[13:17] <cjwatson> s'always been like that ...
[13:18] <infinity> Not saying it hasn't.  Just curious. :P
[13:18] <cjwatson> I think .utf8 is glibc's preferred internal naming but .UTF-8 is what you see in SUPPORTED
[13:18] <cjwatson> personally I see it as a good thing because it makes sure people NOTICE if they break locale aliases
[13:18] <infinity> Heh.
[13:19] <infinity> Well, hunting the bit that broke lightdm should be easy enough.
[13:19] <Laney> I see "[+6.73s] DEBUG: Failed to find locale for language en
[13:19] <infinity> As for the jasper thing, I think I might just sprinkle some syncs in and see if that magically fixes it.
[13:20] <cjwatson>     - Add ability to set the language of a user from the greeter (LP: #803858)
[13:20] <cjwatson>     - Set LANG variable based on the user language
[13:20] <cjwatson>     - Add language selector into GTK greeter (disabled by default)
[13:20] <cjwatson> fairly significant set of additions
[13:21] <infinity> Just confuses me a tad that it's not trusting PAM's return and just going with it.
[13:22] <infinity> So, entirely off-topic, but does anyone know off-hand if 'mount -o remount,ro /foo' forces a sync?
[15:11] <infinity> ^--- 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] <infinity> 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] <slangasek> nvidia-graphics-drivers - hurrah
[18:00] <infinity> Those aren't words oft-uttered.
[18:02] <slangasek> dude, console-setup, what's the deal
[18:03] <slangasek> why does your build make my laptop overheat
[18:04] <slangasek> yes, my ACPI tables are screwed up, but why is *console-setup* running hotter than running gcc? :P
[18:09] <stgraber> slangasek: is your laptop shutting down because of overheat?
[18:09] <slangasek> yes
[18:09] <stgraber> is it also doing it when AC is unplugged?
[18:09] <slangasek> I've got screwed up values in my ACPI, the critical threshold is lower than the passive cooling threshold
[18:09] <slangasek> so the first time the kernel knows there's a problem is when ACPI tells it to panic-shutdown :P
[18:11] <stgraber> 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] <stgraber> I can now happily 3 installs in kvm, do some other work and not have my laptop shutdown every 5 minutes
[18:12] <slangasek> what "power management setting" do you mean?
[18:13] <stgraber> some value in the BIOS power management section
[18:13] <slangasek> it's ridiculous that there is any setting that would give this behavior
[18:13] <slangasek> ok, next time it powers off I'll have a look :)
[18:13] <slangasek> the other thing is that the fan fails to spin up appropriately
[18:13] <slangasek> levels 0-7 are all "meh"
[18:14] <slangasek> only disengaged/full-speed actually pushes any air :P
[18:14] <slangasek> (and thinkfan doesn't support specifying full-speed :P)
[18:16] <stgraber> 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] <slangasek> apparently it's ckbcomp that chews the CPU up.  Really efficient, or really inefficient?
[18:39] <stgraber> 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] <slangasek> whee, 'totextmode' works for bug #864466
[18:55] <ubot4> 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] <slangasek> oh, doh, no it doesn't
[18:57] <slangasek> it just looked like it did because plymouth was being helpful :P
[19:05] <slangasek> ah right, because totextmode didn't actually get copied to the initramfs
[19:26] <cjwatson> slangasek: I tried to optimise ckbcomp earlier in the cycle, but ran out of time ...
[19:27] <cjwatson> argh, why does oneiric now want to suspend my laptop every time I step away from it for a while
[19:27] <infinity> Because GNOME knows best?
[19:27] <infinity> Don't question it.
[19:29] <slangasek> cjwatson: because the GNOME3 default sleep policy is ridiculous - though fortunately we at least now have a setting to change the policy
[19:29] <cjwatson> 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] <slangasek> hmm
[19:30] <slangasek> perhaps the setting isn't wired up correctly then
[19:30] <cjwatson> I suppose it might be confused by apparently thinking I have two batteries
[19:31] <infinity> Do you?
[19:32] <cjwatson> No
[19:32] <stgraber> cjwatson: http://paste.ubuntu.com/701188/
[19:33] <stgraber> I gave up trying to do it through the UI last time...
[19:33] <cjwatson> stgraber: ah, thanks!
[19:33] <cjwatson> I'm sure this won't bother any of our users at all
[19:34] <cjwatson> err.
[19:35] <slangasek> 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] <slangasek> I have these settings here:
[19:35] <slangasek> org.gnome.settings-daemon.plugins.power sleep-inactive-ac false
[19:35] <slangasek> org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 1800
[19:35] <slangasek> org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
[19:37] <infinity> Does the UI not touch all the settings that stgraber pastebinned?
[19:37] <infinity> If it's exposing them but not actually setting them, that's unpleasant.
[19:38] <cjwatson> 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] <cjwatson> 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] <stgraber> 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] <infinity> Grand.
[19:40] <infinity> Perhaps we should be testing that control panel with some vigor on upgraded and fresh systems?
[19:40] <slangasek> infinity: dunno, I haven't tested, I already set it by hand before the GUI existed
[19:40] <stgraber> 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] <infinity> Surprising suspend behaviour is one of the nastier user experiences. :/
[19:41] <cjwatson> 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] <cjwatson> bug 864479
[19:41] <ubot4> 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] <cjwatson> shall I crank the priority on that and milestone it?
[19:42] <slangasek> IMHO yes
[19:42] <slangasek> (though probably -updates material at this point?){
[19:42] <cjwatson> depends how big a change it is?
[19:43] <slangasek> I'd like to see the schema fixed as well to give a sensible default policy on AC :P
[19:44] <cjwatson> that would be a separate bug I think ...
[19:44] <cjwatson> (though I agree)
[19:44] <infinity> slangasek / cjwatson: Can I get one of you to review 'bzr diff /home/adconrad/debian-cd/' on antimony?
[19:46] <infinity> Should fix the short image bugs I was seeing.
[19:46] <cjwatson> um, well, the code's OK, I really can't vouch for accuracy of what it's intended to do ...
[19:46] <infinity> And then I can get back to fixing jasper. :P
[19:46] <infinity> cjwatson: The problem, in both cases, was that no one was accounting for the "reserved blocks" before the boot/ext partitions.
[19:47] <infinity> cjwatson: On mx5, that's 1 sector, on omap, that's one track (32 sectors).
[19:47] <infinity> Represented by these two errors:
[19:48] <infinity> [164532.491847] EXT4-fs (sdb3): bad geometry: block count 1580032 exceeds size of device (1580031 blocks)
[19:48] <infinity> [145254.594400] EXT4-fs (sdb2): bad geometry: block count 1505280 exceeds size of device (1505264 blocks)
[19:48] <infinity> (Note those are in 1k blocks, not 512 byte, hence the count being a bit confusing)
[19:49] <infinity> That is EXT4 is whining in 1k blocks, but the debian-cd code is in 512 byte sectors.
[19:50] <stgraber> 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] <cjwatson> infinity: seems plausible, then
[19:51] <infinity> cjwatson: I can live with plausible.
[19:51] <cjwatson> stgraber: sleep-inactive-battery was set to false for me, so I don't think that's my problem
[19:52] <slangasek> stgraber: but is sleep-inactive-{ac,battery} even the right key, or does it need sleep-inactive-{ac,battery}-type?
[19:52] <infinity> 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] <cjwatson> stgraber: (well, -ac)
[19:52] <cjwatson> 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] <infinity> ... and maybe I'll try on another computer. :P
[19:54] <stgraber> 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] <cjwatson> infinity: I think it might actually give you a usage message by coincidence
[19:55] <cjwatson> looking at the code
[19:55] <stgraber> 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] <cjwatson> stgraber: well, -type is what your paste changes
[19:55] <cjwatson> stgraber: I guess I'll find out after the next time I come back to my laptop
[19:56] <infinity> cjwatson: It did, yes.  Not a terribly helpful one.
[19:56]  * infinity goes to look at the code instead.
[19:57] <stgraber> ok, grabbing gnome-settings-daemon's code then as gnome-control-center seems to do what it's supposed to
[20:15] <cjwatson> bug 864787 - d'oh
[20:15] <ubot4> 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] <cjwatson> will fix tomorrow
[22:23] <infinity> slangasek / ScottK / anyone: Around for a quick review of jasper-initramfs for me?
[22:23] <infinity> Maybe I should have asked that when we weren't horribly netsplit. :P
[22:24] <infinity> slangasek / ScottK / anyone: Around for a quick review of jasper-initramfs for me?
[22:26] <infinity> cjwatson: Or you, if you're not asleep or otherwise occupied? :)
[22:30] <infinity> 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] <slangasek> infinity: 'service cron stop' during the install maybe?
[22:41] <infinity> slangasek: Maybe.  Would be nice to avoid it for some undetermined amount of time post-install too, though.
[22:41] <infinity> If your very first user experience is "everything is slow", it kinda sucks.
[22:42] <infinity> I assume it's anacron going "holy crap, we haven't booted in FOREVER" and just firing everything.
[22:42] <slangasek> hmm
[22:44] <slangasek> 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] <infinity> See -devel too.
[22:45] <infinity> But yeah, I don't think a universal defer is sane.
[22:45] <infinity> And I think that if you happen to install at 4am, or whenever daily is MEANT to happen, sucks to be you.
[22:45] <infinity> But anacron running daily unconditionally after install is broken.
[22:46] <infinity> Or during install, even.
[22:47] <infinity> oem-config-remove-gtk timed out a dbus call due to apt-xapian.  Oh dear.
[22:47] <infinity> So, part of the problem here is installing a desktop OS to an SD card on a cell phone.
[22:48] <infinity> But still, this can't be pleasant on desktop hardware either, just less awful.
[22:48] <Laney> Don't we run under {,io}nice?
[22:49] <infinity> We, being.. The installer?
[22:49] <infinity> Niced up or down?
[22:49] <Laney> Jobs spawned from anacron. Niced to be ... nice
[22:49] <infinity> Oh, yes.
[22:49] <infinity> Generally.
[22:50] <infinity> But on slow systems, now amount of nice can fix this sort of thing.
[22:50] <infinity> s/now/no/
[22:51] <stgraber> "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] <infinity> It's really not.
[22:52] <Laney> I guess, yeah.
[22:52] <infinity> update-apt-xapian-index is vicious.
[22:52] <infinity> It brings some of my laptops and netbooks with real hard drives to their knees.
[22:52] <infinity> On SD, it's... Well... Hahaha is the only real description.
[22:53] <infinity> And part of that is mvo needing to profile the heck out of it, and he knows.
[22:53] <infinity> 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] <stgraber> infinity: touching /var/lib/apt/periodic/update-stamp should be enough to delay it for a while
[22:54] <infinity> stgraber: That would solve the update-apt-xapian-index one, I guess?
[22:54] <infinity> stgraber: Which is the big one for now.
[22:54] <Laney> Still, having it delayed just long enough for you to get down to some real work also sucks.
[22:54] <infinity> (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] <stgraber> yep, that's the one being checked just before calling update-apt-xapian-index
[22:55] <Laney> you can probably touch /var/spool/anacron/cron.daily
[22:56] <infinity> 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] <infinity> Thanks for the ideas and digging.
[22:57] <stgraber> 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] <infinity> Might need to happen earlier than that for the oem-config case.
[22:59] <infinity> What's the default delay for cron.daily?
[22:59] <Laney> 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] <infinity> It'll fire 5 minutes after boot.
[23:00] <infinity> Yeah.  Maybe I'll just hack around it in jasper for ARM for now.
[23:01] <infinity> And revisit it in ubiquity later, when I can generalise an oem-config/live-install solution that works for both.
[23:01] <infinity> (Well, okay, I guess it's just touching it early if oem-config mode, and later if not, but whatever)
[23:01] <infinity> I have gin and tonic calling me.  Beckoning, even.