Tag Archives: ktown

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!


Rebuilt packages for Plasma5 (ktown)

The updates in Slackware-current this week (icu4c, poppler, libical) broke many programs in my Plasma5 ‘ktown’ repository, to the extent that the complete Plasma 5 desktop would no longer start.

That is the fun of using the bleeding edge – if something disruptive happens in slackware-current you’ll have to wait for the 3rd party repositories to catch up. And I am one of those 3rd party packagers.

I have researched the list of packages that needed a recompilation, and in some cases I performed an upgrade at the same time (qt5 went up to 5.9.3, poppler synced to the 0.62.0 in Slackware-current, qtav went up to 1.12.0). The 64bit packages have already been uploaded but if you are running 32bit Slackware-current (why are you doing that?) you’ll have to wait another day because I just started the compilation there.

What has been updated in the ‘ktown’ repository? Here is a list, mostly in order of compilation:


Every package in kdepim? Well yeah, there were many broken packages and it was simply faster to recompile all of kdepim and be done with it.

Users of slackpkg+ will be up & running fast with these updates; the others probably just need to download the individual packages I listed above from a mirror like https://slackware.nl/alien-kde/current/latest/.

When the 32bit package set has been finished The 32bit packages have now been recompiled and uploaded to the repository.

I will also recompile whatever is needed in the ‘testing’ repository (that’s where the Wayland related packages are stored).

Other – not related to Plasma5 – updates/rebuilds are coming soon have finally been uploaded too. Those are LibreOffice, Pale Moon, Calibre; these programs are also affected by the updates in slackware-current but the urgency was lower than with the Plasma5 desktop.

Poll: who needs 32bit packages for latest Plasma 5?

During the past week I have been spending time on getting the latest KDE Frameworks, Plasma and Applications built. The new Applications 16.12 was quite a bit of work due to the splitting of tarballs in many smaller ones. Also, the Slackware 14.2 and -current versions have now diverged sufficiently that the packages I compile on 14.2 are no longer guaranteed to work on -current, so that introduces additional work.

This effort took much longer than I am comfortable with. I do not have as much time available as I used to have due to “real life” – meaning my new job is quite a bit more demanding than my previous one.
This made it clear to me that I have to start making decisions about my Slackware activities, with more detail than what I said in the past along the lines of “updates may come less frequent”. It is obvious that I can not keep releasing a new set of ‘ktown‘ packages every month, for both 32bit and 64bit platforms, and for both Slackware 14.2 and -current. I have a few options:

  1. stop releasing 32bit packages for Plasma 5 (ktown repository)
  2. stop releasing Plasma 5 for Slackware 14.2 and start focusing on -current exclusively

I tend to lean into option (1) and therefore wrote this blog post. Who is using my Plasma5 (ktown) packages on a 32bit Slackware OS?

If there are users running a 32bit Slackware-current OS then this could mean a stop to new Plasma5 releases for Slackware 14.2. Updates to the graphical desktop does not have priority at this time in the development cycle of Slackware-current which means I will have to keep maintaining my ‘ktown’ repository for a while to come.

Bottomline: I will have to make one of the two above choices, and I will listen to you – the users of my packages – to help me make that decision.

Ktown for Slackware – development history available in git

kde4 For a long time I have been keeping copies of the full source directories for every KDE 4 release I have made for Slackware. That is amounting to a lot of megabytes, since I am also keeping the source tarballs, not just the scripts and patches. Traditionally, I have kept one KDE version publicly available for all recent Slackware releases, in my ‘ktown’ package repository at http://alien.slackbook.org/ktown/ . This repository is also available through rsync, not just http (using my primary mirror at rsync://taper.alienbase.nl/mirrors/alien-kde/).

But what was missing (because I am lazy) is a git interface. Now, you could argue that accessing the ktown scripts and patches through git is somewhat pointless, since you would either want the packages (through direct download or using slackpkg+) or the full sources (inclusing the source tarballs, not just the scripts) and the git interface I intend would not be offering that.

However,  with the advance of KDE 5, it starts making sense to use git: primarily for version control and history keeping.

The old KDE 4 releases were self-contained: all sources would be released at the same time, so that I could simply create a toplevel directory of, say, “4.14.3” and put everything that I needed to compile the packages below that directory. Easy-peasy. KDE 5 on the other hand, has abandoned the big coördinated release effort. Instead, the releases are now done for subsets of the Software Collection (old name, no longer used). You’ll find separate uncoördinated releases for the KDE Frameworks, Plasma and the Applications. Of course these are all dependent on each other and require specific  versions to work together, but there is no longer something like a “KDE 5.2.0”.

You saw in my initial release of KDE 5 packages that I simply named the toplevel directory “5”, i.e. without minor numbers. My plan for the future is to stick to that number until Frameworks and Plasma move away from 5.x. Inside the “5” directory you will see future partial updates: whenever new Frameworks, Plasma and Applications tarballs are released, I will update one or more of these at the same time, but not necessarily all of them at the same time.

This poses a problem for my internal version control. Copying directory trees every time I refresh a subsection, will create a big mess with greater risk of not being able to go back to a previous point in time, in particular for the “deps” packages but I also see a risk of not being able to retrace working combinations of Frameworks, Plasma and Applications.

Therefore I have decided to move my ktown sources and scripts into a git repository. What I did, was take every final increment of every KDE release since KDE 4.6 for which I have ever created packages, and build a git version control history using those sources. The git repository has a master branch which will be the release which I consider most recent and stable. At the moment, that is 4.14.3. Every release will have its own branch too. There are branches for 4.6.5, 4.7.4, 4.8.4, 4.9.5, 4.10.5, 4.11.5, 4.12.5, 4.13.3, 4.14.3 and 5 at the moment, and you’ll find them here:


I think this will work best for future development on KDE. Currently, the patches in there are mostly gzipped, since this is what Slackware wants, but I am thinking about creating “unzipped” branches for recent releases, so that it will be easier to peek into the patches.

Any feedback, tips etc, let me know.


Edit – Tue Dec 23 12:26:25 UTC 2014:

I have added a cgit interface as well: http://taper.alienbase.nl/cgit/ktown/

Two rebuilt KDE packages.

kde44For your information:

I had to rebuild two packages for users of my KDE 4.11.2 on Slackware-current.Both are packages that are being used by a lot of people so I did not want to wait for the next release of KDE (scheduled for November 5th).

  1. ark: this package was broken after the update of the ‘libarchive’ package in Slackware-current
  2. calligra: actually I did not have calligra as part of my KDE 4.11.2 set. However it turns out that the new ‘marble’ package of KDE 4.11.2 breaks Calligra Words! Therefore I have added a rebuilt Calligra 2.7.3 to my KDE 4.11.2 set (the same package as you’ll find in Slackware-current… only this time with a working Calligra Words).

Get them from any of my ‘ktown’ mirrors: