It’s been an annoying couple of days on the packaging front in our OpenSolaris land. Having gotten everything to build nicely on our big build server, I copied the resulting packages over to my old amd64 workstation to see how they did – and they didn’t. Some of the packages didn’t even install, with mysterious failures in the package installer. I think the first rule of OSOL Packaging Club is: don’t talk about OSOL packaging, it sucks. Talking to the packaging guys at MPK about the new setup (IPS?) shows that there’s real awareness of the problem and a good engineering effort to fix it (after which rpms will at least be installable in a sensible fashion, I think).

So, throw away the packages and build from source again. At which point another dozen build issues crop up. Gettext and libiconv in particular are annoying with circular dependencies, long build times and weird Makefile constructs. But, having gotten through that, there’s the payoff of getting a working Qt, right? Well, no. My first round of getting Qt going led to apps which hung (all of them with a GUI) while the current setup is such that designer will pretty much take the system down in a swap storm, while linguist and the grandients demo work quite nicely. So there’s still plenty to debug there – Marius has his work cut out for him.

Our packaging setup builds 32- and 64-bit libraries and binaries out of everything. That’s wonderful, except when you’re building on a single-CPU setup and intending to use only the 32-bit binaries, then compiling everything twice suddenly seems like a properly bone-headed thing to do. So I’ve added extra code to optionally disable the 64-bit build even if the machine would support it. I’m telling you, going from 16 cores to 1 for compiles is quite a shock.

But there’s a variety of good news as well. The KDE OpenSolaris community continues to grow; our inspector Frost writes LSD-inspired bits and pieces on OSOL and KDE and acts as a general brake on productivity in the IRC channel by asking how things works. That’s a good thing – it’s a reminder that our documentation needs maintainence as well. The Techbase page for KDE on Solaris is invariably out-of-date and often missing something crucial. Since we’re in a pre-alpha stage this is to be expected, but it also leads to questions from people who are trying to follow the instructions too closely. We also have packages now of at least KBE, and those packages seem to work well enough (not the FOSS ones, though).

KDE 3.58 is available (and the actual screenies and report); this is parallel work to what I report as “work by the KDE Solaris team.” Using gcc is one way to save yourself a lot of headaches, that’s for sure. It’s also not the official supported platform compiler, which means part of it is wasted effort with respect to getting the software into some kind of long-term-support state. Still, dependencies that are massaged into shape and which can be shared between KDE3-gcc and KDE4-sunpro are useful, and it means that folk who want a modern KDE3 desktop on OpenSolaris right now can go that route. I think I shall be downloading it fairly soon, as CDE is really driving me nuts.

The Wayback Machine ⏲ does not archive everything. Broken image links are marked with a 💔.