My thoughts on Slackware, life and everything

Month: March 2022

Chromium 99 critical security fix, upgrade asap

I have uploaded new chromium 99 packages for Slackware. The chromium-ungoogled 99 packages are currently being built and will follow shortly.
These new packages were triggered by a recent Google Chromium update which mentions a fix for a security hole which allows remote attackers to take control of your computer. Opening a malicious advertisement or web page is already sufficient, the vulnerability does not need any interaction to do its work. See CVE-2022-0971.

Get my Chromium packages for version 99.0.4844.74 from my repository or any mirror, and upgrade to these as soon as you can: or

Links to the un-googled chromium: or .

These packages work on Slackware 14.2 and newer, 32bit as well as 64bit variants still of course.

On 32bit Slackware 15.0 and newer, Patrick has updated the profile script as part of a qt5 package upgrade so that Chromium crashes are prevented by automatically disabling the seccomp filter sandbox:

# Unfortunately Chromium and derived projects (including QtWebEngine) seem
# to be suffering some bitrot when it comes to 32-bit support, so we are
# forced to disable the seccomp filter sandbox on 32-bit or else all of these
# applications crash. If anyone has a patch that gets these things running on
# 32-bit without this workaround, please let volkerdi or alienBOB know, or
# post your solution on LQ. Thanks. :-)
if file /bin/cat | grep -wq 32-bit ; then
  export QTWEBENGINE_CHROMIUM_FLAGS="--disable-seccomp-filter-sandbox"


Calibre 5.x available for Slackware 15.0 and -current (finally)

Finally! I have a working package for Calibre 5.38.0, targeting Slackware 15.0 and -current.

As you surely know by now, Calibre is an e-book library management program, probably the best you can get and it surpasses its commercial rivals in terms of feature set and ease of use.

Calibre is not only a library manager, it can act as a content server to make your book library accessible online (on your phone and in web browsers for instance), and it also contains a Qt5-based e-book reader application, as well as a full-fledged e-book editor. If you have online magazine or newspaper subscriptions, Calibre can download these magazines automatically for you and add them to your library.

It is also quite the complex piece of software. It is written in Python, using several modules to enable its features. Calibre creates its graphical user interface using PyQt5 widget libraries. My calibre package for Slackware embeds all these modules, so that the package does not have any external dependencies. It does expect a full Slackware installation however, because that includes Qt5, PyQt5 and related packages. You could slim down your Slackware as long as you keep Qt5 related packages installed.

It took a long time to upgrade my Calibre 4.x package to 5.x, the first release in the 5.x series was on 25 September 2020. The reason is that the developer, Kovid Goyal, switched Calibre from Python 2 to Python3 and that influenced many of the Python modules that are used by the program. I had decided to wait for a Slackware 15.0 release to start working on the calibre.SlackBuild… but then that Slackware 15.0 release got delayed, and delayed, and… I could finally free up some of my time to actually do this, last week.

So here it is: Calibre 5.38.0, get it from my repository or any mirror (like my own US mirror)!

Note that you should either install my calibre4 package, or calibre (now at 5.x) but do not install both at the same time! Their files overlap.

Another note: on 32bit Slackware 15.0 and -current, all Chromium based programs will crash with a seccomp error. This is caused by the changes in glibc with regard to secure computing (seccomp), and the affected versions of glibc can be found in Slackware 15.0 and newer. The Chromium developers have been unable to update their sourcecode to make this work on 32bit Operating Systems. As a result, for instance Falkon on 32bit Slackware 15.0 and newer will crash immediately on startup.
The workaround is to disable the seccomp filter sandbox for your 32bit OS. This is achieved without much effort, you have to make an environment variable available after login: QTWEBENGINE_CHROMIUM_FLAGS needs to be set to “--disable-seccomp-filter-sandbox“.

For bash-compatible shells you would do as follows:

# echo "export QTWEBENGINE_CHROMIUM_FLAGS='--disable-seccomp-filter-sandbox'" > /etc/profile.d/
# chmod +x /etc/profile.d/

And after logging in again, you should find that calibre works also on 32bit Slackware.

Addendum: even the screenreader 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. Unfortunately the configuration button does not work there, but if you don’t like the default espeak voice you can manually pick one of the available alternatives by editing the file “/usr/lib64/calibre/etc/speech-dispatcher/speechd.conf” (on 32bit Slackware the libdir is ‘lib‘ of course).

Have fun! Eric

Calibre 5.x – I can’t create a working package

Calibre is my favorite e-book library management program. My repository contains a package for Calibre 4.x which works well, but it is using Python2 and has been superseded since September 2020 by the new 5.x releases which are based on Python3.
I have been postponing the Slackware package migration from 4.x to 5.x until Slackware 15.0 would be released, since the move from Python 2 to 3 promised to be a significant effort in terms of changing the calibre.SlackBuild script.

