Bobulate

I recently mentioned that Plasma Desktop and KDE applications 4.5.2 was building. It’s done now and the repository has been put up on solaris.bionicmutton.org. This uses a Linux port of pkg.depotd, rather crudely hacked together by myself. That should ease up some package downloading issues.

So, users of KDE4 on OpenSolaris and OpenIndiana, it’s time to update. Remember to file bugs at bugs.kde.org with the OS set to Solaris, and drop by #kde4-solaris on Freenode.

PS. There was an article up on a Dutch website with “5 best things Oracle did for Open Source” and one of them was “Kill OpenSolaris”. Hm. PPS. Konqueror does crash on Flash games sites, somewhere in kjs. On the plus side, DrKonqui now produces nice stack traces with dbx.

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.

Even though OpenSolaris is no more, and I should be writing about “Qt 4.7.0 on OpenIndiana” instead (OpenIndiana is a distribution made by the people of the Illumos Project, which is intended as a Free Software community development effort based on the existing OpenSolaris codebase), I’m going to continue saying “OpenSolaris” for now. That’s partly because I haven’t actually tried any of the newer versions available through OpenIndiana — I’m still stuck on build nv134, the last one to come out officially from the maw — belly? — of the beast. Hajma says OI is fine with our existing KDE packages.
Stuff carries on in the KDE4-OpenSolaris repositories. The active repo is -460 which advances towards the eventual release of KDE 4.6.0. That Mercurial repo now has two branches. The default branch is Qt 4.6.3-based, with the KDE 4.5.68 snapshot. There’s a separate branch (hg up qt-4.7.0) in which I’ve been pushing the new Qt 4.7.0 release. In that branch:

• Grantlee 0.1.6, prompted by Steve.
• Qt 4.7.0, obviously.
• Qt 4.7.0 examples and demos. This is new for 4.7.0, because previously we didn’t have any packages building the examples. After a great deal of digging around, it turned out that qglobal.h was overly pessimistic about the compiler, which in turn caused compile errors in the examples, which is why we had them switched off. Install FOSSqt-examples.
• Full(er) QtConcurrent support, related to the previous fix. This is one thing that I really enjoy in packaging (or at least, it dulls the pain): something doesn’t package right, so I need to figure out why, so I read lots of code and documentation and in the blink of an eye I’ve spent half a day writing Qt Concurrent test programs. It’s good practice as a programmer.
• QML. At least the QML minesweeper demo runs, I haven’t tried anything else.
• hgview. This is a Mercurial log viewer, written in PyQt. I’ve added it because it is a useful tool and because it demonstrates the power of PyQt reasonably well. To run it, you’ll need a newer Mercurial than the one bundled with OSOL, so I banged together a Mercurial 1.6 package as well.
• KDEPIM 4.5.68. That’s Kontact, updated with all the previous, so you now have KNotes with fancy templates and the mobile version of all the Kontact apps, too. This snapshot brings Akonadi into the mix, about which I’ll write some other time.
• Qt Creator. I grabbed 2.0.1, the latest, which is just as well because I see there’s a security warning about 2.0.0. I still need to figure out one more RPATH fix for it to go really well.
• Lots of crashes

For grantlee, I ran the test suite and got 34 seconds on the benchmark (test 9). No idea if that’s good or bad. In general Qt apps seem a little sluggish to me, which means that we’ll have to look at the locking performance again and check out how debug output is handled.

The “lots of crashes” thing is worrying though. eAlex79 reported on IRC that he was having trouble with gcc-based builds of Qt 4.7.0 on OSOL as well, so it might be something more fundamental. He says it’s got to do with threading and glib, which fills me with dread. I just know the symptoms for now: Konqueror crashes. The Qt browser demo crashes while loading the default page. Blogilo crashes when starting the settings page. That kind of stuff, and it will take us some time to sort out what’s what. As always, this reflects more on the unusual platform and compiler and flags choices than anything else.

On the other hand, the important bits (konsole and kate) do work.

