[00:00] <sconklin> cjwatson: thanks. So since we'd like to deliver a small change to pm-utils with jaunty in order to support reporting of suspend/resume failures, what's the best way to do that? Sorry, I'm just venturing into ubuntu userspace . . .
[00:00] <cjwatson> StevenK: remember that the same BuildLiveCD code is used to support older distributions too. I rather suggest that you leave the old names around
[00:01] <StevenK> cjwatson: And remove support from livecd.sh ?
[00:01] <cjwatson> sconklin: file a bug on https://bugs.launchpad.net/ubuntu/+source/pm-utils/+filebug, attach patch
[00:01] <cjwatson> sconklin: and hunt around early next week for somebody to upload it
[00:01] <sconklin> haha, ok. thanks
[00:02] <cjwatson> StevenK: livecd.sh lives in the release-specific chroot so doesn't matter so much
[00:02] <cjwatson> StevenK: rest looks fine
[00:02] <cjwatson> StevenK: BTW, please commit the substantive changes separately from the UNRELEASED -> jaunty bit
[00:02] <sconklin> time to put food on my family . . .
[00:03] <StevenK> cjwatson: Hmm. Why?
[00:03] <cjwatson> StevenK: it generally produces a more readable log if you go "commit change, commit change, commit change, dch -r, debcommit -r"
[00:03] <sconklin> sorry, that's a regional joke
[00:03] <cjwatson> so it's easy to see in 'bzr log' where the upload points were
[00:04] <sconklin> George W Bush once said "You're working hard to put food on your family"
[00:04] <directhex> sconklin, the greatest president said many inspired things
[00:05] <sconklin> maybe so, but GWB said that last one
[00:33] <ArneGoetje> slangasek: hardy translations export has been finished a few minutes ago. Import into langpack-o-matic is running. ETA in 3.5h.
[00:49] <ArneGoetje> cjwatson: ^
[01:16] <BenB> drescher.canonical.com broken: http://pastebin.ca/1304823 - who to contact?
[01:18] <crimsun> doesn't seem broken, just takes a bit to respond
[01:18] <BenB> no, it never responds...
[01:19] <BenB> nevermind, though... it works from another network, so it's local horkage, sorry.
[01:20] <BenB> yes, my stupid DSL router resetted the MTU.
[03:58] <ArneGoetje> slangasek, cjwatson: uploading hardy base language-packs to hardy-proposed.
[07:40] <slangasek> ArneGoetje: ah, huzzah!
[07:46] <slangasek> ArneGoetje, cjwatson: langpacks accepted
[12:23] <LordMetroid> Where should I file a bug report that you can not rename files from example foo to Foo in nautilis?
[12:50] <Adri2000> LordMetroid: bugs.launchpad.net/ubuntu/+source/nautilus
[12:51] <Adri2000> LordMetroid: on what kind of partition do you have this problem?
[12:51] <LordMetroid> ext3 I think it is running
[12:51] <LordMetroid> You mean you do not have this problem?
[12:51] <Hobbsee> nope
[12:51] <LordMetroid> I thought it would be an universal occurence
[12:52] <Hobbsee> do the files show up with locks next to them?
[12:52] <LordMetroid> no
[12:52] <LordMetroid> they are like normal
[12:52]  * Adri2000 has the problem with fat32 partitions
[12:52] <LordMetroid> It is just that it says that the file already exists if I try to change the capitalization of the name
[12:52] <Adri2000> but I think it's not a bug, it's just because fat32 is not case-sensitive
[12:52] <Hobbsee> LordMetroid: well, does it?
[12:52] <Hobbsee> a Foo?
[12:53] <LordMetroid> Ahh, I see it does that on Fat32
[12:53] <LordMetroid> The usb memorystcik must be fat32
[12:54] <StevenK> fat32 filesystems are case-insensitive
[12:54] <Hobbsee> ah
[12:55] <Adri2000> so mv test TEST doesn't work. but mv test test2 and mv test2 TEST works
[12:56] <LordMetroid> StevenK, should be possible to code a hack for this
[12:58] <LordMetroid> Bug filed, https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/315782 hopefully in the future one can change capitalization on files, making renaming files more intuitive
[12:59] <LordMetroid> That was a neat bot
[13:05] <cjwatson> Adri2000: while FAT32 isn't case-sensitive, it is case-preserving, and therefore this is a bug
[13:11] <Adri2000> ok. if it's a bug then mv is affected as well
[13:12] <theunixgeek> It's success story time! I got a friend to switch her office computer over to Ubuntu. I spent about 7 minutes setting it up to have a more familiar Windows-like look with only one panel, with only the relevant applications in the application menu. Now, she's loving it! Switching over from Vista, she says the interface looks much brighter, cleaner, and easier to use! Thank you, developers! :D
[13:12] <theunixgeek> and she finds it to be more stable as well
[13:15] <LordMetroid> Yeah, I am seriously wishing to use Ubuntu for on my dekstop as well... But then I will have problems with games that I wish to run
[13:15] <theunixgeek> LordMetroid: dual boot? :)
[13:16] <LordMetroid> Adding dual boot want solve the problem, then I would need to reboot too much and I would just boot into windows cause I know I am going to play games
[13:18] <theunixgeek> I see :(
[13:19] <theunixgeek> well, good luck :)
[13:20] <LordMetroid> Indeed, it suck but little one can do about the gaming industry
[13:24] <theunixgeek> LordMetroid: what country are you from?
[13:24] <LordMetroid> Sweden
[13:24] <LordMetroid> Why?
[13:24] <theunixgeek> cool. I've been looking into Swedish for a while :)
[13:24] <LordMetroid> Really, that not something I had expected someone to do
[13:24] <theunixgeek> I just noticed some different word order, so I knew you were neither American nor British
[13:25] <theunixgeek> why not? it's a cool language :)
[13:25] <theunixgeek> besides, it's Germanic, so it'll be relatively easy to learn
[13:26] <LordMetroid> Yes, indeed... the words will come easy the grammar I hear is relatively complex but that shouldn't deterr you, once you know Swedish you can also communicate, read and understand danish and norweigan and to a certain extent icelandic
[13:26] <theunixgeek> Jag gillar svenska :)
[13:26] <LordMetroid> and to a certain extent german
[13:26] <theunixgeek> I've been studying German for a few weeks now, and I noticed I can understand some Swedish text already
[13:27] <theunixgeek> I feel like learning Swedish for that reason: it's like just the right stepping stone to Danish and Norwegian
[13:27] <theunixgeek> I'm averting Norwegian for a while due to the bokmål/nynorsk mix
[13:28] <theunixgeek> for pronunciation, I'm using an online text-to-speech app to hear how to pronounce the words, as well as to practice my listening comprehension (copy/pasting text :P)
[13:29] <LordMetroid> Sounds cool
[13:29] <LordMetroid> regarding the bug reports what does "triage" mean?
[13:30] <theunixgeek> 中国大陆送给台湾的两个友谊熊猫"团团"和"圆圆"顺利抵达了台湾。
[13:30] <theunixgeek> whoops sorry. pasted in wrong chat :X
[13:30] <theunixgeek> sorry
[13:30] <LordMetroid> np
[14:50] <ArneGoetje> slangasek: what about the langpacks in the New queue?
[14:57] <Keybuk> soren: I'm reverse-thinking here
[14:57] <Keybuk> we should probably just copy of all of /etc/udev/rules.d into the initramfs
[14:58] <Keybuk> though that might break things since we don't copy hardly any of /lib/udev/rules.d
[14:59] <Keybuk> or
[14:59] <Keybuk> copy anything not in /lib/udev/rules.d
[14:59] <Keybuk> and copy anything in /lib/udev/rules.d *if* it has been copied into the initramfs
[15:38] <Tenkawa> anyone know offhand why between config-2.6.28-3-generic and config-2.6.28-4-generic of the kernel IPV6 went from module to being compiled in?
[15:39] <Keybuk> Tenkawa: many things have gone from modules to being compiled in
[15:40] <Tenkawa> bummer
[15:40] <Tenkawa> oh well..
[15:40] <cjwatson> ipv6 seems like a slightly dubious choice for that given the historical problems
[15:40] <Tenkawa> cjwatson: agreed
[15:40] <Tenkawa> it still has "hiccups"
[15:40] <Mithrandir> cjwatson: we should have worked around that for just about all users now, though.
[15:40] <cjwatson> I think you should file a bug on /ubuntu/+source/linux with details (if there isn't already one)
[15:41] <cjwatson> Mithrandir: I'm assuming that the fact that Tenkawa is showing up here about it means we haven't
[15:41] <Tenkawa> yep
[15:41] <Keybuk> this sounds like a case of allowing users not to file bugs so we don't find out about the real problems
[15:41] <Tenkawa> no way to turn it completely off
[15:41] <Keybuk> Bug: please let me disable IPv6 is wrong
[15:41] <Keybuk> Bug: ipv6 is broken for me *because* is right
[15:41] <Tenkawa> yeah its not a bug
[15:41] <cjwatson> one problem here is that some of the problems aren't ours
[15:42] <Tenkawa> its a preference
[15:42] <Mithrandir> Tenkawa: are you actually using ipv6 for anything or do you want to turn it off?  What are the symptoms you are getting?
[15:42] <cjwatson> we've had historical problems with idiotic routers
[15:42] <Tenkawa> but there should still be a choice
[15:42] <Tenkawa> Mithrandir: no.. I just wanted to disable it completely
[15:42] <Tenkawa> Mithrandir: just odd that it got switched to being forced
[15:43] <Mithrandir> cjwatson: yes, and glibc now doesn't send out AAAA queries unless you have an address with scope >= site defined (and haven't for a while).  (As I think you know)
[15:43] <cjwatson> (that said I agree with Keybuk, please file a bug about the breakage you're encountering with ipv6 turned on so that we can fix that properly)
[15:43] <cjwatson> Mithrandir: *nod*
[15:43] <Tenkawa> no more aliases trick... hehehe
[15:43] <Keybuk> Tenkawa: the aliases trick is likely to stop working soon anyway
[15:43] <Keybuk> (sorry)
[15:43] <Keybuk> (for any module)
[15:43] <cjwatson> aliases trick?
[15:43] <Tenkawa> oh really?
[15:44] <Tenkawa> darn
[15:44] <Tenkawa> that was fun
[15:44] <cjwatson> oh, alias ipv6 off?
[15:44] <Tenkawa> y
[15:44] <Tenkawa> a
[15:44] <Keybuk> cjwatson: an ancient method of stopping the kernel being able to load ipv6 when it wants
[15:44] <Tenkawa> yep
[15:45] <Mithrandir> Tenkawa: from what I understand, you don't have any problems with it, you just want to disable it because you prefer it not to be loaded?
[15:45] <Tenkawa> correct
[15:46] <Tenkawa> the modular way seems more flexible
[15:46] <Mithrandir> *shrug*; it's effectively disabled unless you configure ipv6 addresses, so the end result should be just about the same.
[15:46] <Tenkawa> Its nothing to rebuild the kernel for me... was just trying to determine if this was intended
[15:46] <Mithrandir> which is a fair question, agreed.
[15:46] <Tenkawa> Mithrandir: no.. once the device comes up it does assign a link local address
[15:47] <Tenkawa> although it "should" do nothing... it still responds to other api calls for ipv6 functionality
[15:47] <Mithrandir> Tenkawa: correct.  Link-local addresses don't cause glibc to do lookups for ipv6 names.
[15:47] <Tenkawa> possibly confusing other apps
[15:47] <Mithrandir> so unless you do telnet $ipv6_address or some such, it won't actually use ipv6.
[15:47] <Keybuk> do you have an example of an app confused by an ip6 link local address?
[15:47] <Tenkawa> but apps that use apis checking for ipv6 capabilities "could" be affected
[15:48] <Tenkawa> iceweasel I believe is one someone mentioned to me
[15:48] <Tenkawa> it can be turned off but is a manual process
[15:48] <Mithrandir> hmm, people reported to me that the glibc patch fixed that, but this was a couple of years ago, so iceweasel might be doing something different today.
[15:48] <Tenkawa> like I said.. no big deal.. just curious
[15:49] <Tenkawa> its a hobby/test box anyway... hehehe
[15:49] <Tenkawa> thanks for the info though... be back later...
[15:50] <Keybuk> I'm often surprised that my ISP don't do IPv6 yet
[15:51] <Keybuk> Be seem to be staffed by the kind of techies who'd do it just because
[15:51] <Keybuk> probably stuck by the fact the routers don't do it or something
[15:51] <Keybuk> cjwatson: thought for the day http://lwn.net/Articles/313838/
[15:58] <broonie> Keybuk: There are amusing issues with the BT network, I believe.
[15:59] <Keybuk> broonie: the BT network doesn't apply in this case
[15:59] <Keybuk> it's an LLU
[16:02] <cjwatson> Keybuk: ah, so it sounds like Tenkawa didn't really have an issue then
[16:02] <cjwatson> OK, less concerned :-) (I mean not a concrete, demonstrable issue)
[16:05] <slytherin> has anyone else seen a problem on jaunty with permissions for dvd drive node. In my case the permissions (for /dev/hdc) are brw-rw----+. mplayer complains that it can not open dvd device.
[16:06] <Keybuk> slytherin: err
[16:06] <Keybuk> can you do ls -l /dev/hdc
[16:06] <Keybuk> and getfacl /dev/hdc
[16:06] <Keybuk> (and how the hell is it hdc and not sdc? :p)
[16:06] <slytherin> Keybuk: ls -l output - brw-rw----+ 1 root disk 22, 0 2009-01-10 18:49 /dev/hdc
[16:07] <Keybuk> I mean of course sr0
[16:07] <Keybuk> ok
[16:07] <slytherin> Keybuk: getfact output - getfacl: Removing leading '/' from absolute path names
[16:07] <slytherin> # file: dev/hdc
[16:07] <slytherin> # owner: root
[16:07] <slytherin> # group: disk
[16:07] <slytherin> user::rw-
[16:07] <slytherin> group::rw-
[16:07] <slytherin> mask::rw-
[16:07] <slytherin> other::---
[16:07] <cjwatson> Keybuk: yeah, I noticed Uli mentioning that on his LJ too
[16:07] <Keybuk> cjwatson: which?
[16:08] <cjwatson> Keybuk: the setcap on ping thing
[16:08] <Keybuk> slytherin: cat /sys/block/hdc/media
[16:08] <cjwatson> Keybuk: do you know if it needs any particular install-time mkfs options?
[16:08] <Keybuk> cjwatson: I don't think so
[16:08] <cjwatson> we could do it without any dpkg extensions - it'd just need maintainer script hacking
[16:08] <slytherin> Keybuk: there is no such file
[16:08] <Keybuk> slytherin: ?!
[16:08] <Keybuk> slytherin: uname -a
[16:09] <slytherin> Keybuk: wait, there is /sys/block/hdc/device/media, the output is cdrom.
[16:09] <Keybuk> oh, sorry
[16:09] <Keybuk> right
[16:09] <slytherin> Keybuk: uname -a - Linux iBook 2.6.27-1-powerpc #1 Fri Nov 7 00:30:26 UTC 2008 ppc GNU/Linux
[16:09] <Keybuk> slytherin: udevadm test /block/hdc | pastebin
[16:11] <slytherin> Keybuk: not able to redirect the output to a file.
[16:11] <Keybuk> slytherin: ?
[16:12] <Keybuk> udevadm test /block/hdc > somefile.txt 2>&1
[16:12] <Keybuk> hahaha
[16:12] <Keybuk> bwahahaha
[16:12]  * Keybuk spots the problem
[16:13] <Keybuk> SUBSYSTEM=="block", KERNEL=="hd[0-9]*", SUBSYSTEMS=="ide", ATTRS{media}=="cdrom", GROUP="cdrom"
[16:13] <Keybuk>                                ~~~~~~
[16:13] <cjwatson> deliberate mistake, right/
[16:13] <cjwatson> ?
[16:14] <Keybuk> I suspect it's a case of nobody's used hd* in so long, it was forgotten they weren't numbered ;)
[16:14] <slytherin> Keybuk: http://paste.ubuntu.com/103181/
[16:15] <Keybuk> yeah
[16:15] <Keybuk> that confirms it
[16:15] <Keybuk> udev_rules_apply_to_event: GROUP 6 /lib/udev/rules.d/50-udev-default.rules:62
[16:16] <Keybuk> the later GROUP assignment isn't being used
[16:16] <Keybuk> slytherin: if you just do chgrp /dev/hdc cdrom
[16:16] <Keybuk> does mplayer work then?
[16:16] <slytherin> let me check
[16:18] <slytherin> Keybuk: it doesn't give me any error anymore. And now it is reading the stream information from DVD.
[16:18] <Keybuk> sweetness
[16:23] <slytherin> Keybuk: so should i file a bug for this?
[16:25] <Keybuk> slytherin: I've already mailed udev upstream
[16:25] <Keybuk> but a bug on udev would be welcome
[16:25] <Keybuk> (so I don't forget to hassle/chase/etc.)
[16:26] <slytherin> Ok. I will file a bug.
[16:28] <slytherin> Now another completely unrelated problem. I am getting stuttering sound when playing songs or movies. It is very irritating. I am not able to figure out what the problem is. Can it be some buffer overrun?
[16:57] <Keybuk> slytherin: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=18cff5c3b2e3591fa46107288ea2d7026a15ccf3
[17:16] <sbeattie> cjwatson|keybuk: actually, apparmor has the (little-known little-used) ability to grant posix capabilities, which would let one remove the setuid bit on ping by writing the apparmor policy and granting within it cap_net_raw.
[17:18] <cjwatson> sbeattie: true; though that'd introduce a reliance on apparmor for functionality as well as for security, which is a significant step
[17:18] <Keybuk> sbeattie: why is that better than using xattr?
[17:20] <sbeattie> Keybuk: does the deb packaging format include xattrs?
[17:20] <kees> why do we want to drop the setuid bit on ping?
[17:20] <Keybuk> it includes maintainer scripts
[17:21] <kees> (xattr and aa both impose greater limitations than just leaving the setuid bit)
[17:21] <Keybuk> kees: I'd've thought you'd be in favour of dropping setuid everywhere it's not needed? :p
[17:21] <kees> Keybuk: I'm in favor of it when it's used irresponsibly.  ping (and most of the other setuids) just give themselves a CAP and drop privs
[17:21] <Keybuk> kees: the suggestion is that you just give them the CAP on the filesystem, so they don't even need to do that
[17:22] <kees> I mean, I'm in favor of xattrs in general, but it'd mean we could no longer support any filesystems that didn't support xattrs
[17:22]  * Keybuk waits for the downside :p
[17:22] <kees> yeah, me too.
[17:23] <kees> I'm a fan of it, but I just wanted to play devil's advocate for a second
[17:23] <kees> fscaps are in the kernel now (added for hardy, I think)
[17:23] <Keybuk> right
[17:24] <Keybuk> not that we really make any effort to support filesystems other than extN anyway
[17:24] <cjwatson> we don't? (I get bugs about them and fix them, generally ...)
[17:24] <Keybuk> all we tend to do for people who report lost data with XFS is not laugh at them in their face
[17:25] <Keybuk> cjwatson: I suspect we're using different meanings of the term "support" ?
[17:25] <cjwatson> which filesystems that are supported for installation (which a user could be forgiven for mistaking for "supported") don't support xattr, anyway?
[17:25] <kees> well, what about the boot-inside-windows thingy?
[17:25] <cjwatson> Keybuk: yeah, you sound like you're saying "I don't want to support anything other than extN", which is slightly different ;-) (though I acknowledge the way XFS and apt are not friends)
[17:25] <kees> cjwatson: that's probably the right question. :)
[17:25] <jdong> isn't the boot-inside-windows thing a fancy loopback image of a standard Linux FS?
[17:25] <cjwatson> yes, it is
[17:25] <cjwatson> ext3 loop on ntfs-3g
[17:26] <cjwatson> except for /boot which is directly on ntfs-3g
[17:26] <kees> I think /boot isn't, though -- which has caused problems (like, for symlinks) in the past.  ?
[17:26] <cjwatson> in the context of this discussion that's irrelevant, though
[17:26] <kees> but we don't need fscaps there :)
[17:26] <kees> also, this would be a delta from debian -- not strictly bad, just pointing it out
[17:27] <cjwatson> I think it'd be pretty reasonable to do it for ping in maintainer scripts, and see what follows - unless there's a filesystem commonly used for / or /usr that doesn't support xattrs
[17:28] <jdong> JFS does xattrs right?
[17:29] <Keybuk> cjwatson: that is what I'm saying :p
[17:29] <Keybuk> I was thinking of the way that dpkg and XFS weren't friends
[17:30] <jdong> oh they only aren't friends if you crash the system at the right time ;-)
[17:30] <cjwatson> the installer permits any of ext2, ext3, ext4 [jaunty], reiserfs, jfs, xfs as /
[17:30] <Keybuk> we still permit reiserfs? :p
[17:30] <cjwatson> yes
[17:31] <Keybuk> it's kiiinda unmaintained now, no?
[17:31]  * Keybuk hasn't seen anyone step forward for it
[17:31] <jdong> is there still that one guy from Novell?
[17:31] <cjwatson> I have no information
[17:31] <cjwatson> and I am not interested in creating more grief for myself by removing it
[17:31] <Keybuk> the people who used to be excited about it seemed to have redirected their efforts to btrfs
[17:31] <jdong> last I heard novell is having one guy manage reiserfs for bugfixes primarily for their SLES products still supported
[17:33] <cjwatson> anyway, as far as I can tell, all of the above filesystems have some level of xattr support (i.e. a file matching *xattr* in fs/foo/ ...)
[17:33] <cjwatson> so the discussion, while diverting, is probably not relevant to whether we can rely on xattr :-)
[17:33] <kees> sweet.  let's do it!  :)
[17:34] <cjwatson> that said I do not know whether any of those filesystems need mkfs/mount options to enable xattr
[17:34] <cjwatson> I know they have user_xattr mount options, but that's only for the user.* namespace isn't it?
[17:34] <Keybuk> according to mount(8)
[17:35] <cjwatson> mount(8) says different things for different filesystems, so I wanted to check that the option with the same name actually means the same thing for different filesystems
[17:35] <elmo> err, how on earth are you planning to handle upgrades?
[17:35] <Keybuk> xfs has attr2/noattr2
[17:35] <Keybuk> but that seems to only refer to the format of xattr on disk
[17:35] <kees> cjwatson: I tried playing with user_xattr on the bus from google, and I got mixed results.
[17:36] <Keybuk> elmo: is there some special handling that needs to be done?
[17:36] <kees> Keybuk: potentially adding mount options
[17:36] <Keybuk> oh, right
[17:36] <Keybuk> but we were just vaguely concluding there were no relevant mount options
[17:36] <Keybuk> besides, we've added mount options during upgrade before :p
[17:37] <cjwatson> elmo: what's the upgrade problem? it looks like all filesystems already permit extended system attributes (which is where this would live) and it would be a matter of disabling the setuid bit and running setxattr or whatever it is in the postinst
[17:37] <elmo> oh, I assumed it required user_xattr
[17:37] <cjwatson> obviously we would have to check the first assertion there properly
[17:37] <cjwatson> I don't think it does
[17:37] <elmo> (which has eaten my disk several times, so it makes me squirm when people talk about relying on it)
[17:39] <cjwatson> sorry, setcap not setxattr
[17:40] <Keybuk> no user_xattr required
[17:40] <Keybuk> according to http://www.friedhoff.org/posixfilecaps.html
[17:40] <Keybuk> there do seem to be other patches required
[17:40] <Keybuk> cp and mv need patching to copy the attributes
[17:41] <cjwatson> http://www.friedhoff.org/posixfilecaps.html does suggest that if we did that then ping would stop working in systems running dapper kernels
[17:42] <cjwatson> (yes yes pace Keybuk I know udev won't work)
[17:42] <Keybuk> likewise tar, rsync, etc;
[17:42] <Keybuk> cjwatson: I was more thinking that Upstart wouldn't work <g>
[17:42] <cjwatson> neither upstart nor udev is necessary in a chroot
[17:42] <cjwatson> at least it doesn't matter whether they really work, even if they happen to be installed
[17:43] <kees> Keybuk: are those patches not already upstream?  I think a mess of that was done already since selinux support needed it too?
[17:43] <cjwatson> ping in a chroot is the sort of thing you might well be a bit surprised about breaking though
[17:43] <cjwatson> and definitely tar
[17:43] <Keybuk> kees: the doc is old, the patches could very well be applied now that fscaps has gone kernel upstream
[17:44] <Keybuk> cjwatson raises very interesting questions here
[17:44] <Keybuk> do we have to limit ourselves to only using kernel features in our oldest supported LTS?
[17:45] <cjwatson> slangasek and I had this debate a little while ago regarding glibc
[17:45] <elmo> this seems like a lot of work given the current model is to give itself caps and drop privs
[17:45] <Keybuk> because we would want to support them running a modern chroot under that LTS
[17:45] <cjwatson> slangasek reckoned we did, and made glibc only require 2.6.15 for that reason
[17:45] <Keybuk> cjwatson: glibc has requirements?
[17:45] <cjwatson> it is my belief that modern chroots under LTS kernel basically work
[17:45] <cjwatson> Keybuk: yes
[17:45] <Keybuk> what changes if you up the requirement?
[17:46] <cjwatson> it uses new syscalls
[17:46] <cjwatson> and drops fallback support
[17:46] <elmo> cjwatson: we know they do; our powerpc boxes are still (and have to) run dapper
[17:46] <Keybuk> but if the requirement is lower, but you *have* the new kernel, does it use the new syscall or still the old one?
[17:46] <cjwatson> I *think* it uses the new one but you'd have to check
[17:46] <Keybuk> do you have a syscall example?
[17:46] <cjwatson> I suspect that may vary between features
[17:46] <Keybuk> (I'm guessing it's something like pselect or ppoll)
[17:47] <cjwatson> pselect is one such yes
[17:47] <cjwatson> there's a header file somewhere with a nice summary
[17:48] <cjwatson> glibc/sysdeps/unix/sysv/linux/kernel-features.h
[17:48]  * Keybuk is waiting for bzr
[17:48] <cjwatson> I think that glibc's bzr is debian/-only :-(
[17:50] <Keybuk> oh, I see
[17:51] <Keybuk> __ASSUME_SOCK_CLOEXEC is kinda a cute example
[17:51] <Keybuk> if defined, it assumes it always exists
[17:51] <Keybuk> if not defined, it tries with it, then falls back to without
[17:52] <Keybuk> doesn't __LINUX_KERNEL_VERSION come from the linux kernel headers themselves?
[17:52] <cjwatson> no in this case it's set by glibc/configure
[17:52] <cjwatson> I'm not certain that all the features follow the same model
[17:53] <Keybuk> some seem to change the behaviour of other bits
[17:53] <Keybuk> like __ASSUME_PACCEPT only changes nscd
[17:53] <cjwatson> debian/sysdeps/linux.mk:MIN_KERNEL_SUPPORTED := 2.6.15
[17:53] <cjwatson> is the ultimate source of this in our packaging
[17:54] <Keybuk> pselect() is really the one that interests me
[17:54] <Keybuk> since the glibc wrapper for it is an idiotic thing to have anyway
[17:54] <ebroder> I'm maintaining an apt repository for some site-specific configurations. Is there something I can hook in update-manager so that repo doesn't get disabled in sources.list when my users take a release upgrade?
[17:55] <Keybuk> I never understood what they were smoking to lead them to believe that having a glibc-implemented wrapper for that was a good idea
[17:55] <Keybuk> right, in the pselect() case, the fuck-stupid wrapper is used only if you get -ENOSYS
[17:57] <Keybuk> looks like it doesn't turn off anything that should be on ;)
[17:57] <Keybuk> the glibc guys are usually pretty awesome about such things anyway, but worth checking
[17:59] <Keybuk> hmm
[18:00] <Keybuk> cjwatson: so how strict do we need this policy to be?
[18:00] <cjwatson> can we talk about this on Monday? :-)
[18:00] <Keybuk> sure :p
[18:01]  * Keybuk figured that since you were online and chatting in the channel, you were trying to escape your home life rather than being distracted from it <g>
[18:01] <cjwatson> I'm interested, but too many other things to do ...
[18:01] <cjwatson> nah, I was around because I was trying to get my 3G modem to work :-), but now I have nappies to change and such
[18:02] <cjwatson> (and oh dear god this ZeroCD thing is AWFUL)
[18:02] <Keybuk> zeroCD?
[18:03] <cjwatson> some USB 3G modem manufacturers got the bright idea of embedding a flash drive into the device containing drivers
[18:03] <cjwatson> which would have been fine if they'd also added a USB hub so that both the mass-storage and the modem show up at once
[18:03] <Keybuk> right
[18:03] <Keybuk> I thought these were mostly handled in the kernel now?
[18:03] <cjwatson> but no - what happens on Windows is that the first time you plug in the device, it installs the driver, and subsequently the driver pokes the device to switch to modem mode
[18:04] <Keybuk> or has someone written a userspace hack for it, because they didn't realise the kernel has a quirks list about this?
[18:04] <cjwatson> what happens on Linux is that either the kernel's already arranged matters for you, or else you go through godawful userspace hacks
[18:04] <cjwatson> and what happened to me today was that I went down blind alleys of godawful userspace hacks, and then discovered that Dan Williams had sent a patch recently for nearly the same model which got merged
[18:04] <cjwatson> (kernel patch that is)
[18:05] <cjwatson> so I'm trying that out now. Weirdly, Alan Cox vehemently objected to that patch on lkml
[18:05] <Keybuk> Alan Cox seems to be objecting to a lot of patches atm

