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

FreeBSD Plasma 5.4.1 and Frameworks 5.14.

Just a quick note that the KDE-FreeBSD “bleeding edge” ports repository area51 has been updated to the most-recently-released KDE Frameworks 5.14.0 and Plasma Desktop 5.4.1. These packages have been poudriere-built on 9.3 x86, 10.2 amd64 and 11 amd64 (no, I’m not building Plasma Desktop for Beagle Bone just yet). Information on area51 is on the K-F site, although you’ll want the plasma5-branch, which is at http://area51.pcbsd.org/branches/plasma5.

Posted in FreeBSD, KDE | 1 Comment

FreeBSD on Beagle Bone Black (with networking)

I set out to run FreeBSD on my Beagle Bone Black (now dubbed “smurf” by the kids on account of it’s small and blue), for network services. My DSL modem is a crappy under-configurable thing, but I don’t dare to start hacking on it directly because it runs the telephony side of things, too. So I decided to use the Beagle Bone Black to take control of my home network.

The modem is, of course, responsible for the actual internet connection. Its internal IPv4 address is, and it functions as the router for the whole house. Smurf is wired to one of the LAN ports on the modem, and it lives at There’s a switch wired to another LAN port on the modem, and the rest of the wired network lives behind that switch. Wifi (still) goes through the modem. I might change that too, since the range is lousy compared to my old WRT 54GL. It looks something like this:

Network diagram described in text

Network diagram showing services and hostnames

Inside the network, there are a couple of machines with specific roles. There’s the printer, and the media server, and the NAS, and the poudriere builder, and a couple more. Most of these machines run services with some form of autodiscovery — like the printer and the media server — but not all of them. And there’s the configuration aspect of each: not only do I need to be able to find the printer’s IPP service, I may also need to reach the printer’s configuration webpage. It’s most convenient when I can put http://printer/ into a browser anywhere in the house and get the webpage for exactly that.

