The Sun Sets on KDE-Solaris

[[ No stories at Akademy this year — well, not by me. Maybe Kevin will write down how he got his students to sleep this year. Heck, I didn’t even put together a not-going-to-Akademy badge this year, and I see it’s been almost a year since my last post, which was after-Akademy-Brno. ]]

The KDE-Solaris site has been shuttered. The subdomain now redirects to KDE techbase, which documents the last efforts related to KDE on then-OpenSolaris. From the year 2000 or earlier until 2013, you could run KDE — two, three or four — on Solaris, either SPARC or (later) x86. I remember doing packaging for my university, way back when, on a Sun Enterprise 10000 with some ridiculous amount of memory — maybe 24GB, which was ridiculous for that time. This led — together with some guy somewhere who had a DEC Alpha — to the first 64-bitness patches in KDE. Solaris gave way to OpenSolaris, and Stefan Teleman rebooted the packaging efforts in cooperation with Sun, using the Sun Studio compiler. This led to a lot of work in the KDE codebase in fixing up gcc-isms. I’d like to think that that evened up the road a little for other non-gcc compilers later.

But OpenSolaris was removed from circulation, and Illumos hasn’t really got much in the way of desktop. The team kind of fell apart as the OS shifted underneath. The mailing list was shut down over a year ago.

This week, the site closed down as well.

So I’d like to take a moment to thank Stefan, hajma, Eva, Gerard, Joep, Alan for their work on  or support of KDE on Solaris over the years. Many others contributed as well — I don’t, and didn’t, know everyone involved, but I’d still like to say thank you.

As one roadway is abandoned, another pathway is cleared. And of course the ruins are still there, lurking in the shrubbery, for anyone with a machete and a Solaris-derivative-OS to rediscover and rebuild, should they so feel inclined. There’s gold (at least dtraces of gold) in them thar hills.

KDE 4.7 on OpenSolaris

Since KDE 4.7 first alpha was released two weeks ago, we’ve slowly started work on KDE 4.7.x specfiles for OpenSolaris / OpenIndiana / Oracle Solaris 11 / Solaris 10 (what a terrible naming confusion — there’s the enterprise stuff from Sun, Solaris 10, which is old but semi-supported by us; there’s OpenSolaris which is dead under Oracle’s boot; there’s OpenIndiana which is an effort to retain Open-Source values in the Solaris OS world; there’s Oracle’s next version of Solaris, heavily weighed down with proprietaryness). I’ll just call it "KDE4 for Solaris" from now on, regardless of the specific flavor or trademark the software is packaged for.

The KDE 4.7.0 specfile repository was just started. It’s a clone of 4.6.0 up until last night, now with some minor updates. I don’t even think we’ve adjusted the KDE version number (from 4.6.3 to 4.6.80) yet. But the stuff will be forthcoming, eventually.

With this alpha release, a number of things have changed in the KDE stack, which is going to slow down at least initial Solaris packaging:

  • Deprecating HAL and several other technologies lower in the stack (I’m not even sure which, but HAL is the biggie). The support burden for these technologies is being moved to the platforms that (still) use them. These platforms include Solaris, FreeBSD and Slackware Linux. Possibly more. This mostly affects libraries that KDE wraps around the lower-down technologies, like Solid. It’s an understandable decision, and I vaguely hope it ushers in a whole lot of test- and test-script writing in order to test various back ends (of which I guess we need at least four, now: Windows, MacOSX, HAL and udev).
  • Changing the structure of the tarballs. These now match the split-up git repository structure. That’s pretty straight-forward to do (in terms of creating the tarballs from the repo) but introduces a bunch of changes in the packaging scripts. (Solaris uses RPM-style specfiles, which point at source tarballs and scriptlets for the actual build process) Where once we had kdebase-apps (one tarball) it’s now split up into bits. Konsole, for instance, is now its own tarball. So we’re forced to decide whether to (a) download konsole’s tarball during the build of our package kdebase-apps and munge the packaging build scriptlet to do it as well, or (b) create a separate package for Konsole and figure out how to transition from konsole-in-kdebase-apps to konsole-in-konsole packages?