Now that Slackware 15.0 is available, I decided to pick up this chore and re-write the build script to support Calibre 5.x. The re-write took several days because of all the new Python modules that are now required by Calibre 5.
I have dropped support for embedding a copy of the Qt5 libraries and compiling an embedded Python interpreter is no longer optional. It simplified the script and reduced the compile-time a lot (no more Qt5 compilation).

Now the bad part. I have been trying to compile Calibre 5.38 on Slackware 15.0 now for the past week. Well, compiling is OK, and the ebook viewer and editor work properly. But the main calibre program crashes with an error “free(): invalid pointer” as soon as it tries to create a new (or read an existing) Calibre database (metadata.db). As a consequence, the Calibre library maintenance program is completely useless.
I have not found a cause for that, and unfortunately the Calibre developer refuses to discuss any bug that is not in his own pre-built binaries.

So I am between a rock and a hard place. I have no idea how to proceed from here, and I am not willing to add a non-functional package to my repository. So I have uploaded my work here:

If anyone wants to try this out and finds the cause of the crash bug, please share your thoughts here.

Thanks, Eric or

I am considering an additional article to my Slackware Cloud Server series.

As I showed in that series, a Nextcloud server can be equipped with capable text, voice and video communication apps but they are self-contained. The Jitsi Meet stack contains an internal XMPP communication server and Nextcloud collabration apps can only connect to user accounts on other Nextcloud server instances (through a process called federation).
What if you wanted to collaborate with people on other networks, say, other clouds? In the past I would be quick to point to XMPP server solutions like Jabber but those seem to be disappearing. Two popular platforms exist which use completely different protocols: is built on top of its own Matrix open standard and is built with the Meteor JavaScript platform. These two also use federation to connect to other instances of their own product but on top of that, these servers offer bridges to a whole lot of other communication platforms, such as Teams, WhatsApp, IRC, Slack etc.

How well do these two integrate with Nextcloud? On my own cloud server (based on the Nextcloud platform) I installed Element for Nextcloud, which is an app to use the web client called Element (formerly Element can connect to existing servers out there, or you can setup a Matrix server yourself.
And then there is an alpha-quality app to integrate into Nextcloud but it is not advised to install that on anything else than a testing environment.
Worth mentioning: both and offer seamless integration of the Jitsi collaboration platform which is also covered in great detail in my article series.

I am happy with the Element app on Nextcloud, it allows me to talk to people in the Slackware Matrix room but also to connect to the Libera.Chat IRC network through a Matrix bridge. I did not try setting up my own homeserver yet. I was wondering whether I should do that eventually because as you can see in the Element configuration dialog on Nextcloud, you can make Element use your own private Jitsi service as well.
That would be an interesting extension of the capabilities of our own private Slackware Cloud Server!

But then I read the article about Nextcloud and intensifying their collaboration to provide a deeper level of integration. This would for instance mean that during your Rocket.Chat conversations you will be able to access the data you store on your Nextcloud account. That would definitely bring a lot of added value to our Slackware Cloud server!

But since is a commercial offering using an Open Source service, I also have been investigating whether there are differences between the ‘community’ open source version of and the commercial subscriptions. There are of course features like redundancy, advanced monitoring and such that you need to pay for, but lacking that on a self-hosted service is not so relevant.

I found a few controversies that I think may be relevant for self-hosted instances.

One is the fact that role and group mapping to and group sync with identity services (like our Keycloak server) are removed from the community server version as of 4.0 and became closed-source. See this article by fairchat for more detail.

The other is the artificial limit on push notifications. There’s some unproductive interactions between open source users/admins and the support team (1, 2, ) about the requirement to register your self-hosted instance in order to use push notifications and about the subjectively low limit to the amount of notifications per day. Actually there is a good reason for limiting these notifications – has millions of users and the company runs a global infrastructure to allow users to communicate with other platforms – the push gateway is what all the clients connect to.
Community users don’t have to pay for using the gateway but are rate-limited as a consequence of that. It still sucks if you miss most of your notifications about new messages.

It is not trivial to setup your own push gateway: for mobile users (Apple and Google platforms) you’ll have to recompile the client and in the worst case you’ll have to pay Apple and Google for adding your custom client to their App Store. Seems like a bad architecture design to me. There is however at least one solution that may work, which you can host yourself and which does not need a custom-built mobile client app: this push gateway.

So dear readers… with all that background information on the table, what are your views with regard to and Do you prefer one over the other? Is there a reason to avoid one or the other? Do you have a need for an article here that describes the setup of one or the other?

Let me know – below in the comments section. Don’t hold back. I want to be informed with as much detail as you can give. Really wondering whether this will be a “vi versus emacs” type of discussion.


© 2024 Alien Pastures

Theme by Anders NorenUp ↑