KDE Slimbook!

Yesterday I picked up my new KDE Slimbook from the Slimbook.es stand at Akademy.

Photo of slimbook being handed over

First thing I did, of course, was boot it with my FreeBSD 11.0 SD card, to see if it works with my favorite operating system (with Plasma 5 desktop, of course). Nope: 11.0 hangs after finding acpi_ec0, so I will write about that later this week.

Second thing I did was boot KDE Neon (pre-installed) on it, to see how it works out-of-the-box. I collected a bunch of tiny-little-irritations, papercuts if you will, from the basic installation — which have disappeared after an update and reboot.

It’s a really nice and slick machine. I wanted a machine that would still fit in the train or plane, for work, but a little larger than my Thinkpad x121e. I bought that machine in 2012(?) from Hettes, a Dutch shop specializing in hardware with Linux preinstalled (now gone, since they could no longer source hardware without a Windows license). So I’m really happy to buy a new machine from a Free Software supporting shop in 2017.

There’s a bit of a weird-ass dongle in the box for wired ethernet, SD card slot, HDMI and two USB ports on the sides, and a DC in — I don’t think I will miss USB-C at all, although that would be neat for a refresh. I have not tried the webcam, which is in the bezel at the top of the screen (no nostril shots like some Dell machines). Speaking of bezels, they’re pretty wide compared to current “design” laptops, Not any wider than the x121e, so relatively more narrow.

The touchpad is a big change for me personally, since I am — or shortly will have been — an IBM TrackPoint™ fan. On the other hand, the touchpad is solid and clicky. The keyboard is nice, with perhaps a little too much flex in the right-hand alt and delete keys. The arrow keys are arrowy, not the fat-left-and-right that (I think) HP uses.

So!

Having discovered that the machine is shiny and nice and fast and works well .. my next step is to try to break it. With the blessing of Alejandro and César — it’s good to have the best possible tech support right at hand.

(Oh, I forgot to mention: I’m pleased as punch with the ordering process, too, for instance the special “deliver to Akademy” shipping option, and the fact that I got email informing me of progress as the laptop was assembled and installed.)

Posted in Bla Bla, FreeBSD, KDE | 1 Comment

Best be precise

Screenshot with memory use KSysGuard — the system monitor — on FreeBSD seems oddly precise. This machine with FreeBSD 10.3 and KDE Applications 17.04.2 installed, tells me that I have 3,274,960.000000 KiB memory in use. That is, three million, two hundred seventy four thousand, nine hundred and sixty kibibytes. I’m willing to believe that, since notionally the machine has 4GB installed and FreeBSD uses up memory until it’s full and so memory use rarely reports much unused. What I’m less inclined to believe is the .000000 part of the measure: and zero millionths of a kibibyte. So that’s a .. um .. more than a millibyte, and a smidgen less than one one-hundred-twenty-secondth of a bit.

So, dragging in some information theory and plugging in some values,  using the binary entropy function, Wolfram Alpha tells me that

p ≈ 0.999314653604933

so we can be ninety-nine point nine percent sure that that is my actual memory use.

Sometimes it’s good to be precise.

Posted in Bla Bla, FreeBSD | Leave a comment

Akademy Schedule

Akademy 2017 is coming close. The schedule of talks (Saturday, Sunday) is now posted, and the community wiki for organizing things is slowly filling up.

The workshops and lightning talks and BoFs are being planned, too. I’m glad Anu Mittal has mentioned her QML + JS workshop, it’s a great topic for getting started with application development. QML is something I’ve never gotten in to, but should, so I’ve penciled this workshop into my schedule as well.

Posted in Bla Bla, KDE | Leave a comment

FreeBSD 11.0 and Plasma 5 HowTo

Here’s a step-by-step guide to getting a machine with FreeBSD 11 in it, running X, and KDE Plasma 5 Desktop and KDE Applications. It’s the latest thing! (Except that 11-STABLE is in the middle of the pack of what’s supported .. but the KDE bits are fresh. I run 10.3 with KDE4 or Plasma 5 on my physical machines, myself, so the FreeBSD version isn’t that important except that packages are readily available for 11-STABLE, not for 10-STABLE.)

TL;DR: get FreeBSD + X running; switch to mouf.net packages; pkg install kde.

