Bobulate

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.

Even if Talk Like a Pirate Day (developer idea: implement tlapd, a proxy LDAP server that mangles replies to be more piratey or which intercepts http requests) passed quiety for me this year, I’m still partial to the (ahem) romantic ideals of the pirate. So when Something Positive pointed to a Steve Jackson floortop game Evil Stevie’s Pirate Game which combines Pirates, Lego ships and large group gaming. Whee!

Recent kitchen projects have included a totally failed meringue pie and chocolate ice cream — neither of which the kids liked, but which nonetheless disappeared so quickly no photos are available. And I think I’m getting the hang of white bread now, too. Need to work on getting the crust just right.

GUUG’s Linux Kongress is on right now, if you’re near Nuremberg. NLUUG’s Fall Conference, with Security and Privacy as topics, is coming up at the beginning of November.

Lastly, I’m happy to hear tales of people (like Frederik) Joining the Game. Coincidence that he describes what KDE e.V. does the same day I write a rather dry item on the same topic? Mystery! At least he can spell “e.V.” properly, which I couldn’t.

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.

For years — perhaps since KDE e.V. was formed — there has been a mailing list kde-ev-vorstand. A perfectly sensible name if you happen to speak German and know something about eingetragene Vereine. For the rest of the world, perhaps not so much. The list has now been renamed to kde-ev-board. Unfortunately, during the changeover, mail sent to one list or the other has gotten lost. So if you tried to communicate with the board of KDE e.V. on the weekend or monday or tuesday morning, september 18-21 2010, your mail may have silently vanished. Please be extra alert for replies and don’t be shy to re-send.

So, what’s KDE e.V. you might ask? It is the non-profit association which was set up to support KDE development. An association is a convenient legal form in Germany (and elsewhere). It has members — the membership of KDE e.V. are those people who want to help the association achieve its goals. It’s a little like a tennis club: the members want to be able to play tennis and so set up a club that ensures that there’s infrastructure so that everyone can play. The association doesn’t play tennis itself, even when the members do; its purpose is there to make things possible. KDE e.V. makes it possible to channel money into developer sprints and helps organize the yearly Akademy conference — this year that will be a Desktop Summit once again in cooperation with the GNOME Foundation. You can find out what the association has been doing in the Quarterly Reports. The latest one is for 2010Q2; Q3 is just about to close so we’ll be looking for volunteers to help write it up and we’ll be soliciting items from the various working groups and teams in the KDE community.

The board list is the right place to ask about travel reimbursements (ask before you book!) or to suggest sprint topics, offer hardware support and instigate new projects which have funding requirements. Just remember that kde-ev-board@ is now the best address to use (although -ev-vorstand continues to function).

This weekend is Software Freedom Day — a chance to celebrate the idea that you, the owner of a computing machine, should be in control of the computations done on that machine. As the owner, you should be able to run what ever you want on the machine — or be able to prevent running someone else’s software on your device. This is a notion best served by Free Software.
The SFD events are global and organized in a decentralized fashion. I see there are six events in Nigeria, for instance, including one in Bauchi state and one in Sokoto. There are two events in the Netherlands, one on the 18th in Den Haag (the Hague). Karsten Gerloff, president of the FSFE, will be speaking there, among others. The other event is on the 17th in Amsterdam at the CWI.
Also don’t forget that the 19th is Talk Like a Pirate day.

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.

Do you get this as well? A PDF delivered along with a message that you can use Adobe Acrobat Reader (r) to open that file?

PDF is a (relatively) open standard. It is an ISO standard (19005-1), for one thing. This also means that there are alternate implementations of the standard. And you might have good reasons to avoid the Adobe implementation. For instance the number of exploits against their implementation, or because it doesn’t run on your hardware / software platform. Most of the time I’m at a computer which is perfectly capable of dealing with PDF files through a Free (both as in speech and in beer) PDF reader, and the "download Reader" just strikes me as weird. I get these PDF files from travel agencies, hosting providers, financial advisors and local governments. I often reply asking them to update the text accompanying the file to say something like "You need a PDF reader to view this file. Get a free one or use something else." The PDF Readers (.org) site is a good place to point people and organizations. The site points out the available options and how to get a Free PDF reader.

The Free Software Foundation Europe (FSFE) has started a campaign to promote the use of Free PDF readers by local governments. The idea is to point out where your local government is pointing only to the proprietary software solution and to get them to adapt the text to offer more choice. There’s a contest involved, as well.

As far as the PDF readers site goes, it points to muPDF; that’s one I would personally avoid for semi-technical reasons: the code is terrible and utterly undocumented. Maybe the application works — but it’s not something that satisfies my code-readability test. Not one of the files has a license header, although the thing as a whole is licensed under the GPL version 3 or a commercial license.

Turning to the more popular — or rather, the recommended readers on Free Software operating systems — selections, there’s Okular and Evince. I use both of them fairly regularly — Evince is my fallback on OpenSolaris during those times that I’m compiling KDE. Following the links from PDF Readers to the two web pages for Okular and Evince shows a pretty big difference: the latter is focused on packages and contains a link to a how-to-compile page, while the former is all about building the software from scratch with a comment that there’s probably packages available. Neither of these strike me as a particularly good user experience. I wonder if there’s any feasible (technically and privacy-preserving) way to detect the OS so as to improve the download suggestions.

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.