| ScottK | cjwatson: Particularly for things like the installer I think there is zero reason to be concerned about supporting python < 2.7. | 00:58 |
|---|---|---|
| === micahg_ is now known as micahg | ||
| === tkamppeter_ is now known as tkamppeter | ||
| 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:11 |
| infinity | cjwatson: Quite. | 13:13 |
| infinity | cjwatson: I'm curious why 'locale -a' returns *.utf8 rather than *.UTF-8, though. | 13:15 |
| infinity | cjwatson: Given that we use the other naming nearly universally, wouldn't we want that tool to output the same format? | 13:16 |
| cjwatson | s'always been like that ... | 13:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| infinity | Just confuses me a tad that it's not trusting PAM's return and just going with it. | 13:21 |
| infinity | So, entirely off-topic, but does anyone know off-hand if 'mount -o remount,ro /foo' forces a sync? | 13:22 |
| 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:11 |
| 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. | 15:12 |
| slangasek | nvidia-graphics-drivers - hurrah | 17:57 |
| infinity | Those aren't words oft-uttered. | 18:00 |
| slangasek | dude, console-setup, what's the deal | 18:02 |
| slangasek | why does your build make my laptop overheat | 18:03 |
| slangasek | yes, my ACPI tables are screwed up, but why is *console-setup* running hotter than running gcc? :P | 18:04 |
| 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:09 |
| 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:11 |
| slangasek | what "power management setting" do you mean? | 18:12 |
| 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:13 |
| slangasek | only disengaged/full-speed actually pushes any air :P | 18:14 |
| slangasek | (and thinkfan doesn't support specifying full-speed :P) | 18:14 |
| 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:16 |
| slangasek | apparently it's ckbcomp that chews the CPU up. Really efficient, or really inefficient? | 18:31 |
| 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:39 |
| 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:55 |
| slangasek | oh, doh, no it doesn't | 18:57 |
| slangasek | it just looked like it did because plymouth was being helpful :P | 18:57 |
| slangasek | ah right, because totextmode didn't actually get copied to the initramfs | 19:05 |
| cjwatson | slangasek: I tried to optimise ckbcomp earlier in the cycle, but ran out of time ... | 19:26 |
| 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:27 |
| 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:29 |
| 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:30 |
| infinity | Do you? | 19:31 |
| cjwatson | No | 19:32 |
| stgraber | cjwatson: http://paste.ubuntu.com/701188/ | 19:32 |
| 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:33 |
| cjwatson | err. | 19:34 |
| 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:35 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| slangasek | I'd like to see the schema fixed as well to give a sensible default policy on AC :P | 19:43 |
| 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:44 |
| 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:46 |
| 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:47 |
| 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:48 |
| infinity | That is EXT4 is whining in 1k blocks, but the debian-cd code is in 512 byte sectors. | 19:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| * 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:53 |
| 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:54 |
| 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:55 |
| infinity | cjwatson: It did, yes. Not a terribly helpful one. | 19:56 |
| * infinity goes to look at the code instead. | 19:56 | |
| stgraber | ok, grabbing gnome-settings-daemon's code then as gnome-control-center seems to do what it's supposed to | 19:57 |
| 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 | 20:15 |
| 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:23 |
| infinity | slangasek / ScottK / anyone: Around for a quick review of jasper-initramfs for me? | 22:24 |
| infinity | cjwatson: Or you, if you're not asleep or otherwise occupied? :) | 22:26 |
| 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:30 |
| slangasek | infinity: 'service cron stop' during the install maybe? | 22:40 |
| 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:41 |
| infinity | I assume it's anacron going "holy crap, we haven't booted in FOREVER" and just firing everything. | 22:42 |
| slangasek | hmm | 22:42 |
| 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:44 |
| 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:45 |
| infinity | Or during install, even. | 22:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| infinity | But on slow systems, now amount of nice can fix this sort of thing. | 22:50 |
| infinity | s/now/no/ | 22:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| Laney | you can probably touch /var/spool/anacron/cron.daily | 22:55 |
| 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:56 |
| 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:57 |
| infinity | Might need to happen earlier than that for the oem-config case. | 22:58 |
| 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 | 22:59 | |
| 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:00 |
| 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. | 23:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!