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-progress post-hoc

So, back in Randa I was splitting my energies and attentions in many pieces. Some attention went to making pancakes and running the kitchen in the morning — which is stuff I take credit for, but it is really Grace, and Scarlett, and Thomas who did the heavy lifting, and Christian and Mario who make sure the whole thing can happen. And the attendees of the Randa meeting who pitch in for the dishes after lunch and dinner. The Randa meetings are more like a campground than a 5-star hotel, and we work together to make the experience enjoyable. So thanks to everyone who pitched in.

Part of a good sprint is keeping the attendees healthy and attentive — otherwise those 16-hour hacking days really get to you, in spite of the fresh Swiss air.

Frederik encouraged us to touch the floor and the ceiling with his acro-yoga sessions; it is good to get out of the hacking room and get into shape. These sessions also teach us all trust and cooperation. And between sessions, he fixed a Qt bug that probably affects Calamares accessibility.

Calamares had some more bugs squashed, its accessibility improved — although I need to test that again and again on different setups now that I’m home, since it needs time to re-build Qt and all. Even with this fix, the goal to reduce Calamares’ root-needs remains.

You can read more of what the attendees in Randa achieved on planet KDE (e.g. kdenlive, snappy, kmymoney, marble, kube, Plasma mobile, kdepim, and kwin). I’d like to give a special shout out to Manuel, who taught me one gesture in Italian Sign Langauage — which is different from American or Dutch Sign Language, reminding me that there’s localization everywhere.

For me, being back home means sitting back at my big FreeBSD box, hacking on Calamares and ARPA and CMake and stuff again, with a renewed sense of purpose and team thanks to having worked together in Randa. If you like what KDE achieves in Randa, consider still supporting the fundraiser so that we can return to the mountains next year.

Take Randa and Stuff It

[[ Written monday, but I did not get around to posting it then. Since I do not feel like applying a modal time-shift operator to the text, I will publish it on tuesday, even though that introduces some temporal disparities.]]

It is almost 3pm. At three, the presentations from the Randa attendees will start, where each team or individual will present what they want to do for the week, and what they need from other attendees. So I’ll say “Calamares needs to support orca”. Short presentation, but then I’ve not had much time to prepare.

It’s almost 3pm, I’ve been up since 6:45 and have spent half an hour at my laptop. The rest of the day so far has been in the kitchen. Because keeping the meeting running, so that the attendees can do their thing to their full potential, takes a lot of logistics and effort. Let me give an example, based on profession software-engineers who are not professional cooks, doing the logistics.

Breakfast is from 7:30 to 9:00, which means that at 7:02 the kitchen opens. Coffee machine on. Dishwasher on. Tea kettle on. Send a minion to fetch the bread from the bakery. Dispense jam, nutella, peanut butter into bowls. Slice butter. Prepare muesli and yoghurt. Slice bread, together now that the minion has returned. One person runs the cheese / sausage slicer for 15 minutes while the other sets out cutlery, plates, cups, gets milk and orange juice ready. So at 7:30 when the first breakfasters show up, we’ve already put in one person-hour getting it ready. Hang around during breakfast, getting more bread, butter, refilling the coffee machine, slicing more salami. Once the last breakfasters are done (they show up at 8:50 for a quick bite), there’s three loads of dishes to do. The dishwasher is fast — less than two minutes — but everything needs to be put away, and the tables wiped down, and the slicer dismantled and cleaned, and the kitchen cleaned and swept.

So the “human cost” of breakfast is roughly 4, maybe five hours for non-professionals. Granted, there’s some time lost just in finding the way in the kitchen during the first day.

Lunch is a hot meal at 13:00 sharp, so preparations start at 11:00. Collecting today’s ingredients. Starting the stove and the oven. Starting 6l of water to boil for the rice, and another 6l of water for other parts of the meal. Cracking 15 eggs and whisking them. Cleaning, rinsing, and chopping 6kg of vegetables. Starting two pans of peanut sauce. Making a giant omelette. Waiting for 2kg of rice to cook. Shuffling six pans across five giant electric hobs. Setting out the chafing dishes, cutlery, plates, places again. Filling all the water pitchers. Checking the coffee machine. We — Grace, Scarlett, and I — had everything on the table at 13:05. And the cleanup cycle repeats, but with about six loads of dishes because of pots and pans. At 14:30, the kitchen is clean and tidy again.

