Look at my horse
My horse is amazing
This is the last of the KDE e.V. board photo montages I’ll do from our recent board meeting in Berlin. You will note that we have considerable skills in rodeo riding as applied to dragons. But for a much better view of the KDE community (“KDE”) you should take a look at the planet or the dot.
Just because the source code isn’t all delivered in a tidy bundle to my doorstep with a thank-you note attached, doesn’t mean that I won’t try stuff out. Thanks to Christoph and Holger for explaining some of the WebKit things to me. In the course of today the KDE4-OpenSolaris folks updated the soprano packages, phonon (from an SVN checkout), and futzed around sufficiently that you should be able to build the Essential KDE Desktop (I don’t know where that fits in the new branding: it’s konsole, konqueror, kmail, plus integration with GDM so you can actually log in). As always, the specfiles and patches can be found in the Mercurial repo.
We still have 21 open bugreports against KDE trunk with patches attached (these are the same as patches in that repo, only reported upstream). That’s still a bunch to “encourage” maintainers to pick up. As a general rule, we commit trivia directly (happy constructors, const mismatches), file bugs on larger items, and try to keep the amount of unmergeable cruft to a minimum. I wrote some such cruft today for Dolphin, where apparently ? (some const KFileItemList method) : KFileItemList() << item isn’t acceptable. Sun Studio is particularly picky about types in the ternary operator; come to think of it a const_cast might have done the trick as well: something to experiment with later, because that would be a mergeable-trivia kind of patch.
Sometimes it’s hard to decide what flavor a patch is: today I added find_package(Boost) include_directories(Boost_INCLUDE_DIRS) to a few subdirectories in KDE PIM; that’s because Boost doesn’t live in the default compiler search path, but Akonadi’s headers #include them — so anything using Akonadi must also have the Boost include dirs in its include search path, which wasn’t the case. It’s a minor change, but it doesn’t scream “trivial” to me, so it’s sitting in our repo as “unmergeable cruft” for now.
All that said, that part of KDE SC 4.3.77 that I’ve gotten up and running is really nice; I’ve said it before, but the stuff integrates really well, including the GNOME network manager and notifications done by the pkgbuild tools when I’m building new stuff and the device manager; there’s still plenty to work on as well, but on the whole it pebbles (a small way to rock). Now if only I could start konqueror or dolphin from the menu or krunner — must be some weird crash going on behind the scenes when there’s no tty output. [[ And as a final shot, I should add that Konqueror is almost infinitely better with WordPress now than it was in 4.3.0. ]]
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).