Auditing Licenses in KDE Frameworks FreeBSD Packaging

FreeBSD is getting more serious about license metadata in the packages produced by the project — that is, the binary distribution of software produced from licensed source code. A lot of software in FreeBSD “proper” is (naturally) BSD-licensed, and a lot of Free Software packaged by FreeBSD is (also naturally) GPL licensed. But the different licenses carry different obligations, so it’s good to keep track of the exact licensing applied to each bit of software.

To this end, there’s the LICENSE= line in each port’s Makefile. Its meaning is “this software has such-and-such a license”. For conciseness, SPDX identifiers are used, so that you can write

LICENSE=LGPL21

and we know what you mean. Because licenses can carry textual obligations (e.g. the GPL expects you to receive a copy, and the BSD licenses generally require you to include the copyright notice with distributions), there’s
an additional setting to include the actual text, called LICENSE_FILES:

LICENSE_FILES=COPYING.LIB

There’s a third source of license information, and that is the headers of the sources themselves. Usually you put a copyright-and-license header at the top of each file; some licenses such as the MPL even require some administration in there. The reuse.software site (by the FSFE) provides good guidance and best-practices information for providing licensing metadata in software packages.

Anyway, for KDE Frameworks 5 I was going through the ports Makefiles and adding LICENSE information. The KDE Licensing Policy tells me that frameworks should be licensed LGPL21+, with a few variants allowed; an interesting one is (at your option) “LGPL21 or LGPL3 or any later version approved by KDE e.V.” Right now, in 2017, this choice is the same as LGPL21+ because no later versions exist, but it is not always-in-the-future-same, so I hesitate to write

LICENSE=LGPL21+

for KDE Frameworks until I’ve checked the files. The license text is usually included, but it’s not quite consistently named, so I need to look into the tarballs anyway. And as a double-check, I read a couple of source headers to see if the license named in the code, matches the license text elsewhere (e.g. some files say LGPL 2.1 only).

It’s a bit of a slow process — one which upstream (that is, the source code) could support a little better with consistent naming. It’s also a process that needs to be monitored continually, to ensure that the whole body of software remains properly and consistently licensed — hopefully following best practices, too.

Anyway, as of today only ten of the KDE Frameworks 5 ports in the official FreeBSD ports repository  have all their licensing information set, to the best of my ability to check their accuracy. As an ongoing project in keeping-license-info up-to-date it’s not very high-priority but something that gets done in-between other things.

Sayonara

Not goodbye, but hello to a new music player on my desktop. It is already packaged for FreeBSD and has a long development history.

Music players stand or fall per individual user whether they satisfy the user’s needs — no duh there, but it means I should note what my use cases are before enthusing about some music player in particular. I would be fine with playing music from the command-line, most of the time: mpg123 --shuffle /mnt/music/*/*/* is just about right (except it fails with an argument list too long error in the shell). This is for music-while-I-hack, so I don’t listen too closely, it’s not hi-fi at all, basically I want “play in a genre until I switch it off“. Tagging is largely done when ripping my CDs (I still buy physical media!) and I don’t care for album art (I can look in the jewel case if I want that, and they’re all stacked in boxes upstairs). So play, pause, stop .. and if it can avoid mixing Mahler with Morrissey and Mötorhead, that’s a bonus.

Screenshot of Sayonara main windowOff to the left here is Sayonara, which describes itself as:

Sayonara is a small, clear and fast audio player for Linux written in C++, supported by the Qt framework. It uses GStreamer as audio backend. Sayonara is open source and uses the GPLv3 license. One of Sayonara’s goals is intuitive and easy usablility. Currently, it is only available for Linux.

Clearly that’s not true, because it’s available for FreeBSD as well 🙂 . I forget how I configured it; there’s a File > Open Directory entry and I probably filled in /mnt/music and it went and found everything that gstreamer will sensibly play. The screenshot is of the minimal playlist-only view. It can be broadened to include a library view which is a bit chaotic, but which searches reasonably well (e.g. for Mudhoney). Sayonara is actually where I discovered the luxury of stay-on-genre autoplay: when I started on some Dutch punk and it kept pretty close to that, wandering off to de Kift occasionally — but no Drs.P.

I contributed a few small fixes to get Sayonara building on FreeBSD, cleaning up the CMakeLists for newer CMake, that kind of thing. Now that it runs on my Plasma desktop all day, I can spot some more  minor issues — the system tray media player control doesn’t interact with Sayonara at all, for instance. For my use-case, that’s not so important, since the fire-and-forget genre play does it for me until I hit pause in the main UI.

I’m looking forward to KDE music players Elisa and Babe, for comparison purposes: maybe they tick my requirements-boxes just as well, or better. Certainly Elisa seems to be fairly playing-music-focused. I’ve even got a FreeBSD port for Elisa ready, just waiting for Qt 5.9 to show up on my doorstep (I can get it to compile against 5.7, but it won’t run due to QML runtime thingies).