The same issues affect Slackware, for instance. I think the KDE-FreeBSD team has already solved much of this for themselves (since it’s a packaging decision, not something to deal with upstream).

Anyway, all this isn’t intended to take anyone to task — just to explain why KDE4 Solaris packages for the KDE 4.7 alpha 1 will not show up quickly.

PS. gcc support in our specfiles is doing pretty well.

Some things Oracle just doesn’t get

Yesterday at the NLUUG conference I picked up a Solaris 11 Express CD in a nice brownish CD sleeve (I say "nice" because it feels and looks different from the generic white sleeves). Here’s a scan of the back of the sleeve, with a big sticker over the flap (click on image for a larger, readable version).

scan of cd sleeve

I thought shrink-wrap licenses went out with Disco, or something like that?

A little searching gets me to the license text so I can read it before opening the package to get at the license itself. The one saving grace is that the license condition is "opening this sealed software package and using the software" (emphasis mine) so it’s not classic shrink-wrap.

In classic fashion, though, I can’t give away this CD to someone else, not even if they want to use it to develop or demonstrate an application on Oracle Solaris.

If we turn to the license text itself, the section on "Open Source Software" rubs me in every possible wrong way, starting from the definition

"Open Source" software – software available without charge for use, modification and distribution – is often licensed under terms that require the user to make the user’s modifications to the Open Source software or any software that the user ‘combines’ with the Open Source software freely available in source code form.

It’s increasingly difficult to engage with Oracle Solaris except as a commercial entity; increasingly difficult to easily check if the software you produce (you in the sense of "a Free Software community") might work on that OS. Combine that with a compiler that’s also increasingly hard to get and, well .. it certainly seems like there’s no interest in third-party software development except on a commercial basis.

We’ve been keeping Qt on Solaris (with Sun Studio) going for three years now. That has led to many patches in the compiler, many in WebKit, and most of the time we’ve got a good working relationship with upstream (i.e. Nokia / QDF). I still think we can deliver a Qt suitable for other applications’ use (maybe not VirtualBox, but that’s still dreamable). Now the Qt modules maturity list shows that Solaris (along with the proprietary UNIXes that still exist; remember at some point Solaris distinguished itself from those by being reasonably-almost-open) is "done". Needs new maintainer. That bodes ill from an upstream-support perspective.

Note about the compiler: you can’t get patches (beyond the released 12.2 version) without a support contract, as far as I can tell. So there’s no easy way to get a version of Sun’s C++ compiler that has all of the bug fixes prompted by the KDE4-Solaris project. The partly-patched version I still have on my Solaris machines is falling behind, so that I can’t even compile all the stuff I’m trying to package. This is one of the reasons the KDE4-Solaris project is looking hard at both gcc and Pathscale.

Quassel bump on OpenIndiana

Folk — ok, just Johannes — showed up in #kde4-solaris asking about Quassel packages for OpenIndiana. Quassel is a disconnected IRC client, useful if you move from computer to computer regularly and want to take your IRC session with you. We have a specfile, but it isn’t built as part of our usual KDE consolidation. The specfile was also still version 0.3, which is pretty darn old.

With that as motivation I’ve bumped Quassel to 0.7.1. It compiles, without much patching (available in the Mercurial repo), just one gcc-linuxism related to stacktrace C++ name mangling. Easy to replace with the code we already use in kdelibs, or for simplicity with backtrace(int fd). Packages will be available shortly.

KDE4 on OpenSolaris update