The “human cost” of lunch is about six hours.

Dinner is scheduled at 19:00, which will have costs similar to lunch. Tallying up, it takes about 16 hours a day to keep everyone fed and happy (“it takes 30 people with their feet on the ground, to keep one man with his head in the air”). Today, we are doing it ourselves, because it is also a really fun way to work together and it’s a good team-building exercise. And while we’re sure to get more efficient, it’s just not efficient to actually do the cooking ourselves. I’m very happy to have worked together with Grace and Scarlett and Christian today, but I’ll be happy to hand over the chef’s hat to Hadrien tomorrow.

(O yeah, lunch was pretty expansive and tasty, so we’re stuffed. And in Randa.)

ERR (En Route to Randa)

Today I traveled from Zurich to Randa, which is about three hours by train. The day’s views started with a city, and trams and buses and high buildings. And then they got better:

Pictures of mountainsidesThe trip from Visp up to Randa is impressive every year. The moment you can see the ice of the glacier above Randa is wonderful. And now I’m sitting across from Thomas and Bhushan who are debugging something complicated. There was a wonderful dinner cooked by Mario’s parents, and a re-union feel with attendees from last year. I’m happy to see KDEnlive Joseph and Grace again, and the PIM dudes (although they seem to have slunk off to one of the meeting rooms for Serious Talks already).

Tomorrow starts at 7:02, when I have kitchen duty to roll out breakfast for 20-or-so Free Software hackers who are hungry from the fresh mountain air, and then after that it’s time to self-organize and sit down to work.

GPG Keysigning Protocol

With Randa approaching, I’ll be meeting some KDE people, some for the first time. So it’s time for another GPG keysigning! The usual approach to a GPG keysigning is to have Harald organise it, that ensures a maximum amount of abiding-by-rules. But .. he’s not going to be there, this year. So this post is a random bit of throw-information-out-there about how typical KDE event keysignings work, and an annoucement of my own protocol in handling keysinging.

My PGP key can be found here in pubkey.asc, and has key fingerprint = 00AC D15E 25A7 9FEE 028B 0EE5 7FEA 3DA6 169C 77D6.

Anyway, a typical KDE keysigning goes like this:

  • An Austrian^Wattendee is selected to coordinate the process in advance. You need to trust the coordinator and their printer.
  • A wiki page is started, which lists participants by name and GPG key fingerprint.
  • On the day of the event, the coordinator prints out one copy of the wiki page with the key table for each attendee. This is the point at which you need to trust the coordinator, to print out N identical copies.
  • At the event, each attendee in turn is asked to state that the key fingerprint on the sheet is, indeed, their key fingerprint.
  • All those who say “aye”, are participants. A shared secret for the session is established by writing a word on the whiteboard; this can optionally be used as part of the verification process later.
  • Each pair of participants cross-checks government-issued photo-ID plus whatever else they want to do. Sometimes we try to establish two concentric circles, for efficiency in cross-checking, but in my experience that leads to random milling about.
  • After all the cross-checking, we’re done the party part, and people can do the actual signing in whatever way they wish.

My personal protocol adds the following:

  • During the keysigning, I have double-slips of paper with my key fingerprint printed on them, and five randomly selected words from /usr/share/dict/words (on a FreeBSD machine, there are 235924 words in that file). Each double-slip has the words printed twice, and can be cut in half with the same words on both halves. For each participant, I have a different double-slip with uniquely selected words.
  • I’ll cut the slip in half, write your name on both halves, and give you one of the copies. Now we have a shared secret — those five randomly-selected words. Both you and I need to guard those slips of paper carefully!
  • Once home, I’ll send you an encrypted, signed, message asking for our shared secret.
  • You respond with an encrypted, signed, message containing those five words.
  • I send you an encrypted, signed, message with my signature on your key.

