[06:32] <AnAnt> Hello, does linux-headers-2.6.31-19 include the changes in linux-headers-2.6.31-18 ? I ask because I don't see anything about linux-headers-2.6.31-18 in the changelog
[12:45] <JediMaster> Hey guys, hopefully in the right channel here, I'm trying to upgrade a VM from 9.04 to 9.10, I've tried it in the past and it's failed due to some problems with the kernel
[12:46] <JediMaster> it's a xen VM, and currently has 2.6.24-27-xen installed
[12:46] <JediMaster> I've done the do-release-upgrade and not rebooted and I've tried installing linux-image-2.6.31-19-virtual but I get:
[12:46] <JediMaster> Ignoring non-Xen Kernel on Xen domU host: vmlinuz-2.6.31-19-server
[13:08] <JediMaster> if it makes any difference I have no access to dom0 only domU
[13:43] <gangil> Hi , where can I get started with compiling the ubuntu 9.10 kernel , I mean any links..
[13:43] <gangil> ?
[13:44] <gangil> Is this the right place to ask beginner kernel questions?
[13:46] <ivoks> wiki.ubuntu.com/KernelTeam
[13:46] <ivoks> ?
[13:48] <ivoks> gangil: i'd start here https://wiki.ubuntu.com/KernelTeam/KernelGitGuide
[13:56] <gangil> ivoks: I have already downloaded the source kernel linux-2.6.31 , I needed a guide for kernel compilation and starting off with the source code :)
[14:02] <gangil> I did google it , but didn't quite get good results 
[14:03] <gangil> If anyone has any easy source or link , please share it
[14:06] <ivoks> first google link for ubuntu kernel build
[14:07] <ivoks> https://help.ubuntu.com/community/Kernel/Compile
[14:07] <ivoks> 7.
[14:15] <JediMaster> can anyone verify that the linux-image-virtual package will install a xen domU compatible kernel?
[15:04] <mirsal> hello
[15:04] <mirsal> ogasawara_, ping
[15:26] <jepler> I last tuned in to ubuntu kernel development/building for 8.04, where a flavour could apply patches from debian/binary.custom.d/flavour/patchset/*.  Is this facility gone in the lucid kernel?
[15:32] <lool> apw: I have an issue with "debian/rules updateconfigs": it empties debian.master/config/amd64/config.flavour.preempt and others
[15:33] <lool> Actually only debian.master/config/amd64/config.flavour.preempt
[15:33] <lool> and it changes a bunch of configs despite not having changed anything in the configs myself (yet)
[15:34] <lool> I see rtg just added the amd64 preempt flavour
[15:39] <lool> Looks like updateconfigs wasn't run after adding the preempt flavour
[16:53] <apw> lool, ok
[17:09] <lool> apw: I'm preparing a series of patches updating the configs
[17:09] <lool> Including one running updateconfigs
[17:10] <apw> lool, yep its broken right now it seems, i am working on it
[17:16] <lool> apw: I'm saying, I'm sending a patch as part of a stack which will fix this
[17:16] <lool> Might actually be simpler if you dont updateconfigs too
[17:31] <lool> apw: So I'm working on the versatile config, and the update is getting really large
[17:31] <lool> I'm basically trying to minimize delta with common configs
[17:31] <lool> Is it ok if I dump this as a very large config update?
[17:32] <apw> i was juist told you had it down to two config changes by ogra
[17:32] <lool> apw: That's to fix video output
[17:33] <lool> apw: Problem is that the versatile config is a mess
[17:33] <lool> apw: So in subsequent commits I'm trying to bring it in shape
[17:33] <apw> as its only used to qemu, as long as it boots thats all that matters
[17:34] <lool> apw: Ok; my goal is to have the config as close to a desktop config as possible
[17:34] <lool> So I'm working on minimizing the length of the versatile and common.armel files
[17:34] <apw> well if it was as close as possible  the config changes sahould be reducing delta, and so moving stuff up to common.config ... and that is good so go for it
[17:35] <lool> apw: That's exactly what I'm doing
[17:35] <apw> then thats good, when will i get it, as i can't sensibly do any updates if you are doing something so invasive
[17:36] <lool> However, it's a bit long because things like CONFIG_PCI were missing, or CONFIG_NLS so I have to flip all the right options
[17:36] <lool> (Since the config update tool defaults to the upstream defaults, not the ubutnu commons IIUC)
[17:39] <apw> lool, depends how you do it
[17:39] <apw> if you add CONFIG_PCI to the flavour and rebuild the others will default from the common
[17:45] <lool> apw: I'm adding everything to the versatile flavour, yet a bunch of new delta keeps appearing after updateconfigs
[17:45] <lool> I could copy the common config at the top of the versatile flavour perhaps
[17:48] <apw> lool yep though that is how the config construction is meant to proceed
[17:58] <lool> Ok; I think I'm done
[17:58] <lool> I need to test build this huge diff
[18:06] <lool> apw: So a) it boots (didn't try with a root device) and b) has nicer fonts   ;-)
[18:07] <lool> I didn't build modules, nor an actual kernel package, just the zImage in the lucid tree
[18:07] <lool> Now I just need to figure out how to fix my umask when pushing to kernel.u.c
[18:10] <lool> Ah it's a bug with zsh
[18:16] <lool> apw: I've sent the pull request
[18:17] <lool> versatile-config-fixes branch in lool/ubuntu/ubuntu-lucid.git repo
[18:50] <apw> lool, thanks got it ... have you tested it?  ie. can i just spoon it in in your name?
[18:51] <lool> apw: As I said, I've booted it to the kernel panic rootfs not found
[18:52] <lool> apw: Which is an improvement over what we have in archive right now which doesn't output anything (probalby doens't boot)
[18:52] <lool> apw: I just finished building the modules too
[18:52] <apw> ok, then i'll shove it into the repo
[18:52] <lool> apw: So technically, it should be a win and should build
[18:52] <lool> apw: What I intend to work on next is making more drivers builtin this kernel (storage, ethernet etc.) and that should be it
[18:52] <apw> i'll squash your first two commits, into a combined 'un-f*ck preempt configs'
[18:52] <lool> ok
[18:53] <lool> the second commit is just "updateconfigs" which is why I split them
[18:53] <lool> (doing updateconfigs without the first fix resulted in the version config being copied in a bunch of places)
[18:53] <apw> yeah, i am going to squash them for this commit, and then just squash them into the preempt add, as that was just a fook up
[18:54] <apw> it should never have existed and just will cause issues for M
[18:54] <lool> Ok
[18:54] <apw> good spot thanks
[18:54] <lool> I think that's the only weird thing I saw from preempt/amd64
[18:54] <lool> But I did cross other oddities between i386 and amd64 while poking armel; nothing serious, just surprizing differences in this or that non-arch specific feature being a module or builtin for instance
[18:55] <lool> Anyway, the way to go is probably your config enforcer for the core stuff
[18:55]  * lool => dinner and WE
[18:56] <lool> apw: thanks for review and merging and have a safe trip back
[18:57] <apw> lool yeah we have review of that on the agenda for this week if we get that far
[18:57] <apw> and i think yes we will add rules to keep them in sync through the enforcer
[18:57] <apw> you too
[20:44] <lamont> where is umask hidden in /proc/NNN/?
[21:40] <jk-> lamont: looks like it isn't in there
[21:42] <jk-> lamont: is this for a once-off thing? or something you need to script?
[21:43] <lamont> one off
[21:43] <jk-> gdb -p process
[21:43] <lamont> I'm actually going to just to a mother-of-all straces to find where it's happening
[21:43] <jk-> p /x umask()
[21:43] <lamont> yeah
[21:43] <jk-> ok, fair enough :)
[21:43] <lamont> I verified that it wasn't what I wanted it to be, and put a workaround in place for it
[21:44] <jk-> also, -e trace=umask  may make your "mother of all strace" less "mother of all"
[22:28] <mirsal> ogasawara, ping ?