=== asac_ is now known as asac === philwyett_ is now known as philwyett [04:17] I really wish Kano would look before speaking [04:17] that dvb fw is already in lrm === foka_ is now known as foka [06:42] How does a 'kernel variable' differ from a 'kernel parameter'? [06:53] bullgard4: I've never heard of a kernel variable, but I assume it refers to a kernel parameter [06:58] One exmple: /usr/src/linux-headers-2.6.24-18/include/linux/timex.h Line# 191 [07:24] bullgard4: that's a kernel global variable, in the programming sense...not a kernel parameter [07:56] Ah! Thank you for explaining. [08:00] does gspca build for somebody with 2.6.26? [08:03] it seems it is missing in ubuntu/Makefile [08:08] hmm no, it is much simpler... [08:08] obj-$(GSPOCA) is below... [08:09] could somebody fix the typo [08:12] remove the O please... === doko__ is now known as doko [08:44] Kano: fixed the typo [08:44] good, now only my uvcvideo hotfix is needed ;) [08:51] http://kanotix.com/files/kernel/kernel-update-pack-generic-next/source/2.6.26-uvc_driver-medion-e1210.patch [08:52] thats what i use - already added to hardy lum [08:58] well the gscpa module still does not compile, even with that fixed typo [09:08] did somebody else try to compile the kernel? [09:08] Kano: I am doing it... [09:10] did the module build for you? [09:11] no [09:11] any ideas why it does not build? [09:15] maybe CONFIG_ is missing in front [09:16] 2 errors in same line it seems *g* [09:46] Kano: really fixed now and it compiles [09:47] i am still compiling with that change *g* [09:48] hopefully it works, the standard makefile has some extra options enabled i think [09:48] i can not test it, but at least i know some [17:00] Good afternoon (morning, evening, whatever) [17:02] Time for our weekly IRC meeting [17:02] hi [17:02] hi [17:03] Basically we just want to review the progress for intrepid so far [17:03] as of this week, a -rc8 based kernel is in the archive, and we have rebased to -rc9 in the git repo [17:04] The current kernel in the archive is the one that will be in alpha 2 [17:04] most of the drivers from hardy linux-ubuntu-modules are now in the intrepid kernel tree [17:04] lirc being the only exception [17:06] BenC: Is lirc scheduled to be included later? [17:07] cking: if we can get it to compile [17:07] The linux-ports tree seems to be lagging right now... === Nafallo_ is now known as Nafallo [17:08] That's a nudge to the community to step up :) [17:09] That's about all I have [17:09] anyone have anything to add or ask? [17:10] rtg: want to give an update on hardy SRU's? [17:10] I'm doing 'em. [17:10] hehe [17:10] concise, I like it :) [17:10] I'm working on getting the next batch uploaded as soon as the Hardy -security release is done. [17:10] Hopefully later this week. [17:10] rtg: any notable updates in that batch? [17:11] Its an ABI bumper. [17:11] rtg: anything we can do to prevent an ABI bump? [17:11] Not do the SRUs [17:11] There are a couple of significant ACPI updates courtesy of smb [17:12] can't remember what else, 'cause there a bunch stacked up [17:12] rtg: are these SRU's in a tree where we can review them and investigate reworking the patches to prevent ABI bump? [17:12] BenC: they are all in the working Hardy git repo [17:13] I've also been building in my PPA all along [17:13] Hence, my question earlier today about getting Hardy daily builds into the kernel PPA [17:13] Ok...I might give it a once over today to see if we can do a test run of not bumping the ABI [17:14] The ones from ACPI unfortunately can't be different and after one bum the others won't hurt [17:14] frankly, I have pretty strong opinions about why its a good idea to bump the ABI, I just have not taken the time to write 'em down. [17:15] I think there are at least 3 ABI bumpers. [17:15] thats all from me. [17:15] Wasn't there one also from security? [17:15] nope [17:15] well, bumping the ABI is required if there is an actual reason to bump it...but if we can avoid it, all the better...it'd be a good exercise at the very least [17:16] rtg: thanks [17:16] Anyone else? [17:16] BenC, sure. have fun. :) [17:16] smb_tp_: the security patches added a new public interface, but that doesn't cause an ABI bump [17:16] BenC, Nope [17:17] rtg, Ok, I might well be I remoember incorrectly [17:18] Ok, meeting adjourned..have a great week and see you next Tue, same time, same place [17:19] Oh, reminder, next week there will be no IRC meeting as we'll be at sprints === BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.26-3.8 | Latest news: 2.6.26 kernel is in Intrepid | Next meeting: July 22, 16:00 UTC | Kernel Team machine: http://kernel.ubuntu.com === BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.26-3.9 | Latest news: Please test last-good-boot, now in intrepid (grub/module-init-tools) | Next meeting: July 22, 16:00 UTC | Kernel Team machine: http://kernel.ubuntu.com [17:20] is intrepid safe for use yet, as a developer who doesnt mind hitting a small bug now & then? [17:23] mkrufky: I can't say for sure...the kernel is pretty damn stable for me, but I am mostly hardy in userspace [17:23] I know the intel/vesa Xorg was busted somehow and is getting fixed today [17:24] ah, cool [17:24] so, how do i try that? (using interepoid kernel with hardy userspace) [17:24] and, i dont want to waste your time with that kind of explanation -- if there's a howto or wiki page that would do just fine [17:25] add intrepid to apt's sources.list, update and "sudo apt-get install linux-image-generic" [17:26] may also want to install new linux-restricted-modules-common (which is where all the firmware went) [17:26] then i would have to disable the intrepid repos afterwards to prevent from getting userspace stuff? === mkrufky is now known as mkrufky-lunch [17:55] "EE: 1401 symbols changed hash and weren't ignored" [17:55] rtg: that's for the current hardy build :/ [17:58] BenC: thats almost like an ABI bump, huh? [18:01] rtg: Just wonder how so many things changed [18:02] that's about the same that I get when going from rcX to rcY [18:02] and I mean the low rc's, not like rc8 to rc9 :) [18:03] BenC: when there is that many changes its usually a fundamental macro, like when we went from SCHED_USER to SCHED_CGROUPS on -generic [18:03] BenC, If you change a basic struct that has a lot of dependencies. And maybe the ACPI stuff is basic enough [18:03] I can't see how acpi can cause changes to a good chunk of the net core [18:04] BenC, Hm, no unlikely [18:09] BenC, might be something sounding harmless (like CONFIG_NETDEVICES_MULTIQUEUE=y) [18:14] smb_tp_: agreed...your acpi change for cpuidle doesn't cause an ABI bump that I can tell [18:15] BenC, no the one sure candidate was that for the irq descriptor sizes [18:15] BenC: CONFIG_NETDEVICES_MULTIQUEUE is a likely culprit [18:17] BenC, I can't remember exactly either there was something before that irq descripttor size patch or it was that patch that bumbed the abi and after that we lost slightly track [18:22] ok, MULTIQUEUE accounts for almost all of the abi changes [18:22] cpuidle accounts for 19 changes [18:23] rtg: what did we need multiqueue for again? [18:23] wireless-testing in LBM needs it for 802.11n support [18:24] BenC: or rather, compat-wireless [18:25] rtg: will it compile without it? [18:27] BenC: there was a period where it would not, but I have not checked lately. I figured it was as good a time as any to add an ABI bumping change since there were already some SRU changes that caused an ABI bump. [18:28] Yeah, the two acpi changes cause an ABI bump as well [18:28] ok, as long as we can account for the need for an ABI bump, I'm fine...the acpi fixes seem pretty serious (oopses) [18:29] BenC: you don't think I let them in for free do you? I made smb_tp_ work hard for them :) [18:30] hehe [18:30] Oh yeah... :) [18:30] I trust your judgment, but I was hoping we could work them out somehow [18:36] Is the fix for bug 218516 already in the intrepid kernel? As I see the same problem with the intrepid kernel [18:42] bug #218516 [18:42] hmm...why isn't ubotu in here :-/ [18:43] sadly, ubuntoid seems missing in action [18:43] http://launchpad.net/bugs/218516 [hardy] key events are delayed under circumstances [18:45] BenC: ubotu left with seveas [18:45] geser: doesn't seem to have made it upstream, so no, it's not in intrepid [18:45] ubottu is the new bot [18:46] I wonder about the patch, since it didn't get accepted into 2.6.26 === asac_ is now known as asac [22:46] <_MMA_> rtg: Has Alessio talked with you regarding any upstream issues that are holding him up with -rt?