My thoughts on Slackware, life and everything

Month: October 2022

Flatpak on Slackware

A while ago, someone e-mailed me with a request to add Flatpak to my repository. At the time, I had no interest in Flatpak, had not actually bothered to investigate it, so I said “sorry, no” and dismissed it.

Still, my curiosity was piqued, because I have been having long-time struggles getting our company version of MS Teams up and running on my Slackware desktop, and Flatpak could offer resolution. I am an advocate of running natively compiled code on your Slackware OS, and the software that I am using regularly is all available in my repository as packages that have been compiled on Slackware from source. But Open Source is all about choice, and more power to you, right?
I am realistic enough to see how self-contained binary software distributions can have an appeal to people. These days, more and more new software releases are made available as AppImages, Snaps or Flatpaks. The developers won’t have to worry about maintaining friendly relationships with distro packagers who may or may not do the packaging work for them every release. In fact, distribution mechanisms like Flatpak finally place niche distros like Slackware on the same level as their more widely used brethren like Ubuntu or Mint. The Flatpak app will run on all of them, unmodified.
The downside of course, is that this bundling of a program plus all its dependencies will increase the size of the on-disk installation. A natively-compiled package relies on dynamic linking to the libraries which are provided by the OS, but the Flatpak needs to bundle its own compatible copies of all those libraries. Lean versus bloat. Convenience has its own sacrifices.
For me as a Slackware packager and coreteam member, it is more important to offer options than to be a zealot. If a tool like Flatpak brings you more joy using Slackware on your computer, who am I to deny it to you?

Bringing it to Slackware

So I dove into the available Flatpak documentation (it is very extensive!) and also I went through the Flatpak submission on to see if there were Slackware-related challenges to be overcome. Seems like the only hairy topic may be that of getting sound out of the Flatpak and into your speakers, but so far I have not messed with audio. On first glance audio works out of the box on Slackware64-current in a Plasma5 desktop session, where I tested an Internet radio player.
I will update this article once I understand the concepts better and can share proper and fool-proof instructions.

The versions of flatpak and its dependencies found on SBo are limited by the versions of libraries in Slackware 15.0, hence you won’t find the latest version of Flatpak there. For Flatpak 1.14.0 you really need to be running Slackware-current.

It’s not just about Slackware’s own provided libraries; the external dependency requirements also changed between Flatpak 1.12 and 1.14. I use both Slackware 15.0 and -current, therefore I have built two parallel sets of packages; one for Slackware 15.0 and another for -current.
On Slackware 15.0 you’ll get appstream-glib, bubblewrap, gcab, libostree and xdg-desktop-portal-gtk to support Flatpak 1.12.0. For Slackware-current I can offer Flatpak 1.14.0 (latest release) and because it switched from requiring appstream-glib to appstream, the supporting packages on -current are: appstream, bubblewrap, libostree and xdg-desktop-portal-gtk.

Note that my ‘libostree‘ package is called ‘ostree‘ on, but the software changed its name and I am using the new name here.

My Flatpak package registers the FlatHub repository as a system-wide remote upon installation. It also creates a ‘flatpak‘ user (with the same UID and GID numbers as reserved but not yet used by SBo). Flatpak uses this as a system helper account.

Why Flatpak at all

All the rage nowadays is to containerize applications and distribute them in a “build once, run everywhere” fashion, pretty much isolated from the host Operating System and using kernel capabilities to interact with that OS.

One example of this is Docker. I have been providing Docker packages for a while and have written an article series about setting up your private cloud server using Docker. Docker is a framework to deliver server applications via containers and it does so quite well.

But to ‘containerize’ graphical desktop applications that interact with your Slackware desktop environment – adding a desktop menu item, allowing access to your local files, and play audio? That is a whole different ball-game. For this, you have the aforementioned solutions like Flatpak, Snap or AppImage. They all are conceptually similar but have different architectural design considerations.
I have no preference for either. Prior to researching Flatpak I had not used any of them. Picking Flatpak was driven by Slackware user request, simple as that.

Flatpak runs its apps in a secure virtual ‘sandbox’ which does not require root privileges. This mitigates potential security threats.
Like with AppImage or Snap, this sandbox environment contains everything that is required to run the software. This makes it possible to build a self-contained Flatpak application and then run it on any distro transparently.