Ivan has been on a tear with his “stripes” series of wallpapers. They remind me of crinkly potato chips, too. In some random browsing I ended up on the Blue Mint, with 15 more cool wallpapers. The latter page shows that “K Desktop Environment” is a rather persistent term. Like mildew, it’s hard to get rid of.
It’d be nice to have a KDE4-OpenSolaris wallpaper, something nice for the 4.6.0 release when it rolls around (4.6.0 of Plasma Desktop plus the KDE Platform 4.6.0 and the KDE Applications Collection — which even on OpenSolaris is more than just what’s found in the core KDE SVN modules). Of course, the OpenSolaris term is one that needs eradication as well, now that Oracle has definitely killed it (last week in Linux Journal, but really old news to anyone watching the official face of OSOL). Anyway, Ivan, here’s a chance at fame in an insanely niche environment.
I’ve been looking through things on kde-look.org a bit, trying to find one or two nice wallpapers and themes to put into the default KDE consolidation, if only to give a teensy bit more spice to the OSOL packages. It’s really hard to choose — because of the sheer volume of material on there. Themes as well: possibly I just don’t understand what “Beryl Emeral Theme” or “Aurorae Theme” means; I assume they’re not applicable in a stock KDE installation. That doesn’t leave much to choose from, anyway.
Of course, for your needs in art, Lukas’s work is to be recommended. The advances made over in Krita are one reason I really should get down to updating the Krita packagers, so’s I can see for myself what’s going on.

I’ve been using VirtualBox (the Open Source Edition) a fair bit recently. My desktop machine fairly hefty: an i7 860, 4 core HT and 8GB RAM. I leave it running Kubuntu and VirtualBox on top of that. Then I have a workable, if by now slightly dated, desktop and all the KDE applications that I need. In VirtualBox I run the machines I’m interested in for development. That’s an OpenSolaris instance and a FreeBSD one (just resurrecting that interest now and I haven’t even gotten around to checking out area51 yet). I also keep a Fedora and a Kubuntu VBox around for comparison purposes. So plenty of ways of using up the CPU power. Next to the desktop machine (also under my desk) is my spare box, which is an amd64 6250e, dual core, 6GB RAM.

The guest additions make the applications running in the VBox interact with the host machine without mouse or keyboard grabs; then the KDE application running inside GNOME in OpenSolaris is very nearly just another window on my desktop.

I use the OpenSolaris VBox to compile KDE packages. In a very simple test — building QScintilla — I find that the virtual machine outperforms the physical machine sitting next to it. Compile goes from 3 minutes to two, running the same software stack. I’m very much surprised, because the clock speed difference isn’t that great and I’d expect there to be some non-trivial virtualization overhead.

The fact I can share a folder between the host OS and the VBoxes is quite useful, since it means I only need a single checkout of KDE SVN. I can patch from inside each virtual machine, experiment and eventually push things back out. FreeBSD doesn’t support directly shared folders, but I can still network-mount everything. This then means that it’s become much easier for me to test changes across OSsen. No longer will I horribly break Linux builds with a little Solaris patch (er .. I don’t think I’ve done that before, or maybe I just don’t remember).

What would be really keen is appliances: a VBox image that is an instant FreeBSD / OpenSolaris / OpenSUSE development environment. That would work for FreeBSD and OpenSUSE, I think, but the license terms of Sun Studio presumably preclude redistribution. That’s unfortunate, because it makes it harder to get development done (although, come to think of it, a system which has everything installed except for the one tarball of Studio might not be encumbered). It would serve a different purpose than the SuSE build service which does builds for many many different OSsen — desktop development in a separate environment.

One thing I intend to add to the stable is a Linux VBox with Sun Studio for Linux installed on it, so I can try some stuff related to the compiler. I recently finished up packages for KDE-PIM and there were many patches needed; there’s some template magic that the Sun compiler just doesn’t understand, leading to dozens of KCalCore::Incidence::Ptr() cast constructors being patched into code that’s otherwise a model of tidyness. Only once I’ve got something sensible set up will it be possible to apply power machinery (in casu KDAB Marc, C++ template guru) to the problem. In any case, we have packages for all the parts tagged as KDE 4.5.68 (snapshot from trunk) for OSOL except for bindings, edu, kmix and plasma-addons. The problem in kde-edu is actually a bug with Boost and Sun Studio, so that’s going to take a little more work to fix.

