Reading old stuff

A few months ago, Helio blogged about building KDE 1 (again) on modern systems. So recently while cleaning up some boxes of old books, I found the corresponding books — which shows that there was a time that there was a market for writing books about the Linux desktop.

Particularly the top book, “Using KDE” by Nicholas Wells, is interesting. The first page I opened it up to was a pointer to the KDE Translation teams, and information on how to contribute, how to get in touch with the translation teams, etc. You can still find the translation info online, although the location has changed since 2000.

There’s also tips and tricks on getting your .xinitrc right, and how to safely fall back to twm. I find this amusing, because I still use the same techniques when testing new Plasma 5 packages in a FreeBSD VM. It’s good that the old standalone twm is still there, but it would be much more amusing to fall back to KDE 1.1.2 if Plasma 5 doesn’t start right, I think.

Posted in Bla Bla, KDE | Leave a comment

Packaging with CPack — on FreeBSD

Some days of the week, I work on Free Software projects that aren’t ready to see the light yet; they live in my own git repo’s, or wherever. While I have the intention of publishing eventually, I usually want to get things somewhat working before throwing code out there.

Part of checking if things work is packaging, and installing the stuff on more than one system. Sure, I can build everywhere, or copy around executables, but it struck me that it’d be cool to have packages — you know, installable with the system package manager — for the stuff I make. O yeah, I know flatpak is the new orange, but I’m not that hip. I’ll stick with Debian and FreeBSD packages, thanks.

And so my thoughts turned to CPack, for the reasons (well, because it’s there anyway and I use cmake as meta-buildsystem for almost everything).

So I spent two days messing with CPack internals and exercising libpkg (from pkg(8)) and writing code and then throwing it away (because can replace a half day of me trying to be clever quite easily).

At this point I’m happy to report that I’ve got a working CPack FreeBSD package generator. Like any package, it needs some metadata to be set before it can actually produce an installable package: things like who is the package maintainer, package description, etc.

I’m taking the position that this way of producing packages is auxiliary to the official packaging mechanisms (in FreeBSD, that would be via ports). So for these unofficial packages, the metadata is of less importance; they’re for unofficial, or for testing, purposes. With that in mind I decided to re-use as many of the package-metadata settings from Debian as I could find, and put bogus (e.g. example.com) defaults in the rest. That way, you can get away with very little metadata setting in CMakeLists.txt before CPack’s FreeBSD package generator is happy.

Here’s a minimal CMakeLists.txt which will successfully be packaged using the CPack FreeBSD generator:

set(CPACK_PACKAGE_CONTACT "groot@kde.org")
set(CPACK_PACKAGE_LICENSE "GPLv2")

include(CPack)

add_executable(hw hw.c)
install(TARGETS hw DESTINATION bin)

Notice that there’s nothing FreeBSD-specific in there. For testing purposes, or maybe also for proprietary software, it’s reasonable to have just one contact address, so the packaging falls back to using the generic CPACK_PACKAGE_CONTACT. Of course there’s also CPACK_FREEBSD_MAINTAINER, just like there’s CPACK_DEBIAN_PACKAGE_MAINTAINER, for setting specific maintainers for different packaging if you want to do that. Similarly, there’s a generic license setting, but in the unlikely chance that the license identifier specified generically isn’t recognized by the packaging system, you can override it. The default for project-homepage is example.com, but if CPACK_DEBIAN_PACKAGE_HOMEPAGE is set, that gets used; CPACK_FREEBSD_PACKAGE_WWW can also be used — but that only makes sense if the homepage of the upstream project is different for FreeBSD than for Debian, which seems unlikely. The rest of the variables that influence CPack FreeBSD package generation are described in the CPack script for it. The only thing specific to FreeBSD packaging that you might really need to set manually is CPACK_FREEBSD_PACKAGE_DEPS, which is a list of ports-origins on which the package depends. I may try to generate this automatically, even — libpkg knows about shared-libs dependencies, and could query the package database as well to get whatprovides information — but not right now.

