Earlier last week Google released 108.0.5359.71. On friday, I had finally built and uploaded Slackware packages for this, when they released a quick fix to plug an already actively exploited hole (CVE-2022-4262).
The intermediate release took me by surprise. Luckily someone alerted me to the security fix in the comments section of my previous post. I grabbed the new source tarballs and built 108.0.5359.94 in the course of the weekend.
And I have now uploaded new packages both for chromium and chromium-ungoogled. Target OS releases are Slackware 14.2 and higher (32bit and 64bit).
I will stop releasing Chromium packages for Slackware 14.2 after February 2nd, 2023. On that day, Slackware 15.0 is one year old and I expect that everybody who uses a graphical desktop on Slackware, will have upgraded from Slackware 14.2 to 15.0 during that year. If you did upgrade yet but still want to use my Chromium browser packages, you still have two months’ time to prepare and execute that upgrade.
Chromium packages for Slackware 15.0 and -current will of course keep coming.
Around the last weekend I worked on several package updates. In the meantime I had to battle home infrastructure breakdown, as well as the realization that I had inadvertantly opened up my SMTP server as an open relay and had to do some fast infrastructure redesign 🙁
Chromium, regular and ungoogled.
There was a new release at the end of last week. The Chromium 107.0.5304.121 release fixes a security issue for which an exploit already exists in the wild (CVE-2022-4135).
I provide packages for this release both for chromium and chromium-ungoogled. Target OS releases are Slackware 14.2 and higher (32bit and 64bit).
The latest release of LibreOffice ‘fresh’ is 7.4.3. This is an incremental bugfix release.
I provide packages for this release, targeting Slackware 15.0 and newer.
Note that my libreoffice package depends on openjdk11 (see below). If you are running slackware-current instead of 15.0, you will additionally need boost-compat and icu4c-compat packages to provide the libraries that are no longer present in -current.
Oracle released its quarterly update to the Java source code release affecting both JDK 8 and JDK 11.
Andrew Hughes provides an updated icedtea release to be able to compile OpenJDK 8 update 352 build 08. My openjdk package targets Slackware 14.2 and newer.
And for the OpenJDK 11.0.17_8 (aka the 11.0.17 General Availability release) update I provide an openjdk11 package which targets Slackware 15.0 and newer.
Here’s LibreOffice 7.4.3.
My Slackware packages (targeting the 15.0 and -current releases) are available from slackware.com, my own slackware.nl or any mirror (wait a bit to get the packages synced over there).
Friendly reminder: These packages depend on openjdk11. On -current, please also install boost-compat and icu4c-compat to get back the older libraries that are part of Slackware 15.0 but not found in -current.
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 SlackBuilds.org 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 SlackBuilds.org, 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: https://docs.flatpak.org/en/latest/under-the-hood.html . 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/flatpack.sh‘.
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 https://dl.flathub.org/repo/ - - - 1 system … … https://flathub.org/ https://dl.flathub.org/repo/logo.svg
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 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
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...>
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.2.1 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 LQ.org 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:
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!
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
Dear visitor, you seem to be using an Ad Blocker. Please consider whitelisting 'Alien Pastures'. I use the revenue from displaying ads (small as it is) to keep this site running. Thanks!