[00:10] <ericm_> NCommander, yes, but as bjf said just the begining - there are a lot other need to be sorted out - far from complete
[00:11] <NCommander> ericm_, still, very promising to see things go upstream
[00:12] <ericm_> NCommander, yes - would be a lot easier for us
[11:23] <ripps> Are we going to use kernel 2.6.33 in Lucid?
[11:41] <crimsun> no.
[12:45] <weecol> can anyone recommend options for building and submitting builds via kernel.org source trees?
[12:46] <hyperair> weecol: what do you mean submitting builds?
[12:47] <hyperair> otherwise if you're looking for a suitable .config, you can get the ubuntu kernel packages and extract the /boot/config-<kernel version>.gz from it
[12:48] <weecol> do i have to have priveliges to offer a build in ubuntu based on a kernel org tree for example, could this go in a development channel at my first stage of working on the kernel?
[12:50] <hyperair> i don't really understand what you mean here.
[12:50] <weecol> how does one interact with testing to prepare a build for ultimate general release?
[12:50] <hyperair> i'm not sure actually (i'm not part of the kernel-team). the wiki page in the title should say something though
[12:52] <weecol> is there a path to submitting packages like the kernel for download from ubuntu repositories?
[12:53] <hyperair> for packages in general, there's revu.
[12:53] <hyperair> http://revu.ubuntuwire.com/
[12:54] <hyperair> http://wiki.ubuntu.com/REVU
[12:54] <hyperair> but for kernels it's best to bring up whatever issue in the kernel-team mailing list i would think
[12:58] <weecol> If I want to create a deb package of the kernel from kernel org is there a page in the wiki about patching the kernel tree so that you can then create a candidate package for other people to test in kernel development under ubuntu?
[12:59] <weecol> btw what is the ubuntu schedule for kernel normally?
[12:59] <weecol> is that something i can read some where else?
[13:04] <weecol> I am looking for some cummunity based development work I can join in with, what is the best approach for a collaborative manner of working?
[13:04]  * hyperair pokes apw
[13:04]  * apw looks confused
[13:05] <weecol> hoes he have more ideas on this then?
[13:05]  * hyperair is very confused as well
[13:06] <weecol> am i not making sence?
[13:06] <apw> weecol, i am not sure how far back to read, whats the question?
[13:07] <apw> are you asking if you can build and offer kernels to people as a 'personal thing" ?
[13:07] <apw> PPAs will build and allow distribution of kernels as for any other package
[13:09]  * apw waits for weecol 
[13:10] <weecol> is there a set plan to the kernel program or do different people contribute different ideas and you get a diversity of idea for the testing teams to try and comment on?
[13:10] <smb> Probably the question is "how can I help to get upstream fixes into ubuntu kernels" for which more or less the answer is work together with upstream.
[13:11] <apw> weecol, people are free to contribute to the process of getting the kernel ready for a release, though few do so
[13:11] <apw> the main interface for that is the kernel team email list
[13:12] <weecol> hope i haven't disturbed you too much.
[13:12] <apw> not at all
[13:12] <apw> weecol, not sure if we have managed to answer your question
[13:13] <weecol> so if I want to look at some fix/feature in a release in upstream I can work with a group in that part of the development team?
[13:14] <apw> the team is pretty small at the ubuntu level, we hang out here
[13:14] <apw> people wanting to help are always welcome
[13:15] <smb> Right, though writing to the mailing list has some advantages. For one people can look at it over time and it is less likely to be lost
[13:15] <apw> indeed
[13:18] <weecol> if I want to offer help but I want to help in more than one role is there any issues with that from what you can see?
[13:19] <weecol> i know I may have to manage my time and efforts like everyone would I can to everything.
[13:20] <smb> Not that I would see any. If you have a specific niche and can help there, why not
[13:21] <apw> indeed
[13:23] <weecol> how does the upstream and other source of fixes and features get managed is there someone who can see which parts have changed in the current tree?
[13:24] <weecol> is there a svn repositry for development kernel trees?
[13:24] <weecol> in ubuntu?
[13:24] <smb> There are git repos
[13:25] <rtg> weecol, https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
[13:26] <weecol> something gfor me to read
[13:27] <smb> weecol, when you look at the index (https://wiki.ubuntu.com/KernelTeam/KnowledgeBase) there is a whole bunch of things to help
[14:25] <asac> jjohansen: hey. jdstrand send me to you to ask about what commits from .32 apparmore would be good to backport to .31
[14:27] <asac> background: on arm we have .31 in lucid and want to ensure that we still deliver best apparmore experience ;)
[14:28] <rackerhacker> is this the right channel to inquire about the linux-ec2 kernel package?
[14:29] <jjohansen> asac: backporting individual commits from .32 will be kind of ugly, better to pull the whole thing
[14:29] <rtg> rackerhacker, jjohansen is the guy to ask. he may not be on yet.
[14:29] <rackerhacker> rtg: thanks - looks like both of you spoke at the same time ;)
[14:30] <jjohansen> asac: there is only one or two tweeks needed to have the .32 version run on .31
[14:30] <rtg> rackerhacker, xchat network lag :)
[14:30] <rackerhacker> hah
[14:31] <rackerhacker> jjohansen: when you have a moment, i have a question regarding linux-ec2 and compiling it from source
[14:31] <rackerhacker> no rush
[14:31] <jjohansen> rackerhacker: shoot, I am following a meeting atm but as long as you don't mind some lag now works
[14:32] <rackerhacker> jjohansen: i haven't had enough caffeine yet this morning, so i am a bit laggy as well
[14:32] <jjohansen> which source are you referring to, EC2 branch or using an upstream kernel
[14:33] <rackerhacker> jjohansen: i'm familiar with make-dpkg for standard debian/ubuntu kernels, but i'm still digging for the proper procedure to compile linux-ec2 using that ec2 kernel flaviour
[14:33] <rackerhacker> jjohansen: not upstream vanilla, i'm pulling the linux-ec2 source package itself
[14:33] <jjohansen> ah well in that case it is basically just the upstream build
[14:34] <jjohansen> what kind of problems are you running into?
[14:34] <rackerhacker> well, i'm wrestling with make-kpkg to get it to use the ec2 flavor
[14:35] <rackerhacker> to be completely honest, i'm used to compiling vanilla source all the time, but the debian/ubuntu build process throws me for a loop
[14:35] <jjohansen> hrmm, okay I have never used make-kpkg
[14:35] <rackerhacker> jjohansen: that's good to know - it's results are terrible so far ;)
[14:36] <apw> https://wiki.ubuntu.com/KernelTeam/KernelMaintenance i think is the place to find compile instructions
[14:36] <rackerhacker> do you use the fakeroot debian/rules method?
[14:36] <rtg> rackerhacker, you're swimming upstream. have you read https://wiki.ubuntu.com/KernelTeam/KernelMaintenance ?
[14:36] <jjohansen> rackerhacker: yep
[14:36] <rackerhacker> oh man, where was this page yesterday ;) this is exactly what i need
[14:36]  * rackerhacker facepalms
[14:37] <smb> rtg, Do we have any bugs associated with the last three Karmic LBM updates? I believe to remember there is one for compat-wireless but can't remember which number...
[14:37] <rtg> smb, not that I recall
[14:37] <rackerhacker> jjohansen: one last thing, and it might be somewhat trivial - would it be possible to rename the -ec2 tag to something else during the kernel build?
[14:38] <rtg> smb, are you referring to a tracking bug?
[14:38] <rackerhacker> jjohansen: i don't work for amazon ;)
[14:38] <smb> rtg, yes
[14:38] <rtg> smb, I have not created one.
[14:39] <rackerhacker> jjohansen: i've tried some basic hackery, but i've ended up causing more headaches
[14:40] <smb> rtg, Hm, I guess though it is "only" lbm, it might be nice for the sru
[14:40] <smb> rtg, I can do then
[14:40] <smb> rtg, Is there more reason for alsa updates than "offer the latest crack to people in need"?
[14:40] <rtg> smb, not as far as I'm concerned.
[14:41] <smb> rtg, Ok, then I'll take that :)
[14:42] <rtg> smb, LBM has always been best effort. at least now with the stable updates, we;re not as much at risk for totally braking things
[14:42] <rtg> breaking*
[14:42] <asac> jjohansen: pull the whole thing?
[14:43] <smb> rtg, Right, its more to make it a bit more similar to the main kernel sru. And I believe we had those before. Gives the sru team a bit to read. 
[14:44] <jjohansen> rackerhacker: it should be possible, I haven't really looked at it so I can't say how to do it off the top of my head
[14:45] <rackerhacker> jjohansen: i figured it might be a little involved ;)
[14:45] <asac> jjohansen: could you send me some pointers to asac@ubuntu.com ?
[14:45] <rtg> jjohansen, rackerhacker: change the package name in debian.ec2/changelog ?
[14:45] <jjohansen> asac: that would be the easiest backport, since it lives in its own dir
[14:46] <jjohansen> rtg: yeah that was my guess, I have done that to add my own tag but wasn't sure if that was sufficient to drop ec2 from the whole build and package
[14:46] <jjohansen> asac: sure
[14:47] <asac> thx a bunch!!!
[14:47] <rtg> jjohansen, it'll like take some more hackery then that, but I can never remember until I actually have to do it.
[14:47] <rtg> likely*
[14:51] <rackerhacker> rtg / jjohansen: thanks again for pointing me in the right direction
[14:58]  * apw cries, reviewing stable updates is incredibly boriing
[14:59] <rtg> apw, and there is a slew of 'em
[14:59] <smb> apw, Really? >:-P
[14:59] <apw> bah i am 'just' doing your 31.7 and thats borigin enough
[14:59]  * smb just completed 31.10
[15:00] <smb> (which admittedly were "only" 30 instead of 90)
[19:12] <rackerhacker> jjohansen: with linux-source-ec2, what's the recommended way to make menuconfig?
[19:13] <rackerhacker> jjohansen: i tried 'debian.ec2/scripts/misc/kernelconfig editconfig', but it refuses to save my changes, and reverts to the old configs each time its run
[19:13] <rackerhacker> s/its/it's/
[19:13] <jjohansen> really?
[19:14] <rackerhacker> yeah, it surprised me, too
[19:14] <jjohansen> rackerhacker: it is what I have used
[19:14] <jjohansen> reackerhacker: if you are just doing it temporarily, you can do
[19:15] <jjohansen> fdr clean
[19:15] <jjohansen> fdr prepare
[19:15] <jjohansen> make menuconfig O=debian.ec2/build
[19:15] <jjohansen> where fdr is fake debian root
[19:18] <rackerhacker> i'll give that a go
[19:19] <rackerhacker> jjohansen: the clean worked fine, but then the prepare threw an error -> http://pastie.org/769171
[19:27] <jjohansen> rackerhacker: sorry fdr prepare-ec2
[19:34] <rtg> rackerhacker, try 'fakeroot debian/rules editconfigs' instead of calling the script directly.
[19:35] <rackerhacker> thanks rtg - i'll try that as it's still not saving
[19:43] <rackerhacker> hmm, still not saving... this is quite peculiar
[19:43] <rackerhacker> each time i run editconfigs, it reverts to the defaults
[19:44] <rackerhacker> i'm wondering if my build environment isn't right
[19:44] <rackerhacker> i'm going to quit bothering y'all and try to clean this up, start fresh ;)
[19:45] <rtg> rackerhacker, 'sudo apt-get build-deps linux-ec2' should get all of the tools you need.
[19:46] <jjohansen> rackerhacker: a few things to check, is there a stamp-prepare-ec2 in debian/stamps
[19:46] <jjohansen> if you edit the configs manually you will need to touch that file
[19:46] <jjohansen> other wise they get regenerated
[19:47] <rackerhacker> jjohansen: that may be what i'm missing
[19:47] <rackerhacker> by manually, do you mean via something like vim? or via menuconfig?
[19:47] <jjohansen> yeah
[19:48] <jjohansen> if you are use fdr, I don't think it should be necessary
[19:49] <jjohansen> as it should save the changes to debian.ec2, so the changes show up when the config file is generated
[19:49] <rackerhacker> to get the source, do you recommend using 'apt-get install linux-ec2-source' ?
[19:49] <rackerhacker> i was downloading the tar.gz from packages.ubuntu earlier
[19:49] <rackerhacker> wasn't sure if they were the same
[19:50] <rtg> rackerhacker, 'git clone git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git'
[19:50] <rtg> then 'git checkout -b ec2 origin/ec2'
[19:59] <rackerhacker> rtg: thanks, will try that next
[21:39] <andrew[pkwrks]> hi everyone... i'm wondering, where did all the kernel debuginfo packages go?
[21:39] <andrew[pkwrks]> they used to be at http://ddebs.ubuntu.com/pool/main/l/linux/, but now that is empty...
[22:15] <andrew[pkwrks]> where have the kernel debuginfo packages gone... does anybody know?
[22:18] <smb> andrew[pkwrks], I cannot say where they have gone, but I believe the place is right. Will need to investigate