- Now we use cabal (comparable to rust's cargo) to build binary packages.
Reason:
- Haskell's cabal packaging system is like rust's cargo. Every packages
depends upon some specific version of other library. Hence, it is
hard to maintain each and every version.
- Patching packages so that they use latest of dependencies breaks
compatibility.
Benefits:
- Enables building very large packages like `pandoc`.
- Reduces disk space used.
- Lesser packages to maintain.
Signed-off-by: Aditya Alok <alok@termux.dev>
Their functionality is included in libc, but some packages anyways
searches for libpthread.so and librt.so. Provide these files so that
such configure steps succeed.
Instead of in termux_setup_toolchain_XX. This helper lib does really
not have anything to do with our toolchain so it does not belong in
termux_setup_toolchain.
It is also good to only modify $TERMUX_PREFIX (for other things than
make install) before termux_step_create_timestamp_file has been run,
and termux_step_start_build fits that criteria.
and `posix_spawnp` defined in libandroid-spawn.
There are other symbols defined in libandroid-spawn, but hopefully this
is sufficient for the purpose of guarding underlinking.
Reference: https://github.com/termux/termux-packages/issues/14623
It replaces termux_setup_python_crossenv and can be used when
compiling python packages. Packages should specify their python
dependencies in TERMUX_PKG_PYTHON_TARGET_DEPS,
TERMUX_PKG_PYTHON_BUILD_DEPS, and TERMUX_PKG_PYTHON_COMMON_DEPS.
The pattern `for lib in "$(find [...])"` does not work if `find` matches
more than one file. Double quotes around `$(...)` must be removed.
This bug was introduced in 849112f9e7, and
the check did not work correctly from then on, until now.
Seems to be outdated since a long time. Let's better fix it. I don't
think there will be any breaking changes (like some weird new
compilation errors or something).
python2 is no longer available in official repositories. See https://archlinux.org/news/removing-python2-from-the-repositories/
Also depend on jq directly. I know there are a lot of packages missing
from the list. But I guess it will be better for the contributor to
install them as needed instead of keeping a lot of unnecessary stuff
installed.
to avoid warnings like
```
/usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: PkgResourcesDeprecationWarning: 2:0.8.3 is an invalid version and will not be supported in a future release
```
This add-on requires careful review and testing, but this will not interfere with compiling packages.
Co-authored-by: agnostic-apollo <agnosticapollo@gmail.com>
%ci:no-build
* Bump SDK revision to 9123335
* Remove no longer used platforms;android-21
* Do not remove "unused parts" from SDK (which are actually used)
* Make it possible to use alternative JAVA_HOME via TERMUX_JAVA_HOME
Earlier convention:
upgpkg(<repo>/<package>): update to <ver>
Newer convention:
upgpkg(<repo>/<package>): <ver>
Similarly same for dwnpkg.
Thanks to @truboxl for the suggestion
neovim-nightly has already been 8.0.0 for a while, and has apparently
built without issues. I was not able to build it without first
updating libvterm and adding lua-{lpeg,mpack} to docker image though.
After upgrading grep from 3.7 to 3.8 it now warns when pattern
contains unnecessary escaped characters, like:
grep: warning: stray \ before !
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before !
grep: warning: stray \ before /
grep: warning: stray \ before !
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before !
grep: warning: stray \ before /
Silence these warnings by fixing our termux_step_massage function.
termux_setup_rust might be run several times in a build recipe, so
that continued (`./build-packages.sh -c`) builds can be supported.
The setup function uses and then unsets CFLAGS, resulting in an error
the second time termux_setup_rust is run.
NDK r25 has removed GNU Assembler (GAS). Removal of GAS introduced a number of build issues.
The most prominent is:
/usr/bin/as: unrecognized option '-EL'
Some options to solve this:
1. Disable building custom assembly and suffer performance penalty
2. Hand rewrite the custom assembly to be LLVM compatible
3. Wait for upstream to write LLVM compatible assembly (openssl, openssl-1.1)
4. Bring back GAS from NDK r23c
In this commit, GAS is brought back as a separate toolchain instead of following NDK r23c file hierarchy.
We pass "--gcc-toolchain=GAS_TOOLCHAIN_DIR" to NDK r25 clang to detect.
Packages only have to add "termux_step_gnu_as_23c" to build.sh to enable GAS.
In the future, we expect packages should follow option 3 more than option 4 as that is a last resort.
This commit also bumps revision for packages that rely (or previously rely) on "-fno-integrated-as":
hors, libffi, libgcrypt, libpixman, openssl, openssl-1.1
Co-authored-by: Henrik Grimler <grimler@termux.dev>
Co-authored-by: Chongyun Lee <45286352+licy183@users.noreply.github.com>
This caused undefined symbols to go undetected in libzmq in latest
build. Probably more packages are affected, should do a rebuild of
all packages again to check for undefined symbols.
And keep ndk-patches in 23c/ subdirectory. Run
termux_step_setup_toolchain_23c only if TERMUX_NDK_VERSION equals 23c.
This is a step towards having the possibility to use different NDK
versions. Using a different NDK version than the one termux
officially supports should *really* not be done except for
testing/debug/development reasons, or if it is strictly necessary to
be able to compile a program (for example for packages that need a
fortran compiler, which at the moment is only supported with old
gcc-using NDKs).
Otherwise these variables is not visible to child shells. This caused
configure step of termux-tools to always use debian/apt combination,
since it checks for variables among environmental variables and they
were not visible.
Missed this when changing back and forth from having the code in a
subfunction instead.
This caused termux_step_massage to return prematurely, and subpackages
to not be generated (which is how I noticed it).
Fixes commit 849112f9e7 ("scripts(massage): remove symbol loop in
undefined syms check").
If `--tty` is not passed to `docker exec` because stdout is not available (`[ ! -t 1 ]`), like due to redirection to file (`&> build.log`) or if stdin is not available (`< /dev/null`), then docker does not forward kill signals to the process started and they remain running.
To fix the issue, the `DOCKER_EXEC_PID_FILE_PATH` env variable with the value `/tmp/docker-exec-pid-<timestamp>` is passed to the process called with `docke exec` and the process started stores its pid in the file path passed. Traps are set in `run-docker.sh` that runs the `docker exec` command to receive any kills signals, and if it does, it runs another `docker exec` command to read the pid of the process previously started from `DOCKER_EXEC_PID_FILE_PATH` and then kills it and all its children.
See Also:
https://github.com/docker/cli/issues/2607https://github.com/moby/moby/issues/9098https://github.com/moby/moby/pull/41548https://stackoverflow.com/questions/41097652/how-to-fix-ctrlc-inside-a-docker-container
Also passing `--init` to `docker run` to "Run an init inside the container that forwards signals and reaps processes", although it does not work for above cases, but may helpful in others. The `--init` flag changes will only engage on new container creation.
https://docs.docker.com/engine/reference/run/#specify-an-init-processhttps://docs.docker.com/engine/reference/commandline/run/
```
./scripts/run-docker.sh ./build-package.sh -f libjpeg-turbo &> build.log
^C
$ ./scripts/run-docker.sh ps -efww
Running container 'termux-package-builder' from image 'termux/package-builder'...
UID PID PPID C STIME TTY TIME CMD
builder 1 0 0 05:48 pts/0 00:00:00 bash
builder 9243 0 0 06:01 pts/1 00:00:00 bash
builder 28127 0 0 06:12 ? 00:00:00 /bin/bash ./build-package.sh -f libjpeg-turbo
builder 28141 28127 0 06:12 ? 00:00:00 /bin/bash ./build-package.sh -f libjpeg-turbo
builder 28449 28141 1 06:12 ? 00:00:00 ninja -w dupbuild=warn -j 8
builder 28656 28449 0 06:12 ? 00:00:00 /bin/sh -c /home/builder/.termux-build/_cache/android-r23c-api-24-v0/bin/clang
builder 28657 28656 79 06:12 ? 00:00:01 /home/builder/.termux-build/_cache/android-r23c-api-24-v0/bin/clang
builder 28694 28449 0 06:12 ? 00:00:00 /bin/sh -c /home/builder/.termux-build/_cache/android-r23c-api-24-v0/bin/clang
builder 28695 28694 89 06:12 ? 00:00:00 /home/builder/.termux-build/_cache/android-r23c-api-24-v0/bin/clang
builder 28728 28449 0 06:12 ? 00:00:00 /bin/sh -c /home/builder/.termux-build/_cache/android-r23c-api-24-v0/bin/clang
builder 28729 28728 0 06:12 ? 00:00:00 /home/builder/.termux-build/_cache/android-r23c-api-24-v0/bin/clang
builder 28731 28449 0 06:12 ? 00:00:00 /bin/sh -c /home/builder/.termux-build/_cache/android-r23c-api-24-v0/bin/clang
builder 28734 28731 0 06:12 ? 00:00:00 /home/builder/.termux-build/_cache/android-r23c-api-24-v0/bin/clang
builder 28740 28449 0 06:12 ? 00:00:00 /bin/sh -c /home/builder/.termux-build/_cache/android-r23c-api-24-v0/bin/clang
builder 28741 28740 0 06:12 ? 00:00:00 /home/builder/.termux-build/_cache/android-r23c-api-24-v0/bin/clang
builder 28744 0 0 06:12 pts/2 00:00:00 ps -efww
builder 28748 28449 0 06:12 ? 00:00:00 /bin/sh -c /home/builder/.termux-build/_cache/android-r23c-api-24-v0/bin/clang
builder 28752 28748 0 06:12 ? 00:00:00 /home/builder/.termux-build/_cache/android-r23c-api-24-v0/bin/clang
builder 28753 28449 0 06:12 ? 00:00:00 /bin/sh -c /home/builder/.termux-build/_cache/android-r23c-api-24-v0/bin/clang
builder 28754 28753 0 06:12 ? 00:00:00 /home/builder/.termux-build/_cache/android-r23c-api-24-v0/bin/clang
builder 28755 28449 0 06:12 ? 00:00:00 ninja -w dupbuild=warn -j 8
$ ./scripts/run-docker.sh ./build-package.sh -f libjpeg-turbo &> build.log
$ ./scripts/run-docker.sh ./build-package.sh -f libjpeg-turbo
Running container 'termux-package-builder' from image 'termux/package-builder'...
ERROR: Another build is already running within same environment.
```
Absolute paths are still allowed in `DCMAKE_INSTALL_LIBDIR` as per https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html
Different packages have different way of handling `DCMAKE_INSTALL_LIBDIR`. The `libprotobuf` is appending an absolute path to `build` directory (#10068), while `libjpeg-turbo` is not appending a relative `lib` path to `DCMAKE_INSTALL_PREFIX` and instead appending to `build` directory and so all the lib files stay at `/home/builder/.termux-build/libjpeg-turbo/build/lib` and hence won't get added to the `deb`, which results in `openjdk-17` failing if `-i` is not passed to `build-package.sh`, since it can't find `libjpeg.so` with `-L${TERMUX_PREFIX}/lib` after compilation from source, unless `-L$TERMUX_TOPDIR/libjpeg-turbo/build/lib` is passed.
Considering that most packages would likely be considering an absolute path passed in `DCMAKE_INSTALL_LIBDIR` to actually be absolute, the default behaviour should be reverted, specially considering it is what's been working, otherwise lot of packages would need testing, like from https://github.com/termux/termux-packages/commit/9155acd040.
```
checking for which libjpeg to use... system
checking jpeglib.h usability... yes
configure: WARNING: jpeglib.h: accepted by the compiler, rejected by the preprocessor!
checking jpeglib.h presence... no
checking for jpeglib.h... yes
configure: WARNING: jpeglib.h: proceeding with the compiler's result
configure: error: --with-libjpeg=system specified, but no libjpeg found
checking for jpeg_CreateDecompress in -ljpeg... no
configure exiting with result code 1
```
```
[0/1] Install the project...
-- Install configuration: "Release"
-- Installing: /home/builder/.termux-build/libjpeg-turbo/build/lib/libturbojpeg.so
-- Installing: /data/data/com.termux/files/usr/bin/tjbench
-- Installing: /home/builder/.termux-build/libjpeg-turbo/build/lib/libturbojpeg.a
-- Installing: /data/data/com.termux/files/usr/include/turbojpeg.h
-- Installing: /home/builder/.termux-build/libjpeg-turbo/build/lib/libjpeg.a
-- Installing: /data/data/com.termux/files/usr/bin/rdjpgcom
-- Installing: /data/data/com.termux/files/usr/bin/wrjpgcom
-- Installing: /data/data/com.termux/files/usr/share/doc/libjpeg-turbo/README.ijg
-- Installing: /data/data/com.termux/files/usr/share/doc/libjpeg-turbo/README.md
-- Installing: /data/data/com.termux/files/usr/share/doc/libjpeg-turbo/example.txt
-- Installing: /data/data/com.termux/files/usr/share/doc/libjpeg-turbo/tjexample.c
-- Installing: /data/data/com.termux/files/usr/share/doc/libjpeg-turbo/libjpeg.txt
-- Installing: /data/data/com.termux/files/usr/share/doc/libjpeg-turbo/structure.txt
-- Installing: /data/data/com.termux/files/usr/share/doc/libjpeg-turbo/usage.txt
-- Installing: /data/data/com.termux/files/usr/share/doc/libjpeg-turbo/wizard.txt
-- Installing: /data/data/com.termux/files/usr/share/doc/libjpeg-turbo/LICENSE.md
-- Installing: /data/data/com.termux/files/usr/share/man/man1/cjpeg.1
-- Installing: /data/data/com.termux/files/usr/share/man/man1/djpeg.1
-- Installing: /data/data/com.termux/files/usr/share/man/man1/jpegtran.1
-- Installing: /data/data/com.termux/files/usr/share/man/man1/rdjpgcom.1
-- Installing: /data/data/com.termux/files/usr/share/man/man1/wrjpgcom.1
-- Installing: /home/builder/.termux-build/libjpeg-turbo/build/lib/pkgconfig/libjpeg.pc
-- Installing: /home/builder/.termux-build/libjpeg-turbo/build/lib/pkgconfig/libturbojpeg.pc
-- Installing: /home/builder/.termux-build/libjpeg-turbo/build/lib/cmake/libjpeg-turbo/libjpeg-turboConfig.cmake
-- Installing: /home/builder/.termux-build/libjpeg-turbo/build/lib/cmake/libjpeg-turbo/libjpeg-turboConfigVersion.cmake
-- Installing: /home/builder/.termux-build/libjpeg-turbo/build/lib/cmake/libjpeg-turbo/libjpeg-turboTargets.cmake
-- Installing: /home/builder/.termux-build/libjpeg-turbo/build/lib/cmake/libjpeg-turbo/libjpeg-turboTargets-release.cmake
-- Installing: /data/data/com.termux/files/usr/include/jconfig.h
-- Installing: /data/data/com.termux/files/usr/include/jerror.h
-- Installing: /data/data/com.termux/files/usr/include/jmorecfg.h
-- Installing: /data/data/com.termux/files/usr/include/jpeglib.h
-- Installing: /home/builder/.termux-build/libjpeg-turbo/build/lib/libjpeg.so
-- Installing: /data/data/com.termux/files/usr/bin/cjpeg
-- Installing: /data/data/com.termux/files/usr/bin/djpeg
-- Installing: /data/data/com.termux/files/usr/bin/jpegtran
...
Most scripts are set up to just be sourced, but these ones can handle
being run as well. They have not had a shebang set though, use
/usr/bin/bash to ensure they work as intended.
Some of the IPs of fosshost's proxy do not work (see
termux/termux-packages#11007), so stick to using one that we know work
until that is fixed.
Suggested by agnostic-apollo.
Make changes as per new design implemented in termux/termux-app@b950efec and termux/termux-app#2740
The package build and termux-tools scripts use current package manager for custom logic. The `termux-tools/termux-setup-package-manager` script has been added that will now be used to provide backward compatibility for termux-app `< 0.119.0` (when its released) and validate the package manager. It will also ensure the variable in not unset to prevent `unbound variable` errors if `set -u` is being used by calling scripts.
Closes#10782
Currently, we assume that a package is not coupled with any specific
version of it's dependencies. Therefore, we update them individually
without any specific order. But this assumtion fails for package
families like lxqt which requires all it's family members to be of
specific version.
Although we would have to manually update dependencies in such
situation (if they can not be auto-updated), but we can atleast
decide order of updation for packages that can be auto-updated.
Signed-off-by: Aditya Alok <dev.aditya.alok@gmail.com>
- add checks for 'newest-tag' as fallback, if 'latest-release-tag' is not found
- adhere to DRY principle
Signed-off-by: Aditya Alok <dev.aditya.alok@gmail.com>
Butta
Tee KOBAYASHI
Aditya Alok
Henrik Grimler
Ivan Max
Leonid Pliushch
Yaksh Bariya
ifurther
Chongyun Lee
Jia Yuan Lo
Arun
T-Dynamos
Leonid Pliushch
kawanakaiku
Lucy Phipps
Kevin Williams
sogaiu
tjhexf
agnostic-apollo
Ivan Max
MedzikUser
Leonid Pliushch
Henrik Grimler
tjhexf
Aditya Alok