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