Home [ade] cookies

Tribulations of a packager

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() {
  // Without this, Visual Studio will complain that this method does not return a value.
  return 0;

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


8 Responses to “Tribulations of a packager”

  1. chicken and egg Says:

    hi there,

    the globalconfig.h ist in the phonon from kdesupport. If i am not misunderstood, kde 4.4 uses phonon from kdesupport and not the phonon from QT

  2. Christoph Says:

    Hm, Strigi, Soprano, Phonon, and even the brand new Shared Desktop Ontologies (for Nepomuk) are all part of trunk/kdesupport. Do I miss something?

  3. Holger Freyther Says:

    FastMalloc.cpp:1438: The return statement is never reached, so maybe we should plant a ASSERT_NOT_REACHED in there to hint the compiler..

    Missing configure checks: That is not so much a problem with WebKit/GTK+ where we are using autoconf and can easily handle these, for Qt we solely rely on capabilities of qmake.

  4. Karellen Says:

    “it’s not so much reading Qt code as it is looking at the DailyWTF.”

    Surely the clue is in the fact that FastMalloc.cpp is actually in a directory *called* “wtf”!

  5. adridg Says:

    @karelten: Took ages to realise is was the Web Toolit Framework, too :)

  6. adridg Says:

    A /* NOTREACHED */ would help, already — but is there any reason at all to #if away the un-reached return statement? Is there a measurable performance gain for those compilers that don’t bother checking for values returned that would justify shipping code that is wrong like this? As for autoconf — point taken. In that case, kludgy patches like adding || Q_OS_SOLARIS in wtf make sense. Or as much sense as they can.

  7. adridg Says:

    .. and kdesupport isn’t released for any of the “unstable” alphas up until now, which was pretty much the point here: there’s a hole in that stack that hasn’t been released, even if the code is available from KDE SVN.

  8. Christoph Bartoschek Says:

    The method scavengerThread() called directly above is annotated with the remark NO_RETURN. Normally this should be nough to pacify the compiler. But it is obvious why MSVC complains here. The macro is not defined for it.

    There are however two other problems:

    1. runScavengerThread is passed to pthread_create although static class members are not allowed there. Only functions with C-Linkage are allowed.

    2. There is no way to clean the thread up. One could argue here, but in my opinion there should always be a way to do this.