Now that the october updates for all the software shipped by the KDE community — that is, Plasma Desktop and the applications — has been released, it’s time to bump versions, etc. and kick off a bunch of builds. This follows the tried-and-true approach of replacing the version number (i.e. it now reads ‘%define kde_src_ver 4.5.2′), running make, waiting for the pkgbuild tool to report failures, fix, rinse, repeat. Usually the things we fix are just new or removed files. In this release, for instance, KHelpCenter has a new documentationnotfound/ directory and some files there.
During this period, our so-called stable (-450) repository is not stable. Fixes to the packages get pushed as and when they are found. Once the builds are stable (i.e. a few of us have managed to get everything to build), then Hajma kicks off a clean build on our build server, waits about six hours for that to finish, then uploads the whole darn thing to the actual binary IPS package server. And then people can update as they like.
I won’t vouch for the stability of updating. We usually take the ‘pkg uninstall -r hier-kde4-deps ; pkg install KDEconsolidation’ route, which is also known as ‘log into JDS, rip out all of KDE, install a new one’. One day we hope to look at that more closely.
Our IPS package server runs in OpenSolaris in a VirtualBox on an OpenSuSE machine. There’s issues with networking in that setup; I’m a little hazy on the details but it means that downloads often crap out. There’s 1226 TCP connections in FIN_WAIT2 state right now. That’s also a sign that people are actually using Plasma desktop and KDE applications on OpenSolaris and OpenIndiana. Apparently folks are overrunning the OI IRC channel asking what’s wrong with our package server — ask in #kde4-solaris, folks.
Since the server setup has been giving us some problems, I cloned the pkg source code repository from Oracle and now have a copy available in our Mercurial repository. The purpose of the clone is to hammer the system into shape so it can run on Linux. It seems Onno M. has done something similar, to the point of producing packages of same via the OpenSuSE build service. In any case, the idea is to drop the VM and additional OS from the equation and make pkg.depotd serve packages directly from Linux. This needs some testing, but I imagine we will be switching over for serving up 4.5.2.
Finally Michael will be able to install KDE software without a week’s worth of disconnects.
[[ While I typed this story, I built the KDEsdk, KDEtoys and KDEutils packages; changes here reflect the renaming of kdesvn-build to kdesrc-build. KDEtoys has no changes, and KDEutils incorporated one of our patches from 4.5.1, so there was a patch to remove. ]]
Two last tidbits: I managed to utterly break my OSOL VBox, so I now do builds on OpenIndiana virtually and on physical hardware running OSOL. Packages are produced in OSOL b.134 and work unmodified on OI b.147 and later. The -460 repository is in the throes of a massive cleanup since the range of supported platforms has shrunk recently: it’s either Solaris10 (untested except by the hardiest of souls) or OSOL b.134 or OpenIndiana, pkgtool 1.3.102 or later. That means cleaning up tons of cruft and special-cases. Once that’s done, there looks to be a bump to Boost (to 1.44) and some Qt mucking about.