Skip to content

fix(common-files/building-system-patches/disable-apparmor): more aggressive method of disabling AppArmor#2395

Merged
robertkirkman merged 1 commit intotermux-user-repository:masterfrom
robertkirkman:disable-apparmor-aggressively
Apr 1, 2026
Merged

fix(common-files/building-system-patches/disable-apparmor): more aggressive method of disabling AppArmor#2395
robertkirkman merged 1 commit intotermux-user-repository:masterfrom
robertkirkman:disable-apparmor-aggressively

Conversation

@robertkirkman
Copy link
Copy Markdown
Member

@robertkirkman robertkirkman commented Apr 1, 2026

[ -d "${TERMUX_STANDALONE_TOOLCHAIN}-work" ] || mkdir -p "${TERMUX_STANDALONE_TOOLCHAIN}-work"


- if ! mountpoint -q "${TERMUX_STANDALONE_TOOLCHAIN}"; then
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR ensures that TUR entirely doesn't depend on FUSE. I think a more robust approach would be to unmount the filesystem first, to check if it is currently mounted.

Currently, I use a virtual machine to build packages. There will be some problems if I attempt to build a package using TUR immediately after having previously built a package using termux-packages.

Copy link
Copy Markdown
Member Author

@robertkirkman robertkirkman Apr 1, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There will be some problems if I attempt to build a package using TUR immediately after having previously built a package using termux-packages.

Thank you for explaining that.

in my workflow, problems do not occur when I build a TUR package immediately after building a termux-packages package. That might be because of my practice of invariably using a unique CONTAINER_NAME with every different scripts folder that I manually set every time I download a new copy of the scripts folder. The reason I do that is because I consistently observed many problems occurring in the past as a result of attempting to share the same container for multiple separate scripts folders, that do not only have to do with AppArmor or fuse-overlayfs. However, I understand that not everyone finds it convenient to always use a different CONTAINER_NAME with every copy of the scripts folder.

In my opinion, this patch to disable both AppArmor and fuse-overlayfs should be a command line argument to the run-docker.sh script (and build-package.sh script) in upstream, but I'm not sure if thunder-coding would approve of that or not (because they wanted to encourage the use of both AppArmor and fuse-overlayfs in the main repository). I will try, and find out.

If this mode were a command line argument to the run-docker.sh script (and build-package.sh script) in upstream, then do you think that would solve your problem, because we could both use that command line argument while building our TUR and local packages, and then you wouldn't have a problem with building packages using TUR immediately after building packages using termux-packages, or am I not yet understanding the problem correctly?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: frustrating AppArmor-related error user builder is currently used by process 1

2 participants