Bobulate

The English Breakfast Network — which hosts the KDE code checking site, vizzzion.org, an anonsvn mirror for KDE, my irssi-in-screen instance and a bunch of other stuff — is down following a power outage at the university. While the older CodeYard machine came back up with no problems (yay FreeBSD 6.1!? too bad about the 3 years uptime, maybe) the EBN is stuck somewhere. I’ll have to fiddle around to find the ILOM password, I guess, or in worst case go over there and sort it out at the console (which is not a little trip I would look forward to, as it’s hella stormy today). Expect medium to major delays.

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.

Hola, MeeGo. Not amoeba. Not mi-go (I wonder if they stay at the YMRCIGB-S?). The Register has a little bit on it, and Engadget has it labeled “a doozy?” With Intel and Nokia cooperating on a single Maemo/Moblin platform, re-dubbed MeeGo, we’re seeing a reduction (in the medium term at least) of the number of platforms for smartphones and devices (leaving Windows mobile, iPhone OS, Bada, Android, Symbian still out there as well as plenty of others, I’m sure).

At OSiMWorld last year I fiddled around with Moblin devices and thought they were OK — but unfinished. I haven’t done a whole lot with Maemo, either. But the two of them together, on ARM and x86 platforms? Sounds to me like a strong mix if the license-to-tinker and the dedication to Free Software remains. Since MeeGo is to live under the auspices of the Linux Foundation, I think that’s a given. In addition, there’s a history of working towards good governance there (by all three parties involved). I like governance. It makes things simpler, smoother, so that everyone can focus on their core competence and tasks (in other words, don’t get developers hung up on licensing questions).

All the more reason to have a good mix of devices at Tokamak4, starting this Friday.

