[01:27] <Sarvatt> heads up that X is broken in 2.6.37-5 with kvm/vmware and on a ton of old UMS drivers until this commit comes in in case it comes up - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8c05cd08a7504b855c265263e84af61aabafa329
[01:44] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/676759
[01:44] <ubot2> Launchpad bug 676759 in linux (Ubuntu) "X fails to start in vmware/kvm and with various UMS drivers on 2.6.37-5 (affects: 3) (dups: 1) (heat: 20)" [High,Triaged]
[01:45] <jk-> Sarvatt: ack
[02:12] <kees> is anyone successfully using the natty kernel? I'm seeing really broken NFS with it (file locking appears hosed).
[02:13] <lifeless> nfs locking hosed....
[02:13] <lifeless> this is different somehow?
[02:15] <kees> lifeless: yes. I've had no problems for years.
[02:29] <RAOF> I'm using the natty kernel, but I don't use NFS.  Nothing seems to be more broken than usual.
[02:30] <kees> I'll track it down tomorrow...
[07:50] <kees> I bet this fixes NFS for me... http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8e35f8e7c61c88f9a979a4e6f7f4ffd4c158a88a
[07:50]  * kees waits for -rc3
[07:50] <kees> :)
[07:59] <TheSarge> So what is the deal with the new patch?
[07:59] <TheSarge> Are you guys gunna take the bashrc workaround instead?
[08:02] <TheSarge> Hello?
[08:04] <amitk> TheSarge: patience :) Most of the kernel team working on the Ubuntu distro kernel are in the European timezone - so they are probably stumbling around looking for coffee at the moment.
[08:05] <amitk> (and US timezone)
[12:09] <juniort> Hi I am new member here I just had posted on mailing list
[12:09] <juniort> for doing some thing on the kernel front
[12:09] <juniort> I am having a Laptop 
[12:09] <juniort> and that is the only hardware available to me
[12:10] <juniort> I have developed a character device driver recently
[12:10] <juniort> and have been reading a lot of things related to 
[12:10] <juniort> devices such as CMOS ,Network and etc etc
[12:10] <juniort> so I wish if I can contribute to 
[12:10] <juniort> the kernel development or bug fixing some way 
[12:10] <juniort> so show me some way
[12:11] <juniort> I am very interested for the wireless devices area
[12:11] <juniort> but I do not have  hardware for that
[12:13] <juniort> I have checked this page https://wiki.ubuntu.com/KernelTeam/BugTriage
[12:14] <juniort> and also looked at this page https://wiki.ubuntu.com/Kernel/Dev/KernelPatches
[12:16] <juniort> I have also checked this page https://bugs.launchpad.net/ubuntu/+source/linux/+bugs
[12:16] <juniort> let me know how can I start 
[12:16] <juniort> working
[12:19] <JeanPijon> Hello to all devs. Can someone please tell me, if there will be enabled again OSS emu sometime in the future in the stock kernel? 
[12:21] <diwic> JeanPijon, that is unlikely
[12:22] <joaopinto> JeanPijon, you probably want to follow https://bugs.launchpad.net/ubuntu/+source/linux/+bug/579300
[12:22] <ubot2> Launchpad bug 579300 in linux (Ubuntu) "Please disable CONFIG_SOUND_OSS* and CONFIG_SND_*OSS* (affects: 19) (heat: 130)" [Wishlist,Fix committed]
[12:23] <JeanPijon> joaopinto: I have read this, so there won't be stock kernel with this feature enabled?
[12:24] <joaopinto> that is what looks from the bug reading
[12:24] <joaopinto> it was one of those hard changes
[12:25] <JeanPijon> joaopinto: I see, but there will be probably problems with many applications (such as MythTV)... and it results 
[12:25] <diwic> JeanPijon, how come that MythTV does not support ALSA?
[12:26] <joaopinto> diwic, from the bug report, "It turns out this OSS garbage is responsible for my (cx8801) TV tuner cards' being able to capture audio from analog cable."
[12:27] <JeanPijon> joaopinto, diwic, so it results to the way NOT to update any kernel, until those applications will be rewrited:(
[12:28] <diwic> joaopinto, so is it the hardware or the software that does not support ALSA?
[12:30] <diwic> joaopinto, googling both MythTV and CX8801 it seems like there is support for ALSA on both sides.
[12:30] <diwic> JeanPijon, or help us fix the problems with ALSA
[12:31] <JeanPijon> diwic: Sure, but I don't think I am the right person to code the kernel:(
[12:32] <diwic> JeanPijon, you can at least file bugs for your issues and help out with testing if we come up with a fix
[12:33] <JeanPijon> diwic: Absolutely right, I will try, but again, there is no possibility for now, except to recompile own kernel with that modules enabled...
[13:00] <apw> smb, whats the status of: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/669496
[13:00] <ubot2> Launchpad bug 669496 in linux (Ubuntu) "natty kernel fails to mount root on ec2 (affects: 1) (heat: 210)" [Critical,Confirmed]
[13:01] <apw> smb, seems it is on the release meeting agenda
[13:51] <smb> apw, It seems to affect only i386 and amd64 with t1.micro. Unfortunately when it fails it usually gives no logs at all. jj had captured some but I have to check whether he attached them to the bug
[14:02] <jtapas> Hi on this thread https://lists.ubuntu.com/archives/kernel-team/2010-November/013541.html I was suggested to join this IRC
[14:09] <apw> jtapas, hi you are interested in helping with kernely things i think
[14:10] <apw> this is the place where all those interested in ubuntu kernely things hang out
[14:10] <apw> so you are in the right place
[14:13] <apw> smb, ok so i'll write that up as a limited exposure and testing still possible, investigation continuing
[14:13] <smb> apw, sounds good to me. I am just now updating the bug as well with that facts
[14:17] <jtapas> yes
[14:17] <jtapas> @apw
[14:17] <jtapas> yes I am interested in developing or doing kernely things
[14:18] <apw> jtapas, so i guess the question is what sort of things are you interested.  we have lots going on
[14:18] <jtapas>  I like network sort of things
[14:18] <smb> I believe he mentioneed wireless
[14:18] <apw> ranging from initial triage of bugs through to patching and upstreaming patches
[14:18] <jtapas> ya
[14:18] <jtapas> wireless is one thing that does fascinates me
[14:18] <jtapas> the only hardware I have is 
[14:18] <jtapas> my laptop
[14:19] <apw> ok well if you are interested those kinds of things then i think we do tag bugs which are related to that
[14:19] <jtapas> ok
[14:19] <apw> is it kernel-wireless ?  i forget exactly
[14:19] <smb> jtapas, This is not uncommon when looking at bugs
[14:19] <smb> We rarely have the hardware ourselves
[14:19] <apw> you might want to have a poke about in those and see what you can help wil
[14:19] <apw> with ...
[14:19] <apw> cirtainly one learns a lot about a thing by looking at the bugs there
[14:20] <jtapas> I do not know if i am right or wrong but I feel that to have a fix or
[14:20] <jtapas> driver u need to have that hardware
[14:20] <jtapas> is that not the case
[14:20] <smb> This is where talking to people comes into play. :)
[14:20] <jtapas> ok
[14:20] <jtapas> so how can I start with
[14:21] <jtapas> let me know reading and reading books I have cooked myself too much
[14:21] <jtapas> I want to actually do some real work
[14:21] <jtapas> which u people enjoy doing
[14:22] <smb> jtapas, JFo is our "master triager" sort of. So he would know a bunch of reports grouped for people wanting to help
[14:23] <jtapas> ok JFo is it a human
[14:23] <smb> Sometimes yes and no
[14:23] <smb> He tends to run his scripts in his name but he is a human too
[14:23] <jtapas> so u mean to say that I should contact him
[14:23] <jtapas> is he on this IRC
[14:23] <apw> yeah jfo looks after our incoming bugs, and helps us find the interesting ones. he is normally here
[14:24] <smb> Right, he will be here on irc too
[14:24] <apw> hrm, but not at the moment
[14:24] <jtapas> Ok when can I expect him generally 
[14:24] <jtapas> UTC time I will be online at that time
[14:24] <smb> apw Still relatively soon in the morning his place
[14:25] <apw> smb, its 9:30 his time, not so early
[14:25] <smb> But more or less soonish. Depenends on the human factor
[14:25] <smb> apw, Maybe he was able to sleep for a change
[14:25] <apw> yeah maybe, that guy needs to relax
[14:25] <jtapas> my time zone is +0530 of UTC r u referring to UTC time at 09:30
[14:26] <apw> jtapas, he is east coast US, so i am guessing your are similar
[14:26] <smb> jtapas, It is 9:30 where he is
[14:26] <smb> So thats 14:30 UTC
[14:26] <jtapas> ok
[14:26] <apw> 'about now' :)
[14:26] <jtapas> ya :)
[14:26]  * apw incants to try and raise him
[14:26] <apw> jFo, JFo, Jfo ...
[14:27] <apw> man it worked for bloody mary on the tv last night
[14:27] <jtapas> Ok then I shall wait for the guy to let me understand where to start
[14:27] <apw> the other place to look is in our Kernel wiki, that has lots of information on how we do things
[14:27] <apw> https://wiki.ubuntu.com/Kernel/
[14:29] <jtapas> ya I had looked that page also
[14:32] <apw> the stuff on trige would help you understand what the status of bugs means etc
[14:33] <apw> and on the tagging page you should find the lists of tags we use to mark bugs
[14:33] <jtapas> ok
[14:33] <jtapas> are you referring to this page https://wiki.ubuntu.com/Kernel/BugTriage
[14:37] <jtapas> I see a lot of bugs here https://bugs.launchpad.net/ubuntu/+source/linux/+bugs
[14:38] <jtapas> but if I pick one and start doing some thing then that would not be heading to any direction
[14:38] <jtapas> since I never fixed any bug till today in my life
[14:38] <jtapas> though I wrote a char driver
[14:39] <apw> jtapas, working at the distro level generally involves digging into peoples issues, and trying to help them
[14:39] <jtapas> and at kernel level
[14:39] <apw> the other place people help is with askubuntu, which helps with things including onfiguration and usage issues
[14:40] <jtapas> how did u people started fixing such kernel bugs
[14:40] <jtapas> since all here are developers so I believe
[14:40] <jtapas> some where u must have started
[14:40] <jtapas> I will follow the same
[14:40] <jtapas> it might take time
[14:41] <jtapas> but I feel I will be able to do it with some patience and practise
[14:41] <apw> yep, i just dug into the bug list, picking out bugs I knew things about, using the source of the kernel to help understanding them and trying to fix
[14:41] <jtapas> currently I am not clear
[14:41] <jtapas> and how much time it took u to fix the first bug
[14:41] <apw> so as you like networking i would look at some in gneeral networking perhaps as you can fix those
[14:41] <jtapas> ok
[14:41] <apw> i think i fixed a few in my first week, but i was working on it full time
[14:41] <jtapas> ohh I see
[14:41] <apw> a lot of the time you find the issue is already fixed in much newer kernels
[14:42] <jtapas> hmmm
[14:42] <jtapas> did u had the devices for which u fixed the bugs
[14:42] <apw> so one can use that information to pull back the fix, or to do the equivalent
[14:42] <jtapas> Ok
[14:42] <apw> often we ask people to try newer kernels and mainline kernels from the mainline kernel archive
[14:42] <apw> to see if later kernels have a fix
[14:43] <jtapas> r u referring to vanilla kernel from kernel.org
[14:43] <jtapas> or the one from ubuntu repositories
[14:43] <apw> jtapas, yes we build those installable for ubuntu systems every day
[14:44] <apw> https://wiki.ubuntu.com/Kernel/MainlineBuilds
[14:44] <jtapas> ok
[14:44] <apw> those are made automatically as they release, and we use those as a debugging resource
[14:44] <jtapas> ok
[14:44] <jtapas> let me read that doc
[14:44] <jtapas> I will get back here once I read it
[14:50] <jtapas> ok what I understand from the link of MainlineBuilds is u apply Ubuntu specific patches to kernel which is on www.kernel.org and test
[14:50] <jtapas> if those patches work
[14:50] <jtapas> or not
[14:50] <jtapas> is that correct
[14:53] <apw> jtapas, no those kernels have our _config_ only applies
[14:53] <apw> they are useful to know if the ubuntu patches are causing an issue
[14:53] <jtapas> I did not get that
[14:54] <jtapas> why do u test your config 
[14:54] <jtapas> are u referring to the config file in arch subdirectory
[14:54] <apw> well a distro needs cirtain things turned on to be useful
[14:54] <jtapas> ok
[14:54] <apw> so we build with the ubuntu config to make sure the kernels are likely to be usable on an ubuntu root
[14:55] <jtapas> ok
[14:56] <jtapas> so let me know if this time I understand :u take a kernel from kernel.org and 
[14:56] <jtapas> give ur default config
[14:56] <jtapas> and test if it works for ubuntu
[14:57] <jtapas> if that is the case then I am curious to understand why do u do that
[14:57] <jtapas> does the kernel from kernel.org not work for Ubuntu
[14:57] <apw> the ubuntu kernel includes fixes for various things
[14:58] <apw> sometimes those things fix the person they are intended for, but break someone else
[14:58] <apw> so sometimes a failure can be related to a fix we carry above and beyond the base point
[14:58] <jtapas> these are ubuntu kernels?
[14:58] <jtapas> ok
[14:58] <apw> the mainline kernels are mainline virgin trees, configured for ubuntu
[14:58] <jtapas> ok
[14:58] <apw> used as testing points.  they allow testing without our patches, and on newer versions than our stock kernels
[14:58] <apw> both are useful
[14:59] <jtapas> ok
[14:59] <jtapas> on that page it is mentioned u built 4 sets 
[14:59] <jtapas> of kernels
[14:59] <jtapas> 2 from Linus's tree and
[14:59] <jtapas> 2 from DRM
[15:00] <jtapas> what  is the difference between the two
[15:00] <jtapas> are these both different kernels
[15:00] <jtapas> I have compiled kernels in past
[15:00] <jtapas> but I never came across such thing
[15:00] <jtapas> Linus's tree and DRM
[15:00] <jtapas> development repositories
[15:11] <apw> linus tree is the master upstream repository
[15:11] <apw> from that we build each release he does (ie each tag) and we also build a random daily
[15:11] <apw> snapshot, ie whatever is in the tree at 10am UTC every day
[15:12] <apw> the other two are maintainer trees for sub-systems we care about a lot
[15:12] <apw> in this case two graphics trees.  they contain stuff likely to be in the next release from linus, but before he gets them
[15:12] <apw> so we can see if there is anything coming which may help us
[15:13] <jtapas> ok
[15:13] <jtapas> I checked this page https://wiki.ubuntu.com/Bugs/HowToTriage/Charts
[15:14] <jtapas> the laptop I have I use it in my work place also
[15:14] <jtapas> if I try these new kernels and bug fixing on
[15:14] <jtapas> a virtual machine would that be fine
[15:14] <jtapas> or I need do all on the bare metal
[15:18] <apw> jtapas, some of us do testing in VMs too
[15:18] <apw> specially in early cycle like now when the release is not very stable
[15:20] <jtapas> ok
[15:22] <jtapas> since I am new also so I will take some time to understand all this but I am happy that at least I am heading in some direction
[15:23] <jtapas> you mentioned above in coversation ubuntu specific __config_ files
[15:23] <jtapas> applied to mainline kernel so can you give me 
[15:23] <jtapas> link to those configurations which exactly you are pointing to
[15:24] <jtapas> I want to see what is ubuntu specific __config_ in Ubuntu's situation and how is it
[15:24] <jtapas> different from the mainline kernels config files
[15:37] <ogasawara> smb: thanks for testing Dapper
[15:38] <smb> ogasawara, No problem, its installed so its not much effort
[16:28] <apw> http://people.canonical.com/~platform/workitems/natty/canonical-kernel-team.html
[16:29] <apw> cking, ^^
[16:41] <apw> tgardner, i have a couple of config changes i want to put in the same one
[16:42] <tgardner> apw, you have time to roll it? you're nearing EOD.
[16:42] <apw> yeah no problem
[16:42] <tgardner> take it away...
[16:43]  * ogasawara bails for appt, back in a bit
[16:54] <smb> sconklin, bjf Pushed and uploaded a lucid-ec2 package which is rebased to the phase2 lucid kernel
[16:55] <smb> jjohansen, And btw realized that there is nothing to do for Maverick \o/
[16:55] <bjf> smb, thanks though i have no idea what the "phase2 lucid kernel" is
[16:56] <smb> bjf, The one you have currently in proposed and has the reverts. Hey I am just using your new wording. ;-P Or is that phase 0 and 1? ;-)
[16:57] <tgardner> smb, oh, crack week v.s. stable week
[16:57] <JFo> apw, want to plan a chat on Monday (morning for me)?
[16:57] <apw> JFo, can do
[16:58] <JFo> cool
[16:58] <apw> ping me when you get in
[16:58] <JFo> will do
[16:58] <smb> tgardner, Yes
[16:58] <sconklin> tgardner: verification kernel vs. testing kernel.
[16:59] <smb> sconklin, I think that is the same with less opinion
[17:02] <jtapas> JFo I was suggested you are "master triager" sort of here ,I am some one who wants to contribute to bug fixing etc on wireless area and kernely things on Ubuntu can u say some thing about this I had been waiting for you to come online
[17:02] <JFo> hey, sure
[17:02] <JFo> sorry about that. Sometimes I don't realize IRC isn't up for a while(happens often in the AM) :)
[17:03] <JFo> any specific portion of the kernel interest you jtapas?
[17:03] <jtapas> I want to do some thing on wireless area also I was looking at many links
[17:03] <jtapas> https://blueprints.launchpad.net/ubuntu/+spec/cloud-server-n-ec2-cluster-compute
[17:03] <jtapas> and the above link seemed interesting to me
[17:04] <jtapas> though not sure as what I can contribute at this point of time
[17:04] <jtapas> wireless does appeal me
[17:04] <JFo> no problem, there are many ways to contribute
[17:04] <JFo> excellent
[17:04]  * JFo looks at the BP
[17:04] <jtapas> I want to do bug fixing 
[17:04] <jtapas> on such areas
[17:05] <JFo> excellent! I am happy to have you here then :)
[17:05] <jtapas> yea :) but I am just beginner and it will take me time
[17:05] <jtapas> to understand things and then to be able to 
[17:05] <jtapas> actually contribute some thing worth
[17:05] <jtapas> may take time
[17:05] <jtapas> I am a bit slow learner
[17:05] <JFo> smb is our kernel server liason and jjohansen to a degree, so they will have the most info on that relationship
[17:05] <JFo> that's ok
[17:05] <jtapas> ok
[17:06] <JFo> those things worth doing sometimes take time :)
[17:06] <jtapas> ok
[17:06] <smb> This blueprint is about images for amazon ec2, nothing wireless there
[17:06] <jtapas> so I have been reading  lot of wiki pages here
[17:06] <jtapas> on Ubuntu kernel pages
[17:06] <JFo> excellent
[17:06] <JFo> smb, yeah
[17:06] <smb> In general I don't think blueprints are a place to start when one wants to do bugs
[17:06] <jtapas> ok
[17:06] <JFo> I agree
[17:06] <JFo> but that is ok
[17:07] <JFo> we can look at some bugs :)
[17:07] <jtapas> yea
[17:07] <jtapas> I did had looked the Kernel Wireless page
[17:07] <jtapas> but that redirects outside
[17:07] <jtapas> the Ubuntu domain
[17:07] <jtapas> http://wireless.kernel.org/en/users/Documentation/Reporting_bugs
[17:07] <jtapas> to the above page
[17:07] <JFo> jtapas, have you looked at the Triage pages found here:https://wiki.ubuntu.com/Kernel/BugTriage ?
[17:07] <jtapas> yes
[17:07] <jtapas> I did looked and the mail 
[17:07] <JFo> excellent
[17:08] <jtapas> also in which the questions were answered
[17:08] <jtapas> I want to start with some thing easy
[17:08] <JFo> ok
[17:08] <jtapas> that will take me some time to understand
[17:08] <JFo> hmm
[17:08] <jtapas> so if you think you can give me one such bug I want to
[17:08] <JFo> let me see...
[17:09]  * smb thinks wireless and easy are slightly orthogonal. But that is just my opinion
[17:09] <jtapas> ok
[17:09] <JFo> are you wanting to learn about how wireless works in the kernel or try to help with wireless misconfiguration on bugs?
[17:09] <JFo> I would agree with smb
[17:09] <jtapas> I want to do some thing kernely
[17:09] <jtapas> and wireless seemed promising to me
[17:09] <jtapas> so I asked
[17:10] <JFo> by that you mean development?
[17:10] <jtapas> ya
[17:10] <jtapas> exactly
[17:10] <JFo> ok
[17:10] <JFo> let me see...
[17:11] <JFo> so, in order to ensure we are all on the same page...
[17:11] <JFo> I just wanted to mention that 'wireless' really covers a lot of ground
[17:11] <jtapas> ok
[17:12] <JFo> and is mainly handled by the modules themselves that are created and provided by outside companies
[17:12] <jtapas> ohh
[17:12] <jtapas> it is not some thing specific to Ubuntu
[17:12] <JFo> smb, correct me anywhere here if you see that I am wrong
[17:12] <JFo> jtapas, no, it is specific to the overall kernel itself
[17:12] <jtapas> ok
[17:12] <JFo> and is different in each of the modules
[17:12] <jtapas> ok
[17:13] <JFo> hence my question about whether you wanted that or helping to fix misconfiguration etc.
[17:13] <jtapas> I do want that 
[17:13] <jtapas> development
[17:13] <jtapas> it may take time for me to understand
[17:13] <jtapas> but do not worry about that part
[17:13] <JFo> In many cases (those that we have the most issues with) the driver  is messy
[17:14] <jtapas> ok
[17:14] <JFo> I'm not worried :)
[17:14] <JFo> I just want to give you the best information
[17:14] <jtapas> ok :) u mean messy to misconfiguration
[17:14] <jtapas> ya ya right
[17:14] <JFo> and point you in the right direction
[17:14] <jtapas> ok
[17:14] <JFo> well, that and the code is very questionable in some cases
[17:14] <jtapas> ok
[17:15] <JFo> meaning that over time they have done things to make bits work that didn't improve the overall quality of the code
[17:15] <JFo> not that they are bad
[17:15] <jtapas> ok
[17:15] <jtapas> ok
[17:15] <JFo> just that many of them would require a rewrite to be improved
[17:15] <JFo> which is a major undertaking
[17:15] <jtapas> ya that will be a good start
[17:15] <JFo> but I digress
[17:16] <jtapas> ok
[17:16] <JFo> so, the kernel handles pretty much all modules it loads the same
[17:16] <jtapas> ok
[17:16] <phetips> can anyone tell me why this is happening when i try to load my module? http://pastebin.com/55dBXeKE
[17:16] <JFo> the difference is to do with what the module does or controls
[17:16] <phetips> module source: http://pastebin.com/asn5Bt9p
[17:16] <phetips> makefile: http://pastebin.com/30c5WLHU
[17:17] <jtapas> ok
[17:17] <JFo> but it is not entirely that simple either
[17:17] <vanhoof> JFo: btw, it has to be that ~kernel-bugs had its list removed.  I just removed myself from ~u-k-t, and what'dya know, everything works again
[17:17] <jtapas> ok
[17:17] <JFo> vanhoof, hmmm
[17:17] <JFo> but you had to remove yourself from u-kt though
[17:18] <JFo> sounds odd
[17:18] <vanhoof> JFo: i think i found that 'crackhead' stuff you mentioned, which also happened on the 5th
[17:18] <JFo> jtapas, give me one sec to check something
[17:18] <jtapas> ok
[17:18] <JFo> vanhoof, yeah, I think something there is what did it
[17:18] <vanhoof> I see that in my 'Indirect' folder
[17:18] <vanhoof> Vishnu (vishnuvishnu.2012) added Kernel Bugs (kernel-bugs) (which you
[17:18] <vanhoof> are a member of) as a member of sljdg (hjgf). <https://launchpad.net/~hjgf>
[17:19] <JFo> yep, that's the stuff
[17:19] <vanhoof> all on the 5th
[17:19] <phetips> i keep getting the following when trying to build my module: WARNING: "kallsyms_lookup_name" [/home/daan/Code/Phrack/phrack.ko] undefined!
[17:19] <JFo> looks like someone was trying to escalate privilege in the groups
[17:19] <phetips> and this when trying to load it: Unknown symbol kallsyms_lookup_name
[17:19] <JFo> may have succeeded
[17:19] <phetips> i am pretty sure i included the right header (linux/kallsyms.h)
[17:20] <phetips> and my kernel also exports the symbol
[17:20] <JFo> bdmurray, I'm still getting the mail. Any ideas?
[17:20] <vanhoof> JFo: ~k-bugs was never set to the list
[17:20] <vanhoof> JFo: i dont think bdmurray can set it
[17:20] <JFo> I just want to know where it is suddenly coming from and nuke whatever that is
[17:20] <JFo> :)
[17:21] <bdmurray> And I'm telling you set the email address for the team to k-bugs
[17:21] <bdmurray> I can't do it since I'm not in ubuntu-kernel-team - they are the owner of kernel-bugs
[17:21] <JFo> bdmurray, k-bugs@l-u-c?
[17:21] <JFo> oh ok
[17:22] <JFo> sorry, that must have been after my brain scramble yesterday
[17:22] <bdmurray> yes, set the email address to kernel-bugs@lists.ubuntu.com
[17:24] <JFo> k, done
[17:24] <JFo> but apparently there is a confirmation sent
[17:24] <JFo> and I am not subscribed to the list
[17:25] <JFo> wonder how that will work out :)
[17:25] <JFo> ok, moving on
[17:25] <JFo> jtapas, apologies
[17:25] <jtapas> no problem
[17:25] <JFo> so, it is not entirely as simple as generically handling modules
[17:25] <jtapas> what I understand from ur conversation till now is
[17:25] <jtapas> to be able to start some where
[17:25] <jtapas> this will be a good warm up
[17:25] <JFo> I think so, ye
[17:25] <JFo> err yes
[17:25] <jtapas> that way when I jump to actual bug fix etc
[17:26] <jtapas> I will be able to do some thing
[17:26] <JFo> indeed
[17:26] <jtapas> so that is fine with me
[17:26] <jtapas> even I want to start with some thing that I can at this point understand
[17:26] <jtapas> this is a time consuming process and needs
[17:26] <jtapas> practise I feel
[17:26] <JFo> and once you get the idea of the scope of the bugs, you will have a better understanding of the wireless modules once you start looking at them from a dev standpoint
[17:26] <jtapas> so do give any link
[17:26] <jtapas> right
[17:27] <jtapas> so go ahead and give links which you feel I should be starting 
[17:27] <jtapas> at least I begin some where
[17:27] <JFo> so here are the bugs that I have tagged kernel-net already: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=kernel-net
[17:28] <JFo> those bugs should be a good place to look for bugs about networking and wireless
[17:29] <jtapas> ok
[17:30] <JFo> sorry, got pinged in another channel
[17:30] <jtapas> just one question I was looking at this page
[17:30] <jtapas> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tags_combinator=ALL&field.tag=kernel-net+kernel-needs-review
[17:30] <JFo> :)
[17:30] <jtapas> what is the difference between the link you gave and I gave
[17:30] <JFo> right, that is probably going to become obsolete
[17:30] <JFo> that is the list of bugs up for review by the team in my weekly bug meeting
[17:31] <jtapas> ok
[17:31] <JFo> but we are changing what we look at 
[17:31] <jtapas> ok
[17:31] <JFo> so that will probably go away
[17:31] <jtapas> so the link which you gave needs improvement in quality of code
[17:31] <jtapas> the way it is written is not very well as I understand this
[17:31] <jtapas> from this conversation
[17:31] <JFo> jtapas, no. The link I gave are just the bugs I have tagged as relating to kernel-networking
[17:32] <jtapas> ok
[17:32] <jtapas> ok
[17:32] <JFo> they are for all types of net bugs
[17:32] <jtapas> ok
[17:32] <JFo> some are things we can fix, some are not
[17:32] <jtapas> ok
[17:32] <JFo> but in all cases there is a minimum amount of information needed before the bug is ready to be looked over
[17:33] <JFo> and to be fair, some will never get looked at
[17:33] <jtapas> ok
[17:33] <JFo> there are over 6,000 bugs filed on the kernel
[17:33] <JFo> and there is a team of less than 20 people
[17:33] <JFo> so you see where the math is going
[17:34] <jtapas> oh 
[17:34] <jtapas> right
[17:34] <JFo> I think the best thing for you would be to start in that list I gave you
[17:34] <jtapas> ok
[17:34] <jtapas> do I need to mail on the lis
[17:34] <jtapas> t
[17:34] <JFo> and begin to understand the problems these reporters are encountering
[17:34] <jtapas> ok
[17:34] <JFo> mail on the list for what?
[17:34] <JFo> I didn't understand thatr
[17:34] <jtapas> wait
[17:34] <JFo> k
[17:34] <jtapas> I forgot the link
[17:34] <JFo> :)
[17:34] <jtapas> let me get back I am searching
[17:35] <JFo> ok
[17:38] <JFo> vanhoof, I had to subscribe to the team list. I am now trying to change the team e-mail
[17:38] <JFo> :-/
[17:38] <JFo> vanhoof, will let you kow how it goes
[17:38] <jtapas> this is the link I was talking about https://lists.launchpad.net/ubuntu-bugcontrol/msg00715.html
[17:39] <jtapas> I got above from here https://wiki.ubuntu.com/UbuntuBugControl
[17:39] <jtapas> with a sentence Application from Yofel
[17:39] <jtapas> do I need to do a similar mail
[17:39] <JFo> jtapas, ah, that is the bug control team. You can only become a member of that once your basic triaging skills have been verified
[17:39] <jtapas> ok
[17:39] <vanhoof> JFo: cool man
[17:40] <jtapas> for that I need to download understand and commit changes
[17:40] <JFo> so there must be a body of work in order to review what you have done and your understanding of the policies
[17:40] <jtapas> ya ya right
[17:40] <JFo> jtapas, no
[17:40] <jtapas> then
[17:40] <JFo> for that you need to triage bugs for the developers ofr a while
[17:40] <JFo> and then submit an application
[17:41] <JFo> via e-mail to become bug control
[17:41] <jtapas> I think that would come at a later part once I start understanding such stuff
[17:41] <jtapas> and be able to deliver some thing
[17:41] <JFo> yes, so you see there are several steps before you can start committing changes to code
[17:42] <jtapas> ok so suppose I choose one bug
[17:42] <JFo> and I think looking over those bugs is the best start
[17:42] <jtapas> I do not have the hardware for that
[17:42] <jtapas> and I need to pull down the kernel 
[17:42] <jtapas> and start understanding the bug
[17:42] <jtapas> and make some changes is this how the process will work
[17:42] <JFo> no
[17:42] <JFo> first, you look here https://wiki.ubuntu.com/Bugs/HowToTriage
[17:43] <JFo> next you look at those bugs on the link I gave you
[17:43] <jtapas> ok
[17:43] <JFo> and get them to a good triaged state that can be worked from
[17:43] <jtapas> oohh okk
[17:43] <JFo> once you have done that for a bit
[17:43] <jtapas> I was confused about this part only
[17:43] <JFo> then you can go for Bug Control
[17:43] <jtapas> ok that makes it clear
[17:44] <JFo> but the main thing here is that you get an idea of the issues that are being reported
[17:44] <JFo> before you start looking at code... or even while you are looking at code so that you understand
[17:44] <jtapas> ya ya that I am doing
[17:44] <jtapas>  I was reading I2C protocol
[17:44] <jtapas> and related drivers today 
[17:45] <jtapas>  I had looked at many other sort of drivers
[17:45] <JFo> if you see something you think you can fix, you can submit a patch to the kernel mailing list for a review
[17:45] <jtapas> ok
[17:45] <jtapas> right
[17:45] <JFo> but understand
[17:45] <jtapas> ok
[17:45] <JFo> if you want to do fixes on those systems, you will need to understand and use the upstream patch submission process 
[17:45] <JFo> because we pull the vast majority of our fixes from upstream
[17:46] <JFo> meaning Linus and the maintainers
[17:46] <JFo> via the stable tree
[17:46] <jtapas> Ok
[17:46] <JFo> as maintained by Greg K-H
[17:46] <JFo> so, what I want to do
[17:46] <JFo> is give you the data to begin understanding these bugs
[17:47] <jtapas> ok
[17:47] <rtg__> bjf, do you keep your email sent folder? If so, look for "ALSA: HDA: Apply SKU override for Acer aspire 7736z"
[17:47] <JFo> so that when you begin submitting patches, you will have the best information
[17:47] <jtapas> ok
[17:47] <JFo> make sense?
[17:48] <bjf> rtg__, i do and that is not in my sent folder
[17:48] <JFo> jtapas, does that make sense?
[17:48] <rtg__> bjf, hmm, I distinctly remember you complaining to David that his second patch did not apply (but that was back in October)
[17:49] <bjf> rtg__, i remember that as well, let me look
[17:50] <jtapas> hi sorry I was copying the text
[17:50] <jtapas> of chat 
[17:50] <jtapas> from beginning yes that makes sense
[17:50] <JFo> heh
[17:50] <bjf> rtg__, the title is "Acer aspire 7736 - Playback not working"
[17:50] <JFo> good idea
[17:51] <rtg__> bjf, ah, cool. I was searching on the wrong subject
[17:51] <jtapas> JFo I was making a backup of the links u gave and conversation to look back
[17:51] <JFo> great idea
[17:51] <jtapas> I am clear with this and I will get back here 
[17:51] <jtapas> let me see what I can do
[17:51] <JFo> ok
[17:51] <jtapas> thnkx for the information
[17:51] <bjf> rtg__, looks like you applied it
[17:52] <JFo> jtapas, my pleasure
[17:52] <JFo> I am normally here, unless I have forgotten to open my IRC client after an update reboot like last night :)
[17:52] <JFo> so feel free to stop in and ask questions jtapas :)
[17:53] <rtg__> bjf, yes, but sconklin  was hassling me about missing Acked-by....
[17:53] <JFo> heh
[17:53] <JFo> that sconklin, what a harsh taskmaster
[17:53] <JFo> :-P
[17:53] <bjf> rtg__, so do you know if this patch was tested by diwic against maverick
[17:54] <JFo> grabbin lunch, bbiab
[17:54] <sconklin> JFo: I am a quick student
[17:54] <JFo> sconklin, :-D
[17:54] <rtg__> bjf, one wouls assume, but I guess that'll shake out during verification week.
[17:56] <jtapas> sure thanks JFo I have been poking into kernel and drivers
[17:56] <rtg__> sconklin, updated Maverick master-next.
[17:56] <jtapas> from some time
[17:56] <sconklin> rtg__: thanks
[17:56] <jtapas> the idea to actually start some thing came recently
[17:56] <jtapas> and I do want to do some thing 
[17:56] <jtapas> like if some one opens a driver file 
[17:56] <jtapas> then I see peoples email id mentioned in that I wish I can be one of those :)
[17:57] <jtapas> it is very appealing and I did not knew
[17:57] <jtapas> that an OS as Ubuntu which is highly popular
[17:57] <jtapas> has only 20 people in their kernel bug fixing team
[18:02] <rtg__> JFo, whats with all these initramfs-tools bugs? Are they asa result of that udev regression?
[18:03] <JFo> rtg__, no idea, but I will look 
[18:04] <rtg__> JFo, there appear to be dozens of them.
[18:04] <JFo> what is the udev regression? got a bug link?
[18:04] <JFo> I'll compare the behavior in them to that
[18:05] <rtg__> JFo, dunno. maximilian attems has been telling most of the folks with this bug that their disk is full. I'm having a hard time buying that.
[18:06] <JFo> yeah
[18:07] <smb> rtg__, Are those kind of the failed to boot after upgrade because the initrd is bad?
[18:08] <rtg__> smb, https://bugs.launchpad.net/bugs/572083
[18:08] <ubot2> Launchpad bug 572083 in initramfs-tools (Ubuntu) "package initramfs-tools 0.92bubuntu78 failed to install/upgrade: (affects: 1) (heat: 6)" [Undecided,Invalid]
[18:09] <smb> would help if most of the message was *not* is Russian
[18:10] <JFo> one of them is in spanish
[18:10] <JFo> which isn't AS bad
[18:10] <JFo> but still
[18:10] <rtg__> smb, how about https://bugs.launchpad.net/bugs/577205
[18:10] <ubot2> Launchpad bug 577205 in initramfs-tools (Ubuntu) "package initramfs-tools 0.92bubuntu78 failed to install/upgrade: (affects: 1) (heat: 15)" [Undecided,New]
[18:10] <JFo> my spanish is old
[18:11] <smb> rtg__, Though some people tend to have /boot as a separate small partition
[18:11] <smb> and having lots of abi bumps tends to fill that
[18:12] <rtg__> but that many? I've seen him reply to dozens of folks like that over the last several days.
[18:13] <smb> Its probably visible in the install log .gz which I have not looked into
[18:13] <JFo> rtg__, that last one was opened in May
[18:13] <smb> And we may just have reached a critical / common level of multiple kernels
[18:14] <rtg__> JFo, why haven't they been expired if they're that old?
[18:14] <smb> the computer janitor would bring you down to 4 but its not automatic
[18:14] <JFo> rtg__, I suspect due to them not having been properly triaged
[18:14] <JFo> I have not looked at anything other than linux bugs for a while
[18:15] <JFo> which reminds me... we need to nail down the list of packages you guys want me to report on/triage
[18:15] <JFo> so that I am working the right ones
[18:15] <JFo> I think I am missing some (like this one)
[18:16] <rtg__> JFo, we don't own this one. I just thought it was interesting that there were so many reports.
[18:16] <JFo> ah
[18:16] <JFo> whew, thought I was failing you guys :)
[18:16] <JFo> well failing worse than normal that is
[18:24] <Nafallo> hmm. have we got any reports of bluetooth disappearing with the latest kernel?
[18:26] <rtg__> JFo, how can I get a list of bugs with patches attached? Preferably for bugs that are not fix-committed, etc.
[18:30]  * Nafallo bets it's just his hardware being old and grumpy.
[18:44]  * smb -> EOW
[18:50]  * JFo looks
[18:51] <JFo> rtg__, see if http://goo.gl/TpbSJ meets your needs
[18:54] <rtg__> JFo, yeah, looks good. thanks.
[18:54] <JFo> my pleasure
[19:00]  * rtg__ lunches
[19:18]  * cking calls it a day
[19:37] <rafiyr> How hard is it to disable a specific acpi gpe interrupt from the boot command line?
[19:43] <JFo> rafiyr, I'd ask cking, but he is gone for the day
[19:43] <rafiyr> JFo: Thanks
[19:45]  * ogasawara lunch
[19:47] <JFo> rafiyr, my pleasure
[20:07] <julius__> hi
[20:07] <julius__> is thre any reason why theres still the outdated rt2870sta staging driver?
[20:08] <julius__> its from 2008 i think v 2.1.0.0
[20:09] <julius__> the new one from ralink site is 2.4.0.1
[20:09] <julius__> from 2010
[20:09] <julius__> it improves the wireless reliability and speed a lot
[20:11] <kees> apw, tgardner: if you're going to do another natty kernel publication before -rc3, can you include 8e35f8e7c61c88f9a979a4e6f7f4ffd4c158a88a ? This seems to fix my NFS regressions.
[20:12] <kees> (I will send email too)
[20:16] <tgardner>  kees - its already upstream, right? I'm pretty sure apw will rebase against current tip
[20:16] <kees> tgardner: yeah, it's already in linus's tree. I just wasn't sure what your schedule was for publishing to natty
[20:17] <tgardner> kees - he was thinking about rolling a version to fix a KVM regression
[20:17] <kees> works for me :)
[20:34] <komputes> Hi kernel folks, I am trying to patch the 2.6.32-25 kernel with Mike Galbraith's recent sched patch, but I need some help with rejected hunks
[20:34] <komputes> JFo: ^ you free to assist?
[20:47]  * jjohansen lunches
[20:56] <komputes> I will try with a newer kernel
[20:56] <komputes> later y'all