Revert "fcgi: remove"

[ynezz]

Compile tested: OpenWrt 22.03 x86/64, ipq40xx, mvebu/cortexa9
Run tested: OpenWrt 22.03 x86/64, ipq40xx, mvebu/cortexa9

This reverts commit 65ef6c6 where @neheb removed fcgi library for "Nothing uses this." reason.

I've noticed this missing library while rebasing downstream project from OpenWrt 19.07 release base to OpenWrt 22.03, as there is amx-fcgi system component which depends on this library.

So I would like to fix that regression by adding back the removed library package.

[neheb]

I probably also removed it as it was failing in some other way (maybe nls or autoconf issues).

Where is this amx-fcgi used?

[ynezz]

I probably also removed it as it was failing in some other way (maybe nls or autoconf issues).

I can't find anything regarding this in the issue tracker, it compiles and works fine, CI here doesn't complain either.

Where is this amx-fcgi used?

tr181-rest-api for example.

[ynezz]

Here is the regression exposed by the latest OpenWrt 22.03.2 x86/64 SDK:

x86_64-openwrt-linux-musl-gcc -Os -pipe -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -ffile-prefix-map=/home/build/openwrt/build_dir/target-x86_64_musl/amx-fcgi-v0.2.3=amx-fcgi-v0.2.3 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro  -I/home/build/openwrt/staging_dir/toolchain-x86_64_gcc-11.2.0_musl/usr/include -I/home/build/openwrt/staging_dir/toolchain-x86_64_gcc-11.2.0_musl/include/fortify -I/home/build/openwrt/staging_dir/toolchain-x86_64_gcc-11.2.0_musl/include  -Werror -Wall -Wextra -Wformat=2 -Wshadow -Wwrite-strings -Wredundant-decls -Wmissing-declarations -Wno-attributes -Wno-format-nonliteral -fPIC -g3 -I ../include_priv -I /home/build/openwrt/staging_dir/target-x86_64_musl/include -I /home/build/openwrt/staging_dir/target-x86_64_musl/usr/include -Wstrict-prototypes -Wold-style-definition -Wnested-externs -std=gnu11 -c -o ../output/x86_64-openwrt-linux-musl/object/amx_fcgi.o amx_fcgi.c
In file included from ../include_priv/amx_fcgi.h:69,
                 from amx_fcgi.c:64:
../include_priv/amx_fcgi_types.h:69:10: fatal error: fcgiapp.h: No such file or directory
   69 | #include <fcgiapp.h>
      |          ^~~~~~~~~~~
compilation terminated.

It is working fine with OpenWrt 19.07 SDK.

[champtar]

@ynezz could you maybe add a comment in the makefile pointing to the external users of the lib ? It's a bit weird to keep libraries with no users.
Also should you set yourself as maintainer ?

[ynezz]

It's a bit weird to keep libraries with no users.

Fair enough, I wasn't aware about this rule.

[champtar]

IMO It's fine to keep it in as there is at least one known user, but it's better to make it explicit so we don't delete it again in the future.

[neheb]

I think if introduced it should also be removed from packages-abandoned.

[ynezz]

IMO It's fine to keep it in as there is at least one known user, but it's better to make it explicit so we don't delete it again in the future.

Do we really want to start adding this kind of build system unrelated "hey, I'm using it, don't delete it" noise into the Makefiles? How often you would need to update it, so you know, that the users are still active? Once a year? IMO it's going to bit rot, folks can simply miss the information and delete the package anyway. It should probably be documented as well.

What about simply assuming, that there always might be some users out there, so don't delete the package in the first place? If you really need to remove it for some reason, then simply make that reason clear in the commit message and allow adding the package back.

[ynezz]

Also should you set yourself as maintainer ?

Done.

[ynezz]

I think if introduced it should also be removed from packages-abandoned.

Prepared.

[dhewg]

Not directly related, but:
I've tried to get some prpl hosted firmware files released under a compatible license for OpenWrt. I've used their issue tracker for that some month ago. Now they've shut down access to it.
Apparently they don't care about open source communities, so why should OpenWrt care about them and maintain this without in-tree users?

[ynezz]

I've tried to get some prpl hosted firmware files released under a compatible license for OpenWrt. I've used their issue tracker for that some month ago.

As you've probably already noticed, those files reside under Intel vendor/member subgroup and are Copyright 2017-2018, Intel Corporation.. Basically prpl itself can't do much about it since unfortunately none of those files are being used/distributed in any form by prpl. Otherwise it would've need to follow IP Policy and thus have FOSS friendly license already.

What prpl can do in this case is to politely ask MaxLinear representatives to consider re-licensing those files, which was done and AFAIK it's currently waiting for final approval from their legal department, but you're hopefully already aware.

Now they've shut down access to it.

I believe, that its not intentional, IMO its just being caused by the ongoing Jira system migration from on-premise to the new cloud hosted instance. Thank you for letting me know, I'll try to ping responsible folks and ask them for a fix.

so why should OpenWrt care about them and maintain this without in-tree users?

IMO OpenWrt is a FOSS project with a clear contribution rules and guidelines, which anyone could reference in exactly such ambiguities.

IIUC then in FOSS projects "Upstream First" philosophy means, that whenever you solve a problem in your copy of the upstream code which others could benefit from, you contribute these changes back upstream, for example you send a patch or open a PR in the upstream project.

IMO thats exactly what I'm doing, I'm trying to upstream a fix for a downstream project breakage, so anyone else using fcgi library in OpenWrt 19.07 based project and migrating to any later versions could get the fix.

[dhewg]

What prpl can do in this case is to politely ask MaxLinear representatives to consider re-licensing those files, which was done and AFAIK it's currently waiting for final approval from their legal department, but you're hopefully already aware.

I was aware of an initial ping from a few months ago. Final approval sounds better than that though.

I believe, that its not intentional

I checked their website first, but couldn't find any info on any migration, so I assumed it is intentional.

Thanks, let's hope that gets resolved.

[ynezz]

Thanks, let's hope that gets resolved.

https://prplfoundationcloud.atlassian.net/browse/PCI-16

[dhewg]

Nice, thanks!
If that got resolved that quick due to you poking around, I urge you to poke some more to get that the desired response from MaxLinear.