[18:06] <cjwatson> if it works with the obvious quirks addition over and above Dan's patch, I'll throw it lkml-wards. It just took me rather more time than I'm happy with to figure out that *that*'s where the five lines of code needed to go ...
[18:09] <cjwatson> the manufacturers are pushing some pile of dodgy udev rules
[18:09] <Keybuk> yeah
[18:09] <cjwatson> and object to the kernel defaulting to turning off ZeroCD on the grounds that they might want to put something shiny in there
[18:09] <Keybuk> iirc they eject the storage device, then poke in sysfs to power off and on the usb device again, thus it represents to the kernel
[18:10] <cjwatson> yeah, that kind of thing
[18:10] <Keybuk> yeah I saw that
[18:10] <Keybuk> the counter to that of course is that the Windows default is to turn it off once the driver is installed
[18:11] <cjwatson> indeed
[18:11] <Keybuk> Linux _comes_ with the driver ;-)
[18:11] <cjwatson> and *obviously* you get a 3G modem so that you can use it as a flash drive
[18:11] <cjwatson> err
[18:11] <Keybuk> you could do some insane things with jockey
[18:11] <Keybuk> first time they insert the device, it appears as a storage device so you can look at their PDFs or something
[18:11] <cjwatson> I think mine was read-only anyway and contained only Windows drivers
[18:11] <Keybuk> a bubble appears telling you to click jockey to turn it into a modem
[18:11] <Keybuk> then jockey turns it into a modem, and installs a udev rule to do it next time
[18:11] <cjwatson> ... or the modem could just work :;-)
[18:11] <Keybuk> but that's just insane
[18:11] <Keybuk> exactly
[18:11] <cjwatson> :-)
[18:12] <cjwatson> /usr/sbin/update-grub: line 333: /sbin/vol_id: No such file or directory
[18:12] <cjwatson> hmm, I thought you put a symlink in?
[18:12] <Keybuk> err, I thought I did
[18:14] <Keybuk> this may be a case of "Scott forgot to bzr add debian/udev.links"
[18:14] <cjwatson> I thought I saw it while NEWing it, but maybe that was only for udev-udeb
[18:15] <Keybuk> so it worked when I tested it, but bzr bd didn't copy it over
[18:15] <Keybuk> I think in the udeb, we just copy vol_id into sbin
[18:16] <cjwatson> I believe the installer generally does PATH=/lib/udev:$PATH vol_id, but wouldn't swear to that being the case everywhere
[18:16] <Keybuk> nope, it's missing in the udeb too
[18:17] <cjwatson> maybe you didn't build the one I NEWed with bzr bd?
[18:17] <Keybuk> maybe
[18:18] <Keybuk> was certainly having trouble
[18:18] <Keybuk> the -2 I did, so that could have lost the symlinks again
[18:22] <ebroder> Is there any way to do site-local hooks in update-manager?
[18:23] <cjwatson> ebroder: might want to ask during European working hours when mvo's around
[18:23] <ebroder> cjwatson: Ok, I can do that
[18:33] <ScriptRipper> I read: https://dev.launchpad.net/OpenSourcing
[18:36] <ScriptRipper> "We're open-sourcing the code that runs Launchpad.net. The process will be completed by 21 July 2009, coinciding with the 3.0 release (see the schedule of releases)."
[18:37] <Keybuk> ScriptRipper: ... this isn't twitter
[19:11] <asac> hmm after todays upgrades Xorg consumes tons of CPU (hardy usable) for me - i am on ati (free)
[19:11] <asac> bryce: tjaalton: ^^ ... any idea?
[19:22] <asac> bryce: tjaalton: seems like enabling exa caused this. going for Xaa makes things go back to normal (https://edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/1:6.9.0.91-1ubuntu3)
[19:22] <asac> bryce: tjaalton: what info do you need? i would love to have this fixed ... but in worst case we have to exclude this card from exa i think. let me knew
[19:33] <asac> bryce: tjaalton: its #315889
[20:59] <PovAddict> what just happened to the language packs? http://packages.ubuntu.com/hardy/language-pack-es
[20:59] <PovAddict> 36KB?
[22:03] <jpds> PovAddict: I believe the rest is contained in -base.
[22:03] <PovAddict> I just saw them show up as upgradeable packages in aptitude
[22:03] <PovAddict> from 3MB to 33KB
[22:04] <jpds> Hmm.
[22:05] <PovAddict> http://pastebin.com/d3746efeb
[22:06] <PovAddict> http://pastebin.com/d2c243f5
[23:21] <Hobbsee> hrm.  Jaunty X appears to have exploded.  Fun!
[23:23] <RainCT> oh, X likes explosions.. btw, is it normal that X fail to start if I close the laptop's lid while it's booting?
[23:24] <RainCT> jcastro: shame on you, how could you fall asleep? :P
[23:27] <Hobbsee> RainCT: this one's particularly interesting, with things like "failed to allocate frame buffer" and "Failed to allocate EXA offscreen memory" and "[dri] DRIScreenInit failed. Disabling DRI", which i've not seen before
[23:29] <RAOF> Hobbsee: Hurray for no acceleration!
[23:29] <Hobbsee> RAOF: indeed!  Well, X just does'nt start at all now
[23:31] <RAOF> Sounds fun.