[07:46]  * smb --> BOD
[07:55] <cking> BOD?
[07:57] <smb> cking, Beginning Of Day
[08:00] <cking> ah
[08:17]  * apw notes cking is so last year
[08:18] <cking> why?
[08:18] <cking> 'cos I don't comprehend an arbitary TLA
[08:18] <apw> not knowing BOD ... i bet you can't understand your kids either :)
[08:19] <smb> apw is quite harsh this morning. :)
[08:20] <apw> smb, its my job
[08:27] <cking> ignorance is not an excuse I see
[08:31] <apw> cking, there are no excuses
[08:32] <cking> shame
[08:32] <apw> smb, http://people.canonical.com/~apw/CVE-2011-1090-hardy/
[08:32] <ubot2> apw: The __nfs4_proc_set_acl function in fs/nfs/nfs4proc.c in the Linux kernel before 2.6.38 stores NFSv4 ACL data in memory that is allocated by kmalloc but not properly freed, which allows local users to cause a denial of service (panic) via a crafted attempt to set an ACL. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1090)
[08:35] <apw> !kernel-src
[08:35] <ubot2> Factoid 'kernel-src' not found
[08:35] <apw> !kernel-source
[08:36] <ubot2> You can access all the kernels for previous and current development releases at http://kernel.ubuntu.com/git. There are repositories for each supported release under ubuntu/ubuntu-<release>.git - For more details see: https://wiki.ubuntu.com/Kernel/SourceCode
[08:36] <apw> !faq
[08:36] <ubot2> A list of common questions and answers about Ubuntu: http://help.ubuntu.com/community/CommonQuestions - Official documentation: http://help.ubuntu.com
[08:38] <smb> !kernel-faq
[08:38] <ubot2> Factoid 'kernel-faq' not found
[08:40] <apw> !kernel-faq is A list of common questions about the Ubuntu Kernel: http://wiki.ubuntu.com/Kernel/FAQ
[08:43] <apw> !kernel-mainline is Information and binaries of the upstream mainline kernels are found here: https://wiki.ubuntu.com/Kernel/MainlineBuilds
[08:43] <ubot2> apw: Error: I am only a bot, please don't think I'm intelligent :)
[08:43] <apw> !kernel-mainline
[08:43] <ubot2> Factoid 'kernel-mainline' not found
[08:46]  * apw tires of ubot2
[08:47] <smb> !kernel-mainline is <reply> Information and binaries of the upstream mainline kernels are found here: https://wiki.ubuntu.com/Kernel/MainlineBuilds
[08:47] <ubot2> smb: Error: I am only a bot, please don't think I'm intelligent :)
[08:47] <smb> hm, does not like that either...
[08:50] <apw> no odd indeed
[09:09] <apw> !kernel-mainline
[09:09] <ubot2> Factoid 'kernel-mainline' not found
[09:10] <smb> !kernel-faq
[09:10] <ubot2> Factoid 'kernel-faq' not found
[09:11] <apw> !kernel-faq
[09:11] <ubot2> Factoid 'kernel-faq' not found
[09:11] <apw> hmmm
[09:12] <apw> !kernel-faq
[09:12] <ubot2> Factoid 'kernel-faq' not found
[09:44] <hemin>  Hi, I compiled my kernel from the source code.. after make, make_modules and make install and update_grub, I rebooted.. Now when I choose the new entry from the list, It gives me this error "Kernel panic- not syncing: VFS: Unable to mount root fs on unknown-block(0,0)" .. any suggestions ??
[09:49] <smb> Doing the install that way you likely missed to build an initrd. If "the source code" is our git repos, you should better follow https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel which gives you .deb packages that will do that all when you install
[09:52] <hemin> I downloaded from kernel.org, 2.6.38.8 .. how do I know if I have missed to build initrd?
[09:53] <smb> You have no initrd.img-... with that version in /boot. Btw, if that is a vanilla 2.6.38.8 build, did you know those are already built?
[09:54] <smb> !kernel-mainline
[09:54] <ubot2> The kernel team supply continuous mainline kernel builds which can be useful for tracking down issues or testing recent changes in the Linux kernel. More information is available at https://wiki.ubuntu.com/Kernel/MainlineBuilds
[09:54] <apw> !kernel-faq
[09:54] <ubot2> A list of common questions about the Ubuntu Kernel can be found in http://wiki.ubuntu.com/Kernel/FAQ
[09:54] <apw> nice
[09:59] <cking> !kernel-oops
[09:59] <ubot2> Factoid 'kernel-oops' not found
[10:00] <cking> !kernel-dev
[10:00] <ubot2> Factoid 'kernel-dev' not found
[10:00] <cking> yawn
[10:00] <smb> cking, she does not like you. :)
[10:01] <hemin> smb: I tried to compile the same version installed on my machine through source which is 2.6.38.8 .. does it cause any problem?
[10:04] <smb> hemin, Apparently it does. But seriously, it would just save you the compile time and some of the worries when using the mainline builds. As your build now there are a few special drivers/modules missing but usually that does not cause problems. And installation is much simpler when using a .deb
[10:07] <hemin> smb, ok.. My motive to compile through sourcecode was to learn rather than just installing it
[10:09] <hemin> smb, i would try the .deb package too
[10:11] <smb> hemin, Then I would actually start with the build your own kernel link. Which uses the exact same sources as are used for the releases (and have the ./debian infrastructure). And when being familiar with that look at mainline kernels as a secondary step
[10:12] <hemin> smb, ok.. would go through that document and try out
[10:33] <hemin> smb, I would like to remove the kernel I installed from the source.. how to do that safely as my current working kernel and the installed one has the same version?
[10:37] <smb> hemin, While they are based on the same version, they should have slightly different names. You probably have a vmlinuz-2.6.38 and a vmlinuz-2.6.38-x-generic or so in /boot and likewise a directory with -gerneric (or whatever flavour you got) in /lib/modules
[10:39] <smb> But as you installed them without a package the way to remove them is to remove the file / directory in /lib/modules and then run update-grub to clean up your grub menu
[10:39] <smb> Note those files with -generic in them are the original ones and you should _not_ remove them
[10:41] <hemin> smb, yes.. vmlinuz-2.6.38.8, vmlinuz-2.6.38.8-generic both are there.. ok.. so the generic ones are not to be touched
[11:07] <ppisati> apw: when you want, can you open an lp tracker for CVE-2010-4251? thanks
[11:07] <ubot2> ppisati: The socket implementation in net/core/sock.c in the Linux kernel before 2.6.34 does not properly manage a backlog of received packets, which allows remote attackers to cause a denial of service (memory consumption) by sending a large amount of network traffic, as demonstrated by netperf UDP tests. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4251)
[11:08] <bliss> hmm, haven't noticed that one
[11:10] <apw> ppisati, should be done: bug #807462
[11:10] <ubot2> Launchpad bug 807462 in linux-ti-omap4 "CVE-2010-4251" [Undecided,Invalid] https://launchpad.net/bugs/807462
[11:19] <ppisati> cool, 10
[11:19] <ppisati> x
[12:44] <tgardner> apw, are you happy with 3.0.0-4.5 in kernel-ppa ?
[12:45] <smb> herton, sconklin It looks like I need to do yet another respin of lucid-ec2. This time it even needs an aditional revert for ec2 (as I had made changes to follow the reverted patch)
[12:48] <herton> smb: hmm ok, just invalidate the current tracking bug. In fact we should be doing the rebases now, you can just have the branch ready and we do the packages
[12:49] <smb> herton, ok. I will be pinging you when I have pushed the tree. Want to get it test built before
[12:50] <herton> ok
[12:53] <euroford> 连http://lists.debian.org/都被墙了？
[12:53] <euroford> http://lists.debian.org/
[13:12] <smb> herton, new lucid-ec2 branch pushed out. proceed at your leisure
[13:12] <herton> smb: ok
[13:24] <herton> smb: the repo misses the tag for 2.6.32-317.35, the previous release, not sure this matters much
[13:25] <smb> herton, I did put it. Maybe you need to try git fetch --tags?
[13:25] <smb> push I mean
[13:27] <herton> smb: yes, --tags brought it. I found strange as I had here the 317.36 tag but not the .35...
[13:28]  * smb thinks it may happen when the tag in question is not part of any named branch anymore...
[14:37] <brendand> sconklin - what's up with lucid SRU?
[14:38] <brendand> sconklin - 33.69 not getting released?
[14:38] <ricotz> sconklin, hello :), i saw a lot of ubuntu kernel updates lately, but is there a reason that the natty kernel is still base on 2.6.38.7 instead of 2.6.38.8?
[14:40] <apw> ricotz, its pending the current round of updates making it through testing and out
[14:40] <smb> and lucid seems to have found one more regression
[14:40] <herton> brendand: sorry, we had to resping lucid again because of another regression
[14:41] <smb> so -33.70 got mode
[14:41] <smb> made
[14:41] <apw> herton, yep smb is correct, only things on the linear history are downloaded without --tags
[14:41] <brendand> skaet mentioned another fix going in?
[14:41] <apw> herton, what the hec was this one
[14:41] <brendand> and this is the one that will be used in 10.04.3?
[14:41] <herton> brendand: yep, steve talket to her
[14:41] <herton> *talked
[14:41] <herton> apw: let me see here the bug number
[14:42] <ricotz> apw, i see, it has been quite some time and the last update missed it by one day ;)
[14:42] <ppisati> do i need to put BugLink and "commit upstream" even on commits upon which other CVE commits depend?
[14:42] <herton> apw: bug 805209
[14:42] <ubot2> Launchpad bug 805209 in linux "System locks up after upgrading to linux-image-2.6.32-32-generic-pae" [Undecided,New] https://launchpad.net/bugs/805209
[14:43] <herton> brendand: correct, this one should end in .3 point release from what I got
[14:43] <apw> ppisati, all upstream commits should be recorded if they are pulled in in case we ever care to know where they came from
[14:43] <brendand> ok, good to know
[14:43] <apw> ppisati, and anything we commit for a specific fix should mention the bug number 
[14:43] <apw> so i think thats yes and yes
[14:43] <herton> brendand: so just watch the 33.70 tracking bug when you got the task to confirmed
[14:43] <ppisati> ok
[14:43] <brendand> herton - certainly
[14:50] <kees> I'm nervous about the fix for 791019 -- this ends up mixing spinlock_bh() with spinlock(). I don't think this is safe...
[14:52] <tgardner> kees, for natty ?
[14:53] <kees> tgardner: oneiric
[14:53] <kees> I don't know if mixing _bh with non-_bh is safe
[14:53] <tgardner> kees, its not. what did we miss?
[14:54] <kees> let me look, I haven't seen the commit yet. fetching it now
[14:55] <tgardner> kees, looks like all uses of ptracer_relations_lock use _bh lock/unlock functions
[14:56] <kees> tgardner: ah, so they all got replaced? is that sensible? i.e. it's only to use _bh everywhere?
[14:56] <tgardner> kees, yes, its quite sensible.
[14:56] <kees> okay, cool. reading commit now
[14:57] <tgardner> kees, if any of the list manipulation functions can be called from soft IRQ context, then you must use _bh functions for protection.
[14:58] <kees> tgardner: right, that's cool. I wasn't sure if it was okay to use _bh in non-soft-IRQ context.
[14:59] <tgardner> kees, well, in fact you have to in order to prevent a soft IRQ context from getting control. Thats the whole point.
[15:05]  * kees nods
[15:28] <ppisati> besides rolling an image and testing it with qemu, is there any quick way to test a lucid amd64 kernel?
[15:28] <ppisati> or if anyone wants to try it...
[15:28] <ppisati> i just need a "it boots!"
[15:51] <bjf> ppisati, there are a few of us that are running lucid 64, put the kernel up somewhere and we will boot test it for you
[15:52] <ppisati> bjf: i'm almosto done rolling my image
[16:44] <sconklin> manjo: https://bugs.launchpad.net/linux/+bug/790754 is going to be reverted
[16:44] <ubot2> Ubuntu bug 790754 in linux "[NATTY] RICOH [1180:e823] unable to read MMC cards" [Undecided,Confirmed]
[16:45] <manjo> sconklin, agreed ...
[16:45] <manjo> sconklin, why revert for natty ? 
[16:45] <sconklin> For Maverick
[16:45] <manjo> ok
[17:07]  * smb -> EOW
[18:03]  * tgardner --> lunch
[19:06]  * cking --> EOD
[20:02] <lamont> 15811424        build/buildd/linux-3.0.0/
[20:02] <lamont> um... guys?  that's a tad bit huge, don't you think?  I'll put cash on it failing to build on most of the ppa buidlers
[21:18] <lifeless> what target builds linux-header-x.y.x package? 
[21:19] <Sarvatt> binary-headers
[21:38] <lifeless> Sarvatt: thanks! I should have nvidia going again on my custom build :)