Modern KDE on FreeBSD

New stuff in the official FreeBSD repositories! The X11 team has landed a newer version of libinput, opening up the way for KDE Plasma 5.14 in ports. That’s a pretty big update and it may frighten people with a new wallpaper.

What this means is that the graphical stack is once again on-par with what Plasma upstream expects, and we can get back to chasing releases as soon as they happen, rather than gnashing our teeth at missing dependencies. The KDE-FreeBSD CI servers are in the process of being upgraded to 12-STABLE, and we’re integrating with the new experimental CI systems as well. This means we are chasing sensibly-modern systems (13-CURRENT is out of scope).

Looking ahead for the first quarter of 2019:

  • Qt4 is scheduled for removal mid-March. That affects a lot more ports than KDE4 does, For instance leechcraft — that looks like a desktop environment to me, which I’d never heard of before. There doesn’t seem to be a release of it based on Qt5 yet, though.
  • QtWebEngine update from 5.9.5 to 5.12. WebEngine is terrible for distro packagers, especially outside of Google’s target audience. This has been lagging, but we’re now in a position to work on an update — and we’ve welcomed a new contributor who wants to make that happen.
  • Wayland! Really, it’s time to also have a KDE Plasma Wayland session on FreeBSD. I had some stuff working experimentally a year ago, but nothing that could work in the official ports tree. That’s now feasible (and then I can sit down to debug KMail Wayland issues as well).
  • Kookbook and Kolorfill. Aww, so cute.

KDE4 on FreeBSD, post-mortem

The KDE4 ports in the official FreeBSD ports tree have been removed. I was there at the release party, in Mountain View, in 2008. And I’m here at the end of 2018 to cast some earth upon it.

The KDE-FreeBSD team has spent the past month or more, along with FreeBSD ports committers and maintainers who have other KDE4-related ports, in bringing things up-to-date with recent KDE-Frameworks-based releases, with hunting down alternatives, and with making the tough call that some things are just going away. Thanks to Rene for doing the portmgr commits to clean it up (r488762, r488763, r488764 and followups to remove KDE4-options from other ports) .

The modern KDE Plasma desktop, KDE Applications, and the rest of the stack continue to be actively supported. As of this writing, there’s 20 ports bugs open for kde@, so I think we’re doing OK.

FreeBSD security settings and KDE Konsole

Konsole has this neat feature where you can automatically title each tab in the terminal-emulator window with information from the foreground process running in that tab. Useful if you have lots of shells opened to different directories in the system.
Screenshot of konsole tab bar
It’s configurable, of course, by editing the tab’s profile (Settings -> Edit Current Profile -> Tabs). There’s a printf-ish configuration widget. I usually cut it down to just %d, the working directory.

When I switched over to FreeBSD 12.0, I enabled some extra security features from the installer, and noticed that konsole was being less informative than usual:Screen shot of konsole tab bar without directories

The reason is simple: konsole uses the debugging interface (e.g. ptrace) to query its child processes, and I have turned off debugging support for unprivileged processes. A quick sysctl security.bsd.unprivileged_proc_debug=1 restores the show-current-directory functionality in konsole, although that does, of course, switch off that security feature. Set it in /etc/sysctl.conf to make it permanent.

FreeBSD 12 and the graphics stack

Over the Christmas season I rebuilt my workstation — the one I use in my home office, all day every day, writing Calamares or FreeBSD ports or other stuff — to be almost-all-flash (and 3TB of spinning rust for backups). Since the machine was open and on its side on my desk anyway, I decided to try out the available graphics options.

As occurs so often: I’m not writing about something I did. It’s nearly all someone else’s work, and the FreeBSD 12.0 release notes understate it a great deal.

Various improvements to graphics support for current generation hardware.

  • Intel iGPU My machine has an Intel Skylake i7 in it, so it’s got an iGPU. The graphics/drm-kmod port supports this, and so I installed the i915kms kernel module, followed instructions, fiddled around with some settings. Results: Video works, with 2 monitors. Sound over HDMI works, although I needed to configure the Plasma mixer to use pcm instead of vol as the OSS volume knob to turn.
  • nVidia GTX730 The cheapest and most fanless card I could get two years ago. This needs the (proprietary) x11/nvidia-driver as well as an Xorg configuration file, and some other settings for sound. Results: Video works, with 2 monitors. Sound over HDMI works, with the default mixer setup.
  • Radeon R7 360 This is a friend’s old gaming card. While it’s supposed to be supported by graphics/drm-kmod, all I got out of it was screen buffer corruption on loading the driver and no X after that. I didn’t bother debugging this because the choice for a zero-extra-power part (i.e. the iGPU) was easily made.