If you want to know the internals of how Flatpak works, there is a nice article here: . Main takeaways are that Flatpak relies on OSTree as a system for versioning and distributing filesystem trees (inspired by how git maintains a repository of source code but then for binaries); Bubblewrap to allow unprivileged users to set up and run containers, using kernel features such as namespaces, bind mounts and seccomp rules, and Appstream to provide the infrastructure that allows application installers to interact with the OS in a well-defined manner.

Getting to know the commandline

Let’s play a bit with the commandline tool straight after installation and a logoff/login (or running ‘source /etc/profile.d/‘.

To get details of the already configured remote repositories, run the following command:
$ flatpak remotes -d
Name    Title   URL                          Collection ID Subset Filter Priority Options … … Homepage Icon
flathub Flathub -             -      -      1        system  … …
List available packages in a remote repository:
$ flatpak remote-ls | less
AuthPass    app.authpass.AuthPass       stable x86_64
BlueBubbles app.bluebubbles.BlueBubbles stable x86_64
Blurble     app.drey.Blurble            stable x86_64
Dialect     app.drey.Dialect            stable x86_64
EarTag      app.drey.EarTag             stable x86_64
KeyRack     app.drey.KeyRack            stable x86_64
Warp        app.drey.Warp               stable x86_64
Space       app.getspace.Space          stable x86_64
Lith        app.lith.Lith               stable x86_64
Will I get the same listing for my own user?
$ flatpak remote-ls --user

Actually, this command comes back empty. This is because Flatpak works in two modes: the default mode is to manage packages system-wide; but alternatively you can manage apps in your own homedirectory as well.
For Flatpak apps that are downloaded into your homedirectory location ‘~/.local/share/flatpak‘, you do not need any special privileges, you just need to add the commandline parameter “--user” to any flatpak command-line that you use.
For system-wide package installations which go into ‘/var/lib/flatpak/‘ you either run the flatpak commands as root, or else you will get a prompt to enter the root password prior to the actual download and installation.
The above listing is empty because I still need to enable the FlatHub repository for my own user (remember, the package registers that repository system-wide only).

Using flatpak as regular non-root user:

Let’s add the Flathub repository to your own user account so you can install and manage applications without the need for root’s password:

$ flatpak --user remote-add --if-not-exists flathub /etc/flatpak/remotes.d/flathub.flatpakrepo
Search for a package:
$ flatpak search minetest
Name   Description Application     ID                     Version Branch Remotes
Minet… Multiplayer infinite-world… net.minetest.Minetest  5.6.1   stable flathub
libre… a opensource tile game eng… ….celleron56.libretile 2.5     stable flathub

Sometimes when your terminal is not wide enough, it’s more readable to list only a subset of columns:

$ flatpak search minetest --columns=name,application
Name      Application ID
Minetest  net.minetest.Minetest
libretile io.gitlab.celleron56.libretile
Install a package from the flathub repository:

FlatHub is the default repo so you can omit the keyword ‘flathub‘ here, but suppose you have defined more than one repo…

$ flatpak list
$ flatpak install flathub Minetest
  <lots of activity...>
net.minetest.Minetest permissions:
    network     pulseaudio     x11    devices

$ flatpak list
Name        Application ID                 Version     Branch Installation
Minetest    net.minetest.Minetest          5.6.1       stable system
Freedesktop Pl… org.freedesktop.Platform   22.08  system
Mesa        …eedesktop.Platform.GL.default mesa-22.1.7 22.08  system
openh264    …freedesktop.Platform.openh264 2.1.0       2.2.0  system

As you see, not just Minetest got installed, but additionally some dependencies that were missing from my local Flatpak repository. One of the benefits of the underlying OSTree filesystem management is that a dependency which is requested by multiple apps, will only be downloaded and installed once.
Also worth pointing out that at the end of the ‘flatpak install‘ command, you’ll be notified about the permissions the app will require from your local OS and desktop environment. Minetest will want to use your network, play audio, run as a X11 graphical application and enumerate your peripherals. Remember that this is a sandboxed application, which will request these permissions outside the sandbox through kernel capabilities.

Where to go from here?

There are still kinks I have to resolve, which is why I uploaded the packages and wrote this blog article. I need your help.

I ran the above installation as my regular user and got more than 10 ‘policykit‘ popups prompting me for the root password. This is bad, and I need to find out how I can reduce this to only getting prompted once.

I can not find Minetest in my XFCE desktop menu, even though I see the file “/var/lib/flatpak/exports/share/applications/net.minetest.Minetest.desktop“. The question is: as far as I understand, appstream-glib is responsible for the desktop integration but it seems to fail. Or perhaps XFCE is not supported? In KDE Plasma5 on my slackware-current laptop an installed Flatpak app nicely integrates into the desktop menu.

And on my Slackware 15.0 machine I could not start Minetest as my regular user, and had to run it as root because of this error:

$ flatpak run net.minetest.Minetest
bwrap: Can't mount proc on /newroot/proc: Operation not permitted
error: ldconfig failed, exit status 256

There’s an old post on which suggests that my NFS mounts or a running RPC server could cause this, but I cannot stop NFS here. Other posts suggest that user namespaces are required to get rid of the error, but Slackware already has those enabled by default:

$ zcat /proc/config.gz | grep CONFIG_USER_NS

When first becoming root using ‘sudo -i‘ and then running “flatpak run net.minetest.Minetest” I can get the app to start properly except for this audio related error:

ERROR[Main]: Audio: Global Initialization: Failed to open device

Any insights are welcome of course. Please post them below in the comments section and if any changes need to be made to the SlackBuilds, that’s what I will do.

Discover on KDE Plasma

For users of the Plasma desktop environment, I have added discover to my repository. Discover is a software package management tool that is part of KDE Plasma, but Slackware does not ship the application because it has no support for Slackware repositories. However it does support Flatpak, if it is compiled while Flatpak is available on the system.
So that is what I did: I built a discover package with Flatpak support.

This is how Discover presents itself after already having installed Minetest via the commandline:

There is one thing which I think is worth investigating. Flatpak’s package management is not compatible with the Slackware tools like slackpkg or pkgtools. It would be nice to manage all your software centrally, and what do you know… Discover supports not only Flatpak as backend but also PackageKit. I wonder how well PackageKit’s own Slackware backend works these days, but finding out is very low on my TODO. I leave the exercise to you, the reader.

Happy hacking, and I love to hear your usage stories!


First package for Calibre6 in my repository

Not so very long after I was finally able to produce my first packages for Calibre 5.x, Kovid Goyal ended that development cycle and bumped his e-book management application’s major version number to “6” in order to make a switch from Qt5 to Qt6 as its graphical engine.

The main hurdle for me when the upgrade from Calibre 4.x to 5.x happened was that internally, Calibre switched from Python2 to Python3. Essentially the whole of Calibre is written in Python and it uses PyQt to build the graphical interface using Qt widgets.

It took me a lot of work to re-write the calibre.SlackBuild to also make that Python switch. After all, my single calibre package is actually getting built from many sources (44 tarballs for Calibre 4, 55 tarballs for Calibre 5) and a lot of those had to be replaced to work with Python3. Moving my calibre.SlackBuild to Python3 took so much effort that I decided to apply some simplification as well: I removed the script’s ability to build its own Qt5 libraries from source, instead I let my calibre-5.x packages depend on the qt5 package which is already present in the Slackware OS since release 15.0.
Naturally I was not looking forward to doing the same cumbersome and time-consuming exercise again, now having to figure out the intricacies of Qt6, a graphical toolkit I had never built or used before.

But I was bothered by the consequence that I had to stick with Calibre 5.44 being the final release using Qt5, and so I decided to take my time, and inbetween other activities I started gradually re-writing the calibre.SlackBuild script to encompass the new sources and get these compiled and tested.

Now then finally, you can install Calibre 6 on Slackware using a 170 MB large natively-built package which needs 64 source tarballs to compile You can get the new Calibre 6 packages from my repository or any mirror (like my own US mirror). No external dependencies, works out of the box on Slackware 15.0 or -current.

To refresh your memory in case you are still thinking “what the heck is he talking about” – Calibre is an e-book library management program which I started using after buying my first E-reader (a Sony TRS-T1) and discovering that the accompanying e-book management software was proprietary and not user-friendly. The functionality and ease-of-use of Calibre were so much better than the commercial software that I never looked back.
I now read my e-books on a Kobo Aura2 H2O . Adding books to the reader is dead-simple: Calibre exports my book library on the internet as a OPDS server that works with any e-reader that has Internet connectivity, and I can scroll through my library even when on vacation and pick a new book to read. The power of Open Source.

A note for those of you who are on a 32bit Slackware and are currently using my Calibre 5.x package. With Calibre 6 it is no longer needed to set the “QTWEBENGINE_CHROMIUM_FLAGS” variable to disable seccomp. Qt6 does not appear to have the issues that the embedded Chromium browser of Qt5 had.

I also checked that the application’s screenreader still works. Right-click the current page in your open e-book text and then click “Read Aloud“. The text-to-speech is provided by an embedded speech-dispatcher program.
This is great, but the downside of it is, that the default espeak voice sounds like Steve Hawking came to visit you. If you find out how to improve the text-to-speech capability of Calibre by adding voices (especially non-english) and playing with the various engines, please let me know in the comments section below. I really would like to improve the out-of-the-box TTS experience for people with visual disabilities or dyslexia.

Have fun! Eric

Ardour 7.0, Avidemux 2.8.1 and more cool stuff added to my repositories

A month full of interesting package updates in my Slackware package repositories. I have not blogged about them, because of a busy work schedule, but here are the highlights.
Note that you can subscribe your feedreader to my RSS feeds (regular and restricted) so that you never miss a package update!


With more than two years of development after 6.0 was released in May 2020, a new major update for Ardour was finally made available last week. Packages are available for 32bit and 64bit Slackware 15.0 and -current.
Ardour 7.0 comes with lots of new features, and Unfa goes in-depth in this YouTube video:


Avidemux 2.8.1 was released in September, and I missed the announcement. Fortunately I was alerted to it today by a Slackware user who commented on the blog. These packages are found in my restricted repository because they contain AAC encoder libraries, the code for which is patent-encumbered in the United States.

For the 32bit package I had to forcibly disable SSE support in the soundtouch library, if anyone comes across a patch that fixes the compilation error, let me know. I guess nobody runs test builds of Avidemux on a 32bit OS anymore.


I uploaded three consecutive updates for Chromium 106 (regular as well as un-googled) during the last month, did anyone notice?
As usual, any update to Chromium is a must-do, to eradicate any vulnerabilities that allow online hackers to own your computer. Again, subscribing to my repository’s RSS feed will alert you to updates immediately.


My four Docker related packages (runc, containerd, docker and docker-compose, you don’t need any other package) were also updated to their latest releases last week.
A note: I provide 32bit packages for Docker, even though that is supposed to not work. At least, it is not supported by the developers. I wonder, since I tested the 32bit packages and they actually do work (I can run 32bit containers on a 32bit host) is there anyone who uses these? Or should I skip 32bit builds of future Docker releases altogether? Let me know.


LibreOffice 7.4.2 was released last week and I uploaded a set of packages right before the weekend, so that you can enjoy the latest and greatest of this office suite on Slackware 15.0 and -current.

Note that I build these packages on Slackware 15.0 but also offer these same packages for installation on slackware-current. Since slackware-current ships newer (incompatible) versions of boost and icu4c, please also install boost-compat and icu4c-compat from my repository – these packages contain older versions of the boost and icu4c libraries and are a live-saver if you are running slackware-current. Note that this “compat” is not the same as “compat32” – which is the designation for the converted 32bit Slackware packages in my multilib package set!

OBS Studio

If you ever have a need for recording a live video using professional-grade software, Open Broadcaster Software released OBS Studio version 28.0.3 recently. If you want to broadcast a live stream of an event you are covering, OBS Studio plugs straight into Youtube, Facebook, Twitch or other streaming platforms. Packages are available for Slackware 15.0 and -current.


Also I had to update Calibre, FFMpeg and Audacity packages for Slackware-current, after the recent incompatible upgrades of Qt5 and FFMpeg in the OS.
If you wonder ‘why ffmpeg, it’s part of Slackware already‘ – my ffmpeg package has several codecs enabled that the stock Slackware version does not offer, particularly the package in my restricted repository.

Have fun! Eric

© 2024 Alien Pastures

Theme by Anders NorenUp ↑