Bugzilla Bug 184947

new version is out, needs a little hack/patch for compiling on old mac80211
iwl4965 users please use latest mac80211

Reproducible: Always

Created an attachment (id=124548) [details]
net-wireless/iwlwifi/iwlwifi-0.1.1.ebuild

the new ebuild (works fine with iwl3945 (set useflag))

(From update of attachment 124548 [details])
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 an attachment (id=124553) [details]
iwlwifi-0.1.1.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 an attachment (id=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.