Bugzilla Bug 204744

Hello,

1. Use kernel headers from kernel, as it segfaults in transition from 2.6.22 to
2.6.23.

2. Check CONFIG_BRIDGE at kernel configuration.

3. Add ~mips keyword.

4. Add noip patch (accepted by upstream).

If you want I can commit this...

Regards,

Created an attachment (id=140376) [details]
bridge-utils-1.2-r1.ebuild.diff

Created an attachment (id=140377) [details]
bridge-utils-1.2-noip.patch

NAK on the kernel sources.
Now I cannot build it on a machine that only has a kernel with no sources
present.
Rebuild it against newer linux-headers instead. Depending on a specific kernel
config also blocks me from building on some other machine and then deploying to
the bridging box.

The noip patch is fine however.

Created an attachment (id=140379) [details]
bridge-utils-1.2-r1.ebuild.diff

OK...
1. Use linux headers, but work with cross compile correctly.
2. The CONFIG_BRIDGE check was in warn mode... Nothing would have prevented you
from compiling this.

I thought about the linux kernel requirement... And I think your approach
suggest that all packages using linux-info should be modified to use
linux-headers...

While kernel usermode components should be compiled with latest kernel sources.

Because linux-headers cannot be slotted, it is better to use linux-info
approach, for this case as well.

Created an attachment (id=140485) [details]
bridge-utils-1.4.ebuild.diff

Actually version bump...
But please consider your approach regarding the linux-headers, I believe you
are wrong in this case.

No, the user's kernel sources might not be suitiable (this happened with audit
before, people running some badly patched kernels got a broken audit binary),
or even present (I do indeed have machines where this is true, on a cluster
that all uses the same kernel, there is absolutely no need to have sources on
each machine).

There are two cases with headers:
1. kernel newer than headers - specific features for the new kernel might not
get built.
2. headers newer than kernel - The binary should work always.

If you hit a case that linux-headers aren't new enough, either bug the kernel
herd (they are quite responsive), or extract the specific headers you need and
include them with the ebuild.

The only time that kernel sources should be needed, is when the actual content
of the kernel matters (eg: the l7filter of iptables), or you are need to
link/include some part of the kernel (while building modules).

But for you, i'll bring it up on the -dev list anyway.

Please bump this one way or the other...
Thanks.

Hello Robin,
I don't understand... Why do you keep simple bugs like this one opened for a
long time?
Is there some hidden advantage in this?
Last time I checked, bugs behaves differently than wine... :)
Regards,

I fail to understand why you keep this open, maybe I miss something... I can
learn...

ping...

*** Bug 214126 has been marked as a duplicate of this bug. ***

ping again...

Well.. as a user now... still waiting for this bump... No reason to not provide
this new version to users.
Thanks.

1.4 in the tree now.

alonbl: Because it's nowhere near the top of my list of priorities of things to
do.