rpcd-mod-luci: use standard POSIX header for basename() The musl libc only implements POSIX basename() but provided a GNU header kludge in <string.h>, which was removed in musl 1.2.5 [1]. Use the standard <libgen.h> header to avoid compilation errors like: luci.c: In function 'rpc_luci_parse_network_device_sys': luci.c:676:53: error: implicit declaration of function 'basename' [-Werror=implicit-function-declaration] 676 | blobmsg_add_string(&blob, "master", basename(link)); | ^~~~~~~~ luci.c:676:53: error: passing argument 3 of 'blobmsg_add_string' makes pointer from integer without a cast [-Werror=int-conversion] 676 | blobmsg_add_string(&blob, "master", basename(link)); | ^~~~~~~~~~~~~~ | | | int ... cc1: all warnings being treated as errors Link 1: https://git.musl-libc.org/cgit/musl/log/?qt=grep&q=basename Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
luci-lib-nixio: Fix add_luci_conffiles adding duplicate files (#6568) * luci-lib-nixio: Fix add_luci_conffiles adding duplicate files add_luci_conffiles does not check whether the file already exists when adding the file, which may result in redundant backups in the sysupgrade backup. Signed-off-by: Xiang W <wxjstz@126.com>
luci-lib-jsonc: improve handling of integral numeric values Properly deal with integral numeric values exceeding the int32_t range by replacing the cast logic with more fine grained checks: - Lua numbers which are integers in the first place are directly converted to JSON integers - Finite double Lua numbers which are integral are converted to JSON integer values - All other numeric values are converted to JSON doubles This should bring the handling of large integral value in line with the documented behavior of turning non-fractional Lua numbers into JSON integers. Fixes: #6647 Signed-off-by: Jo-Philipp Wich <jo@mein.io>
luci-lib-rpcc: Remove old broken lib Remove the old library that has been BROKEN since 2015. Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
rpcd-mod-luci: fix reporting network device flags Fix reporting of ceertain flag values larger than 255, such as IFF_PROMISC by explicitly casting the bit test expression to a boolean result since the implicit integer truncation to uint8_t will turn the `0x100` result of a set IFF_PROMISC bit into just `0x0`. Signed-off-by: Jo-Philipp Wich <jo@mein.io>
luci-lib-httpprotoutils: add airplay mime types Airplay of a statically hosted video file from one Apple device to another fails due to unrecognized content-type. Adding Airplay supported mime types fixes the issue. Signed-off-by: Sasha Andonov <s.andonnov@gmail.com>
rpcd-mod-luci: reuse infos provided by libiwinfo Don't hardcode bit/name pairs, instead iterate over what's known to the library and use that instead. This automatically adds the missing ad hwmode and HE80+80 htmode - and any future ones. The only difference in the output is the order of the 'hwmodes' array. Signed-off-by: Andre Heider <a.heider@gmail.com>
luci-lib-base: ensure that `luci.http` can be required standalone Various existing Lua software is requiring the `luci.http` library for URL encoding/decoding tasks so ensure that it can be loaded in a stand alone manner even if the emulated Lua runtime environment is not available. Fixes: cea2c3578e ("luci-lib-base: forward luci.http.context.request.message to ucode") Ref: https://forum.openwrt.org/t/x/141817 Ref: https://github.com/openwrt/luci/pull/5976#issuecomment-1296220586 Signed-off-by: Jo-Philipp Wich <jo@mein.io>
luci-lib-base: forward luci.http.context.request.message to ucode Some existing LuCI application code accesses the `luci.http.context.request.message.params` HTTP parameter table directly. Forward the `luci.http.context.request.message` object to the ucode `luci.http.message` instance in order to properly support this. Signed-off-by: Jo-Philipp Wich <jo@mein.io>
treewide: separate Lua runtime resources Move classes required for Lua runtime support into a new `luci-lua-runtime` package. Also replace the `luci.http` and `luci.util` classes in `luci-lib-base` with stubbed versions interacting with the ucode based runtime environment. Finally merge `luci-base-ucode` into the remainders of `luci-base`. Signed-off-by: Jo-Philipp Wich <jo@mein.io>
luci-lib-nixio: always build without TLS support The build system fails to set up the chosen TLS provider and always builds the package without TLS. While this could be easily fixed, the package would fail to build with axTLS and cyaSSL without further intervention. The version of axTLS included with the source is outdated, as is the API used with cyaSSL, now wolfSSL. OpenSSL support could be enabled, but the TLS code limits connections to TLS 1.0, deprecated by RFC 8996: "TLS 1.0 MUST NOT be used". Remove the provider configuration from build options, and always build the library without TLS. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>