new version is out, needs a little hack/patch for compiling on old mac80211 iwl4965 users please use latest mac80211 Reproducible: Always
Created attachment 124548 [details] net-wireless/iwlwifi/iwlwifi-0.1.1.ebuild the new ebuild (works fine with iwl3945 (set useflag))
Comment on attachment 124548 [details] net-wireless/iwlwifi/iwlwifi-0.1.1.ebuild This now requires kernel 2.6.22+. Please attach a patch against the below revision if needed, net-wireless/mac80211 is not supported. http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-wireless/iwlwifi/iwlwifi-0.0.36.ebuild?rev=1.2&view=markup
There is something funky about this If no useflags are given, build everything? anyway, it is equivalent to this, do to defaults: if ! use iwl3945; then BUILD_PARAMS="${BUILD_PARAMS} CONFIG_IWL3945=n" fi if ! use iwl4965; then BUILD_PARAMS="${BUILD_PARAMS} CONFIG_IWL4965=n" fi less code is less maintaining?
Well yeah I don't understand why the use flags were removed. The current RDEPEND is nonsensical due to this, also the dependency on 2.6.22 kernels won't ensure you are actually running such kernel. I'll attach something better.
Created attachment 124553 [details] iwlwifi-0.0.36.ebuild Please, test this.
the complex build params are set because it isn't sure what defaults afaik it defaults to no, the setting to know was done by me today because an iwl dev mentioned. Secondary supporting mac is highly recommended by the devs because so this could be used down to any 2.6.18. Thirdly selection of which modules should be done is also highly recommended by iwl devs, because for iwl4965 you need latest unconfirmed mac80211-9*, for iwl3945 it is recommended to stay on mac80211-8.0.2 At least i think you should first have a look in the commit log from sunrise, before blaming people, could be that you maintain something mostly done by the person you are blaming to do crap. Jakub: The cleanup is nice, thx
btw, what version of mac is in 2.6.22?
oh you removed the patch, i predict this will fail
(In reply to comment #8) > oh you removed the patch, i predict this will fail Which patch? There's wasn't any in sunrise. You mean the sed stuff? Is it needed? You really need to be more verbose, I can't test the thing at all ATM. Wrt the external mac80211 stuff, well that's not in gentoo-x86 official tree so it's not really an option, plus it really made the ebuild very very messy.
it was on sunrise next to this with really good reasons and the patch is needed for 0.1.1 it was in the ebuild you marked as shit. I mentioned that in initial comment
(In reply to comment #10) > it was on sunrise next to this with really good reasons and the patch is needed > for 0.1.1 it was in the ebuild you marked as shit. > I mentioned that in initial comment Uh I don't maintain this thing at all, I did all the rewrite there and noone complained about the thing being broken, so I assume it was working. The ebuild in the official tree sucks, I attached a rewrite above and you continue screaming that I broke it. You really want to piss me off? I'm not going to dig into svn history for which patch you mean, if you have a patch that's needed, link/attach it here. If you have a better ebuild, attach it here.
just take a fucking look on the ebuild i posted here, it applies a patch. and afaik with inkernel mac of 2.6.22 you will surely to be unable to get any iwl building without this patch and even with it you will be unable to build iwl4965
btw the version you need to build iwl4965-0.1.1 of mac80211 was released yesterday
(In reply to comment #12) > just take a fucking look on the ebuild i posted here, it applies a patch. And I told you to attach an ebuild patch against current ebuild in the tree. Right in Comment #2. The external mac80211 is not in the tree, your ebuild is therefore broken. Plus the http://rafb.net/p/INGqTi16.txt in SRC_URI must be a bad joke?!?
it was a hot fix directly from devs with great excuses for the bad mistakes, and i stressed that is it a little hack
iwlwifi will default to building both modules these two conditional statements at the top of the makefile should make this clear. export CONFIG_IWL3945 ?= m export CONFIG_IWL4965 ?= m this means that Jakub's Moc ebuild probably won't work correctly, but it already looks a lot cleaner btw, I already informed "upstream" about the build problems of the 3945 depending on the very latest (intel) experimental patches, which probably isn't intentional. This would make the patch deprecated. the version of mac80211 that iwlwifi depends on now, are not even in wireless-dev. So certainly not in .22. (these are mainly for 802.11.n support in 4965) And the 4965 module will probably need to depend on those from now on. 3945 shouldn't though. I expect that to be resolved in a matter of days.
(In reply to comment #15) If 0.1.1 doesn't work with in-kernel mac80211 stack, then stop requesting version bumps for it, it can't be done. @compnerd - please consider the fixes attached here for 0.0.36 or just drop the thing from the tree, I've wasted enough time here, and the user even refuses to test 0.0.36 w/ in-kernel 2.6.22 stuff. (In reply to comment #16) Feel free to elaborate on the ebuild attached here. The version bump is out of debate ATM, as explained above.
Created attachment 124562 [details] iwlwifi 0.0.36 ebuild Hi, Sorry I hadn't read through all the comments, in this thread before my previous replies. If I had, I would certainly have objected to the strong language, and rudeness (especially in regards to a zero day bump request). I was just happy to wake up to a portage with iwlwifi in there. First of all. Yes I'm afraid a version bump is out of the question, because of the incompatibility with current kernel. There are a few updates that might be worth applying though, like QoS support and a few fixes. But it might be too much trouble doing all this. Now waiting a while to see how it develops might prevent all these problems from occuring. I have (upgraded kernel) and tested your ebuild Jakub Moc. And it doesn't yet work perfectly. I attached a possible solution to that. It's due to iwlwifi building everyting by default, so instead of listing what we want, we need to list what we don't want. about the attached ebuilds: I get a warning : /usr/portage/eclass/linux-mod.eclass: line 506: cd: /var/tmp/portage/net-wireless/iwlwifi-0.0.36/work/iwlwifi-0.0.36/compatible: No such file or folder. which is probably due to the fact that it doesn't exist before the make is executed. cheers
Thanks for this ebuild folks. Works fine on Dell D830 with i4965 wireless chipset + wpa_supplicant (AP is 802.11g & wpa2+PSK ) and Kernel 2.6.22. I had to compile softmac80211 as part of the Kernel not as a module to make it stable. Seems to do with some WEP / STA issues. thank again.
merged the changes for the 0.0.36 ebuild
what about the mac80211 subsystem if it is built as a module via ebuild just like we do with the alsa-driver? The ebuild should honor that...
(In reply to comment #21) > what about the mac80211 subsystem if it is built as a module via ebuild just > like we do with the alsa-driver? The ebuild should honor that... > Nope. Comment #2, Comment #9, Comment #14. Anything you've built outside of official tree is not supported. There's mac80211 in kernel, use it.
Stefan Schweizer recommends: "For mac80211 it is better to use intels release version." Link to his blog: http://planet.gentoo.org/developers/genstef/2007/07/10/external_wireless_drivers_and_kernel_2_6_22
Please... This bug has been closed, plus bugzilla is not a discussion forum.
