=== shengyao_afk is now known as shengyao
=== xnox_ is now known as xnox
[04:57] <trippeh> dang. wireless-regdb really could use a update.
[04:58] <trippeh> 11ac seems gimped even in vivid
[04:59] <trippeh> at least for .no
=== rsalveti_ is now known as rsalveti
[17:38] <apw> trippeh, could you file a bug against crda or whateevr it is called and let us know the bug number here. 
[17:42] <apw> trippeh, wireless-regdb is separate ... so that indeed.
[17:51] <Novelocrat> Is there a mechanical or enumerated correspondence between the names of kernel modules (as used by modprobe and listed by lsmod) and the CONFIG_* options in .config that control their compilation? I'd like to programmatically disable building (CONFIG_...=n) any unit that the distro's maintainers built as a module that I don't have loaded.
[17:59] <apw> Novelocrat, not that i know of, i think that is a tricky one to map too, as that mapping is essentially defined by the Makefile rules themselves.
[18:01] <Novelocrat> Ok, so if we wanted that sort of thing, someone would have to patch basically the entire kernel to create that correspondence
[18:22] <apw> yeah, it is pissible the mod info has other hints ...
[18:22] <Novelocrat> looks like 'make localmodconfig' does approximately what I want
[19:13] <trippeh> apw: there was a bug already, bug 1284093
[19:13] <ubot5> bug 1284093 in wireless-regdb (Ubuntu) "Please update regulations to support VHT" [Undecided,Confirmed] https://launchpad.net/bugs/1284093
[19:15] <trippeh> looks like debian is sometimes updating it to match upstream even in stable, so :)
[19:54] <apw> trippeh, then we ought to be able to merge that with luck ...
[20:10] <ius> Can anyone tell how the extended stable kernels are related to the shipped releases? Specifically:
[20:11] <ius> I've tracked down this OOPS: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1296660 which seems to have an upstream fix in v3.18
[20:11] <ubot5> Launchpad bug 1296660 in linux (Ubuntu) "Kernel oops: fb: conflicting fb hw usage astdrmfb vs VESA VGA (unable to handle kernel NULL pointer dereference / con_set_unimap+0x32" [High,Confirmed]
[20:11] <ius> I also noticed it was backported to the extended stable http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=commit;h=c00b3bcf1e2e9531d1816c220fbac0852eaa4bd6
[20:13] <ius> Does that mean it'll end up in the Trusty release kernel eventually? I can't tell whether someone skipped that patch or that it's yet to land automagically..
[20:14] <apw> the extended stables are pulled in fairly regularly, roughly every 3 weeks
[20:18] <ius> So if a fix is present in the extended stable it should get fixed without any further action on my end.. ..soon?
[20:22] <apw> in theory, wtiting up that info in the bug would help
[20:40] <ius> Actually, as I'm reviewing it now, I found the Trusty git repo and noticed it was pulled in for 3.13.0-44.73
[20:41] <apw> ok good.  well note that too in the bug, then we can close it out
[20:53] <ius> Right. I've done so, didn't touch the bug status (besides, I'm unable to test, but based on my best judgment + disassembly the fix should be correct)
[20:53] <ius> Thanks.
[22:42] <apw> ius, if you are unable to reproduce after the update, that might be meaningful, maybe
[22:57] <ius> I can't really test it in a meaningful way, I've got no console access to the box to determine how often it currently panics. Traced the OOPs back to the line that's patched though, and it makes sense. I'll wait for someone else to ack it though.