In any case the new release and graphics improvements make it much easier to run FreeBSD on laptops and systems without a discrete GPU (I should get a Ryzen 2200G or something like that to see how other Radeon graphics do .. or debug the one I’ve got).

Wanted: Power9, for the mouses

Here’s a nice obscure bug: mouse wheel events on FreeBSD on Power9 are not recognized by Qt5. I don’t have anything PPC64 .. there were some Mac G4s at a second-hand place in town, but that is not a road to happiness. So obviously I need a Power9-based system to test this, and by coincidence Raptor Computing is now accepting pre-orders.

Yeah, not for $2000 to debug a mouse problem, but if anyone has one I can borrow, hit me up 🙂

(PS. I mentioned back in October that KDE Plasma 5 on Debian on Power9 Just Works, so it is something in the FreeBSD side of things.)

Patching Qt5Network for Christmas

Qt5 and KDE Plasma 5 have been running smoothly on my workstation desktop for a year or more. I have a kind of boring desktop: there is one CPU, one graphics card, two network interfaces, and I use the default settings for just about everything. .. and everything (that I need) just works.

But it didn’t work for everyone: there was this one weird bug report that when the system had VLANs defined, that most Qt5-based applications would crash or refuse to start up. That first manifested itself there as a build failure of kf5-syntaxhighlighting. After some discussion with Volker, I ended up with a workaround: don’t validate the schema’s during the build. That takes away the networking dependency, and things were OK again.

Other similar bug reports trickled in. They’re now all closed as duplicates of this original. Some patches trickled in, which I didn’t particularly like because they were of the “comment this bit out and things work”. Thankfully the original reporter of the kf5-syntaxhighlighting build failure, Ting-Wei Lan, did a great deal of debugging work. Enough to give me a handle on where to continue looking. I hemmed and hawed, tried blaming the run-time loader, but really all the evidence pointed at memory corruption from inside Qt5Network.

Fortunately the problem was totally reproducible and consistent in the way it crashed: create a VLAN, and one by one all Qt-based applications that touch the network would crash with an unresolved symbol. Rebuilding with debug symbols and everything turned on .. just got me a core dump somewhere else. After much futzing about, I found one location where adding a qWarning() << "foo"; made the problem go away. That's just as unsatisfying as commenting-out bits until it works.

Valgrind to the rescue. It told me about uninitialized memory being used in ioctl() calls, in an area of Qt5Network that I already thought was a bit flaky (wrt. FreeBSD support, anyway).

En passant I learned more about gdb, valgrind, ioctl() internals, and network status querying. And on Christmas Eve (or afternoon) I finally landed a bunch of patches:

  • Network bearer detection fixed; Ethernet is now recognized as such and doesn't hit the generic bearer.
  • Network media detection fixed; don't re-use ioctl buffers for a different ioctl; use the right ioctl number (apparently NetBSD and FreeBSD differ there).
  • Be slightly smarter about closing sockets; I took this opportunity to introduce a SockPuppet class, for silliness.
  • Support LibreSSL, OpenSSL 1.0, and OpenSSL 1.1 all at the same time.

The last item, supporting different SSL implementations, is all other people's work. I just built, tested and landed their efforts. Credits are in the corresponding ports commits.

As a consequence of all this, along with the release of FreeBSD 12.0, I now have an i3-based FreeBSD 12 machine with up-to-date Intel graphics and a KDE Plasma 5 desktop that uses libressl across the entire stack, and can survive having VLANs modified, as well. That's a good present for the end of the year. (For the new year, I resolve to try to upstream some of these fixes, minus any silliness)

Semantik on FreeBSD

Semantik 1.2.0 was just released this week. It is (or was) one of the bits of KDE4-era software in the FreeBSD ports tree. So our packaging has jumped forward by two years for this particular piece of software. Here it is, running in a weird test-VM without a KDE Plasma environment:

Screenshot of Semantik 1.2.0

Semantik 1.2.0, with the example sheet loaded and a preview generated.

I’d like to thank Thomas Nagy for being a responsive upstream, particularly in the face of downstream-packager questions (which can be summarized as “I can’t be arsed to read the manual and I don’t use this application normally, but I compiled it and now it doesn’t do what I expect”).

This leaves us with just four applications to update (or rescue) from the KDE4 era before The Kulling takes place.

KDE4ward on FreeBSD

KDE4 is deprecated in FreeBSD. Even more: kdelibs4 doesn’t build on 12-STABLE because of changes in OpenSSL. The KDE-FreeBSD has decided not to put any effort into reconciling long-EOL’ed software with current dependencies.

Of course, we don’t want to lose software if we can help it. So there is a wiki page detailing which packages there are and what we are doing about it. (The Debian wiki page for the same is quite useful, too; both wiki pages address the broader issue of removing Qt4)

Right now we’re in the phase of figuring out what can be moved forward, and what is really over and out. As an example: basket. This is a desktop-organizer application. At one time it was (nearly?) part of KDE-PIM, but has wandered off to be a not-KDE-community project. It’s still alive, and (nearly?) has a KDE Frameworks-based release. So we updated that port from v1.81 to somewhere post-2.49. Software saved, KDE4ward!

I did kaffeine, the media player, this evening, and our friends from GNOME-FreeBSD did avahi-qt5. We’re rapidly reaching a point where we’ve updated our own ports and everyone else’s that depends on KDE4, to newer versions if they are available at all. The effect on users should be minimal (if pulling-in-Qt5 is considered minimal).

KDE ports on FreeBSD 12 (amd64)

FreeBSD 12 was released last week. I’m in the process of rebuilding my main workstation to all-flash (which means backups, disentangling ZFS pools, etc. etc.) and in the meantime installed 12-R to an older i3 I had lying around. KDE Applications 18.12 were released last thursday. Those are in ports, but haven’t made it around to the official packages yet. So here are some notes on almost-current KDE on almost-current FreeBSD:

Installing modern KDE: from a freshly installed 12-R system, getting to a KDE Plasma desktop is a matter of installing two metapackages: pkg install xorg kde5 . That will leave you in a state where you need to link .xinitrc to startkde .. rather old-school. For purposes of having a pleasant setup, pkg install falkon quassel sddm as well.

Graphics configuration: with FreeBSD 12, the Intel on-board graphics drivers have synced up with Linux KMS. Since I’m running an Intel box with iGPU, I installed package drm-kmod and drm-fbsd12.0-kmod, and added the kernel module (as instructed by the pkg-message):

sysrc kld_list+="/boot/modules/i915kms.ko"

Configuring KDE packages: Plasma (modern desktops in general) want to have DBus running, so enable it: sysrc dbus_enable=YES. If you want SDDM, enable it too: sysrc sddm_enable=YES. The invocations of sysrc can be combined, it’s smart enough.

And .. that’s it! Updates (for KDE Applications 18.12) are a pkg upgrade away.

There are a couple of tweaks I’ve left out: SDDM will complain about HAL not being started; I need to sort out what that means, effectively, for us. And both Falkon and Akonadi want larger local socket buffers than the default. That requires sysctl.conf changes and I’m not sure they are actually needed on 12-R. So it’s more a matter of “these legacy tweaks might still be necessary, I’m ignoring them to find out if they are actually necessary.”

Calamares seeking translators

Calamares, the Linux system installer for boutique distro’s, is translated into 50 or so languages. It’s not a KDE project, but uses a bunch of KDE technology like the KDE Frameworks and KPMCore. It doesn’t use the KDE translation infrastructure, either, but Transifex.

There’s two languages for Calamares that don’t have any translators — they were requested, and then added to the system, but there is noone to do the work. Those are Macedonian and Uzbek. That said, there are also translations to Lao, Farsi, Gujrati, Urdu and Swiss French (is that even a thing) that have not seen any actual translation work done.

If you’re interested in any of those languages, the Calamares translators guide can get you started.

PS.: boutique distro for me means anything outside the “big five”, it doesn’t say anything about the size or importance of the distro itself.