[03:10] <goldphish> Any Ubuntu kernel people around that could take a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911064 ?
[03:10] <ubot2> Launchpad bug 911064 in linux "Apple Bluetooth Keyboard Fn key not working" [Medium,Triaged]
[03:11] <goldphish> That bug had been open for a very long time and has a rather simple fix. You just need to patch a commit from 3.3 or 3.4 into Ubuntu's 3.2 tree.
[03:13] <RAOF> goldphish: Has that patch gone to -stable?
[03:14] <goldphish> The patch mentioned in bug 942184 was for an older 2.6.x kernel. The commits I reference in comment #25 are in mainline trees but for 3.3.x and 3.4.x series kernels.
[03:14] <ubot2> Launchpad bug 942184 in linux "The Fn key of my Apple keyboard doesn't work" [Medium,Fix released] https://launchpad.net/bugs/942184
[03:15] <goldphish> mainline 3.2.x kernels do not have the commits backported
[03:16] <RAOF> The reason I ask is that anything that gets sent to the 3.2 stable kernel will get folded into the Ubuntu kernel (pretty much) automatically. Is there a reason it *hasn't* gone to 3.2 stable?
[03:16] <goldphish> I'm guessing nobody has bothered to submit a duplicate patch.
[03:17] <goldphish> I'm not familiar with the backporting process or I would initiate that route.
[03:17] <goldphish> Reading the code I can't see any reason why it would not work.
[03:18] <RAOF> Generally when there's a small patch that fixes a bug it gets CCd: to stable, and the stable kernel process picks it up.
[03:20] <goldphish> Hmm not sure why the original contributors did not do that. 
[03:21] <goldphish> It doesn't feel right for me to copy their work and submit to 3.2 stable
[03:21] <RAOF> No, that's perfectly fine. You don't claim its your own work, just that it's (a) safe, and (b) should be fixed in stable. See also https://wiki.ubuntu.com/Kernel/Dev/KernelPatches
[03:24] <goldphish> oh nice, that doc is very helpful!
[03:24] <goldphish> Sadly my google searching for ubuntu kernel processes did not turn that up :/
[03:26] <RAOF> “site:wiki.ubuntu.com kernel dev” should get you useful pages pretty quickly.
[03:26] <goldphish> indeed will do that next time :-)
[03:26] <goldphish> So I'll prepare a patch, submit upstream and update the existing bug.
[03:27] <RAOF> That would be a good way to proceed.
[03:28] <goldphish> thanks
[04:00] <ppisati> moin
[05:22] <ppisati> http://www.engadget.com/2012/05/22/via-technologies-outs-49-apc-android-barebones/
[05:22] <ppisati> another inexpensive arm board
[05:22] <ppisati> unfortunately it's an armv6 chip
[06:13] <yo> hola
[06:39] <cooloney> ppisati: is that armv6, i assume it is an x86 board
[06:44] <_ruben> it's arm iirc
[06:50] <tjaalton> the quantal backport kenrel to precise hangs immediately after X has started, mainline 3.4 works fine
[06:50] <tjaalton> this on ivybridge
[06:51] <tjaalton> but the quantal one should be based on v3.4 as well, so wondering how that's possible
[06:54] <RAOF> tjaalton: The main quantal kernel works fine on my ivybridge, but that's not the backport kernel.
[06:55]  * smb is tired
[06:56] <tjaalton> RAOF: hmm, ok
[06:57] <RAOF> Possibly toolchain fun?
[06:57] <tjaalton> could be
[07:02] <tjaalton> oh, i've got quantal mirrored locally.. i'll just try that one then :)
[07:08] <tjaalton> nah, hung with that one too.. the lightdm login prompt cursor was blinking, mouse & keyboard didn't work but was able to ssh in. nothing suspicious, then it hung after a minute or so..
[07:10] <tjaalton> and why the heck is it using vesa
[07:19] <tjaalton> the hang is probably related to vesafb then, stopped lightdm and it's working fine so far
[07:21] <tjaalton> mainline 3.4 gets drm set up normally
[07:23] <tjaalton> duh, hung with that one too
[07:27] <RAOF> Ah. Well, then.
[07:29] <tjaalton> trying 3.3.7 next
[07:46] <jpds> http://people.canonical.com/~jpds/64-bit_x68_kernel.png
[07:47] <jpds> Is that 64-bit x86 PAE kernel a known typo issue?
[07:48] <jpds> bug #992414, I see.
[07:48] <ubot2> Launchpad bug 992414 in linux "linux-image-* package title and descriptions have packagers architecture rather than the contained architecture" [Medium,Fix committed] https://launchpad.net/bugs/992414
[07:59] <tjaalton> 3.3.7 is fine, but i want my overlayfs :)
[08:21]  * apw yawns
[08:21]  * apw watches his firewall upgrade ... while routing his traffic
[08:22] <smb> bzz
[08:25] <apw> yean, i didn't consider that during upgrades one might want to use the thing, nor did i consider the number of hours it would take
[08:25] <apw> and its not the fastest box in the world either
[08:33] <smb> Very true, it is amazing it works. I think I have to do the same but wanted to do it during the weekend.
[08:34]  * apw notes google won out on the patent infringment case with oracle
[08:39] <smb> We should trademark "patent infringement"... 
[08:43]  * smb wonders: how many months will it take for is, until they have fixed gomeisa...?
[08:44] <apw> man
[08:44] <smb> Guess, the answer my friend is blowing through rt...
[08:56] <jk-> heh
[09:20] <apw> smb, i've jollied the rt along we shall see
[09:20]  * apw notes he has finished his router upgrade and rebooted, and well i am still here
[09:21] <smb> apw, Thanks and congrats :)
[09:33] <henrix> doh
[09:34] <henrix> i just realised i dput'ed a precise package with -u kernelteam:lucid :-/
[09:35] <apw> henrix, ok that is probabally very bad
[09:35] <henrix> apw: yeah, probably it was a bad idea...
[09:35] <henrix> apw: i realised that because it failed to build
[09:36] <apw> if my experience is anything to go by we may have to delete the ppa and recreate it to allow us to upload lucid again
[09:36] <apw> which package is it
[09:36] <henrix> linux-backports-modules-3.2.0_3.2.0-25.9
[09:36] <apw> that said it is more recoverable than if you had done that to the archive itself, thats fatal forever
[09:37] <henrix> who shall i ping to help me sort that out?
[09:37] <apw> henrix, looking now ... i think we may have been lucky cause its LBM
[09:38] <apw> cause it is a version specific package so i think i can just delete it 
[09:38]  * henrix is surprised the impact of that is *that* bad!
[09:39] <apw> well if you upload a higher version of a package the version number can never go down
[09:39] <henrix> hmm... i see the problem
[09:39] <apw> so if you'd made this mistake with linux then we'd never be able to upload linux at a lower version number than the error version again
[09:39] <henrix> yeah, got it
[09:40] <apw> but as its lbm its linux-backports-modules-3.2.0 so actually even if the PPA remembers we likely don't care
[09:40] <apw> you may find you cannot upload it into precise either though, but lets first delete the erroring one
[09:41] <henrix> so, after sorting out this mess my next task will be to write a script that makes sure uploads will go always to the correct place!
[09:42] <henrix> and stop using dput directly :)
[09:42] <apw> henrix, its an annoying issue as normally you let the dput use whats in the package but there are no -proposed pockets in PPAs hense you need to type it, hense you can mess it up
[09:42] <apw> henrix, ok i've removed the bad pacakge, it takes a full publisher run to clear out
[09:43] <apw> then you may or may not be able to upload the package you have into precise.  it may claim the version number is already present.  but we'll worry about that if it happens
[09:43] <henrix> apw: ok, thanks. will try to upload it again later on
[09:43] <Caribou> apw: howdy : any reason why the -dbgsym packages would suddently disappear from http://ddebs.ubuntu.com/pool/main/l/linux/
[09:43] <apw> give it half an hour and then see
[09:44] <henrix> apw: ack
[09:44] <apw> Caribou, they are removed from there 14 days after the package in the main archive is deleted
[09:44] <Caribou> I found the pristine Natty kernel there last week (2.6.38-8-server #42)
[09:45] <Caribou> apw: ^
[09:46] <apw> Caribou, right, thats still in the archive
[09:46] <apw> Caribou, becasue its in the -release pocket, so its still held in the pool, and so the ddebs are held also
[09:47] <apw> Caribou, i thought arges was already mirroring these cause of this behaviour
[09:47] <Caribou> apw: yes, but unless I'm blind, they are no longer there : http://ddebs.ubuntu.com/pool/main/l/linux/
[09:48] <Caribou> apw: I'm working on this with arges
[09:48] <apw> ok which version are you looking for which isn't there ?
[09:48] <Caribou> apw: 2.6.38-8-server
[09:48] <diwic> Caribou, hmm, I think there was a UDS session about the ddebs, where they said they deleted some ddebs to free up disk space
[09:48] <diwic> Caribou, but I don't know how the selection was made
[09:48] <Caribou> diwic: I hope not
[09:48] <diwic> or don't remember, rather
[09:49] <apw> diwic, hmmm ...
[09:50] <apw> Caribou, hmmm, i concur it seems to be gone, asking pitti now if they have done something different or its 
[09:50] <apw> whether its broken
[09:50] <Caribou> apw: I'm sure it was there last week, I got a copy from there
[09:50] <apw> Caribou, ok they ran out of space and nuked them
[09:50] <Caribou> apw: luckily, I still have the extracted ddeb on a local machine
[09:51] <apw> its not clear what use hte ddeb from a natty -release kernel is, as noone in their right mind should need it
[09:51] <apw> but yes, it was that or lose the latest ones for the latest kernels it seems
[10:54] <apw> cooloney, smb, vv
[10:55] <apw>     Pull user namespace enhancements from Eric Biederman:
[10:55] <apw>      "This is a course correction for the user namespace, so that we can
[10:55] <apw>       reach an inexpensive, maintainable, and reasonably complete
[10:55] <apw>       implementation.
[10:55] <apw>     
[10:56] <cooloney> apw: hmmm, not sure about what's the enhancements from Eric.
[10:56] <cooloney> apw: any URL or email? smb told me some of Eric's patch were landed in linux-next
[10:56] <apw> cooloney, this is in linus master tree, merged overnight by the looks of it
[10:56] <apw> the beginning is worrying
[10:56] <apw>       Highlights:
[10:56] <apw>        - Config guards make it impossible to enable the user namespace and
[10:57] <apw>          code that has not been converted to be user namespace safe.
[10:57] <apw> in my version of english that implies usernamespaces are broken and off
[10:57] <apw> lets hope thats not what it means
[11:03] <apw> /git2/linux$ git log --oneline dd775ae2549217d3ae09363e3edb305d0fa19928..4b06a81 | wc -l
[11:03] <apw> 46
[11:03] <apw> smb, can you remember how many patches we were seeing in the userns branch serge was pointing us at ? ^^
[11:03] <cooloney> apw: does that mean new kernel with the patches from Eric will break our userspace namespace?
[11:03] <apw> cooloney, to be honest i have no idea, his english isn't very accurate so i cannot fathom the meaning with cirtainty
[11:04] <apw> i am suspecting i am going to be asking you and smb to work that out sharpish :)
[11:07] <apw> cooloney, i think he is saying that the bits which arn't converted will be impossible to turn on or build, but i am not clear
[11:08] <cooloney> apw: no problem. i can dig into it
[11:08] <cooloney> thanks for pointing out this
[11:08] <cooloney> you know merging window sometime is crazy
[11:08] <apw> cooloney, and it may not be complete yet, as in there may be more to merge sometimes they do that
[11:09] <apw> though it does sound about the size he was suggesting might be merged in 3.5
[11:11] <cooloney> apw: totally 46 patches
[11:11] <apw> yeah so about 1/3rd if my memory is complete
=== BenC__ is now known as BenC
[12:05] <apw> bjf, hey i see your PPA is nearly full ... i assume we can always delete the 'newer version available' ones right ?
[12:19] <apw> diwic, henrix is having terrible trouble with mumble, with pulse
[12:19] <apw> diwic, oh typically he has sorted himself perhaps
[12:20] <diwic> apw, for the wrong device being selected, did you try mumble from my ppa?
[12:20] <apw> i did some time back and i seem to remember it didn't change anything
[12:20] <apw> or was there a second attempt ?
[12:20] <diwic> apw, well, there was one bug in g-c-c and one in mumble, IIRC. And the g-c-c one should be fixed by now
[12:21] <henrix> diwic: i may try that ppa actually 
[12:21] <apw> diwic, oh yeah there was the volumn not beeing tracked right on mics, that is deffo fixed
[12:21] <diwic> henrix, if your problem is that you select "default device" in mumble, and it does not update when you select a default device in the sound settings, that's what it's supposed to help against
[12:22] <apw> diwic, and there was the mumble using default device, but i tried your PPA for that and it didn't work
[12:22] <apw> as in it was still wrong, though i have mumble bolted to my snowball now
[12:22] <apw> so i don't notice it
[12:24] <diwic> apw, did you test it with the latest g-c-c that was released nine  days ago into precise-updates?
[12:25] <diwic> 1:3.4.1-0ubuntu2 to be exact
[12:30] <apw> henrix, i so need the system to know that the d in your name is optional
[12:31] <henrix> apw: what you mean by 'd'?
[12:33] <henrix> ouch! just took a look at the new bugs, and it looks like there's something really bad going on on initramfs generation
[12:38] <apw> henrix, hendrix is what my fingers type when i type your name ... call me old
[12:38] <apw> henrix, on the 24 hours jobbie ?
[12:38] <henrix> apw: ah! right! :D
[12:38] <henrix> apw: yep, the 24 hours thingy
[12:39] <apw> henrix, this may not be a new issue more than a lot of people upgrading right now of course
[12:39] <apw> dammit why does it report bugs in the native language ... 
[12:40] <henrix> true. but it does look like these reports were already running precise
[12:42] <smb> apw, There were many... 30 ... 46 all is many to me
[12:42] <smb> apw, And yeah we will find out at some point
[12:42] <smb> apw, And I believe deletion in the ppa is a manual job
[12:45] <apw> smb, yeah its manual, and i am pretty sure we don't need 'em in there either
[12:46] <smb> No anything superseded in any way is rather useless
[12:46] <Caribou> apw: any luck with rebuilding natty's dbgsym pkg ?
[12:46] <smb> deleting can be a pain as you need to not exceed too many in one request
[12:46] <Caribou> apw: I have a copy of the other one, so no rush, just so I can test yours
[12:46] <apw> Caribou, actually yes
[12:47] <Caribou> apw: want me to test it ?
[12:47] <apw> Caribou, just copying them now, this is not quick
[12:50] <apw> Caribou, http://people.canonical.com/~apw/ddeb/
[12:51] <apw> tgardner, can you add a WI to the backports thingy for me to get that automation done
[12:51] <tgardner> apw, there is a backports thingy ?
[12:52] <apw> security-q-kernel-backports
[12:52]  * apw saw you updating it
[12:52] <tgardner> ah, taht one. too many blueprints
[12:52] <Caribou> apw: got the one I needed
[12:53] <apw> Caribou, ok cool ... let me know if they work as i can then make you any others you need i guess
[12:54] <Caribou> apw: works fine ! just complain about kernel version diffs but nothing to worry about
[12:54] <Caribou> apw: this one in particular was a problem. I was able to rebuild the -14 myself.
[12:55] <Caribou> I'll work with arges to build a local mirror
[12:55] <Caribou> apw: thanks for your help, at least now I know that I wasn't doing something wrong when I tried to build it
[12:55] <arges> apw, Caribou what happened with the build?
[12:56] <Caribou> arges: looks like apw was able to fix things
[12:56] <tgardner> apw, this one ? https://blueprints.launchpad.net/ubuntu/+spec/security-q-kernel-backports - I don't think its the right one for an automation WI.
[12:56] <apw> Caribou, yeah that was definatly a "kernel version running on the build system" error
[12:57] <apw> tgardner, ok ... erm perhaps just shove it on the versions and flavours then, just so i don't forget
[12:57] <tgardner> apw, yeah, that one is more like it
[12:57] <apw> arges, yuo can't build the very early natty kernels on a machine running 3.x the make fails
[12:58]  * apw waits to find out if Caribou can use the rebuilt ddeb or not, useful to know if they are regeneable
[12:58] <Caribou> apw: yes it works fine, I think you missed me mentioning it
[12:59] <arges> apw, i though the builds were done in a fakeroot
[12:59] <arges> but i guess the kernel version would be the same still
[12:59] <Caribou> apw: crash just complains about version discrepancy but nothing to worry about
[12:59] <apw> Caribou, ahh yes i should have built it without a version suffix, silly me
[12:59]  * apw will likely rebuild and get you to retest, just so i have the process down pat
[13:00] <Caribou> apw: it's not a problem really. actually, I prefer it that way
[13:00] <apw> oh ok, then i wont :)
[13:00] <tgardner> apw, added to https://blueprints.launchpad.net/ubuntu/+spec/hardware-q-kernel-version-and-flavors
[13:00] <apw> tgardner, thanks
[13:00] <Caribou> apw: this way we can know if they were 'rebuilt' or coming from the original build
[13:00] <apw> Caribou, yeah a point indeed
[13:01] <apw> Caribou, is there any others you need while i am in the process ?
[13:02] <arges> apw, are you just building from scratch or using scripts?
[13:02] <Caribou> apw: no, all the crashes I have are from the same kernel, thanks
[13:03] <Caribou> apw: but yeah, might be a good idea to tell arges how you did it, in case we need to rebuild some later
[13:03] <apw> arges, just doing a full build on our builders so i get ddebs and udebs
[13:03] <apw> arges, so literally just building using 'full_build=true' on the command line
[13:03] <arges> gotcha
[13:04] <apw> its good to know they are at least vagluly usable when made that way
[13:05] <Caribou> apw: I would have been surprised of the contrary : I spent hours rebuilding SLES9 kernels because SuSE never made the debuginfo kernels available
[13:06] <apw> Caribou, i would have hoped, and even assumed they would be, but knowing is so much nicer
[13:06] <Caribou> apw: :)
[13:06] <Caribou> apw: arges now back to trying to identify the KSM corruption
[13:39] <dileks> hi
[13:40] <dileks> if I rebuild a package destinated for quantal on a precise host, to which distribution I shall assign it? precise | precise-proposed | precise-backports | etc.?
[13:41] <tgardner> dileks, it hardly makes any difference unless you intend to upload it to a PPA
[14:05] <jsalisbury> tgardner, Is someone free to take a look at bug 1003793
[14:05] <ubot2> Launchpad bug 1003793 in linux "broadcom wireless does not work with quantal-backport-kernel" [High,Confirmed] https://launchpad.net/bugs/1003793
[14:07] <tgardner> jsalisbury, hmm, seems like a dkms issue.
[14:08] <jsalisbury> tgardner, I added it to the hot list due to the "Reported by"
[14:08] <tgardner> jsalisbury, I happen to have the same HW. lemme explore it a bit.
[14:08] <jsalisbury> tgardner, cool, thanks!
[14:14]  * ppisati -> brb
[14:28]  * apw finds his dhcp server got deconfigured on upgrade
[14:28] <apw> so everything broken an hour after
[14:39] <apw> bug #1003971
[14:39] <ubot2> Launchpad bug 1003971 in isc-dhcp "on upgrade lucid -> precise /etc/default/isc-dhcp-server is not migrated" [Undecided,New] https://launchpad.net/bugs/1003971
[14:41] <tgardner> apw, that seems pretty  serious
[14:42] <apw> tgardner, yeah, a point, will bring it up on #ubuntu-server
[14:42] <apw> i assume we want these sorts of things resolved for .1
[14:43] <tgardner> apw, you'd think so
[14:43] <tgardner> apw, maybe you should target that milestone lest skaet miss it.
[14:45] <apw> tgardner, done ... so
[14:45] <apw> hmmm it went confirmed already someone metoo'd it
[14:50]  * ogasawara back in 20
[14:54]  * apw notes that we are now anonymising ipv6 addresses outgoing ... cool
[14:55] <dileks> privacy extensions?
[14:57]  * ppisati -> gym, before the rest of the world goes there too...
[15:16] <apw> dileks, yeah somthing like that, random addresses as primary on the interfaces
[15:33] <apw> ahh now my ipv6 is unreliable
[15:37]  * tgardner grows old whilst watching a Dell mini-10 install 12.04
[15:46] <jsalisbury> tgardner, bjf, I've been seeing allot of apt-get bugs today like bug 1002388  
[15:46] <ubot2> Launchpad bug 1002388 in linux "package linux-image-3.2.0-24-generic 3.2.0-24.38 failed to install/upgrade: subprocess installed post-installation script returned error exit status 17" [Medium,Confirmed] https://launchpad.net/bugs/1002388
[15:46] <jsalisbury> tgardner, bjf The common error is:
[15:46] <jsalisbury> Setting up linux-image-3.2.0-24-generic (3.2.0-24.38) ...
[15:46] <jsalisbury> Running depmod.
[15:46] <jsalisbury> Failed to symbolic-link /boot/initrd.img-3.2.0-24-generic to initrd.img: File exists
[15:46] <jsalisbury> dpkg: error processing linux-image-3.2.0-24-generic (--configure):
[15:46] <jsalisbury>  subprocess installed post-installation script returned error exit status 17
[15:46] <jsalisbury> Errors were encountered while processing:
[15:46] <jsalisbury>  linux-image-3.2.0-24-generic
[15:48] <henrix> jsalisbury: yeah, i saw that too... i guess there's something really wrong with the initramfs generation. didn't had a chance to take a closer look yet
[15:49] <jsalisbury> henrix, yeah.  or maybe the install script changed?  
[15:50] <henrix> jsalisbury: maybe
[15:50] <henrix> jsalisbury: but there are a bunch of bugs
[16:16] <ogasawara> apw: you've got a netbook with broadcom wifi?  Could you test the 12.10 lts kernel from the PPA https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
[16:16] <tgardner> ogasawara, working on it.
[16:16] <apw> ogasawara, using which driver ...
[16:17] <apw> tgardner, i assume you are talking about the brcm ?
[16:17] <tgardner> apw, yep. I have the exact same dell mini-10
[16:17] <apw> ack
[16:17] <ogasawara> tgardner: ah cool, thanks
[16:17] <tgardner> apw, I've just now gotten precise installed. took nearly 2 hours
[16:18] <apw> tgardner, heh then it'd be rude for me to just test it
[16:18] <tgardner> apw, if you've got one installed, then feel free.
[16:19] <apw> tgardner, oh but ... i have a Q kernel on that machine already
[16:19] <apw> tgardner, and i am noticing i have to modprobe brcmsmac before it does anything
[16:19] <apw> tgardner, is that the complaint ?  i wonder if its that option you turned on ogasawara for the non-overlapping ids
[16:20] <ogasawara> apw: rickspencer3 is dogfooding and claiming jockey vomits if he tries to active the driver
[16:21] <apw> god, he used jockey, is that wise with a newer kernel
[16:21] <tgardner> ogasawara, as it should. we're not backporting dkms drivers, so perhaps this is a jockey bug ?
[16:22] <apw> tgardner, but as i say there is also something stopping brcmsmac working right with that kernel
[16:22] <apw> tgardner, which i bet is why he is running jocky in the first place
[16:22] <tgardner> apw, I'll have a look at the overlap config
[16:23] <tgardner> apw, according to the bug he didn't try jockey until after his wifi wouldn't work
[16:23] <apw> right which would fit the symtoms i am reporting
[16:23] <apw> i have to run sudo modprobe brcmsmac with mine
[16:23] <apw> after reboot each time, not had a chance to track it
[16:24] <tgardner> apw, I'll bet there are some modalias issues then
[16:24] <apw> right, and i remember ogasawara turngin somethign off recenting for brcm something perhaps its wrong
[16:24] <tgardner> apw, CONFIG_B43_BCMA_EXTRA
[16:25] <sforshee> apw, is bcma being loaded?
[16:27] <apw> tgardner, hmmm i am finding brcmsmac works well for me, but doesn't autoload
[16:27] <apw> tgardner, so i'd say its not that then, but we do need to find out why its not autoloading at all
[16:28] <ogasawara> apw: I thought we had another brcmsmac sauce patch regarding autoloading, /me digs back through the git logs
[16:28] <apw> hmmm maybe we lost it then, that would expalin a lot
[16:28] <apw> ogasawara, i have a test bed for that one if you find it
[16:30] <sforshee> apw, bcma should be loaded for the pci device, it will create a bcma: device that brcmsmac should match
[16:30] <sforshee> so first thing to check is that bcma is loading
[16:32] <apw> sforshee, rebooting now
[16:32] <sforshee> ogasawara, apw, tgardner: fwiw brcmsmac autloads okay for me with BCM43224
[16:33] <ogasawara> bug 1003793
[16:33] <ubot2> Launchpad bug 1003793 in linux "broadcom wireless does not work with quantal-backport-kernel" [High,Confirmed] https://launchpad.net/bugs/1003793
[16:33] <sforshee> the autoloading changed from 3.2 -> 3.4, brcmsmac used to match pci ids but now matches on bcma devices
[16:33] <apw> sforshee, so no brcma
[16:34] <sforshee> apw, bcma, no r
[16:34] <apw> sforshee, not that either
[16:34] <tgardner> sforshee, its still got 'MODULE_DEVICE_TABLE(bcma, brcms_coreid_table)'
[16:34] <apw> if i manually load that should brcmsmac load then ?
[16:34] <sforshee> apw, likely
[16:35] <sforshee> what's the modalias for the pci dev?
[16:36] <sforshee> tgardner, in 3.2 or 3.4?
[16:36] <tgardner> shadeslayer, 3.4
[16:36] <tgardner> sforshee, ^^
[16:36] <shadeslayer> huh? oh .. ok
[16:36] <sforshee> tgardner, right. In 3.2 it was a PCI device table
[16:36]  * shadeslayer was surprised for a moment there, having done no kernel work and being highlighted in #ubuntu-kernel
[16:39] <tgardner> sforshee, still waiting for this dell mini-10 to update. then I can look at the module aliases for Quantal 3.4. I'm suspecting that is the root of the issue, especially since things work OK after manually probing.
[16:39] <ogasawara> apw: scratch my comment about a sauce patch for autoloading, it was a sauce patch to allow brcsmac and b43 to both build
[16:39] <sforshee> tgardner, all the pci ids that were in brcmsmac are in bcma, so I don't know why bcma wouldn't be loading
[16:39] <sforshee> apw, you don't have bcma blacklisted, do you?
[16:39] <tgardner> sforshee, 'cause the brcmsmac IDs are for a bcma device, not PCI.
[16:40] <sforshee> tgardner, but apw says bcma isn't loading, and it should match the id
[16:40] <sforshee> then bcma creates a device that brcmsmac matches
[16:40] <tgardner> sforshee, yeah, bcma should load.
[16:40] <apw> sforshee, ahh yes i do ... cause i have wl installed
[16:40] <sforshee> apw, that's your problem then :)
[16:41] <apw> and i bet that is also ricks problem, i bet he has wl installed so everything is disabled
[16:41] <tgardner> sforshee, so with 3.2 bcma loads b43.
[16:41] <apw> but i bet wl doesn't compile ... so he has nothing
[16:42] <sforshee> tgardner, I think what happens is that brcmsmac probes before bcma and thus matches on the device first
[16:42] <apw> sforshee, ok will reboot witht hat and see if it resolves
[16:43] <apw> sforshee, but i bet he has wl installed, we should ask
[16:43] <sforshee> tgardner, because both match on that pci id in 3.2
[16:44] <apw> sforshee, ok that worked, bcma and brcmsamc are now both loaded and i have wifi.  so that is just a me config cause i wanted wl installed to i know if it blows up, but not being used so i test the real version
[16:44] <apw> but as i say i bet this is a wl not working and installed iss
[16:44] <apw> issue
[16:45] <ogasawara> apw: what's the package name again that provides the wl driver?
[16:46] <tgardner> bcmwl-kernel-source
[16:46] <tgardner> ogasawara, ^^
[16:46] <ogasawara> thanks
[16:46] <apw> yep that thing
[16:48] <tgardner> apw, we should write a patch for module-init-tools that blacklists on a per-kernel basis
[16:49] <apw> tgardner, yeah and we have a WI for that, but in this case its carried by wl so it still would mess us up
[16:49] <sforshee> tgardner, to fully explain the situation: b43 will still match the same bcma ids as brcmsmac if CONFIG_B43_BCMA_EXTRA is enabled, which is why we want it disabled
[16:49] <sforshee> it was racy before, but in a way that worked out in brcmsmac's favor
[16:49] <tgardner> sforshee, I think it is disabled.
[16:49] <sforshee> when brcmsmac moved to matching on bcma it worked out in b43's favor
[16:50] <sforshee> tgardner, yes, I sent a patch for that last week
[16:50]  * apw thought i saw it applied
[16:50] <apw> no idea if its uploaded mind
[16:50] <tgardner> # CONFIG_B43_BCMA_EXTRA is not set
[16:50] <tgardner> this is from the LTS backport kernel
[16:50] <sforshee> yep, I think it went in with the last upload
[16:51] <tgardner> lsmod|egrep ^b
[16:51] <tgardner> b43                   351462  0 
[16:51] <tgardner> bnep                   17790  2 
[16:51] <tgardner> btusb                  17888  0 
[16:51] <tgardner> bluetooth             185648  24 bnep,btusb,rfcomm
[16:51] <tgardner> bcma                   26123  1 b43
[16:51] <tgardner> rtg@m10:/boot$ uname -a
[16:51] <tgardner> Linux m10 3.4.0-3-generic #7~precise1-Ubuntu SMP Tue May 22 20:22:09 UTC 2012 i686 i686 i386 GNU/Linux
[16:51] <tgardner> 03:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g LP-PHY (rev 01)
[16:52] <tgardner> sforshee, so, this is doing about what I would expect.
[16:52] <sforshee> tgardner, brcmsmac probably doesn't support that one
[16:52] <tgardner> right
[16:52] <tgardner> apw, what model do you have ?
[16:54] <tgardner> sforshee, incidentally, b43 on this machine doesn't work for shit.
[16:54] <sforshee> tgardner, performance, reliability, or both? My experience is that b43 reliability is fine, but performance sucks
[16:55] <tgardner> sforshee, doesn't even scan a beacon
[16:55] <sforshee> tgardner, what machine? It's not a macbook, is it?
[16:55] <tgardner> dell mini-10. its a few years old
[16:56] <sforshee> okay, no ideas then
[16:58] <tgardner> sforshee, huh, could be I need firmware.
[16:59] <apw> tgardner, ahh yes, mine loaded b43 (the dell mini 10) and that bitched about firmware
[16:59] <sforshee> tgardner, is firmware loading failing? now that you mention it I recall seeing a thread on linux-wireless about that in the past few days...
[16:59] <apw> tgardner, as i am not using it on there, i rmmod'd it
[16:59] <apw> (just noticed half an hour ago when tyring to work out why my network kept stopping)
[16:59] <apw> and now i know, its cause my firewall reneabled 'suspend on lid close' on upgrade ... POS
[17:00] <sforshee> tgardner, http://article.gmane.org/gmane.linux.kernel.wireless.general/91341
[17:01] <tgardner> sforshee, I just read that one this AM, but its more of a load race then anything. I simply didn't have the firmware on disk.
[17:02] <sforshee> tgardner, oh yeah, that's a problem
[17:02] <tgardner> apt-get install linux-firmware-nonfree
[17:02] <tgardner> sforshee, now it connects.
[17:03] <tgardner> ok, back to loading the LTS kernel
[17:12] <ogasawara> tgardner: keep me posted how the lts kernel goes after installing linux-firmware-nonfree.  I think rick's running into the same hurdle but he's gotta drop off and will pick back up tomorrow morning.
[17:12] <tgardner> ogasawara, it seems to work fine. wl would definitely screw things up
[17:13]  * sforshee -> lunch
=== tgardner is now known as tgardner-lunch
[18:10] <ogasawara> jsalisbury: for bugs coming in against the 12.10 kernel in 12.04, can you make sure they are tagged 'qa-kernel-lts-testing '
=== tgardner-lunch is now known as tgardner
[18:12] <ogasawara> jsalisbury: in the future, once apport is fixed to allow bug reporting when running the backport kernel, you should be able to edit our bug processing scripts to grep for ~precise in the version string and have it add the tag automatically
[18:13]  * smb -> beer
[18:14] <jsalisbury> ogasawara, will do
[18:16] <jsalisbury> ogasawara, Do you know if there is an apport bug opened to allow bug reporting when running the backport kernel?
[18:16] <ogasawara> jsalisbury: there isn't
[18:16] <ogasawara> jsalisbury: or at least none that I'm aware of
[18:18] <jsalisbury> ogasawara, should I open one, or is there already a work item somewhere to add that functionality 
[18:18] <ogasawara> jsalisbury: I was going to add a work item to one of our blueprints so it stays on our radar.  If you want to open a corresponding bug for it, feel free
[18:18] <jsalisbury> ogasawara, cool, thanks
[18:27] <jsalisbury> ogasawara, opened a corresponding bug 1004101
[18:27] <ubot2> Launchpad bug 1004101 in apport "[RFE] Allow Bug Reporting When Running Backport Kernel" [Undecided,New] https://launchpad.net/bugs/1004101
[18:28] <ogasawara> jsalisbury: thanks
[18:29] <jsalisbury> ogasawara, np.  It's just a skeleton, since I didn't add many details.
[20:18] <arges> tgardner, started to look at pad.lv/669641  , anything you need help with to get that one fixed?
[20:19] <arges> or rather i was going to, but just saw you assigned it to yourself
[20:20] <tgardner> arges, huh, I guess I forgot about it. UDS likely got in the way. feel free to take it over.
[20:21] <arges> tgardner, sure. was at the end of my to-do list and just got to it
[20:48] <jsjgruber-x-p> Where's the browsable kernel git repo? The one mentioned on the kernel wiki page seems to be gone-- kernel.ubuntu.com/git
[20:52] <ogasawara> jsjgruber-x-p: which specific Ubuntu kernel are you interested in?  http://kernel.ubuntu.com/git still looks valid to me
[20:56] <jsjgruber-x-p> ogasawara, I'm trying to help someone on askubuntu. He wants to know where to look to see where apparmour patches were dropped from the kernel. When I go to that url . I just tried it again and it came up. Sorry for the bother.
[21:10]  * tgardner -> EOD
[21:57] <hggdh> question: will the LTS backports always have a meta-package ending in 'lts-backport-<version>'? like linux-image-lts-backport-quantal?
[22:50] <jMCg> Let's go to
[22:50] <jMCg> O_o interesting. I think that ended up in the wrong channel.
[22:51] <jMCg> Anyway, hey folks o/~ I'm debugging a problem with a Ubuntu 10.04 VM not booting in KVM. All I can see in the VNC is this:
[22:51] <jMCg> init: ureadeadahead main (372) terminated with status 5
[22:54] <jMCg> So, if someone has an idea what this is, or how to properly debug it, how to get more info out of it, Ihmmmm.. Have I configured stuff for serial console properly, I wonder..
[22:58] <RAOF> hggdh: We don't know yet; it's planned to rename (as *-backports-* is associated with danger by some customers), but I don't know to what.
[23:06] <hggdh> RAOF: k, thank you. I will base my scripts on the current naming; I do hope you folks give me some advance notive when it changes ;-)
[23:06] <hggdh> s/notive/notice/