new package: python-numpy

[licy183]

These packages are built with old NDK toolchain, and I think they will not be accepted by the main repo.

Test results are as following:

Numpy Test Results

Architecture / RAM Size	Android Version	Result	Comment
AArch64 / 12G	11.0	18 failed, 17619 passed, 342 skipped, 1302 deselected, 39 xfailed, 2 xpassed, 9 errors in 165.51s (0:02:45)
ARM / 6G	9.0	4 failed, 17071 passed, 1191 skipped, 1302 deselected, 39 xfailed, 2 xpassed, 19 warnings, 9 errors in 380.60s (0:06:20)
X86-64 / 4G	7.0	8 failed, 17721 passed, 1442 skipped, 1302 deselected, 36 xfailed, 5 xpassed, 4 warnings, 9 errors in 113.52s (0:01:53)	On a BlueStacks 5 VM
X86 / 4G	7.0	3 failed, 17707 passed, 1450 skipped, 1302 deselected, 39 xfailed, 2 xpassed, 4 warnings, 9 errors in 125.58s (0:02:05)	On a BlueStacks 5 VM

Scipy Test Results

Architecture / RAM Size	Android Version	Result	Comment
AArch64 / 12G	11.0	370 failed, 35036 passed, 2758 skipped, 11452 deselected, 104 xfailed, 10 xpassed, 120 warnings in 957.88s (0:15:57)
ARM / 6G	9.0	15 failed, 18834 passed, 27 skipped, 11424 deselected, 344 xfailed, 10 xpassed, 26 warnings in 3499.34s (0:58:19)	Testing are lagging for about 30 minutes when executing signal/tests/test_signaltools.py, so it was cancelled midway.
X86-64 / 4G	7.0	5 failed, 35403 passed, 2755 skipped, 11452 deselected, 104 xfailed, 11 xpassed, 28 warnings in 490.26s (0:08:10)	On a BlueStacks 5 VM
X86 / 4G	7.0	Invalid	On a BlueStacks 5 VM. Segmentation fault when executing linalg/tests/test_basic.py.

I wonder if scipy in this Pull Request is acceptable to be added to this repo.

Any ideas? @kcubeterm @2096779623

[kcubeterm]

I wonder if scipy in this Pull Request is acceptable to be added to this repo.

Remove scipy for now as it looks critical or blacklist those aarch where scipy is not passing sufficient tests.

[licy183]

I think openblas and scipy is critical to use so I will only add numpy (disable blas) into TUR. The android-gfortran toolchain uses gcc-4.9. It is too old for modern C++, even not with a full C++11 feature support (std::to_string is not availble).

[2096779623]

@kcubeterm Need to differentiate root packages like termux-packages does?

[kcubeterm]

I believe, we just keep separate folders for root packages so that maintainer would be know in advance that packages require root. But we serve those deb files under same apt repository. Creating another repo means, one more sub domain will be used.

What you both think on it ?

[2096779623]

I believe, we just keep separate folders for root packages so that maintainer would be know in advance that packages require root. But we serve those deb files under same apt repository. Creating another repo means, one more sub domain will be used.

What you both think on it ?

Creating too many subdomains is not a good idea.

A reverse proxy is a method.

[kcubeterm]

No no, it won't require sub domain. As I host a redirector on my server. What's actually needs is,

deb tur.kcubeterm. com tur tur-root >> $prefix/../../tur-root.list

Will make job done.

Thanks @2096779623 for sharing idea.

[kcubeterm]

Here is redirector source code. Which handle TUR and Github termux mirror

https://github.com/termux-user-repository/dists/blob/master/scripts/redirector.go

[licy183]

No no, it won't require sub domain. As I host a redirector on my server. What's actually needs is,

deb tur.kcubeterm. com tur tur-root >> $prefix/../../tur-root.list

I'd prefer this.