[00:00] <Zetto> smb_tp, NP, i saw a lot of critical bugs assigned to Ubuntu-Kernel-Team, i know that they are working hard 
[00:02] <smb_tp> Zetto, speaking of: guess I have to go shopping to get some food... ;-)
[00:04] <Zetto> smb_tp, hehehehe
[00:04] <Zetto> smb_tp, do you have a job ?
[00:06] <smb_tp> Zetto, Well, look at your report ;-)
[00:07] <Zetto> smb_tp, ok :D
[00:07] <smb_tp> Zetto, Gotta run. CU :)
[00:10] <Zetto> smb_tp, i and my girlfriend wanna travel to Canada someday
[00:11] <Zetto> but we still don't have enough money ^^
[05:45] <hyperair> hello there. in which kernel does intel 5100 support come in?
[05:45] <hyperair> uh whoops dc
=== emma_ is now known as emma
[09:45] <fabbione> BenC: pull request in your inbox for gfs1 for .27
[10:03] <laga> BenC: what's the status on aufs? :)
=== n0u_ is now known as n0u
[13:19] <cjwatson> hey - I'm trying to figure out bug 251593, which is part of the complex of things hosing PS3 right now
[13:20] <cjwatson> the spufs module seems to be present in that kernel (2.6.25-1-powerpc64-smp), and as far as I was aware sys_mount ultimately ended up telling kmod to load missing modules as necessary. Nevertheless, all this seems to fail and mount says "unknown filesystem type: spufs". Does anyone know what's up?
=== asac_ is now known as asac
[13:44] <pgraner> cjwatson: BenC is prob best to ask. I know he has the box in question.
[13:44] <cjwatson> BenC: ^-
[14:00] <hyperair> does anyone know when iwlwifi with support for 5100 is coming?
[14:05] <BenC> cjwatson: I'll check in a bit
[14:06] <BenC> hyperair: check linux-backports-modules in hardy, or latest kernel in intrepid (2.6.27, but may be a day before it's ready)
[14:06] <hyperair> i see
[14:06] <hyperair> okay
[14:37] <hyperair> BenC, linux-backports-modules contain the iwlwifi-5000-1-lbm.ucode, but not the driver that uses the ucode
[14:38] <hyperair> unless i'm mistaken about the driver name
[14:39] <rtg> hyperair: at the time compat-wireless was snap shotted, I'm not sure support for the iwl 5K device was fully implemented.
[14:39] <rtg> I didn't have one to test.
[14:40] <hyperair> i see
[14:40] <hyperair> what's the driver name supposed to be anyway?
[14:40] <hyperair> i see an iwl4965, iwl3945, and iwlcore
[14:40] <hyperair> i don't see any other iwls
[14:41] <hyperair> brb i'm gonna restart and see how the iwl4965 driver in lbm works
[14:41] <hyperair> currently my led's not working =\
[14:42] <hyperair> by the way can someone look into backporting alsa 1.0.17 to hardy? or will hardy users who have HDA intel sound cards that require the new alsa drivers just suffer until intrepid appears?
[14:44] <rtg> I'm working on a proposal to get the Intrepid kernel available in Hardy, but its gonna take awhile.
[14:50] <hyperair_> ah. iwl4965 still has the awesome kernel-panic-upon-rmmod bug
[14:50] <hyperair_> in lbm that is
[14:50] <rtg> hyperair_: welcome to 2.6.26 wireless bugs
[14:50] <hyperair_> lol
[14:51] <hyperair_> will 2.6.27's modules get backported via lbm anytime soon?
[14:52] <hyperair_> i think it might be worht mentioning that the leds still don't work in lbm
[14:52] <rtg> hyperair_: I doubt it. there are significant backporting difficulties. thats why I'm proposing backporting the whole kernel.
[14:52] <rtg> I'm aware of the led issues.
[14:52] <hyperair_> that'll be nice
[14:52] <hyperair_> i've noticed that my leds work in 2.6.27
[14:53] <hyperair_> the rc3 kernel that is built in kernel.ubuntu.com
[14:53] <hyperair_> however, upon resume, iwlagn causes the keyboard to lock up
[14:53] <hyperair_> only happens when there's some problem associating with an AP
[14:53] <hyperair_> something about a timeout
[14:53] <hyperair_> then the keyboard locks up and theo nly way to bring it back is to turn the HW RF Kill switch on
[14:57] <rtg> hyperair_: there are still a bunch more iwlwifi fixes bubbling up, though there seems to be some flame wars in LKML about what is a fix and what is a feature wrt to iwlwifi pull requests.
[14:58] <hyperair_> lol that's interesting to see
[14:58] <hyperair_> i'll go look in the archives or something
[14:58] <hyperair_> what's the thread name?
[15:00] <rtg> Re: pull request: wireless-2.6 2008-08-26
[15:00] <hyperair_> thanks, found it
=== lamont` is now known as lamont
[17:01] <BenC> rtg, smb_tp, cking, pgraner: ping for IRC meeting
[17:02] <pgraner> BenC: ack
[17:02] <smb_tp> BenC, ack
[17:02] <cking> BenC: ack too
[17:02] <BenC> pgraner: do you have a quick link to the contingency plan you sent earlier?
[17:03] <pgraner> BenC: Nope, still in email, I guess I can throw it up quick
[17:03] <BenC> Thanks
[17:03] <BenC> zul, soren: We're discussing the 2.6.27 move and contingency plan if you're interested
[17:03] <zul> sure
[17:04] <BenC> I'm waiting to see if mdz and slangesek are interested in joining
[17:04] <cjwatson> I noticed that we seemed to have already moved in intrepid
[17:04] <pgraner> BenC: wiki is sloooooow saving
[17:05] <cjwatson> I've been holding off on changing the installer until we are all agreed on a plan
[17:05] <pgraner> [LINK] https://wiki.ubuntu.com/KernelTeam/2.6.27-kernel-plan
[17:05] <BenC> cjwatson: we have, because in order to make the move, we need to do it now...what we are discussing is the contingency and criteria for reverting back to 2.6.26
[17:06] <cjwatson> there's no mention of certification in the plan, which I think will be valuable input
[17:07] <BenC> cjwatson: should we get cr3 in on this now, or is there someone else that can better represent that?
[17:07] <pgraner> cjwatson: good point
[17:07] <cjwatson> I would suggest that all certification regressions need to be considered as 2.6.27 blockers unless explicitly declared to be minor
[17:07] <cjwatson> they're one of our best sources of hard data
[17:07] <cjwatson> BenC: cr3 or heno could speak to it
[17:07]  * pgraner just edited wiki for better formatting
[17:08] <pgraner> ogasawara: ping, can you sit in on this meeting?
[17:08] <ogasawara> pgraner: sure
[17:09] <cr3> hi folks
[17:09] <cjwatson> BenC: I suggest phoning mdz - he's likely to be in meetings with the LP folks today
[17:09] <pgraner> cjwatson: he is in a meeting for the next 90min I just talked to him
[17:09] <BenC> I'll be sure to post the log to him afterwards
[17:10] <pgraner> cr3: can you read  [LINK] https://wiki.ubuntu.com/KernelTeam/2.6.27-kernel-plan
[17:10] <BenC> cr3: Thanks...we're interested on what can be done to speed up certification/regression testing with a 2.6.27 based intrepid image?
[17:10] <pgraner> cr3: we need to cover cert in this plan
[17:11] <BenC> cr3: This is quite important since cert is the most reliable testing for us right now
[17:11] <cr3> BenC: I spoke with heno this morning and I could start delivering more comprehensive testing as of next week
[17:11] <cjwatson> cr3: I've been assuming that you'll need stock ISOs built with 2.6.27 (i.e. installer and linux-meta switched over) before you can realistically do a certification pass; is this true?
[17:11] <BenC> cjwatson: When's the soonest we could get ISO's with 2.6.27 on them if I upload linux-meta today?
[17:12]  * BenC converges on cjwatson's thoughts
[17:13] <cr3> cjwatson: if the kernel is available somewhere, it might be possible to have it installed outside the iso
[17:13] <BenC> cjwatson: note that lrm for 2.6.27 is built and needs to be NEW'd
[17:14] <cr3> I would really want to perform the extensive testing from next week on .26 and then on .27, just to compare the results. I should have results for both ltp and autotest
[17:14] <cjwatson> BenC: tomorrow
[17:14] <cr3> Ideally, I should do that today, but my code is just not ready :(
[17:14] <cjwatson> cr3: can you do testing without an installer image?
[17:15] <cjwatson> it's going to be a little difficult to get parallel images with .26 and .27
[17:16] <cr3> cjwatson: I could use a prior installer image and perform post-installation steps if necessary, to install .27 for example
[17:16] <cr3> cjwatson: right, I wouldn't expect parallel images with .26 and .27 either
[17:16] <cjwatson> you wouldn't get verification of whether the installer still works, but you'd get some of it
[17:16] <BenC> I'd like to see installer images
[17:17] <BenC> compcache+aufs+squashfs testing is important to me
[17:17] <cjwatson> could we just compare alpha 4 to alpha 5?
[17:17] <BenC> Mainly because of some VFS changes I had to port them for
[17:17] <cr3> cjwatson: where alpha 5 would use .27, right?
[17:17] <BenC> cjwatson: Yeah, that's fine with me
[17:17] <cjwatson> on the assumption that we will be able to identify userspace regressions
[17:17] <BenC> cr3 is smart enough to separate installer/userspace bugs from kernel ones
[17:17] <cjwatson> cr3: right - or preferably an earlier milestone if we can identify one that works
[17:18] <cr3> cjwatson: my intention is to run the full suite from next week on alpha 4 again in order to have data to compare against 5, so I should be able to identify regressions that way
[17:18] <cjwatson> that sounds good
[17:18] <BenC> cr3: Can we have a hard date from you for results?
[17:19] <BenC> I know it may be difficult to estimate, but we have some serious time constaints
[17:19] <cjwatson> BenC: lrm 2.6.27 processed
[17:19] <cr3> BenC: one of heno's concern is my reporting, which is not very strong right now. worst case, you might have to query a database dump
[17:19] <BenC> cjwatson: Thanks, meta coming up then
[17:20] <cr3> BenC: results for alpha 5? at least some should be made available 24 hours after release
[17:20] <BenC> cr3: as long as we have some discernible data to look at
[17:20] <pgraner> cr3: define query a db dump?
[17:20] <cr3> BenC: yeah, the data is all there, just getting reports out of it is lagging behind
[17:21] <pgraner> cr3: do we see pass/fail by subsystem? component level? a mix?
[17:21] <cr3> pgraner: if the reports on the web site are not sufficient, I might have to pg_dump my database and make it available for running sql queries against it. that's assuming the reports aren't sufficient and can't be improved in reasonable time
[17:21] <cjwatson> BenC: once we upgrade -meta, if we have to go back to .26, how will we get the newer kernel off testers' systems so that we don't end up with divided testing effort
[17:21] <cr3> pgraner: you at least see pass/fail per build and per system
[17:22] <BenC> cr3: basically we just need to compare pass/fail from one set to the next and verify that it was caused by a kernel issue
[17:22] <pgraner> cr3: ack ... do you have a pointer to the web page as an example that would go along way to knowing what to expect
[17:22] <cr3> pgraner: someone is working full time on improving the reports but he's on vacation right now
[17:23] <pgraner> cr3: can you show us what you have today?
[17:23] <BenC> cjwatson: linux-meta uploaded
[17:24] <cr3> pgraner: sure, I'll send you an invitation to access the site
[17:24] <pgraner> cr3: great thx
[17:24] <BenC> Ok, as far as known regressions...
[17:24] <BenC> Subject: 2.6.27-rc4-git1: Reported regressions from 2.6.26
[17:25] <BenC> that's on lkml...I've been going through the list...it's very tedious
[17:25] <BenC> So far I have identified ~8 regressions that may pertain to us
[17:25] <cr3> BenC: regarding comparing pass/fail from one "set" to the next, "set" being a build?
[17:26] <BenC> the rest of the bugs are either on non-x86, outside the scope of our configs (we don't enable things that cause the bugs) or they were present in 2.6.26 as well
[17:26] <pgraner> BenC: is that this list? http://bugzilla.kernel.org/showdependencytree.cgi?id=11167&hide_resolved=1
[17:26] <BenC> cr3: set being a system
[17:26] <BenC> pgraner: looks very similar
[17:26] <BenC> pgraner: that list may be more up-to-date as well, so I'll cross check against it
[17:27] <pgraner> BenC: I went thru that yesterday and most were not critical as you say due to config options and the like
[17:27] <BenC> The ones I've payed attention to aren't critical, but I want to investigate them further to make sure we get full descriptions of what we may have to handle
[17:28] <BenC> or things we can look into fixing ourselves
[17:28] <BenC> pgraner: Are you adding that link to the wiki?
[17:28] <cr3> BenC: ideally, you would probably want to see that for a bunch of systems at once, right?
[17:28] <pgraner> BenC: ACK done
[17:28] <BenC> cr3: right
[17:29] <BenC> pgraner: thanks...that's much easier than the email thread I was looking at
[17:29] <cr3> BenC: what would the columns and rows look like? I'm imagining the first column would contain the system name, where each row would be an individual system. not sure about the subsequent columns though
[17:30] <BenC> cr3: each row would be a system with columns being doubled for each test (with pass/fail for alpha4/alpha5 shown for each test)
[17:30] <BenC> cr3: mainly we only want to see the ones where there is a pass for alpha4 and a fail for alpha5
[17:30] <cr3> BenC: ok, I would like to follow up after this discussion by email with you and pgraner to make sure we at least have that kind of report straight
[17:31] <pgraner> cr3: ack
[17:31] <BenC> cr3: knowing which ones are fail/pass for alpha4/alpha5 would be nice to, so we can see what we're fixing :)
[17:31] <BenC> cr3: thanks
[17:31] <cr3> BenC: well, I can't make a report specific just for this corner case of a new kernel but hopefully something generic which could be reused across releases
[17:31] <cr3> pgraner: problem?
[17:32] <pgraner> cr3: nope
[17:32] <BenC> cr3: I would have thought that comparing fail/pass between test runs was a normal reporting output
[17:32] <BenC> cr3: ACK == "ok, noted"
[17:33] <BenC> cr3: but we can discuss this more through email
[17:33] <cr3> BenC: the problem is that not all systems necessarily have a test run each day, and some systems might have multiple runs the same day. the problem is that when you display multiple systems at once, it doesn't always make sense to have columns per date but perhaps per build or milestone might make sense.
[17:33] <cr3> BenC: or phone
[17:34] <BenC> cjwatson: There are some things that need to be contended with from userspace....one of the main ones is alsa userspace and pulseaudio to get the benefits of 1.0.17 alsa drivers
[17:34] <cr3> per build or per milestone would be awesome actually, I could finally determine which systems have been neglected!
[17:34] <BenC> cjwatson: it's not required mind you, but the benefits will be lost without syncing those
[17:35] <cr3> BenC: actually, I think I have a good idea for the report now. I'll build something this week and ping you when done
[17:35] <devfil_> hi to all, there is a chance to include compcache (http://code.google.com/p/compcache/) to ubuntu kernel? it seems to be good (but I don't know nothing about how a kernel work, so at your choice :))
[17:35] <BenC> cr3: great thanks
[17:35] <BenC> devfil_: already there, thanks
[17:35] <BenC> cjwatson: do you forsee any issues in syncing alsa/pulseaudio?
[17:35] <devfil_> BenC: in what kernel version?
[17:36] <BenC> devfil_: intrepid
[17:36] <devfil_> BenC: wow, really good thing :)
[17:37] <shenki> another reason to not run .26, no more compat wireless backports: http://marc.info/?l=linux-wireless&m=121977672215224&w=2
[17:38] <BenC> shenki: nice point, but sucks for hardy :/
[17:38] <BenC> rtg: you can add that to your reasons for trying to get 2.6.27 into hardy though :)
[17:38] <shenki> yeah, poor hardy. no 80211n for you
[17:38] <pgraner> BenC: rtg's proposal look more attractive huh?
[17:39] <lukehasnoname> Hardy doesn't have wireless N support?
[17:39] <BenC> pgraner: definitely
[17:39] <lukehasnoname> you learn something every day
[17:39]  * BenC wonders if cjwatson caught the underground home already
[17:39] <shenki> lukehasnoname: not with intel atleast
[17:39] <BenC> lukehasnoname: it's supports 11n chipsets, but not 11n itself
[17:39] <cjwatson> BenC: I'm at home
[17:40] <BenC> cjwatson: ah :)
[17:40] <lukehasnoname> :( Well then... looks like I have one more reason to move to Intrepid
[17:40] <cjwatson> BenC: I believe new pulseaudio still needs a bit of TLC before we add it, though folks in the know seem generally keen
[17:40] <cjwatson> 00:43 <TheMuso> As now 2.6.27 is in/going into the archive, I now have to get alsa 1.0.17 in before FF.
[17:40] <cjwatson> 00:49 <cjwatson> TheMuso: I don't think 2.6.27 is settled yet
[17:40] <cjwatson> 00:49 <TheMuso> cjwatson: oh ok.
[17:40] <cjwatson> 00:51 <TheMuso> then I'll hold off on my uploads then...
[17:40] <cjwatson> 00:54 <cjwatson> hmm, though it does look like linux is at 2.6.27 now
[17:40] <cjwatson> 00:54 <cjwatson> but the discussion with mdz on ubuntu-devel didn't seem to reach a clear conclusion
[17:40] <cjwatson> 00:54 <cjwatson> I'd say put the alsa (and pulseaudio?) packages in a PPA for now so that we can try them out with 2.6.27
[17:40] <BenC> cjwatson: I noticed before we did this there were a lot of complaints about not having 1.017 alsa so that pulseaudio could be updated to fix a lot of bugs
[17:41] <cjwatson> 00:54 <TheMuso> Yeah I gathered. I'll wait.
[17:41] <cjwatson> 00:55 <TheMuso> Yep I'll do that once my dmraid work is done.
[17:42] <BenC> cjwatson: It's important to note that even if we revert back to 2.6.26, unless the regressions are because of alsa 1.0.17, we'll be moving 2.6.26 to alsa-1.0.17 anyway
[17:42] <BenC> cjwatson: so moving to new alsa userspace and pulseaudio should be done regardless
[17:42] <cjwatson> how intrusive is that?
[17:42] <BenC> cjwatson: we'll be taking 2.6.27's entire sound/ and include/sound/ directories into 2.6.26
[17:42] <cjwatson> it's reassuring that we wouldn't have to roll back alsa, since rolling back libraries is always fraught with pain
[17:43] <BenC> cjwatson: that was our plan before moving to 2.6.26 anyway
[17:43] <BenC> *2.6.27
[17:43] <pgraner> BenC: Can you summarize where we are for the record with AI's
[17:43] <BenC> cjwatson: I went to the trouble of doing this before we switched to 2.6.27, and the compile and build of it went fine
[17:43] <BenC> pgraner: AI's?
[17:44] <pgraner> BenC: Action Items
[17:44] <BenC> ACTION: TheMuso: move to alsa 1.0.17, new pulseaudio
[17:44] <BenC> ACTION: BenC: summarize known regressions in 2.6.27/2.6.26 move
[17:45] <BenC> ACTION: cr3: Setup call/email thread with BenC and pgraner to discuss cert testing and reporting between alpha4/alpha5
[17:45] <smb_tp> On email cc: kernel-team?
[17:46] <pgraner> smb_tp: good point
[17:46] <BenC> essentially, if there are regressions in 1.0.17 alsa, we will have to work to fix them, because reverting to 2.6.26 will cause more pain
[17:46] <BenC> pgraner: that's probably worth noting on the plan
[17:47] <BenC> which shouldn't be much trouble because we have all kinds of hardware to reproduce and fix bugs in alsa (IOW, snd-hda)
[17:47] <pgraner> BenC: Have you talked to davej at Fedora to see where they currently sit with 2.6.27 and see if we could attack different problems so we don't duplicate effort?
[17:47] <BenC> pgraner: No, but that's a good idea...opensuse and fedora are both going with 2.6.27, so would be good to coordinate
[17:48] <pgraner> BenC: do yo know davej? If not I could do an into for you
[17:48] <BenC> ACTION: BenC to contact opensuse and fedora kernel devs to improve efforts
[17:48] <BenC> pgraner: I believe davej introduced himself quite rudely on my blog :)
[17:48] <cr3> pgraner: invitation sent and follow up email
[17:48] <cr3> BenC: ^^^ copied you to give an idea of my report
[17:49] <BenC> but I may be thinking of another dave*
[17:49] <cr3> you can both expect a ping from me this week
[17:49] <BenC> cr3: thanks
[17:49] <pgraner> pgraner: I'll send an into email, and no your correct same davej
[17:49] <pgraner> s/pgraner/BenC/
[17:49]  * pgraner needs food
[17:49] <BenC> pgraner: I knew it was only a matter of time before this job drove you mad
[17:49]  * pgraner is talking to myslef
[17:50] <BenC> pgraner: file an expense report for the psych visits and meds :)
[17:50] <pgraner> Has everyone read the page and agree in principal to the plan? Do we need to tweak dates?
[17:50] <pgraner> BenC: I can see mdz looking at the now... hehe
[17:51] <ogasawara> pgraner: we might want to change the first call for testing date - it'll likely happen before the 2nd
[17:51] <BenC> Yeah, I plan sending out a CFT today as a matter of fact
[17:51] <pgraner> ogasawara: just edit and set when you think is appropriate 
[17:51] <BenC> to -devel-announce, -devel and blog
[17:51] <pgraner> BenC: Coordinate that with ogasawara so we don't send multiple msgs
[17:51] <lukehasnoname> what's CFT?
[17:52] <pgraner> lukehasnoname: Call For Testing
[17:52] <lukehasnoname> thanks.
[17:52] <ogasawara> BenC: I'll wait for the announcement to hit the ml, then spam the bug report
[17:52] <BenC> ogasawara: Ok
[17:52] <zul> pgraner: yep read it
[17:54] <BenC> ACTION: BenC to send out CFT
[17:54] <BenC> ACTION: ogasawara to follow up with bug report requests to update to 2.6.27-1 and test
[17:55] <pgraner> BenC: Also grab this log and link to the page as well for background and reference
[17:56] <BenC> ACTION: BenC to grab IRC log and link wiki plan to it
[17:56] <pgraner> BenC: I have to jump off, I'll check to log and will circle back with you in and hour or so.
[17:57] <BenC> pgraner: Ok, I think we are pretty much done
=== pgraner is now known as pgraner_afk
[17:57] <BenC> Anyone have anything to add?
[17:58] <zul> what about pending patches for 2.6.27?
[17:59] <BenC> zul: we'll try to get those in before alpha5...I want to try to keep the tree is pristine as possible though so we don't mix regressions we introduced with ones that came from external patching
[18:00] <BenC> I'd hate to revert to 2.6.26 just because a xen64 patch fubar'd everything :)
[18:00] <zul> BenC: heh it should only affect xen when its enabled
[18:00] <zul> but thats fine
[18:02] <BenC> Ok, then let's call this done, and get to work :)
[18:15] <ubunubi> is compiling the kernel from linux-source package broken? every machine I've tried it on errors with *** No rule to make target `arch/x86/kernel/asm-offsets.c', needed by `arch/x86/kernel/asm-offsets.s'.  Stop.
[18:22] <rtg> ubunubi: https://wiki.ubuntu.com/KernelMaintenance
[18:25] <ubunubi> rtg: why is the linux-source package still put in the repos if it's no longer maintained for building kernels?
[18:27] <rtg> ubunubi: if course it is maintained. in fact, its generated from the sources in the git repo. Once you have 'apt-get source ...' then run 'debuild -b' to generate the binary packages.
[18:27] <rtg> alternatively, chewckout the sources using git, then build the same way.
[18:27] <ubunubi> rtg: sorry i meant kernel-package
[18:28] <ubunubi> rtg: i just want to recompile my current (2.6.24-19-generic) with PAE enabled. all the guides I can find online are using (apprently the old fakeroot make-kpkg way)
[18:29] <rtg> ubunubi: now that I couldn't tell you. I've never used kernel-package.
[18:31] <ubunubi> rtg: do you know of a decent tutorial using your method, for compiling with pae? all kernel compiling howto's are super old (7.10 and older)
[18:31] <mdz> BenC,pgraner: I just got off my last call of the day. what did I miss?
[18:32] <rtg> ubunubi: I beg to differ. the instructions in  https://wiki.ubuntu.com/KernelMaintenance are current as of 2.6.26
[18:34] <ubunubi> rtg: that's hardly a tutortial. doesn't show how to adjust any individual build options etc, like enabling/disabling custom options (like pae) ...like  make menuconfig did for the old method
[18:35] <rtg> ubunubi: try 'debian/rules editconfigs'
[18:35] <ubunubi> rtg: k thanks will give it a try
[18:36] <BenC> mdz: I'll have a log posted soon
[18:36] <BenC> mdz: we have a complete plan in place with some action items...cr3 and cjwatson were in the meeting
[18:37] <BenC> mdz: rookery:~bcollins/kernel-team-irc-log.txt if you want a quick look
[18:38] <BenC> mdz: you can "grep ACTION" as well
[18:39] <mdz> BenC: thanks, will review
=== pgraner_afk is now known as pgraner
[19:17] <tormod> benc, I think our beloved prism2 drivers need some patching for 2.6.27
=== emma_ is now known as emma
=== emgent` is now known as emgent
[19:38] <BenC> tormod: they seem to compile fine...is there a runtime problem?
[19:40] <tormod> BenC:  I haven't tested, but this is in upstream git: http://git.shaftnet.org/git/gitweb.cgi?p=linux-wlan-ng.git;a=commitdiff;h=0b9426b9e7bfdd838b1f0a3e2a4ed8a8fc95ebf7
[19:40] <tormod> and this: http://lists.linux-wlan.com/pipermail/linux-wlan-devel/2008-August/003861.html
[19:42] <tormod> BenC: I can test it if I get some i386 builds but I guess it will take some time before it's out?
[19:50] <BenC> tormod: I already have that done in our tree (else it wouldn't have compiled :)
[19:51] <tormod> BenC: good. you updated BOM then? :)
[19:54] <BenC> tormod: doubtful, but I did update the commit log
[19:56] <tormod> BenC: I can not see that from http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=history;f=ubuntu/misc/wireless;hb=HEAD ?
[20:04] <BenC> tormod: it's not a separate commit...check the actual code, it's there
[20:07] <laga> BenC: can i pretty please get a status update on aufs?
[20:12] <BenC> laga: basically while moving to 2.6.27 I don't want to introduce anything yet that wasn't in the last 2.6.26 upload so we can more easily track regressions
[20:12] <BenC> laga: once alpha5 is out I'll include your aufs update
[20:12] <laga> BenC: thanks. consider yourself hugged. 
[20:13] <tormod> BenC: I am just nitpicking about this because last time we updated the drivers from upstream it was not clear that the Ubuntu code had some needed changes of its own. And this commit log looks like a copy of an older commit although you changed a few things... But as long as you keep track of it yourself, it's not my business :)
[20:14] <BenC> tormod: I should have updated the BOM...I'll make sure to add the notes in later
[20:14] <BenC> laga: consider yourself thanked for doing the work :)
[20:47]  * BenC => rebooting
[21:23] <nixternal> ok kernel freaks, gotta a good one for you...found it once via google weeks back, but now I can't
[21:23] <nixternal> setting up hot-swap (SATA) on a server I have
[21:24] <nixternal> current setup is /dev/sda /dev/sdb /dev/sdc /dev/sdd
[21:24] <nixternal> if I pull out /dev/sdc the kernel does what it is supposed to do and performs a check every 5 seconds for drive insertion
[21:24] <nixternal> so, if I insert the same drive or a new drive back in the same slot, it doesn't come back as /dev/sdc, it comes back as /dev/sde
[21:25] <nixternal> 2.6.24 kernel
[21:25] <nixternal> I thought I read about a fix somewhere a few months ago, but I do not remember
[21:37] <CarlFK> trying to install .27 - "nvidia (177.68): Installing module.  Kernel source for 2.6.27-1-generic not installed.  Cannot install this module. [fail]"  http://dpaste.com/74302/
[21:37] <CarlFK> should I file that on lp?
[21:39] <CarlFK> how do I turn off # defoptions=quiet splash 
[21:40] <CarlFK> I tried ##, and I get "file has been modifed... [x] use maintiners version  [ ]merge?  [ ]leave alone.." which seems to revert it back to one #
[22:07] <pwnguin> its a config file
[22:07] <pwnguin> debconf will notice it's been changed when upgrades, and notifies you
[22:18] <CarlFK> pwnguin: so how should I answer the "what you want to do?" 
[22:18] <pwnguin> not sure
[22:18] <pwnguin> I'd do a merge
[22:18] <CarlFK> ill try that next time 
[22:18] <pwnguin> but that means you'd have to know whether changes are relevant
[22:23] <cr3> lspci question: why does lspci -vvv return nvidiafb as value for Kernel modules whereas this value does not appear in lsmod nor in /var/log/Xorg.0.log