fix(main/uv): Fix #28771: Update uv

[Benjamin-Loison]

@robertkirkman

[robertkirkman]

Does this fix this issue?

• uv 0.9.15 worked on python 3.12. fails on python 3.13 (pep 738) #28771

Also, what about 64-bit x86 architecture, does that need a case to handle it also?

[Benjamin-Loison]

Does this fix this issue?

* [uv 0.9.15 worked on python 3.12. fails on python 3.13 (pep 738) #28771](https://github.com/termux/termux-packages/issues/28771)

Also, what about 64-bit x86 architecture, does that need a case to handle it also?

As current pull request title denotes, yes it solves #28771. x86 does not need to be explicitly mentioned as x86 is fine (the conversion would be the identity), hence android_abi_to_arch.get(architecture, architecture) default second argument architecture works as wanted a priori, I couldn't test with a 32-bits device.

[zanieb]

It'd be great if ya'll could wait for us to validate the correct change upstream instead of shipping incremental patches from a third-party contributor.

[robertkirkman]

It'd be great if ya'll could wait for us to validate the correct change upstream instead of shipping incremental patches from a third-party contributor.

When you make an upstream solution, it won't be testable yet though, right, since the current newest version of uv doesn't work on Android even with Python 3.12? (and the change might not apply without conflicts to the older version that did work)

[Benjamin-Loison]

It'd be great if ya'll could wait for us to validate the correct change upstream instead of shipping incremental patches from a third-party contributor.

When you make an upstream solution, it won't be testable yet though, right, since the current newest version of uv doesn't work on Android even with Python 3.12?

I agree we are blocked to uv 0.9.5, even on Python 3.12, so no matter uv upstream change we need a specific Termux patch in termux-packages repository. Waiting upstream would just avoid potentially changing our potentially different patch to upstream one to get on the same page, otherwise solving the blocking issue as quick as possible seems to be the priority in my opinion.

[zanieb]

I'm fully supportive of ya'll backporting a fix, but the last one was clearly incorrect to us.

It looks like you're stuck on 0.9.15 because your previous patches didn't apply? I think that's a good reason to engage with us upstream about issues, e.g., I didn't know about #27176 until now.

[robertkirkman]

I'm fully supportive of ya'll backporting a fix, but the last one was clearly incorrect to us.

It looks like you're stuck on 0.9.15 because your previous patches didn't apply? I think that's a good reason to engage with us upstream about issues, e.g., I didn't know about #27176 until now.

I think this is the issue in the uv repo:

• Support target aarch64-linux-android astral-sh/uv#14574

[robertkirkman]

A user @NoNameWasDefined reported this (#28804) works for them (through Discord)

[robertkirkman]

@Benjamin-Loison since zanieb says that 00003-android-as-linux.patch is incorrect, should you remove that one?

If you remove it, does the previous error return?

[zanieb]

Incorrect as-in incomplete, i.e., the architecture transformation is needed too.

This patch also seems a bit weird because the android_abi_to_arch mapping is applied even if the operating system is "linux".

[zanieb]

astral-sh/uv#14574 looks focused us supporting builds for the target? It doesn't mention the flock patch at all.

[Benjamin-Loison]

@Benjamin-Loison since zanieb says that 00003-android-as-linux.patch is incorrect, should you remove that one?

If you remove it, does the previous error return?

I think zanieb said that it was incorrect because I was just correcting android -> linux conversion, but CPU architectures was also requiring a patch, except for transparent ones (x86-64 I tested on for instance, but not armv8). I added such CPU architecture conversion patch in files#diff-d12ce5cc241cf88e44f91c13709f0ce237f0595c796bbda4688a63bcea5794a5. So if you remove such patch on armv8 you will face again termux/termux-packages/issues/28771#issuecomment-4003445144, except if we achieve updating Termux uv version (without facing termux/termux-packages/issues/27547#issuecomment-4001663009) and upstream uv merges astral-sh/uv/pull/18296.

[robertkirkman]

I'm sorry for the confusion, I interpreted that issue as "catch-all Android support", coming with the implication that once the uv repository had an official Android build, they would test it and eventually encounter any follow-up Android-specific issues that would then become reproducible in the official build.

[Benjamin-Loison]

astral-sh/uv#14574 looks focused us supporting builds for the target? It doesn't mention the flock patch at all.

It seems that I agree with you.

[Benjamin-Loison]

Incorrect as-in incomplete, i.e., the architecture transformation is needed too.

This patch also seems a bit weird because the android_abi_to_arch mapping is applied even if the operating system is "linux".

This is by purpose, see #discussion_r2891055748.

[zanieb]

I'm sorry for the confusion, I interpreted that issue as "catch-all Android support", coming with the implication that once the uv repository had an official Android build, they would test it and eventually encounter any follow-up Android-specific issues that would then become reproducible in the official build.

That makes sense, but I'd also happily use an android-specific flock approach so you don't need to carry a patch even if we don't have full support. Feel free to open specific issues in the future.

This is by purpose, see #28804 (comment).

I'm not sure I follow, the system can report "linux" as the operating system and still report android-style architectures?

[Benjamin-Loison]

This is by purpose, see #28804 (comment).

I'm not sure I follow, the system can report "linux" as the operating system and still report android-style architectures?

I was unsure about this and preferred being on the safe side by converting CPU architectures for linux in case of doubt, but #discussion_r2891291290 seems to show that such mapping does not seem required for linux, I am waiting @robertkirkman confirmation before updating according my pull requests.

[Benjamin-Loison]

@robertkirkman
@zanieb

I updated accordingly both pull requests.

[NoNameWasDefined]

Yes, now the command uv tool install behave like before. Thanks.

[NoNameWasDefined]

A user @NoNameWasDefined reported this (#28804) works for them (through Discord)

Replying from this msg sorry

[robertkirkman]

@robertkirkman let me know if you want me to propose the same patch as astral-sh/uv/pull/18301 until we achieve updating uv version. In my opinion we can rely on my current patch until we update the uv version (no patch will then be necessary).

Actually what I was wondering is, now that upstream is fixing the build for Android, could you make this PR into a PR to update uv to the newest version and replace all the downstream patches with patches copied from upstream's PRs? That way, this issue could also be fixed at the same time:

• Auto update failing for uv #27547

[Benjamin-Loison]

@robertkirkman let me know if you want me to propose the same patch as astral-sh/uv/pull/18301 until we achieve updating uv version. In my opinion we can rely on my current patch until we update the uv version (no patch will then be necessary).

Actually what I was wondering is, now that upstream is fixing the build for Android, could you make this PR into a PR to update uv to the newest version and replace all the downstream patches with patches copied from upstream's PRs? That way, this issue could also be fixed at the same time:

* [Auto update failing for uv #27547](https://github.com/termux/termux-packages/issues/27547)

now that upstream is fixing the build for Android

looks unclear to me, are you referring to astral-sh/uv#18333?

So you don't want to wait astral-sh/uv#18323 getting merged, and want to make current PR contain astral-sh/uv#18323 to have an up-to-date Termux uv?

[robertkirkman]

So you don't want to wait astral-sh/uv#18323 getting merged, and want to make current PR contain astral-sh/uv#18323 to have an up-to-date Termux uv?

If that's ok with them, yes.

[Benjamin-Loison]

So you don't want to wait astral-sh/uv#18323 getting merged, and want to make current PR contain astral-sh/uv#18323 to have an up-to-date Termux uv?

If that's ok with them, yes.

I am currently testing such an approach at Benjamin-Loison/termux-packages/issues/15.

[Benjamin-Loison]

@robertkirkman I updated current PR accordingly.

[zanieb]

I think you'll need to take astral-sh/uv#18323 (though it has not been tested and reviewed on our end yet) or uv will be unusable.

[robertkirkman]

I think you'll need to take astral-sh/uv#18323 (though it has not been tested and reviewed on our end yet) or uv will be unusable.

@Benjamin-Loison I think that is a good idea, and then once it is built in a termux package, termux users can test it by downloading the PR artifact here and check the behavior.

[Benjamin-Loison]

@robertkirkman I updated current PR accordingly.

I just forgot to git add packages/uv/00002-fix-file-locks-on-android.patch, I corrected my PR. I tested it on both Virtual Machine Manager x86-64 LineageOS 23.0 and Fairphone 4 armv8 LineageOS 23.2.

[robertkirkman]

Ok, now, could you make this cleanup change in the package?

--- a/packages/uv/build.sh
+++ b/packages/uv/build.sh
@@ -13,17 +13,6 @@ TERMUX_PKG_AUTO_UPDATE=true
 termux_step_pre_configure() {
 	termux_setup_cmake
 	termux_setup_rust
-
-	# Dummy CMake toolchain file to workaround build error:
-	# error: failed to run custom build command for `libz-ng-sys v1.1.15`
-	# ...
-	# CMake Error at /home/builder/.termux-build/_cache/cmake-3.28.3/share/cmake-3.28/Modules/Platform/Android-Determine.cmake:217 (message):
-	# Android: Neither the NDK or a standalone toolchain was found.
-	export TARGET_CMAKE_TOOLCHAIN_FILE="${TERMUX_PKG_BUILDDIR}/android.toolchain.cmake"
-	touch "${TERMUX_PKG_BUILDDIR}/android.toolchain.cmake"
-
-	: "${CARGO_HOME:=$HOME/.cargo}"
-	export CARGO_HOME
 }
 
 termux_step_make() {

when I test building this, it seems like that section is not necessary anymore, because that error does not occur anymore. Setting CARGO_HOME is also not necessary anymore because that is only needed for patching crates in a way without cargo vendor that is not necessary here anymore, and if crate patches are added in the future, they should use different code that does not involve CARGO_HOME.

[Benjamin-Loison]

@robertkirkman I proceeded to your requested changes.

[robertkirkman]

That's great!

@okhex @NoNameWasDefined @shel1kest0learn @Vinfall @DroidKali could you download this PR's GitHub Actions artifact when it finishes building and try using this build of uv, to check whether it is working properly or not?

[NoNameWasDefined]

@okhex @NoNameWasDefined @shel1kest0learn @Vinfall @DroidKali could you download this PR's GitHub Actions artifact when it finishes building and try using this build of uv, to check whether it is working properly or not?

I will do it, yes. I'm waiting for the build to finish. (Building it is really slow)

[NoNameWasDefined]

Installing MyPy works with uv tool install mypy

[okhex]

Everything is working properly now 👍

astral-sh/uv#9559 This issue can be closed now

[robertkirkman]

Ok @zanieb would you recommend we wait until your PR is finalized and merged upstream, or do you think it is fine to merge this PR now?

[zanieb]

I'm supportive of you carrying the patch without it landing upstream if it's working — it'll take us a bit longer to get an Android test pipeline figured out.

[robertkirkman]

Ok, I will wait a little while for anyone using this to report issues, then merge it if none are found.

[robertkirkman]

There are some existing issues loosely related to uv in Termux that this does not solve (at least I think it doesn't),

• [Bug]: uv - Failed building wheel for homeassistant #22422
• uv pip list does not read all system packages in sys.path and ignores system-site-packages astral-sh/uv#2500

however, those are edge cases specific to particular PyPi packages and should be solved separately.

[zanieb]

This should close #22422 as it fixes the sys-info compile error and we haven't required CMake for a while now (astral-sh/uv#11894)

[shel1kest0learn]

That's great!

@okhex @NoNameWasDefined @shel1kest0learn @Vinfall @DroidKali could you download this PR's GitHub Actions artifact when it finishes building and try using this build of uv, to check whether it is working properly or not?

uv_0.10.9_aarch64.deb uv pip list successful