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

A bit of a belated thanks to Albert and Frederik for providing information about updates in dependencies needed for KDE4 — even trunk things as it works towards the 4.6.0 release of Plasma Desktop and the KDE applications.That kind of "heads up!" makes it much easier to keep the whole software stack up-to-date. Shortly after reading their blog entries, I updated (attica) or added (ebook-tools) specfiles to the specfile repository for 4.6.0. ebook-tools needed libzip, which as far as I could tell wasn’t available yet either (caveat: Oracle basically stopped updating all the package repositories and the SourceJuicer efforts, so the past four months have seen total stagnation on the official front for software packages, so it’s possible that someone else has already packaged the stuff elsewhere). Anyway, it’s appreciated, and those packages will affect the next package release on OpenSolaris.

We’ve just bumped the build to KDE 4.5.68 snapshot (in the -460 repository; the -450 one remains at 4.5.1). The builds haven’t finished shaking out yet, though. We’ve rolled a Phonon 4.4.3 tarball (apropos tarballs, I really enjoy reading Valorie Zimmerman’s blog for a reminder of what it’s like to start out in developerland) from git for internal use. QScintilla and the Python bindings for it have been added. Those aren’t directly useful in KDE, but they’re nice to have. I have tried a bunch more PyQt applications and they all seem to work ok, so I’m declaring those bindings "good enough."

Bug reports and patches can go into KDE’s bugzilla bugs.kde.org, with the OS set to Solaris.

Just a heads up that the KDE4-OpenSolaris group has now got KDE SC 4.4.0 beta 1 (version number 4.3.80) building the following components: base, pim, games and graphics. For me that’s what makes a minimal desktop. Getting Akonadi up and running was the biggest challenge, because it needed a fix down in Qt related to bit-twiddling, compiler flags related to aliasing, and mutexes. One line, but it took quite some time to hunt down and rebuild.

You can get the sources for the specfiles here, and build from source. It will take a while. If you’ve built Qt 4.6.0 previously from the repo, do remember to remove it first because of this mutex change (we still don’t have a good means of getting pkgtool to decide when to upgrade). Background information for this effort may be found on KDE Techbase.

I’m writing these lines from inside Konqueror 4.3.80 on OpenSolaris. I wrote previously that Konq is much better with WordPress nowadays, so that means I can blog from a browser I like under an OS that I like (or I could boot into FreeBSD and do the same thing thanks to the efforts of miwi and the gang). It was Sinterklaas this weekend, and the ole Sint brought the kids too many toys and brought me updates to the spec files for KDE software on OSOL.

Ben Taylor has picked up the prodigious (or is it Sysiphean?) task of updating the dependency tree for Solaris 10 again.

Elsewhere in the stack, strigi was updated to 0.7.0 (thanks Jos for having an official release available), shared-desktop-ontologies was added at version 0.2 (a simple build), soprano was massaged once, then virtuoso added for version 3.52.7, then soprano massaged again, then cursed, then discarded. Then all the staightforward stuff involved in updating libs, pimlibs, base-* — that is basically updating packing lists to reflect new or changed files and removing the patches that we had pushed upstream.

Virtuoso was .. a trial, in any case. I don’t even understand why the dependency is referred to as Virtuoso when it’s about libiodbc; at that point I end up wondering why we require one ODBC library and not another (e.g. UnixODBC has a Qt SQL driver and is KDE friendly). Maybe there’s more undocumented dependencies underneath there — but I can’t find anything about it. Albert seems to be compiling something completely different when he mentions Virtuoso.

Getting libiodbc to compile at all (the code isn’t all that bad) did show up an interesting pattern: there’s a wchar_t based API and a char based API available, and the interface header does this:

#ifndef SQL_NOUNICODEMAP
#ifdef UNICODE
#define SQLInstallODBC SQLInstallODBCW

