Like Christoph, I’m going to Randa! It’s a long train ride, but that means I can get some hacking done on the way.
You can support the Randa meetings! Click on the image for fundraiser information. The Randa meetings are one of the biggest sprints in KDE. Each year a tightly focused group gets together to work on KDE technology for one goal. This year the goal is KDE technology on every device.
While most of the participants seem to be going to the meeting for the purpose of getting more KDE applications on Windows, MacOS or Android — indeed platforms where our technology can make a difference for developers and where our applications can make a difference for Freedom — I’m going with a slightly different purpose. I’m there for our traditional niche platforms: the BSD’s. But also for packaging in a traditional sense, and for building our software effectively and efficiently.
There’s a lot of infrastructure in the KDE software (git) repositories, information about dependencies and build orders and where to find sources and stuff like that. For the traditional packagers, though, packaging is largely an artisanal process: discover what software is released this time, under what names and in which directory; figure out what new dependencies there are by trying to compile the new stuff in an environment that worked for the previous release; adjust sources for invalid assumptions. Lather, rinse, repeat.
Speaking of repeat, Scarlett has been working on reproducible builds of KDE software for Debian. FreeBSD is part of the same organization, so I hope to learn a lot from Scarlett towards that goal.
If containerized apps are really a thing, I’d hope to be able to build FreeBSD(-ish) containers from the same metadata as other containers are built from.
As preparation, I tried to build KDE (as in, the software stack needed for Zanshin) from source on a Linux distro. I failed. To me, that suggests that we shouldn’t forget the devices running Linux, either, and the packagers that work there.
After a long struggle with digiKam (mostly because of the libmediawiki plugin), a brief struggle with KDevelop (it is well-behaved), and a careful struggle with CMake (because lots of other ports depend on it), official ports have been updated (by Tobias Berner and Raphael Kubo da Costa) with the state-of-the-art for KDE4 from the unofficial area51 repository. That means:
- digiKam 4.14.0
- KDevelop 4.7.3
- CMake 3.5.2
Other bits and pieces have been updated as well; what hasn’t been added are zanshin and simon. Those are waiting on a next round of updates. As far as KDE Frameworks 5 are concerned, those work very nicely in area51, but are not yet candidates for downstream (official ports). There are a few steps to go:
- Another round of KDE4 infrastructure updates so that it is compatible with what has been developed in the plasma5 branch for the new KDE Frameworks 5, KDE Plasma 5 and KDE Applications.
- Merging plasma5 branch into area51-trunk and double-checking that KDE4 and KDE Frameworks 5 can co-exist.
- .. then sending KDE Frameworks 5 downstream to the official ports.
I have two things on my “that’s what I’d like to do” list; one is preparing a Zanshin 0.4 with Frameworks port and the other is sorting out the branding of the desktop.
This year, Akademy is being held together with other Free Software conferences, all rolled up into one. The umbrella we all live under is QtCon, and it will bring KDAB‘s Qt Training Day, the Qt Contributor Summit, Akademy, as well as the FSFE Summit and VideoLan Dev Days under one roof (well, multiple roofs; one umbrella). The call for papers is now available.
Because of this wide range of events at one time, there is unprecedented opportunity for presenting your work to a broad audience. I’ll be there; maybe “Keeping Qt going on non-tier-1 operating systems” is a useful talk to give. I really want someone to submit an “Optimizing Qt scene graph through algebraic geometry” talk, too. And a “Biggest video wall in Amsterdam with Qt and VLC”. And “Estimating proprietary development through observation of Free Software development”. And .. gosh, the list goes on and on.
Deadline is may 15th!
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.