Bobulate

The first beta of KDE 4.6.0 has rolled around, pretty much on schedule. In the KDE4-OpenSolaris community we’ve been following closely, building trunk as much as possible and upstreaming those patches that make sense. So we’re happy to announce that for the first time there are 0-day packages available for OpenSolaris-type systems using Sun Studio (I’ve got to add that last proviso because the Belenix guys do a good job of producing packages with gcc).

The packages can be had from the 4.6.0 package repository and include Plasma Desktop Workspace, KDE sdk, Konversation and Amarok along with a bunch of other things. There’s no KDE PIM, edu or KOffice because of various compilation problems that we have not yet been able to solve or functionality issues (e.g. KMail crashes in all of its GPG handling in a way that makes me suspect a compiler bug, but I haven’t been able to track it down well enough yet). The specfiles repository from which these packages are built is available too.

Supported Platforms: the packages are currently available for x86 only. In a poll we did some time ago there was little enthusiasm for specific 64-bit packages, so we have not been building them. Anyway, the Solaris kernel can mix-and-match 32- and 64-bit applications and libraries, so there’s not much lost. There’s no SPARC packages, in spite of some recent success in getting things to build. Here’s the list of supported platforms:

• OpenSolaris build 134, x86 Edit: while the repo should build on 134, these packages will not install there because dependency names have changed.
• OpenIndiana build 147, x86

Just those two, hunh. Later builds of either should work, but have not been tested. Oracle Solaris Express 2010.11 should work (it names itself build 151) but has not been tested. Solaris 10 is not supported, as it uses a different packaging system and needs lots of other updated software.

How to get it: set your kdeips-dev publisher to the new repository URL, refresh and install. Something like this should do:

pfexec pkg set-publisher -O http://solaris.bionicmutton.org/pkg/4.6.0/ kdeips-dev
pfexec pkg refresh
pfexec pkg install KDEbase-apps

PS. I’d like to welcome Onno Molenkamp to the fold. He’s been doing 64-bit builds for us and tackling some long-standing annoyances (in Virtuoso and Qt) that make the build less pleasant than it might. The #kde4-solaris channel now has random bits of Dutch on it, too.

PPS. KDE4-OpenSolaris acts as an "upstream" for OpenIndiana. We’re "downstream" from the work done by the KDE community, and massage the code a little and send it off again. There is plenty of scope for cooperation, and we’ve seen recent conversations about having various parties interested in stuff to work together more effectively. (Here "stuff" is Qt and KDE frameworks as well as KDE applications and Plasma workspaces).

PPPS. Solaris 10 isn’t dead as far as we are concerned, just very much unsupported and uninteresting as a target (even if it has a decent installed base of corporate use). Some people try building our specs every now and then and we do try to avoid actively breaking stuff for S10.

PPPPS. We know not all of our patches are acceptable for upstreaming. Some actively break stuff for other systems. Those are the kind that don’t go anywhere else. Sometimes we massage things until they are acceptable. It’s a bit of a trade-off. A shout-out to the author of Sentinella, Carlos Olmedo Escobar, for contacting me about the Solaris packaging we’ve tried to do and the patches that required. I hope to have Sentinella running on OpenSolaris pretty soon.

It took some wrestling, but the EBN machine is back up, with some of the VMs up and running FreeBSD 8-STABLE. I’m still repairing the EBN itself, since that has many many more packages installed that need recompiling than the other VMs. There’s also Java to deal with — it may have become superfluous on the machine, but I need to sort that out or build by hand again (due to license restrictions, you still need to fetch Java distribution sources manually).

In any case, with the server up and running again the KDE4-OpenSolaris folks could push their updates to our Mercurial Repository with specfiles (and patches) for the KDE SC 4.4 series, including dependencies. As always, this is intended to build all of the KDE packages on a recent OpenSolaris (I use 130, others use 134, and I would recommend against anything pre-124). Mark and Ben also work on supporting Solaris 10 (the stable, enterprise OS release) so you can probably build the whole thing on there as well. Both SPARC and amd64 are supported, and we do try to support 64-bit builds for all of the dependencies. KDE itself builds only in 32 bit mode, though (simply because I don’t see much point in doubling build times and having an extra copy around).

Let’s take a look at what has happened recently in the repository:

