My thoughts on Slackware, life and everything

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 . This repository is also available through rsync, not just http (using my primary mirror at rsync://

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:


  1. Ryan P.C. McQuen

    This is great news Eric! I use git every day (for work and home) and find it invaluable.

    Hopefully Pat will move the Slackware tree to git versioning at some point as well (I know there is already an unofficial one). 😉

    Thanks for all your work!

  2. Michelino

    No tips…but compliments!
    Thank you really much.

  3. Willy Sudiarto Raharjo

    It would be nice to have cgit interface as well, since it’s simpler and easier to navigate through history

  4. Oleg

    Greate news!
    Will wait for binaries and/or instructions for building all packages.

  5. Deny Dias

    The storage overhead for such big projects like KDE is definitively something to take into account. Why not publish all your git tree to GitHub and free yourself and your server of this storage hungry bits?

    Just asking, though.

    Aside from this question, +1 to Michelino’s comment.

  6. alienbob

    Deny Dias,

    Since I do not trust anyone with my own stuff, I host it all myself.
    In addition, I think github’s web interface is absolutely horrible.

  7. alienbob

    Willy, I would like to configure cgit properly, unfortunately I have some issues with it.
    See – all it shows is one branch, not a list of all available ones like gitweb does, and the luacrypto module does not load because of “t/usr/lib/lua/5.1/ undefined symbol: luaL_prepbuffer” even though I compiled lua and luacrypto from source today, using the SBo scripts.

  8. Deny Dias


    Roger that. 100% understood and supported.

  9. grissiom

    Good news for KDE5!

    But Git perform poorly in tracing binary data since it use “snapshots” to track files. So an unzipped tree is reasonable.

    Also, one big advantage of rsync is I can sync part of the tree, say, only the -current. In git, I have no choice but clone the whole tree with all the branches. However, this is not a big deal if the diff between branches is small(so extra branches won’t consume much storage space).

  10. Niki Kovacs

    Why does this somehow remind me of Pat’s reason to drop GNOME? Here’s what he wrote in the ChangeLog back in 2005: “GNOME is and always has been a moving target (even the “stable” releases usually aren’t quite ready yet) that really does demand a team to keep up on all the changes (…)”.

  11. alienbob

    Yes Niki, KDE 5 adds a maintenance burden.
    And grissiom, I have added a git repository as an extra. The directory trees and the rsync access are staying!
    The git repository is purely for version control.

  12. Andrew Poltavets

    My thanks!
    Sorry for newbie question:
    How can I upgrade from 4.14.3 to SC 5?
    I am confused because there are 3 dirs:
    frameworks, plasma, plasma-extra.
    So, where I can to run upgradepkg and for what packages?

  13. alienbob

    Andrew, please read an older post of mine, for the information you are missing.
    These KDE 5 packages are not meant to be used by themselves. KDE 5 (at least the set of packages I created a couple of months ago) is not self-contained and matured. The presence of a KDE 4.14 installation is required or else you’ll have an almost nonfunctional Plasma 5 desktop.

  14. Willy Sudiarto Raharjo


    it seems that you have solved the branch problem

    anyway, here’s my global cgitrc configuration for your preferences


  15. alienbob

    Hi Willy

    The problems with the page display was this line, which I also wanted to use:


    When I have that enabled, my apache log shows the error “/usr/lib/lua/5.1/ undefined symbol: luaL_prepbuffer” and the web page stops loading at the point where the first gravatar should be displayes (the luacrypto error crashes the script). When I disabled that line in cgitrc everything went back to normal but now I do not have a display of gravatars.
    Strange though, because I built lua, luacrypto and lua-md5 using the SBo scripts and I know it is working on the SBo server.

  16. Willy Sudiarto Raharjo


    Do you have lua5.2 installed on that machine?
    it is supposed to be lua (5.1)

  17. alienbob

    I have these installed:


  18. Willy Sudiarto Raharjo

    weird indeed
    i tried to reproduce it on 14.1 and it worked
    also in 14.0

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

© 2024 Alien Pastures

Theme by Anders NorenUp ↑