Goin’ to FOSDEM

Today I built quasselcore for FreeBSD on armv6 — well, I say today but it took about 20 hours of cross-compiling to get all the bits, then another 10 minutes to repackage because all I wanted was the core, to run on my BeagleBone. So score one more qt5-based package that works on FreeBSD on miniature machines. While building, it touched on LLVM, and BSD, and maybe IoT, and that finally reminded me that I needed to get my butt in gear and actually book travel for FOSDEM.

I’ve skipped a few years, but I’m looking forward to seeing some of the familiar KDE faces there, as well as finally meeting a couple of the KDE-FreeBSD folks. There’s a long list of familiar faces at the Legal Devroom. For once, I have a plan of talks that I want to see, even some that I can claim are work-work related (yay!). Whether I’ll be useful at the KDE booth, I don’t know: last time I was there there was Plasma-desktop to be demonstrated and me with still KDE4 on my laptop. I’m not a good poster child for the modern generation.

As usual, I expect there to be waffles and too much beer and much random Free-Software joy.

Posted in KDE | Comments Off on Goin’ to FOSDEM

Plasma 5.5.3, Applications 15.12.1 and Frameworks 5.18.0 by KDE on FreeBSD

Thanks to the Chakra announcement, I could copy-and-paste the title of this blog post. Thanks, folks.

The latest round of software releases by the KDE Community — Frameworks, Plasma, and Applications — can be found the KDE-on-FreeBSD community’s area51 repository. These are unofficial ports, not yet included in the official ports tree.

One day, these ports will all be merged upstream, but not yet. There are some steps to be taken first. One of them is updating Qt upstream, to Qt 5.5. I’m told this is “somewhat close”. When that is done, it becomes possible to introduce the newer KDE releases as well. The integration issues aren’t so much the KDE software itself, as getting everything in ports to build and build nicely.

Once that is done, you can expect KDE Frameworks 5 to start infiltrating the ports tree, and then the whole flood of Plasma Desktop and the KDE Applications.

Posted in FreeBSD, KDE | Comments Off on Plasma 5.5.3, Applications 15.12.1 and Frameworks 5.18.0 by KDE on FreeBSD

Zanshin 0.3 on FreeBSD

When Zanshin 0.3 was released, it took just an hour or so to update the FreeBSD port for it. Since then, the real K-F folks Tobias and Rafael have put some polish on the port, made it compatible with FreeBSD 9-STABLE and 11-CURRENT, and pushed it into area51.

So, if you use the experimental KDE-on-FreeBSD repository, you can build Zanshin 0.3 today. Its dependencies are KDE4-based, so it is compatible with the official ports tree as well. Do follow the instructions for merging area51-trunk with the official tree though, since there’s all kinds of massaging that has happened already as preparation for KDE Frameworks 5, and that massaging needs to be merged as well.

Posted in FreeBSD, KDE | Comments Off on Zanshin 0.3 on FreeBSD

K-F updates, a whole mess of them

There’s a whole mess of updates in the area51 repository maintained by the KDE-FreeBSD team. These are the ports that will eventually, when they’re ready, be merged into the official FreeBSD ports tree (which still has KDE 4, installable through the kde4-metaport). Recent updates include Frameworks 5.17 (released december 12th), Plasma 5.5.1 (the weekly bugfix release, from december 15th) and Applications 5.12.0 (the 16th). But there’s other things going on as well: due to naming clashes (e.g. what to call last year’s kate, which is co-installable with this-year’s kate?) there is now a kate-legacy port. Ralf Nolden has provided updates for Qt creator.

Some updates have also made it to the official ports tree. That’s generally the case when they’ve matured for a while in area51, or when they are a regular update to existing software. In the official ports tree, Calligra has updated to version 2.9.10, released december 9th. Some options that make sense in a Frameworks+Plasma environment have been dropped, since for now the official ports repository targets KDE4.

As usual, I’m grinding through this lot of updates with poudriere, and then trying them out in a VM to see what happens (my other decent machine which I’d use for live tests has been totally taken over by the kids for the purpose of playing with dinosaurs).

Posted in FreeBSD, KDE | Comments Off on K-F updates, a whole mess of them

Resuming GPG

I think I spent nearly five years GPG-Free. When I was with the FSFE, I know I spent some time fiddling with the smartcard variant, even. But then I spent a long time working in places where secure communications meant talking in the hallways and secure electronic commuications wasn’t relevant at all. In those five years, only Ingo once sent me an encrypted message; I’ve now finally replied to it.

Because yes, I’ve gone back and unearthed my GPG keys from old backups, and once more can use FEA2A3FE for communications, just like I did in 2002.

Quite possibly Moxie Marlinspike is right, but for non-casual communications this can still be useful.

Posted in Bla Bla | 1 Comment

Cookery 2015

I was on a stroll down memory lane — partly because I was showing the kids that I was blogging before they were born (“so were you, like, internet-popular back then?”) — and ran across this old entry for cooking local. And I realised that not much has changed (and I still don’t have a recipe for sinasiri, nor much chance of ever getting one). Sunday breakfast was home-made Brussels waffles (roughly this recipe from Piet Huysentruyt), home-baked whole wheat bread with sunflower seeds (from a slowly-mutated recipe that most likely originated in one of the Moosewood Cookbooks, but basically straight-forward yeast bread), home baked blueberry pie (admittedly with frozen blueberries, from a Junior Masterchef competition) and meringues (recipe is on a grubby sheet of paper folded in with one of my cookbooks).

I still believe it’s important to know what goes into my food, and to make sure the kids know how to make stuff from scratch (it’s fun to me, at any rate, to notice how Mira has grown stronger as she’s grown older and now can actually knead the dough for an entire loaf of bread). There’s probably a simile for software development hiding here, but all this writing about food has gotten me hungry (so dinner will be roasted parsnips).

Posted in Bla Bla | Comments Off on Cookery 2015

When’s the current generation of KDE Frameworks, Applications, and the Plasma Desktop going to be available on FreeBSD?

So I’ve written about KDE-on-FreeBSD quite regularly, and in fact my most-common commit to KDE’s repositories recently is “adding news to the K-F site about updates”. But there’s an increasingly large gap between what’s in the official FreeBSD ports tree and package repositories, and what’s in area51. The testing repo gets regular updates, and I’ve got a local package server for testing. I’m sure the folks doing the real work in the testing repo have, too. But all that’s not official. And sometimes there are questions about when KDE Frameworks / Plasma5 / Qt5 are going to be updated in the official repo’s. Those questions also come from users of PC-BSD — PC-BSD is developed by iXsystems, who also graciously support the area51 repository.

I don’t have answers to those questions, though :(

Probably the answer is “when it’s stable and usable”.

On that front it’d be nice if releases slowed down at some point, for a little bit, so that we have one fixed point to get out there. On the other hand, the release of Frameworks 5.17 only took a day to hit our testing repo, so we’re catching up. Plasma 5.5.1 took less than a day. Calligra has just updated as well. One thing that really holds up integration with the official ports tree is the need for backwards compatibility — with all the other bits and pieces of FreeBSD and the ports tree. That means dealing with Qt4-versions of many applications and handling namespacing (of Qt4, but also Qt4 bindings to Python, for instance). Getting all the bits ready for peaceful co-existence is a lot of work and a lot of (re-)building.

That said, some important bits of the compatibility layers — for instance, PyQt 5.5.1 — have recently landed in the official ports tree, so it’s not totally unlikely that we’ll see KDE Frameworks 5, KDE Applications 5 and Plasma 5 Desktop (there’s a metapackage called kde5, which is a crude vernacular for installing plasma5-plasma-desktop, kf5-frameworks and a bunch of applications).

Posted in FreeBSD, KDE | 4 Comments

Nethack 3.6

Four days ago, and after a ten-year hiatus, a new version of NetHack was released. Many years ago, I was an avid player, competing gently with my friends Jesse and Joe over who would ascend the fastest, or whatever. Eventually I did the “ascend all the classes in reverse-alphabetical order” kinds of challenge, and then vaguely lost interest. But this new release has re-kindled my interest, so I quickly did a port for FreeBSD (based on the existing NetHack 3.4 port). I have filed a PR for it, so maybe the latest NetHack will be available shortly.

Me, I’m satisfied that I have the port. As part of testing, I also built it (with cross-compilation through poudriere) for my Beagle Bone:

root@smurf:/usr/local/etc/pkg/repos # uname -a
FreeBSD smurf 10.2-STABLE FreeBSD 10.2-STABLE #0 r287149: Thu Aug 27 06:11:58 UTC 2015 root@releng1.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE arm

and that means I could conceivably set up my own ssh-to-home NetHack server.

NetHack, Copyright 1985-2015
By Stichting Mathematisch Centrum and M. Stephenson.
Version 3.6.0 Unix, built Dec 13 12:58:42 2015.
See license for details.

Shall I pick a character's race, role, gender and alignment for you? [ynaq]

Posted in Bla Bla | Comments Off on Nethack 3.6

Area51 updates (KDE on FreeBSD)

The area51 repository continues to update, even as the official ports tree for FreeBSD sticks with KDE4. Since the KDE-FreeBSD team is also responsible for the official ports, that basically means that not everything has been shaken out yet, and that the team doesn’t feel that it can provide a really good Frameworks5 / Plasma5 / Applications installation .. yet. I’ve been playing with ideas for a default desktop wallpaper (the upstream default gives me a headache; I’d really like to combine Flying Konqui by Timothée Giet with bubbles made from the BSD logo.

That said, Plasma5 and some Applications work very nicely on FreeBSD. They also produce plenty of .core files, so it’s not all wonderful, but it’s a usable desktop by all means (and of course, all your KDE4 and GNOME applications continue to work). I tried to install a Qt5-only (+Frameworks, of course) desktop and discovered a long-standing bug in gsettings, as well.

The KDevelop-KF5 beta is available as a port from area51 as well. There’s an interesting potential bug there, too: it uses LLVM 3.5 libraries while the Mesa libraries use LLVM 3.6 in the software renderer. So if you have a machine without hardware GL, you can end up with two LLVM libraries runtime-linked into an application, which means crashy-time. This is the first time that upgrading my graphics card has fixed my IDE.

Posted in FreeBSD, KDE | 4 Comments

KDE FreeBSD in my KDE FreeBSD

Yo dawg, I heard you like FreeBSDYeah, dogg. I hear ya.

This post carries on a bit about the way I build and test packages for FreeBSD. I only have one desktop machine, running FreeBSD amd64, and it needs to function as a desktop even while building and testing packages. Elsewhere, things like Project Neon and the OpenSUSE build service do something similar, on a much larger scale: building packages from various stages of development and delivering them to users. Here, though, I’m concentrating on end-to-end ports and packages testing for FreeBSD for a single computer and user.

To do this, I’m using both FreeBSD jails (containers, if you will) and VirtualBox VMs. This means everything runs on one host (although really it doesn’t have to) and one monitor. The process looks like this:

Diagram of build steps and repositories

Components of the build process with poudriere + VMs.

Very little of this is my original work. Previously I pointed to some poudriere tutorials; that was the nucleus of this build setup.

Build Configurations: poudriere uses ZFS in FreeBSD to manage the disk space used by the different build configurations. This makes a couple of things easy: creating and destroying configurations and keeping state or rolling back to previous known-good configurations. This means you can have several ports trees — I’ve illustrated the default ports tree (which as of this writing is Qt 5.4.1, and KDE SC 4.14.3), area51 (which is Qt 5.4.1 and KDE Frameworks) and a plasma5 (which is Qt 5.5 and KDE Frameworks plus Plasma 5 Desktop).

Each ports tree is created with poudriere ports -c -p , which fetches the default ports tree. After that, I customize the tree by futzing directly with the filesystem. That can mean kdemerge (from area51), or editing ports files by hand. If needed, I can use ZFS snapshots to keep a known-good configuration around.

Each build jail is also created by poudriere, with poudriere jail -c -j . I show an amd64 and an armv6 jail here, since those are the architectures I build for. The armv6 jail takes a little more effort to set up, but that’s described in the poudriere tutorial. These jails live on a ZFS filesystem too, so I can snapshot them and update if needed, or clone them cheaply.

Doing a build takes one build jail — say amd64 — and one ports tree — say area51 — and builds a particular set of packages for that combination, with poudriere bulk -f -j -p . All the resulting packages are dropped into yet another filesystem (easy to clean!); each set of packages is named for the two ingredients that went into it. The packagelist-file can be really simple: if can be a single line x11/plasma5-plasma-desktop to build the KDE Plasma 5 Desktop.

You can use any kind of web server to serve up the packages. I followed the straightforward nginx setup described in the tutorial.

But the upshot of all this is that I can grind out packages in a bunch of different configurations in a pretty straightforward fashion. Per package set the automation might be a little different, but as an example, amd64-area51 packages (preparing for the first KF5 packages on FreeBSD) go like this:

  1. rollback the area51 ports tree to a clean state
  2. update the base ports tree in the snapshot, reset snapshot to new clean state
  3. update area51
  4. merge area51 with the ports tree
  5. kick off a build

With the current gaggle of packages, this takes about 4 hours on my machine, and then I’ve got a new set of packages I can test.

Test Machines: that second half of the setup is doing actual testing of the packages; e.g. installing them and running stuff. For this, I use VirtualBox — at least for the amd64 packages. It’s cheap and simple and gives me a standard platform that I can recycle and use for subsequent tests.

I have one disk image, which I snapshot to a known good state. I find it vaguely amusing that I can use ZFS snapshots inside the VM (on the virtual disk), or snapshots in VirtualBox, or snapshot the disk image in its own ZFS filesystem on the host system. So many ways to achieve the same thing.

My basic disk image has XOrg server installed, twm, xterm, and has a user account configured for ssh access. The point is to have a usable system (yay twm!) on which I can configure and run the packages just built elsewhere. To try a new package set, I clone the existing machine, start it up, set the pkg(8) repository to the right URL (which is on the host machine of the VM), then snapshot it and pkg install qt5 (or whatever packages I’m interested in at the time).

Since my area51 builds only build Qt5, KDE Frameworks 5 and KDE Plasma 5 Desktop (plus dependencies that aren’t already installed), it’s possible that the VM needs packages that aren’t built by poudriere in the build jails. So I have two pkg(8) configuration files in /usr/local/etc/pkg/repos, one to pull from the official packages repository, and one for my test repo.

[adridg@kafer ~]$ cat /usr/local/etc/pkg/repos/FreeBSD.conf 
FreeBSD: {enabled: yes}

[adridg@kafer ~]$ cat /usr/local/etc/pkg/repos/beastie.conf 
beastie: {
url: "pkg+http://beastie:8080/repo/101amd64-area51/.latest",
mirror_type: "srv",
enabled: yes
priority: 10
}

Aside from the URL — it uses my in-house DNS to resolve the hostname of the poudriere build-machine — the important thing in the second file is the priority: 10 line, which ensures that packages that are available from beastie will be preferred over packages from the official FreeBSD packages repository. As long as my build machine stays reasonably up-to-date, that’s fine.

The standard snapshot for my VM uses only the official FreeBSD packages, so I can also do this:

  1. rollback the VM snapshot to a known-good state
  2. update all the packages (from the official packages), reset snapshot to new clean state
  3. install packages from area51 (e.g. pkg install plasma5-plasma-desktop)
  4. startx. Yay twm!
  5. futz around; I generally run startkde by hand inside the X11 session, since I don’t know beforehand if it’s going to work, nor if the fallback behavior is sensible.

And with all that, I can say here’s KDE in FreeBSD in KDE in FreeBSD (with gobs of error messages from plasmashell, and I forgot to minimize some of the xterms so you could see the background; but the hamburger is there and KWin (X11) runs.):

Side-by-side screenshots

TWM on the left, KDE Plasma 5 Desktop on the right, on a KDE 4 desktop all running FreeBSD 10-STABLE.

PS. Now is the time to start with a FreeBSD-themed splash or default background. I think Beastie could very well be turned to glass and smashed into triangular bits to fit into the look. Any interested artists?

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