On Mon, 2013-11-18 at 15:28 -0800, Jason Mobarak wrote: > The problem, I think, was that CRYPTO_CCM was added as a dependency of > of MAC80211 in the meantime. I discovered this by using menuconfig to > figure out what config flags where causing MAC80211 to be disabled...
Yeah, I guess that's really the best way. I don't see a good way to print out "You can't do this in your defconfig because of CONFIG_XXX". > At first, to address this, I tried adding "crypto/" and > "drivers/crypto/" to "copy-list" and regenerating (which also > requiring some sed manipulation of the CONFIG_ flags)... That wouldn't really work. > However, the more "correct" solution (which didn't require any changes > to backports) was to just enable CYPTO_CCM as a module in the kernel > backports was being compiled against. Right. FWIW, I have a backport of crypto-ccm, but it's kinda ugly: http://p.sipsolutions.net/f70f203dd2bfbd67.txt (Note the patch is diffed in a subdirectory and a bit messy, but you'll get the point) I don't think we should merge this into backports though since all distro kernels will have CRYPTO_CCM enabled, and everybody else will just have to know I guess. > So... my question is, is this a bug? And/or is there a better way to > detect this situation in the future? Well, it's not really a bug - the dependencies changed but what they need is in every kernel since 2.6.25 or something like that. johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
