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.
Eric
Edit – Tue Dec 23 12:26:25 UTC 2014:
I have added a cgit interface as well: http://taper.alienbase.nl/cgit/ktown/
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!
No tips…but compliments!
Thank you really much.
It would be nice to have cgit interface as well, since it’s simpler and easier to navigate through history
Greate news!
Thanks!
Will wait for binaries and/or instructions for building all packages.
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.
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.
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.
Eric,
Roger that. 100% understood and supported.
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).
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 (…)”.
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.
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?
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: Links 23/12/2014: Updates on GNU/Linux in China and N. Korea | Techrights
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
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.
alienbob:
Do you have lua5.2 installed on that machine?
it is supposed to be lua (5.1)
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
weird indeed
i tried to reproduce it on 14.1 and it worked
also in 14.0