• Updated to KDE SC 4.4.3: after it was released on May 5th, 2010, it took only a day to bump the repo to 4.4.3 as well. We now tag things in the Mercurial repo a little more consistently, so you can pick releases as needed — I do think this is a little more convenient than cloning a separate repo for each minor release as we did for the 4.3 series.
• GPG Updated: updated gpg to 1.3.0, which is the latest version. This also meant updating libassuan to 2.0.0 and some other minor tweaks, but it gives us something modern again.
• icu4c updated: The Unicode consortium’s library for Unicode manipulation — needed by Boost — has been bumped to the latest version. There’s a “competing” version from Sun itself, SUNWicu4c, but that’s built against the old Cstd library so we can’t use it.
• Various administrivia: updated libattica to 0.1.3 and changed the QImageBlitz library version to 0.0.4; this was 4.2.0, matching the KDE release that it originally came with, but the library itself thinks that it is 0.0.4. Looks a bit unmaintained otherwise, and I had to go (thankfully!) to the Debian source mirrors to get a sensible source tarball.
• GNU Telephony: The dependencies for the GNU Telephony project have been imported as well. I don’t know if this is needed on OpenSolaris — it hasn’t been built for any of my KDE needs yet.

So there’s plenty of updates going on, and we’re happy to have a single source where you can type “make” and get a working KDE4 desktop on an OpenSolaris machine. Packages might be available by now, too. I’m still working on transferring the package server to an OpenSolaris VirtualBox on FreeBSD.

By tracking things more closely each minor release (of anything) becomes easier to test and integrate — I suppose I should write something about using ZFS to do that — and we can stick closer to the actual release dates. I don’t think we’ll ever be able to keep up with the Linux distro’s or FreeBSD, but we’re close.

The OSOL appliance released by Jignesh Shah is 2009.6 — nearly a year old now. Since then the packaging tools for OpenSolaris have made great strides. IPS remains .. interesting. I’m not entirely convinced that it was worth the effort of not using some of the existing package formats. However, by now I understand the API it brings in as well as the various uses of the tool, (and it crashes no more) so I’m starting to like it.

Anyway, the point of this particular appliance is to host KDE4 packages for OpenSolaris in an IPS repo. To do that means running the IPS pkg.depotd. I have a port of an older version of pkg(5) to FreeBSD, but it all seems a little klunky and hard to maintain. So using an OpenSolaris VM seems the right approach.

Except that the OSOL VM from Jignesh is kind of old, isn’t it. So I ended up looking into upgrading the OSOL VM after installation, and ended up with the following steps:

1. Set the publisher to the dev branch: pkg set-publisher -O http://pkg.opensolaris.org/dev/ opensolaris.org . This means that future packages will come from the dev branch, not the released branch.
2. pkg refresh --full to fetch all the new package references.
3. pkg image-update -f (I have to force it, because something’s wrong with cherrypy and the image will not update otherwise) and wait a while while 138MB of package updates are downloaded.
4. Reboot into the new boot environment (VOSApp-1). This will fall into a root shell for fixit-purposes, because the filesystems are messed up.
5. Fix mountpoints for those messed-up filesystems and reboot again; I recall I needed to re-set a number of zfs mountpoints to get the correct organization for regular system operation. Bear in mind this isn’t needed with normal OSOL upgrades, just for this slightly peculiar application setup. I think I had to set the new rpool/ROOT/VOSAPP-1/opt/ (and var and root) to mount in the right places and move the older rpool/ROOT/VOSApp/ filesystems to somewhere in /mnt.
6. Reboot, possibly fix up remaining mountpoints, then zfs destroy the old ones.

There’s a useful HOWTO entry on updating OSOL to a specific build which I might otherwise have used, but the appliance image does not have an entire package installed which could be used to drive the upgrade. Hence this slightly klunkier approach.

Since Jignesh has left Sun, I’m not sure if there will be any future growth in these appliance builds. They were popular enough in Nigeria, where I distributed verbatim copies of the original (probably still in violation of the license terms though) to people interested in running OSOL at all.

Oracle has confirmed that they’re doing something with OpenSolaris, it’s not being sunk to create a diving reef or anything, so the folks who have been putting effort into KDE4 on OpenSolaris can carry on a bit. There’s KDE 4.4.1 packages available (that link, which includes a specific port number, may be valid only through to mid 2010). A number of crashes has been fixed. Debugging information has been improved. There’s still a little weirdness in q_atomic_decrement every now and then, but on the whole it’s good to use.

It’s also usable on Sun Ray 5 (which has version 4.2, I think). My OSOL machine runs SRSS (following the installation instructions on the Sun Ray wiki for OSOL 2009.6) and I can run a KDE4 session both on the local display and on the Sun Ray DTU, quite acceptably.

I took a look at the “Come out as part of KDE” guidelines, those for distro’s in particular, and find that for the distributions we should (?) be writing something like this:

OpenSolaris 2010.03 comes with either GNOME 2.2.26 or Plasma Desktop 4.4 and many applications like the GIMP 2.10, Amarok 2.3.3, F-Spot, Digikam and many more.

I’m not sure why we’re putting words about the available GNOME components into our distro’s mouths, and the sudden (maybe I haven’t been paying attention) appearance of “Plasma Desktop” is a little strange. My initial response is “that’s nice, Thomas, but I wanted a Bud Lite^W^W^WKDE.” Certainly because GDM’s session manager is going to say “KDE” as session type, not “Plasma Desktop” for the foreseeable future.

This week I’ve spent a few late nights working on the OpenSolaris packaging of KDE 4.3.0 — since 4.3.1 is out, it’s just about time, don’t you think? FreeBSD has the good stuff already.

New development repositories: we have been using Mercurial for a while for maintaining the specfile repositories that drive the packaging of KDE4 on OpenSolaris, which — like any DVCS — makes branching and merging and opening up development a breeze. That also means some unrestricted growth in the number of repositories and sometimes feature creep on individual repo’s, so we’ve stopped for a moment to consider what’s what. There are now five repositories, of which one is legacy, two deprecated for being too confused (but kept for a bit just in case someone is using them), and two repositories that are in current use.

The KDE 4.3.0 repository has specfiles for KDE 4.3.0 (this should not be a surprise) and the dependencies that we have built. Those include Qt 4.5.2, BOOST, Apache stdcxx and lots more. This repository is considered stable and should not change any more. The 4.3.1 repo is not stable, and is under construction.

Things that will go into the 4.3.1 repo are an update of poppler to 0.10.7 (current version) and of course updating KDE to 4.3.1; this also means adding the new KDEpim-runtime module to the set of packages. We don’t package it for 4.3.0 and that doesn’t seem to hurt KMail. We hope to improve collaboration with Belenix by stealing all of their updates to the dependency tree, while we’re at it.

[[ And there was a Qt security announcement on September 1st — that one is in both repositories and applies to the packages that are available as well. ]]

New IPS package depot: in the past three months or so we have accumulated a crufty set of packages on various IPS servers; these have been knocked down and a fresh set of IPS packages is available from the publisher http://pkg.bionicmutton.org:10000/ (also supports port 8080, by popular request).

These packages are the ones built from the 4.3.0 repository using Sun Studio Express on OpenSolaris 2009.6 and are supposed to “just work.” As usual, people with the initials MS will find out that they don’t — honestly Michael, what do you do to those poor install images.

Tools usage: the KDE4 packages are still not built using Source Juicer. This is easy enough to explain: because it’s a family of 122 packages which share settings and common files, it’s difficult to merge into Source Juicer effectively. We have tried, and SJ does drive us to do some simplification and a reduction in the number of files used for the build, but we are not there yet.

Instead, packages are built on a stock amd64 (an X2 4850e w/ 6GB RAM under my desk) OpenSolaris 2009.6 install, then tarballed using the tools from the IPS best practices wiki, archivepkgs.py in particular. These are copied to the actual server which then needs to be restarted every time we import new packages — wanting to avoid the restart is what led to our wild growth of IPS servers.

One tool I’m missing (lazyweb wishlist warning) is one that cleans up the on-disk pkg depot; I’d like to be able to strip out all but the most recent version of every package from a depot. I have an inkling of how this would work (determine what’s “latest”, flag all the files it uses; later walk the filesystem tree and remove all non-flagged files), but I don’t feel like going the destructive route myself right now.

There’s a problem in pkg(1) with large file uploads, so publishing the packages directly to the server is infeasible; that’s something that we need to fix with a nice workflow and one appointed person to kick the depot server when needed. This will happen once we have KDE 4.3.1 packages built and somewhat tested.

Stability: There are some known crashes; Dolphin has some threading issues and KMail crashes on exit, for instance, but the overall impression I get from running KDE 4.3.0 as my desktop on OSOL is pretty good. Even with an underpowered X1200 onboard video. With a proper video card (e.g. the GF9600 512MB on my laptop) things are much nicer.

Feedback: Please use the kde-discuss forum/mailing list or file bugs in the regular KDE bug tracking system and set the Operating System to Solaris in your report. We appreciate bug reports (if you can, check that they are Solaris-specific by comparing with, say, FreeBSD behaviour) and appreciate patches even more. Remember, the specfiles are open and everything can be built from source by following the instructions on the KDE TechBase page on OpenSolaris (and that’s a wiki, so if the instructions are not clear, you can help improve them!).