- Includes revision-bumps of all reverse dependencies; only one package, `apache-orc`, has a build failure because of newer `libprotobuf`. Its patch is copied and pasted from this PR: https://github.com/apache/orc/pull/2316
- `protobuf-static` is also bumped. It is an orphaned package and there have been, in the past several months since
https://github.com/termux/termux-packages/pull/24131, **no known cases of anyone encountering any issues for which they need `protobuf-static` anymore**. This strongly suggests that the **new `libandroid-stub` invented by twaik** that I helped with https://github.com/termux/termux-packages/pull/23712 is probably a completely successful workaround in Android to this upstream `libprotobuf` issue: https://github.com/protocolbuffers/protobuf/issues/5254. However, because the original bug is very rare and only affects a very few Android devices, and among those few Android device where it is reproducible, there are some subtle variations in the content of the protobuf error message, for the time being, I think it is probably a good idea to keep `protobuf-static` unchanged, and eventually, maybe in 1 year from now, if still nobody has ever needed `protobuf-static` at that time, it can be completely disabled.
- Progress on https://github.com/termux/termux-packages/issues/23492
- Dependency of https://github.com/termux/termux-packages/pull/25826
- In order to rebuild all reverse dependencies successfully, also includes some fixes for builds of packages that currently fail to build with CMake 4, which are either the commonly-used `-DCMAKE_POLICY_VERSION_MINIMUM=3.5` argument, or are patches named to indicate their purpose
- All patches with attribution headers are cherry-picked from respective upstream PRs or commits
- All patches without attribution headers are written from scratch by me to solve errors that are either Termux-specific or are not yet fixed anywhere in upstream
Some notes about unique patches:
- Very big thanks to cho-m, who almost single-handedly brought boost 1.89 to `libc++`-based UNIX-like operating systems with their work on boost 1.89 for MacOS in https://github.com/Homebrew/homebrew-core/pull/233031. Many cherry-picked patches originated from them.
- I chose to write my own patch for `ncmpcpp` for boost 1.89 rather then exactly copy the example of cho-m, even though my method involves more lines of code, because **I decided that I would like to be notified, through the patch failing to apply, when upstream `ncmpcpp` has added official support for boost 1.89**, indicating that the downstream change can then be removed without me having to remember it, which cho-m's example unfortunately wouldn't do.
- For some reason, building `openfoam` with boost 1.89 instead of boost 1.87 causes it to attempt to link to `libgmp.so` in a nonexistent folder `/data/data/com.termux/files/usr/lib64`, instead of `/data/data/com.termux/files/usr/lib`
- It's unclear how exactly boost 1.89 draws out this error, but it can also be seen that the origin of the "lib64" instance is within openfoam, and Termux does not use any "lib64" folder, so it should be patched out from `openfoam` (which resolves the error)
```
-L/data/data/com.termux/files/usr/lib64
-L/home/builder/.termux-build/openfoam/src/ThirdParty/platforms/linuxARM64Clang/boost-system/lib
-L/home/builder/.termux-build/openfoam/src/ThirdParty/platforms/linuxARM64Clang/boost-system/lib64
-lmpfr -lgmp -lfileFormats -lsurfMesh -lmeshTools -ldecompose -ldynamicMesh -lsnappyHexMesh
-o /home/builder/.termux-build/openfoam/src/platforms/linuxARM64ClangDPInt32Opt/lib/libconformalVoronoiMesh.so
ld.lld: error: unable to find library -lmpfr
```
- `ravencoin` and `mkvtoolnix` use `autoreconf -fi` during their `build.sh` files, but unfortunately, in the Ubuntu 24.04 cross-builder Docker image, there is a package installed in Ubuntu `autoconf-archive` version 20220903-3, which contains a file `/usr/share/aclocal/ax_boost_system.m4`, and this file is unfortunately propagated into the build systems of `ravencoin` and `mkvtoolnix` by `autoreconf -fi` and "pollutes" them with "awareness" that they would not otherwise have of the `Boost::System` shared library that no longer exists in boost 1.89, so temporary changes to `TERMUX_PKG_EXTRA_CONFIGURE_ARGS` are required, which should be removed the next time the Ubuntu cross-builder image is bumped, since after that happens, they will no longer be necessary.
- Copy and paste fix for building `abiword` with `libc++` 19+ (NDK r28c) from FreeBSD: e6daa211c6
- Fix prefix pollution `libjxl`->`telegram-desktop`
- (i.e. the command `scripts/run-docker.sh ./build-package.sh -I -f libjxl telegram-desktop`)
- For clarity, the edits to `packages/libjxl/fix-pkgconfig-file.patch` are primarily implementing this fix by removing the invalid path `/data/data/com.termux/files/usr//data/data/com.termux/files/usr/include` from the command `pkg-config --cflags libjxl`
auto-update was disabled in a4ba31d78285070b70e14df2a112837c6f69d6fe
commit because CI can not update libarrow-cpp and python-pyarrow at the
same time. Later in 5469a4ca162407605bae2528b615699c448d13bf commit,
libarrow-cpp and python-pyarrow were merged in one build script. So,
those can be updated in single commit now.
%ci:no-build
`python-pyarrow` and `libarrow-cpp` packages versions were required to be aligned and they were built from the same source so they were united into package and its subpackage to reduce maintenance cost.
It is true that libarrow-python should be bumped to the same version in
this PR as well. But its build system has drastically changed from the
previous version and trial and error is needed to adapt to it. It would
be really a pain if I had to wait for libarrow-cpp to finish its build
before build of libarrow-python begins every time I modify the build
recipe.
