Multiboot Pinebook KDE neon

Recently a KDE neon image for the Pinebook was announced. There is a new image, with a handful of fixes, which the KDE Plasma team has been working on over the past week and a half.

Photo of Pinebook

Pinebook running KDE neon

Here’s a picture of my Pinebook running KDE neon — watching Panic! At the Disco’s High Hopes — sitting in front of my monitor that’s hooked up to one of my openSUSE systems. There are still some errata, and watching video sucks up battery, but for hacking on documentation from my hammock in the garden, or doing IRC meetings it’s a really nice machine.

But one of the neat things about running KDE neon off of an SD card on the Pinebook is that it’s portable — that SD card can move around. So let’s talk about multiboot in the sense of “booting the same OS storage medium in different hardware units” rather than “booting different OS from a medium in a single hardware unit”. On these little ARM boards, u-boot does all the heavy lifting early in the boot process. So to re-use the KDE neon Pinebook image on another ARM board, the u-boot blocks need to be replaced.

I have the u-boot from a Pine64 image (I forget what) lying around, 1015 blocks of 1024 bytes, which I can dd over the u-boot blocks on the SD card, dd bs=1k conv=notrunc,sync if=uboot.img of=/dev/da0 seek=8, and then the same SD card, with the filesystem and data from the Pinebook, will boot on the Pine64 board. Of course, to move the SD card back again, I need to restore the Pinebook u-boot blocks.

Photo of a dusty circuit board

KDE neon Pinebook edition running on a Pine64, with console output

Here’s a picture of my Pineboard (the base is a piece of the garden fence, it’s Douglas pine, with 4mm threaded rods acting as the corner posts for my Pine64 mini-rack), with power and network and a serial console attached, along with the serial console output of the same.

The nice thing here is that the same software stack runs on the Pine64 but then has a wired network — which in turn means that if I switch on the other boards in that mini-rack, I’ve got a distcc-capable cluster for fast development, and vast NFS storage (served from ZFS on my FreeBSD machines) for source. I can develop in a high(er) powered environment, and then swap the card around into the Pinebook for testing-on-the-go.

So to sum up: you can multiboot the KDE neon Pinebook image on other Pine64 hardware (i.e. the Pine64 board). To do so, you need to swap around u-boot blocks. The blocks can be picked out of an image built for each board, and then a particular image (e.g. the latest KDE neon Pinebook) can be run on either board.

Everything old is new again

Just because KDE4-era software has been deprecated by the KDE-FreeBSD team in the official ports-repository, doesn’t mean we don’t care for it while we still need to. KDE4 was released on January 11th, 2008 — I still have the T-shirt — which was a very different C++ world than what we now live in. Much of the code pre-dates the availability of C++11 — certainly the availability of compilers with C++11 support. The language has changed a great deal in those ten years since the original release.

The platforms we run KDE code on have, too — FreeBSD 12 is a long way from the FreeBSD 6 or 7 that were current at release (although at the time, I was more into OpenSolaris). In particular, since then the FreeBSD world has switched over to Clang, and FreeBSD current is experimenting with Clang 7. So we’re seeing KDE4-era code being built, and running, on FreeBSD 12 with Clang 7. That’s a platform with a very different idea of what constitutes correct code, than what the code was originally written for. (Not quite as big a difference as Helio’s KDE1 efforts, though)

So, while we’re counting down to removing KDE4 from the FreeBSD ports tree, we’re also going through and fixing it to work with Clang 7, which defaults to a newer C++ standard and which is quite picky about some things. Some time in the distant past, when pointers were integers and NULL was zero, there was some confusion about booleans. So there’s lots of code that does list.contains(element) > 0 .. this must have been a trick before booleans were a supported type in all our compilers. In any case it breaks with Clang 7, since contains() returns a QBool which converts to a nullptr (when false) which isn’t comparable to the integer 0. Suffice to say I’ve spent more time reading KDE4-era code this month, than in the past two years.

However, work is proceeding apace, so if you really really want to, you can still get your old-school kicks on a new platform. Because we care about packaging things right, even when we want to get rid of it.

.. in with the New

It’s been a long time since I wrote anything about the state of current KDE software in FreeBSD. So, without further ado:

  • Qt is now at 5.10.1; work on 5.11 is proceeding. Right now, WebEngine is still at 5.9.5, and that’s remaining so for 5.11 unless we have a sudden influx of free time to work on that monster.
  • KDE Frameworks are at 5.49, which is the august 2018 release; 5.50 hasn’t come out yet but we’re ready for them when they do.
  • KDE Applications are at 18.08.0, which again is the august 2018 release; 18.08.1 was just released today.
  • KDE Plasma is at 5.12.5, so we’re one whole minor release behind (5.13.5 came out on tuesday). This is actually blocked by libinput, which is lagging in FreeBSD.
  • KDevelop version 5.2.3 is one patch level behind