This is fine (sortof .. it’s very C-ish) except when the same interface header is included from the library itself. Since the library contains definitions for both SQLInstallODBC(char) and SQLInstallODBCW(wchar_t), the compile breaks. You end up with two definitions for SQLInstallODBCW() instead of one of each. That meant going through and patching each file in the library to not be stupid that way by adding #define SQL_NOUNICODEMAP (I suppose I could have added it to CFLAGS instead). It’s apparent that noone has ever tested this stuff with UNICODE turned on (or perhaps more restrictively, on Solaris with UNICODE on).

Once the library is no longer stupid then it turns out Soprano itself isn’t all that secure about the difference between wchar_t and char. If UNICODE support is on, then consider a line like this one:

SQLExecDirect( hstmt, ( UCHAR* )utf8Request.data(), utf8Request.length() )

Explicitly munging a UTF-8 request into UCHAR (um .. I’m not sure that the non-unicode interface is supposed to understand UTF-8, really) is going to break if that function is #defined to version that expects a wchar_t parameter there. All in all enough to make me give up on this rapidly and think about other parts of the stack instead.

Since there’s still no KDE 4.4 compilation requirements posted on KDE Techbase as of this writing, (and I don’t feel qualified to add it myself based on my rather grumpy interpretation of what needs documenting) it’s hard to figure out what we should be looking for.

Anyway, in positive news all of KDEBase built for 4.3.80, so that’s why I have konq and konsole; PIM needs some additional new patches (remember: if Akonadi, then add_includes(${Boost_INCLUDE_DIRS})) but on the whole it looks like fairly smooth sailing. Expect updated specs for a build maybe next weekend when Ben and Hajma have finished thrashing the repo.

Qt 4.6.0 is out. That’s the first of the trials and tribulations for today, because it suggests that packagers should update their work on Qt. Which is one of those things that can take up to half of a KDE SC minor release cycle to get right. And when you find code in WebKit that has actually shipped that looks like this (real version in FastMalloc.cpp line 1438):

void *foo() {
#if COMPILER(MSVC)
  // Without this, Visual Studio will complain that this method does not return a value.
  return 0;
#endif
}

.. then it’s not so much reading Qt code as it is looking at the DailyWTF. No duh, you need a return statement to return a value. WebKit has other bits of badness in it as well, like missing configure checks. Remember when it was all the rage to check if the platform had char *strnstr() and then working with HAVE_STRNSTR instead of going #ifdef Q_OS_WINDOWS? Anyway, our sixteen variegated patches against Qt 4.5.3 still mostly apply, so I’ll go and experiment with them.

But actually I was trying to start updating the packages for OpenSolaris in the run up to KDE SC 4.4.0, which is still two months away. Fortunately Hajma has wrestled with KDE SVN trunk compilation and the dashboard now, so we have some idea of what’s going on in trunk and can slay bugs (happy constructor pattern seems popular again) as they show up. However, building from SVN checkouts (including all of kdesupport) is a world apart from building packages where you’re looking for released tarballs, clear dependency versioning and good documentation. Unfortunately, the Techbase documentation for KDE SC 4.4 requirements isn’t started yet as of this writing. It strikes me that there’s nothing about the parts coming from kdesupport in the 4.3 requirements either — I must have missed a memo somewhere.

Soprano just released a new version, 2.3.70, meant to work with the 4.4 beta cycle, so we can get started on that. Phonon is a bit trickier, since there’s no version check for phonon done in KDEbase-runtime (in the released 4.3.77 tarball, at least) and it fails sometime during compile with a missing phonon/globalconfig.h. The strigi website hasn’t been updated in over a year, but I know Jos has been doing releases of it — I just need to find out where to get a stable tarball.

Maybe it’s just a month too early to want to build KDE SC 4.4 against anything resembling release packages or on top of a stable software stack. Certainly when the stack that you’re delivering (various support packages, then the KDE development platform, then applications and a desktop on top of that) is very deep it can be tricky to get everything in sync, but it does place a burden on packagers. There’s a lot of stuff to update when a new release comes out, and not much time to do it in (which, incidentally, makes the KDE-FreeBSD team’s 4.3.3 packages all the more impressive to me — now if only 8-R didn’t have that little root hole).