How new software ends up on KDE4-Solaris

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

Tags: osol, packaging, specfile, update