Call for testing: Snapcraft 7.1.0

Snapcraft 7.1.0 has been released and is currently on the 7.x/candidate channel. Some worthy features to mention are:

  • A new gnome extension when using core22 which uses GNOME 42 by default.
  • A ros2-humble extension when using core22
  • Architectures support for core22

The full set of changes can be found on

This release will be tentatively promoted to the 7.x/stable channel on 2022-08-03T03:00:00Z if not issues are found during the testing period. The team appreciates your involvement.


Been experimenting with this release and I have encountered some issues with the meson plugin when trying to snap GNOME applications. It looks like meson is not being installed in the build environment which is causing the parts that use the meson plugin to fail.

I opened a bug report on Launchpad that contains more information + relevant log files:

I was excited to try the architectures support to cross-compile a snap for arm64 and armhf. So I added:

  - build-on: amd64
    build-for: amd64
  - build-on: [amd64, arm64]
    build-for: arm64
  - build-on: [amd64, armhf]
    build-for: armhf

After running snapcraft on my amd64 machine, the amd64 snap is built correctly, but the arm64 build fails with the error Stage package not found in part ‘theengs-gateway’: bluez.

Previously (with Snapcraft 7.0) I built the arm64 snap on a jammy LXC container on an arm64 machine, and the armhf snap on an a jammy LXC container on an armhf machine, and this just worked: the stage package bluez was found and the resulting snaps installed and ran fine locally. Building the arm64 snap on arm64 or the armhf snap on armhf with Snapcraft 7.1 also works, and the resulting snaps install and run fine too. So it seems something is going wrong with stage packages while cross-compiling.

Here’s the project:

Here’s the pull request where I try to use the architectures support:

You can see the full logs in the artifacts of one of the runs on Github Actions:

I opened a bug report on

Is it possible to coerce launchpad to allow remote-build to use core22 and thus gnome extension?

$ snapcraft version
snapcraft 7.1.0                      
$ snapcraft list-extensions | grep core22
gnome             core22
ros2-humble       core22
$ snapcraft remote-build
snapcraft remote-build is experimental and is subject to change - use with caution.
Issues while validating snapcraft.yaml: The 'apps/spot/extensions[0]' property does not match the required schema: 'gnome' is not one of ['flutter-stable', 'flutter-beta', 'flutter-dev', 'flutter-master', 'gnome-3-28', 'gnome-3-34', 'gnome-3-38', 'kde-neon', 'ros1-noetic', 'ros2-foxy']

Using remote-build because for some reason lxd locally is using IPV6 and failing and I don’t have the time or inclination to debug it, so thought I could test remotely instead.

@koenvervloesem, nice find and thanks for filing a launchpad bug!

I’m seeing the same failure.

  • When building on amd64 with core20, snapcraft will download bluez from the amd64 repository.
  • When building on amd64 with core22, snapcraft attempts to download bluez from the arm64 repository, then fails because the arm64 repository was never added.

I’ll follow up more in launchpad.

We have just released 7.1.1 to the same channel with the following changes:

For which we will be delaying the migration to stable to late tomorrow

Will this be going to latest/stable in addition to 7.x/stable when you push the button? That will be most helpful as I need the gnome extension to be available via the build service for some of my snaps now (remote build doesn’t work as @popey pointed out)

yes it will, more rapidly with positive feedback :slight_smile:

1 Like

Well for positive feedback - I’ve used it successfully over the past few days to port several snaps over to core22 and the gnome extension now… No issues to be seen from my end so far…

1 Like

ooh, this one is a good one that should eliminate the need for one of my hacks:

1 Like

Related to the fix above, is there any functionality similar to this hack of mine for ensuring that root-anchored symlinks are rewritten to be relative (so that they point to the file within the snap filesystem rather than the root/base-snap filesystem)?

edit: yes it seems like you have fixed that too :slight_smile:

Tested the colcon plugin at 7.1.1 and it works well.


7.1.1 is now on 7.x/stable and latest/stable


Seems amazing info which we been looking for !

That’s coming very soon, right? How long is the usual propagation time between the stable release and its adoption for the launchpad builders?

As soon as it is in stable. I believe what Alan alludes to is being able to test the in-flight version of Snapcraft using remote-build through launchpad builders

1 Like