Developer sprint Sep 17th, 2018

Yep, we’re going to do that.


Regarding this I would like to mention the following topic:

1 Like

I think this is a great idea - we’ll look into it.


Handover of core16 and core18

  • core16 is just core without snapd inside it
  • snapd is becoming its own snap
  • New snaps should follow traditional processes for other images shipped by Ubuntu
  • Updated whenever there are security issues, as usual
  • core will still be maintainable in the near future for compatibility purposes, and until a transparent migration from core to core16+snapd is possible.
  • snapd team maintains core, foundations team maintains core16 and core18
  • Retention policy for general images in general is 3 days
  • New core16 and core18 snaps ship every time a package in the manifest is updated
  • As usual, new snaps first go to edge channels first, and flow up from there
  • Test suite needs to make sure core devices can still boot with updated core snaps
  • Process:
  • Upload to edge automatically
  • Several tests are run automatically, from different teams
  • Tests pass, move to candidate
  • Nobody complains, 48h later it goes into stable
  • If end of timeframe falls on weekend, it’s expanded to fit whole Monday

(cc @slangasek @gaughen)

1 Like

Restriction for snap names in specific stores

  • Given the flat namespace of snaps, brand stores that consume well known names might prevent everybody else from using these names
  • Idea is to have one or more prefixes per store which is automatically approved, usually matching the brand trademarks/names/etc
  • Other snaps go into manual approval mode, same as current black list
  • We need a target date on which the store will enforce those rules

Restrictions for account usernames and display names

  • Account names are too generous in terms of acceptable characters at the moment
  • We want a single separator character (probably dot or dash)
  • Supporting dash and dot and plus and … is just unreasonable
  • We need a migration plan so we don’t cause pain over the migration process
  • … to be finished

This flow doesn’t mention the beta channel at all, which has historically been tested by CE on Commercial/Reference Devices. Would this still be the expectation with this new flow? Our fully automated infrastructure looks for new snaps in the beta channel for the vast majority of snaps that are shipping on commercial devices, and it would be quite disruptive to special case the Core snap to test in Edge rather than Beta.

The tests mentioned above run by CE do this (and quite a bit more of course) on both Commercial Devices as well as all reference devices (rpi2, rpi3, CM3, Dragonboard, NUC, etc)

