[00:41] <jjohansen> -> walk
=== kamal is now known as kamal-afk
=== ericm-Zzz is now known as ericm|ubuntu
=== kamal-afk is now known as kamal
=== ericm|ubuntu is now known as ericm-afk
=== ericm-afk is now known as ericm
[08:13]  * smb pries open his eyes
[08:18] <smb> cking, g'morning
[08:18] <cking> good morning!!!
[08:19] <smb> Woah! Not so enthusiasticly :-P
[08:19] <cking> oh, ok, how about:  yawn, morning... *sigh*
[08:19] <cking> ;-)
[08:20] <smb> Ah much better :=
[08:20] <cooloney> good morning smb and cking 
[08:20] <ikepanhc> good morning
[08:20] <smb> cooloney, morning o king of SMS
[08:20] <cooloney> smb: i guess no SMS here. hehe
[08:21] <ikepanhc> smb: I read your email, what you mean is we plan to removing control*?
[08:22] <ikepanhc> smb: I look into the hardy tree, looks like netbook branch is using the same control/control.stub with master branch
[08:22]  * cking starts trawling through a load of BIOS bugs
[08:23] <smb> ikepanhc, Can you give me more context of what I said? I am not sure what exactly I wrote when. I don't think I will remove any of the control files on the master branch.
[08:24] <smb> ikepanhc, Maybe you mean my stuff about removing kernel-versions
[08:24] <smb> in your branch
[08:24] <smb> as you removed the other two files
[08:24] <ikepanhc> smb: if master branch not to remove them, I vote for not to remove them in netbook branch...
[08:25] <ikepanhc> smb: sorry for making you confusing because of changing mild
[08:26] <smb> ikepanhc, No worries. Its done later, so why not think about it. I am just a bit conservative there. As Hardy is out that long
[08:26] <smb> ikepanhc, Still you would be free to do your own thing there.
[08:26] <smb> Whatever seems better to you
[08:26] <smb> Actually the lpia branch is already different in that it checks no abi files
[08:28] <ikepanhc> smb: let me 'fdr clean' again to make sure what will happen on those three files
[08:29] <smb> ikepanhc, I guess all three will be re-created. The main reason for keeping them was to avoid a failure when you run something else. And clean is not the most obvious way to create something.
[08:32] <ikepanhc> smb: for Jaunty and later release, we need to 'fdr clean' before doing anything else, do we expect the same on hardy release?
[08:32] <ikepanhc> anything means 'debuild -S' and 'fdr binary'
[08:33] <cooloney> ikepanhc: debuild -S is a command to build source package
[08:33] <smb> ikepanhc, I would not, but more because a lot of things changed after Hardy. So I am prepared to difference there
[08:33] <ikepanhc> cooloney: I know
[08:33] <cooloney> ikepanhc: fdr bianry is for building binary package.
[08:34] <smb> ikepanhc, We need to rename cooloney to man-bot. :)
[08:34] <ikepanhc> :)
[08:36] <smb> ikepanhc, For me its just one more difference of things in Hardy compared to the later releases that I don't want to make it different as that might surprise other people. (same with Dapper)
[08:36] <cooloney> smb and ikepanhc, hehe, man-bot is more popular than bugbot
[08:37] <ikepanhc> smb: agree, so I prepare the tree again, not to remove control and control.stub this time
[08:37] <smb> cooloney, Maybe as popular as the talking office clip... >:-P
[08:37] <ikepanhc> smb: just "as it was"
[08:38] <jk-> "it looks like you're trying to package a kernel ..."
[08:39] <smb> jk-, :)
[08:39] <ikepanhc> btw, the kernel-version is re-created by kernel-wedge?
[08:40] <smb> ikepanhc, Ok. I was saying you could keep it as you like. But there actually might be a sort of dependency when using the rebase script later. And for kernel-version, yes
[08:48]  * apw thinks we should rip them out of hardy master too ...
[08:48] <apw> rend, tear, shread
[08:48] <smb> apw, Its a needless change to a working environment
[08:49] <smb> You just should not expect that an old release behaves the same as a new one
[08:49]  * apw puts his mining hat on ... "i'll get them captain"
[08:49] <apw> smb, by that measure debian commonisation back to jaunty makes no sense, but i really have no firm oppinion
[08:50] <smb> I am not really sure about Jaunty either. But at least Jaunty is more similar to Karmic and Lucid that to Hardy
[08:51] <smb> In Hardy we have custom binary build blocks which are nowhere else
[08:51] <apw> smb, if we wait long enough jaunty will fix itself :)  and no i wouldn't suggest any major changes to hardy anyhow
[08:52] <apw> though i am not sure that removing those built files would be such a big change, it has stopped a lot of error in later releases
[08:52] <smb> apw, If we wait long enough even Hardy fixes itself... All just a matter of time. :)
[08:52] <apw> heh indeed
[08:53] <ikepanhc> fixed itself.... I like it
[08:53] <ikepanhc> btw, I heard hardy netbook branch will fix itself at March 2011
[08:53] <smb> Well yes, you cannot create a source package without them rather than with the wrong files
[08:54] <smb> ikepanhc, Then you would be more lucky than me
[08:54] <smb> :)
[08:55] <ikepanhc> smb: ah, yeah, the EOL for you is to 2013
[08:55] <apw> smb when does hardy desktop support finish ?
[08:55] <apw> is that the same time as dapper comes off completely ?
[08:55] <amitk> weber finance loan company <weberfinanceloan@gmail.com> has been
[08:55] <amitk> successfully subscribed to kernel-team.
[08:56] <jk-> sweet
[08:56] <amitk> apw: ^^ what are the chances we've got a spammer
[08:56] <smb> apw, I am just thinking that there might be people out there that use the Hardy git repo as a base and might get surprised. Sure it would "just" be a educational process. But then, I usually update the files on abi bum. Or find out on my test builds...
[08:56] <smb> apw, Dapper-server goes off in Apris 2011
[08:56] <apw> smb we like supprising people on my side of "conservatism valley"
[08:57] <smb> apw, We know we live on opposite ends of that. :)
[08:57] <apw> smb, so i assume as hardy is 2 years behind, and desktop is 2 years less than server, that it goes at the saem time ?
[08:57] <apw> smb, na i live in the middle, tim lives on the other side :)
[08:57] <smb> hehe
[08:58] <smb> apw, I usually check the times on the wiki. And usually I am surprised every time I do
[08:58] <apw> smb, got a link to the support wiki ?
[08:59] <smb> http://wiki.ubuntu.com :)
[08:59] <apw> i can never find the support info ... i hate the wiki
[08:59] <smb> Hardy: Destop till Apr-2011 and Server till Apt-2013
[08:59] <apw> smb, so we do drop off desktop as we drop dapper, sweet
[09:00] <apw> smb, s
[09:00] <smb> Or even https://wiki.ubuntu.com/Releases. Right
[09:00] <apw> smb, shouldn't dapper be on that list ?
[09:00] <apw> and i note dapper says june
[09:01] <smb> apw, Remember what I said about being surprised
[09:01] <apw> well as it was a .06 that makes sense, though i had heard apr recently for it
[09:01] <smb> There is a last column on the Release page
[09:02] <smb> Oh, yeah
[09:02] <smb> Err
[09:34] <apw> gitk origin/ti-map4 ti-omap4 ^v2.6.32
[09:34] <apw> git reset --hard origin/ti-omap4
[09:37] <Sleep_Walker> hi amitk, do I understand correctly that there is currently no driver for SD and framebuffer for i.MX51 based machines?
[09:40] <cooloney> apw: are you reviewing the ti-omap4 branch?
[09:41] <apw> cooloney, not that i know of, should i be ?
[09:42] <Sleep_Walker> (in upstream)
[09:43] <apw> cooloney, oh i see, no i was helping out lag
[09:47] <cooloney> apw: got it, hehe
[09:48] <jk-> Sleep_Walker: that's correct
[09:51] <Sleep_Walker> jk-: ah, ok, well, I'm sick this week and I'd like to help a bit - any suggestions what is needed and what doesn't anyone work on?
[09:51] <jk-> Sleep_Walker: I think it's just a matter of having the time to work on it
[09:55] <Sleep_Walker> jk-: I see, I'll try to have a look on SD then
[09:55] <jk-> Sleep_Walker: yeah, that'd be my preference
[09:55] <jk-> but you may want to catch amitk first to make sure.
[10:11] <Sleep_Walker> jk-: ok, I first read some doc
[10:13] <jk-> excellent plan :)
[10:13] <Sleep_Walker> :b
[10:21] <cooloney> apw: if i change a module driver to compile it into kernel, need i remove the module name from the abi module list file?
[10:22] <cooloney> apw: is that the right way to avoid the module check failure?
[10:22] <apw> you need to do something to stop the error yes
[10:22] <apw> you can either remove it from the modules list or you can add it to modules.ignore
[10:24] <cooloney> apw: but removing is removing from the previous ABI module list file, right?
[10:25] <cooloney> apw: so after we bump abi, the new module list file of the new abi won't contain the module name which i removed, i think
[10:25] <apw> yes
[10:25] <apw> correct
[10:25] <cooloney> apw: ok, i understand. thanks
[10:36] <amitk> Sleep_Walker: correct, nothing in mainline. But I'll take patches :)
[10:50] <trapmax> during system update & restart, noticed this: http://pastebin.com/cF1TVjx1
[11:35] <Sleep_Walker> amitk: there are imxmmc.c and mxcmmc.c for other i.MX processors, can it be good start or it is mostly incompatibile?
[11:36] <apw> trapmax, that looks liek its telling you that you have queueing state for a device which is configured not to do queuing, odd
[11:39] <trapmax> apw: ok. what actions would you suggest?
=== cking_ is now known as cking
[11:57] <amitk> Sleep_Walker: Freescale have created a new file drivers/mmc/host/mx_sdhci.[ch]. You'll have to look at how much of that you can merge into the existing drivers
=== arun__ is now known as arun
[12:39] <Sleep_Walker> amitk: yeah, already reading these, but it looks like one file to all MXC MMCs
[12:39] <Sleep_Walker> amitk: that's the reason I ask
[12:39] <Sleep_Walker> I understand that it looks weird with all that "quirks", but it reduce reduntant code a lot
[12:40] <Sleep_Walker> I'll read more
[13:09] <amitk> Sleep_Walker: Do you mean that drivers/mmc/host/mx_sdhci.* essentially replaces mxcmmc.c ?
=== kentb_out is now known as kentb
[14:32]  * amitk waves to BenC 
[14:33]  * BenC waves back
=== sconklin-gone is now known as sconklin
=== _guitarm1n_ is now known as _guitarman_
[15:13] <manjo> cking, so every thing looks like a go for monday, there still is no installer though
[15:41] <shadeslayer> hey is it possible that a new kernel can disable support for middle click of external mouse?
[15:41] <shadeslayer> scrolling with the wheel works fine... its just that when i press the wheel,it doesnt register a middle click
=== bjf[afk] is now known as bjf
[16:31] <tgardner> lag, mpoirier: I wanna bounce emerald to pick up the latest LTS kernel as soon as your builds are finished.
[16:32] <mpoirier> tgardner: I'm out
[16:33] <lag> ~30mins :-S
[16:35] <lag> tgardner: Okay, do it!
[16:36] <tgardner> lag, bouncing
[16:41]  * JFo grabs some lunch before the meeting
[16:43] <bjf> ##
[16:43] <bjf> ## Kernel team meeting in 1 hour 15 minutes
[16:43] <bjf> ##
[16:49] <cking> manjo, you ok with the arrangements for testing?
[16:49] <manjo> cking, yep I think so
[17:05] <tseliot> mjg59: did you discuss with AMD the need to call the ATIF method in the radeon driver?
[17:06] <mpoirier> tgardner: are you done with emerald ?
[17:06] <mjg59> tseliot: Yes, we're still working with them on that
[17:07] <tseliot> mjg59: is there some code branch where the work is being done?
[17:07] <tgardner> mpoirier, pounding the shit out of it right now.
[17:07] <mjg59> tseliot: No
[17:08] <mjg59> We don't have permission to release any code yet
[17:08] <mjg59> From AMD, that is
[17:08] <tseliot> mjg59: ok, who is working on it at AMD?
[17:10] <tseliot> feel free to answer in private if you can't make it public
[17:11] <mjg59> Alex
[17:12] <tseliot> mjg59: ok, thanks, I'll talk to him then
=== ericm|ubuntu is now known as ericm-Zzz
[17:35] <bjf> ##
[17:35] <bjf> ## Kernel team meeting in 25 minutes
[17:35] <bjf> ##
[17:36] <apw> Keybuk, hey you about?  you said you had the union-mount tool changes somewhere.  I am looking to get those so I can test this mess :)
[17:36] <Keybuk> apw: yes, I'll get them out tomorrow morning
[17:36] <Keybuk> they were in pbuilder when my desktop decided it didn't like life anymore yesterday
[17:37] <apw> Keybuk, cool ... did you get to test the init args stuff or the ureadahead thingy ?
[17:37] <Keybuk> did you build the init args stuff?
[17:37] <Keybuk> last I looked there was no built kernel for that
[17:37] <apw> yeah ...
[17:37] <apw> hrm ... let me double check
[17:37] <Keybuk> ah you didn't tell me :p
[17:38] <Keybuk> cool, looks like all three are built
[17:38] <Keybuk> will test tomorrow
[17:38] <apw> oh both are built, they are in my red and green PPAs
[17:38] <Keybuk> yup
[17:38] <apw> i suspect the init args one is a slam dunk
[17:39] <apw> Keybuk, so many things to track, gah
[17:39] <Keybuk> aye s'ok
[17:40] <manjo> Keybuk, I cced you on a mail regarding a blue print on firewire stack I fwded to ubuntu-devel 
[17:40] <Keybuk> manjo: I don't have that mail
[17:40] <manjo> Keybuk, just did 2mts ago :) 
[17:41] <Keybuk> oh, right
[17:41] <manjo> Keybuk, all we need is blacklist the old stack and whitelist the new stack modules 
[17:41] <Keybuk> manjo: is up to the kernel folks, not me
[17:41] <manjo> Keybuk, the email has details 
[18:40] <tgardner> manjo, dpkg -S /etc/modprobe.d/blacklist-firewire.conf
[18:41] <manjo> tgardner, thanks got it 
[18:52] <smb> kamal, mail sent. Don't hesitate to ask. I might have been a bit terse
[18:54] <kamal> smb: got it -- all very clear, no problem.
[18:55] <smb> kamal, Ok, cool. Oh one addition: Please cc kernel-team list too when sending. So I know what goes out. :)
[18:56] <kamal> smb: will do
[18:56] <smb> thanks
[19:01] <kamal> mjg59: ping
[19:01] <mjg59> kamal: Hi
[19:01] <kamal> mjg59: Hi - In the ubuntu-kernel team meeting we discussed proposing your patch "ACPI: Unconditionally set SCI_EN" to stable-commits.  Your thoughts on that?  (objection?  would you like to submit it, or would you like me to?)
[19:01] <mjg59> I've no problem with you doing so
[19:02] <kamal> great, I'll do that then.
[19:02] <kamal> and while I've got you...
[19:03] <kamal> what about that i915-brightness stuff?  seems to have had no further comments on the mailing list -- what next?
[19:04]  * manjo luches
[19:04]  * manjo getting lunch will be back soon
[19:05] <mjg59> kamal: Yeah, I'll get back to that next week with luck
[19:05] <kamal> mjg59: that's just fine -- thanks very much :-)
[19:17]  * cking calls it a day
=== jcrigby is now known as jcrigby-afk
[19:51] <manjo> apw, when I push to bzr I do, cd modules-init-tools, bzr push lp:~manjo/modules-init-tools ? 
[20:06]  * ogasawara lunch
[20:11] <jjohansen> -> Lunch
[21:21] <jcastro> ogasawara: if you've got a few minutes to waste this afternoon I have some questions!
[21:25] <ogasawara> jcastro: go ahead and post em, I'm in the middle of cleaning up a patch but I'll get to them in a bit
[21:25] <jcastro> ogasawara: ok
[21:26] <jcastro> ogasawara: ok so during UDS I asked about enabling fscache now that upstream has removed the experimental tag. The module looks enabled and working and all that good stuff in maverick, but # CONFIG_NFS_FSCACHE is not set
[21:26] <jcastro> should I file a bug to ask for someone to enable the modules for the filesystem support?
[21:26] <jcastro> (The module and userspace thing don't seem to work without it otherwise)
[21:27] <jcastro> also, there's a corresponding config for AFS and 9p, but I don't think people use the latter. No idea who uses AFS these days
[21:33] <apw> manjo, superm1 suggests you also ask for testing from ubuntu-mythtv@l.u.c
[21:33] <manjo> JFo, ^ CFT that list ? 
[21:33] <manjo> apw, yes I saw the mail from him 
[21:35] <apw> manjo, ok was in irc so didn't know if you'd see it ... cool
[21:36] <manjo> apw, he is the only one who responded to my RFC :)
[21:37] <manjo> apw, currently upgrading my system to maveric to test package 
[21:40] <tgardner> jcastro, looks like we can enable it. I'll update bug #440522
[21:40] <ubot2> Launchpad bug 440522 in linux (Ubuntu) "Kernel modules not compiled (Stats, NFS, AFS, etc) (affects: 9) (dups: 1) (heat: 53)" [Wishlist,Confirmed] https://launchpad.net/bugs/440522
[21:40] <jcastro> tgardner: apparently CONFIG_FSCACHE_STATS=y and CONFIG_FSCACHE_HISTOGRAM=y help with debugging, maybe a good idea to have on during alpha/beta?
[21:41] <tgardner> jcastro, it depends if it has a runtime impact. I'm still looking at those
[21:41] <jcastro> oh ok.
[21:50] <ogasawara> jcastro: yep, typically I'd say file a bug with the request to enable the config option, but in this case I'd say we just use 440522
[21:50] <ogasawara> jcastro: I'll milestone the bug for Alpha2 so it stays on the radar
[21:50] <jcastro> \o/
=== jcrigby-afk is now known as jcrigby
=== kentb is now known as kentb_out
[22:23] <Delemas> Hello, can anyone point me to an example kmod block source package? I want to make a kmod-3w-sas or something similar for Lucid.
[22:37] <manjo> amitk, go to sleep dude 
[22:38] <amitk> manjo: it's only half past midnight :-p
[22:38] <manjo> amitk, my friend will think you are a workoholic 
[22:39] <manjo> amitk, I am trying to drag him to the golf course ... and he is using you as an excuse 
[22:39] <amitk> naah, wife is away ;)
[22:39] <manjo> lol
[22:40] <manjo> amitk, tell dinh he needs some exercise 
[22:40] <amitk> he is exercising his brain
[22:40] <amitk> give him a few minutes
[22:40] <manjo> :) was just joking 
[22:41] <amitk> I know :)
[22:45] <lifeless> question - 
[22:46] <lifeless> I have lucid running on an i7 laptop (arrandale, 640m), with a belkin N+N wifi access point
[22:46] <lifeless> is that known brain-damaged? I'm having to unload and reload iwlagn every hour or so, to stay connected.
[22:48] <jpds> lifeless: Does dmesg show anything like bug #352228?
[22:48] <ubot2> Launchpad bug 352228 in linux (openSUSE) (and 2 other projects) "Intel Wireless 5300 AGN: iwlagn: No space for Tx (affects: 55) (heat: 301)" [Undecided,New] https://launchpad.net/bugs/352228
[22:49] <lifeless> http://pastebin.com/CMktwt73
[22:49] <lifeless> dmesg | grep iwlagn | tail -n 50 | pastebinit ^
[22:49] <amitk> manjo: he's not going with you
[22:49] <manjo> amitk, yeah he is making excuses
[22:50] <lifeless> jpds: (in short, no)
[22:50] <manjo> amitk, complaining that he has a bad neck 
[22:50] <manjo> amitk, I think he wants to watch the NBA finals instead
[22:52] <amitk> sounds like a good excuse
[22:53] <jpds> lifeless: Bug #200509 then. That error message looks familiar.
[22:53] <ubot2> Launchpad bug 200509 in debian (and 3 other projects) "iwl4965: Microcode SW error detected. Restarting 0x2000000 (affects: 33) (dups: 5) (heat: 235)" [Undecided,New] https://launchpad.net/bugs/200509
[22:54] <lifeless> the [ 7003.963431] iwlagn 0000:02:00.0: Microcode SW error detected.  Restarting 0x2000000.
[22:54] <lifeless>  line ?
[22:54] <lifeless> sounds plausible, the restart is failing I guess
[22:55] <lifeless> no
[22:56] <lifeless> its a generic code
[22:56] <lifeless> anytime the microcode asserts
[22:56] <lifeless> so its got no diagnostic utility at all :(
[22:57] <lifeless> comment https://bugs.edge.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.24/+bug/200509/comments/111 matches my experience
[22:57] <ubot2> Launchpad bug 200509 in debian (and 3 other projects) "iwl4965: Microcode SW error detected. Restarting 0x2000000 (affects: 34) (dups: 5) (heat: 229)" [Undecided,New]
[23:13]  * manjo siging out 
[23:14] <anoteng> I've git-bisected a kernel bug, should I subribe/asign the bug to the committer of the first bad revision, or just leave it to triaged and hope someone sees it?
[23:15] <anoteng> subribe = subscribe
[23:15] <kees> hm, how do I fix this?  ->
[23:15] <kees> Your branch and 'maverick/master' have diverged,
[23:15] <kees> and have 9661 and 293 different commit(s) each, respectively.
[23:18] <ogasawara> kees: we rebased to -rc3 recently, so I'm guessing you might need to rebase your branch to the latest master?
[23:18] <ogasawara> anoteng: what's the bug#?
[23:18] <kees> ogasawara: I tried, but it didn't seem to help.
[23:20] <anoteng> ogasawara: #556232 
=== sconklin is now known as sconklin-gone
[23:22] <kees> ogasawara: everything seems correct, but it keeps yelling at me every time I change branches back to my maverick branch.
[23:22] <kees> I even did a reset --hard to somewhere far in the past.
[23:26] <kees> ogasawara: hm, it needed: git remote update maverick
[23:26] <kees> no idea why
[23:26] <ogasawara> kees: hrm, I've never used that before
[23:27] <kees> me either.  found the clue here: http://stackoverflow.com/questions/2298556/branches-have-apparently-diverged-but-commit-history-is-identical
[23:32] <ogasawara> anoteng: unfortunately the commit you narrowed it down to was the commit which backports the 2.6.33 drm stack which was supposed to bring more stability and bug fixes, ie it's not going to be reverted
[23:32] <ogasawara> anoteng: but you mentioned that a 2.6.34 kernel works fine
[23:33] <ogasawara> anoteng: don't suppose you might be able to do the bisect in the opposite direction and isolate the patch which fixes the issue?
[23:34] <ogasawara> anoteng: as that I think would have a better chance of being applied as a fix in an SRU