Main menu:

Sponsoring

Please consider a small donation:

 

 

Or you can donate bitcoin:

 

Thanks to TekLinks in Birmingham, AL, for providing colocation and bandwidth.

Page Rank

Fame

FOSS Force Best Blog--2013 Award

Recent posts

Recent comments

About this blog

I am Eric Hameleers, and this is where I think out loud.
More about me.

Search

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 417 other subscribers

My Favourites

Slackware

Calendar

February 2019
M T W T F S S
« Jan    
 123
45678910
11121314151617
18192021222324
25262728  

RSS Alien's Slackware packages

RSS Alien's unofficial KDE Slackware packages

RSS Alien's multilib packages

RSS Slackware64-current

RSS SBo

Meta

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/

Comments

Comment from Ryan P.C. McQuen
Posted: December 22, 2014 at 18:01

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!

Comment from Michelino
Posted: December 22, 2014 at 18:02

No tips…but compliments!
Thank you really much.

Comment from Willy Sudiarto Raharjo
Posted: December 22, 2014 at 18:32

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

Comment from Oleg
Posted: December 22, 2014 at 22:07

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

Comment from Deny Dias
Posted: December 22, 2014 at 22:32

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.

Comment from alienbob
Posted: December 22, 2014 at 23:06

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.

Comment from alienbob
Posted: December 22, 2014 at 23:09

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.

Comment from Deny Dias
Posted: December 22, 2014 at 23:09

Eric,

Roger that. 100% understood and supported.

Comment from grissiom
Posted: December 23, 2014 at 03:33

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

Comment from Niki Kovacs
Posted: December 23, 2014 at 10:04

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

Comment from alienbob
Posted: December 23, 2014 at 12:43

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.

Comment from Andrew Poltavets
Posted: December 23, 2014 at 19:55

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?

Comment from alienbob
Posted: December 23, 2014 at 22:09

Andrew, please read an older post of mine, http://alien.slackbook.org/blog/first-preview-for-slackware-of-plasma-5/ 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.

Pingback from Links 23/12/2014: Updates on GNU/Linux in China and N. Korea | Techrights
Posted: December 23, 2014 at 22:39

[…] Ktown for Slackware – development history available in git […]

Comment from Willy Sudiarto Raharjo
Posted: December 24, 2014 at 03:30

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

Comment from alienbob
Posted: December 24, 2014 at 11:31

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.

Comment from Willy Sudiarto Raharjo
Posted: December 24, 2014 at 13:01

alienbob:

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

Comment from alienbob
Posted: December 24, 2014 at 14:04

I have these installed:

lua-5.1.5-i486-1_SBo
lua-md5-1.2-i486-1_SBo
luacrypto-0.3.2-i486-1_SBo

Comment from Willy Sudiarto Raharjo
Posted: December 25, 2014 at 02:34

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

Write a comment