So except for the Qt version, we’re keeping up reasonably well with the modern stuff. And we’ve finally joined most of the Linux distributions in deprecating KDE4 software. For KDE4-using ports that are not “ours”, we’re encouraging other ports maintainers to update them (e.g. to KF5-enabled versions) or follow in deprecating the software.

Out with the Old ..

KDE4 ports will be removed from FreeBSD ports on December 31st, 2018

The KDE-FreeBSD team met at Akademy this year, and while hacking on some other stuff, we also got around to deciding what to do with the KDE4 ports. We have wanted to get rid of them for some time, and there is an increasing pressure of maintainence on them: code written in 2003 doesn’t play well with the C++ of 2018 (in particular clang keeps getting more picky, which is good).

As for KDE4 itself: there haven’t been any upstream KDE4 releases since Applications 17.08.3, and Qt4 upon which it depends is EOL since 2015. The latest KDE Plasma desktop has been available in the official ports tree for over four months (and has been in use by users of Area51 for much much longer).

So, given that there is a viable upgrade path (although, truth be told, you’ll probably have to re-configure KMail and get used to Falkon), we’ve decided to put a four month deprecation period on all the KDE4 ports. They will be removed at the end of this year, which will free up some maintainence time for chasing the steady stream of updates from the KDE community.

Akademy, Akadeyou

Akademy is the yearly conference of the KDE community, and of KDE e.V. What makes the conference isn’t so much the technical content — see Kevin’s sketchnotes for instance — but the people. Seeing KDE Brasil grow the way it has is great (hey, people, please post a date for LaKademy). Aracele gives a good overview. Even bigger is KDE India, what a bunch of happy and talented contributors. Shout-out to Abhijeet for being one of the far-flung travelers.

I could only stay until wednesday morning, so I didn’t talk with anywhere near all the people I would have liked to sit down with. I did sit with Tobias, so that half of the KDE-FreeBSD team was hacking together, and with Leinir, and there was beer with Paul, .. with a conference of 200 people, the list of darn-didn’t-talk-to is always going to be longer than the list of good-seeing-you-again people. Such is life.

In the sense that Akademy is about me, and you, and making connections within the community, I’ll share one more anekdote: I stayed in a dorm room at the recommended hostel, and the first morning, still in my shorts, had a brief conversation in German with some guy about the ventilation mechanism in the bathroom. Then I pulled on my KDE India shirt, and the conversation turned a corner: hey, are you going to that KDE contributors thing? Turns out that roommate was also going, to his first Akademy.

Turns out, mr. Schiffner was “just a user” who “just runs the 20 Linux desktops” in a company. Wow! I’m really happy we got some “just users” at the conference, because where it’s important for the developer community to “put a face to names” to improve communication the rest of the year, it is also important for users to know that there’s regular people behind the software, as well. Personally I’d be really happy to have some user-talks; talks about deployments or specific use-cases of applications; a KDEnlive talk from a movie-maker would be keen. (That said, Paul did give a talk somewhat like that, about KDEnlive and promo films).

So, take-away things from Akademy are:

  • Debugging KConfig is full of surprises, even now, and having KDE-FreeBSD CI is really useful.
  • The Netherlands is just a local transportation network, for Itinerary.
  • Distro’s generally all feel the same pain.
  • Nobody wants to think about LDAP.
  • People are more important than things.

Coming back from the conference is always a bit weird; there is tons of neat stuff from the event still whirling around in my brain, and there’s 900 unread email messages in my inbox that need attention. I’ve sorted through most of it, done some communications things, pushed a bunch of commits to Calamares, and am now gearing up for an event next week in Brussels. But in september, things will be calm again.

(PS: gosh, I missed Carlos Soriano at the event, who has written a really cool I-went-to-Akademy from another kind of outsider’s perspective — we’re all in this Free Software thing together.)

More Laptops

One of the things to come out of Akademy is the first community release of the KDE neon Pinebook Remix image. I’ve been carrying around the Pinebook for some time — since FOSDEM, really, where I first met some of the Pine folks. At Akademy, TL was back and we (that’s a kind of royal “we”, because TL and Rohan and Bhushan and other people did all the hard work) got around to putting the finishing touches on the Pinebook image.

There’s not much to show beyond what you can see on the Dot already (my own Pinebook is looking a bit beat-up after a year, and the drawing Timothée did on it is rubbing off), really, so I’m not going to add photos: the Pinebook is a low-cost, low-power, quite adequate laptop, and it runs a modern KDE Plasma.

Best Service

How often do you meet your laptop vendor in person? Last year, I picked up a KDE Slimbook, and the machine has been great, acting as my development-box-on-the-go for lots of KDE travels. It has a few stickers, and some scratches, and the screen had gotten a bit wobbly by now .. so, at this year’s Akademy I stopped by the Slimbook stand, admired the newer Slimbook II (alas, the old one isn’t written off yet), and mentioned the wobbly screen.

