Snapcraft 8.3.0 is now in the latest/candidate and 8.x/candidate channels.
The tentative release date to stable is 2024-07-08T05:00:00Z.
Snapcraft 8.3 brings in a variety of improvements including support for ROS 2 Jazzy, a stable core24 gnome extension that integrates with the gpu-2404 SDK, and a variety of improvements and material added to the readthedocs documentation.
@mr_cal We’ll post these announcements in Ubuntu Hideout. If you let us know when they are made, as you have done with the office hours meetings, we’ll post to the community-noticeboard.
And I have no way to override it, if I set contact in snapcraft.yaml it should take precedence. In any case we should check for validity before setting it or we risk breaking existing projects.
It’s a list now, so, it’s just added into the existing one. But, it should take up strings only. Then where is this validation coming up from? Like it was not meant to be only email addresses. It can be anything, right?
It can be a url or a valid email address, this one is masked. Either case, if defined in snapcraft.yaml we should replace instead of append or there is no easy way to get out of this.
I’d used 8.3 to go from Core22 + Gnome to Core24+Gnome. In comparison to earlier base/extension upgrades, it seemed to go smoother. (In comparison to say, Core18–> 20, or 20–>22). Maybe that’s just experience and removing cruft over time, but still.
I gave the support architecture-independent snap build support a go, and it seems to work well. Thanks for bringing this feature back!
Not sure if this counts as a bug, but I can’t omit the build-for: all property like I can for regular platform definitions. For example, this definition:
platforms:
all:
build-on: amd64
Results in this error:
Bad snapcraft.yaml content:
- error for platform entry 'all': platform entry label must correspond to a valid architecture if 'build-for' is not provided. (in field 'platforms')
If I specify build-for everything works, so this isn’t a blocker bug.
Requiring a full build-on/build-for definition for all was done on purpose. I just added support for all upstream in craft-application, so we’re starting with a strict definition and may relax it in the future.
It looks like Launchpad still has trouble building architecture independent core24 snaps with the new Snapcraft. I did a bit of analysis and filed a bug report about it here:
From the look of it, this reaches a bit beyond architecture independent snaps: it seems the code used to schedule builds has no understanding of the new platforms section, so acts as if there is no architectures specified and schedules simple same-arch builds:
