Bobulate

I really like it when new software packages are mentioned in blogs or on the dot. Those — based on a combination of personal interest and seeing how the community reacts — drive my selection of packages for OpenIndiana and OpenSolaris (such as it was). Something like the dot story on Sentinella says to me “this is interesting software.”

So I’ve started to package Sentinella, and you can find progress in the -460 repo. What progress? You ask. Yeah, it’s not trivial and the code shows some gcc-isms, for which I have filed bug reports. So as of this writing, there’s no Sentinella spec file in there. It’ll come.

I spotted a new poppler release (1.5.2) in its work towards a 0.16 version. I think I spotted that in a Freshmeat RSS feed somewhere. Packaged most of that up, although it too has some gcc-isms. Balked at registering for the FreeDesktop bugzilla, here are the patches. A gcc-ism for variable-length arrays, introducing a Solarisism for RPATH, using the <ios> header to get std::hex and std::dec, and a gcc-ism around unicode strings. Simple.

Speaking of unicode strings, it seems that gcc will take “\u0161″ as a unicode string and encode it in UTF-8 as two bytes. The Sun compiler doesn’t like that as it interprets \u0161 as a UTF-16 character, which doesn’t fit in a char. On the other hand, U”\u0161”, a unicode character string, is not a char * but a short *. I ended up using gcc to determine that “\u0161” is the same as “\305\241” (octal!) and patched poppler to use that.

But while searching for some information on unicode strings, I found Lukas Lalinsky (see, no unicode for me; sorry Lukáš) blogging about taglib releases, so I bumped that one as well.

I guess the summary answer to “how does software end up in the KDE4-Solaris specfile repository and package server?” is “it’s a crap-shoot depending on what I notice.” That’s not entirely good, but it also means that we’re largely driven by KDE needs.

In closing, a shout-out to Jarosław and the KOffice folk for providing some really useful information for packagers. That deserves a whole separate post (e.g. when KOffice is indeed packaged for OpenSolaris and OpenIndiana).

The OSOL appliance released by Jignesh Shah is 2009.6 — nearly a year old now. Since then the packaging tools for OpenSolaris have made great strides. IPS remains .. interesting. I’m not entirely convinced that it was worth the effort of not using some of the existing package formats. However, by now I understand the API it brings in as well as the various uses of the tool, (and it crashes no more) so I’m starting to like it.

Anyway, the point of this particular appliance is to host KDE4 packages for OpenSolaris in an IPS repo. To do that means running the IPS pkg.depotd. I have a port of an older version of pkg(5) to FreeBSD, but it all seems a little klunky and hard to maintain. So using an OpenSolaris VM seems the right approach.

Except that the OSOL VM from Jignesh is kind of old, isn’t it. So I ended up looking into upgrading the OSOL VM after installation, and ended up with the following steps:

1. Set the publisher to the dev branch: pkg set-publisher -O http://pkg.opensolaris.org/dev/ opensolaris.org . This means that future packages will come from the dev branch, not the released branch.
2. pkg refresh --full to fetch all the new package references.
3. pkg image-update -f (I have to force it, because something’s wrong with cherrypy and the image will not update otherwise) and wait a while while 138MB of package updates are downloaded.
4. Reboot into the new boot environment (VOSApp-1). This will fall into a root shell for fixit-purposes, because the filesystems are messed up.
5. Fix mountpoints for those messed-up filesystems and reboot again; I recall I needed to re-set a number of zfs mountpoints to get the correct organization for regular system operation. Bear in mind this isn’t needed with normal OSOL upgrades, just for this slightly peculiar application setup. I think I had to set the new rpool/ROOT/VOSAPP-1/opt/ (and var and root) to mount in the right places and move the older rpool/ROOT/VOSApp/ filesystems to somewhere in /mnt.
6. Reboot, possibly fix up remaining mountpoints, then zfs destroy the old ones.

There’s a useful HOWTO entry on updating OSOL to a specific build which I might otherwise have used, but the appliance image does not have an entire package installed which could be used to drive the upgrade. Hence this slightly klunkier approach.

Since Jignesh has left Sun, I’m not sure if there will be any future growth in these appliance builds. They were popular enough in Nigeria, where I distributed verbatim copies of the original (probably still in violation of the license terms though) to people interested in running OSOL at all.