CMake 3.10 on FreeBSD

The CMake port on FreeBSD is in the hands of the KDE-FreeBSD folks (since KDE was an early adopter), and generally it falls to me to do the CMake update while Tobias is still wrestling with Plasma and Raphael massages Qt 5.9 into our way of building. 3.10 was released five weeks ago, and it took a while to update the port.

It doesn’t take long because of CMake — they’re great, the code builds flawlessly, and there has been a real effort on the part of the KitWare folks recently to absorb our downstream patches so that we have less work in future (During the delay packaging CMake 3.10.0 Kitware even put out 3.10.1, which re-started some processes). It doesn’t take long because of new FreeBSD-specific features in CMake — you can now use CPack to create native FreeBSD packages, just in case you don’t want to go through the ports system or poudriere.

Nope, the problem is the 2000-odd ports using CMake. These generally behave, but every CMake update brings with it some ports that suddenly don’t build. So I spent a day on things like openvsp and scalapack, which fall over with 3.10 (and didn’t with 3.9). The causes of these failures is diverse; sometimes bad local CMake modules that don’t add all the right linking flags, sometimes bad C++ code, sometime stuff that has nothing to do with CMake at all but just happens to be newly triggered, and therefore my problem.

CMake 3.10.1 landed in the official ports tree with r457041, just before Christmas.

Naturally, there are some cases that fall out after an update, that are not caught before the update is committed. I’m told that FreeBSD on PowerPC doesn’t have a C++11-capable compiler installed by default, so I’ll need to massage that a little. Boost 1.66 came out very shortly after CMake 3.10.1, and that leads to new kinds of breakage. I’ve spent a half day compiling and re-compiling ceph, a distributed filesystem, trying to get that to work. It’s amazing sometimes how shifting one brick can bring down a whole house, and how we ever built the house in the first place.

Switched to Plasma 5

I’ve switched to using Plasma 5 as my daily (work) desktop. “So what?” you say, since Plasma 5 has been available since July 15th, 2014. Yep, more than three years on the desktop — see Sebas’s blog for some history. So I’ve finally switched my FreeBSD desktop machine, as a sign that Plasma 5 really is coming closer to the official FreeBSD ports tree.

KDE Applications are starting to trickle in to the official ports tree. The first (I think) was FileLight, which gave a good illustration of the gotcha’s involved with the update:

  • Anything that touches baloo requires a radical update to Plasma 5 as a whole. Baloo 4 and baloo 5 are not happy side-by side, and we don’t intend to put serious effort into installing them in separate places.
  • Translations are tricky, because they have moved from (KDE 4 times) a separate i18n package, to the application package. This means that the new KF5-based application package conflicts with the old KDE4 application, but also with the entire translation package (for, say, Russian) for KDE4.

For people who want the whole thing now, and who understand that KDE4 co-existence with Plasma 5 and modern KDE Applications can be problematic, the official ports tree can be avoided, and Area51 is the repository or ports tree to use.

On my desktop, on 10.3-STABLE and with nVidia drivers, Plasma 5 is more stable than on 12-CURRENT with tricksy Intel IGP drivers on the laptop. That’s a good thing, for the desktop I spend all week in writing code.

KMail and Akonadi have decided that my local maildirs are not accessible, so I’m using mutt for the time being to look at those. All my IMAP (knock on wood) is fine, so there’s still an intriguing bug there. In Randa I showed the effect and the messages to Dan and Volker, who were likewise intrigued. In the
end, though, it needs to be debugged and fixed here, locally, and then upstreamed.

At some point, the KDE-FreeBSD team had in mind to have Plasma 5 in the official ports tree in 2017Q2. It’s looking like 2017Q4, now (with just 5 days to go in Q3), basically because the upgrade path is annoying (from a ports perspective). Not for any functional reason, which is why it’s worth repeating that Plasma 5 from Area51 is a fine, fully functional, and fully up-to-date KDE desktop.

[[ Edit 2017-09-27 14:18 because Phoronix manages to get everything wrong, all the time: Tobias has been using Plasma 5 as his FreeBSD desktop of choice for years, dogfooding the ports much better than I ever have. And while I might be the noisiest blogger of our lot, that’s .. not necessarily a position of leadership. ]]

New FreeBSD Committer

I’ve been part of the KDE Community for over 15 years .. maybe 20. I started with Red Hat Linux, and then ran Yellow Dog Linux with KDE on my work desktop; probably KDE 1.1.2. But mostly I was one of the FreeBSD and Solaris people. I packaged KDE for Solaris on big Sun iron like the E10k, and then for FreeBSD around 2005 (I know this because of at least one wonderfully descriptive commit message Add boogers on July 26th, 2005 in Area51), and then for OpenSolaris for a while, and moved back to FreeBSD when OpenSolaris went away.