A bit of a belated thanks to Albert and Frederik for providing information about updates in dependencies needed for KDE4 — even trunk things as it works towards the 4.6.0 release of Plasma Desktop and the KDE applications.That kind of "heads up!" makes it much easier to keep the whole software stack up-to-date. Shortly after reading their blog entries, I updated (attica) or added (ebook-tools) specfiles to the specfile repository for 4.6.0. ebook-tools needed libzip, which as far as I could tell wasn’t available yet either (caveat: Oracle basically stopped updating all the package repositories and the SourceJuicer efforts, so the past four months have seen total stagnation on the official front for software packages, so it’s possible that someone else has already packaged the stuff elsewhere). Anyway, it’s appreciated, and those packages will affect the next package release on OpenSolaris.

We’ve just bumped the build to KDE 4.5.68 snapshot (in the -460 repository; the -450 one remains at 4.5.1). The builds haven’t finished shaking out yet, though. We’ve rolled a Phonon 4.4.3 tarball (apropos tarballs, I really enjoy reading Valorie Zimmerman’s blog for a reminder of what it’s like to start out in developerland) from git for internal use. QScintilla and the Python bindings for it have been added. Those aren’t directly useful in KDE, but they’re nice to have. I have tried a bunch more PyQt applications and they all seem to work ok, so I’m declaring those bindings "good enough."

Bug reports and patches can go into KDE’s bugzilla bugs.kde.org, with the OS set to Solaris.

Sun Studio has been renamed Solaris Studio, to reflect its target OS — or maybe just to say that Sun has been consumed by the boa constrictor that is Oracle. Of course, Studio works on Linux as well, so the name is now a misnomer in other ways.

Solaris Studio 12.2 is out, a minor upgrade over 12.1. The KDE4 on OpenSolaris project is one of the biggest public consumers of the C++ compiler — I suppose VirtualBox is as well, although that project never led to much C++ technology being updated in Solaris. Pavel was active during the beta phase of this product, and was the first person to report a regression in the C++ compiler: the -Y flag (in particular, -YP, which is documented to prepend directories to the linker’s search path) changed behavior. Now, historically the -YP flag has been different between the C and C++ compilers (duh?), and code consolidation pushed the C behavior into C++.

Unfortunately, the documentation hasn’t been updated to reflect this change. Neither has the regression been fixed. In other words, a bug reported pretty much on day 1 of the beta, shipped unchanged three months later.

We (as in the KDE4 on OpenSolaris crew) are creative enough to adapt to this situation: instead of using -YP to prepend paths, we can set the whole search path (like we would in C) like so: -YP,/opt/kde4/lib:/usr/lib . There’s one big gotcha, though: the C++ runtime and standard libraries live in the compiler installation directory, which must be searched for them. So we end up with a situation like this: if it’s Studio 12.1, use -YP,/opt/kde4/lib (nothing else, since the compiler libraries and /usr/lib are searched already) and if it’s Studio 12.2, first find out where the compiler libraries are installed (typically, but not necessarily, /opt/solstudio12.2) and then use -YP,/opt/kde4/lib:/usr/lib:/opt/solstudio12.2/lib . And don’t forget to adjust for different architectures (x86 vs amd64 vs SPARC).

In short: Solaris Studio 12.2, don’t bother.

Of course, a compiler isn’t the most important thing for Oracle. That’s just enabling technology and I imagine that it just needs to be good enough to push their in-house code to production. ISVs apparently don’t contribute enough to the bottom line to give them the tools to use the OS as well.

The past few months I’ve been a little quiet about KDE4 on OpenSolaris, but that’s not to say that nothing happens. Pavel Heimlich and Jan Hnatek have pushed the packages and dependencies forward. For instance, the 4.5.1 release of Plasma Desktop for OpenSolaris along with KDE Applications happened entirely because of their efforts. Pavel is now part of the kde-packagers group, so we should see a slight improvement in release timing — that is, KDE4 on OpenSolaris should release packages on release day alongside SuSE, Fedora, Ubuntu and PC-BSD.

The Korona distribution of OpenSolaris — that is OSOL plus a Plasma Desktop and KDE applications by default — is also a result of their work. There hasn’t been a recent update of it (not with 4.5.1 that I know of) but there will be, once the dust settles a little around OSOL.

