madwifi: Aggressive revert of my aggresive fix :-)

madwifi: Aggressive revert of my aggresive fix :-)

[Leon Woestenberg]

Hello Mike,

I tried to fix the GNU_HASH issue in madwifi by leaking LDFLAGS into
the build, and respecting those flags in some Makefiles.

http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=f67b2104dafeda09571259ba4c3e6019d8a0888b

hat apparently broke something for you, so you unset LDFLAGS again:

http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=75d4826c3c0f7012ccee3a7116d7350f41539fa3


The tools for example, need them. Someone just ran into that problem,
that I (agressively) fixed before:

[23:16]	<tharvey>	pb_, madwifi includes some userland tools - its
those that fail the GNU_HASH based on ldflags that I'm trying to fix

So let's work towards a fix that works for both of us:

- The right fix is to leak LDFLAGS into the build from the recipe, but
unset them *only* where needed.
- Please revert your commit (i.e. unsetting LDFLAGS) and see which
part of madwifi needs LDFLAGS unset.

We will probably end up with a fix to one or two of the Makefiles instead.

Regards,
-- 
Leon

Re: madwifi: Aggressive revert of my aggresive fix :-)

[Mike Westerhof (mwester)]

Leon Woestenberg wrote:
> Hello Mike,
> 
> I tried to fix the GNU_HASH issue in madwifi by leaking LDFLAGS into
> the build, and respecting those flags in some Makefiles.
> 
> http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=f67b2104dafeda09571259ba4c3e6019d8a0888b
> 
> hat apparently broke something for you, so you unset LDFLAGS again:
> 
> http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=75d4826c3c0f7012ccee3a7116d7350f41539fa3
> 
> 
> The tools for example, need them. Someone just ran into that problem,
> that I (agressively) fixed before:
> 
> [23:16]	<tharvey>	pb_, madwifi includes some userland tools - its
> those that fail the GNU_HASH based on ldflags that I'm trying to fix
> 
> So let's work towards a fix that works for both of us:
> 
> - The right fix is to leak LDFLAGS into the build from the recipe, but
> unset them *only* where needed.
> - Please revert your commit (i.e. unsetting LDFLAGS) and see which
> part of madwifi needs LDFLAGS unset.
> 
> We will probably end up with a fix to one or two of the Makefiles instead.

So, you want _me_ to revert _my_ fix (after it was broken by someone
else), and then spend my time sorting through the maze of Makefile
madness from the madwifi-ng organization to make a patch to the Makefile
-- so that I can get back to the state I was in originally?

Respectfully, the answer is no.

I do not have time right now to do that.

Further, the root cause of this issue is a far earlier change, which is
the one that makes the GNU hash warning a failure -- prior to that
change, this package was working for everyone.

Further, if you examine the commit I made, you'll note that the changes
are made to a single, solitary BB file -- and here's an excerpt from
that BB file:

DEFAULT_PREFERENCE = "-1"
DEFAULT_PREFERENCE_slugos = "1"

So the particular recipe in question is clearly intended for ixp4xx (and
not even all ixp4xx machines, only the one distro to which I had access
to test).

Further, the madwifi-ng driver is not only an out-of-kernel device
driver, but it also contains a number of binary blobs that are
pre-compiled for specific architectures, with specific linker options on
the pre-compiled blobs.  This makes this package unusually
machine-specific, compared to the typical OE package.

So I would suggest that for this package we should take the path of
least resistance and simply have recipes based on the set of machines
committers can test on.  I can only test on SlugOS on ixp4xx.  Since it
was broken by the LDFLAGS commit, I have to assume that others can only
test on their machines.  Hence it's foolish for this package to waste
time trying to patch the moving target that is the madwifi-ng makefiles.

If someone else wants _that_ particular version of the madwifi drivers,
that's fine -- just copy that recipe, as-is, to the next SVN version
number, remove the DEFAULT_PREFERENCE_slugos line from the original one,
and revert my changes to the original one -- I can find time to do that,
if you wish.

On the other hand, if the powers-that-be insist that there can be only a
single recipe that must be good for everyone, well, then I regret that I
do not have time right now to create such a thing.  Nor do I have other
atheros-based machines with which to test.  But rather than revert my
commit, I suggest that we go back to the commit that originally broke it
-- the GNU hash commit.  Or at the very least, the commit that followed
that change, the one that committed the LDFLAGS stuff preceding my
commit.  To point at my final commit in the chain and say that it is the
one at fault, and therefore is the one that should have been done
differently, is simply not correct logic in this situation.

Regards,
Mike (mwester)

Re: madwifi: Aggressive revert of my aggresive fix :-)

[Leon Woestenberg]

Hello Mike,

On Fri, May 22, 2009 at 2:16 AM, Mike Westerhof (mwester)
<mwester@dls.net> wrote:
> Leon Woestenberg wrote:
>
> So, you want _me_ to revert _my_ fix (after it was broken by someone
> else), and then spend my time sorting through the maze of Makefile
>

Sorry, I meant to write "revert locally" in my request: "Please revert
 your commit _locally_ (i.e. unsetting LDFLAGS) and see which part of
madwifi needs LDFLAGS unset.", but never mind;

In my goal to make the recipe work again for other machines after the
GNU_HASH / LDFLAGS check (I tested powerpc and x86),  I thereby broke
it for the initial combo it was written for (slugos). I should have
tested that combo for sure.

Mea culpa and excuse me for breaking it for you.

I largely agree with your points, especially after your email explanation.

Regards,
-- 
Leon

Re: madwifi: Aggressive revert of my aggresive fix :-)

[Andrea Adami]

Wouldn't this case just need the magic of INSANE_SKIP?

My 2 cents

Andrea