Anyway, I’m going to add this to FreeBSD’s cmake package, so that we can experiment with it downstream. In the medium term I’m going to try to merge it upstream. It surprises me a little that there’s no Flatpak generator: surely that can’t be too difficult to wrangle up (or maybe there’s no point — the intro-to-Flatpak workshop given in Randa was a long time ago). And now, having spent two days messing around on infrastructure for my other projects, I can get back to those.

Posted in Bla Bla, FreeBSD | 2 Comments

Tracking KDE Frameworks and Qt

The KDE-FreeBSD team bumped Qt to 5.7.1 and KDE Frameworks to 5.31.0 in official ports last week, so we’re fairly up-to-date in that department. On FreeBSD, we still fully support Qt4 next to Qt5, so some of the delay in getting this stuff in is due to some shuffling of install locations. In particular, we’ve added qt-chooser in this round of updates, so that qmake is qmake — and no longer qmake-qt4 or some other suffixed binary. We use qt-chooser to switch out one or the other. Checking that this doesn’t break anything else — or at least making sure that everything still compiles — is what took the most time this round of updates.

So we’re edging closer to getting Plasma 5 Desktop; TCBerner intends to import it together with all the KDE Frameworks-based KDE Applications. That makes it a grand shuffling of ports — and that again takes lots of time.

I’m about to embark on an examination of kcheckpass — we still have two of them, even, one kdelibs4-based and one kf5-based — because the Plasma maintainers would like to clean up the code, and have asked distro’s to double-check what actually gets used on each platform. (And kcheckpass is tricksy, like the time in 2003 or so I locked out all the sysadmins at the university by updating the KDE packages, but forgot to setuid it ..)

Anyway, the usual applies: Plasma 5 and KDE Applications are fine to use on FreeBSD, from the area51 repository, and official ports just keep getting closer, bit-by-bit.

Posted in FreeBSD, KDE | Comments Off on Tracking KDE Frameworks and Qt

Fixing old stuff

On FreeBSD, Qt4 is still a thing — for instance, for the KDE4 desktop that is still the latest full-KDE experience you can get from the official packages. And although that software is pretty old, the base system still evolves. FreeBSD 9 has been put to rest, and with it all the GCC-based FreeBSD systems. That frees us from having to deal with GCC and Clang at the same time, and we can generally patch things in just one way (usually towards more-modern C++). But the base system also evolves “out from under” older software. There’s an effort to update the base system compiler (for FreeBSD 12) to Clang 4.0 (sometime soon-ish), and that means that our older C++ code is being exposed to a newer, pickier, compiler.

Seems like I’ve been doing “fix KDE stuff relative to pickier compilers” since, like, forever (on Solaris, and then FreeBSD, and then Solaris again, and OpenSolaris, and then FreeBSD).
Anyway, today’s little fix comes from Qt4 Linguist (devel/qt4-linguist in the ports tree), where we find this code:
if (c->findMessage(m->text(), m->comment()) >= 0)
Here findMessage() returns a MessageItem*, so that’s a nonsensical comparison that should be != 0 instead (or idiomatically, just leave out the comparison but Qt4 sources are somewhat inconsistent in their formulation of null-pointer checks).
So there’s — for me — a brief interlude of messing with old codebases in preparation for new things, while the rest of the KDE-FreeBSD team deals with newer things like the latest KDE Frameworks and Plasma Desktop releases (which, as I’ve said many times, may be had from the area51 repository and work fine, but are waiting on various dependencies in the official ports tree).

Posted in FreeBSD, KDE | 1 Comment

KDE Frameworks and Plasma on FreeBSD

It’s been quiet from the KDE-FreeBSD folks for a bit, but not because it’s actually been quiet. Tobias has been on a roll, and Dima has started doing stuff again, and Gleb is still watching over some ports, and Raphael is hovering over it all with good advice. So here’s some bits and pieces:

Some time ago I mentioned a branded wallpaper for FreeBSD, based off of the Flying Konqui wallpaper — which in turn I had mentioned in February. Anyway, here’s a screenshot of the if-it’s-up-to-me default wallpaper for Plasma 5 on FreeBSD. It’s running in VirtualBox, which is why KInfoCenter reports an interesting resolution (KInfoCenter has also been expanded with a lot better data on FreeBSD hosts, so that it reports sensible memory use, and sensible disk usage).

