An expedited release

This is an expedited release, including some features, but more importantly the necessary fix to unbreak snap builds using classic confinement that use no base. These snaps essentially target core, which is based on Ubuntu 16.04.

New in this release

stage-snaps

This feature is equivalent to the stage-packages keyword but instead of using packages from the build environment's repositories, uses snaps hosted on the Snap Store.

The semantics are the same as those available for build-snaps. When declaring a snap to be staged, the snap will be retrieved from the Snap Store and unpacked into the the snap currently being built. The meta and snap directories from the snap will be available as meta.<snap-name> and snap.<snap-name> for the cases where assets from those locations are desired for reuse.

schema migrated from yaml to json

This has been done to make it easier to reuse in editors such as Visual Studio Code to get syntax/error highlighting in place. Here's how it would look like with the appropriate extensions in place:

Once this plugin is ready to use it will be available from the Snapcraft docs. In the meantime, an early preview is available.

New colcon plugin

This plugin enables the new build system that targets ROS2, it has been introduced in experimental form as the build system is actively being worked on by the OSRF.

These are the options the plugin offers for a part needing to build with colcon:

    - colcon-packages:
      (list of strings)
      List of colcon packages to build. If not specified, all packages in the
      workspace will be built. If set to an empty list ([]), no packages will
      be built, which could be useful if you only want ROS debs in the snap.
    - colcon-source-space:
      (string)
      The source space containing colcon packages (defaults to 'src').
    - colcon-rosdistro:
      (string)
      The ROS distro to use. Available options are bouncy and crystal (defaults to
      crystal), both of which are only compatible with core18 as the base.
    - colcon-cmake-args:
      (list of strings)
      Arguments to pass to cmake projects. Note that any arguments here which match
      colcon arguments need to be prefixed with a space. This can be done by quoting
      each argument with a leading space.
    - colcon-catkin-cmake-args:
      (list of strings)
      Arguments to pass to catkin packages. Note that any arguments here which match
      colcon arguments need to be prefixed with a space. This can be done by quoting
      each argument with a leading space.
    - colcon-ament-cmake-args:
      (list of strings)
      Arguments to pass to ament_cmake packages. Note that any arguments here which
      match colcon arguments need to be prefixed with a space. This can be done by
      quoting each argument with a leading space.

The issues and features worked on for 3.2 can be seen on the 3.2 launchpad milestone which are reflected in the following change list:

