Releases: canonical/snapcraft
Announcing snapcraft 2.42
Hello snapcrafters! The snapcraft team is pleased to announce that version 2.42 of snapcraft.
Contributions
This release saw some excellent contributions from outside the snapcraft core team, and we want to give a shout out to those folks. A team thank you to:
New in this release
Core
multipass cleanbuild support
If you are a user of snapcraft cleanbuild and have multipass installed (snap install multipass --beta at the time of this writing) then you might be interested in trying out this new feature, currently triggered by a
feature flag. Try it out by running:
$ SNAPCRAFT_BUILD_ENVIRONMENT=multipass snapcraft cleanbuild
sunset remote persistent containers
The feature, hidden behind a feature flag of enabling a remote lxd instance to drive the build with local
mounts in place has been removed as a feature due to complexities and trimming of scope towards a
unified, working and sustainable interface. Given this was a feature flag and never left its experimental
stages, removing it was the right thing to do to remove any expectation that this will be driven further or
have user go through a bad experience when using it.
This does not affect using local persistent LXD containers, nor does it affect remote cleanbuilds.
Error reporting
When enabling the snapcraft CLI's use of Sentry by means of setting the feature flag to SNAPCRAFT_ENABLE_SENTRY=on (perhaps in your ~/.bashrc) you will now have the option to
always send the traceback instead of being prompted.
architectures keyword
Previous releases of the snapcraft CLI supported an architectures keyword that one could use to specify the architectures on which the snap runs. However, for multiple reasons this proved to be a confusing feature that few could use successfully, so this release sees it reworked to better match user expectations. The architectures keyword has been restructured into a list of more explicit objects, specifying both build and run architecture(s):
architectures:
- build-on: [<build arch 1>, <build arch 2>]
run-on: [<run arch 1>, <run arch 2>]If snapcraft is building on an architecture in build-on, it will use the corresponding run-on in the final snap, stating that it runs on those architectures. Please read the documentation for more details.
Plugins
dotnet
When using override-build, the dotnet plugin can now be used to override the plugin logic.
Full list of changes
Here's the full list of changes that built up to this release:
- elf: patch everything instead of a subset of elf files (#2081)
- elf: clear the current runpath before setting the rpath (#2085)
- python plugin: properly handle distutils on bionic
- ci: add the python integration tests on bionic for travis
- many: remove support for remote lxd per project containers (#2089)
- schema: allow refresh-mode and stop-mode (#2092)
- packaging: include changelog for setup.py's version detection (#2097)
- ci: enable OSX testing on travis (#2084)
- tests: use a common cache for the integration tests
- tests: remove the SharedCache fixture and uses of it
- many: allow building in containers with no version in project (#2104)
- errors: remove logic for SNAPCRAFT_SEND_ERROR_DATA
- errors: implement the always option to sent to sentry
- package: make use of snapcraftctl snapcraft features (#2103)
- nodejs plugin: lazy load the required tarballs (#2106)
- build_providers: new build provider using multipass (#2100)
- tests: use FakeSnapd for grammar tests
- tests: adapt the integration suite to work for all releases
- project_loader: support architectures for CI (#2080)
- meta: soften warning about using passthrough (#2091)
- storeapi: better handle network errors and retries (#2094)
- grammar: support compound on..to statement (#2088)
- tests: fix arch-specific integration tests
- python: bring back support for older versions of pip (#2055)
- tests: don't use os_release and repo from snapcraft (#2096)
- lxd: wait for on-going refreshes to finish (#2098)
- ci: setup AppVeyor (#2087)
- repo: catch error updating the package cache (#2079)
- tests: do not shadow deb_arch in architecture scenarios
- tests: parser tests need the cache
- tests: don't hard-code expected arch in VersionScriptTestCase
- dotnet plugin: add dotnet command to path for step overriding (#1909)
- lifecycle: skip -all-root for base snaps (#2090)
- tests: update metadata store integration test, no previous push
required (#2086)
Final notes
To get the source for this release, check it out on github. For the full extent of changes, take a glance at https://github.com/snapcore/snapcraft/milestone/21?closed=1
A great place to collaborate and discuss features, bugs and ideas on snapcraft are the forums. Please also feel free to file a bug.
Happy snapcrafting!
-- Sergio and the team
Announcing snapcraft 2.41
Hello snapcrafters! The snapcraft team is pleased to announce that version 2.41 of snapcraft.
Contributions
This release saw some excellent contributions from outside the snapcraft core team, and we want to give a shout out to those folks. A team thank you to:
New in this release
Core
Information extraction: setup.py
New in this release, snapcraft has added logic for information extraction from setup.py.
Currently only version and description are retrieved from setup.py.
Check the documentation for further use of the feature.
Improved mechanism for overriding lifecycle steps
The feature carrying the name of scriplets has been vastly improved with common understandable logic. To override a step in the lifecycle the semantics are as simple as override-<step>, to call the original logic for the step (useful when wanting to perform operations prior or after the step), one just needs to run within the script snapcraftctl <step>
Furthermore, it is now possible to programatically set the version and grade from within these overriden steps, using whatever logic pertinent or artifact available in that step by eventually calling snapcraftctl set-version <version> and snapcraftctl set-grade <grade>.
Read more about this feature on the documentation site.
passthrough property
Occasionally snapd adds a new experimental feature that may or may not make it to a stable release. In order to support such features as soon as they're added, this release sees the addition of a passthrough keyword that one can use in the root of the YAML as well as in apps and hooks, which can contain properties that are simply passed through to the final snap.yaml.
Error reporting
This release sees the integration of Snapcraft with Sentry. This is still in the testing phases and nothing is enabled by default, but if you would like to enable it and optionally send us any terrible tracebacks you see, simply set SNAPCRAFT_ENABLE_SENTRY=on (perhaps in your ~/.bashrc) and you will be prompted if such an error occurs. Note that no personally identifiable information is sent: just the traceback (which may include the project name).
Plugins
dotnet
Upstream's release information is now used to determine the correct dotnet artifacts to use depending on the target defined in the project.
nodejs
It is now possible to pass an npm-flags list of arguments when using the nodejs plugin.
python
For users experimenting on bionic, snapcraft has caught up with the latest changes to this date occurring there.
Final notes
To get the source for this release, check it out on github. For the full extent of changes, take a glance at https://github.com/snapcore/snapcraft/milestone/18?closed=1
A great place to collaborate and discuss features, bugs and ideas on snapcraft are the forums. Please also feel free to file a bug.
Happy snapcrafting!
-- Sergio and the team
Announcing snapcraft 2.40
Hello snapcrafters! The snapcraft team is pleased to announce that version 2.40 of snapcraft.
Contributions
This release saw some excellent contributions from outside the snapcraft core team, and we want to give a shout out to those folks. A team thank you to:
New in this release
Core
Base support
Initial support for bases has been added. To use this feature for example targeting the new-to-be core18 base snap, Just add this entry to your snapcraft.yaml:
base: core18You should ideally be running snapcraft from 18.04 to test this feature. Keep in mind that there is still no transparent cleanbuild or project container support for this, it was quickly enabled to get the feature rolling end to end for eager developers wanting to target this new core base.
Improved elf mangling
This functionality is triggered when the build environment is newer than a given base (experimental) or when confinement is set to classic. Most of the improvements are related to the underpinnings of snapcraft to make this a joyful and unsurprising experience as a developer.
This version introduces better detection of DT_NEEDED and snapcraft's lifecycle execution for their discovery. It is now also optimized to only handle these scenarios when creating a snap of type app (the implicit default). There's proper architecture detection of elf files and error handling of non-elf files. The list of RPATH has improved so elf files make use of $ORIGIN for easier relocation (a rather important feature when creating snaps). The extraction of the correct linker has also been optimized.
patchelf has also been SRUed into 16.04 LTS to enable the full extent of architectures out of the box.
execstack
Many binaries that made their way into a snap from pre-built binaries have been making their way in with the execstack bit set on binaries, which caused unexpected behaviors. Given that execstack is not a common thing binaries would need enabled, snapcraft now strips the execstack bit from binaries after going through the files in prime.
This feature can be disabled per part, as the warning for when it happens mentions, by setting:
parts:
part-name:
build-attributes: [keep-execstack]appstream
Better appstream integration, now by making use of common-id under an apps entry, if the information is extracted using the information extraction feature introduced in 2.39, the desktop file and icon is provisioned automatically.
This common-id is also indexed by the Snap Store for proper deduplication of apps on store fronts. Read more about the feature on the new docs site
Plugins
catkin
ROS Kinetic recently released an update that caused Kinetic-based snaps to start failing due to a hard-coded path to Python. This release sees that fixed by the Catkin plugin dynamically rewriting these files to use Python from the PATH instead.
This release also sees the addition of support for recursive rosinstall files. If you have a rosinstall file that resolves to another repository with rosinstall files you also would like to satisfy, simply set recursive-rosinstall: true and Catkin will recursively handle rosinstall files until it has handled them all.
CLI
version
You can now run snapcraft version just as well as snapcraft --version
bash completion
The bash completion script snapcraft has provided has been hooked up to work with the snap.
Final notes
To get the source for this release, check it out on github. For the full extent of changes, take a glance at https://github.com/snapcore/snapcraft/milestone/16?closed=1
A great place to collaborate and discuss features, bugs and ideas on snapcraft are the forums. Please also feel free to file a bug.
Happy snapcrafting!
-- Sergio and the team
Snapcraft 2.39 has been released
Hello snapcrafters! The snapcraft team is pleased to announce that version 2.39 has been released.
Contributions
This release saw some excellent contributions from outside the snapcraft core team, and we want to give a shout out to those folks. A team thank you to:
- Paolo Pisati
- Alberto Donato
- Herman Yanush
- Konrad Krawiec
- Marcin Mikołajczak
- Alan Pope
- Daniel Lim Wee Soong
- Chris Glass
- Jonathan Cave
Availability
This new version of snapcraft is now available in the following ways:
- From the SnapStore,
snap install snapcraft(from thestablechannel) - On a Mac with Homebrew,
brew install snapcraft - With docker,
docker pull snapcore/snapcraft:stable
New in this release
Core
Improved support for classic confinement
We have solidified and unified the experience for classic confined snaps. Creating snaps on 16.04 targeting that same base will now make the necessary arrangements so that runnables and libraries target the correct linker and have the right paths regardless of how the snapcraft project is assembled (source or pre-built binaries).
Experimental support for building on newer stacks
When building on a newer stacks than the base that is being targeted, there is possibility of incompatibilities at the ABI level of the libraries involved, one of those that is noticeable is libc6. To sort through this, when building on newer stacks where this incompatibility may occur an error is issued to prevent the same failure at runtime; with this error, instructions on how to move forward are provided for those wishing to embark in such task.
New "to" keyword in grammar
The grammar which can be used to conditionalize build-packages and stage-packages has grown a new statement. The new "to" statement, analoguous to the existing "on" statement, only evaluates the given packages depending on the target architecture.
For example:
build-packages:
- to armhf:
- foo
- barIn this case, package foo will only be installed when building the snap targeting the armhf architecture. However, package bar is always installed. Furthermore, any package in a to statement will be installed for the target architecture rather than the host version.
In this example, foo has an implicit architecture specific tag matching what is in to, which would make it the same in the example shown to write foo:armhf.
Information extraction
Snapcraft 2.38 added support to extract basic metadata info from appstream files, such as summary and description and making them available in the resulting snap.yaml, allowing to reduce the entry point for specific application information to central point. On this release we have extended that to also extract the icon and desktop files declared in the appstream metainfo.xml file.
CLI
Specify expiration date for exported login
Snapcraft v2.37 gained the ability to export a login that could be used in CI. However, it only supported the default lifespan of one year. This release sees the addition of the ability to specify a shorter lifespan with the --expires option.
Default locale
Snapcraft requires a UTF locale to be set, given that most CI systems have the C locale setup by default, snapcraft now sets a default locale of C.UTF-8 as a fallback locale.
Plugins
kbuild
If, when cross-compiling a kernel, one set the ARCH variable and not the CROSS_COMPILE variable, the kbuild plugin would incorrectly proceed with an empty CROSS_COMPILE variable set, which resulted in a failed build. This release sees the kbuild plugin only use the CROSS_COMPILE variable if it's actually set.
Final notes
To get the source for this release, check it out on github.
A great place to collaborate and discuss features, bugs and ideas on snapcraft are the forums. Please also feel free to file a bug.
Happy snapcrafting!
-- Sergio and the team
snapcraft 2.38 has been released
Hello snapcrafters! The snapcraft team is pleased to announce that version 2.38 has been released.
Contributions
This release saw some excellent contributions from outside the snapcraft core team, and we want to give a shout out to those folks. A team thank you to:
The last three contributors have done so as part of Google's CodeIn initiative.
New in this release
Core
Improved support for classic snaps
snapcraft now has a better architecture overall to handle classic snaps, not
only for those coming from parts that are built, but also for the case where
prebuilt binaries are dumped into the snap. Prior to this version of
snapcraft, true isolation for a dynamically linked executable from the host
was not possible.
The work here makes sure that the correct interpreter is set and also sets
up valid rpaths for the binary. Determining these rpaths is done by crawling
the prime directory and the selected base (currently only what today is known
as the core snap). For the base, absolute rpaths are set, while paths found
inside the primed directory make use of $ORIGIN.
Sunsetting host crawling
A feature which was useful at the time of its introduction in the past, where
libraries from the host are fetched to satisfy a dependency for a binary that
was primed, is going to be removed in a future release of snapcraft given that
it was deemed confusing and counter intuitive. A warning will be shown to users
when this feature comes into action and how to solve it and move forward.
Advanced grammar for strings
Snapcraft has long-supported a more advanced grammar when it came to build- and stage-packages that allowed one to select a different set of packages depending on build architecture. This release sees the addition of the grammar to the source keyword, allowing one to specify a different source depending on build architecture. Here's a quick demo:
Information extraction: Appstream support
This release sees the addition of the capability to extract appstream metadata (currently only summary and description) from individual parts, and use that data to help fill in the snapcraft.yaml. Here's a quick demo of that in action:
Final notes
To get the source for this release, check it out on github.
A great place to collaborate and discuss features, bugs and ideas on snapcraft are the forums. Please also feel free to file a bug.
Happy snapcrafting!
-- Sergio and the team
snapcraft 2.37 has been released
Hello snapcrafters! The snapcraft team is pleased to announce that version 2.37 has been released.
Contributions
This release saw some excellent contributions from outside the snapcraft core team, and we want to give a shout out to those folks. A team thank you to:
The last three contributors have done so as part of Google's CodeIn initiative.
New in this release
CLI
help command
As a user experience improvement, the snapcraft help command now produces the
same output as when running snapcraft --help. Viewing help information
related to plugins and other topics previously supported by snapcraft help is
still supported.
export-login command
Until now, the only support Snapcraft had baked in for CI systems was the enable-ci command, which only supported Travis, and only supported pushing a given snap to edge. This release sees the addition of a new export-login command that exports a login with the exact capabilities requested, which opens the door to many more possibilities in CI. Want to create a login that can only push a specific snap to edge? No problem. Want to create a login that can only migrate a specific snap from edge to beta? No problem. Here's how it works:
Error messages
Another improvement that was developed together with the design team is that now
most (if not all) errors have a very well defined semantic explaining first
what went wrong followed by a suggestion on how to fix it.
Store
The API to synchronize changes made to the metadata in the snap related to the
presentation layer of the store has been extended to support binary assets. So
far, icons are the only entry supported. Once a definition is made on other
potential assets such as screenshots are made, support for them will be added
as well.
To synchronize the data to the store, you need to run the command that was
introduced in version 2.34 of snapcraft:
snapcraft push-metadata
Plugins
catkin-tools
This release sees the addition of the catkin-tools plugin. This plugin works similarly to the Catkin plugin, but instead of using Catkin, uses the newer (and faster) Catkin Tools. Catkin Tools is still under beta, as is this plugin, but please give it some mileage!
Final notes
To get the source for this release, check it out on github.
A great place to collaborate and discuss features, bugs and ideas on snapcraft are the forums. Please also feel free to file a bug.
Happy snapcrafting!
-- Sergio and the team
snapcraft 2.36 has been released
Hello snapcrafters,
The team is pleased to announce release 2.36 of snapcraft
Contributions
This release saw some excellent contributions from outside the snapcraft core team, and we want to give a shout out to those folks. A team thank you to:
New in this release
Core
snapcraft.yaml
It was discovered that the snap of Snapcraft v2.35 (currently in stable) doesn't work on i386 due to an inability to find libsodium. That's fixed in this release; you should be able to use Snapcraft v2.36 on i386 with no issues.
Plugins
catkin
Prior to this release, in order to use the Catkin plugin, one needed to specify each package in the workspace that was to be built and installed into the snap. We received feedback that this was, of course, annoying for large workspaces, especially because the entire workspace was typically desired anyway. A new feature has been added to this release, where if you simply don't specify the catkin-packages property, the Catkin plugin will assume you want to build the entire workspace.
ament
ROS1 has been supported pretty much from the beginning via the Catkin plugin, but this release sees the addition of an Ament plugin for supporting ROS2 (which has reached beta3). It fetches the ROS2 underlay and bootstraps it before building the overlay, so it does take a while. Give it some exercise! Here's an example of building a simple talker/listener workspace:
Final notes
To get the source for this release, check it out on github.
A great place to collaborate and discuss features, bugs and ideas on snapcraft is the forum. Please also feel free to file a bug.
Happy snapcrafting!
-- Sergio and the team
Plugins
snapcraft 2.35 is here
Hello snapcrafters! The snapcraft team is pleased to announce that version 2.35 has been released.
Contributions
This release saw some excellent contributions from outside the snapcraft core team, and we want to give a shout out to those folks. A team thank you to:
- Mark Lee
- Michael Vogt
- James Beedy
- Aleix Pol
- Jeff Dickey
- Nathan Haines
- Chris Ratliff
- Marius Gripsgard
- Rakesh Singh
- Martin Wimpress
- Colin Watson
- Paolo Pisati
- Jonathan Cave
- Carlo Lobrano
- Alfonso Sanchez Beato
New in this release
Core
Containers
Each build instance created now correctly works out isolated temporary folder locations for those users running many builds in parallel. There is also better detection of existing or missing lxd installations so first time users can better understand any problems with the host they are currently trying to use.
When running snapcraft from the snap, snapcraft now injects itself into the actual snap instead of apt installing the deb (for the case of today of only supporting one base), providing parity with the local environment at hand.
Work has been added to get rid of all the corner cases and provide useful feedback to users and making the experience feel more native.
Additionally, support has been added for using remote lxd instances.
To enable the persistent build containers feature the SNAPCRAFT_CONTAINER_BUILDS environment variable needs to be set.
Here's an example of using a remote lxd instance:
Recording
On this new version we added more information to the build manifest, like the contents of lock files, the debs and snaps installed in the machine, information from uname and the fingerprint of the container used for the build. To record the build manifest, set the environment variable SNAPCRAFT_BUILD_INFO. The manifest will be saved and distributed inside the snap. After the build, you can inspect it in the prime/snap/manifest.yaml.
Command Line Interface
new command: pack
This new pack command replaces the now deprecated use of snap <snap-dir> with the goal of decoupling the concept of working on an actual snapcraft project and packing up a directory layout into a snap.
new command: refresh
This command is only available when persistent build containers are enabled and exists to make the environment feel as native as possible. Prior to the existence of this command, building continuously in a container triggered a refresh of the packaging archive every time, now this refresh only takes place on container creation or when called through snapcraft refresh.
new command: edit-collaborators
This command will eventually replace the use of the store invites mechanism to setup other people as collaborators to the project. It is currently hidden as the production snap store has it currently disabled. A future release once things have stabilized will expose the command to users. It is harmless to use today as a proper error will show up.
In the meantime, here is how it works when using the integration store:
OS Support
Solus
Initial support for running the snapcraft snap on solus has been added. It should work well enough for things like performing store operations, packing up snaps; or if lxd is installed and setup, most operations should work through use of persistent build containers or cleanbuild.
We look forward to knowing how this initial experience performs.
Ubuntu 14.04
Snapcraft currently only really runs well on Ubuntu 16.04, but we're working on adding support for other releases and Linux distributions. This is the first release where you can use the Snapcraft snap on Ubuntu 14.04 (Trusty). This is particularly important for snaps based on ROS (Robot Operating System) Indigo, which targets Trusty. Here's a demo of just that:
Plugins
dotnet
This plugin developed by Rajesh, a .NET developer at Microsoft, allows you to create .NET 2.x based snaps, currently embedding the runtime with plans to enhance it to understand content snaps of .NET runtimes which could be leveraged by projects.
The syntax is pretty straightforward and builds on language understood by upstream so getting started for a current .NET developer should feel like a pleasant journey.
ruby
This release sees the addition of a Ruby plugin, written by James Beedy. It supports a number of different Ruby versions by building them from source, which takes a little while but makes it pretty versatile. It could definitely use some exercise! Here's an example of building a snap of the Travis gem:
catkin
The Catkin plugin has long supported rosdep to resolve and fetch system dependencies (i.e. Debian packages). However, rosdep also supports resolving pip dependencies. This release adds support for those, so they don't need to specified elsewhere in the snapcraft.yaml.
Final notes
To get the source for this release, check it out on github.
A great place to collaborate and discuss features, bugs and ideas on snapcraft are the forums. Please also feel free to file a bug.
Happy snapcrafting!
-- Sergio and the team
Snapcraft 2.34 is here
Hello snapcrafters!
We are pleased to announce the release of snapcraft 2.34:
- Available on all supported Ubuntu releases (Ubuntu 16.04 LTS and 17.04), and the development release (Artful Aardvark).
- A windows MSI preview installer for snapcraft on Windows.
- brew installabled on OS X by running
brew install snapcraft(store interaction and cleanbuild are supported). - pip installable from PyPI (with caveats when setting up
aptbindings) by runningpip install snapcraft. - View the full list of merged PRs.
- Specific bug fixes can be seen on the Launchpad milestone.
Contributions
This release saw some excellent contributions from outside the snapcraft core team, and we want to give a shout out to those folks. A team thank you to:
New in this release
Core
types
A new snap type was added: base, this opens the door to start producing base snaps.
Containers
Each build instance created now correctly works out isolated temporary folder locations for those users running many builds in parallel. There is also better detection of existing or missing lxd installations so first time users can better understand any problems with the host they are currently trying to use.
When running snapcraft from the snap, snapcraft now injects itself into the actual snap instead of apt installing the deb (for the case of today of only supporting one base), providing parity with the local environment at hand.
Additionally, when cleaning projects making use of persistent project containers, snapcraft destroys the container that was assigned for this work as well.
To enable the persistent build containers feature the SNAPCRAFT_CONTAINER_BUILDS environment variable needs to be set.
build-snaps
They work in a similar fashion to build-packages, build-snaps takes leverage of snaps in the store to create your snaps. This release exposes the feature through
build-packages
While build-packages have been around for a while, it is only now that they have gained the support for advanced grammar, just as what is provided for stage-packages.
Support for grammar-powered build-packages, both at the part-level and global are here to stay.
source caching
Logic has been added to cache source entries that provide a source-checksum entry for parts, this would behave like:
Cleanup
Release detection
Snapcraft used the deprecated linux_distribution method from the platform module, it now correctly handles the host it is running on through parsing of /etc/os-release.
Tour removal
The tour has been sunset in favour of the tutorial which can be currently found here.
Errors
Many new exceptions have been created to handle the many potential errors that can occur when running snapcraft. In addition to that, proper snapcraft generated and understood errors will produce a nice user friendly error message while situations that were not thought of in the code base will provide proper tracebacks. This will provide a faster turnaround time for fixes and a more apparent situation of wrongness to the users of snapcraft. The errors codes for these two situations are also different, being 1for the former and2` for the latter.
Plugins
nodejs
Catching up to yarn's latest developments, the snapcraft plugin now supports the latest release of yarn.
This plugin has also gained recording capabilities by means of running snapcraft with the environment variable SNAPCRAFT_BUILD_INFO set.
jhbuild
This is a new plugin which uses jhbuild to build mostly gnome projects
python
The python plugin now records the assets it used to build, to get a glimpse of this feature you need to run snapcraft with the environment variable SNAPCRAFT_BUILD_INFO set.
catkin
Support for multiple dependency types was added. The catkin plugin now supports a new API which raises an exception if the dependency type is anything other than apt. This is paving the way for support of pip dependencies coming from rosdep.
The plugin now properly defaults to creating a release build, to enable a debug build, edit the part as follows:
kbuild
This plugin has gained the crosscompiling logic that existed for the kernel plugin, unifying the code bases more with the side effect of having cross compilation support for kbuild
Support for Makefiles without install targets is now also of declarative nature, to set it as such here is an example:
ant & gradle
Support for authenticated proxies has been added, this should be transparent to the snapcraft author through means of consumption of the already existing environment variables for proxy management (http_proxy, https_proxy, ...).
Here's an example recording:
Final notes
To get the source for this release, check it out on github.
A great place to collaborate and discuss features, bugs and ideas on snapcraft are the forums. Please also feel free to file a bug.
Happy snapcrafting!
-- Sergio and the team
Snapcraft 2.33 is here
Hello snapcrafters!
We are pleased to announce the release of snapcraft 2.33:
- Available on all supported Ubuntu releases (xenial, zesty) and the development release (zesty).
- brew installabled on OS X by running
brew install snapcraft(store interaction and cleanbuild are supported). - pip installable from PyPI (with caveats when setting up
aptbindings) by runningpip install snapcraft. - View the full list of merged PRs.
- Specific bug fixes can be seen on the Launchpad milestone.
Contributions
This release saw some excellent contributions from outside the snapcraft core team, and we want to give a shout out to those folks. A team thank you to:
New in this release
Core
Containers
The experience of using persistent build containers has become much more pleasant with this release as snapcraft now takes care of:
- containers that have no use any more such as when a project is cleaned.
- file handling an exposing to and fro the container does not leak container specific assets onto the host.
- use of
--debugandcleanbuildnow properly enters into a shell inside the container for inspection. - the
cleancommand now properly handles corner case scenarios that weren't handled before. - id mappings for the namespace are now correctly set depending on the uid of the user calling
snapcraft
Yaml Merge tags
Yaml merge tags are now supported in snapcraft.yaml, allowing for advanced use of yaml in snapcraft.yaml if needed.
Bash completion
Support for bash completion in snapcraft has arrived, it is just a matter of defining completer for your app entry under apps with a script which would deal with such completions. As an illustrative example:
apps:
my-application:
command: runme
completer: completion.shWhere completion.sh would be found under the root of prime.
For all this to work a recent version of snapd is required like 2.27.
reload-command for daemons
App entries under apps in snapcraft.yaml now support reload-command as an entry which defines how to deal with configuration reloads for daemons.
Plugins
kernel
Handling of default make targets depending on the architecture is now supported for all architectures.
nodejs
Support has been added for newer releases for nodejs/npm for special cases where in tree builds are done and npm generates a symlink farm. This should now just work with no hassle.
Cross compilation
Cross compilation support is now enabled for:
autotoolswaf
Final notes
To get the source for this release, check it out on github.
A great place to collaborate and discuss features, bugs and ideas on snapcraft are the forums and the snapcraft channel on Rocket Chat. Please also feel free to file a bug.
Happy snapcrafting!
-- Sergio and the team









