Time for a KDE Plasma6 package refresh.
On KDE’s announcement page, the releases of KDE Gear 26.04.1 and Frameworks 6.26.0 were announced yesterday and today. Since OS packagers have early access to the source tarballs, I had everything compiled and ready for days and could simply push everything into my ‘ktown’ repository today.
I also updated okteta to the new release 0.26.27 (unfortunately still Qt5 based).
Get the new packages from https://slackware.nl/alien-kde/current/latest/ (NL), https://us.slackware.nl/alien-kde/current/latest/ (US), or https://slackware.uk/people/alien-kde/current/latest/ (UK).
Or use their rsync URI’s for commandline downloads.
And a heads-up:
I went to the spring conference of the NLUUG (the Dutch Unix User Group) yesterday . My old colleague (from 40 years ago) and friend Jeroen Baten gave a demonstration of setting up and configuring Forgejo. This is a software forge software which is stewarded by Codeberg e.V in Germany. A fully open source, constraint-free and European alternative to Github or Gitlab. Absolutely relevant given the current political climate where the Orange Clown and his Big Tech billionaire minions try to control the whole world from a US “me! me! me!” perspective.
That same conference also had a presentation from a Dutch government team that maintains their software on code.overheid.nl which is also running Forgejo. It’s really cool to see that finally the Dutch government acts (somewhat) on the commitment to favor open source and open standards above commercial and closed software.
It made me decide that Slackware software projects need a space for their code that is never in danger of being abused for AI training or where repositories are deleted and access revoked simply because the Orange Clown demands it. The final push to decide that I need to get my own projects off Github came recently when I read this: VS Code v1.117.0 automatically adds GitHub Copilot as your co-author.
My commitment: I am going to setup a Forgejo instance below the slackware.nl domain.
At first, I will work on getting the git repository server up and running with moderated creation of user accounts. Projects that can show a relevance for the Slackware Linux community will get an account. I will be using Keycloak for Identity and Access Management (IAM). Rather conveniently I already have a full setup guide in my Slackware Cloud Server series: https://blog.slackware.nl/slackware-cloud-server-series-episode-2-identity-and-access-management-iam/
The fun will not stop there. I also intend to allow runners and workloads on the Forgejo instance. That will give projects a chance to create CI/CD pipelines for their code. I will be offering Slackware 15.0 and -current Docker containers (64bit but also 32bit) for these runners and will also ensure that the Docker images are re-generated after a ChangeLog.txt update in the Slackware tree.
It’s a lot of ambition but this is something I really want to do. The process will likely end up as another article (or two) in the Slackware Cloud Server series.
I cannot give a timeline, it depends on the complexity of setting up the Docker infrastructure for the Forgejo runners. The git repository server with Keycloak should be rather straightforward. I’ll move my own projects from Github to Forgejo ASAP of course.
When I have updates you’ll hear it first on this blog!
That’s cool about Forgejo, and the less eggs in one basket, the better, as it were. I dumped VS Code for neovim and a lilypond plugin awhile ago when Microsoft was starting the AI push. I still might circle back to Frescobaldi via flatpak (little more insulated from current’s changes), but so far neovim is doing what I need.
Moving slackware bugs and issues off linux questions would ultimately be a good thing, IMO.
VSCodium is the un-branded version of VSCode, built from the same sources and without telemetry or AI.
Think of it as Chrome versus Chromium but then for the Visual Studio Code.
SlackBuilds.org has a binary re-packaging script for it.
Regarding Slackware bug/issue reporting – I do not think Pat or the coreteam are ready for that. We simply do not have the bandwidth to deal with all the issues in a formalized way.
Yeah, I used vscodium for awhile, but the lilypond plugins for it would break with every update. (And were unmaintained.) The neovim ones appear to be receiving bug fixes at least.
Bug reporting: I’d imagine the moderation, alone, would be a Herculean task…
Thank you – especially for the heads-up!
Hi Eric, tbh I have been using Forgejo for a while and when I looked at your git I didn’t like it much O:-) I salute this upcoming change.
My git service at git.slackware.nl is read-only of course. It uses cgit to add a web-based interface on top of the actual git server. It’s nice to look at a history of development but it is not meant for anything else.
Ah ok so it’s different from what you’re talking about in the post.
I don’t know what you are talking about. In the post I talk about a new (future) git service based on Forgejo. My current server at git.slackware.nl is totally unrelated and will also not disappear.
You can try to look on Andrew Clemon’s docker as reference if you need
https://github.com/aclemons/slackrepo-docker
I published my own set of Slackware Docker images years ago: https://hub.docker.com/r/liveslak/slackware
Built using this script: http://www.slackware.com/~alien/tools/docker/create_slackware_docker_image.sh
Just read this:
https://dustri.org/b/follow-up-to-carrot-disclosure-forgejo.html
Is it important?
It’s quite the shit show how this person thought to be really cool but is basically pissing off some committed volunteers. Worse is the arrogant stance with which he wrote the initial article (https://dustri.org/b/carrot-disclosure-forgejo.html) basically insulting a lot of people.
The exploit itself requires that your Forgejo instance offers open registration, which I will not be offering (you can request an account when you can show that your software is part of Slackware ecosystem). Plus, he managed an exploit on a Forgejo instance which he had installed on his own computer. Normally you do not have physical access to infrastructure.
This is open source software. The bugs will be fixed. I don’t know if you’re old enough to remember how the code quality of LibreOffice was when it was forked from OpenOffice. The effort of many people improved the quality a lot. What you should never do is open the window of your ivory tower and piss down on the peasants.
What, are you working for the government or Microsoft or something since you keep saying “cloud”? It sounds like that.. Try dropping that expression, it’s just a corporate buzzword used for marketing, try to replace it with concrete words with actual meaning, like servers..
Ah, another frustrated teenager with a gripe.
The word “cloud” is as old as fuck. Grow up.
Hi Eric, thanks! The ktown packages worked without apparent issues.
Wow… This automatic Copilot co-author thing is insane.
I’m totally in favor of anything allowing to get out of american services in the current context.
I am getting there slowly 🙂
Currently the Forgejo instance is running, it has a few users onboarded and a couple of repositories imported. I have an automated process to create Docker images for Slackware (triggered by ChangeLog.txt updates) and I am working on the git runners that can use these Docker images to build Slackware packages (as CI test or as actual releases).
Just for info, plasma-6.7.0 will require ‘corrosion’, as it’s a new mandatory dependency of ‘kdeplasma-addons-6.7.0’. It was also an optional dependency for ‘akonadi-search’, ‘angelfish’, and ‘kdepim-addons’. So far, I have a SlackBuild example here:
https://slackware.halpanet.org/gmgf/corrosion/src/
I thought I was pretty much up to speed with the new dependencies but apparently I missed ‘corrosion’, thanks for mentioning 🙂
I really hope that by then (halfway through June) Pat will have taken over ktown and added Plasma 6 to -current.
Yes, we’ll see, 😉
by Eric.
I forgot to ask you a question: for ‘timedated’, did you find out how to adapt it ?
thank 😉
No time for that, I just returned from holiday. Also, it is not yet time for Plasma 6.7.When that time approaches, I will have a look at it.
Ok, thanks 😉
Somehow I’m not receiving updates from your blog to my email any more…
Since about May 2025
Thu Jun 4 01:22:28 UTC 2026
l/qt6-6.11.1_20260508_bfde7b89-x86_64-1.txz: Upgraded.
Thanks to alienBOB for the 32-bit fixes!
Compiled against abseil-cpp-20260526.0.
This update to Slackware-current is causing kwin-wayland to segfault:
“segfault at 0 ip 00007f900ffb1935 sp 00007ffd51fb8b60 error 4 in libQt6Gui.so.6.11.1[3b0935,7f900fe8b000+7b7000] likely on CPU 0 (core 0, socket 0)”
This causes the Wayland session to end and return to the login screen.
Downgrading to qt6-6.10.3_20260330_6417867c-x86_64-4 corrects the problem.
As usual, with the caveat that this is happening on my machine. YMMV
Thanks
This is normal, a new version of qt requires recompilation (plasma-integration, layer-shell-qt, kwin, kwin-x11).
Please hold off the latest updates (specifically, do not upgrade to qt6 6.11) until after the coming weekend. I don’t have the time to rebuild all of ktown right now.
Thanks to both of you. I’ve blacklisted qt6-6.11 for the time being.
In the meantime, one may rebuild the relevant parts after a full update using Ktown’s source tree:
./kde.SlackBuild frameworks:kguiaddons
./kde.SlackBuild plasma:layer-shell-qt,plasma-integration,kwayland,knighttime,kdecoration,kwin,kwin-x11
(this was taken from Zhao’s advice in LQ).
That’s not going to solve all your issues. Best is to stick with qt6-6.10.3_20260330_6417867c-x86_64-4.txz which you can still find in the ‘cumulative’ archive if you already ran the upgrade to qt6 6.11: https://slackware.nl/cumulative/slackware64-current/slackware64/l/qt6-6.10.3_20260330_6417867c-x86_64-4.txz
And then wait until after the weekend.
That’s right, even with those rebuilds there are some apps that give me segfaults. Thanks Eric.
Finally, come back, in the ‘KDE Gear 26.04.2 Full Log Page’:
libkleo:
Require GpgME 1.24.2 instead of GpgME 2.0.
kleopatra:
Require GpgME 1.24.2 instead of GpgME 2.0.
That would be really strange.
QScintilla was removed from Slackware-current, will it be needed for Ktown? I remember that it was a dependency at some time, is that no longer the case?
Nothing depends on QScintilla anymore.
Hi, Eric, in the ‘kdeconnect-kde’ package the udev rules are in a bad directory, /usr/lib64/udev/, instead of, /lib 😉