• many: support for stage-snaps (#2468) (LP: #1805214)
• project loader: do not leak a part's build-environment (#2472) (LP: #1815658)
• build providers: remove dead code (#2474)
• tests: disable spread colcon tests (#2476)
• ci: shallow clones for CLA checks on travis (#2477)
• meta: handle symlinked hooks (#2478)
• project loader: remove special LD_LIBRARY_FLAGS handling for classic (#2485) (LP: #1817300)
• sources: avoid marking changes to the snap directory as dirty (#2475) (LP: #1806746, #1816397)
• cli: clean up snapcraft push output (#2469) (LP: #1804439)
• cli: handle legitimate provider exec errors (#2483)
• schema: convert yaml jsonschema document to a json equivalent (#2448)
• tests: make before/after items an array in schema test (#2465)
• ruby plugin: support new download URL (#2466) (LP: #1815336)
• colcon plugin: new plugin (#2456) (LP: #1805213)
• colcon plugin: support build-time chaining (#2486) (LP: #1816565)

A snapcraft bug fix release

A bug fix release focusing on paper cuts

The issues and features worked on for 3.1.1 can be seen on the 3.1.1 launchpad milestone which are reflected in the following change list:

• ant, maven and gradle plugins: use correct defaults for jre (#2453)
  (LP: #1813637, #1813636)
• rust plugin: new link for rustup (#2438) (LP: #1662960)
• baseplugin: add a proper exception for cross-compilation support (#2454)
  (LP: #1808454)
• clean: error out on invalid or missing yaml (#2458) (LP: #1777501)
• lifecyle: avoid installation of snaps in docker (#2457) (LP: #1814148)
• ci: use non virt-enabled gce instances for 16.04 (#2461)
• extractors: fix typo in code comment (#2452)
• pluginhandler: handle removal of inconsistent files (#2450) (LP: #1813033)
• cli: retrieve error data from provider (#2455) (LP: #1793082)
• build providers: recreate instance if base changed (#2460) (LP: #1794506)
• catkin plugin: describe how to build all packages (#2459)

Welcome snapcraft 3.1

A new minor release building on top of the foundations laid out from the snapcraft 3.0 release.

Build Environments

It is now possible, when using the base keyword, to once again clean parts. To do so run:

snapcraft clean <part-name>

Cleaning individual steps from a specific part, previously provided by the --step option to clean, is being redesigned to be more intuitive and straight forward in its use.

Core

before and after

The before and after keywords, used for ordering service launching within a snap, are now properly supported in snapcraft.

Appstream extractor

The appstream metadata extractor can now properly handle tags inside the relevant nodes and properly filter xml:lang, such that:

  <description>
    <p>List:</p>
    <p xml:lang="es">Lista:</p>
    <ul>
      <li>First item.</li>
      <li xml:lang="es">Primer item.</li>
      <li>Second item.</li>
      <li xml:lang="es">Segundo item.</li>
    </ul>
  </description>

Is presented as the following description in snap.yaml:

List:

- First item.
- Second item.

Additionally, desktop files are now properly found from the appstream launchable entries or by falling back to legacy mode and inferring the desktop file from the appstream id.

Plugins

cmake

The plugin can now leverage build-snaps into the build environment, when any given build-snaps entry exists for a part that uses the cmake plugin, the plugin will make use of CMAKE_FIND_ROOT_PATH so that libraries and headers from that snap are preferred.

Additionally, cmake primitives are now used to drive the build instead of just calling make.

These features have already been used to create an initial set of KDE applications leveraging core18 as a base as described on the KDE apps at the snap of your fingers article.

rust

The rust plugin has been refactored in a backwards compatible way to work better with the non-legacy rustup tool.

Platforms

OS X

When using snapcraft with homebrew for the first time, if multipass is not found, the user will be prompted to install it before proceeding.

The issues and features worked on for 3.1 can be seen on the 3.1 launchpad milestone which are reflected in the following change list:

• cmake plugin: use native primitives (#2397)
• cmake plugin: use build snaps to search paths (#2399)
• static: update to the latest flake8 (#2420)
• project: state file path change (#2419)
• tests: do not use bash as a reserved package name on staging (#2423)
• nodejs plugin: fail gracefully when a package.json is missing (#2424)
• tests: use fixed version for idna in plainbox (#2426)
• tests: remove obsolete snap and external tests (#2421)
• snap: re-add pyc files for snapcraft (#2425)
• tests: increase test timeout for plainbox (#2428)
• lifecycle: query for multipass install on darwin (#2427)
• cli: fix usage string in help command (#2429)
• repo: document package purpose (#2390)
• extractors: better appstream support for descriptions (#2430)
• tests: re-enable spread tests on gce
• rust plugin: refactor to use the latest rustup
• tests: temporarily disable osx tests
• snap: add build-package for xml
• appstream extractor: properly find desktop files
• appstream extractor: support legacy launchables
• snap: add xslt dependencies for lxml
• repo,baseplugin: support trusting repo keys (#2437)
• schema: allow before and after (#2443)
• meta: make hooks executable instead of complaining they are not (#2440)
• build providers: remove SIGUSR1 signal ignore workaround for multipass (#2447)
• cli: enable cleaning of parts (#2442)
• tests: appstream unit tests are xenial specific
• tests: skip rust unit tests on s390x
• tests: use more fine grained assertions in lifecycle tests
• tests: remove rust revision testing for i386

Presenting snapcraft 3.0

The arrival of snapcraft 3.0 brings fresh air into how snap development takes place!

We took the learnings from the main pain points you had when creating snaps in the past several years, and we we introduced those lessons into a brand new release - snapcraft 3.0!

Build Environments

As the cornerstone for behavioral change, we are introducing the concept of build environments. These are configurations created for every snapcraft project you work on, tuned for the desired targets, ensuring API and ABI compatibility are in place for every binary through these build environments.

The way build environments work is by leveraging a feature of the snap architecture called bases.
A base is the building block that applications can rely on as a stable run time. At build time, the snapcraft tool ensures you are creating your applications inside an environment specifically tailored for this base.

To make the transition easy, the entire functionality for this new tool behavior is triggered by making use of the base keyword in snapcraft.yaml. For backward compatibility, all currently well known functionality is still available. You can omit the base keyword and continue working as you have previously done until you are ready to move to a newer or different stack provided by a different base.

The environment is encapsulated from the user during normal operations, but there are ways to step into the environment with the following build command options:

• --shell, runs upto the prior lifecycle step and drops into a shell instead in lieu of running the lifecycle step (e.g.: running snapcraft prime --shell will run up to the stage step and drop into a shell).
• --shell-after, runs upto the lifecycle step and and then drops into a shell (e.g.: running snapcraft prime --shell-after will run up to the prime step and then drop into a shell).
• --debug, drops into a shell inside the build environment when errors occur.

The below video shows an example of how the system behaves with the new functionality in place:

New platforms

With this release of snapcraft 3.0 we are happy to announce that MacOS is supported through homebrew. Moreover, the experience is transparent thanks to the use of build environments and its underlying technology.

Removed features

When using the base keyword in snapcraft.yaml the following, long ago deprecated, features are no longer available:

• wiki parts and the quirks in the code base to allow for certain corner cases introduced by this feature such as allowing / in parts.
• cleanbuild and triggering builds by use of lxd in certain environment variables.
• The prepare, build and install keywords used in parts are replaced with override-build and snapcraftctl, which also have the benefit of doing override- for pull, stage and prime as well.
• The snap keyword which was superseded by the prime keyword.
• When calling build commands through snapcraft, --disable-parallel-build is no longer available, it can be setup per part using the build-attributes property.
• Also, calling build commands through snapcraft, --use-geoip which affected stage-packages is no longer available.

The following plugins are no longer available when using the base keyword:

• tar-content, superseded by the dump plugin.
• copy, superseded by the dump plugin.
• jhbuild, it has too many dependencies against core.

Core features

The snapcraft 3.0 release brings the enablement of these core keywords for snapcraft.yaml with the use of the base keyword.

license

The license applicable to a snap is defined under the SPDX 2.0 format.
Validity of the license syntax is done using snap pack schema validation to ensure consistency across this snap ecosystem.

Wrapperless snaps

If you were part of the history of snaps since its conception, the idea of these wrappers probably make sense as they were useful when they were introduced to setup the environment appropriately. The architecture for the runtime has evolved in such a way where these wrappers do not make sense anymore as the primitives in the runtime have evolved into allowing a better design.

Although it is not the default today, the intention is to make this adapter value (full), the default behavior. Advantages of this design are that when entering a shell through snap run --shell the environment would be properly loaded through use of command-chain entries in snap.yaml

The recording below shows how the original command defined in snapcraft.yaml is now still the command that makes it to snap.yaml and the command-chain feature is used instead:

Extensions

The architecture and framework has been cemented into the snapcraft tool to grow declarative functionality in the snapcraft.yaml. We have done this to avoid repetitive tasks or require deeper knowledge of a target software stack.

Extensions have a unique property of being applied to the snapcraft.yaml itself, for them to be expanded and potentially used in lieu of the extension itself and make further project specific modifications.

You will be able to interact with extensions using the following commands:

• list-extensions, to view the available extensions.
• extension, to show information about the extension.
• expand-extensions, to display how the snapcraft.yaml will look like with the extensions
  applied.

Lifecycle

Prior to snapcraft 3.0, one had to go in and manually clean any part that was found to be dirty due to modifications in the code itself or the part definition in snapcraft.yaml. This was proven to be an unnecessary burden brought upon developers.

Taking this into account, the default action the snapcraft tool takes now is to rebuild parts, by either re-running without cleaning a lifecycle step upon changes for plugins that allow for it (through their underlying architecture) or automatically cleaning and re-running the necessary lifecycle steps for that part.

Here is snapcraft in action considering a project that has already been pulled:

Implicit source

Previously, if a source was not specified for a part, an implicit default source of . were set for parts. This was clearly a mistake that led to many confusing errors. Starting with version 3.0, if a plugins requires a
source to be specified, it will be required through the schema for which an appropriate error message will be raised. For plugins such as nil, a source is not really needed, so if it is not set, no action upon local sources (i.e.: .) will be taken.

Plugins

The majority of non deprecated or removed plugins have been reworked to be base aware.
Since the declaration of the base keyword is done manually by the user, some plugins have introduced semantic changes into how they operate as well.

Below is the set of plugins with interesting changes and new properties available to the user.

ant

These are the properties the ant plugin now operates with:

    - ant-properties:
      (object)
      A dictionary of key-value pairs. Set the following properties when
      running ant.

    - ant-build-targets:
      (list of strings)
      Run the given ant targets.

    - ant-version:
      (string)
      The version of ant you want to use to build the source artifacts.
      Defaults to the current release downloadable from
      https://archive.apache.org/dist/ant/binaries/.

    - ant-version-checksum:
      (string)
      The checksum for ant-version in the form of <digest-type>/<digest>.
      As an example "sha512/2a803f578f341e164f6753e410413d16ab60fab...".

    - ant-openjdk-version:
      (string)
      openjdk version available to the base to use. If not set the latest
      version available to the base will be used.

catkin

These are the properties the catkin plugin now operates with:

    - catkin-packages:
      (list of strings)
      List of catkin packages to build.
    - source-space:
      (string)
      The source space containing Catkin packages. By default this is 'src'.
    - include-roscore:
      (boolean)
      Whether or not to include roscore with the part. Defaults to true.
    - rosinstall-files:
      (list of strings)
      List of rosinstall files to merge while pulling. Paths are relative to
      the source.
    - recursive-rosinstall:
      (boolean)
      Whether or not to recursively merge/update rosinstall files from fetched
      sources. Will continue until all rosinstall files have been merged.
      Defaults to false.
    - catkin-cmake-args:
      (list of strings)
      Configure flags to pass onto the cmake invocation from catkin.
    - underlay:
      (object)
      Used to inform Snapcraft that this snap isn't standalone, and is actually
      overlaying a workspace from another snap via content sharing. Made up of
      two properties:
      - build-path:
        (string)
        Build-time path to existing workspace to underlay the one being built,
        for example '$SNAPCRAFT_STAGE/opt/ros/kinetic'.
      - run-path:
        (string)
        Run-time path of the underlay workspace (e.g. a subdirectory of the
        content interface's 'target' attribute.)
    - catkin-ros-master-uri:
      (string)
      The URI to ros master setting the env variable ROS_MASTER_URI. Defaults
      to http://localhost:11311.

go

These are the properties the go plugin now operat...

2.43.1

Hello Snapcrafters! The Snapcraft team is pleased to announce that version 2.43.1 is out.
This is a minor point release to fix some outstanding issues.

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 Evan Dandrea

New in this release

Core

Extensions

What was previously known as templates is now called extensions and the architecture on which this builds on is now pure python code to allow for future growth and decision making.

The rename takes place to convey that this functionality only extends an existing snapcraft.yaml and does not take part in modifying things that are only in place.

Containers

Build environments will soon be provided by multipass, guaranteeing more consistent results when builds are run from different machines. LXD containers (snapcraft cleanbuild today) will still be supported for existing projects.

In this release we catch up with snapd changes to continue offering a working snapcraft cleanbuild command.

Given the opportunity of modifying this code base, the logic to wait for cloud init has been improved.

Full list of changes

The issues and features worked on for 2.43.1 can be seen on the 2.43.1 launchpad milestone which are reflected in the following change list:

• lxd: support new style snap injection (#2222)
• snap: prepare override scripts to allow rebuilding (#2223)
• lxd: wait for cloud-init (#2227)
• storeapi: handle releasing to a curly braced branch (#2228)
• snap: use set-version and set-grade (#2230)
• lxd: proper filename set when using architectures (#2232)
• tests: cover manifest generation with review-tools (#2235)
• reporting: record the released version for errors (#2238)
• file_utils: find tool when using docker and deb (#2240)
• elf: better messaging on glibc ABI incompatibilities (#2241)
• spread: stop running catkin tests on 18.10 (#2221)
• snapcraftctl: run in isolation mode (#2224)
• templates: reimplement templates as python classes (#2226)
• templates: rename to extensions (#2233)
• cli: add list-extensions command (#2237)
• extensions: fix install path (#2236)
• reporting: improve messaging on errors (#2242)

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

2.43

Hello Snapcrafters! The Snapcraft team is pleased to announce that version 2.43 is out.

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:

• Michael Vogt
• Celso Providelo
• Daniel Llewellyn
• Emmanuel Leblond
• Paolo Pisati
• Jesse Sung

New in this release

Core

lifecycle

snapcraft now accurately identifies source and build changes and re-executes steps accordingly. This new mode is enabled through configuration in this release. To enable it now, open (or create) ~/.config/snapcraft/cli.cfg and add the following entry:

[Lifecycle]
outdated_step_action = clean

Take a look at the feature in action in the following video,

build providers

• Per project SSH key management support was added. Each project will have its own key generated.
• Snap injection logic has been improved and should be faster for the currently exposed build providers (i.e., multipass).
• Use of cleanbuild on OS X now defaults to using multipass transparently.
• Underlying image retrieving logic has been added to have a unique image available to build with any provider which would target a specific base (this is still under the covers and needs enabling).

error reporting

Snapcraft internal errors now prompt to send a report to Sentry, helping us identify the most pressing issues. An option to always report errors has also been added. Set SNAPCRAFT_ENABLE_SILENT_REPORT to a truthful value to automatically send the report.

The prompt asks if you always want to send error reports. If you choose this and change your mind, you can edit the option in snapcraft's configuration.

Take a look at this video to get a quick idea of the error reporting experience:

manifest

For better tracking of deliverables, if SNAPCRAFT_BUILD_INFO is set, the resulting manifest.yaml will contain the version of snapcraft used to create the snap.

templates

The templates machinery has made it into this release. However, no new template has been added as we want to carefully review any of these with all relevant stakeholders to provide the stability and consistency which was not fully achieved with shared parts.

CLI

templates

Although no template is available today, the commands to work with them are already available (these are working names for the commands and subject to change):

• template: Show contents of template.
• expand-templates: Display snapcraft.yaml with all templates applied.
• templates: List available templates (it is currently missing its counterpart list-templates).

Cleaner output

Tracebacks are now handled in a less verbose manner and stored to a file for inspection instead of printed to the screen.

The verbosity of output when using --debug has been reduced considerably as well, leaving the option with a more user-focused role (i.e., debug the actual project being worked on and not snapcraft itself).

The explicit traceback and the output previously seen when using debug can be enabled through use of an environment variable, SNAPCRAFT_ENABLE_DEVELOPER_DEBUG=yes.

Plugins

go

The go plugin now knows not to install the debs if the well known snap is used.

Here's a video showing off the functionality:

kernel

As was done with Ubuntu based deb kernels, the kernel plugin now also installs the .config used at the root of the snap as config-$kernelversion.

rust

Given that they are well integrated into cargo, tests are now run for cargo builds.

jhbuild

The jhbuild plugin can now properly run as root and has been greatly simplified.

Full list of changes

The issues and features worked on for 2.43 can be seen on the 2.43 launchpad milestone which are reflected in the following change list:

• recording: expose the version of snapcraft (#2147)
• tests: add a fixture for OsRelease to simplify test setup
• recording: add the os-release ID and VERSION_ID to manifest.yaml
• nodejs plugin: update to the latest 6.x LTS point release (#2157)
• snap: use apt from the archive instead of compiling (#2156)
• build_providers: support for communicating with a qemu VM (#2155)
• many: refactor snapcraft.yaml loading out of load_config (#2160)
• tests: update codespell, the scope of checks and ordering of static
  tests (#2162)
• rust plugin: fix cargo builds and run tests (#2170)
• build_providers: add ssh key managemet to the qemu build provider (#2168)
• ci: disable osx tests until a new pyyaml is released
• build_providers: inject snaps when running from a snap (#2174)
• code: use black as the standard style (#2180)
• cli: reserve the --debug option for snapcraft projects (#2185)
• state: allow parametrization of the global state file (#2186)
• errors: enable sentry by default (#2187)
• file_utils: get_tool_path to always return an absolute path (#2193)
• errors: support keyboard interrupts (#2198)
• build_providers: add a build image setup facility (#2192)
• build providers: better injection logic (#2196)
• Revert "ci: disable osx tests until a new pyyaml is released" (#2213)
• providers: multipass by default on darwin (#2215)
• lifecycle: automatically stage dependencies (#2144)
• lifecycle: automatically clean dirty steps (#2145)
• travis: use LXD from 3.0 track (#2149)
• project_loader: process parts in consistent order (#2146)
• project_loader: allow loading null parts (#2153)
• tests: disable sentry (#2154)
• lifecycle: don't clean priming area if the snap is being tried (#2143)
• many: extract lifecycle ordering into own module (#2159)
• many: automatically redo step for specified part (#2152)
• tests: add lifecycle ordering tests (#2163)
• many: automatically detect dependency changes (#2165)
• project_loader: replace dict keys as well as values (#2166)
• {catkin,python} plugin: support cleaning (#2171)
• many: add shellcheck to static tests (#2172)
• lifecycle: detect local source changes (#2167)
• lifecycle: pass commands to containerbuild, not steps (#2178)
• cli: SNAPCRAFT_BUILD_ENVIRONMENT isn't deprecated (#2179)
• pluginhandler: use uname from the host (#2177)
• store: properly handle disabled deltas (#2181)
• tests: create basic integration test spread infrastructure (#2173)
• tests: add spread suite for autotools plugin (#2182)
• tests: add spread suite for cmake plugin (#2183)
• spread: stop testing 17.10 (#2197)
• tests: add spread suite for copy plugin (#2199)
• tests: add spread suite for nil plugin (#2201)
• tests: add spread suite for kbuild plugin (#2203)
• kbuild plugin: stop modifying kconfigfile (#2204)
• tests: support running spread suite in autopkgtests (#2188)
• tests: add spread suite for meson plugin (#2205)
• tests: add spread suite for godeps plugin (#2200)
• tests: add spread suite for scons plugin (#2208)
• tests: add spread suite for catkin plugin (#2206)
• tests: add spread suite for waf plugin (#2210)
• cli: add inspect subcommand (#2184)
• tests: add spread suite for tar-content plugin (#2209)
• tests: add spread suite for ament plugin (#2211)
• tests: add spread suite for ruby plugin (#2212)
• project_loader: add basic template support (#2189)
• spread tests: vendor gotty
• spread tests: vendor kbuild-template
• spread tests: vendor hello
• sentry: support disabling error reporting (#2214)
• jhbuild plugin: allow running as 'root' (#2141)
• python plugin: add process-dependency-links to the pull_properties (#2190)
• ci: improve pr template and tools' ignored files list (#2191)
• tests: stricter match when running snapcraft revisions (#2195)
• go plugin: do not install go debs if go snap is used (#2194)
• kbuild plugin: read configs from source directory instead (#2202)
• kernel plugin: install .config as config-$kernelversion (#2207)

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

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:

• Michael Vogt
• Rakesh Singh
• Matias Bordese

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:

• Guilhem Lettron
• Bjorn Tillenius
• Rakesh Singh
• Colin Watson

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:

• Gustavo Silva
• John Lenton
• Celso Providelo
• James Henstridge

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: core18

You 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 the stable channel)
• 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
  - bar

In 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