[06:54] <ggvaberi> hello. is possible to debug rmmod process?
[10:38] <xnox> I have tried to re-build a kernel with extra patches, but it failed with:
[10:38] <xnox> II: Checking modules for generic...previous or current modules file missing!
[10:38] <xnox>    /«PKGBUILDDIR»/debian.master/abi/3.11.0-0.4/i386/generic.modules
[10:38] <xnox>    /«PKGBUILDDIR»/debian.master/abi/3.11.0-0.3/i386/generic.modules
[10:38] <xnox> what piece of packaging magic did I miss? =)
[11:24] <smb> xnox, you probably added a new section in the changelog, which then reguires debian.master/abi/3.11.0-xxx to be adapted to be the previous version. Or, if you do not need a nice changelog, just change the version number of the current section
[11:24] <smb> which works around this
[11:26] <xnox> smb: i see. i've now pulled 1.4 kernel and I think kept the changelog as it was, so hopefully should work.
[11:27] <xnox> smb: but first time around after initial abi bump, you just copy across the debian/abi/*/ from each arch?
[11:27] <xnox> it built \o/ now, I should do the config review ;-)
[11:28] <smb> xnox, That should work. For test kernels I usually go for the modify last version path. No, we pull in the last versions from the builds. But renaming most of the times would work
[11:28] <xnox> smb: ok. cause abi is fairlyish stable.
[11:29] <xnox> ls
[11:29] <smb> no files found
[11:29] <xnox> =)
[11:29] <xnox> smb: are you planning on pulling focus-follows-eyesight patches for dual-screen monitors? or that still breaks hangouts =)))))
[11:30] <smb> xnox, bumping abi and renaming the directory would always work as the checking is less strict.
[11:30] <smb> xnox, not the one doing any new features
[11:31] <smb> but it would be an interesting feature, especially when I have to look to the ceiling for help
[11:32] <xnox> smb: just to let you know. I've pulled patches into ubuntu .11 kernel to support minnowboard, which builds fine, now i need to check that config is sane (cause it's 32-bit UEFI system), next week I will receive minnowboard and will try to boot it & make installer image for it.
[11:33] <xnox> and if that works, i will make pull request =)
[11:38] <xnox> config looks ok. so shelving until i get the hardware.
[11:38] <smb> xnox, I think you will need to talk to the upstream hand about that and I doubt it thinks 32bit EFI is something sensible
[11:38] <xnox> smb: i'm in touch with Intel folks =) and yeah 32bit EFI is madness but that's the reason I'm trying to play with this =)
[11:39] <smb> Suppose you don't have to be mad to do this but it helps. :-P
[11:40] <xnox> minnow board is the cheapest way to bring up support for the new expensive "intel atom, 32-bit, uefi-only, touch/laptop convertibles"
[11:44]  * henrix -> lunch
[15:25] <rtg> jjohansen, I plan to install a 3.11 kernel on tangerine this morning.
[15:38] <jjohansen> rtg-afk: ack
[20:27] <rtg> jsalisbury, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1201092/comments/26
[20:27] <ubot2`> Ubuntu bug 1201092 in linux (Ubuntu) "Cannot load kvm_amd module - (says disabled by bios)" [High,Confirmed]
[20:46]  * rtg -> EOD
[21:38] <s0u][ight> hello, I have a kernel related question. There was a bug with kernels before 3.3 that would cause mac80211 drivers to give the wrong channel number to a monitor interface, but since 3.3 this should be fixed. However, on 13.04 i still get this error
[22:12] <infinity> s0u][ight: That would seem to imply it's not fixed in 3.3, then.  Unless it regressed.  How do you know it was fixed in 3.3?  Do you have a pointer to the relevant commit?
[22:13] <s0u][ight> infinity, http://www.aircrack-ng.org/doku.php?id=compat-wireless
[22:14] <s0u][ight> it says about the patch for negative one that it is only required for versions prior to 3.3
[22:17] <infinity> s0u][ight: That's for compat-wireless releases, not upstream kernel releases.  Furthermore, that bit of code (patches or unpatched) doesn't appear to exist in the kernel at all...
[22:17] <s0u][ight> infinity, https://patchwork.kernel.org/patch/913852/
[22:20] <infinity> Like I said, that bit of code doesn't appear to exist at all anymore.
[22:21] <infinity> I imagine it got factored into non-existence.
[22:21] <infinity> Are you sure you're seeing the same bug that patch was meant to fix?
[22:21] <infinity> If so, please file a bug ("ubuntu-bug linux")
[22:22] <s0u][ight> i'm not sure if the bug is because of the same error, but yes i get the same symptoms as that one
[22:23] <s0u][ight> infinity, this is what i get from the irc bot on #aircrack-ng:  fixed in Kernel or compat-wireless 3.3_rc1 or higher
[22:23] <infinity> Right, well.  It could have regressed when chan.c was refactored and largely rewritten.
[22:24] <infinity> Cause it looks a lot different than it did in 3.3
[22:24] <infinity> So, please file a bug and explain the exact symptoms, and feel free to copy and paste our above IRC conversation.
[22:24] <s0u][ight> infinity, to the bugtracker of ubuntu or kernel in general?
[22:25] <infinity> Like I said, run "ubuntu-bug linux"
[22:25] <infinity> And mention which wireless driver you use.  If those interfaces were rewritten, it might not be that they're still buggy, but that a driver was poorly ported to the new world order.
[22:26] <s0u][ight> infinity, sounds ignorant but it's not only my driver (brcmsmac)
[22:27] <infinity> sforshee: If you're around, feel free to address the above. :P
[23:09] <s0u][ight> infinity, if I would download and compile compat-wireless 3.3, try that driver and see if it was really fixed back then, is that alright?
[23:15] <infinity> s0u][ight: It could be a helpful data point, perhaps.
[23:16] <s0u][ight> :/ compile errors
[23:16] <s0u][ight> gonna try with a later version
[23:20] <infinity> Well, to be fair, I'm not sure I'd expect cw-3.3 to work with >> 3.3 kernels.
[23:20] <infinity> Since that's kinda not the point.
[23:20] <infinity> It's meant to be a backport of the 3.3 stack to older kernels, not the inverse.
[23:21] <s0u][ight> i kinda assumed it would work, with the limitations of older drivers