Alien Pastures

My thoughts on Slackware, life and everything

Ktown updates: KDE Frameworks and Gear (PIM & Applications)

Today KDE Frameworks 6.22.0 were released, and yesterday we already saw new KDE Gear 25.12.1 tarballs.
Note – in ‘ktown’ you will find that KDE Gear packages are split over ‘kdepim’ and ‘applications’.

I built new packages for those new sources and now you can get the packages for 32bit and 64bit Slackware from the original server: https://slackware.nl/alien-kde/current/testing/ or else from one of its mirrors.
For US folk, this one already has all the new packages: https://us.slackware.nl/alien-kde/current/testing/ .

You can download the sources from https://slackware.nl/alien-kde/source/testing/ and if you want to track the changes in git, go visit https://git.slackware.nl/ktown/log/?h=6_26.01

Have fun! Eric

KDE Plasma 6_25.12 for Slackware-current

A couple of days ago, I promised to use my holiday to come up with packages for KDE Plasma6.
Today I finished compiling packages for 32bit and 64bit Slackware-current and uploaded a fresh package repository to my ‘ktown‘. The name seems to stick with people, even when it has not seen activity for two years, so I will keep calling it ‘ktown‘.

You will find these packages at the origin location: https://slackware.nl/alien-kde/current/testing/ together with an expansive README which will help you remove KDE Plasma5 from your Slackware-current computer and install the ‘ktown‘ version of KDE Plasma6 instead.

I just went through the process and this is the first time that I am actually running and using KDE Plasma6 on my production laptop:

I did not have to remove any kind of configuration from $HOME and merely had to delete a couple of obsoleted system tray elements.

I also switched to Wayland instead of X11 and to be honest, that is working better than expected and even better than the good old X11 session. For instance, suddenly I can play 4K video in VLC without stuttering. And the laptop’s  Synaptics touchpad was not found at all in the X11 session (must be a bug because I had been using it for 9 years in Slackware KDE)… while it works perfectly in the Wayland session.
The thing that I miss is the Latte Dock which was dropped from KDE Plasma. Having these MacOS-like ballooning application launcher icons floating at the bottom of my screen always impressed my friends, but it was also extremely powerful in the way I could manage my favorite applications. In Plasma6 I created an auto-hiding QuickLaunch panel at the bottom of the screen but it looks dull compared with the Latte Dock. Shame.

My intention is to keep this new Plasma6 package repository in a ‘testing‘ state as reflected in the repository URL. I expect that there’s stuff that does not work as it should and I would like you all to help in testing and stabilizing the packages. When KDE Gear 26.04 releases in April 2026 I expect that the few remaining Qt5 based KDE applications will finally have been ported to Qt6. By that time, I want to promote the repository from ‘testing‘ to ‘latest‘ and that will then reflect in the repository URL.

