[00:56] hi [01:00] if anyone around is in charge of the mainline kernel ppa, please can you look into why the amd64 kernels are not building? === bryceh_ is now known as bryceh === bryceh is now known as bryce [05:11] hi [05:11] anyone from the kernel team about? === _LibertyZero is now known as LibertyZero === yofel_ is now known as yofel [08:10] * ppisati -> out to take care of some stuff, be back in a hour or so [10:58] Is there a way I can tell a PCI ID to use a specific kernel module? [10:58] I have a Broadcom wireless card which is not being detected in jockey: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/765839 [10:58] Launchpad bug 765839 in linux "Kubuntu installer not finding Wireless [bcm 4331 needs driver]" [Undecided,Confirmed] [10:59] jpds, normally modules list which things they support [10:59] apw: Aha, so I guess I need to hack up the broadcom-sta-source package? [10:59] for jocky i think there is a list of things which trigger wl to be loaded (for broadcom stuff) [11:16] jpds: You can make it work without patching anything. [11:17] jpds: Find the relevant /sys/bus/pci/drivers/ dir. [11:17] jpds: In there, there's a new_id "file". [11:18] jpds: You can write a vendor/product id pair to it, and the driver will take attempt to use any devices that match. [11:18] jpds: I forget the exact format, but I think it's just "1234 6789". If not, try "0x1234 0x6789". [11:19] soren: Cool, thanks. [11:19] jpds: Sure thing. [12:02] <_ruben> is there a trick to compile a kernel in a pbuilder other than pbuilder login and going from there? [12:04] _ruben, sorry not familiar with using pbuilder, though i'd expect the kernel to be the same as any other package [12:04] <_ruben> apw: well, pbuilder takes a .dsc as "input", a kernel build tends to be more complex than a "standard" source package [12:05] _ruben, well you can cirtianly make a source pacakge out of our tree [12:05] <_ruben> let me rephrase: how does one usually do a kernel build in an as clean as possible env? clean chroot? clean server/vm? [12:09] _ruben, i do all my test builds before upload in clean chroots yes [12:09] as there i can do partial builds [12:09] <_ruben> apw: made with debootstrap? [12:18] _ruben, yep basically so [14:09] Oooo, 2.6.39 final came out. /me rebases [14:09] ogasawara, have at it :) [14:18] ogasawara: do we have 2.6.41 for O then? ;) [14:18] (.39 came earlier than expected) [14:19] amitk: :) it might make it an interesting call towards the end of the release [14:21] i suspect .41 will appear very late, which will make getting arm ports up to .41 hard, they may actually make .40 [14:25] apw: who cares about ARM?! [14:26] :) [14:28] apw: you mean omap4? [14:28] ppisati, including omap4 yes [14:28] apw: we are discussing it, and tomorrow i hope to know who is going to carry the landing tree [14:29] because the situation is a bit fuzzy right now [14:29] ppisati, does not supprise me. === MTecknology is now known as EvilMTeck [14:40] ogasawara, let me know when there is a rebase to play with, i have some patches i want to pull up [14:40] apw: cool, should be just a sec [15:24] bug 765082 looks like a good cherry pick for natty to me [15:24] Launchpad bug 765082 in linux "[ips-monitor] is in state 'D'" [Undecided,Confirmed] https://launchpad.net/bugs/765082 [15:27] ogasawara: ^ [15:32] apw: rebased and pushed to master-next [15:32] ogasawara, sounds good to me :) [15:32] bdmurray: cool thanks, will take a look when I get back [15:32] * ogasawara bails to appt [15:32] ogasawara, when we uploading agian? wondering about cd support [15:33] apw: I uploaded tues so we have your aufs bits [15:33] apw: will likely upload again tomorrow to get v2.6.39 final in [15:33] ahh ncie, will see if there is a disk [15:33] you are off tommorrow [15:34] apw: I know, but it'll only take a few min to prep the upload [15:34] apw: unless you want to volunteer to do it :) [15:34] if you want me to spin it just say [15:34] apw: spin it [15:34] ack [15:35] apw: doko mentioned he might be uploading a new gcc towards the end of the week, but not sure we really need to worry about it considering our new stance [15:35] ogasawara, only in that we want to compile everything with the same one [15:35] will ask him now ... thakns for the heads up [15:36] * ogasawara really bails now [16:27] * ppisati has just tried to rebase sebjan tree on top of natty's master and got around 2.6k patches... [16:29] ppisati, you gonna have good time :-s [16:33] firewave: throwed the towel after the Xth conflicts [16:35] ppisati, :-/ I understand... [16:40] ppisati, have you tried just merging that tip with the natty master instead [16:40] df [16:42] apw: i'm re-reading your (you, bryan, npitre, etcetc) about the handling methods [16:42] s/your/your thread/ [16:42] yep [16:43] nope, but i'll try later [16:43] btw, i have an email from cooloney from... [16:43] 23/3/2001 [16:43] 2011 [16:43] [Natty] [ti-omap4] [Pull-request]: TI OMAP4 2.6.38 updates [16:44] where he mentiond he was able to do a rebase against master [16:44] but, really, 2,6k patches are a bit too much [16:44] ppisati, though i think he did t th opposite, he didn't rebase branch aganst master, he rebased master against his branch [16:44] which isn't the same at all, but he called it that anyhow [16:44] ah [16:45] now i personally think as i said in the thread, if we are using the linaro base, then we should just merge that with master [16:45] so he got the latest ubuntu sauce/cve/sru/etcetc [16:45] actually sebjan tree was supposed to be based on mainline + BSP [16:46] ppisati, either way if its a major pile of patches, i am inclined to suggest a merge may be less mind dammaging for us, and its not hard to maintain if we know that is what it is [16:47] uhm k [16:47] anyway, i keep reading... [16:47] anyhow, thats what i tried out in my thread, so perhaps speak again when you have read [16:47] ok [17:12] lunch... bbiab [17:27] rebooting [17:40] apw: i didn't faint, it's just that i'm trying to get a sane set of patches from sebjan [17:40] apw: and i'm down to 453 now [17:40] ppisati, heh [17:40] still after 10 of them i start getting all kinds of conflicts [17:42] that was my experience ... very hard to merge and i am not sure its worth it [17:44] anyway, i'm off to the gym now [17:44] but i'll keep trying a bit more [17:45] we can discuss about it monday [18:19] ok, I am tired of looking at bugs for one day [18:19] * JFo goes back to planning [18:25] JFo: just fyi, I posted all the action items from your UDS bug handling session to the blueprint and assigned them to milestones [18:25] JFo: there were some Alpha1 items to knock out [18:25] ogasawara, you rock! thank you very much. :-) [18:26] Pete fussed at me for getting action items [18:26] apparently I wasn't supposed to incur any as this cycle will be almost solely focused on the defect analysis definition [18:27] so we can get it solidified before the next LTS [18:27] :-/ === hallyn is now known as hallyn_afk === ayan is now known as ayan-afk [18:27] JFo: well now is the time to go through the current items and pull out any you know you need to defer then [18:27] I thought he meant 'don't get action items from anything OTHER than the bug handling bp [18:27] right, will do that [18:27] but thank you so much for taking the notes and noting the actions. I really do appreciate it. [18:29] ogasawara, do you know why the mainline builds aren't generating amd64 packages? [18:29] http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.39-rc7-oneiric/ [18:29] not since .39-rc5 [18:29] cnd: hrm, not sure. best to nudge apw since he's been caring for the mainline builds for the most part. [18:30] ok [18:30] cnd i am told the dailies are now [18:30] and if you look back its cause amd builds are broken [18:30] where are the dailies? [18:30] nm, found them [18:30] in the daily sub dir, not that i've checkeed my self [18:31] they look good [18:31] and it looks like v2.6.39 worked too, so i assume upstream fixed the bug [18:33] if someone finds out which commit fixed it i can rebuild the earlier ones with it [19:02] hello, why is detected as ethernet controller? Ethernet controller [0200]: Atheros Communications Inc. AR5001 Wireless Network Adapter [168c:001c] (rev 01) [19:03] njin: Because its PCI class header says it's an ethernet controller [19:04] mig59: and isn't detected as wirless device then ? [19:06] There's no PCI id for wireless [19:06] Only ethernet or generic network controller [19:07] It makes no difference to anything [19:07] ops, the wireless driver is used but don't work [19:08] mig59: thanks for the explicaton [19:08] mjg59, very amusing patch comment: https://lkml.org/lkml/2011/5/19/377 - how many more UEFI screwups await us? [19:09] Dell laptops with 4GB or more don't boot, but they seem to be dying in grub so that's probably not my problem [19:09] Several machines have just appeared with screwed up video setup, but again that's something the bootloader's going to have to deal with [19:09] So with luck we're ok in the kernel for now? [19:10] I obviously don't actually believe that when I say it [19:10] But I'm hoping that maybe we'll catch a break [19:10] I can see we are going to have many more years of dumb UEFI issues in the pipeline [19:19] cking: well if how buggy bioses have been is any indication ... [19:19] Let's solve the BIOS problem by making it even more complicated [19:22] hehe, yeah that sums it up nicely === hallyn_afk is now known as hallyn [20:13] * jjohansen -> lunch [21:10] running an errand [21:25] sforshee, thanks a lot for your support with kernel http://people.canonical.com/~sforshee/lp614238/linux-2.6.39-020639rc7.201105192014~lp614238/ [21:26] I will test it tonight or tomorrow [21:26] mfilipe, no problem, hopefully the fix does the job === kentb is now known as kentb-out [23:45] ogasawara: that test kernel worked for me [23:46] bdmurray: cool, thanks for testing. I'd pinged nessita too to test. [23:46] bdmurray: I'll probably send it to upstream stable === hallyn is now known as hallyn_afk