I used to ask a question (like “what stupid joke did I tell you on the first day of Akademy?”) which was some kind of shared secret between us, but memories are fallible and something that makes a big impression on me might be useless fluff to you. So that’s why I’m switching to using these slips of paper. I figure “choledocholithotripsy unobeying odontogeny staymaking fantigue” is as good a shared secret as any.

Posted in KDE

Akademy Results

At the beginning of the summer I went to Akademy in Almeria. So what did it bring, in terms of development? I can point to the FreeBSD-on-KDE-Slimbook posts as one technical result of Akademy, although I suppose I could have just had the machine shipped to me, too. (There need to be more posts about the laptop, as FreeBSD support for it improves; I must admit I’ve been a little lax in hacking on that).

There was a documentation BoF, expressing the wish to work on the community.kde.org pages to make them more up-to-date. Documentation, especially something showcasing the latest-and-greatest, is a constant source of maintainence-effort-required. I’ll have to admit I haven’t done anything there — writing Calamares documentation, for instance, has higher priority for me personally and can chew up inordinate amounts of time as well.

Photo of Mira with KTuberling

Using KTuberling in KDE3

Non-technically, there were two really surprising, but personally gratifying results:

  • My daughter, age 14, is going to Akademy 2018. Partly for Akademy, partly because of the Lippizaner horses; I guess she’s a nerd-horse girl.
  • Her response to her school’s mandatory-Windows-10-laptop policy: “dammit, why can’t they just use Linux? I know how to use that.”

She’s come a long way since KDE3.

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.


CMake Module Libraries

The KDE Extra CMake Modules (docs in CMake-style) are a collection of CMake code that do three things: add useful features to CMake, provide Find modules for dependencies for KDE code, and provide tooling for KDE code. There is slow osmosis between KDE ECM and the official CMake modules shipped with each CMake release.

Some days of the week I work on the ARPA2 project, which is a software stack devoted to security and privacy handling. There’s a bunch of TLS wrangling, and Kerberos hounding (not done by me) and LDAP bit-banging. There’s a whole stack of software, starting with an allocation-free DER-handling library, going up to a TLS handling daemon with desktop UI intended to allow you to quickly and efficiently select privacy settings and online identities (e.g. X509 certificate identities). Most of the software stack now uses CMake, and most of it uses roughly the same modules. So I’ve been thinking of setting up another “Extra CMake Modules”, but this time for the ARPA2 project.

Much like KDE ECM, there are two things I would want to get out of a CMake module collection:

  • Curated Find modules. Much of the ARPA2 stack works with Berkeley DB, OpenLDAP, GPerf, GnuTLS, Kerberos .. and there seems to be a huge selection of crappy CMake modules for finding those dependencies, and not much that lives up to the quality and consistency standards of KDE ECM. I’ve started collecting these modules, or writing my own, and will try to live up to those same standards.
    • Useful features like version-extraction from git, consistent packaging and config-file generation (and pkg-config files, too). These features spill over into tooling easily: based on consistent source structures across the software stack, it’s possible to do automatic packaging and uninstalls as well. This reduces the complexity of the CMakeLists in each sub-project / software product from ARPA2.

So my goals are pretty clear, and KDE ECM serves as a big inspiration, but I’m left with an existential question: why aren’t there more of this kind of curated library? Especially curated Find modules are really valuable so that CMake-based projects can easily and consistently find components from outside the CMake ecosystem. I can’t possibly be the only one who needs to find Berkeley DB on both Linux and FreeBSD. I can understand core CMake not shipping Find modules for everything. I can understand Berkeley DB itself not shipping CMake files so that find_package() can use config mode. What surprises me thoush is that no one has sat down and said “here’s the bestest, most portable, shiniest FindBDB.cmake you can get, and everyone should be using FindBDB from the DatabaseCMakeModules package (which, incidentally, also comes with Find modules for a dozen other databases and …)”

In a way, I’m wondering where the “CMake extragear” is, something close to CMake, but not part of the official distribution.

So, with that much ado, here’s a link to the ARPA2 CMake Modules github repository; it’s in an early stage of development and still collecting modules from the ARPA2 stack, but I do hope to reach a point where find_package(ARPA2CM) becomes as but-of-course as find_package(ECM).