The communities working on KDE4 on OpenSolaris are fairly small — there’s one group using Sun Studio and aiming for integration with the usual packaging on OpenSolaris, and there’s the Belenix distribution which uses gcc. The two complement each other. I’m involved with the former group, working on packaging and keeping KDE code tidy (as much as possible — though I’ll admit to introducing hideous #ifdefs). What we don’t know much about is who would want KDE4 on OpenSolaris (or Solaris 10, for that matter — Ben has been really active in bringing the whole thing to S10, which takes even more porting). To that end, Pavel has set up a poll on SurveyBob, writing: If you are already using KDE4 on OpenSolaris or Solaris, or you plan to, please let us know more about your expectations and take a brief survey. There’s no prizes attached to this survey, but we’d be happy to know more about the people for whom we’re doing all this packaging (you don’t necessarily have to show us any love, either).

Valentine’s day is approaching, and if you love Free Software, show some of that love. Send a bug report (a well-written one). Add to API documentation (someone was complaining about that on the dot). Update a wiki page.

The Free Software Foundation Europe encourages you to show your appreciation for your (fellow) friendly neighbourhood Free Software contributor. Hugs show up with distressing frequency in the KDE world, as does beer. I’ve gone out of my way to thank folks who have written useful software for me, and I’d like to recommend you to do it too.

A long time ago, in elementary school — and a primary purpose of elementary school is socialization — the words we used were “warm fuzzies” and “wet blankets” to describe different ways of interacting with people. Wet blankets tend to hang around a long time; so spread some love instead.

(Maybe this is just cover for an upcoming “ten things in KDE4 use that I can’t decide whether they’re bugs or just design decisions that I don’t like” blog post, who knows?) (Also, in spite of Tom Albers, I’m not going to be at the Dutch KDE launch event — other commitments)

Although KDE SC 4.4.0 isn’t officially released yet (or there’s no announcement on the dot yet), I’ve bumped the specfiles in the KDE4-OpenSolaris repository to 4.4.0 and kicked off a rebuild. That means that we should have new packages at about the same time that the major GNU/Linux distributions have them. The release candidate was pretty stable on OpenSolaris as long as you didn’t (re)build any parts of it while logged in, but we’ll probably be hearing enough bug reports in the next few months for OSOL. You can report problems to KDE’s bugzilla with the OS set to Solaris, or use the OpenSolaris bug tracker and choose one of the KDE components there.

Of course, the whole future of OSOL is a little .. fuzzy. The Oracle / Sun takeover has caused a fair amount of shake-up in many of Sun’s projects, but OSOL has not, as far as I know, been either committed-to or deprecated. We’ll see.

In the wake (er, .. the bow shock wave, since I’m getting ahead of myself) of the release, Jos asks for something offensive and the KDE website has been re-vamped. Especially the latter is impressive, for breathing new life into the somewhat moribund site. I believe the call for help still applies as the rest of the content is polished and brought up-to-date.

The second beta release of the main collection of software produced by the KDE community, aka KDE SC 4.4 beta 2, was released last week. There are OpenSolaris packages available thanks to the compilation efforts of the Pavels; since we’re still not very good at publishing the packages in a standard repository, nor in managing smooth upgrades, you can find the packages here.

This set of packages includes Qt 4.6.1, which is a marked step up in stability; also Virtuoso support has been added if you build from source, but not in the packages. We’re still wrestling a bit with the C++ stack, as some things still use the older Cstd STL and “our” stack uses the newer Apache stdcxx4. In OpenSolaris, things are supposed to move to the Apache stack, but that takes some time and needs careful coordination, for instance because enchant plugins need to be moved over, but that implies that all of GNOME (the parts of it that use a C++ API anyway) also needs to be recompiled.

The first time I started up 4.4 beta 2 was a real eye-opener, from the new artwork to various bits of polish applied to the desktop (well, on OpenSolaris that includes things like “you can now start an application from the K-Menu again”, which was broken in all the recent versions). Since then I’ve started jotting down comments about aspects of the default installation that bother me — mostly little things, and it’s another indication that the packaging is coming together pretty well on OSOL that little bits that lack in polish are able to attract attention again.

Once I’ve got a more substantial list I suppose I’ll blog about them. That’s a little tricky to do, since many of them might be a “designed that way, but incompatible with [ade]” thing that I just don’t know about and I don’t want to come across as whiny or demanding (I’ll save that for licensing issues). And I don’t think that things like “Akonadi startup screen gets in the way” are worth filing a bug over, not until there’s some consensus that it is a bug. See also the “logout sound” thread on KDE core-devel right now, that feels similar.

Anyway, it’s good to see that the next release will be pretty solid, also on OSOL; if you want to take a peek, bother me at FOSDEM this weekend (just before the 4.4.0 release!).

Another week gone by an no end to my cold in sight. This is getting to be really annoying, as it both fragments my work day and makes me unreliable in responding to just about anything — so various jobs (both real and hobby) have been falling behind.

The hobby bits are easier to write about, so here goes: I wanted to produce a screenie of Krita on OpenSolaris, but it turns out that it hand not been built in my first packaging (neither had KSpread, for that matter). Turns out they require Eigen. Eigen is a C++ template-based linear algebra library. So I installed the Eigen package (also produced by the KDE4-OpenSolaris project: make no mistake, this is a small group with a big software stack to take care of). That’s where the fun starts — I don’t think anything else makes serious use of Eigen. Maybe some stuff in KDEgames or KDeedu, but obviously because I hadn’t had Eigen installed previously, they (if they are there) have been silently ignored.

So, Eigen. Since the KDE4-OpenSolaris project aims to use the Sun Studio compiler (so that the resulting KDE4 could be included in the base system and so that i t can re-use any other C++ infrastructure in the system), we need to make sure that Eigen works with the compiler. In the case of a giant and complicated template library, that can be a big effort. And I’m immediately stymied by the Matrix class, where the compiler complains about multiple definitions of every type in the Eigen generic interface (Base, Scalar, and another half-dozen). I’ve not even managed to strip the examples down to an example that demonstrates the problem, which makes debugging — or asking the compiler gurus for help — difficult.

Suffice to say that Krita screenshots are not to be expected anytime soon.

On the upside, the release of KDE SC 4.4 RC2 means that the other bits are nearing stability, which means we can re-focus on stability and performance on OpenSolaris for a bit. Since Pavel has set up various continuous builds on our crunchy build box (courtesy of Sun Netherlands) so tracking in future should work a little better — I hope we have fewer separate patches to maintain in future as more stuff gets upstreamed.

Inge Wallin recently blogged about the portability of KOffice — spurred on, no doubt, by the success of the port to the Nokia n900 and to Haiku. So he listed GNU/Linux, Mac OSX, Windows, FreeBSD (thanks, Inge, for checking), Haiku. That list is missing (Open)Solaris though, which as a UNIX flavor. ought to be a pretty simple target.

Of course, Solaris has been a primary target for OpenOffice for ages, so KOffice is a little late to the game on this particular platform. But I guess that’s my fault, since I’m one of the packagers for KDE4 on Solaris, and I hadn’t gotten around to it yet. So this weekend I spent a little under two hours hammering together a specfile (RPM-style) for koffice and getting the whole darn thing to build. Screenshot of KWord in action as proof. I tried KPresenter as well, but that crashed on changing the list style, so I didn’t think that was a good demonstration.

Of course, no port is without its patches, so here they are:

• constness — this patch matches the constness of parameters in definitions with those in declarations, so that int foo(const int) is defined with int foo(const int i) and not as int foo(int i). Now, since the last time constness-matching blew up, I’ve learned that this is really a bug in Sun’s compiler, because constness is not supposed to be mangled into the name. However, I’ll claim that code neatness demands that they match, anyway.
• double — some math functions like sqrt() can take both float or double, and Sun’s compiler doesn’t just pick one when you pass it integer parameters, so we need some explicit disambiguation. This is common all across the KDE codebase.
• NaN — the KOffice code uses val != NAN which uses the gcc-specific NAN #define; probably !isnan() is better.
• math — the header file math.h in Solaris uses the identifier “exception”, which becomes ambiguous in the context of the STL, so it needs to be included earlier, rather than later. This patch bungs in math.h as the first include in a number of C++ files — not necessarily something to merge upstream, because it’s mostly working around a bug elsewhere.
• stupid — yes, this is a stupid patch. I can’t convince Sun Studio that 8.5 * 1440 is an secretly an integer constant and that it shouldn’t complain about a bunch of initializers in the MS Word import filters. I’m not really sure what’s going on here, it’s something special about static const initializers of class variables, since doing the same in a non-class context works just fine.

So there you have it. Five tiny patches for a codebase of a little over 600000 lines of code. Nice. Tip of the hat (I have lots of hats, but all of them are baseball caps and I don’t have a decent Stetson) to Inge and the KOffice folks for a nice portable office suite. You may be troubled, but your code is good.

LinuxTag in Berlin is one of the recurring and very fun events, both on the community and business sides of the Free Software equation. The call for papers is open until the 29th of January. The NLUUG spring conference on systems administration has a call that is open until tomorrow, but tends to be somewhat lenient in the submission deadline. I think it would be cool to have a talk on “Konsole as a sysadmin tool”; I don’t think general Free Software talks fit the bill all that well. There will probably be an FSFE stand at the conference, though, to talk about licensing and the importance of Free Software in sysadmin tasks, even if it’s not an all-that-obvious fit for the conference theme.

Though the call for papers closed a long time ago, you can still attend CampKDE starting on Friday. This is the North American get-together of KDE developers and users, in San Diego this time around.