If I attempt to build my snap using snapcraft cleanbuild it appears to be done as root.
If I set SNAPCRAFT_BUILD_ENVIRONMENT=lxd to get a reusable container, the snapcraft (2.42.1) build fails almost immediately because the autotools plugin does not have the permissions necessary to run ./configure… suggesting another user is used. What is the correct way to use this feature?
Please paste the output you receive when you try to run with SNAPCRAFT_BUILD_ENVIRONMENT set to lxd. Both cleanbuild and persistent containers run inside the container as that container’s root user, so the error is likely due to something else in your environment or build.
I am trying to build a library (using the autotools plugin) that will be linked in my app (built after:, using the make plugin).
With snapcraft cleanbuild --debug configure and build succeeds in an ephemeral container, and I can see the library artifacts in a /usr/lib subtree of the staging tree (although I haven’t gotten the app to find them yet).
With SNAPCRAFT_BUILD_ENVIRONMENT=lxd running snapcraft fails with a permissions error at the library’s configure stage with:
Skipping pull fftw (already ran)
'ka9q-sdr' has prerequisites that need to be staged: fftw
Preparing to build fftw
Building fftw
./configure --prefix= --prefix=/usr --enable-single --enable-threads --enable-sse --enable-avx --enable-shared
/bin/sh: 21: exec: ./configure: Permission denied
Failed to run './configure --prefix= --prefix=/usr --enable-single --enable-threads --enable-sse --enable-avx --enable-shared' for 'fftw': Exited with code 126.
Verify that the part is using the correct parameters and try again.
Stopping local:snapcraft-ka9q-sdr
(This happens with or without the --prefix=/usr as one of the configflags, which was an attempt after failing with install-via: prefix method.)
Full output https://gist.github.com/jimt/2ed9c37a3195175f97e42ef367c57b72
snapcraft.yaml https://gist.github.com/jimt/943fd5c0bc053f805152a50d0e0ff897
Your pulled source is possibly in an inconsistent state: Run snapcraft clean fftw -s pull and try again. The permission problem does not present itself to me when I build your project with SNAPCRAFT_BUILD_ENVIRONMENT=lxd.
Thanks for the suggestion, but snapcraft clean fftw -s pull doesn’t appear to make a difference:
I /u/l/s/a/k/snap snapcraft clean fftw -s pull
Skipping cleaning priming area for ka9q-sdr (already clean)
Skipping cleaning staging area for ka9q-sdr (already clean)
Skipping cleaning build for ka9q-sdr (already clean)
Skipping cleaning pulled source for ka9q-sdr (already clean)
Skipping cleaning priming area for fftw (already clean)
Skipping cleaning staging area for fftw (already clean)
Skipping cleaning build for fftw (already clean)
Cleaning pulled source for fftw
Cleaning up priming area
Cleaning up staging area
Cleaning up parts directory
I /u/l/s/a/k/snap snapcraft
Device /root/build_ka9q-sdr removed from snapcraft-ka9q-sdr
Waiting for a network connection...
Network connection established
error: no changes of type "auto-refresh" found
Mounting /usr/local/src/amsat/ka9q-snap/snap into container
Device /root/build_ka9q-sdr added to snapcraft-ka9q-sdr
Preparing to pull fftw
Pulling fftw
Downloading 'fftw-3.3.8.tar.gz'[==================================================================] 100%
'ka9q-sdr' has prerequisites that need to be staged: fftw
Preparing to build fftw
Building fftw
./configure --prefix=/root/build_ka9q-sdr/parts/fftw/install --enable-single --enable-threads --enable-sse --enable-avx --enable-shared
/bin/sh: 21: exec: ./configure: Permission denied
Failed to run './configure --prefix=/root/build_ka9q-sdr/parts/fftw/install --enable-single --enable-threads --enable-sse --enable-avx --enable-shared' for 'fftw': Exited with code 126.
Verify that the part is using the correct parameters and try again.
Stopping local:snapcraft-ka9q-sdrI am just guessing… but I wonder if it has to do with the /etc/subuid and /etc/subgid mappings. The first time I ran with SNAPCRAFT_BUILD_ENVIRONMENT=1 snapcraft told me to add root:1000:1 to each file without deleting any other lines (which already contained other root and lxd mappings). I did, and restarted lxd, but wound up with the problem that started this thread. I am just suspicious that the difference between this method and cleanbuild has something to do with the mapping from my host into the container leading to permissions problems.
I would suggest dropping all other entries.