My thoughts on Slackware, life and everything

Tag: ktown (Page 1 of 3)

Updated ‘ktown’ packages, and a heads-up

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!

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

Ktown becomes Vtown

So it is finally happening.
On US Election Day 2020, Pat Volkerding added “vtown” into the ‘testing’ directory of Slackware-current.

The “vtown” in Slackware is essentially my ‘ktown’ repository containing KDE Plasma5 plus its dependencies, with a few exceptions, a number of my packages removed, some caveats and a couple of renamed packages.

A lot of useful information from early adopters can already be found on linuxquestions.org in the dedicated thread about vtown.

One of the benefits of this testing version of Plasma5 in Slackware is the merging of several Slackware and ktown packages.
Mostly because I needed to provide Qt5-supporting versions of existing Slackware packages, I needed different names for the ‘ktown’ versions that I was going to provide. I could not risk that people would end up with old Slackware Qt4 based packages which would break Plasma5.
So to avoid clashing with packages like “plasma-nm”, “attica”, “baloo”, “kscreen” etc… I had to use alternative package names like “plasma5-nm”, “attica-framework”, “baloo5”, “kscreen2” and several (actually, many) more.
Here is the full list of my packages that got merged back into packages with the original Slackware names:

attica-framework -> attica
baloo5 -> baloo
baloo5-widgets -> baloo-widgets
grantlee-qt4 -> grantlee
kactivities-framework -> kactivities
kfilemetadata5 -> kfilemetadata
kscreen2 -> kscreen
libdbusmenu-gtk -> libdbusmenu (dropping Qt4 support)
libdbusmenu-qt5 -> libdbusmenu-qt
libkscreen2 -> libkscreen
phonon-qt4 -> phonon (dropping Qt4 support)
plasma5-nm -> plasma-nm
polkit-kde-framework -> polkit-kde-agent-1
polkit-qt5-1 -> polkit-qt-1

There’s also some packages that are new, but given a different name than I did for ‘ktown’: my “qtav” becomes “QtAV’, “phonon-gstreamer” becomes phonon-backend-gstreamer” and “sddm-qt5” becomes “sddm”.

Here’s a list of the packages that did not make it into ‘vtown’ at all:

ddcutil (nothing uses it anymore)
drumstick (only used by vmpk now, and that is not part of Slackware)
freecell-solver (needed by kpat)
kaudiocreator (obsoleted, use k3b or soundkonverter instead)
kblog (no longer included in Applications)
kdelibs (KDE4 - no longer relevant)
klettres (future maintenance will be in ktown, no external deps)
kpat (needs freecell-solver, maybe rename to kpatience if I keep maintaining it)
ktuberling (future maintenance will be in ktown, no external deps)
kwebkitpart (lost its relevance)
labplot (future maintenance will be in ktown, no external deps)
md4c (no longer needed, was a past dep for building qt5)
perl-path-tiny (dep for freecell-solver)
perl-template-toolkit (dep for freecell-solver)
phonon-qt4-gstreamer (obsoleted)
phonon-vlc (needs VLC and I will keep maintaining this in ktown)
python3-random2 (dep for freecell-solver)
sni-qt (nice to have for Qt4 apps with systray icon? Needs libdbusmenu-qt4 which will no longer be in Slackware)
user-manager (deprecated)

Now the big question: how to upgrade?

Assuming you use slackpkg to manage Slackware updates, first edit “/etc/slackpkg/slackpkg.conf and ensure that the line:

PRIORITY=( patches %PKGMAIN extra pasture testing )

is changed to:

PRIORITY=( testing patches %PKGMAIN extra pasture )

This gives higher priority to those new ‘vtown’ packages. Then run:

slackpkg update

The next steps depend on what you currently have installed.

Upgrade from Slackware’s KDE4 to the ‘vtown’ Plasma5 in Slackware’s testing:

That should be easy. If you still have KDE4 installed, run

slackpkg remove kde
slackpkg remove ConsoleKit2
slackpkg install vtown
slackpkg upgrade vtown

I have not tested those “slackpkg install vtown; slackpkg upgrade vtown” commands so if that does nothing, then instead, you need to download the whole testing/packages/vtown directory from an internet mirror and then run:

upgradepkg --install-new --reinstall testing/packages/vtown/deps/*.t?z
upgradepkg --install-new --reinstall testing/packages/vtown/kde/*.t?z

Upgrade safely from my ‘ktown’ to the ‘vtown’ in Slackware’s testing:

That is a good question! I am still running ‘ktown’ because due a medical emergency in the family I do not have enough free time to test this properly. People asked for a blog post so that’s about all I can manage and it has eaten most of today’s free time already unfortunately. Share your experiences in the comments section below and I will update the main article with better info as it becomes available.

What I think will work is this (assuming you are also using slackpkg+ to manage your 3rd party repositories) and thanks to akimmet who posted these instructions in another blog post after having gone through the upgrade himself:

slackpkg update
slackpkg upgrade-all
slackpkg remove ktown kde kdei ConsoleKit2

Now, edit “/etc/slackpkg/slackpkgplus.conf” to remove (or de-activate) all definitions of “ktown”, and instead add “testing:vtown” to your PKGS_PRIORITY list. Then run:

slackpkg update
slackpkg install vtown
slackpkg upgrade vtown
slackpkg install LibRaw autoconf-archive exiv2 poppler

The last line will re-install the few packages that were in my ‘ktown’ but also part of Slackware core. They were upgraded by Pat in Slackware core instead of in ‘vtown’ and thus the “slackpkg remove ktown” removed those permanently.

Remember: perform this upgrade from a console in runlevel 3!
Tell me how it went! Remember, this stuff is now in Slackware ‘testing’ not because the Plasma5 software sucks and crashes but because this means a big and intrusive update to Slackware and it is best to give way to the early adopters to find the remaining kinks in the new packages.

Eric

 

Ktown Plasma5 packages for Slackware 14.2 will go offline soon

Hi all,

As you know, my ‘ktown’ project, providing an extensive and functional Plasma5 package set for Slackware, is mostly targeting the Slackware ‘in-progress’ version called “Slackware-current”.

For a short while after an official stable Slackware release, I keep providing ‘ktown’ packages for the most recent stable Slackware version (which is 14.2 at the time of writing) but once the stable and development releases of Slackware start to diverge too much, I stop updating the Plasma5 packages for the stable release. After all, ‘ktown’ is meant to be the bleeding edge playground for a future Slackware release.

I recently noticed that people are still downloading and installing my ageing ‘ktown’ packages for Slackware 14.2. Those packages have not been touched since end of 2017, they may contain security holes, and they do not represent the state of development of the KDE software today.

Therefore I am giving you a heads-up that this weekend end of May 2020, I am going to remove all the old packages on ‘ktown’ for Slackware 14.2 (that’s https://slackware.nl/alien-kde/14.2/latest/).

If you want to run KDE Plasma5, you should migrate to Slackware-current.

Good luck! Eric

Python3 update in -current results in rebuilt Plasma5 packages in ktown

Pat decided to update the Python 3 to version 3.7.2. This update from 3.6 to 3.7 broke binary compatibility and a lot of packages needed to be rebuilt in -current. But you all saw the ChangeLog.txt entry of course.

In my ‘ktown’ repository with Plasma5 packages, the same needed to happen. I have uploaded a set of recompiled packages already, so you can safely upgrade to the latest -current as long as you also upgrade to the latest ‘ktown’. Kudos to Pat for giving me advance warning so I could already start recompiling my own stuff before he uploaded his packages.

A couple of good things came out of this effort.

  • I took a patch for the ‘sip’ package from its repository, which then allows for compiling the ‘PyQt’ 4.x package errorfree. This patch will be applied the next official sip release by Riverbank Computing, so then Slackware-current can finally also upgrade to the latest sip and PyQt versions.
  • I wrote a one-liner patch for QScintilla to make the PyQt4 part compile again. So now my QScintilla re-gained support for Qt4 next to Qt5.
  • I updated the ‘digikam’ package to DigiKam 6.0.0, a new major release after two years of development.

Have fun!

Eric

« Older posts

© 2026 Alien Pastures

Theme by Anders NorenUp ↑