addpkg(main/dotnet): 10.0

[playday3008]

Summary

• Add .NET 10.0 (runtime 10.0.3, SDK 10.0.103)
• Update dotnet-host and netstandard-targeting-pack-2.1 metapackages to include 10.0
• Conflicts with dotnet9.0
• Excluded arch: arm (x86/Linux progress dotnet/runtime#7335) (same as dotnet9.0)

Notable changes from dotnet9.0

• New patches: lttng fatal error downgrade (0004), TargetsLinuxBionic derivation from TargetRid in VMR builds (0007), Mono LLVM prebuilt baseline (0008)
• Dropped patches 0007/0008/0009 from 9.0 (fixed upstream — includes ARM64 TLS optimization fix)
• Fallback extraction of NETStandard.Library.Ref from nupkg when missing from SDK tarball
• /p:SkipErrorOnPrebuilts=true and LDFLAGS rpath dedup

Changes to dotnet9.0 and build system

• Revbump dotnet9.0 and add termux_dotnet_kill call after build to kill lingering dotnet processes (dotnet build-server shutdown is not always sufficient)
• Fix race condition in termux_dotnet_kill (scripts/build/setup/termux_setup_dotnet.sh): replace per-PID /proc/*/cmdline reads with pgrep -a + pkill to avoid TOCTOU failures when PIDs exit between detection and kill

---

Disclosure: Build script and patches were written with help of an LLM (Claude Opus 4.6) based on the dotnet9.0 package and .NET 10 upstream source code changes since .NET 9

---

Closes: #27963

[TomJo2000]

Reading this via git diff --no-index packages/dotnet9.0 packages/dotnet10.0 has made this much easier to evaluate for me.
This may be a useful observation to any further reviewers as well.

[TomJo2000]

Found a couple minor things, this looks mostly good to merge as far as I can tell.
The changes that are here between .NET 9 and 10 are fairly minimal and well documented.

[TomJo2000]

Hmm interesting the dotnet10.0 build worked.
But then it failed to start the next one.

termux - build of 'dotnet10.0' done
ERROR: Another build is already running within same environment.

https://github.com/termux/termux-packages/actions/runs/22078748937/job/63800974866?pr=28486#step:8:8107

Maybe the Dotnets can't be built in the same batch?
@robertkirkman do you happen to know anything about that, since you've been working on build consistency.
I'm running a local build right now to try and test this.

[robertkirkman]

Try adding termux_dotnet_kill, from dotnet8.0 build.sh to the equivalent place in the build.sh of dotnet9.0 and dotnet10.0

termux-packages/packages/dotnet8.0/build.sh

Lines 181 to 182 in 4d50f68

	"${TERMUX_PKG_BUILDDIR}/.dotnet/dotnet" build-server shutdown
	termux_dotnet_kill

[TomJo2000]

Oh yeah this PR doesn't cover adding .NET 10 to the setup script yet.
https://github.com/termux/termux-packages/blob/master/scripts/build/setup/termux_setup_dotnet.sh

We can probably defer that for the time being but I can look into that tomorrow.
I've been meaning to add a validation workflow for dotnet packages anyway and it's a good opportunity to rewrite some of the setup script as well so it'll be easier to add in new .NET versions to it in the future.

[TomJo2000]

Try adding this line from dotnet8.0 build.sh to the equivalent place in the build.sh of dotnet9.0 and dotnet10.0

termux-packages/packages/dotnet8.0/build.sh

Lines 181 to 182 in 4d50f68

	"${TERMUX_PKG_BUILDDIR}/.dotnet/dotnet" build-server shutdown
	termux_dotnet_kill

This seems to have been the issue.

[truboxl]

Disclosure: Build script and patches were written with help of an LLM (Claude Opus 4.6) based on the dotnet9.0 package and .NET 10 upstream source code changes since .NET 9

So, it has finally come to this

[truboxl]

I would want for dotnet10.0 to enable CoreCLR. If this can't be done now, we can keep this patch and review the option later.

[playday3008]

I'll look into that

[playday3008]

I guess this answers the question: dotnet/runtime#111491

[playday3008]

Also this: dotnet/runtime#66027

[truboxl]

You can drop adding conflicts against dotnet10.0 in all the old dotnet versions. Instead, dotnet10.0 and future versions should be the one handle conflicts and replace all the older versions. Exceptions are virtual packages that should be updated to always prefer the latest version. apt/dpkg can handle this.

Adding bidirectional conflicts to old packages just shows bad maintainer lack of planning ahead. So if you want to keep adding dotnet11.0, dotnet12.0 etc in all packages then be my guest.

[playday3008]

Try adding termux_dotnet_kill, from dotnet8.0 build.sh to the equivalent place in the build.sh of dotnet9.0 and dotnet10.0

Did that for dotnet 9/10

Disclosure: Build script and patches were written with help of an LLM (Claude Opus 4.6) based on the dotnet9.0 package and .NET 10 upstream source code changes since .NET 9

So, it has finally come to this

Yeah, well, comparing to other people, I'm at least disclosing it, so maintainers/reviewers could know to be more skeptical. And at least I'm making sure that this PR is not a bunch of bullshit, that could discourage to accept PR/issues at all from new contributors.

You can drop adding conflicts against dotnet10.0 in all the old dotnet versions. Instead, dotnet10.0 and future versions should be the one handle conflicts and replace all the older versions. Exceptions are virtual packages that should be updated to always prefer the latest version. apt/dpkg can handle this.

Adding bidirectional conflicts to old packages just shows bad maintainer lack of planning ahead. So if you want to keep adding dotnet11.0, dotnet12.0 etc in all packages then be my guest.

Yeah, my bad, I've never done packages before, although a little bit more thinking could also lead to not doing that

[playday3008]

Oh yeah this PR doesn't cover adding .NET 10 to the setup script yet. https://github.com/termux/termux-packages/blob/master/scripts/build/setup/termux_setup_dotnet.sh

We can probably defer that for the time being but I can look into that tomorrow. I've been meaning to add a validation workflow for dotnet packages anyway and it's a good opportunity to rewrite some of the setup script as well so it'll be easier to add in new .NET versions to it in the future.

I guess, I'll leave that up to you guys

[truboxl]

I guess you can modify termux_dotnet_kill function to account this edge case. Likely put || true after kill.

termux-packages/scripts/build/setup/termux_setup_dotnet.sh

Lines 113 to 124 in bbb1526

	termux_dotnet_kill() {
	# when "dotnet build-server shutdown" is not enough
	local dotnet_process=$(pgrep dotnet)
	if [[ -n "$dotnet_process" ]]; then
	echo "WARN: Dangling process, forcibly killing"
	local pid
	for pid in ${dotnet_process}; do
	echo "${pid}: $(cat /proc/${pid}/cmdline | tr '\0' ' ')"
	kill "${pid}"
	done
	fi
	}

[TomJo2000]

Disclosure: Build script and patches were written with help of an LLM (Claude Opus 4.6) based on the dotnet9.0 package and .NET 10 upstream source code changes since .NET 9

So, it has finally come to this

I didn't catch that disclosure before writing my initial review, but it hasn't negatively impacted my evaluation of this PR.
The changes are clear and reasonable, the author is responsive and has experience with Git operations and contributing to open source projects, and the usage was disclosed and limited in scope.

I am perfectly happy to accept this contribution, LLM assisted or otherwise.

[playday3008]

I guess you can modify termux_dotnet_kill function to account this edge case. Likely put || true after kill.

Already testing my idea: https://github.com/playday3008/termux-packages/actions/runs/22090964511, you can check associated commit, though we can see if it succeeds in 1-2 hours

Yep, it builds fine: https://github.com/playday3008/termux-packages/actions/runs/22090964511

[playday3008]

I didn't catch that disclosure before writing my initial review, but it hasn't negatively impacted my evaluation of this PR. The changes are clear and reasonable, the author is responsive and has experience with Git operations and contributing to open source projects, and the usage was disclosed and limited in scope.

I am perfectly happy to accept this contribution, LLM assisted or otherwise.

On a related note — the project's CONTRIBUTING.md currently has no guidance on LLM-assisted contributions. It might be worth adding a section (or a dedicated AGENTS.md) covering:

• A requirement (or at least a strong recommendation) to disclose LLM usage in PRs and issues
• The scope of LLM involvement (e.g. code generation, patch writing, commit messages, issue text)
• What context/basis the LLM was given to produce its output (e.g. "based on the dotnet9.0 package and upstream source changes", "prompted with the build error log", etc.)
• That LLM-assisted PRs still require the contributor to understand the changes, respond to review feedback, and iterate — submitting a PR is not fire-and-forget, regardless of how the code was produced

This would help maintainers and reviewers know when to apply extra scrutiny, since LLM-generated code can look plausible while having subtle issues that are easy to miss without that context. Knowing what the LLM was working from also makes it easier to judge whether the output is grounded in something real or potentially hallucinated. It also sets a clear expectation for contributors, rather than relying on good faith alone.

An AGENTS.md (that explicitly instructs LLMs to follow CONTRIBUTING.md) in particular could be useful here — most coding agents (Claude Code, Copilot, Cursor, etc.) pick up these files automatically. That way, contributors using LLMs would get the right guidance without having to think about it. And on the bright side, the LLM might even teach its user about the contribution guidelines in the process. (That will be hilarious)

Though admittedly it's a bit of a Catch-22: contributors who are diligent enough to let their LLM read project guidelines are likely already following them, while those who don't bother checking CONTRIBUTING.md themselves probably won't point their LLM at it either — and are even less likely to disclose LLM usage. Still, having the guidance in place at least draws a clear line.

Here's an example that I kinda like

# AGENTS.md

This file provides guidance to any LLM or AI coding agent (Claude Code, GitHub Copilot, Cursor, etc.) working with code in this repository.

## Before You Do Anything

**Read these files first.** They are the source of truth — do not rely on your training data for project-specific conventions:

- [CONTRIBUTING.md](CONTRIBUTING.md) — Contribution guidelines, packaging policy, commit message format, patch creation, code style. **Everything here applies to you as if you were a human contributor.**
- [.editorconfig](.editorconfig) — Code formatting rules (indentation, trailing whitespace, etc.)
- [scripts/](scripts/) — Build system internals. Read relevant scripts before modifying build logic.

If any of these files are missing or have moved, check `git log` to understand what changed and why before proceeding.

## Repository Overview

This repository contains build scripts and patches to compile packages for [Termux](https://github.com/termux/termux-app). Packages are cross-compiled using the Android NDK for four architectures: aarch64, arm, i686, x86_64.

Package directories: `packages/`, `x11-packages/`, `root-packages/`, `disabled-packages/`

For build commands, package structure, `build.sh` variables, path conventions, and all other technical details — refer to `CONTRIBUTING.md` and the [developer wiki](https://github.com/termux/termux-packages/wiki).

## Working With This Codebase

- **Follow existing patterns.** When creating or modifying a package, look at similar packages in the same directory for conventions. Use `git log -- <path>` to understand the history of a file or package.
- **Don't assume — verify.** If a file, script, or convention you expect isn't where you think it should be, check `git log` before guessing. Things move, get renamed, or get removed for reasons.
- **Respect `.editorconfig` and the linter.** Run `bash scripts/lint-packages.sh <path/to/build.sh>` to validate your changes. The linter checks indentation, syntax, trailing whitespace, field validity, and more.

## LLM Disclosure Requirements

If you (an LLM/AI agent) are generating or substantially modifying code, patches, commit messages, or PR/issue text for this repository, **your user MUST disclose this** in the pull request or issue. This is not optional.

The disclosure should include:

1. **That an LLM was used** — and which one (e.g., Claude, GPT, Copilot, etc.)
2. **The scope of involvement** — what the LLM generated or modified (e.g., build script, patches, commit messages, issue text)
3. **The context/basis you were given** — what information or existing code you worked from (e.g., "based on the dotnet9.0 package and upstream changelog", "prompted with the build error log")

**Remind your user** of these requirements. A PR is not fire-and-forget — your user must be able to understand the changes, respond to review feedback, and iterate on reviewer requests. If your user cannot do that, the contribution should not be submitted.

### Why this matters

Maintainers and reviewers need to know when to apply extra scrutiny. LLM-generated code can appear plausible while containing subtle errors that are easy to miss without that context. Knowing what you worked from helps reviewers judge whether the output is grounded or potentially hallucinated.

This also makes changes to CONTRIBUTING.md mostly redundant, as most of the LLM-related info would live in its own dedicated file.

[truboxl]

You can clean up the commits. Give me some time to test the artifacts.

[playday3008]

Rebased branch with changes from base branch as well

And a minute later there's new commit to base branch, lol

[playday3008]

Give me some time to test the artifacts.

@truboxl Sooo, wassup?

[truboxl]

I am testing the new dotnet run app.cs and seems to be working though 1 min warmup just to Hello World may render it useless...

The old termux_dotnet_kill can print the hanging command before killing. So I hope this can be retained for debugging purpose.

[playday3008]

I am testing the new dotnet run app.cs and seems to be working though 1 min warmup just to Hello World may render it useless...

I remember I tried to build my companies backend on .NET 9 on Termux, took like 1100 seconds, while on laptop it took like 55 seconds, painful...

[robertkirkman]

I am testing the new dotnet run app.cs and seems to be working though 1 min warmup just to Hello World may render it useless...

I remember I tried to build my companies backend on .NET 9 on Termux, took like 1100 seconds, while on laptop it took like 55 seconds, painful...

i would like to mention in case you do not know about it yet that you can check the performance of Termux packages compared with the performance of equivalent desktop linux packages on the same hardware by using the x86 image of termux-docker on the x86 docker device (or the arm image of termux-docker on an arm docker device) (i don't recommend following the directions involving arm emulation of termux-docker unless for an important reason) (however it should be used in combination with testing on real Termux App, not as a total replacement, because there are some subtle differences between Termux App and termux-docker that take some time to be completely familiar with)

[truboxl]

netstandard-targeting-pack-2.1-10.0 should be removed and not be shipped. The virtual package to be left alone and not updated.

dotnet/sdk#50354
dotnet/source-build#5329

I expect the entire netstandard-targeting-pack* packages on Termux to be removed once dotnet8.0 EOL.

[playday3008]

@truboxl You want me to remove that for .NET 10? Or my changes should be merged and this handled separately?

[truboxl]

I prefer to do it here. Always practice shift left mentality if you get the chance to accumulate lessons learnt from all the past mistakes by others. Here in this case having to deal with leftover RC packages which we do not need to do.

[playday3008]

Ughhhh, I'm gonna experiment locally with this stuff, so I wouldn't murder the CI

[truboxl]

No point of experimenting. This is Termux fault for adding unapproved changes to docker build. Just wait until we settle internally.

[robertkirkman]

If "another build is running" error occurred, it is thought to be possibly fixed in branches that are rebased after this commit: 4fd4e48

[playday3008]

@robertkirkman You were right, just rebasing with that commit included fixed things.

@truboxl Also true, but I want to figure out building in container anyway, and I even have some questions, for example, why does run-docker.sh script runs chmod on repo, this breaks Git by doing that? Or am I doing something wrong? Also, I for example do not have a Docker, but I have Podman, but there's no script for it, would that be ok, if I make new PR with either, separate run-podman.sh script or unified run-container.sh that will autodetect if Docker or Podman is available, and will use whichever is available.

[robertkirkman]

why does run-docker.sh script runs chmod on repo, this breaks Git by doing that?

Could you provide, if you can, a script that can reproduce an error associated with the git-related problem you are encountering on a fresh computer, so that I can check if the same problem you have is reproducible on my computer or not?

Also, I for example do not have a Docker, but I have Podman, but there's no script for it, would that be ok, if I make new PR with either, separate run-podman.sh script or unified run-container.sh that will autodetect if Docker or Podman is available, and will use whichever is available.

Yes, you can make a new PR, but I recommend you do it by adding Podman support to run-docker.sh without changing the name to run-container.sh. because Podman runs images from https://hub.docker.com/, and the docker image run by run-docker.sh is https://hub.docker.com/r/termux/package-builder, and therefore in this situation the use of Podman would be considered to be as an alternative implementation of Docker

[playday3008]

Could you provide, if you can, a script that can reproduce an error associated with the git-related problem you are encountering on a fresh computer, so that I can check if the same problem you have is reproducible on my computer or not?

Uhhhh, I guess I partially messed up it myself, by doing some weird stuff, I just remember that somehow I did that using containers, forget about it, it's not reproducible

[truboxl]

Thanks! Merging now since there is no more packaging issues I can find. The rest of opened dotnet-related TODOs can be followed up later.

[TomJo2000]

This means we finally have a shot at getting PowerShell packaged.