There’s probably plenty of solutions for this, but the one I settled on is somewhat old-school: control over DHCP and over DNS, with DHCP handing out fixed addresses in-house to the machines that need it (e.g. the printer is always and DNS set to something I control that can respond with printer.example.com. 3600 IN A For the non-special machines — random desktops, laptops, phones — I don’t need any kind of in-house naming, those machines just need an address.

Starting DHCP. On the modem side, I had to change two settings: DHCP server off, and DHCP relay on (to the fixed IP address for smurf). Until I got DHCP up and running on smurf, this effectively killed new wireless connections and wired connections that weren’t set to a fixed address, (this was mostly annoying for the kids on their phones).

Smurf is configured with a fixed address, and fixed routing to the outside world, and nameservers as provided by my ISP (I suppose I could add some public DNS there too — in the example configuration below, that’s Google). I used the isc-dhcp41-server package that I’d previously built with poudriere. Basic configuration was really simple (in /usr/local/etc/dhcpd.conf):

option domain-name "example.com";
option domain-name-servers;
subnet netmask {
  option routers;

A little testing shows that yes, the DHCP server is handing out addresses. I left a non-daemonized, verbose logging version of the server running while testing the rest.

Fixed DHCP. Next up is assigning fixed addresses to my special machines. Before starting on this, I had them all configured with fixed IPv4 addresses, so they all need to be changed to use DHCP, and on the DHCP side of things, their MAC addresses need to be associated with a fixed address. The easiest way to gather the necessary information seemed to me to be a combination of nmap(1) and arp(8) — use nmap to ping the whole network, then get the MAC addresses out of the ARP cache:

$ nmap -sn
$ arp -a

For each special host, I added a host block to the DHCP server configuration, like so:

host printer {
  hardware ethernet e8:9a:db:db:db:db;
  fixed-address printer.example.com;

Note that I’m using a hostname in this configuration, so I added a line to /etc/hosts as well to fix the IPv4 address for that name. That’s needed as long as I don’t have DNS set up to resolve hostnames “printer” and “printer.example.com” to the desired address.

Starting DNS. FreeBSD has recently switched to shipping unbound(8) with the base system. Previously you could use BIND(8) or unbound(8) from ports. Unbound is much smaller and lighter, especially for the home-network situation. I can use it as DNS for the whole home network, and it will cache requests — but it also gives me control over the naming inside the house.

I followed an Unbound DNS tutorial, which was pretty comprehensive. On FreeBSD it’s even easier: set up the right nameservers in /etc/resolv.conf, then add local_unbound_enable="YES" to /etc/rc.conf, and start the local_unbound service. A configuration file is generated and unbound(8) is started. The unbound.conf example under Authoritative, validating, recursive caching DNS setup and install in that tutorial is pretty much what I ended up using.

Unfortunately, the auto-setup of unbound(8) seems to leave two things out: it runs unbound(8) in a chroot where there’s no /dev/random, and then everything comes to a DNS-crashing halt. It took me a while to figure that out even though it’s mentioned in the documentation. I ended up just adding it to /etc/fstab:

devfs   /etc/unbound/dev        devfs   rw      0       0

After that, unbound started complaining about its DNSSEC trust root file. I couldn’t quickly figure out what that was about, so I ended up just disabling the auto-trust-anchor-file in the configuration. The config files are spread out a bit, but here’s the most important bits:

# Server listens on the local network and allows all queries
        access-control: allow
        access-control: allow
        unblock-lan-zones: yes
        domain-insecure: 168.192.in-addr.arpa.
        domain-insecure: 127.in-addr.arpa.
# Forward to Google's public DNS
        name: "."

After a few tests with host(1) — which initially all returned SERVFAIL until I had the random-number thing sorted out — I was confident I could use this from smurf and from hosts in the local network as DNS. So the next step was to switch the option “domain-name-servers” in the DHCP configuration over to unbound(8) running on smurf.

Fixed DNS. The last step in this setup is to associate the names for machines on the local network with the local IPv4 addresses I’ve chosen for them. This is done through local-data and local-data-ptr records in the unbound(8) configuration. FreeBSD has an /etc/unbound/conf.d/ directory to drop configuration files into, so I added a local.conf with the local network definitions:

        local-zone: "example.com" static
        local-data: "smurf.example.com.     IN A"
        local-data: "printer.example.com.   IN A"
        local-data-ptr: "  smurf.example.com"
        local-data-ptr: "  printer.example.com"

Once that is done, then all the hosts in my local network that use DNS from smurf — and that means all of them that use DHCP — can use “smurf” as a hostname, and they’ll resolve, and reach the Beagle Bone Black.

With these two services in place, I can take each machine in the house and switch it to use DHCP, knowing that the ones that need a fixed address will still get one — and better yet, that they now have a useful name from all over the local network — and that the rest will have the names of the fixed-address machines available.

Musings. Conceptually, I’m working with configuration triplets: a particular MAC address has a particular name and designated IPv4 address. In the configuration, though, the triplet gets scattered across a number of configuration files, each in a different format. The issue expands with DNS, since then I have to repeat some of the information from /etc/hosts. Let’s call the elements of these triplets (M, N, A). I could make a small table of them. But getting that information into the right places is annoying, since the data gets spread out like this (with a bunch of hand-wavey notation):

  • N, A -> /etc/hosts format “${A} ${N} ${N}.example.com”,
  • N, A -> /etc/unbound/conf/local.conf format “local-data: ‘${N}.example.com. IN A ${A}” (but it has to be at the right spot in the file),
  • N, A -> /etc/unbound/conf/local.conf for the local-data-ptr line,
  • M, N -> /usr/local/etc/dhcpd.conf for the MAC-to-IPv4 mapping.

For my small home network, as long as I don’t go crazy buying devices that need a fixed address and name, the management burden is small. But it cries out for some kind of automation, so that I only need to write down the essentials somewhere once.

Posted in Bla Bla, FreeBSD | 4 Comments

FreeBSD on Beagle Bone Black (with X11)

X11 clients on the Beagle Bone Black .. that’s X11 over the network, with the X Server elsewhere. No display as yet. The FreeBSD wiki notes that there’s no (mini) HDMI driver yet. So I built some X11 programs, xauth(1) and xmessage(1), and installed them on the Bone. Since I bought a blue case for the Bone, and it is the smallest computer in the house (discounting phones .. let’s call it the smallest hackable computer in the house) the kids decided to call it smurf. Here’s a screenshot of poudriere’s text console as it builds packages.

Poudriere build console

Poudriere build console

Timestamps on the left are since the start of the overall build, so after 20 minutes and 11 seconds I had an xmessage(1) package built. Building that package only took (timestamp in the middle) 1 minute and 41 seconds, with the time preceding that all spent in building dependencies, like X Athena Widgets. Woo! Rock the pre-Qt dancefloor.

Since smurf pulls packages from my (cross-)build machine, all I needed to to was pkg install xauth xmessage to install everything, and that leads to screenshots like this:

Screenshot with xmessage(1)

XMessage running on the Beagle Bone Black

I’d show a screenshot with Qt5 designer, too (cross-compiling all of Qt5 took a little over a day, with 16 hours of that on qt5-webkit), but that mostly shows it dumping core as it fails to find a system- or user-dbus. Once I have that sorted, I’ll have a nice little machine on which it’s totally pointless to run Qt apps, but I will finally have an excuse to do a little QML and C++ to write a Qt5, ARMv6-FreeBSD, Beagle Bone Black user LED application — so’s to rock the house with four blinkin’ LEDs.

Posted in Bla Bla, FreeBSD | 6 Comments

FreeBSD on Beagle Bone Black (easy as pie)

For a long time, my Beagle Bone Black  sat on my desk, gathering dust. Recently I decided I would give it a purpose: as a replacement for the crappy DHCP server and DNS on my home router (it’s a Huawei g655d, and it has poor wireless range, a lousy interface, and wonky internal DNS). I ran an update on the Bone, which promptly downloaded a whole bunch of packages from the angstrom distribution. Over plain unauthenticated http. With, as far as I could see, no further checksumming or anything. Bad doggy.

Resigned to replacing the on-board distro anyway, I decided I would try FreeBSD, since that’s my OS of choice — if it didn’t work out, OpenSUSE would do.

Anyway. I wouldn’t be writing this if there weren’t a whole bunch of giants on whose shoulders I could stand, since actually, the whole process was deceptively simple and well-documented.

Hardware Setup: Here’s a picture of my Beagle Bone, on an old DVD-case.

Beagle Bone Black

Beagle Bone Black on FreeBSD

I started from the FreeBSD Beagle Bone wiki page. I power the Bone over USB from a powered hub. There’s a Olimex 3-pin serial cable attached. I spent a frustrating hour with this until I read somewhere that sometimes the TX and RX wires are reversed — so I swapped red and green and voila! You can see that in the picture.

Here’s part of the boot messages:

KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2015 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
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
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
CPU: Cortex A8-r3 rev 2 (Cortex-A core)
Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext
WB disabled EABT branch prediction enabled
LoUU:2 LoC:3 LoUIS:1
Cache level 1:
32KB/64B 4-way data cache WT WB Read-Alloc
32KB/64B 4-way instruction cache Read-Alloc
Cache level 2:
256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc
real memory = 536870912 (512 MB)

The FreeBSD image for Beagle Bone expands to fill the SD card, so I have a nice 8GB drive with a basic FreeBSD installation — hardly any different from when I create a fresh FreeBSD VM in VirtualBox.

Software Setup: then I tried to compile something. There are no binary packages generally available for ARM targets from FreeBSD, but you can compile everything from FreeBSD ports, no problem. Except after about 40 minutes waiting on the very first port that needs to be done, pkg(8), I was about to give up on this path.

At that point, Ralf Nolden asked something that totally turned this little project around: why don’t you use poudriere for cross-compiling?

I’ll point to Randy Westlund for a simple and straightforward recipe. No need to repeat it here, since the only difference between my setup and his are a few minor filesystem path changes. Randy points at Doug and there’s more pointers from there if you want to follow the historical references. Giants.

Suffice to say that poudriere is awesome.

Really. Follow Randy’s “Installing the Tools” steps, take the required modifications
to poudriere.conf from Doug, then continue with “Build the Environment”.

On an i7 860 @2.8GHz, this took less than an hour, if I recall correctly. Maybe an hour and a half, which gave me time to read the documentation on other bits and pieces.

I picked a few packages — isc-dhcp42-server and unbound — and kicked off a poudriere build. I turned off all the DOCS and EXAMPLES options, since I can get those on the build host and they don’t need to be on the Bone. From the extensive logging poudriere produces, I can see that it took a little over an hour and a half. For an overnight build, that’s cheap.

And then the moment of truth:

root@beaglebone:/usr # pkg install isc-dhcp41-server
Updating bbbbuild repository catalogue...
bbbbuild repository is up-to-date.
All repositories are up-to-date.
Updating database digests format: 100%
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
isc-dhcp41-server: 4.1.e_9,2

The process will require 2 MiB more space.
473 KiB to be downloaded.

So there you go! FreeBSD and ARMv6 packaging is as easy as pie. Now the Bone is doing something useful, I can start using poudriere for silly things,
like building Qt5 so I can write a Qt application to control the user LEDs on the board.

Posted in Bla Bla, FreeBSD | 5 Comments

A shout-out to SQLAlchemy

At work-work we write Python apps, using SQLAlchemy as ORM and database layer. I tend to run our stuff on OpenSUSE with SQLite for quick development purposes, but production tends to be MS SQL Server and Windows XP (there are migrations ongoing ..). Today we got a bug report that certain columns in the database were being created as VARCHAR(max) (that’s a SQL-Serverism) and that this was leading to errors elsewhere in the application when reflection of the database was used to (re-)retrieve the types of columns.

So I spent a few hours testing and writing up a careful bug report with a reproducible test case. That’s the time my job is (most) fun, writing up something that contributes outside our own walls.

Turns out we were doing something that wasn’t quite right, but the SQLAlchemy developers agreed that it was a not-unreasonable thing to do and within six hours there was a fix, committed and scheduled for the next release. So here’s a shout-out to Mike B. at SQLAlchemy for his quick work. (And I’m glad the effort of making a good-as-I-can bugreport paid off.)

Posted in Bla Bla | Comments Off on A shout-out to SQLAlchemy

The Sun Sets on KDE-Solaris

[[ No stories at Akademy this year — well, not by me. Maybe Kevin will write down how he got his students to sleep this year. Heck, I didn’t even put together a not-going-to-Akademy badge this year, and I see it’s been almost a year since my last post, which was after-Akademy-Brno. ]]

The KDE-Solaris site has been shuttered. The subdomain now redirects to KDE techbase, which documents the last efforts related to KDE on then-OpenSolaris. From the year 2000 or earlier until 2013, you could run KDE — two, three or four — on Solaris, either SPARC or (later) x86. I remember doing packaging for my university, way back when, on a Sun Enterprise 10000 with some ridiculous amount of memory — maybe 24GB, which was ridiculous for that time. This led — together with some guy somewhere who had a DEC Alpha — to the first 64-bitness patches in KDE. Solaris gave way to OpenSolaris, and Stefan Teleman rebooted the packaging efforts in cooperation with Sun, using the Sun Studio compiler. This led to a lot of work in the KDE codebase in fixing up gcc-isms. I’d like to think that that evened up the road a little for other non-gcc compilers later.

But OpenSolaris was removed from circulation, and Illumos hasn’t really got much in the way of desktop. The team kind of fell apart as the OS shifted underneath. The mailing list was shut down over a year ago.

This week, the site closed down as well.

So I’d like to take a moment to thank Stefan, hajma, Eva, Gerard, Joep, Alan for their work on  or support of KDE on Solaris over the years. Many others contributed as well — I don’t, and didn’t, know everyone involved, but I’d still like to say thank you.

As one roadway is abandoned, another pathway is cleared. And of course the ruins are still there, lurking in the shrubbery, for anyone with a machete and a Solaris-derivative-OS to rediscover and rebuild, should they so feel inclined. There’s gold (at least dtraces of gold) in them thar hills.

Posted in KDE, OpenSolaris | Comments Off on The Sun Sets on KDE-Solaris

Takeaway from Akademy

[[ Way back in 2008 or so, at Akademy in Mechelen, most attendees stayed in a hostel with 4 bunks to a room, which meant that after a long day hacking we ended up talking. It may have been Kevin who first asked “Ade, tell us a story.” This year, in 2014, at my first Akademy in four years, I received the same request. I’ve written down the story that I told this year. It was invented on the tram in Brno between Česká and Technologiky Park at 23:20 on the 9th of September 2014. When I got home I illustrated it. Text and illustrations licensed under CC-BY. If Timothéé feels like drawing it up better, by all means. This is a work of fiction. Any resemblance to people or rabbits, living or dead, is purely coincidental or a weak attempt at humor. ]]

The tale of Glenda the Plan 9 Rabbit

Once upon a time, Glenda the Plan 9 Rabbit was hopping through the forest. She was very happy, because she was free and hopping through the forest. The sun was shining and the birds were singing in the trees. Glenda was free because she had escaped from Bell Labs with a BSD license. That’s not quite as good as a license to kill, but you hardly need one of those as a member of the lagomorphidae, do you? Glenda hopped amongst the trees and she hopped through the bushes and she was very happy. There was a forest path and she ignored the crossing lights and just hopped straight to the other side. She nibbled some grass and hopped onwards, through the trees, under the bushes and over the grass. 

But then, suddenly, Glenda was stuck! She could not move her hoppy feet. She looked down, and there was a big black pool of tar. She tried to pick up her front left foot, but the tar was stuck to that. She tried to pick up her right front foot, but the tar was stuck to that too. Struggle as she might, her feet would not let go. Her left back foot sunk a little deeper into the tar. And then, with a glurpy sound, the tar made a great big tentacle that reached up and swayed in the crisp morning air. Glenda could still hear the birds singing as the tentacle squeezed her. With growing dread, Glenda realized that she would soon be stuck in a compressed tar archive. “That’s it!” thought Glenda, and she pulled out the “j” she still had left over from jay-walking that morning. But it was BSD tar, and it doesn’t understand the “j” option. Desperate now, Glenda the narcoleptic Plan 9 Rabbit (this is actually a useful power saving feature in all modern kernels) quickly fell asleep and with the help of those “z”s extracted herself from the terrible tar archive. She cleaned her feet on some chestnut leaves and hopped on through the forest. She hopped through the trees and under the bushes and over the grass. The sun was shining and the birds were still twittering. Glenda hopped over the grass again.

But suddenly, MROWR! A cat(1) ran out from the bushes towards her, with great terrible pointed teeth and sharp claws and Glenda jumped a foot in the air and turned and ran and ran and ran away from the cat(1) until she reached the edge of the sea and she ran across the beach and jumped into the water! Splash! The cat(1) could not get at her now, and it stayed on dry land, hissing and spitting. She swam and swam and there was a big red sailboat out on the sea. She swam until she got close and climbed up the ladder and there was a big man with a broad smile. 

It was Larry O’Liason, the Irish gourmand who had grown fat by eating all the animals in the sea. “Welcome to my boat, O’Coral. An Irish name of the sea, I’m sure you’ll see. Be welcome! Have something to eat!” And Glenda was very happy. There were no birds singing here, but gulls that screeched, and there was no grass to hop on, only 108 feet of teak from bow to stern. Still, Glenda was happy on board the O’Coral, and happier still because Larry gave her succulent grass to eat, and fresh crisp carrots. Soon Glenda was gaining weight, perhaps even becoming a little bloated. Her features, once sleek like a healthy forest rabbit, grew puffy. And Larry, she noticed, was watching her. Watching, while he sharpened a knife. But still she got her crispy carrots and succulent grass, and she hopped less on the teak deck. Until one day, Larry, with a grim smile, said “tonight, I dine on water-rabbit! I’ve not had that before.” 

And he pulled out his knife and gave out a cry and jumped at Glenda who shot a foot in the air and turned and ran and ran across the slippery teak deck and she ran to the bow and she ran back to the stern and she could hear Larry laughing behind her and he was gaining and she ran back to the bow and Larry was still gaining when THUMP! Another ship hove alongside! It was a crusty old galleon, and it had hoisted the black flag. The skull and crossbones! Larry gripped his knife between his teeth and turned to face this adversary. At the bow of the galleon stood a man with a long tangled beard and a wild look in his eyes. He held a scimitar in one hand and cried “O ho ho ho! I, Richard Boatsman, have come to thwart your terrible deeds, Larry O’Liason! And the railing rang as he leaped across and his scimitar was shining in the sun. It didn’t flash, though Richard did gnash his teeth. He bore down on Larry and the terrified Glenda, who regarded him with great big bunny brown eyes full of awe and relief. Richard faced the opposite captain, glanced at Glenda, and said “oh, hang on, you’re BSD licensed, aren’t you. Well, carry on then.” He turned and sailed off in his boat and Larry had Glenda for dinner and lived happily ever after.


Posted in Bla Bla, KDE | 3 Comments

Personal clones on KDE infrastructure

I’m doing a little work on Tupi — the 2D animation application that joined the KDE community some months back — so that it builds on FreeBSD (the C++ code is wonderful, but the build system is qonf, which is not).
This has led me to the maze of git documentation on KDE’s infrastructure, and I’m taking notes so I don’t forget what I did. It’s also part of one of the things-to-do-at-Akademy on my list: talk to the techbase people to find out what the status and intentions are.
For the purpose of futzing with the build system, I’m using a personal clone of the repository. This is so that whatever weird-ass things I’m doing, they don’t pollute the upstream repository; eventually I hope to code-dump a CMake-based buildsystem into upstream. One that can live alongside the existing build system for platforms other than FreeBSD — although I think that in the long run having the same build system and dependency-finding-modules as all the rest of the KDE software would be good.
Basic git configuration is covered on techbase, which describes the mandatory (username) and optional (URL rewriting, colors, templates and exclusions) configurations for using git with the KDE infrastructure.
The KDE sysadmin git FAQ explains how to create a personal clone of a project repository. I’ve created a personal clone of tupi, and cloned that one locally. Then I work on that (in a project Neon VM and a FreeBSD jail).
The only thing is, my personal clone doesn’t get updates from the upstream (here, that means the original project repository) unless I pull them in myself. This is where additional remote repositories come from. In my clone, by default there’s two origin remotes (one for pull from anongit, one for push over ssh, as documented in the git configuration page).

[adridg@beastie]$ git remote -v
origin  git.kde.org:clones/tupi/adridg/tupi-cmake (fetch)
origin  git.kde.org:clones/tupi/adridg/tupi-cmake (push)

So what I need to do locally is pull in commits from the upstream, merge all of them with my local clone, and then push (which goes to my personal clone on KDE infrastructure). The git-scm book has clear instructions; for me it means adding an upstream repository:

[adridg@beastie]$ git remote add upstream kde:tupi

And then to keep up-to-date with the upstream commits and store them in my own personal copy, I need to do these four steps (this assumes that I don’t do anything in the master branch myself):

[adridg@beastie]$ git fetch upstream
[adridg@beastie]$ git checkout master
[adridg@beastie]$ git merge upstream/master
[adridg@beastie]$ git push

There’s probably a faster / better way of doing this, but at least I know I can keep up with the upstream. Now I can keep rebasing my work inside my local clone onto the latest upstream like this, until such a time as I’m ready to push my CMake branch to my personal clone on the KDE infrastructure. Once that’s done, I can ask the maintainer to pull it into upstream.

Posted in KDE | Comments Off on Personal clones on KDE infrastructure

Prep for Akademy

In preparation for Akademy I wanted to swap out the drive from my laptop — which is full of work-work things — and drop in a new one with stuff I actually want to have with me at Akademy, like git clones of various repositories. I spent a few hours wrestling with my Lenovo x121e (AMD) laptop and FreeBSD, which taught me the following:

  1. You can update the BIOS from a USB stick using only Linux tools, and
  2. FreeBSD does not like it when the SATA controller is in compatibility mode, and either hangs or fails to find the hard drive at all; in AHCI mode things are fine, but
  3. Even the updated BIOS cannot boot from GPT partitions, so I had to be careful during installation to manually do an MBR / fdisk-based installation (this seems to preclude ZFS as well), and then
  4. Wireless isn’t automatically detected (but the WAN modem is), and suspend-resume doesn’t resume.

This makes for  less-than-stellar performance for a conference laptop; I’ll fiddle with it a little before departing for Berlin in two weeks time (isn’t Akademy in Brno? Yes, it is, but the most effective train journey takes me to Berlin first to catch up with the trainful of KDE people at 12:46 from HBf), so I may end up being a FreeBSD person sporting an OpenSUSE laptop.

For development purposes — sort of as a quick counterpart to the FreeBSD VM where I’m doing qt5-based things for KDE applications — I installed a project Neon VM. This way, too, I can check that I’m not breaking anything on non-FreeBSD systems. What I’m seeing on the desktop in that VM is not very encouraging to me, though. As used as I am to the current KDE software on OpenSUSE or FreeBSD (4.12 or whatever), the newer software feels weird and arbitrarily changed and oddly slow. That last bit might be due to VirtualBox, I don’t really know. I’ll have to attend some of the VDG or HCI topics to get a better feeling for the (visual) changes already made.

Posted in FreeBSD, KDE | Comments Off on Prep for Akademy