The KDE4 on OpenSolaris project carries on. The right adverb is probably "doggedly". We continue to follow KDE releases of the KDE Plasma Desktop, Applications and Frameworks. The TechBase page has been somewhat updated (although I’m not really clear on whether that kind of project belongs there or on The 4.6 branch for specfiles is updated regularly and the package server is a fairly up-to-date 4.6.1 (even if it is called "4.6.0").

If you take a look at the specfiles, you will see that recently the Solaris 10 support has been revived. Ben is making great strides in getting first Qt and then the rest of the stack to compile on Solaris 10. That involves a lot more than the stack on OpenSolaris, OpenIndiana or Oracle Solaris 11 Express, because there’s so much very old software that needs updating or replacing on Solaris 10.

We do bump our head on the build system, even on the newer platforms. KDE does tend to want the latest in development tools, particularly CMake. There’s also a Virtuoso and a Boost update looming for us, which are also running into new and innovative compiler bugs.

We may branch out in the world and start equipping our specfiles with more compiler options — Sun Studio is becoming problematic. Once upon a time it was a free (as in beer) compiler with some hope, somewhere, of becoming Free (as in speech), but that hope is fading fast, and the compiler with patches is now hard-to-get. We’re actively considering bringing g++ on board — that would defeat one of the original goals of the project, which was to keep KDE written C++ (as opposed to whatever dialect the current version of g++ speaks). It should be noted, though, that g++ has gotten much much better: what we really need is to turn off gcc-isms through compiler flags. Anyway, that’s for future work.

For now, KDE 4.6.1 chugs along on Solaris variants — and also still on Sun Ray thin clients, although I can recommend you don’t try it on a Sun Ray 1.

KDE 4.6.0 on OSOL

Although KDE 4.6.0 was released nearly two weeks ago, I had not yet gotten around to announcing the availability of KDE 4.6.0 packages for OpenSolaris / OpenIndiana. The KDE4-OpenSolaris team (mostly Jan and Pavel right now, since I’m distracted) are really on the ball and the packages went up on release day. You can find them in our pkg repository and the corresponding specfile repository.

[[ Shout outs to other packages: Gökmen, wow. That’s slick. If I was going to be anywhere near FOSDEM, I’d line up behind Jos in congratulating you on a nice release. ]]

Newer OSOL packages

KDE 4.5.4 (why wasn’t that codenamed "pound" or such?) was released some time ago, so there’s updated OpenIndiana packages available. You can find them at the KDE 4.5 package repository. The naming is now deceptive: it’s KDE 4.5.4 in the 4.5.3 repo. Use specific FMRIs if you want to stick to the previous version. Only KDE packages were updated, so all the dependencies stay the same.

We have decided to drop OpenSolaris build 134 as a target. You can use these packages on OpenIndiana build 147 or later or Oracle Solaris Express build 151a. Maintaining compatibility with the older OSOL was increasing the complexity of building packages, putting our resources under strain. So we dropped it. We’re also still on the fence regarding Solaris 10 — no one seems to want it, which means that it may be swept under the rug sometime as well.

KDE 4.6.0-beta1 packages available for OpenSolaris, OpenIndiana

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 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.

Futile? Yes, but not pointless (Qt 4.7.1 on SPARC)

I feel so conflicted. Just look at that screenshot.

Qt 4.7.1 demo browser running in GNOME, on Oracle Solaris, on SPARCv9

Qt 4.7.1 demo browser running in GNOME, on Oracle Solaris, on SPARCv9

I was considering starting this blog post in a mad-scientist fashion, “mad, was I? they said I was mad to try! haha! and now I shall unleash my creation upon the world and show them all! hahaha!” but I’ve probably done that before. So what you see there in the screenie is probably the first WebKit browser running on Solaris on SPARCv9 hardware. It is the demo browser from Qt 4.7.1. Compiling Qt took just under six hours, I think, but I went shopping in the meantime.
So this is ultimately futile: SPARC hardware just doesn’t get used for the desktop, does it. However, the KDE4-OpenSolaris has had requests from various folks about Qt on SPARC, built with our optimizations and with the Sun Studio compiler. So now it’s here. That is to say, it compiles and some bits run. We still need to figure out how to merge packages so that the IPS repository will spit out a suitable Qt package (either x86 or SPARC). The pkg(5) and pkg.depotd(5) programs know how to handle multiple architectures, I just don’t know how to move the files around to achieve that.
But this exercise isn’t pointless. It shows up how portable Qt is (within the X11 world, anyway). It shows that the packaging setup that the KDE4-OpenSolaris group has set up actually targets the things we said we wanted to hit (which, even after revising away Solaris 10, still includes SPARC). It might help a teensy bit with code quality to consider the warnings a different compiler throws out — although stuff like "textedit.cpp", line 154: Warning: tb hides TextEdit::tb. isn’t useful in my book.
Another thing this experiment shows is that there is more work to be done in catching CStd-based firefox plugins. The Qt demo browser cheerfully tries to load the flash plugin and then falls over because of bad library initialization (when mixing different STLs, see this post of mine for some details) if there’s any interesting media on the page. In the screenshot, we see, which doesn’t do anything fancy.
So there you go. One more platform Konquered (er .. it’ll take another week to get through to KDEbase).

An exercise in futility (nv151 on Ultra 45 with XVR-2500)

Oracle has released Solaris Express 11. That’s a binary-only preview of Solaris 11, which picks up somewhere after OpenSolaris was killed. The kernel identifies itself as snv_151a. As an exercise in futility, I decided to install this on my Sun Ultra 45 workstation — a SPARC machine. Of course I’ll be doing so only to evaluate the software I am creating (or packaging) for the Operating System, not putting the machine into production use — which is what the onerous license agreement (it’s even difficult to find the URL to link to!) demands.

I have a SPARC-based workstation under my desk, from the time that we in the KDE4-Solaris project actively targeted SPARC; that’s some time ago. The machine is still there and I like the architecture, so I try to use it every now and then. With OSOL this was always problematic. Solaris 11 seems to change that a little.

Solaris 11 comes with a text-based installer for SPARC, which is good enough. It doesn’t seem to come with a graphics driver for the XVR-2500 card that’s in the workstation, though, as the boot process tells me that the pciegfx domain will not be used.

For me it was a little confusing that some GNOME packages were installed — like gnome-audio — but no X server or display manager. Text logins are fine, but in order to test my software at some point I’m going to have to actually run X on it. Given the speed at which this machine compiles (random hardware begging: anyone have 2x1GB DDR PC2700 ECC DIMMs left over? Or four of them, for that matter? How about an UltraSPARC IIIi CPU @1.6GHz?) I’ll be happy to get through to Qt sometime in the next seven days. And let’s face it, Qt 4.7 keeps trying to outsmart the KDE4-OpenSolaris team by saying that it’s partly incompatible with Sun compilers — but in the case of Sun Studio 12 on SPARC it might be right 🙂

Turning the SPARC machine into a usable GNOME box took steps like these:

pkg install xorg evince gnome-terminal gdm
pkg install xorg-video kfb xorg-kfb fbconfig-kfb
pkg uninstall xorg-video xorg-video-wsfb

That last uninstall was to get rid of the wsfb driver which crashes Xorg. After mucking about a bit I got some advice on IRC, from the indomitable Alan Coopersmith in particular. You can find some of his work (newer Xorg) on the OpenSolaris forums. So two essential things: "fbconfig -dev kfb0 -defaults" and "pkg install slim_install", then reboot. So thanks, Alan.

The machine will come back but still be in text mode. SSH is enabled by default, so you can SSH in from another machine on the network and start the gdm service to get a login prompt. with “svcadm enable svc:/application/graphical-login/gdm:default“. If you watch the console, after about 15 seconds you get a gdm login screen. On the one hand, it’s tastefully done with some transparency applied around the session and language selectors; on the other hand there’s this giant Oracle logo on there like “abandon all hope ye who enter here.” And a kind of icky hex grid background and default wallpaper, as if drone-like creatures are going to lay their proprietary eggs in your brain and cause you to surrender your will. Ugh.

Why does the Oracle logo look so out of place on a GNOME desktop where the OpenSolaris one didn’t? Seems strange to me.

Anyway, it seems that Oracle have delivered a technically sufficient OS release for SPARC workstations. I can start compiling stuff on it now (some setup scripts will surely be added to the -460 repo as I carry on with that). Making a SPARC machine a usable development workstation takes another whole bunch of packages, just some of which are the Mercurial and the C++ compiler (you could choose gcc instead, but that’s not the mandate of the KDE4-OpenSolaris project). The Sun compiler is not available from the Solaris 11 package repository right now, so get it from the older OSOL repo:

pkg install mercurial
pkg set-publisher --non-sticky \
pkg install sunstudio12u1