KDE’s Snap Packages

The Linux world has always worked with a develop and deploy model where software gets written by projects such as KDE and then distro projects pick that up, polish it and give it to the user.  No other computer environment works like this and it goes against the fashion of DevOps concepts where the people who code are empowered to deploy to the end user going through QA as appropriate.  We changed that with KDE neon where we brought the packaging into KDE making .deb packages. That integration allows for blockages and imperfections which get identified to be solved easily through the most efficient channels.  Kipi Plugins is a good example of this, KDE dropped the ball here by stopping releases. Nobody noticed until as a packager I wondered where it had gone, realised it was no longer being released and, because I work directly in the project responsible, could easily fix that in the right place.  With new containerised formats Linux is changing, and projects like KDE can now package software and send it direct to the user.  I’ll discuss this more in a future blog post but for now lets look at Snaps where last week, for the first time, KDE Applications was released with 50-odd apps available directly for all to enjoy direct from the Snap Store.

Give it a Try

First you need to install snapd which comes as default with KDE neon and Ubuntu distros but others will probably need to enable it manually.  See the Snap set up guide.

For Plasma Discover integration you should also install the Plasma Discover backend snap package, it is called ‘plasma-discover-backend-snap’  in Debian/Ubuntu/neon but the naming convention in your distro may vary.

You can now install Snap packages directly from the store which uses snap:// URLs to start Discover and install them.  You can also install snaps from the command line.

If you look at the KDE page on the Snap Store you can see the 50+ packages we have available today.  Most of the packages are fairly simple apps such as games and education apps, future work is to do many more KDE apps.

Snap Store? Channels? Who controls this?

Snaps follow a similar model to other large providers like Android, iPhone, Windows, Steam, etc with a centralised store, in this case run by our friends at Canonical.

There is a KDE publisher account on the Snap Store which is currently controlled by your friendly KDE neon team.  Anyone can make their own publisher account, and there’s a nifty feature to mark it as a collaboration between several accounts. For example Kdenlive is made by the Kdenlive Jean-Baptiste but the KDE account also has access.

The Snap Store features channels intended for software in different stages  of their development cycle, this mirrors quite closely what we do in KDE neon for our .deb archives.  Most users will only care about the Stable channel offering thoroughly tested software.

There is also the Candidate channel for testing builds of released software. The Edge channel is for Git master builds same as Unstable in KDE neon and the Beta channel is for Git beta branch builds same as Beta edition in neon. By default Snap will only install stuff from Stable and you have to ask explicitly for other channels but this is a great way to be testing pre-release software.

When uploading to the Snap Store for the first time there is a manual review package by archive admins which is similar to uploading new stuff to Ubuntu or many other distros, you also need manual review when you first upload a Snap package which asks for special permissions such as talking to DBus. The reviewers are nice people inside Canonical who you can ping on the Snap forums if you need to.

You might notice the KDE publisher page on the Snap store is missing a load of icons and other met data such as screenshots. These should come from AppStream files but AppStream support is still working its way into the Store backend and build tool snapcraft so not all the icons are there yet. It seems we need to work out how to use a newer snapcraft on KDE neon servers to get all these magic features sorted.

Snapd runs on your system and takes care of downloading and installing the packages. It will update Snap packages automatically so you can be confident you’ve got the latest and greatest provided by the publisher.

How’s it Built?

Snap packages are built with a snapcraft.yaml file to define how and what needs to be built by a tool called snapcraft.

In KDE neon, we have a load of Git repos for our .deb packagingm and we have reused these for our Snap packages. The neon repos are documented on the KDE wiki, and asa KDE project, all KDE dev account holders have full access. For example, KAtomic has a snapcraft.yaml file , a metadata icon and .desktop file.

Here at KDE neon tower, we have a team of guinea pigs building our .deb packages. , We have repurposed the same guinea pigs to build these snap packages. , The build jobs get created on KDE neon Jenkins servers and when someone triggers them (any KDE dev has access), the build is made on the floating cloud of guinea pigs. If successful, it is uploaded to the Snap Store.

KDE neon Tower
KDE neon Tower

This is nice, but is still not as integrated as it should be. Newly released sources are built and uploaded to the Candidate channel on the Snap Store, which then needs manual review before moving to the Stable channel. Thist should get automated using openQA.

And there’s not really any need for any of it to reside on the KDE neon servers, everything should be even more tightly integrated with the rest of KDE and built as part of the new invent.kde.org CI system, and then uploaded from there. It shouldn’t be the responsibility of KDE neon team to make these, it should be done as part of the app development process.  So jump on board and enter a new world for empowered, rapidly released software!

To find out more about the Snap format follow the tutorials, read the docs and browse the notes on KDE paticular stuff.

Kipi Plugins 5.9.1 Released

