Call for testing: Snapcraft 8.0.0

We are pleased to announce the availability of Snapcraft 8.0.0.

It is currently on the 8.x/candidate and latest/candidate channels to try out. The working release notes can be found at

If no major regression is reported, this release will be moved to stable on 2024-01-02T03:00:00Z


Just to let you know that we have tested snapcraft 8 on our projects directly into CI

Our ROS snap examples CI ran with snapcraft 8 (apart from the core18 ones) and the new feature of ROS snaps using content sharing was also tested successfully with snapcraft 8 and on the TurtleBot3 snaps CI.

1 Like

Additionally, we have tested the Gazebo robotics simulator that was also successful.

1 Like

So far so good with snapcraft 8.0.0 on my end. I have been using the updated remote-build command to enable riscv64 builds for my snaps. remote-build works well for multiarch builds and builds targeted towards riscv64.

Only challenge currently is that the riscv64 builders provided by Launchpad are massively slower than the builders for amd64, arm64, s390x, and ppc64el. It takes 3-5x longer to build a riscv64 snap than the other architecture sets. For example, my Spack snap takes about 10 minutes to build from scratch on amd64, but the same build on riscv64 takes 50 minutes to 1.5 hours. Not sure if this is just a performance limitation due to riscv64 being emulated with qemu or another configuration in the remote builder backend. However, I’m happy that I no longer need to use my own local infrastructure :tada:


Yes, the riscv64 issue is a know one and it also affects deb building. Time will fix this (I hope) :slight_smile:

A slight regression when using remote-build was found and the fix landed while we were in downtime, so I am pushing the release date to 2024-01-04T03:00:00Z

8.0.1 is now on the candidate channel with the fixes specified in

8.0.1 has now released to stable

1 Like

I use core18, so I’m getting the following error on Launchpad now that Snapcraft 8 is released:

'core18' is not supported on this version of Snapcraft.
Recommended resolution: Install from or refresh to the '7.x' channel.

I can’t figure out how to tell Launchpad to use the 7.x/stable Snapcraft channel. There’s a place to specify the channel for automatic builds, but I rebuild manually when the upstream repository changes. Can anyone point me to some documentation? One of the Snap packages having trouble is linked below:

Never mind. It’s right there in the dialog I ignore when I click the “Request builds” link! Building with the older Snapcraft now …

In Snapcraft 7, I was used to using Launchpad Remote Builds like so:

snapcraft remote-build --build-for=arm64,amd64

with Snapcraft 8, the comma seems to be treated as part of the architecture itself, making the service try to build for an architecture literally called "arm64,amd64" which it fails to do because it doesn’t exist.

The fix is quite simple, and is just snapcraft --build-for arm64 amd64 - but I feel like this is the kind of thing that looks more like a bug than an actual feature since it changes parameter handling for presumably little gain.

Is it intentional that the =a,b,c syntax has stopped working?

No, I don’t believe this was intentional. Thanks for the report, I’ve created a bug here.

Is there some reason --shell-after behaviour has changed? (or is this related to the above?)

Previously I’d run snapcraft --use-lxd --shell-after to dump me inside the container when I want to poke about. Now it doesn’t stop inside the container. I have to explicitly put some interim stage like snapcraft build --use-lxd --shell-after to get it to stop part way through.

This still bites me regularly. Why can’t I use --shell-after without specifying a stage in the lifecycle?