Raymii.org

Table of Contents

• Why re-package gnash as a snap?
• Why run gnash?

I hate snaps just as much as the next guy but last week I did something unexpected. I packaged up Gnash as a snap. Gnash is a GNU flash media player, not updated since 2011, and thus removed from the Ubuntu 20.04 repositories. The snap packaging is based on work by phil roche, he wrote about re-packaging older debian packages with an Ubuntu 18.04/16.04 base layer as a snap. My gnash package is confined (no --classic needed), the source code for the snap is on my github and on any snap-enabled distro you can now snap install gnash-raymii to enjoy Gnash again.

Consider sponsoring me on Github. It means the world to me if you show your appreciation and you'll help pay the server costs.

You can also sponsor me by getting a Digital Ocean VPS. With this referral link you'll get $100 credit for 60 days.

As the code is up on github and Phil has his code up as well, you should be able to easily re-package deb's as snaps as well. Pygopherd comes to mind, but any package from the Ubuntu repositories you might need fits the bill, search/replace gnash, test the confinement options and you're done.

Here is a screenshot of Gnash running as a snap:

Why re-package gnash as a snap?

As you might know, I sincerely dislike snap and I actively avoid using it. However, a few co-workers do run Ubuntu and were fiddling around with my docker gnash guide, didn't get it to work and asked me for help. As I recently read Phil's article and this was a good way to put that into practice. As Gnash is no longer under active development for almost a decade, it is not in the Debian/Ubuntu repositories anymore, thus hard to install. But, Ubuntu 18.04 was the last release to have it in its repositories, so just as with the Docker guide, I used that as a base. Compiling gnash by hand is hard due to outdated dependencies (looking at you gstreamer).

I might dislike snaps, as with most of my work I'm pragmatic enough to use whatever task suits the current situation best, and for this problem snaps were a good fit. Saves my current and future co-workers a bunch of time.

Why run gnash?

Some of my $dayjob work depends on gnash, although it's actively being replaced with QT. Gnash in our case runs on the framebuffer of an embedded device, no network connectivity, no external input, so almost no risk.

For development and testing we sometimes need to run gnash on my workstation with an SSH port forward to a development board. We can then locally interact with the UI. Also, the development board does not require a screen, which saves time and space in the development setup.

We don't want the coffee machines to end up as e-waste in a few years, expected lifetime with regular maintenance is at least a decade, I suspect we'll use Gnash for just as long. All of our new machines use QT, but the older ones still get support and waranty.

Here is gnash running the coffee machine user interface: