[04:57] <CarlFK1> What does "Tainted GM" mean in:  Pid: 6523, comm: dvswitch Tainted: G   M      2.6.27-11-generic #1 [
[04:57] <CarlFK1> full dump: http://dpaste.com/109665/ 
[10:47] <apw> CarlFK1, the G means you have modules loaded but they wern't proprietry, the M means your machine recieved a machine check in the past
[11:09] <Kinnison> Hi guys, one of the things I'd like to do this weekend is update my toshiba acpi module so that it doesn't crash modern kernels. To do that, I need jaunty's kernel tree. Is it simply git://kernel.ubuntu.com/ubuntu/ubuntu-jaunty.git ?
[11:09] <Kinnison> And is there a simple set of instructions for turning that into a kernel package? (I'll need to update the kernel on my laptop)
[11:24] <Keybuk> yes
[11:24] <Keybuk> "fakeroot debian/rules binary" usually does the trick ;)
[11:24] <Keybuk> though if you're patching, you'll find it annoying to rebuild every time
[11:25] <Keybuk> I usually do out-of-tree ordinary kernel builds (grab the config out of debian/...) until I've got the patch right
[11:29] <Kinnison> right, so the configs are just in debian/ ?
[11:29] <Kinnison> cool
[11:29]  * Kinnison is apparently 52% through 'checking out files'
[11:29]  * Kinnison sighs. kernels are so big these days
[11:30] <Kinnison> Is Jaunty going with 2.6.28 or hoping for 2.6.29?
[11:40] <Kinnison> Keybuk: Presumably I need to concatenate config and config.generic ?
[11:40] <Keybuk> right
[11:40] <Keybuk> 2.6.28 for jaunty
[11:41] <Kinnison> Okies
[11:41] <apw> Kinnison, it is highly unlikely .29 will be out before the kernel is frozen, and we are unlikely to change at this late stage in the cycle.  this is even less likely now we are seeing much more fixes via the stable kernel trees
[11:41] <Kinnison> nod. 2.6.28 is fine I believe
[11:41] <Kinnison> I *think* what I need is in 27 so it should be fine
[11:42] <apw> if you can't just pick the kernels out of /boot/config-* then you can make the configs using debian/rules prepare-generic 
[11:42] <apw> and find them in debian/build/build-generic/.config
[11:43] <Kinnison> I can't pick them out of /boot because the laptop is on 8.04 and I'm loathe to move it on from there because of openvpn issues in 8.10
[11:43]  * Kinnison starts a kernel building
[12:02] <Kinnison> Okay, awkward question.. Given the debian/build/build-generic directory containing a built kernel, can I use that for building out-of-tree modules?
[12:02]  * Kinnison is *so* out of date on kernel building it's sad.
[12:02] <Kinnison> if it's not 'make CROSS_COMPILE=$XC ARCH=arm zImage' then I get confused :-)
[12:09] <Keybuk> cking: sorry, but for filing that bug I'm going to pick on you now ;)
[12:10] <cking> Keybuk: yeah yeah
[12:11] <Keybuk> cking: I need you to step through the boot process by hand
[12:11] <Keybuk> init=/bin/bash, then run each init script in turn (/etc/rcS.d/S01... start, S02... start, etc.)
[12:11] <Keybuk> and between each one, look in /dev for pktcdvd
[12:11] <Keybuk> and see which init script creates it
[12:11] <Keybuk> or is it there in the initramfs, etc.
[12:12] <cking> Keybuk: OK - I will do this in ~1 hour or so once I've finished the current ISO test - is that OK?
[12:12] <Keybuk> sure
[12:12] <Keybuk> it's your bug ;)
[12:13] <cking> ..well it's not a  mega-high show stopper. I will figure out which script creates the message and report to the bug sometime today...
[12:35] <Kinnison> Keybuk: Once I've built a kernel, can I just take the contents of the firmware/ dir and copy that to /lib/firmware/$(kver) and expect it to behave?
[12:57] <Keybuk> Kinnison: I should think so
[12:59] <Kinnison> Keybuk: sweet.
[13:00] <Kinnison> yay, and make -C ..../build-generic M=$(pwd) does the trick
[13:00]  * Kinnison should be able to sort out tlsup for jaunty
[13:00]  * Kinnison is pleased
[14:32] <rtg> Keybuk: you were chortling yesterday about some change that saved several more seconds at boot time. What was it?
[14:42] <Keybuk> rtg_: making lsb_release just return the values in /etc/lsb-release if they're all present
[14:42] <Keybuk> instead of firing up things like apt-cache to work it out
[14:43] <rtg_> not a kernel issue :)
[14:58] <EtienneG_home> hey guys!  is the difference between -virtual and -server documented somewhere?  Is it just the VMI stuff, or there is more to it?
[15:00] <rtg_> EtienneG_home: Hardy?
[15:01] <EtienneG_home> rtg_, yes indeed
[15:01] <rtg_> EtienneG_home: if memory serves, the server kernel is used in the virtual package, so there is no differnce.
[15:02] <EtienneG_home> rtg_, ok!
[15:02] <EtienneG_home> thanks for the info
[15:02] <EtienneG_home> I think I will diff the config, just to see
[15:03] <rtg_> EtienneG_home: hmm, there is a virtyual flavor in i386 but not amd64.
[15:03] <rtg_> looks like a lot of devices are not enabled.
[15:04] <rtg_> EtienneG_home: I get confused, it was Intrepid where we started using the server kernel in the virtual package
[15:04] <EtienneG_home> rtg_, ok
[15:04] <EtienneG_home> I will investigate
[15:14] <Keybuk> cking: there's a patch to grub that replaces the delay with a "hold down a modifier key"
[15:16] <rtg_> Keybuk: that doesn't work on all BIOSs. sometimes the keyboard is disabled if you're holding down a key during boot.
[15:16] <cking> rtg_: thanks for that insight
[15:16] <rtg_> seems like crack to me, but there you have it.
[15:17] <cking> probably holding down a key during boot confuses the Embedded Controller
[15:17] <cking> ..and the user
[15:20] <cking> Keybuk: I'd hate to change the expected functionality (use the ESC key) with something that won't work for all machines - especially for the sake of 1 second 
[15:20] <cking> I expect anyone who really wants to shave time off the grub delay can do so by editing the menu.lst file#
[15:21] <cking> I will look at the patch sometime soon though 
[15:22] <Nafallo> isn't that patch of preventing flicker as well?
[15:22] <Nafallo> s/of/for/
[15:22] <Keybuk> why would it prevent flicker?
[15:23] <Nafallo> just something I read on some fedora interview site :-)
[15:23] <Nafallo> let me see if I find the URL
[15:24] <Nafallo> http://fedoramagazine.wordpress.com/2008/10/21/interview-fedora-10s-better-startup/ <-- Keybuk 
[15:24] <Nafallo> Keybuk: there is a five point list about 2/3 in.
[15:25] <tjaalton> the menu is not shown unless you have a dualboot setup
[15:25] <tjaalton> but it doesn show the countdown
[15:25] <tjaalton> -n
[15:25] <Nafallo> oh. those people are talking about the full menu?
[15:25] <tjaalton> yes
[15:26] <Nafallo> man. I should try fedora at some point :-P
[15:26] <tjaalton> with grahix :P
[15:26] <tjaalton> uh
[15:26] <tjaalton> *graphix
[15:26] <Keybuk> Nafallo: that only counts for Fedora because they have a graphical grub
[15:26] <Nafallo> Keybuk: hehe. fair enough.
[15:26] <Keybuk> that's why I've used phrases like "over my dead body" when people suggest Ubuntu has a graphical grub menu
[15:26] <Nafallo> Keybuk: we did have that! :-)
[15:27] <Nafallo> I remember using it :-)
[15:45] <cking> Keybuk: w.r.t /dev/pktcdvd  - it's created by /etc/rcS.d/S10udev by the line "if /sbin/udevadm settle; then"
[15:47] <cking> "by" means by the time we get to
[15:58] <Kinnison> is it mentioned in any of /etc/udev/rules.d ?
[16:00] <mdz> will call you in just a moment
[16:00] <Keybuk> cking: can you tar up your /dev for me
[16:01] <Keybuk> I assume you mean it's not created by anything before that init script
[16:01] <cking> Keybuk: it's not created until we hit S10udev - I added some debug into the script and watched it appear while the script was executing
[16:02] <Keybuk> ok
[16:02] <cking> ..tar file in an Email in a mo
[16:04] <cking> it's a mystery why it's being created
[16:06] <MykelSilver> hi, first best wishes to everyone. My question: this morning my ubuntu request a reboot because of a new kernel update: linux-image-2.6.27-11-generic (2.6.27-11.23) to 2.6.27-11.24.... I cannot find any information what the security issues are to update... Normally I can find them at http://www.ubuntu.com/usn ... But not this time.... Any has a link for more info...?
[16:07] <rtg_> MykelSilver: its not a security update. you're subscribed to -proposed.
[16:07] <MykelSilver> o sorry
[16:08] <rtg_> MykelSilver: look at https://edge.launchpad.net/ubuntu/+source/linux for changelog entries
[16:08] <MykelSilver> THANKS :-)
[16:08] <MykelSilver> very happy for helping me 
[16:09] <MykelSilver> got it... very fast response. amazing
[16:09] <MykelSilver> nice day. bye
[16:09] <rtg_> I live to serve
[16:40] <rtg_> kirkland: did you get a chance to try 'eCryptfs: Filename Encryption: mount option' ?
[17:03] <kirkland> rtg_: on my todo list for today ;-)
[17:04] <rtg_> kirkland: I'm installing a laptop right now. I didn't realize it requires a mount option.
[17:04] <kirkland> rtg_: yes.  if we like it, we can add it to mount.ecryptfs_private
[17:04] <kirkland> rtg_: ie, if it works well
[17:04] <kirkland> rtg_: well, make it configurable anyway, in your .ecryptfs dir
[17:05] <rtg_> kirkland: if it works well, I think it ought to be a package default
[17:05] <kirkland> rtg_: agreed
[17:05] <kirkland> rtg_: i'm thinking we can perhaps target that for the next alpha
[17:05] <kirkland> rtg_: the installer just started supporting encrypted home yesterday/today
[17:05] <kirkland> rtg_: that's what I'm testing at the moment
[17:05] <rtg_> kirkland: me too.
[17:06] <rtg_> kirkland: whats the story on encrypted swap?
[17:06] <kirkland> rtg_: i need to talk to Keybuk about that....
[17:06] <kirkland> Keybuk: ping?
[17:08] <Keybuk> yup?
[17:09] <rtg_> Keybuk: encrypted swap
[17:09] <Keybuk> never touch the stuff ;)
[17:09] <cking> that's fairly straight forward response
[17:10] <rtg_> Keybuk: :) we discussed the fact the encrypted home isn't much good if you leave stuff in swap
[17:10] <Keybuk> I recall
[17:13] <Keybuk> was there anything in particular about it you wanted to discuss?
[17:14] <rtg_> Keybuk: uh, just wondered if/when it was going to get enabled whenever some chooses encrypted home.
[17:14] <rtg_> s/some/someone/
[17:14] <Keybuk> my dead body may be involved ;)
[17:15] <rtg_> oh, not that again, right along with graphical grub, huh?

