[00:12] <Kano> hi, did anybody port snd-bt-sco to 2.6.28 yet?
[00:12] <johanbr> that's been deprecated for a long time
[00:13] <Kano> and is the new varinat working or not
[00:13] <Kano> as that required a kernel patch too
[00:13] <johanbr> works for me
[00:14] <Kano> whats the package with the client tool
[00:17] <johanbr> bluez... at least in jaunty
[00:18] <Kano> will take a look
[09:27] <emgent``> hello.
[13:28] <Kano> hi rtg 
[13:29] <rtg> Kano: 'morning
[13:29] <Kano> are you working on 2.6.28.2 yet?
[13:30] <rtg> yep, just haven't pushed it yet as its an ABI bump
[13:30] <amitk> rtg: when do you expect to push?
[13:30] <Kano> i know, i have got a new alsa workaround
[13:30] <Kano> just need to find the correct postition
[13:30] <Kano> who was the alsa maintainer here?
[13:31] <rtg> amitk: likely today. I'm traveling beginning Wednesday, so if I don't get it started soon, I won't get all the packages uploaded in time.
[13:31] <rtg> Kano: what is the alsa workaround?
[13:32] <Kano> http://www.alsa-project.org/db/?f=bf479d3ab19f7ac37f7c1a17d4d4210de8fe5e1c
[13:32] <Kano> this system needs model=laptop
[13:32] <Kano> to get the mic working
[13:33] <rtg> Kano: you need to talk to TheMuso about patches in user space.
[13:34] <Kano> i created other alsa patches already, just to need to remember the correct postition
[13:34] <Kano> sometimes it is easy when you can use other patches as example
[13:37] <Kano> you still have got snd-bt-sco in media but not enabled it seems
[13:38] <Kano> well it must be in connexant file it seems
[13:40] <Kano> will test it
[13:41] <Kano> there are already some other hp workarounds in there
[13:47] <`emgent`> BenC: around ?
[13:49] <`emgent`> there is a critical problem in hardy kernel, some times dhcp association with ethernet card (driver r8169) work and some times not.. i found a fix in kernel.org GIT
[13:49] <`emgent`> http://git.kernel.org/?p=linux/kernel/git/jgarzik/netdev-2.6.git;a=commitdiff;h=523a609496dbc3897e530db2a2f27650d125ea00;hp=e93dcb11dd6468000f2f018bd887e94b074ce931
[13:49] <`emgent`> someone can take a look ?
[13:49] <Kano> http://kanotix.com/files/kernel/unused-patches/2.6.28-patch_conexant-hp_dv6700.diff
[13:49] <Kano> most likely that,but will do a test 
[13:50] <`emgent`> kanotix ?
[13:50] <`emgent`> O_o
[13:51] <`emgent`> BenC: anyway when you have time take a look danke.
[13:53] <Kano> rtg: can you push it now? i dont want to compile -5 kernel and then -6 again...
[14:03] <smb_tp_> `emgent`, Do you have a lp bug number for that?
[14:05] <`emgent`> smb_tp_: no, and i dont have a lp account here.
[14:05] <`emgent`> i'm at work and i'm involved in a project based on ubuntu hardy.
[14:05] <`emgent`> so, i found bug and fix..
[14:08] <rtg> amitk: I pushed 2.6.28-6.16. How long does it take you to test build an ARM kernel?
[14:08] <smb_tp_> `emgent`, do you have an account privately? if not I file one but it would be good if you could then mail me a bit more information about it.
[14:09] <Kano> rtg: thanks, will add my patch and compile
[14:10] <rtg> NCommander: whats the story on this ARM kexec patch that Rusty is objecting to?
[14:14] <amitk> rtg: too long
[14:14] <amitk> rtg: are there config changes?
[14:15] <rtg> amitk: ok, I'll just take a chance that ARM will actually compile. it takes me about 10 hours to build a test kernel.
[14:15] <`emgent`> smb_tp_: ya i have an account. I'm Master Of Universe Ubuntu Devel.
[14:15] <amitk> wasn't infinity giving us a porter machine or two
[14:15] <rtg> amitk: no config chnages that I'm aware of.
[14:15] <rtg> amitk: yes, I thought the porter was gonna be ready any day now.
[14:16] <rtg> amitk: do you have an opinion on this kexec patch that I took on faith from NCommander? Is it really borked  as Russel says?
[14:17] <smb_tp_> `emgent`, Great, if you could create a report later and assign it to me stefan-bader-canonical, so we have something to track the stable updates process, that would be awesome.
[14:17] <`emgent`> ya will do when i'm back to home.
[14:17] <amitk> rtg: yes. Which is why I forwarded it to arm list for comments. I would say, revert it for now.
[14:18] <`emgent`> smb_tp_: danke.
[14:18] <smb_tp_> `emgent`, bitte
[14:18] <rtg> amitk: done. I thought it had been tested and worked.
[15:03] <MalikLamin> hi guys, I need to make my helloWorld driver works on my kernel, its version is  2.6.27-9, it should printk helloworld at the module init, I guess it is the version dependency
[15:04] <MalikLamin> could someone help me
[15:16] <MalikLamin> i  'd like to write a module wich is intended to work in multiple versions of the kernels , how do I solve the version dependency????
[15:20] <mjg59> You can't build a module that will work with all kernel versions
[15:20] <mjg59> It has to be recompiled against the target kernel
[15:24] <MalikLamin> yeap, but there are macros that make it possible, not for all kerns, but for some of them...
[15:24] <MalikLamin> so I dont know what is wrong with my sourcecode
[15:25] <MalikLamin> it should at least print hello 
[15:26] <MalikLamin> printk( KERN_ALERT "HELLO")
[15:42] <apw> looks to be missing a ;
[15:49] <MalikLamin> no man, not becouse of that
[16:15] <apw> so what does it say when you try and use it
[16:31] <DGMurdockIII> hey
[16:32] <DGMurdockIII> i havy a qustion about a driver
[16:32] <DGMurdockIII> that i want to be added
[17:25] <Kano> rtg: do you remember the kernel patch for alsa? it is verified now
[17:27] <rtg> Kano: there have been about a zillion alsa patches. which one in particular did you have in mind?
[17:27] <Kano> http://kanotix.com/files/kernel/unused-patches/2.6.28-patch_conexant-hp_dv6700.diff
[18:45] <apw> cking, yeah i agree, and telling the size of each set is tricky
[18:46] <cking> apw: perhaps a recap of the points is required?
[18:46] <apw> my gut is that if the other os does it that way we are less likely to have regressions turning it on, than if it did no
[18:46] <apw> indeed
[18:47] <apw> so we have a some recently released amchines which have synaptics touchpads
[18:47] <apw> when we suspend and resume those touchpads get lost, not reinitialised correctly
[18:47] <apw> bus analysis shows we are not resetting the auxillary ps/2 bus before trying to reaquire them
[18:47] <apw> and this is preventing them from being picked up
[18:48] <apw> other ps/2 mouse drivers commonly do reset before reaquiring the device on resume
[18:48] <apw> and it is suggested that drivers for other OSs do the same
[18:48] <apw> ...
[18:48] <apw> the question outstanding is how to add this reset where it is needed without breaking the existing user set
[18:48] <apw> options are:
[18:49] <apw> 1) enable it on the assumption it is benign and offer a module option/dmi list to disable it where this is wrong
[18:49] <apw> 2) leave it disabled, and add an option to enable it when required
[18:49] <apw> ...
[18:50] <apw> to my mind if it is true that commonly other OSs reset first then this should be low risk, but it is hard to know for sure
[18:50] <apw> so one option would be to enable this for Jaunty with an override available and see who hollers
[18:51] <apw> the basic question is which set is larger the set which are happy with a reset or those which will break with it
[18:51] <cking> It is something that we only know if we get a suitable amount of alpha testing
[18:51] <apw> we have two sets of information
[18:52] <apw> 1) noone has complained before and we do not have it now in our kerenls
[18:52] <apw> 2) the other OSs do do it
[18:52] <smb_tp_> my guess would be, that with 2) there never will be known whether the assumption is true because who will enable an option if nothing is wrong
[18:52] <smb_tp_> how badly will be the bad case is the question?
[18:52] <apw> yeah, going 2) is the safe route but will never tell us the answer
[18:52] <cking> This is a dilemma.
[18:52] <apw> well we might regress all synaptics touchpads out there
[18:53] <apw> i think smb_tp_'s point is quite compelling, if we go 2) we will never ever know
[18:53] <apw> if we go 1) we get shouted at an go 2) if we were wrong
[18:53] <smb_tp_> So the worst that happens is that a lot of touchpads might not work unless an option is given...
[18:53] <apw> so 1) is higher risk, but lower maintenance
[18:53] <apw> that would be the worst case yes
[18:54] <apw> planning on having a 'disable the new reset' option available
[18:54] <apw> votes?
[18:54] <cking> I am convinced that option 1) is a good idea as we have heard that other OS's do it that way 
[18:54] <apw> i feel 1) for now, with 2 as a fall back
[18:54] <smb_tp_> Hm, what about an printk to say "if your touchpads goes on strike use this option"?
[18:55] <apw> smb_tp_, we could do that
[18:55] <apw> if we believe people look at dmesg of course
[18:55] <apw> release notes perhaps too if it makes it to release
[18:55] <cking> smb_tp_: well we will see it when they report a bug :-)
[18:55] <smb_tp_> That would remove searching for users. And we could say please mail to us if that is not working. So we know whether this hits
[18:56] <cking> Also, the extra port write should be relatively benign
[18:56] <smb_tp_> apw, Release notes yes. Unfortunately who really really reads them? ;-)
[18:56] <apw> heh noone of course
[18:57] <cking> apw: This is a good opportunity to try it - it's not an SRU fix which could mess up a whole load more 
[18:58] <smb_tp_> Personally I would vote for 1) with a printk. It is nothing critically that renders a machine unusable. With the print it will be pretty obvious what ifs wrong if it goes wrong.
[18:58] <cking> Very try - it will be catagorised as a suspend/resume regression.
[18:58] <smb_tp_> Actually for Jaunty it is not a SRU, yet
[18:58] <cking> s/try/true/
[18:59] <smb_tp_> rtg, What would you think?
[19:00] <apw> ok i think we have a concensus here.  that 1) with option to turn it off and a printk warning when its on
[19:01] <cking> apw: I'm happier with that now we've thought it through
[19:01] <apw> i think if i pencil in the dmi matching code, then switching the default would be a trivial 1 bit change to the patch should it be deemed crap by release
[19:02] <cking> apw: good call
[19:02]  * smb_tp_ nods
[19:03] <rtg> smb_tp_: what do I think about what?
[19:03] <apw> ok i'll take that as the plan, and if rtg changes things, its only a 1 bit change still
[19:03]  * rtg is ripping his hair over CRDA.
[19:03] <smb_tp_> rtg, About what we discuss here. Its is something for Jaunty you know. :)
[19:04] <rtg> smb_tp_: and you want me to read 47 minutes of scroll back? 
[19:04] <apw> the short summary is that some synaptics touchpads do not work following resume if they are not reset first, the other OS apparently does so we do not
[19:05] <rtg> didn't I already see a patch for that?
[19:05] <cking> you are kidding?
[19:05] <apw> so the options are we add it and allow it to be disabled, or we allow it to be enabled, but the belief is all new synatics will need it
[19:05] <apw> where did you see a patch for that?
[19:06] <rtg> I think it came from Mario at Dell. It might already be in the Jaunty tree
[19:06]  * apw checks, but i am using very recent jaunty kernels
[19:06] <apw> mario did file the bug which you would have had email from too
[19:06] <rtg> apw: It'll come to me eventually.
[19:07] <apw> nothing since july in those drivers (patch wise)
[19:07] <apw> he has been hastling about it as some of their machines are affected
[19:08] <rtg> nothinhg in Hardy or Intrepid?
[19:08] <cking> and I've been drowning in "Critical" issues to fix it so I passed it to apw
[19:08] <rtg> and its 'hassle', no T
[19:09]  * apw goes check
[19:10]  * cking notes that the problem with dictionaries is that one needs to be able spell correctly to be able to look up the word you need to check
[19:11] <apw> indeed.  and that if you are dyslexic at all then you can't even see the error
[19:12] <rtg> apw: whats the only thing I ever hassle you about :)
[19:12] <apw> there is no obvious difference in reset handling from hardy to jaunty
[19:12] <apw> so it must be something else related i guess
[19:12] <apw> heh ... not using this channel?
[19:13] <rtg> maybe I was hallucinating, but I sure thought I remembered a touchpad reset patch.
[19:13] <johanbr> I believe you're talking about https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317270
[19:13] <ubot3> Malone bug 317270 in linux "Dell Studio XPS 16 touchpad doesn't return from resume" [Medium,In progress] 
[19:13] <rtg> anyway, a DMI based reset is fine with me.
[19:14] <apw> rtg the main question is the default, on or off
[19:14] <rtg> we should annoy upstream with it as well. they might have some thoughts.
[19:14] <apw> we are tending to on for jaunty 
[19:14] <apw> yes if we wanted to defualt on, upstream would be the first place i'd wanna send it
[19:15] <rtg> default to off for Intrepid preserving current behavior?
[19:15] <apw> we have been only asked for Jaunty
[19:15] <apw> so i wouldn't be looking to modify there, but i guess off if it went there
[19:15] <apw> and on in jaunty
[19:15] <rtg> go for it then. we have time to find regressions.
[19:15] <apw> thanks all, i call that concensus
[19:49] <ch05en> Hi, I've got a repeatable bug in the UDF filesystem that enables me to crash my box at will
[19:49] <ch05en>  If you create a file with illegal utf-8 filename and copy it over to a writeable udf filesystem you panic the box
[19:49] <laga> ch05en: report a bug and mark it as a security vulnerability
[19:49] <ch05en> ok
[19:50] <laga> i'd say ;)
[20:23] <EagleScreen> any plan to move to 2.6.29 for Jaunty?
[20:24] <rtg> no plans