Same as above. Tries to build it, and dies messily when it turns out you never enabled the new stack (which, I imagine, will be pretty common for a while. E.g.,I use madwifi, and it definitely will be awhile before it's moved to the new stack, so it's pointless for me to build mac80211). Will attach revised ebuild. Also, should this and the other drivers (besides madwifi) also have their own local USE flags? Reproducible: Always Steps to Reproduce: 1.Build 2.6.22 kernel w/o mac80211 enabled 2.emerge hostapd 3.watch it die
Created attachment 124416 [details] revised hostapd-0.6.0.ebuild Checks if mac80211 was enabled in the kernel. If so, the corresponding hostapd driver will be built.
> mac80211="$(getfilevar CONFIG_MAC80211 ${KV_OUT_DIR}/.config)" Please, don't do such things. There's CONFIG_CHECK from linux-info eclass for such things.
(In reply to comment #2) > > mac80211="$(getfilevar CONFIG_MAC80211 ${KV_OUT_DIR}/.config)" > > Please, don't do such things. There's CONFIG_CHECK from linux-info eclass for > such things. > OK, but it spits out a warning or dies. The ebuild silently enables the option for that driver, just like three others in there. Why is it necessary to spew about something that is not configurable by a USE flag? And why was the ebuild allowed to make no check at all in the first place? After all, there's CONFIG_CHECK from linux-info eclass for such things. Besides, you clearly aren't going to use it, so does it really matter that I didn't get it exactly right? I had a problem. I made an attempt to solve it, which does work, but you would prefer it to be done another way. So show me how it's supposed to be handled.
Created attachment 124549 [details] hostapd vs. 2.6.22 vomit Ok. Actually, doesn't matter if mac80211 is enabled or not: it still dies horridly. Having 2.6.22 just makes it possible for the failure to occur. The mac80211 stuff should just go for now.
I have removed support for the mac80211 driver for now. I'll take a look again when the next version is released. Closing as REMIND