Digikam updated in area51

The latest version of digiKam has been added to the unofficial ports tree in area51. The unofficial ports tree is where the KDE-FreeBSD team works on ports in preparation for their inclusion into the official ports tree. The trunk of that repository is basically “what’s next” for the official ports tree from our point of view. There are other branches: mostly plasma5, for the upcoming (from a FreeBSD perspective, at least) KDE Frameworks 5 and Plasma 5; qt5.6 for testing the recently-released Qt 5.6. Official ports will remain Qt 5.5 for the time being.

This has been one of my bigger packaging jobs so far; also one of my first for an application I don’t actually use. Here’s some notes from this packaging exercise (previous digiKam version was 4.2.0 in FreeBSD, so it’s quite a big jump).
  1. For dependencies within KDE — be it frameworks, support libraries, whatever — there’s lots of links to projects.kde.org. Since projects.k.o seems to be going away in favor of other systems of organizing repositories and projects, I foresee a lot of necessary updates fixing URLs / pointers to dependencies. This is easiest to illustrate on the digiKam site, where as of right now, the dependencies-listing page links to a file in digiKam’s git repository through projects.k.o, which now leads to a landing page on quickgit.k.o. From there, it’s possible to find the README file in master, but nowhere near as easy as originally intended. In other words, the change in KDE infrastructure is affecting links and the availability of information to packagers already.
  2. CMakeLists that output a nice list of missing dependencies — also the optional ones — with good pointers to those dependencies are wonderful to work with. Keeping those pointers to dependencies up-to-date (see point 1) is extra work for application developers though.
  3. Unbundling libraries is an unexpected pain in the packager’s butt, even if there’s a nice pointer to find the now-unbundled libraries provided by CMakeLists. The reason it’s a pain is because “update package” becomes “introduce new packages whis may not be co-installable with the old version with bundled libraries; update package”.
  4. Changelogs which are written for usersare pretty much useless for packagers, since they don’t include notes like (see point 3) “Libraries have been unbundled”. At work-work we get things sort-of-right, writing release notes for users and including a separate section specifically for sysadmins detailing internal changes (it’s a Python app, but still ..). Part of distribution outreach is making things easier for packagers by providing this kind of information in an easy-to-find and easy-to-read format.
  5. Changing CMake policies can make the simplest porting job an exercise in wading through gobs of CMake warnings. It would be nice to have a cmake command-line argument complementary to set_policy(). It means that the version of cmake relevant at the time of the software release matters — building a six-month old release with the latest CMake can be problematic.
  6. Translations can be a bumpy ride — appearing one release, vanishing the next. 

These are just items I jotted down based on packaging digiKam. They’re not specific to digiKam, really:  for instance, I just built amor and it encounters some of these points as well.

The update to digiKam 4.14 in the unofficial ports tree is a bit weird, in the end:
  • New ports libkface and libkgeomap,
  • digiKam 4.12 is used to build the libmediawiki library,
  • digiKam 4.14 is used to build the rest of the application,
  • digiKam 4.14 is used to build all the kipi-plugins, including the mediawiki one,
  • the is (Icelandic) translation of the Google Drive plugin has gone away.
I’m actually not sure whether the mediawiki kipi-plugin is still supposed to build: it’s there in the source, it builds if it’s possible, but it isn’t listed among the available plugins on the digiKam site nor has the digiKam team released libmediawiki standalone (like it has for libkgeomap and libkface). We’ve decided to keep the plugin, on the grounds that that is less change in the available packages and Fedora seems to do the same.
Anyway, this unofficial update will hopefully be followed fairly soon by an update to the official ports tree — then the KDE-FreeBSD photography community can enjoy updated software.

Landed updates in FreeBSD

Some interesting things — for KDE users and developers — have landed in the official FreeBSD ports tree recently.

CMake has updated to 3.5.0. One side effect of CMake updates is that newer policies tend to produce voluminous warning messages when building older software (like kdelibs4-based things, which is all the KDE software in official ports right now). This can make it hard to track down cmake / configure errors amongst the warnings. There’s not much to do there except (slowly) update other ports to set the new (or old) policies explicitly.

kdelibs4-related ports now install headers in /usr/local/include/kde4 (where earlier they were in /usr/local/include). This is preparation for adding KDE Frameworks 5 to the official ports tree: since some headers are named the same, we need to be prepared for disambiguating them. Frameworks will end up in /KF5/.

With these two out of the way, we will be able to update some more applications (e.g. KDevelop) alongside the addition of KDE Frameworks 5. After that, of course, Plasma 5 and modern KDE Applications.

Dutch BSD Desktop Dev Beer Day

There’s a handful of BSD-oriented, desktop-oriented, developers in the Netherlands that I know of. Koos. Raphael. Perhaps some remnants of KDE-NL, or a wandering GNOME developer. Or other desktop systems. Anyway, I’m launching the idea to have some kind of get-together around mid-april (when the weather is nice) somewhere central(-ish) like Zwolle or Amersfoort. The Dutch BSD Desktop Dev Beer Day, or (DBD)2. The plan would be to occupy a cafe somewhere and talk about BSD on the desktop, and in particular porting and keeping the desktop stack up-to-date on all fronts.

Consider this post a call for “hey, who would be interested?”

Exp-run for KDE4 on FreeBSD

There’s an exp-run going on for KDE4 on FreeBSD right now. That means that the official package-building machines are grinding through the entire ports tree to see what happens. This is part of the regular procedure for big updates — and this is a big one.

While KDE4 as a desktop — with Plasma shell 4 and the old collection of KDE modules like PIM, etc. — is not getting a lot of upstream releases, it does get some updates, and some applications release new versions. This is one reason to continue to update the packages.

Another reason to update KDE4 on FreeBSD is to get ready for the next generation of KDE: Frameworks, Plasma and Applications. Making things co-installable (and co-developable) means (re-)arranging headers and libraries and whatnot in a nicer way than we have up til now. The kde4 versions of headers now go into /usr/local/include/kde4 (e.g. the headers for libkgeomap).

Once this is done, and the KDE4 updates land in the official ports tree, then the way is cleared for a few updates (e.g. kdevelop, perhaps digikam). And of course the way to landing KDE Frameworks 5 is open then, too: those will install headers probably in /usr/local/include/kf5.

KDE updates in Area51

FlyingKonqui-FreeBSD-2560While I have been quiet on the blogging front, KDE on FreeBSD has not rested. The unofficial ports repository has had a whole bunch of updates:

  • Plasma was updated to Plasma 5.5.5 and then Plasma 5.6-beta in the plasma5-branch.
  • Qt 5.6 has been revived in the qt-5.6 branch. There was an earlier attempt at getting this working, which has been discarded. This time, TCB has also massaged QtWebEngine into some kind of shape.
  • KDE4 has had some small updates in trunk, getting newer kdelibs and newer KDevelop.

The plan is roughly this: get the KDE4 updates into the official tree because they also help pave the way to introducing Frameworks, Plasma5 and KDE Applications ports into the tree by changing up some of the infrastructure. Qt5 is already in-tree. Then KF5 can be added, which will test the waters for parallel-installing KDE4 and Frameworks on FreeBSD. And then the whole hog .. er .. dragon.

Timoth√©e Giet was kind enough to send a Flying Konqui with BSD-bubble. I’m going to try to make that the default wallpaper with Plasma5 on FreeBSD, I think it’s cute. Thanks to him for the artwork, and to Rakuco and TCB for a lot ofall of the heavy lifting in the area51 repository.