[17:16] <Keybuk> I still object to the detail that a multi-user machine cannot be resumed if encrypted swap is used
[17:17] <rtg_> Keybuk: ugh, I forgot about resume.
[17:20] <Keybuk> cking: around?
[17:21] <cking> Keybuk: yep. 
[17:21] <Keybuk> cking: could you run sudo udevadm test /devices/virtual/misc/pktcdvd
[17:22] <cking> Keybuk: not quite at the moment - the laptop is being "upgraded"
[17:22] <cking> ..but I will once I can 
[17:22] <Keybuk> kk
[17:22] <Keybuk> you're sure that symlink did not exist before S10udev ?
[17:31] <rtg_> cking: were you having problems with udev? my laptop complains that it can't read /etc/udev/rules.d and then nothing really works right after that.
[17:32] <cking> Keybuk: pretty certain - I put in "ls -al /dev/pktcdvd" in the script and observed when it could list the device
[17:32] <cking> rtg_: only /dev/pktcdvd 
[17:32] <rtg_> huh, so far I'm underwhelmed by A3
[17:33] <cking> three steps back.. for one forward?
[17:34] <rtg_> seems like
[17:35] <Keybuk> cking: I really need a bit more live help debugging this one I'm afraid
[17:36] <cking> Keybuk: OK - well I will run the udevadm as suggested when I reassembled the laptop this evening
[17:36] <Keybuk> that'll push us back until monday before I can look at it :-/
[17:37] <cking> Keybuk: OK - but I've got a family to put to bed and I've been working since 7am.. give me a 30 mins...
[17:38] <cking> ..I've got little kids to sort out.. hold on
[17:38] <Keybuk> :)
[17:48] <Keybuk> cking: ahh, no panic
[17:48] <Keybuk> I've just realised that this isn't hardware related
[17:48] <Keybuk> I can replicate it here
[18:02] <cking> Keybuk: that's good news to me :-)
[18:43] <ogasawara> cking, rtg:  you guys have migrated to ext4 ya?  I just read bug 317781 .  Curious if you guys have seen any issues?
[18:43] <ubot3> Malone bug 317781 in linux "Ext4 data loss" [High,Triaged] https://launchpad.net/bugs/317781
[18:44] <rtg_> ogasawara: ext4 doesn't claim to preserve data, only the journal
[18:45] <rtg_> ogasawara: perhaps he's getting nipped because ext4 is lazier about committing data
[19:37] <Keybuk> wtf. are
[19:37] <Keybuk>  /dev/cpu_dma_latency
[19:37] <Keybuk>  /dev/network_latency
[19:37] <Keybuk>  /dev/network_throughput
[21:44] <CShadowRun> Does anyone know when the 2.6.29 kernel is due in ubuntu?
[21:45] <CShadowRun> i'm waiting on it since support for my webcam has been regressed since intrepid and the fix is supposed to be in that release :D
[23:52] <ogasawara> CShadowRun: Jaunty is going to have 2.6.28, so Jaunty+1 will likely be 2.6.29.  do you have a specific patch reference?  It could probably be cherrypicked.