So in a sense I have been part-time part of the FreeBSD Community for nearly 15 years as well. FreeBSD has reached Tier-1 status within KDE now, with the KDE FreeBSD CI, which much stronger upstreaming happening, and with Tobias and Raphael following new releases pretty closely. I’ve been pushing and prodding at our ports tree a lot, and chasing CMake releases (and reporting bugs), and trying to get some KDE KF5-based applications into the official ports tree. So I’m happy to now receive a FreeBSD ports commit bit, with Tobias and Raphael acting as mentors. I won’t pretend this will immediately lead to Qt 5.9 and KDE Applications 17.latest in the official FreeBSD ports tree, but it increases the (direct) effort we can expend on it.

For my FreeBSD hat, I can be reached at adridg@, like my KDE hat is groot@ .

Randa Approaches

Later this week, I’m leaving for Zurich, and from there I’ll take the train up to Randa (up, in the sense that I live at sea level, and Randa is the length of one million micro-SD cards laid end-to-end higher).

In Randa, I’ll be working as a KDE developer, and as a Calamares developer, and learning about accessibility tooling. There’s about 60 hacking hours in that week. I’ll also be working as the cook, for one day. There’s about 12 cooking hours in a day, since feeding 30 people takes a lot of vegetable-chopping, bread-slicing, and dish-washing.

That is something special about Randa, I think: the feeling of much closer “living together”, and the way the attendees work together to create an optimal hacking environment. And cooking (along with the hacking) is my way of supporting the Randa meeting.

You can support the Randa meeting, too. That doesn’t support me; it supports other attendees who need to make long trips, it defrays the costs associated with infrastructure, it brings networking to town for a week. Support the Randa meetings for this year’s theme, or for the idea of a focussed retreat for hacking.

There’s a dot story about plans for the meeting. There will be summaries as well, and blog-roundups. But blog-roundups are tricky, because of the kind of things we (attendees) tend to write about. When blogging about the Randa meeting, I’ll probably blog more about food and hikes than about the hacking. The non-hacking bits make for better stories, even if the point of being there is the hacking. The results of the long coding sessions — privilege-separating Calamares, double-checking accessibility of KDE on FreeBSD — will show up later, in a future Calamares release or KDE-FreeBSD update. That’s the long-term payoff.

 

QtWebKit on FreeBSD

Over at lwn.net, there is an article on the coming WebKitGTK apocalypse. Michael Catanzaro has pointed out the effects of WebKit’s stalled development processes before, in 2016.

So here’s the state of WebKit on FreeBSD, from the KDE-FreeBSD perspective (and a little bit about the GTK ports, too).

  • Qt4 WebKit is doubly unmaintained; Qt4 is past its use-before date, and its WebKit hasn’t been meaningfully updated in years. It is also, unfortunately, the WebKit used in the only officially available KDE ports, so (e.g.) rekonq on FreeBSD is the KDE4 version. Its age shows by, among other things, not even rendering a bunch of current KDE.org sites properly.
  • Qt5 WebKit port has been updated, just this weekend, to the annulen fork. That’s the “only a year and a half behind” state of WebKit for Qt5. The port has been updated to the alpha2 release of annulen, and should be a drop-in replacement for WebKit for all ports using WebKit from Qt5. There’s only 34 ports using Qt5-webkit, most of them KDE Applications (e.g. Calligra, which was updated to the KF5-version some time back).
  • Webkit1-gtk2 and -gtk3 look like they are unmaintained,
  • Webkit2-gtk3 looks like it is maintained and was recently updated to 2.16.6 (latest stable release).

So .. the situation is not particularly good, perhaps even grim for Qt4 / KDE4 users (similar to the situation for KDE4 users on Debian stable). The transition of KDE FreeBSD ports to Qt5 / Frameworks 5 / Plasma 5 and KDE Applications will improve things considerably, updating QtWebKit and providing QtWebEngine, both of which are far more up-to-date than what they are replacing.

SDDM on FreeBSD

At some point, the KDE4-era KDM is going to end up unmaintained. The preferred display or login manager for KDE Plasma 5 is SDDM, which is Qt-based, and QML-themeable. In Area51, the unofficial KDE-on-FreeBSD ports repository, we’ve been working on Plasma 5 and modern KDE Applications for quite some time. One of the parts of that is, naturally, SDDM.

There’s x11/sddm in the plasma5/ branch right now, with a half-dozen code patches which I’ll have to look in to for upstreaming. I decided to try building it against current official ports — that is, current Qt5 on FreeBSD — and using it to log in to my daily FreeBSD workstation. One that runs KDE4. That is immediately a good test, I think, of support for not-the-obvious-X11-environment for SDDM.