Kipi Plugins is a set of app plugins for manipulating images.  They use libkipi which is released as part of KDE Applications.  It used to get standalone releases and was then moved to be part of Digikam releases.  Since Digikam 6 they have been deprecated by Digikam in favour of their new plugin framework DPlugins.  While in KDE Frameworks the Purpose Framework is another newer project covering similar features.

However Kipi Plugins are still supported by KDE apps KPhotoAlbum, Gwenview, Spectacle so they shouldn’t disappear yet.

I’ve made a new release available for download now.

https://download.kde.org/stable/kipi-plugins/

Versioned 5.9.1 because it is little changed from the previous release done inside Digikam which was 5.9.0.

Tagged commit b1352149b5e475e0fbffb28a7b5fe13503f24dfe

Sha256 Sum: 04b3d31ac042b901216ad8ba67dafc46b58c8a285b5162b51189833f6d015542

Signed by me Jonathan Riddell <jr@jriddell.org>

This will become part of KDE Applications in its next release scheduled for August and will follow the KDE Applications version numbers.

 

British Canoeing Advanced White Water Safety and Rescue

I’m doing my Advanced White Water Leader award some nine years after I last tried it but stopped due to not enough experience on higher grade water.  I did the training last December and now I’ve redone the safety and rescue training which I last did in 2010.  This is a two day course I did with Sean of Wildriver on the upper Tees at Low Force in Englandshire.  It’s a scrapy river but served fine for the purposes of this course.

20190408_105028

Starts with knots and ropes on land.  We looked at using trees as an anchor with a straight tie around using overhand knot and tape knot.  Then 3 wraps, tie 1, hook 2.  We looked at adding a line to pull on either direct, or at 90 degrees (less friction), adding an italian hitch to make it more controllable then making 2 to 1 pully, 3 to 1 pully, 4 to 1 pully, 3 to 1 with prussiks, adding a pully wheel to make it smoother, 4 to 1 with a pig rig.

In England you don’t need to do a warm up before you get on the water, it is built into the activity as you run across the farmer’s field before he shoots you for trespassing.

We moved onto the river and used the above to help move boats up and down a steep bank.  We also looked at ways to control a person decending down a steep bank with a line down then angel wings (holding line under both arms), south aftrican (holding line around legs) or attached to the chest harness and let out from above.

We went off syllabus and looked at paddle length and grip.  I have a very very short paddle (185cm) because it gives the high cadence and agility needed for freestyle but a more normal white water paddler will use a longer paddle (190 to 210cm) for more power on the stroke as well as being able to reach maybe a boof which needs to be lower down.  A WW or flat water racer will use a longer one still but that’s far too tiring for general WW boats.

We looked at swimming over a current, this just needs a powerful front crawl.  Any corkscrew is only if you don’t have the power to get over an eddy line. We moved to a faster rapid where the best technique to get across was a jump then swim.  This depends on being able to know you’re not jumping into any rocks.  The syllabus says you need to cover your face and crotch but it’s best to look like superman cos that’s cool.

We looked at picking people up with a throwline.  It is often easier to try to bring them in direct towards you than to pendulum them downstream of you as that exerts greater force on your line.  We looked at live bait too where one person is attached to the throw line by their harness and jumps in to catch someone else, this needs some coordination such as who is holding the extra line to be released on jumping.  For extra speed consider just walking or running away from the river when pulling someone/thing.  We looked at picking up kit from the river including lots of live bait jumping.

On day 2 we made a synch for picking people out the river, two throwlines attached in a circle.  One way is both bags on either side, another way is both bags on one side. It’s faffy and the casualty will not make it easy because they’ll be panicking and it only works over a short distance.  But it might be useful.

We looked at in river rescues placing a person in the river using two throwlines on each bank and the person attached from the harness to both lines on a pendulum, Y and X formation.  It’s hard work and needs coordination.

We did a scenario with walking wounded helping them cross a river on a dual rope pendulum setup and moving them across rocky terrain.  It’s hard work.

The idea that you should hold a throwline with a grip of thumbs towards you is probably nonsense, use the best grip possible.

To take my WW river paddling to a decent next level I need to get a new dry suit (current one is 3.5 years old and reliably leaks all over), a new paddle (current one too short) and a new boat (currently I borrow broken club ones). When Brexit happens and the pound collapses I will be able to afford all this.

 

 

Add Appstream Release Data to your App Releases

Appstream is a metadata standard for your software releases which gets used by package managers and app stores as well as web sites such as kde.org (one day at least).

If you are incharge of making releases of an application from KDE mind and make sure it has an appstream appdata file.  You should also include a screenshot preferably in the product-screenshots git repo.

You should also add release data to your appstream files.  See the docs for the full details.  Not all the data will be very practical to add before the release time but it is useful to at least have a version number and maybe a release date added in.

I’ve added this to the Releasing Software wiki page now. And I’ve written a wee script appstream-metainfo-release-update to update the XML with a simple command which I’ve now added to the Plasma release process.