Feedback from community

  • Snaps are bundling libllvm/etc too much
  • New versions of nvidia may need some improvements
  • People want RPMs of snapd for other distributions (non-Fedora)
  • We’ll put some additional RPM distributions in the functional test suite
  • Apparently some applications are always autostarted with no way to disable. Unknown to the team… reproducer is needed.
  • Some publishers are looking for better handling of links (irc://, etc)
  • Support for document portal is desired for some snaps. In theory that’s already done as far as snapd is concerned. Need to confirm what else needs updating for it to work.

@cwayne18 Hi Chris,

If implemented as discussed today, the snap that goes into the edge channel will be unstable and untested. After tests pass, which should include the tests from your team, the snap is promoted to candidate. A promotion to candidate implies any systems following beta will also pick it up, per usual rules for channels. These semantics are in place precisely so that consumers can follow any of the channels, and they are guaranteed to observe the snap in candidate if beta is closed, or stable if both beta and candidate is closed.

Note that the tests that run while moving from edge to candidate must all be automated. We cannot have any manual steps between the edge stage and the candidate stage because these updates will almost always be about CVEs, which need to hit stable very timely. After it hits candidate, there will be a pre-defined amount of time for manual and external tests that might block the stable release if reported and depending on severity.

Also worth noting that these updates won’t include any snapd changes or any other non-security-critical fixes. The snapd changes will be published in the snapd snap itself, in that new world.

How does one get involved? More specifically I would be interested in some working on updating the Go plugin and fixing some issues I’ve had with Rust snaps.

1 Like

Hi @eberkund,

Thanks for your interest. The best way to start the conversation might be to create a topic here in the forum in the #snapcraft category, detailing what you’d like to get done. Then someone in the team (probably @sergiusens or @kyrofa) will reply with suggestions for how to achieve it, and how to submit it.

If you have any trouble doing that, please ping me again.

1 Like

Tame our command-zoo (help command organization)

  • Reorganize help so it’s shorter, fitting in a 25 lines terminal
  • Group commands by functionality
  • Automate creation, and make sure new commands have a group
  • snap help --all lists everything with summaries, grouped in the same categories
  • Proposal for the text of snap -h/–help, snap help, and snap on its own:
The snap command lets you install, configure, refresh and remove snaps.
Snaps are packages that work across many different Linux distributions,
enabling secure delivery and operation of the latest apps and utilities.

Usage: snap <command> [<options>...]

         Basics: find, info, install, list, remove
          …more: refresh, revert, switch, disable, enable
        History: changes, tasks, abort, watch
        Daemons: services, start, stop, restart, logs
       Commands: alias, aliases, unalias, prefer
  Configuration: get, set, wait
        Account: login, logout, whoami
    Permissions: interfaces, interface, connect, disconnect
    Development: run, pack, try, ack, known, download

For more information about a command, run 'snap help <command>'.
For a short summary of all commands, run 'snap help --all'.


  • Server side has most of the complexity, and is mostly done
  • Client side is not finished, but is very simple in comparison
  • We already accept both the shorthand notation and the extended notation in snap.yaml
  • Must make sure snapcraft already recognizes the field with both formats (cc @sergiusens)
  • Do we send to the store on refreshes already?
  • Must block updates
  • When the write epoch changes locally, a refresh needs to be scheduled shortly thereafter
  • Snapshots need to block restores to a revision with an incompatible epoch, much like snapd must block the install of a snap that cannot read the data
  • Snapshots already store the epoch
  • Documentation must get written. Here in the forum we have very good coverage of the low-level details, and some coverage of high-level ones.
  • User data is not part of this picture at the moment, because it requires users to actually run applications for the data to be updated, and there’s no registry of all the users that have ever run the application
  • We may add snapctl epoch for querying purposes
  • In the future we may also support dynamically setting the write epoch via snapctl set-epoch
  • As soon as the basic functionality of snapshots are in master, we’ll start working on the client side of epochs
  • Snapshots will be considered actually done when a refresh or a remove does a snapshot automatically
1 Like

Ubuntu Core 18 kernel and gadget schemas

  • We need the new kernel name and schema that allows upgrade to be independent for diverging platforms
  • A snap built can only be uploaded once to the store
  • That means a single kernel that works on multiple devices needs to either be built twice, even if the bits are effectively the same
  • Proposal is to use “kernel” as the snap name, and then individual tracks “18-pi2”, “18-pi3”, “18-cm3”, etc
  • Same for the gadget: a “pi” gadget, with tracks named “18-pi3”, etc.
  • The advantage of this schema is that one build may be published in multiple platforms, but when necessary they may also become independent builds
  • This schema may be used by third-parties as well
  • The model will mention something like “kernel: kernel=18-pi3” to lock down the track name for this particular platform
  • In those cases snapd won’t allow changing the track, as it would invalidate the model
  • That takes away some freedom from the track functionality, but that sounds okay for this specific context, since we don’t expect more variance than what’s already allowed by the risk levels (edge, beta, etc) plus branches, which all work within a single track
  • The “snap info” command needs to be modified so that when the model has a locked track, only that specific track is shown; that prevents people from seeing tracks for completely unrelated devices, and also is prevents encouraging switching tracks and that’ll error out on that device

Ubuntu Core 18 status and next steps

  • Dragonboard still crashing
  • Pi 2 and 3 have network issues with console-conf
  • We need the “classic” snap for core18 still
  • How do we get different environments from same snap
    • classic→Classic environment for current boot base
    • classic.16→Ubuntu 16.04
    • classic.18→Ubuntu 18.04
    • classic.fedora28, etc
  • It would be great to have that working inside classic systems as well, in addition to core devices
  • The “classic-support” interface and the driving shell script inside the snap need to be reviewed and modernized
  • Hide bases by default from snap list
  • Bases need to be removed when they become unnecessary
  • Timeframe is a few weeks ahead

note that these most likely come from the fact that the gadget in stable uses an extremely outdated boot firmware (one old enough to not have full support for all power management, thermal control and other bits that will influence the operation of peripherials).

There have been multiple approaches to make snapd allow gadget payload updates (and there are multiple forum posts about it), the last one is here i think:

this has never been implemented, with the result that the stable pi gadgets all stayed on a pre-release firmware (with the exeception of the cm3 where we had the opportunity to use a newer firmware from the beginnning, since the initial image was created a lot later than the other two), there are no networking (or other hardware) issues with the edge images .

the same goes for graphics support on all pi devices, the gadget firmware in stable pre-dates many fixes and configuration options for the pi that are all fixed in the edge gadget which could never be released due to the above missing feature.

EDIT: whoops, sorry, i guess for core18 michael actually used a newly created gadget with a newer firmware when doing his test images, in that case the above would indeed not apply (still an issue in core16 though)

Will there be any alternative on core devices to find out which revision of the rootfs snap you are running beyond snap list (this can be pretty essential info at times) ? Or is the plan to only hide the additionally installed bases there ?

We should probably print something on snap version for that.

1 Like


  • Feature has a few related but different use cases
  • Fundamentally, allows going from one model assertion to another
  • In some cases this might be a new revision of the assertion, which means it’s automatically updated
  • In other cases, it would be a manual (or driven externally to snapd) action shifting from one model assertion to a different one
  • We need to research how to integrate the remodeling procedure into the serial vault, so that the device can become a new model as soon as it requests a serial for itself.
  • The goal is allowing changing of all details of the model: base filesystem snap, kernel, gadget, store, required snaps, etc.
  • Internally in snapd, we hope to implement all those changes using the same code path. Among other things, that means being able to shift back to a previous model.
  • Change of model needs to be approved in the model itself, with language to be defined.
  • Change should be approved in both directions. That is, the target model should be able to restrict which models it can be transitioned from.
  • Wildcards allows accepting all transitions (or perhaps not specifying anything allows all transitions, TBD).
  • Restrictions might be specified per brand, maybe?
  • There might be use cases to allow the gadget to start the remodeling via snapctl.
  • Ideally serial would be obtained in the beginning of the transition so it can use it to communicate, but there’s a chicken and egg problem, because downloading the new gadget might require a conversation with the right brand store, and the new gadget might be required to acquire the new serial, and the new serial is required to talk to the right brand store. Loop must be broken somewhere.
  • We might start with a smaller use case where only some fields in the model are allowed to transition. Changing only the store, and perhaps installing non-core required snaps (not kernel, gadget, core, base) might be easier.
  • There are legacy cases which use a store but are using the generic model. This is an unsupported use case, and needs to be ported to a normal scenario where a model is involved and detailing the store.

Desktop topics

  • Discord autostart was starting it at all times, because it uses the X-GNOME-Autostart boolean extension to define whether to actually autostart. We’ll fix it so it’s respected, and will also look for equivalent ones in KDE.

  • Themes

    • gtk-common-themes is working well
    • Might add a couple more in the snap
    • Perhaps remove some unnecessary ones too
    • Regular cadence to release that so it doesn’t become stale
    • New extension system will help making everything look nice by default
  • Snapcraft build VMs

    • More consistent and isolated builds for everybody
    • Won’t fiddle with the host system anymore
    • A “destructive” mode may be supported for environments that are very locked down and want to pretend to be inside a VM already
  • Snapcraft remote parts

    • These are gone in the new world
    • Only true once “base:” is used in snapcraft.yaml
    • Otherwise remains compatible with the past
  • Snapcraft extensions

    • Allow manipulation of yaml in an organized way
    • Composable since one feeds into the other
    • Command chains finally remove the wrapper hacks and fits very well with extensions
    • Allow evolving the extension automatically
    • Adding plugs and slots to extensions should be done very carefully. We don’t want snaps depending on things unnecessarily by default.
  • Other snapcraft improvements

    • A build-environment field will allow setting environment variables to the build generally
    • Using snaps as a build dependency is coming as well
  • Portals

    • Security review done for the main portal package
    • Gtk one is still in the works; estimated for a week ago but there yet… but close.
    • Will get it working in Cosmic, and then backport as necessary.
    • It will just work.
    • As new portals are added, these should also just work.
  • Pulseaudio

    • Cosmic is already restricting recording
    • Bionic is next, and then Xenial
  • Desktop snap QA

    • Automatic checkbox testing of a series of snaps
    • Happens automatically whether people are there or not
    • Plans is to also check whether themes are applying correctly, are applications opening, etc
  • Metered connections

    • Plan is to change meaning of current setting in a compatible way
    • Only blocker at the moment is making sure that devices unattended aren’t incorrectly marking whatever device they use to communicate as metered
  • Translations of metadata

    • Something along the lines of meta/i18n/pt_BR.yaml
    • Consider translation of media as well (screenshots, etc)

Second meeting

  • Banner support

    • Somehow support the fact some screenshots are banners for the top
  • Support some sort of client identification when going through snapd

  • Some asynchronous operations should report an error kind (#1763289)

  • Notification of events from snapd

    • Something that allows a persistent UI to update itself when something happens
  • Channel maps in search results

    • Probably won’t happen… it’s way too much data for search results
    • Gnome software is currently looping and looking for that data… that’s a bad idea and shouldn’t be done
    • Instead, it’s much better to only ask for the channel map once you look at an individual snap
  • Access for hidden files

    • Read-only is okay, purpose is migration of data towards the snap
    • It has to be manually reviewed before it can even be installed, since there’s no way currently for the user to tell what specific directories the connection would allow. That’s okay for the use cases at hand.
    • We may conditionally allow writes as well, also subject to review and approval
  • Have a hook to notify the application that a refresh is available

    • Warn that a refresh is available for some applications
    • We need to force at some point though
  • Review of portal startup PR

    • Drop a marker file in an in-memory filesystem so that it only queries once for presence of doc portal
      • portals.present
      • portals.missing
    • Testing: verify what happens in all supported distributions, when the portals package is present (when it exists) and is not present

I’m guessing this is specifically people want EL7 support? Unless there are other RPM distributions that are desired? It’s not terribly difficult to extend the Fedora packaging to support other RPM distributions, as most distributions are more similar to Fedora than not…

Build images for Snapcraft

  • The goal of the snapcraft build process rework over the last several months was to have consistent builds across all platforms, sideways and back and forth (any given Linux distribution L1 version V1 can build a snap that uses a base snap from L2 version V2).
  • Some platforms are unable to run a full VM, but can use containers, so we’ll allow Snapcraft build VMs to also register a respective LXD image
  • Launchpad and will use the LXD image
  • We might use LXD inside a VM to avoid the consistency requirements between VM image and container image, but it will be slower, more complex, have a different kernel
  • Even ignoring the Snapcraft needs, having an Ubuntu image consistent across VMs and LXD is a good idea
  • The Ubuntu Cloud image isn’t an ideal target for this because it changes more than necessary for building purposes
  • Foundation will own the creation and retention of the image and the containers for Ubnutu, as usual for every other Ubuntu image
  • Images will contain build-essential, and lose documentation and man pages etc
  • Snapcraft will ask multipass for a snapcraft:<base> image, and multipass will do a lookup somewhere remote
  • The Launchpad build environment will be upgraded to LXD 3.0
  • Timeline: TBD, it’s a priority

(cc @slangasek @cjwatson @kyrofa @sergiusens)

1 Like

@Conan_Kudo The ideal case would be to have the package in EPEL indeed, but we may have to do something else before that as it’s taking some time for it to get through.