So the good news: it compiles, installs, and runs. We’ve added a few tweaks, and still need to figure out which packages should be responsible for adding .desktop files for each environment. SDDM now installs an xinitrc.desktop, for the most-basic case. Switching kdm_enable to sddm_enable in rc.conf is all you need.

The bad: some things aren’t there yet, like shutdown support. And, at least with my nVidia card, fonts can vanish from the login screen after switching vt’s.

The ugly: we really need to spend an hour or two on doing some branding material for SDDM / Plasma 5 / KDE Applications on FreeBSD. Basically slapping Beastie on everything. Graham has created some graphics bits, so we’ve got something, just not packaged nicely yet.

Speaking of the Good, the Bad, and the Ugly, I re-watched it recently, but now with the added interest of figuring out where in Tabernas or Rodalquilar it was; turns out the beach past the airport is also part of the desert scenes. And SDDM can soon be part of the FreeBSD scene.

QtWebEngine on FreeBSD

It’s been a long time coming ..

Tobias and Raphael pushed the button today to push QtWebEngine into FreeBSD ports. This has been a monumental effort, because the codebase is just .. ugh. Not meant for third-party consumption, let’s say. There are 76 patches needed to get it to compile at all. Lots of annoying changes to make, like explaining that pkg-config is not a Linux-only technology. Nor is NSS, or Mesa, while #include <linux/rtnetlink.h> is, in fact, Linux-only. Lots of patches can be shared with the Chromium browser, but it’s a terrible time-sink nonetheless.

This opens the way for some other ports to be updated — ports with QtWebEngine dependencies, like Luminance (an HDR-image-processing application).

The QtWebEngine parts have been in use for quite some time in the plasma5/ branch of Area51, so for users of the unofficial ports, this announcement is hardly news. Konqueror with QtWebEngine underneath is a fine and capable browser; my go-to if I have Plasma5 available at all on FreeBSD.

CMake 3.9 on FreeBSD

The KDE-FreeBSD team also maintains the CMake packages on FreeBSD — mostly because KDE was the first big consumer of CMake. The meta-buildsystem is now used by hundreds of packages on FreeBSD. We recently switched the backend — the build system that is generated by CMake — from make to ninja, which gives us small-but-measurable build-time improvements.

Now we’re working on the CMake 3.9 update, which was released a two weeks ago.

Re-building hundreds of packages that use CMake is always an interesting exercise, since it’s the kind of big-practical test that regular testing avoids (this reminds me that really, we should be doing this in the RC phase rather than after release, to help the CMake folks find stuff before a release is finalized). The interesting bits have to do with all the ways that people find to abuse CMakeLists and do weird stuff.

Three CMake things I noticed recently:

  • Checking if stderr is a tty (for instance, to produce pretty colorized CMake output when it is) changed between CMake 3.0 and 3.1. OK, that’s not a recent change, but me-asking-myself “wasn’t this colorized?” was recent. Not a bug, something to work around most likely.
  • Finding UI files and automatically processing them has changed slightly. It is possible to add search paths. Quoting from the release notes,

    A “CMAKE_AUTOUIC_SEARCH_PATHS” variable was introduced to allow “CMAKE_AUTOUIC” to search for “foo.ui” in more places than the vicinity of the file including “ui_foo.h”.

    This breaks projects that #include "path/to/ui_foo.h". Previously, CMake ignored the path and looked for the UI file in the same directory as the source including it. Now, it looks for the UI file at the given path. In some packages which pull weird shenanigans with include flags and UI file locations, this breaks. Bug filed, though I have come to the conclusion that “Don’t Do That Then” is the right response and we’ll have to patch the packages that do this.

  • A change in the way auto-MOC works has revealed a bug of sorts in either auto-RCC or the ninja backend generator; this breaks Digikam for us. The same problem can be triggered in earlier CMake versions by turning on auto-RCC. Since we end up with different build results between make and ninja (make build succeeds, ninja doesn’t), I’ve filed a bug for this too. We’re still looking at what ought to be done about it, though. In the meantime there’s a simple fix for Digikam, though I’m not sure what other packages may be affected.

Trawling through packages that use or support (much) older CMake versions make me appreciate how far CMake has come since, say, 2.7. Whenever I find a page and a half of convoluted code to figure out which compiler flags support a given C++ standard, I’m glad of newer approaches like set(CMAKE_CXX_STANDARD 17) and be done with it. But I can understand projects not chasing CMake releases all that closely; there is a maintainence cost after all.

Anyway, thanks to the CMake folks for being very responsive to bug reports, and for FreeBSD users, expect CMake 3.9 soon-ish — it depends a little on how it intersects with the other updates we are trying to do, where Plasma5 is a big thing happening right now.