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.

Posted in Bla Bla, KDE | Leave a comment

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.)

Posted in Bla Bla | Leave a comment

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.

Posted in Bla Bla, KDE | Leave a comment

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 | 2 Comments

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.

Posted in Bla Bla, KDE | 2 Comments

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.

 

Posted in Calamares, FreeBSD, KDE | Comments Off on Randa Approaches

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).

Posted in ARPA2 | 3 Comments

Calamares 3.1.3 released

Calamares is an (Linux) installer framework. It’s an application with lots of pluggable modules to do system installation tasks (like partitioning, setting up users, and enabling encryption on filesystems) needed when installing Linux onto a computer system. There are modules written in C++ (with Qt), modules in Python, and modules in Python (with Qt). The middle bunch was, up until this release, untranslatable.

Calamares 3.1.2 was released yesterday, followed by a hotfix 3.1.3 (my bad), with new potentially translatable strings. I’ll admit that the last few strings were snuck in quite late, so translations are incomplete. This is no worse than they were, where the strings were entirely untranslatable. Expect more complete translations with 3.1.4, to be relased in two weeks time or so.

This is a medium-sized step for the accessibility of Calamares, now that more of the application is available in the user’s native language.

I’m also planning a much bigger accessibility step, which is adding screen reader support to the application. Actually, “adding” is probably the wrong word: I’ll stop agressively not supporting screen readers. That hostility towards screen readers comes from the setuid nature of Calamares (it’s messing around in filesystems and partitions and whatnot) and that hostility needs to end. Adaptive technologies should be usable also when installing a computer.

With that in mind, I will be going to Randa next month for this year’s Randa meeting, which has a focus on accessibility. The dot story explains the purpose of the meeting better than I can, and one of the comments presents exactly the challenge: turn off the monitor. Now boot the computer with CD in the drive, and install Linux. If Calamares can make that possible, then we’re helping everyone get Free Software.

To help the Randa meeting help everyone, consider making a donation, which helps to keep lights on in Randa (not the heating — we bring sleeping bags because it’s cold in the mountains, even in summer).

(I should note: Calamares isn’t a KDE project, although it is used by some Linux distro’s that have a KDE focus. It is also used by some Linux distro’s that focus on a Qt-free experience after installation. Calamares is an independent project, supported by Blue Systems. And yes, I do hope to install FreeBSD with Calamares at some point.)

Posted in Calamares | 2 Comments

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.

Posted in FreeBSD, KDE | Comments Off on QtWebKit on FreeBSD

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.

Posted in FreeBSD, KDE | 2 Comments