shot6a

On the official ports front, KDE Frameworks 5 have landed. All except Wayland — which requires a Wayland port to build against, and that is currently in the almost-but-not-quite state from the FreeBSD graphics developers — and Bluez — which is just hopeless with the FreeBSD bluetooth stack. So that layer of the stack is now complete, and we follow KDE Frameworks releases closely.

Next bits, like a Plasma 5 Desktop, are lined up in the plasma5/ branch in area51, and there’s some work being done in FreeBSD Phabricator, but don’t hold your breath.

In the mean time, we’re also pushing things upstream (i.e. into KDE itself) a little more often. Also through Phabricator — KDE Phab this time. So every now and then I end up with tasks or reviews in the one system that belongs in the other, oh well. Generally I really like the workflow with Phab. Certainly now I’ve found the “add reviewer” button. I’ll give the Krusader folks a shout-out for dealing really quickly with issues raised through Phab, and Dima thanks for the original patches.

So all in all: KDE Plasma 5 Desktop is moving along, with two layers of the software stack to go before there’s an official modern-KDE-desktop available on FreeBSD; one layer is already available for modern-Qt-based-applications. KDE4 is receiving some attention as well — I see there’s a KDevelop 4 release I should chase down.

Posted in FreeBSD, KDE | 5 Comments

Plasma 5 Desktop on FreeBSD Branding

The FreeBSD packages of KDE software — the KDE 4 desktop, and soon KDE Frameworks 5 and Plasma 5 Desktop and KDE Applications — have traditionally been shipped pretty much as delivered from the upstream source. We compile, we package, and there is very little customization we do as a “distro”. The KDE 4 packages came with a default wallpaper that was a smidgen different from the one shipped with several Linux distro’s. I think Ivan Cukic did that artwork originally. For Plasma 5 Desktop, we also wanted to do a tiny bit of branding — just the default wallpaper for new users, mind.

Thanks to the tremendously helpful Plasma crew who answered my questions about setting a default wallpaper by producing the necessary files on the spot. After a tiny amount of massaging, I’ve now got a package that does the FreeBSD branding of the Plasma 5 Desktop for us. Of course we retain the upstream settings and wallpapers too.

Also great thanks to Timothee Giet, for producing the image (based on his Flying Konqui) that we’re now going to use as the default wallpaper — Konqui flying on BSD, that’s just what we want, after all.

Posted in FreeBSD, KDE | 3 Comments

A bit on Tooling

Last weekend, I finished the construction part of my garden shed. The last bit mostly playing with the circular saw, taking rough boards and making them square, then angling them so that they would fit under the roof. It took a couple of hours, but I ended up filling the 3m-by-65cm gable with vertical planking, quite neatly. At the beginning of this year, I wouldn’t pick up a circular saw — power tools, scary. So I planned building a shed to force myself to learn something about carpentry. The next-door neighbour is a handyman, so we worked together and basically he taught me how to use the tools and get things done. (The Czech animation series “Pat a Mat” is popular in the Netherlands as “Buurman en Buurman“, and we style ourselves thus).

Anyway, I think my point is that learning to use the tools is half the battle.

So on the weekend I also worked on updating Qt 5.6.1 to Qt 5.6.2 on FreeBSD, which involves using new and scary tools as well. Power tools, they can be really useful, or they can take off a finger if you’re not careful. In this case it was Phabricator, which is also used in KDE — but not everywhere in KDE. For FreeBSD, the tool is used to review updates to ports (the packaging instructions), so I did an update of Qt from 5.6.1 to 5.6.2 and we handled the review through FreeBSD’s Phab. The ports infrastructure is stored in SVN, so the review is relatively straightforward: update the ports-tree checkout, apply your changes, use arc to create or update a review request. I was amazed by how painless it was — somehow I’d been frightened. Using the tool once, properly, makes a big difference in self-confidence.

At this point, the tooling no longer stands in my way, and we can expect to have KDE-FreeBSD updates rolling out a little faster (until we’re caught up, finally). Current status is: Qt 5.6.2 is in exp-run (last stage before committing), KDE 4 infrastructure has landed, KF5 is being prepared for review by Tobias, and the plasma5/ branch of area51 contains the latest bits of everything released by the KDE community that we can port.