Photo of an envelope from SlimbookHow often does your laptop vendor say “we can fix that” and do it right there and then? So I had a nicely tightened, fast and friendly Slimbook by the end of the next talk. Not only that, but when I got home from Akademy, I found an envelope with some stickers and the right tool to fix it myself if it happens again.

Now that’s developer-friendly service! Thanks, Alejandro and Raúl, and hope to see you again next year.

Going to Deventer^WVienna^WAkademy

Today I’m heading out to Deventer to say “hi” to Valorie and Boud, whom I’m be seeing again next week in Vienna, at Akademy.

Akademy is, for me, first and foremost a way to see everyone again and re-calibrate my social settings for everyone. After all, I communicate with most KDE people only electronically, though text, and it’s sometimes really important to see the faces behind the IRC nicknames. So I’m particularly excited that Michael Pyne will be there, who has been a voice in KDE for as long as I care to remember, but whom I’ve never actually met. And there will be lots of GSoC students there, new people who deserve all the support they can get — and commendations for the work they have done in KDE this year.

Personally I’m not planning anything specific at Akademy. I may chair a panel during the conference parts, and the Distro BoF is something I’ll definitely attend with my FreeBSD hat on. Other than that, it’ll mostly be spur-of-the-moment what I’m doing. Tug on my sleeve if you want coffee and a chat, about portability, installers, OEM stuff, codes of conduct, or Rick Astley.

My First Clang Bug

Part of the role of being a packager is compiling lots (and lots) of packages. That means compiling lots of code from interesting places and in a variety of styles. In my opinion, being a good packager also means providing feedback to upstream when things are bad. That means filing upstream bugs when possible, and upstreaming patches.

One of the “exciting” moments in packaging is when tools change. So each and every major CMake update is an exercise in recompiling 2400 or more packages and adjusting bits and pieces. When a software project was last released in 2013, adjusting it to modern tools can become quite a chore (e.g. Squid Report Generator). CMake is excellent for maintaining backwards compatibility, generally accomodating old software with new policies. The most recent 3.12 release candidate had three issues filed from the FreeBSD side, all from fallout with older software.  I consider the hours put into good bug reports, part of being a good citizen of the Free Software world.

My most interesting bug this week, though, came from one line of code somewhere in Kleopatra:

Q_UNUSED(gpgagent_data);

That one line triggered a really peculiar link error in KDE’s FreeBSD CI system. Yup .. telling the compiler something is unused made it fall over. Commenting out that line got rid of the link error, but introduced a warning about an unused function. Working with KDE-PIM’s Volker Krause, we whittled the problem down to a six-line example program — two lines if you don’t care much for coding style. I’m glad, at that point, that I could throw it over the hedge to the LLVM team with some explanatory text. Watching the process on their side reminds me ever-so-strongly of how things work in KDE (or FreeBSD for that matter): Bugzilla, Phabricator, and git combine to be an effective workflow for developers (perhaps less so for end-users).

Today I got a note saying that the issue had been resolved. So brief a time for a bug. Live fast. Get squashed young.

Those top Konsole Contributors

Whenever I see a post about community growth or participation — like Tomasz Canabrava’s most recent “From Nothing to top 20 contributors of Konsole in Less Than a Month” — I reach for the toolkit written by Kevin Ottens, because that makes it easy to obtain good numbers and graphs for community measurement.

Graph of Konsole's Entire History, all scrunched up and made tinyLooking at the graph (click to enlarge, but it’s still hardly readable — I’d suggest using Kevin’s tooling directly if you want to zoom in or experiment) of Konsole development since the very beginning shows a few striking facts:

  • Konsole has been in continuous development since 1998
  • Except for a gap 2006-2009, Kurt Hindenburg has been active in Konsole since roughly 2004
  • By looking at the density of commits and the length of commit-streaks, you can guess at maintainers and co-maintainers of Konsole, alongside all the occasional committers. There’s maybe five people whose histories suggest that.

Of personal interest to me is that in 2002 I contributed to Konsole for FreeBSD compatibility, and in 2009 for OpenSolaris compatibility, but nothing else in the history of the project. And Konsole spent a year licensed as Artistic, rather than the GPL2-or-later, in 1999.

Graph of Konsole's Recent HistoryRecently, you can definitely see that Tomaz has been really active, and Kurt has slightly more quiet time. But Ahmad and Mariusz are also consistently putting in work, albeit with a lower rate of commits. Judging by the commit messages, those have gone through Phabricator. That means that their commit counts are reduced because arc squashes commits (just like Tomaz, and as pointed out by Eike elsewhere). Keep in mind that commit-counts are poor proxies for contributions — that’s something we’ve been saying for years and years.

Also of interest in the history: there are 1090 commits by people not in the top-twenty; if those were grouped together they would hold second place!

So, thanks Tomaz for being noisy about what you’re doing. I think we need more of the “hey, I can improve the world” kind of noise — like KDE’s GSoC stories as well. And also, thanks Kurt and KDE community for being consistent and productive in small amounts for many years.