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.
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
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
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:
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?
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.