Re-installing coreutils using pacman in GitHub Actions freezes the container

[theamericanaccount]

Apparently.

Started a couple days ago.

https://github.com/themartiancompany/eslint-plugin-hardhat-internal-rules-ur/actions/runs/25117649402/job/73609186276

[robertkirkman]

@theamericanaccount your link goes to a GitHub Actions workflow that is 32-bit Android and large.

large 32-bit Android GitHub Actions workflows require running the __change_container_pid_max() function before running other operations within the container.

https://github.com/termux-user-repository/tur/blob/dec25dc096db5c31b32d4bdc93355e9f36002679/common-files/build-termux-docker.sh#L25-L44

Does your large 32-bit Android GitHub Actions workflow have the __change_container_pid_max() function?

[robertkirkman]

@theamericanaccount also, there is another problem with your configuration. This might also be related to your issue.

At this line, you use the termux/termux-docker image,

https://github.com/themartiancompany/eslint-plugin-hardhat-internal-rules-ur/blob/9dcda925420b33bdf7fb421eaf90eab22cf2e545/.github/workflows/release-build.yml#L90

however, later on after installing some things, you begin using the pacman command to install things in this same container.

https://github.com/themartiancompany/eslint-plugin-hardhat-internal-rules-ur/blob/9dcda925420b33bdf7fb421eaf90eab22cf2e545/.github/workflows/release-build.yml#L666-L670

unfortunately, that is not correct. While I understand you are very good at using pacman, using the pacman command in termux-apt is actually not a supported configuration of Termux and it can lead to unexpected behavior, because Termux is not designed or tested to handle that.

Instead, to use pacman, I strongly recommend changing the termux/termux-docker image to the termux/termux-docker-pacman image instead in your GitHub Actions. Then, it will already have pacman properly installed, and you can greatly reduce the setup steps.

[robertkirkman]

Also, I am not saying you should not be able to reinstall or upgrade coreutils, but could you just explain why do you need to reinstall coreutils to begin with in this situation? it is already preinstalled. Especially if you use the termux/termux-docker-pacman image, the termux-pacman package of coreutils would already be preinstalled. Reinstalling coreutils should work after you apply the above fixes, but after applying the fixes, will you still even need to reinstall it like that?

[theamericanaccount]

when i started using the container there was no termux-docker-pacman available as far as i remember

its possible to have the pacman environment working on top of the debian one just by configuring pacman and overwriting the packages in most situations
it worked flawlessly until very recently
maybe its the missing switch youve mentioned

its needed also on certain recent android devices in which the standard termux-pacman-setup procedure seems not to work

in this context coreutils is just an explicit makedepends for many packages so it gets pulled by the fur when installing the makedepends to build the package but really at other places before too

[theamericanaccount]

sure right now those ci scripts should be reduced in size and steps
im holding onto those versions just up until the evmfs builds in the ci i guess, then it will just be install the gur the fur ur and then using that to handle build and runtime dependencies installations directly

right now im building coreutils so i dont have to add the -d skip depends option and handle makedepends manually
probably the fastest way is just to switch to the pacman container but i have to make undeletable coreutils source code anyway so either its now or later so im doing it now
ive almost finished making undeletable gcc source code up to version 3.4

[robertkirkman]

when i started using the container there was no termux-docker-pacman available as far as i remember

yes I created it on the 5th August 2025 and it was merged into the official version on 10th April 2026

it worked flawlessly until very recently
maybe its the missing switch youve mentioned

yes I recommend use that and also if you're not currently using it, not using it guarantees that the 32-bit containers will crash at some point if the container runs enough commands no matter what else you do and it will seem random. therefore it could have worked just by chance for you until one day it just stopped.

you should just need to replace the variables and commands in the function with any differences that match your repository GitHub Actions instead of the TUR GitHub Actions and then it will work in your repository.

[robertkirkman]

For your repository, since it uses Docker by the container: directive rather than the docker command like TUR, which is fine, I think the code which applies it for you could be like this:

/entrypoint_root.sh sh -c "echo 65535 | tee /proc/sys/kernel/pid_max"
if [[ "$(cat /proc/sys/kernel/pid_max)" -eq 65535 ]]; then
    echo "Successfully changed /proc/sys/kernel/pid_max for container namespace"
else
    echo "Failed to change /proc/sys/kernel/pid_max for container namespace"
fi

if you try that and it says "Failed to change /proc/sys/kernel/pid_max for container namespace" let me know.

[theamericanaccount]

seems a latest round of changes to the container broke also termux-fix-shebang itself?
also your workaround with login from the other issue doesnt work

i think maybe more people should review your changes before they get merged if there were as in this case hundreds of packages depending on the container and you dont check

im okay forking the container but how are you really a maintainer if you break working stuff
it doesnt seem to me your latest changes have produced a better workflow up so far and youve made me waste weeks of work
its not like its not public
you just broke stuff without caring
thats not good maintainership for me

[theamericanaccount]

still very hard not interpreting you as hostile @robertkirkman and i honestly doubt your good faith and your interest in not just producing issues

[robertkirkman]

seems a latest round of changes to the container broke also termux-fix-shebang itself?

could you describe what happened?

also your workaround with login from the other issue doesnt work

I think that probably you just haven't applied it appropriately yet. Did you apply everything I told you to?

i think maybe more people should review your changes before they get merged if there were as in this case hundreds of packages depending on the container and you dont check

actually, many people tested the changes before they were merged and had no issues, so I think the issue is with the way you configured the container. The only breaking change is the removal of the /usr symbolic link, which you can resolve using the change I explained.

[theamericanaccount]

bah, feels like a mock
ill see to fork the container and revert back your changes
seems we cant have nice things uh

[robertkirkman]

You still haven't applied the changes I told you to in your other repository, regarding adding login:

https://github.com/themartiancompany/gnupg-ur/blob/main/.github/workflows/release-build.yml

feel free to fork the image if you need the old behavior of /usr symbolic link for legacy code.

[robertkirkman]

@theamericanaccount There's an already available fork of the image, if you want, that I believe still retains the old behavior:

Note

EDIT: the image below has none of my changes to termux-docker so it still has the symbolic link /usr, but despite that it is also currently affected by the pacman coreutils problem, because the pacman coreutils problem is because of something else.

https://github.com/termux-user-repository/termux-docker/pkgs/container/termux-docker-android-7

docker run -it ghcr.io/termux-user-repository/termux-docker-android-7:aarch64

if you prefer that behavior, I think you can get it from that one. Also feel free to let others who you see encountering problems with the /usr symbolic link that they can try that one if they prefer to continue using the old behavior.

[theamericanaccount]

why should i have changed it, i made that package work already without your suggestions
now there are more issues deriving from another unreviewed change and here i am testing the "fix"

breaking hundreds of packages without caring and then "feel free to fork the old package"
definitely not hostile behavior

[robertkirkman]

now there are more issues deriving from another unreviewed change and here i am testing the "fix"

there is no unreviewed change regarding the problem involving pid_max. It has been documented in the README since 2022 and I have nothing to do with causing it. Did you notice it there?