The FreeBSD project – which creates and publishes an operating system for a half-dozen machine architectures and packages and distributes about 40000 software products – has a quarterly report from all the various parts of that project: administration, sysadmin, ports and packages and specific technical highlights.

One small part of that vast collection of moving parts is the KDE-FreeBSD initiative, which is also a part of the KDE community. KDE-FreeBSD is a kind of a bridge project, trying to make various bits fit together.

I write “the quarterly” for KDE-FreeBSD, which is mostly based off of what other people do and which I just observe. My hat is off to the folks K-F team doing the real work; farther away in FreeBSD-land I salute Rebecca, Deb and Lara and others for doing deep technical and organizational things.

The K-F team describes itself in various ways; most recently we came up with

The KDE on FreeBSD project aims to package all of the software produced by the KDE Community for the FreeBSD ports tree. The software includes a full desktop environment KDE Plasma, an IDE KDevelop, a PIM suite Kontact and hundreds of other applications that can be used on any FreeBSD machine.

Most of the work the K-F team does on actual ports is done in the GitHub repository and coordinated on IRC in the #kde-freebsd channel on Freenode. (If you look at that repo, you see a bit yellow Dependabot warning, which is because somewhere among the 40000 packages that FreeBSD produces, there’s at least one security vulnerability: rarely one that is relevant to KDE on the FreeBSD desktop.) One interesting change in the past months is that there is now also a desktop@ team that handles things-shared-by-various-desktops. This broadens our developer base a little.

The short form is:

  • Every KDE Frameworks release lands as-soon-as-possible, generally within a few days of the upstream release. Upstream CI is really useful and I see that compatibility is taken seriously. Sometimes I even write patches.
  • Every KDE Plasma release lands soon-ish after release. Plasma sometimes takes a little longer because it’s less easy to test does-it-work-now; I’ve been slacking a bit in following the packaging work lately, relying on the official FreeBSD packages rather than local poudriere builds.
  • Every KDE release service announcement of libraries, applications and add-ons lands soon-ish after release.

CMake and Ninja and other build-infrastructure maintained by KDE-FreeBSD just keeps chugging along. I submitted a handful of changes to CMake for the 3.19 release that should make it a bit better on FreeBSD, so that we need to patch it in packaging a bit less.

The big item for KDE-FreeBSD in 2020q4 is probably dealing with Python 2.7 deprecation. There is very little Python 2 left in the packaging of KDE software – I think there was a Kross plugin that used it, and we have disabled that one – but the elephant in the room is QtWebEngine, which embeds Chromium, which has a horrific custom build system that is all tied to Python 2. I have about 90% of a port to Python 3 stashed away (in public) but that got bogged down – part of the build system uses pickle to export a configuration to a later stage, and the data going into pickle is flawed, but I have not figured out where that flawed data is coming from.