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).
- 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.
- 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.
- 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”.
- 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.
- 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.
- 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.
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
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.
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?”
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
While 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
- 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.
Most distro’s that ship Plasma Desktop as .. well, as a desktop to work in, have their own default wallpaper choice that isn’t exactly the upstream default. OpenSUSE has things with geekos (which I personally really like, for their understatedness). KDE neon goes for the upstream default, but that is the nature of that particular distro.
The FreeBSD packages of KDE4 had a nice variant of vertical blinds (here’s the OpenSUSE variant — FreeBSD is blue and with a FreeBSD logo). I think that was done by Ivan. However, we’re getting close to a release of Plasma 5 Desktop and workspaces as well as KDE Applications for FreeBSD, and it’s time to think of a new default wallpaper for the FreeBSD packages. Something lightly branded. So this here is a call for contributions for a KDE-FreeBSD wallpaper for use with the first (FreeBSD) release of the current generation of KDE software.
(I know personally I’d like some combination of Flying Konqui with a Beastie logo, but we’re open to all kinds of ideas.)
The Qt5 (meta-)port and all its dependent ports have been updated to Qt 5.5.1 in FreeBSD. Special thanks to Yuri Victorovich, who did an independent Qt 5.5.1 port and whose work has been gratefully incorporated into this update. Thanks also to Ralf Nolden for pushing for better upgrade-paths and co-installability.
Users of Qt5 on FreeBSD are advised to consult the UPDATING file, as some ports have been split. Users of Qt4 are unaffected by this change; Qt4 and Qt5 can be co-installed on FreeBSD.
This update opens the doors to (finally!) getting KDE Frameworks and KDE Plasma Desktop ports into the official ports tree.
There is no Qt5 option in the nethack 3.6 port, nor is there one planned.
A little over a month ago I wrote about Nethack 3.6 being released. I haven’t ascended in it yet — Kerbal Space Program has been occupying spare cycles instead. But after a bit of massaging and extra goes-around because of the way FreeBSD ports get updated, the nethack 3.6 port has now landed in the official ports tree. I don’t think there’s a package of it yet.
This is my first port to hit the official tree. Zanshin will follow.
KDE ports updates are getting nearer, since the KDE-FreeBSD team is now doing exp-runs (those are rebuild-everything-with-an-updated-port build jobs that touch all supportd FreeBSD versions and architectures) for Qt 5.5 and the latest CMake. So there’s a whole slew of ports updates looming on the horizon.
Today I built quasselcore for FreeBSD on armv6 — well, I say today but it took about 20 hours of cross-compiling to get all the bits, then another 10 minutes to repackage because all I wanted was the core, to run on my BeagleBone. So score one more qt5-based package that works on FreeBSD on miniature machines. While building, it touched on LLVM, and BSD, and maybe IoT, and that finally reminded me that I needed to get my butt in gear and actually book travel for FOSDEM.
I’ve skipped a few years, but I’m looking forward to seeing some of the familiar KDE faces there, as well as finally meeting a couple of the KDE-FreeBSD folks. There’s a long list of familiar faces at the Legal Devroom. For once, I have a plan of talks that I want to see, even some that I can claim are work-work related (yay!). Whether I’ll be useful at the KDE booth, I don’t know: last time I was there there was Plasma-desktop to be demonstrated and me with still KDE4 on my laptop. I’m not a good poster child for the modern generation.
As usual, I expect there to be waffles and too much beer and much random Free-Software joy.
Thanks to the Chakra announcement, I could copy-and-paste the title of this blog post. Thanks, folks.
The latest round of software releases by the KDE Community — Frameworks, Plasma, and Applications — can be found the KDE-on-FreeBSD community’s area51 repository. These are unofficial ports, not yet included in the official ports tree.
One day, these ports will all be merged upstream, but not yet. There are some steps to be taken first. One of them is updating Qt upstream, to Qt 5.5. I’m told this is “somewhat close”. When that is done, it becomes possible to introduce the newer KDE releases as well. The integration issues aren’t so much the KDE software itself, as getting everything in ports to build and build nicely.
Once that is done, you can expect KDE Frameworks 5 to start infiltrating the ports tree, and then the whole flood of Plasma Desktop and the KDE Applications.