Image of FreeBSD boot schreen

  • Download a 11.0 installation image (e.g. the bootonly ISO).
  • Build a machine with at least 32GB of disk, 4GB of RAM, and one or more processors. I had an AMD A10-5745M board lying around, which is an €85 board that just needs memory and a disk.
  • Put the installation CD in the drive, or plug in the memstick — whatever.
  • Boot it.

It boots to the extremely old-school FreeBSD installer (the irony is not lost on me, relative to what I do the rest of the week).

Installation selection

  • Go through the installer. Install lib32, ports and src, because you’ll need those later.
  • If you have the bootonly ISO, you’ll need to configure networking.
  • Which filesystem layout you pick doesn’t really matter either. I go for ZFS with 1-disk striping (i.e. no redundancy) because then I get ZFS snapshots later, which is convenient for messing around with the system state and possibly starting over.

Wait for the install to finish.

  • Set the system timezone.
  • Set a root password.
  • Disable services you don’t need (I generally disable remote syslog and sendmail; enable clear /tmp. The security-options are up to you.)
  • Create a user.
  • Reboot. While the machine reboots, eject the CD or unplug the memstick. (Have I mentioned I really like KDE Neon’s feature of auto-ejecting the disk?)

  • Log in as root, and do post-installation updates, to wit:
    portsnap fetch extract update
    freebsd-update fetch install
  • install an initial-but-minimal working system, starting with pkg(8), the packaging system itself:
    pkg bootstrap
  • Developer’s basic toolkit (and I prefer bash for an interactive shell):
    pkg install git bash gmake cmake pkgconf gettext-tools binutils
    echo fdesc /dev/fd fdescfs rw 0 0 >> /etc/fstab
    echo proc /proc procfs rw 0 0 >> /etc/fstab
  • An X Server and a backup X11 environment (ancient):
    pkg install xorg xterm twm
  • Desktop technologies (modern):
    pkg install hal dbus
    echo hald_enable=YES >> /etc/rc.conf
    echo dbus_enable=YES >> /etc/rc.conf
  • Clean up
    pkg autoremove
    pkg clean
    rm /usr/ports/distfiles/*
  • Reboot again.

Log in as your regular user and run startx.

Image of TWM

Aren’t you glad you installed twm? Remember, exiting the top-left xterm will exit your X session.

  • If running with ZFS, it’s a good idea to snapshot now, just so you can easily roll back to the it-works-with-basic-X11 setup you have now.
    zfs snapshot -r zroot@x11
  • Now swap out the default FreeBSD package repository, for the KDE-FreeBSD community one. This is documented also on the Area51 page.
    mkdir -p /usr/local/etc/pkg/repos
    cd /usr/local/etc/pkg/repos
    cat > FreeBSD.conf <<EOF
    FreeBSD: { enabled: no }
    EOF
    cat > Area51.conf <<EOF
    Area51: {
    url: "http://meatwad.mouf.net/rubick/poudriere/packages/110-amd64-kde/",
    priority: 2,
    enabled: yes
    }
    EOF
  • Tell pkg(8) to refresh itself (it may install a newer pkg, too), then install something nicer than xterm + twm, and then do some post-install configuration:
    pkg update
    pkg install konsole plasma5-plasma-desktop
    echo cuse_load=YES >> /boot/loader.conf
    echo webcamd_enable=YES >> /etc/rc.conf
  • Log in as your test user, and set up .xinitrc to start Plasma 5:
    cat > .xinitrc <<EOF
    #! /bin/sh
    /usr/local/bin/xterm -geometry +0+0 &
    KDE=/usr/local/bin/startkde
    test -x $KDE && exec /usr/local/bin/ck-launch-session $KDE
    exec /usr/local/bin/twm
    EOF
    chmod 755 .xinitc

If you really want, you can run startx, but this isn’t the complete Plasma 5 desktop experience .. and KDE Applications are not installed, either. So you get a bare xterm (useful to kill X or start konsole) and kwin and not much else. Good thing that getting the rest of KDE Plasma 5 Desktop and KDE Applications is pretty easy (and we could have skipped the intermediate step with konsole and gone straight to the finish:

  • pkg install kde

This metaport will pull in another 2GiB of stuff, for all the KDE Applications and a complete Plasma desktop. There are intermediate metaports for slightly-less-heavy installations, but this one is easy to remember and will almost certainly get you what you want. So it really comes down to installing X, dbus, hal, and then the kde package. Voila!

Screenshot of Plasma 5 desktop

PS. The screenshot shows a machine with 10.3, not 11-STABLE. It comes down to the same process; I have the 10.3 packages built locally so i’ts faster for me this way. The 11-STABLE screenshots were taken in VirtualBox, but I have not had any recent success with VirtualBox and OpenGL and FreeBSD. I can’t run any Qt applications: they all fall over when trying to load shared OpenGL libraries that simply aren’t there in VirtualBox.

Posted in FreeBSD, KDE | 2 Comments

Rand … ahhh

I’ve decided to go to Randa again this year.

There’s at least four reasons for me to go:

  • change of pace, trading coding-in-the-attic-office for coding-in-the-dining-room
  • change of pace, trading discuss-coding-on-IRC for discuss-coding-while-hiking-to-the-glacier
  • with a little planning, we can probably get further up the mountain than last year
  • someone needs to make brigadeiro.

More seriously, the theme this year (from the page for this year’s meeting) is

Accessibility is the big topic. But what does accessibility mean regarding KDE and what else do we want to make more accessible?

From that perspective, there are two kinds of accessibility I’m interested in: making KDE available on FreeBSD (which includes hammering PIM into shape) is one. That’s a bit of a cop-out, really. I mean, I could bring my BeagleBone (probably will, too) and claim I was making KDE accessible to armv6. So portability and platform accessibility is a small thing.

More important to me is actual accessibility in the sense of using-software-with-a-screenreader. When I worked for the Dutch Federation of Audiological Centres, I learned a lot about accessibility for the deaf and hard-of-hearing. A software application that is primarily visual in nature doesn’t need much accessibility work for that. But I was one floor above the Dutch Stichting Accessibility, which works for the vision-impaired. That’s been sort-of hanging around the back of my conscience. So, accessibility in the more generally-accepted sense: making Free Software usable by people of all sort and abilities.

So I’ve got two things to sort out (geez, why do I keep getting bogged down in case-distinctions):

  • Orca screen reader in KDE on FreeBSD,
  • Orca screen reader support in Calamares. This is actually the biggie — and only tangentially related to KDE. Calamares is not a KDE project, but is used as the system installer for a variety of smaller Linux distro’s. There’s an issue filed against Calamares that it is largely inaccessible. This is due in part to the way it needs root (e.g. is run through sudo). That makes it difficult to install Linux — even if the eventual installed system is accessible, the installer isn’t. So I’m going to tackle that at Randa. Doing so will make some other issues go away as well — or maybe, I need to make some other issues go away before tackling Orca, and this will make the whole codebase better.

Serendipidity! One Randa meeting to inspire me to work on things I might otherwise put off, and where it turns out that working on accessibility improves things across the board.

Posted in Bla Bla | Leave a comment

Wayland, and Weston, and FreeBSD – oh my!

KDE’s CI system for FreeBSD (that is, what upstream runs to continuously test KDE git code on the FreeBSD platform) is missing some bits and failing some tests because of Wayland. Or rather, because FreeBSD now has Wayland, but not Qt5-Wayland, and no Weston either (the reference implementation of a Wayland compositor).

Today I went hunting for the bits and pieces needed to make that happen. Fortunately, all the heavy lifting has already been done: there is a Weston port prepared and there was a Qt5-Wayland port well-hidden in the Area51 plasma5/ branch.

I have taken the liberty of pulling them into the Area51 repository as branch qtwayland. That way we can nudge Weston forward, and/or push Qt5-Wayland in separately. Nicest from a testing perspective is probably doing both at the same time.

I picked a random “Hello World” Wayland tutorial and also built a minimal Qt program (using QMessageBox::question, my favorite function to hate right now, because of its i18n characteristics). Then, setting XDG_RUNTIME_DIR to /tmp/xdg, I could start Weston (as an X11 client), wayland-hello (as a Wayland client, displaying in Weston) and qt-hello (as either an X11 client, or as a Wayland client). The result is this:

Screenshot with Plasma 5 and Weston

Plasma 5 Desktop from Area51, with Weston running in X as a Wayland compositor, and two sample Wayland clients displaying in Weston.

So this gives users of Area51 (while shufflinig branches, granted) a modern desktop and modern display capabilities. Oh my!

It will take a few days for this to trickle up and/or down so that the CI can benefit and we can make sure that KWin’s tests all work on FreeBSD, but it’s another good step towards tight CI and another small step towards KDE Plasma 5 on the desktop on FreeBSD.

Posted in FreeBSD, KDE | 13 Comments

Daemons and friendly Ninjas

Image of Beastie + NinjaThere’s quite a lot of software that uses CMake as a (meta-)buildsystem. A quick count in the FreeBSD ports tree shows me 1110 ports (over a thousand) that use it. CMake generates buildsystem files which then direct the actual build — it doesn’t do building itself.

There are multiple buildsystem-backends available: in regular usage, CMake generates Makefiles (and does a reasonable job of producing Makefiles that work for GNU Make and for BSD Make). But it can generate Ninja, or Visual Studio, and other buildsystem files. It’s quite flexible in this regard.

Recently, the KDE-FreeBSD team has been working on Qt WebEngine, which is horrible. It contains a complete Chromium and who knows what else. Rebuilding it takes forever.

But Tobias (KDE-FreeBSD) and Koos (GNOME-FreeBSD) noticed that building things with the Ninja backend was considerably faster for some packages (e.g. Qt WebEngine, and Evolution data-thingy). Tobias wanted to try to extend the build-time improvements to all of the CMake-based ports in FreeBSD, and over the past few days, this has been a succes.

Ports builds using CMake now default to using Ninja as buildsystem-backend.

Here’s a bitty table of build-times. These are one-off build times, so hardly scientifically accurate — but suggestive of a slight improvement in build time.

Name Size GMake Ninja
liblxt 50kB 0:32 0:31
llvm38 1655kB * 19:43
musescore 47590kB 4:00 3:54
webkit2-gtk3 14652kB 44:29 37:40

Or here’s a much more thorough table of results from tcberner@, who did 5 builds of each with and without ninja. I’ve cut out the raw data, here are just the average-of-five results, showing usually a slight improvement in build time with Ninja.

Name av make av ninj Delta D/Awo
compiler-rt 00:08 00:07 -00:01 -14%
openjpeg 00:06 00:07 +00:01 +17%
marble 01:57 01:43 -00:14 -11%
uhd 01:49 01:34 -00:15 -13%
opencacscade 04:08 03:23 -00:45 -18%
avidemux 03:01 02:49 -00:12 – 6%
kdevelop 01:43 01:33 -00:10 – 9%
ring-libclient 00:58 00:53 -00:05 – 8%

Not everything builds properly with Ninja. This is usually due to missing dependencies that CMake does not discover; this shows up when foo depends on bar but no rule is generated for it. Depending on build order and speed, bar may be there already by the time foo gets around to being built. Doxygen showed this, where builds on 1 CPU core were all fine, but 8 cores would blow up occasionally.

In many cases, we’ve gone and fixed the missing implicit dependencies in ports and upstreams. But some things are intractable, or just really need GNU Make. For this, the FreeBSD ports infrastructure now has a knob attached to CMake for switching a port build to GNU Make.

  • Normal: USES=cmake
  • Out-of-source: USES=cmake:outsource
  • GNU Make: USES=cmake:noninja gmake
  • OoS, GMake: USES=cmake:outsource,noninja gmake
  • Bad: USES=cmake gmake

For the majority of users, this has no effect, but for our package-building clusters, and for KDE-FreeBSD developers who build a lot of CMake-buildsystem software in a day it may add up to an extra coffee break. So I’ll raise a shot of espresso to friendship between daemons and ninjas.

(Image credits: Beastie by Marshall Kirk McKusick on FreeBSD.org, Ninja by irkeninvaderkit on deviantart)

Posted in FreeBSD, KDE | 3 Comments

Calamares Testing

Photo of DesktopMy project for Blue Systems is maintaining Calamares, the distro-independent installer framework. Not surprisingly, working on it means installing lots of Linux distro’s. Here’s my physical-hardware testing setup, which is two identical older HP desktop machines and a stack of physical DVDs. Very old-school. Often I use Virtual Box, but sometimes the hum of a DVD is just what I need to calm down. There’s a KDE Neon, a Manjaro and a Netrunner DVD there, but the machine labeled Ubuntu is running Kannolo and sporting an openSUSE Geeko.

I’m all for eclecticism.

So far, I’ve found one new bug in Calamares, and fixed a handfull of them. I’m thankful to Teo, the previous Calamares maintainer, for providing helpful historical information, and to the downstream users (e.g. the distros) for being cheerful in explaining their needs.

Installing a bunch of different modern Linuxen is kind of neat; the variations in KDE Plasma Desktop configuration and branding are wild. Nearly all of them have trouble being usable on small screen sizes (e.g. the 800×600 that Virtual Box starts with — this has since been fixed). They all seem to install Virtual Box guest additions and can handle resizes immediately, so it’s not a huge issue, but just annoying. I’ve only broken one of my Linux installs so far (running an update, which then crashed kscreenlocker, and now it just comes up a black screen). I’ve got a KDE Neon dev/unstable as my main development VM set up, with KDevelop and the whole shizzle .. it’s very nice inside my KDE 4 desktop on FreeBSD.

I’ve got two favorite features, so far, in Linux live CDs and in KDE Plasma installations: ejecting the live CD on shutdown (Neon does this) and skipping the confirmation screen + 30 second timeout when clicking logout or shutdown (Netrunner does this).

So, time to hunker down with the list of issues, and in the meantime: keep on installin’.

Posted in Calamares | Comments Off on Calamares Testing

KDE FreeBSD updates mid-june

I really wanted to say that Krita was the first KDE Frameworks 5-based application available in the official FreeBSD ports tree (so that pkg install krita just works), but it turns out that labplot has been KF5-based for a month or more and no-one noticed.

Nonetheless, three cheers for Krita and Calligra, which have been updated to the latest, modernest versions.

This is the start of a whole flood of updates, although Plasma is still going to take a while. Several things have come together to make this update possible:

  • FreeBSD KDE CI is running, so we can keep a close(r) eye on upstream. (This is what runs in KDE’s CI system, for FreeBSD)
  • KDE FreeBSD CI is running, so we can keep a close eye on ourselves. (This is what runs in FreeBSD’s CI systems, for KDE)
  • Both KDE and FreeBSD have Phabricator review systems, one for changes to downstream packaging, one for changes to upstream code.
  • KDE FreeBSD ports development is happening in a GitHub fork of the official FreeBSD ports tree.

With good CI and a good review process, we’ve been much happier getting packaging-fixes upstream than ever before. The CI catches unpleasant changes (hey, k3b has turned red, what’s up? Patches forthcoming ..) before they are released. The packaging CI is good for keeping track of where we are in packaging things ourselves. Since there’s a fair amount of package-shuffling going on, that’s important to have in hand. Finally the move to a git clone of the official ports tree makes it much easier to do small topic branches (e.g. updating Frameworks), test, and merge than we ever could with the SVN-based tree.

There’s a handful of smaller updates in-flight, alongside the Great Big Plasma5 branch, which is now shrinking as parts of it start to show up in the official ports already.

Posted in FreeBSD, KDE | Comments Off on KDE FreeBSD updates mid-june

Mixed KDE Applications on FreeBSD

The KDE Frameworks have been available in FreeBSD for a while now, but we haven’t seen much movement on the desktop environment or the applications front. KDE4 is still the latest you can get from ports. The plasma5/ branch in the KDE FreeBSD ports repository contains all the applications, and KDE Plasma 5 Desktop, and is very up-to-date with KDE releases — but it’s not in official ports, and that makes it a little more difficult than it needs to be to install the latest KDE  Software on FreeBSD.

The KDE-FreeBSD team is starting to migrate individual applications to recently-released KF5 versions. That sometimes means letting go of some features: Plasma 5 integration isn’t going to happen until we have Plasma 5 in the official ports tree. But KDevelop 5.1 is a valuable upgrade over 4.7, and the IDE suffers very little (except if you wanted the embedded konsole part).

Here’s a screenshot of my KDE4 desktop running on FreeBSD, with the first few KF5 applications alongside.

Those are Krita and Kexi and Calligra Words an KDevelop from KDE Applications 17.04.2, and a KDE4-based JuK.  I haven’t tested this much: they run, and I can type words into the windows and KDevelop can compile something. Krita is out of my league.

So for applications, we’re coming close to a situation where they can be updated to recent releases without breaking everything at once (except for a fistful of “core” applications — we might  keep a konsole-kde4 and a kate-kde4 if there’s both interest and effort put into maintaining them).

For users of the official FreeBSD ports, expect updates to trickle out for a little while yet, while we sort out things like UPDATING and finally decide on what-goes-where in the shiny new (um, I guess we still need a new branding package) KF5-based world.

Posted in FreeBSD, KDE | Comments Off on Mixed KDE Applications on FreeBSD