Ah yes, the dust. Einsturtzende Betriebssystemen or something like that. Oracle has managed to collect epic amounts of ill-will from Sun fans, ex-Sun employees, Free Software enthusiasts, Open Source folks, software packagers and whoever else I’ve left out. Examples of annoyance and exasperation can be found on most of the OSOL forums. Here and here are two examples (mirrored from the OSOL forum site, though).

So, what’s up for us? Well, various dependencies are being updated — like testing Sun Studio 12.2, upcoming Qt 4.7 — for KDE 4.6 releases. The breadth of available software in our tree is increasing — see the inclusion of PyQt and QScintilla as of this week — and our coverage of KDE Applications including the office suite is getting better. I don’t think we have a full KOffice available yet, but it’ll get there eventually.

As always, our software development happens in the open and patches get pushed upstream as much as is feasible. Communications happens on #kde4-solaris on Freenode and on the kde-discuss@opensolaris.org mailing list. Join us. OSOL is still more popular than Plan 9, after all.

For the past month I’ve been honing my PyQt skills and greatly enjoyed it. I’ve been saying to people at conferences — for years already — that Python (or some other scripting language) is the Right Approach ™ to a great many end-user applications for its speed on development and ease of prototyping. Now I finally spent a month testing the truth of that statement.

However, all the work I did was on Linux systems, both Ubuntu and Fedora. Today I sat down to package PyQt for OpenSolaris. Riverbank Computing supports Solaris, to the extent that sip lets you do –platform solaris-cc, but there were a few gotcha’s along the way.

• The mkspecs parser in sip expands Windows-style percent-sign variables. This bumps into the Sun Studio flags which includes things like -library=no%CStd. It took me a long time to track that down, and then patch it out.
• Python lives in /usr while our Qt packages live in /opt/kde4 — this just causes packaging headaches and RPATH juggling, nothing spectacular.

But those little gotchas aside, packaging went smoothly. You can get the specfiles from the KDE 4.6.0 preparation repository. Packages are not yet available from our usual KDE4-on-OpenSolaris repositories, though. We might backport into the -450 specfile and package repository if there’s any enthusiasm for it.

One thing I’ve had some trouble with is finding code to test the bindings with. Somehow the examples that are bundled with the PyQt source distribution aren’t mentioned a lot on the web, so it took a while for me to find the obvious testing ground. But from there the whole QtDemo application runs except for the OpenGL parts: it seems I’m missing the bindings for that. So there’s still some polishing left to do with the dependencies, too.

So what’s the future hold now we have Python bindings for Qt in OpenSolaris? Well, the obvious thing to do would be to produce some small applications that help with OpenSolaris-specific features such as ZFS, dtrace or containers. That would give the KDE4-OpenSolaris desktop a boost as well.

After a few upgrades on various desktop and laptop machines (don’t get me started about the EBN machine, which is curiously unstable under FreeBSD 8.0) so that my main development workstation is running OSOL build nv134, I’ve kicked off a new round of OSOL builds. Of course, I ran into the 134 upgrade issue where /dev/ptmx ends up with the wrong permissions, but that’s documented along with a workaround in the release notes. The new set of builds is plain KDE SC 4.4.3, with only a few updates: Assuan is updated to 2.0.0. This disables parts of KDE PIM, at least until I get KMail recompiled so that I can get at the patch that Will Stephenson sent me two weeks ago to handle Assuan2. ICU4C is updated to 4.4.1. The FOSShier package makes a new appearance, so you can easily manage KDE SC separately from the dependencies that KDE4 has.

For the bits-that-I-haven’t-tried-myself, I think KDM now partly works on OSOL, but it doesn’t run all of the scripts that GDM does, so you don’t get a very good desktop experience out of it.

On the whole, it’s not really exciting. We (as in the KDE4-OpenSolaris folks) have decided to give the KDE SC 4.5 betas a miss for now — I know that trunk was having some interesting template issues a few weeks again, so I have serious doubts it will compile at all — and just try to get the current crop of packages in the best shape possible for OpenSolaris.

There’s an OpenSolaris 2010.03 upcoming, some day. Yes, that 03 was supposed to be March, but clearly corporate takeovers got in the way. There are some pretty big changes in packaging there (in particular, package naming) so in order to make the KDE4 packages integrate cleanly we’ll have to do some fixing there.

As always, the specfiles can be had from our specfile repo; however, packages are not up-to-date on the package server because of stability issues.