Snapcraft

Preamble

Until recently, I worked for Canonical on the Snap Advocacy Team. Some of the things in this blog post may have changed or been fixed since I left. It’s quite a long post, but I feel it’s neccessary to explain fully the status-quo. This isn’t intended to be a “hit piece” on my previous employer, but merely information sharing for those looking to control their own systems.

I’ve previously provided feedback in my previous role as Snap Advocate, to enable them to better control updates. However, a lot of this feedback was spread over forum threads and other online conversations. So I thought I’d put together some mitigations and the steps I take in one place.

This is a bit of a dayjob post, but as I maintain a bunch of snaps in my own time, I figured it’s not out of place here.

Typically when I (or indeed any developer) uses snapcraft to build a snap, a snapcraft.yaml drives the process. I’ll integrate some kind of CI or build system, and start publishing to the Snap Store. Usually, once created, the yaml doesn’t need much in the way of changes. Back when we first started building snaps, we were using Ubuntu 16.04 LTS systems. At runtime the snap would leverage the base of core. The core snap is a super minimal Ubuntu 16.04 LTS runtime environment.

On Thursday I mentioned we were restarting the Snapcraft Clinic. Basically we stand up a regular video call with engineers from the snap and snapcraft team & us from Snap Advocacy. Developers of applications and publishers of snaps are invited to join to troubleshoot.

There was nothing especially secret or private discussed, but as we don’t record or stream the calls, and I don’t have direct permission to mention the applications or people involved, so I’ll keep this a little vague. In future I think we should ask permission and record the outcomes of the calls.

At work we have a forum where developers can discuss packaging Linux applications, specifically as snaps. Sometimes developers just want to pair through a problem to get it either resolved for themselves, or for whatever is blocking to be handed off to the right people.

One strategy for supporting developers we found effective was via regular live video conference. So last year we started the Snapcraft Clinic. On a semi-regular basis we dedicate time to join with anyone who has technical issues with snapping, to help them.

Last year ( 😄 ) I wrote an article called Snap Along With Me in which I detailed how I approached snapping a rust application called t-rec. Well, I’m back with another “Snap Along”, this time we’re snapping an application written in Golang.

During a meeting to on-board a new member of the team at work today, I went through a similar process as my last blog post. This time I chose a different application, so I thought I’d write it up here. I’ve previously explained how I browse the various GitHub Trending pages for each language. Today was no different, we browsed the trending rust projects then moved on to trending Go projects.

I was recently interviewed by Joe Ressington for Late Night Linux Extra episode 14. Here’s a transcription I typed up, which may be useful. I used an automated tool to create the transcription, then tidied it up myself. If you spot anything which doesn’t match the audio, and is materially important, do feel free to propose an edit on GitHub (link at the top of the page).

Joe: This episode is about snaps, quite the controversial topic in some circles, and who better to talk about it than Alan Pope - “popey” as he’s affectionately known by almost everyone. According to his twitter bio he is a Developer Advocate at Canonical working on Snapcraft and Ubuntu. Now, in case you don’t know popey is a good friend of mine and I’ve done many podcasts with him over the years, but this, he’s Alan, he’s Alan Pope of Canonical, he’s not my friend. It’s a work thing for him, because you know, I wanted to ask him some fairly difficult questions and try and clear up some of the misapprehensions and just get to the bottom of what is going on with snaps.

This is an early PSA aimed at developers who publish snaps in the Snap Store. They can probably skip this preamble, but for anyone else here’s some backstory in case you’re bored interested.

Preamble

Snaps are confined software packages for Linux. They were originally designed / intended for IoT use cases so are optimised for size, bundling dependencies, are compressed on disk and auto update. They can also be used to package server software, like NextCloud, and desktop software like Signal Desktop. There’s millions of desktops, routers, servers and other interesting devices with snaps installed.

I don’t consider myself a ‘Developer’ but I maintain a bunch of snaps in the Snap Store, and threw together a shell script which I’m sharing here in case it’s useful to other publishers. The goal of the script is to go through each snap and check to see if there’s a newer version of it upstream than currently published in the store. As such it’s not meant for end-users, but for people like me who publish multiple snaps from different places, and want to keep on top of them.

Every so often I find myself with an idle hour and decide to use that time to package some new software for Linux. A common activity among nerds, I’m sure ;). This blog post is a write up of what I did, and why, which may be useful to others with time on their hands.

I keep meaning to live stream when I do, but on this occasion I had a bad hair day was also listening to and engaging with a podcast, so it wasn’t practical. In leiu of that, while the information is fresh in my head - the morning after - I thought I’d write down some notes here.

As you may or may not be aware, I work for Canonical on Snapcraft and Ubuntu. I use Ubuntu as my daily driver, and spend a lot of time maintaining snap packages, and listening to developers and users talk about software packaging, publishing, delivery and use.

Over time I’ve collected a bunch of virtual notes in my head. Much of it has been turned into documentation, but often the information is rather spread out. I wanted to “brain dump” a bunch of notes, for common things people ask me about snap, snapd and snapcraft. Here’s the first set, about snap / snapd. A later post will focus on snapcraft.