LINUX

tl;dr: I wanted to test one of my snaps on riscv64. I don’t own any RISC-V hardware. I set up a QEMU VM on my ThinkPad, installed Ubuntu desktop inside it, and it actually worked. Slowly. Very slowly. But it worked.

I maintain nearly 50 snaps in the Snap Store. Most of the time I test things on my ThinkPad running Ubuntu 24.04 (amd64), or my MacBook Air running Ubuntu Asahi (arm64). That covers the two architectures most people care about. But some of my snaps are built for more… exotic architectures. Things like s390x, ppc64el, and riscv64.

Parasocial chat

On Linux Matters we have a friendly and active, public Telegram channel linked on our Contact page, along with a Discord Channel. We also have links to Mastodon, Twitter (not that we use it that much) and email.

At the time of writing there are roughly this ⬇️ number of people (plus bots, sockpuppets and duplicates) in or following each Linux Matters “official” presence:

Preponderance of chat

We chose to have a presence in lots of places, but primarily the talent presenters (Martin, Mark, and myself (and Joe)) only really hang out to chat on Telegram and Mastodon.

The other day I wrote about snapcraft metrics, a tool that enables publishers to extract application metrics from the snap store. Something I’ve noticed which I wanted to share, was how quickly automatic updates roll out to an application’s user base.

So I took the metrics from an application that I published in the snap store and scrubbed the names and version numbers. I charted below the speed that devices roll over from one release to the next. Here’s an image that I think clearly shows the rapid rise as a new release is published, and the rapid drop-off, of the previous version. This chart covers a month where three versions were published, a week or so apart.

tl;dr. The OBS Studio snap is now updated to the latest stable release, 29.1.3, after a “brief” hiatus.

Another day, another updated snap, which had been languishing a bit. I wrote about updating Spot yesterday, and today, as per the title, it’s OBS Studio. As I mentioned previously, there’s a bunch of outdated snaps in the store, and I want to help fix that. Hopefully, with these blog posts, others might learn how, and be motivated to either publish new applications or step up and update existing ones.

I recently lamented that there’s a bunch of broken and outdated snaps in the snap store. Well, some of them are my responsibility, so in the spirit of “be the change you want to see”, let’s get them fixed and updated.

I thought I’d highlight one or two as I go through them, to highlight any important or interesting changes. Today I took a look at Spot, which is a very decent native GNOME Spotify client by Alexandre Trendel.

Agon and Agon

Last month I visited the RMC Cave where we got a sneak peek at the Agon Console8 from Heber. The Agon Console8 is a consolised version of the more general-purpose Agon8 Computer. They come in a natty retro case, and features twin 9-pin joystick ports.

I’d not heard about the Agon line of Open Source devices before, but they tickled something in me. I’m somewhat fascinated by computers that boot directly into BASIC.

I was a guest host on Late Night Linux podcast, episode 249 last week, filling in for Will. We each bring along a ‘discovery’, I brought snapcraft metrics to talk about. I thought I’d write up how I use them, for listeners of the show as it’s hard to articulate this very well verbally.

My snaps

I have about twenty snaps in the snap store. Some, like Bombsquad and ncspot have been published for years now. Others such as Classicube were more recently built and published.

I wrote previously about debugging a broken x16emu snap. In short, something went wonky with ld. I started a thread on the snapcraft forum and Ken VanDine came to my assistance with an answer and a pull request.

I grabbed that pr, and it did indeed build successfully..

$ snapcraft --use-lxd
Launching instance...
Executed: pull alsa-pulseaudio
Executed: pull gnome/sdk
Executed: pull x16-roms
Executed: pull x16-emulator
Executed: build alsa-pulseaudio
Executed: build gnome/sdk
Executed: build x16-roms
Executed: skip pull x16-roms (already ran)
Executed: skip build x16-roms (already ran)
Executed: stage x16-roms (required to build 'x16-emulator')
Executed: skip pull alsa-pulseaudio (already ran)
Executed: skip build alsa-pulseaudio (already ran)
Executed: stage alsa-pulseaudio (required to build 'x16-emulator')
Executed: build x16-emulator
Executed: skip stage alsa-pulseaudio (already ran)
Executed: stage gnome/sdk
Executed: skip stage x16-roms (already ran)
Executed: stage x16-emulator
Executed: prime alsa-pulseaudio
Executed: prime gnome/sdk
Executed: prime x16-roms
Executed: prime x16-emulator
Executed parts lifecycle
Generated snap metadata
Created snap package x16emu_b16509b_amd64.snap  

Even better, it’s smaller. The build I had in the store was 6MB in size:

I thought I’d “live blog” (not live) my way through fixing a snap which I noticed was broken this morning. How did I notice? I happened to look at the build page for it. Maybe my spidey sense was tingling, because I wouldn’t ordinarily have zoned in on this particular snap.

I could have some kind of alert that lets me know when this happens, but I currently don’t. I might use my new-found love of GitHub Actions, but that sounds like a future blog post!

For the last six months, I’ve been a presenter on Linux Matters. Prior to that, I spent thirteen years presenting the now-defunct Ubuntu Podcast. Both shows have/had multiple presenters,

We record every other week, and send our individual audio files to Joe. He does all the magic post-recording production including editing, audio processing and mastering. That file is then uploaded and eventually makes its way into the Patreon “all episodes” ad-free feed, then to our feed a day or so later.