The team behind Snapcraft is please to present Snapcraft 4.0.
Among the many changes included, here is the summary of highlights:
core20 base.--use-lxd support for all the snap supported architectures.core20.This release can currently be tried out by switching to the candidate
channel for Snapcraft.
Feel free to read the full release notes over at https://github.com/snapcore/snapcraft/releases/tag/4.0
Beautiful!
I will try it ASAP (today I hope).
core20 is ready? or is in beta like snapcraft?
While trying out the package-repositories key, it seems that a necessary package is not installed, I have this:
package-repositories:
- type: apt
ppa: snappy-dev/image
and then building with lxd I see:
*EXPERIMENTAL* package-repositories in use
Failed to install GPG key: sudo: unable to resolve host snapcraft-pi: Name or service not known
sudo: setrlimit(RLIMIT_CORE): Operation not permitted
Executing: /tmp/apt-key-gpghome.zOSFF1WULV/gpg.1.sh --keyserver keyserver.ubuntu.com --recv-keys 78E1918602959B9C59103100F1831DDAFC42E99D
gpg: failed to start the dirmngr '/usr/bin/dirmngr': No such file or directory
gpg: connecting dirmngr at '/tmp/apt-key-gpghome.zOSFF1WULV/S.dirmngr' failed: No such file or directory
gpg: keyserver receive failed: No dirmngr
Recommended resolution:
Verify any configured GPG keys.
Detailed information:
GPG key ID: 78E1918602959B9C59103100F1831DDAFC42E99D
GPG key server: keyserver.ubuntu.com
If I do this with snapcraft --debug and manually run apt install dirmngr -y and re-run snapcraft then it works like a charm.
(also the sudo: setrlimit(RLIMIT_CORE): Operation not permitted is because sudo doesn’t work in a lxd container, perhaps in the lxd case don’t run commands with sudo? this message is probably harmless so not a big deal but could be a bad user experience)
Thanks for that find.
Adding to the 4.0.1 release checklist.
Hey all,
I’d also ask for testing this with Multipass from the beta channel, which is now strictly confined 
.
strictly confined? so images will be in user space?
When I upgraded to 2020 my installation went down because I had 120g of images in my / partition. Images in user space would be great!!!
Hi @alejandro.vera if you mean in your home directory, no - Multipass is a system-wide service, it’s only the client that runs in your user context.
That said, we’re planning to expose ways to change the location of our heavy storage.
Thanks… the storage is my only concern.
Speaking as a user who just recently ran their first multipass build, I was horrified by the amounts of data being pulled for what I thought should be a simple and “quick” build (it also took ages), based on my experience with older versions of snap – with no indication where that data went, and how I could clean it up. If you can improve the experience in that regard, yay!
</random feedback>
The default behavior is to use a clean environment. It is always bootstrapped for each Snapcraft project, similar using pbuilder or schroots in Debian.
If this is the part that is surprising, then you can always resort to --destructive-mode, just know that you might want to run it in an environment where packages and such might get installed (your build and runtime dependencies). Also, just like building debs, you will need to take special care of the base you are targeting and the environment you are using to build this snap.
If that last paragraph is not the concern of data please clarify in detail to address correctly (in words or reflection in code).
Hi,
I’ve been trying to build a snap that includes a couple of python parts. These parts build fine when the snap has base core or core18, but do not with base core20. The were integration tests for similar parts to this in the plugin v1 intergration tests, I believe. Current version of parts definitions:
Output of attempted build (using a focal container and destructive mode): https://pastebin.ubuntu.com/p/VG5t8WySPt/
Should these parts still work as defined?
pycache is now added by default, using multiple parts means you probably want to inhibit cache generation or filter those out with filesets and stage.
Is there / could there be a plugin-specific keyword to inhibit the cache generation and so reverting to previous behaviour? This would help when maintain snaps across a number of bases.
This time, it might work if you can run find and remove all the cache files after snapcraftctl build but you shouldn’t expect the same language as new bases are introduced, the technology stack does evolve and we try to push the needle to what is current and best behavior at the time of introducing a new base.
It seems that there is a regression with the autotools plugin, it does not recognize “configflags” section:
$ snapcraft
Failed to load plugin: properties failed to load for networkmanager: Additional properties are not allowed ('configflags' was unexpected)
This is the snapcraft.yaml that failed:
This is not a regression for core20, as stated in the release notes, this flag has been renamed for consistency for core20 plugins.
This might be related, as I’m trying to use snapcraft 4.0 with LXD to build on ARM64.
Is it expected that snapcraft cannot launch a core20-compatible container or vm for building a snap (using lxd or multipass respectively)?
$ snapcraft
Launching a VM.
launch failed: Unable to find an image matching "core20"
An error occurred with the instance when trying to launch with 'multipass': returned exit code 2.
Ensure that 'multipass' is setup correctly and try again.
edit: oh, reproducing the lxd variant to capture the log output to post here, it seems to have successfully started a container this time around…