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:

http://taper.alienbase.nl/gitweb/?p=ktown.git

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.

Eric

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

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

19 thoughts on “Ktown for Slackware – development history available in git

  1. 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. 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.



  3. Willy, I would like to configure cgit properly, unfortunately I have some issues with it.
    See http://taper.alienbase.nl/cgit/ – 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/crypto.so: undefined symbol: luaL_prepbuffer” even though I compiled lua and luacrypto from source today, using the SBo scripts.



  4. 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).


  5. 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 (…)”.


  6. 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.


  7. 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?



  8. Pingback: Links 23/12/2014: Updates on GNU/Linux in China and N. Korea | Techrights

  9. alienbob:

    it seems that you have solved the branch problem

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

    enable-log-filecount=1
    enable-log-linecount=1
    enable-remote-branches=1
    defbranch=master
    max-stats=week
    repository-sort=date
    commit-sort=date
    branch-sort=age
    email-filter=lua:/usr/share/cgit/filters/email-gravatar-sbo.lua
    enable-commit-graph=1


  10. Hi Willy

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

    email-filter=lua:/usr/share/cgit/filters/email-gravatar-sbo.lua

    When I have that enabled, my apache log shows the error “/usr/lib/lua/5.1/crypto.so: 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.





Leave a Reply

Your email address will not be published.

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