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 attachment 140376 [details, diff] bridge-utils-1.2-r1.ebuild.diff
Created attachment 140377 [details, diff] 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 attachment 140379 [details, diff] 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 attachment 140485 [details, diff] 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.