If you would look at the content behind the ‘latest‘ repository right now (https://slackware.nl/alien-kde/current/latest/) you will see that it is pointing to a single left-over package for KDE Plasma5 (Slackware 15.0): ‘phonon-vlc‘, a backend for Phonon that requires VLC media player. By the way, I renamed that package to ‘phonon-backend-vlc‘ for Plasma6 to be in line with the Slackware naming convention for these backends.
In April 2026 that repository will get a new  ‘stable’ URL to reflect that it is meant for the stable release of Slackware.

If you want to peek at the source code management, I track everything in a git repository. You will find the 6_25.12 branch at: https://git.slackware.nl/ktown/
A word of thanks to LuckyCyborg who maintained a fork of my ‘ktown‘ during 2024/2025. He never contacted me about this but I was made aware of his activities. I checked out his scripts last week and there were some improvements he came up with that I have incorporated into my own sources. See the git commit message for more details.

I suggest that you try these Plasma6 packages out yourselves! Please leave your feedback in the comments section below.

Enjoy the end-of-year festivities and all the best for 2026! Let’s hope that Slackware merges Plasma6 before the end of 2026.
Cheers, Eric

Enjoy the holidays!

We’re at that unique time of the year that I can work on something that is not trivial and requires long-term focus to succeed.
The festive season is upon us all, which means (not counting family diners and birthday parties) that I have two weeks to revisit all those ideas and plans I cooked up in 2025 and finish as many of them as possible. Otherwise it’s simply waiting for the next Christmas holiday to continue.

 

So what’s brewing in December 2025? To start with, a lot of paint jobs here in the house that are waiting since May when we finished going through a home renovation.

But I am also working on the resurrection of KDE Plasma6 for Slackware-current. Two years ago after releasing a Beta version of Plasma6 as a live ISO image, life took another turn and Plasma6 moved to the TODO list. I wrote about that period on some occasions.
But I think (or at least hope) that having a Plasma6 ktown out in the open and available for testing, will nudge Patrick into merging this into Slackware-current eventually. I’d rather have him focus on the other stuff that blocks a release, since I’ve shown and proven that I can maintain a ‘ktown’ out-of-tree.
Patrick and I discussed it, he sounds interested, not saying it is going to happen, but no risk, no reward, right? I promised that I would maintain a Plasma6 ktown during 2026 but not after. I got burnt with Plasma5 years ago, not going to repeat that. Ideally i’ll keep it going until that time that Plasma6 replaces the ageing Plasma5 in -current in 2026. And if it does not happen, someone else can copy my ‘ktown’ sources and continue from there.

I have a working Plasma6 and I’m now fine-tuning the scripts (I want everything to be built correctly, using the right dependencies) and will update my server’s ‘ktown’ package and source repository and also the git repository on https://git.slackware.nl/ktown once I am satisfied with the results.

Until that time, all you get is a screenshot.

Enjoy the holidays! Be safe and be there for your family and friends.

Eric

Building Chromium for Slackware (contd.)

It’s been ‘fun’ compiling the newest Cheomium 143 sources… as usual when Google updates the major version number.
Again, it is momentarily not possible to compile the Chromium sources using Slackware’s own compilers. I get a Rust error “error: extern blocks must be unsafe” in compiling ‘liballoc_error_handler_impl_ffi.rlib‘. which I have been unable to fix – my knowledge of the Rust programming language is non-existent.
Which is why I could only upload the 64bit packages for chromium and chromium-ungoogled; Google only offers a 64bit version of the heavily patched clang and rust compilers they use internally to compile Chrome. A 32bit package will only become available after I found a fix for the Rust error.
Also, I had to apply some hacks in order to deal with the need for a newer Python than the 3.9 which is part of Slackware 15.0. I already have a successful patch for another part of the code where Python 3.9 was too old (the pipe union operator ‘|’ was added in Python 3.10) but due to time constraints I could not examine the new code and instead added a Python 3.12 binary in parallel.

This means you currently cannot simply run the SlackBuild on Slackware 15.0; you have to add a Python 3.12 package (I compiled a package from the sources I took from from Slackware-current) and point the ‘/usr/bin/python‘ symlink to python3.12. I hope to have fixed that requirement in the next batch of chromium packages.

Building Chromium for Slackware

I thought it would be helpful, and in any case insightful, to describe how I build the Chromium (also -ungoogled) packages for Slackware.

It is not a trivial task but a necessary one I believe. Slackware users should have a choice of browsers – some prefer Mozilla Firefox, others Google Chrome, and then there’s LibreWolf and Chromium that are built on the same code base as respectively Firefox and Chrome. There are others too, but I decided to stick with packages for Librewolf  and Chromium (-ungoogled). This article will focus on Chromium because Librewolf is pretty trivial to compile into a package.

Google develops the Chromium source code using tools which it partly created and maintains itself and for another part extends and patches them from the originals. Most notorious are the heavily customized Clang and Rust compilers used inside Google. The Chromium code reflects those compiler customizations because its codebase contains sections that will fail to compile using the official releases from the LLVM Project and the Rust Team (on which Slackware bases its own llvm and rust packages).

Google formally stopped supporting 32bit releases for their binary distribution of Chrome as long ago as 2015 (that’s ten years ago!) but indicated that the Chromium source code would still be compilable on 32bit platforms. Over time it became clear that internal code reviews and checks only happen on 64bit OS-es and the 32bit compatibility has been susceptible to “code-rot” ever since. As evidenced in my SlackBuild script where more and more patches and code modifications have been added to keep the ability to compile Chromium sourcecode into 32bit binaries.

Google provides binary snapshots of their internally used versions of Clang and Rust which reduces the need for patches a lot. Unfortunately Google at some point in time stopped providing 32bit binaries and so these binaries are nowadays only provided for 64bit machine architectures. In the past I relied on these binary snapshots to compile Chromium for Slackware.
After Google stopped providing those 32bit binaries, I have been putting a lot of effort in making Chromium compilable using the Slackware stock Clang and Rust compilers.

Note: I compile Chromium and Chromium-ungoogled on Slackware 15.0 and make these packages available in repositories for both Slackware 15.0 and -current. The challenge with Slackware 15 is that the provided llvm and rust compiler packages are way too old to be able to compile Chromium. Therefore Patrick Volkerding provides newer llvm and rust packages in the ‘extra’ section of the Slackware 15.0 repository. From time to time I run into new issues with clang and upon request, Patrick then builds and uploads a newer version of llvm into the repository.

Let’s have a look at the required updates for a Slackware 15.0 system (Slackware-current is up-to-date on all these package versions):

  • nodejs >= 20.13.0
  • llvm >= 21
  • rust >= 1.88.0
  • nasm >= 2.14
  • cmake >= 3.30.1

Some of these updates for Slackware 15.0 are in my own package repository (cmake, nodejs, nasm), some others in the ‘extra’ section of the official Slackware 15.0 package tree (llvm and rust).

When these updates are applied to Slackware 15, or in case you are running Slackware-current, compiling a Chromium package is simply:

# ./chromium.SlackBuild

… and compiling Chromium-ungoogled needs this commandline:

# USE_UNGOOGLED=1 ./chromium.SlackBuild

Note: you will need an enormous amount of RAM and lots of free disk space (in the filesystem which $TMP is pointing to) to run this build successfully, and then a lot of patience for that build to complete (my QEMU virtual machine needs about 12 hours to complete this build – per package).

From time to time, usually when the major version number of Chromium makes a jump, the source code has been modified to such an extent that the Slackware compilers will fail to build the binaries successfully. In that case (and if you are creating a 64bit package) you can force the SlackBuild to download and use Google’s binary clang and rust compiler snapshots using this commandline:

# BUILD_CLANG=1 ./chromium.SlackBuild

# BUILD_CLANG=1 USE_UNGOOGLED=1 ./chromium.SlackBuild

Usually this way the compilation will be successful.

Attribution:
Next to the Arch Linux PKGBUILD maintainer for Chromium, I depend more and more on the unparalleled knowledge of the NixOS package maintainers, to find the proper patches for my SlackBuild.
I would have been forced to drop the 32bit package support a long time ago if it were not for emilylange and networkException (NixOS) and Christian Heusel and Evangelos Foutras (Arch Linux).

I hope this article gave some insight into the life of a package maintainer.

Cheers, Eric

« Older posts

© 2026 Alien Pastures

Theme by Anders NorenUp ↑