Posted in Bla Bla, FreeBSD, KDE | 1 Comment

Qt 5.6.2 on FreeBSD

Qt 5.6.2 was released today, the second patch release to the LTS (long-term support) Qt 5.6 release. Tobias had done prep-work by writing the FreeBSD ports for the last snapshot; I accidentally nuked that this morning, but now this afternoon I’ve restored Qt 5.6.2 final to the area51 unofficial ports tree. Since this is a patch-release, I’ll PR it shortly and then we can expect it to end up in official FreeBSD ports shortly.

One little blurb from the release-blog:

Qt 5.6.2 is well suited for users that can not upgrade to a later version of Qt, for example due to dependency to C++98 compiler.

In our (FreeBSD) case, what’s blocking is Qt 5.7 and WebEngine, which remains a big pain in the butt to get working at all (because its upstream doesn’t care about all the platforms that Qt cares about, or that KDE cares about, or that I care about — in decreasing size of audience, I think). How big a pain in the butt? Well, I’ve heard of efforts to update WebKit (not only in BSD-land, mind) and even efforts to port current KDE PIM back to an updated WebKit, thus dropping the WebEngine dependency introduced there. I imagine — or hope — that the pain in the butt of doing that is smaller than the pain of massaging WebEngine into shape. Basic economics — reduction of pain in the butt. I have no idea what’s happening there long-term. Suffice to say that for now, Qt 5.6 is where it’s at on FreeBSD.

KDE Frameworks 5 is lined up for use; there’s a big change in KDE ports infrastructure on FreeBSD going down, which will make it easier for us to keep KDE4 and KDE Frameworks, Plasma and Applications running side-by-side for now, and will help ease the porting maintainence burden. That big change has reached the last stage: an exp-run, which rebuilds everything on every version on every architecture. Once the fallout from that is cleared, KDE Frameworks 5.27 is ready for landing.

Posted in FreeBSD, KDE | 2 Comments

KDE Frameworks 5.27.0 on FreeBSD

The latest KDE Frameworks release — this month is 5.27 — is available in the unofficial KDE-FreeBSD ports repository, area51. Users of the plasma5/ branch in that repository can update as usual. or from the bleeding-edge packages provided by the KDE-FreeBSD team.

The state of those ports with respect to the official ports tree is unchanged: we’re working on getting the infrastructure updates needed to subsequently push KDE Frameworks into official ports (just Frameworks, initially, not Plasma or newer applications) and that’s a long-ish process.

Posted in FreeBSD, KDE | Comments Off on KDE Frameworks 5.27.0 on FreeBSD

KDE Plasma 5.8 LTS on FreeBSD

There’s an LTS (long-term support) release of KDE Plasma 5 available now. The dot story is quite extensive. The FreeBSD ports for this LTS release can be found in area51 (as usual) in the plasma5 branch (as is the norm as long as we’re not done settling other KDE foundations in official ports).

There are also packages available, although those are obviously not sourced from the official FreeBSD package servers but from the KDE-FreeBSD team’s servers. Ask in #kde-freebsd on freenode if you need instructions for adding that repository server.

While the upstream release is an LTS one, we (as in the KDE-FreeBSD team) have not thought about how this translates to FreeBSD ports. The official ports tree doesn’t really support LTS-type releases without forking the tree. What might happen is that we branch off in area51 and keep that around — then users specifically interested in the LTS aspect can merge that with their ports tree. Then again, it might not: we don’t have a lot of energy left over to spend on even more branches.

So where are we regarding the rest of the KDE ports (modernizing KDE4, adding KDE Frameworks 5, etc.)? Well, there’s a Phab review going on to adjust the infrastructure to make the KDE ports more flexible; that is a prerequisite for pushing in the rest. However, once it’s in then we have area51 trunk lined up to add KDE Frameworks 5 ports. Since those are new ports, it’s a lot more straightforward than adjusting infrastructure that a lot of ports depend on.

Answer: slowly getting there.

Posted in FreeBSD, KDE | Comments Off on KDE Plasma 5.8 LTS on FreeBSD