fix(common-files/building-system-patches/disable-apparmor): more aggressive method of disabling AppArmor#2395
Conversation
…essive method of disabling AppArmor - Fixes termux-user-repository#2394 for me
| [ -d "${TERMUX_STANDALONE_TOOLCHAIN}-work" ] || mkdir -p "${TERMUX_STANDALONE_TOOLCHAIN}-work" | ||
|
|
||
|
|
||
| - if ! mountpoint -q "${TERMUX_STANDALONE_TOOLCHAIN}"; then |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
Fixes [Bug]: frustrating AppArmor-related error
user builder is currently used by process 1#2394 for meRelated (though
termux-amis not in TUR, the same patch also currently allows buildingtermux-am) [Bug]:termux-amfails to build after the enablement of AppArmor termux/termux-packages#29118