oonf-*: add cmake 4.x compatibility

[PolynomialDivision]

Maintainer: @HRogge
Compile tested: tbd
Run tested: tbd

[BKPepe]

No. I am not in favor to approve this or merge this.

1. These packages needs to be dropped.
   Look at their repo - development is stalled, documentation is not available (where can I get the Documentation for OONF? OLSR/OONF#70)

2. Your fix is not going to work.
   oonef-dlep-radio: error: initialization of 'int' from 'void *' makes integer from pointer without a cast [-Wint-conversion] #1120 , radio and proxy can not be compiled with GCC 14 (error: initialization of 'int' from 'void *' makes integer from pointer without a cast [-Wint-conversion]) OLSR/OONF#71

Because of upstream referenced issues, I am closing this. Today or tomorrow, I will create PR to remove these packages from this repository.

[XDjackieXD]

Please do not remove oonf/olsrd2 completely.
There are still communities relying on this.
PRs on the OONF repo still get merged but a bit slow.

[BKPepe]

Everything has been explained in my previous comment. As you can observe, the oonf* packages have not compiled since May 23—possibly even earlier—because no one else appears to have noticed. This issue was caused due to OpenWrt's migration to GCC 14 on April 29, nearly a month prior.

It is now November, which means more than half a year has passed, and in that time no one from the community has addressed or resolved the issue—including the OONF developers. While it is possible to apply a fix for one specific package, consider that this problem might also affect, or have affected, multiple other packages. The OpenWrt project maintains hundreds or even thousands of packages, and it is simply not feasible for us to repair every package that is no longer actively maintained or supported.

Moreover, it is untenable to claim that entire communities rely on these packages when the project's website—including documentation, found at http://www.olsr.org/—has been offline for more than a year and a half. Such a situation simply cannot be considered sustainable.

If documentation is unavailable, how can users be expected to work with the software? What happens when a significant problem arises (which has already occurred with upgrades to newer versions of GCC and CMake) that requires substantial effort to resolve—such as a security vulnerability?

For these reasons, as documented in the references above, the affected packages have been removed.

[XDjackieXD]

It is now November, which means more than half a year has passed, and in that time no one from the community has addressed or resolved the issue.

At least in our case, builds for said community are based off of OpenWrt stable builds where oonf still builds fine.
This is the reason I did not notice it earlier.

Moreover, it is untenable to claim that entire communities rely on these packages when the project's website—including documentation, found at http://www.olsr.org/—has been offline for more than a year and a half. Such a situation simply cannot be considered sustainable.

Probably doesn't help my case a lot but the OLSRD2 documentation never was in any acceptable state and imo was completely useless. We have known-good configuration and when I'm trying out things not actively in use by us (like the DLEP components) I usually resort to reading code.

What happens when a significant problem arises (which has already occurred with upgrades to newer versions of GCC and CMake) that requires substantial effort to resolve—such as a security vulnerability?

Someone (like @PolynomialDivision) creates a PR and it is merged by the upstream (see OLSR/OONF#72). The person with push access does not actively maintain the software but merges PRs.

I know this situation isn't ideal but changing routing daemon in a non-centrally-managed network with 200+ nodes is close to impossible...