_Status update, March 2022

_Meson

Even though they may have their shortcomings, I have mostly been using autotools when creating new projects in C. They are almost universally available and while they put some burden on the maintainer (or potentially packager), they are often reasonable for the end user. I have used CMake a lot (e.g. in the KDE ecosystem), but it never really clicked. Other build systems came and went. Meson is one that I’ve recently been seeing get adopted by many projects, even low-level ones. So when this month I got into a big argument with autotools over how to find a certain library, I decided to give it a try (see CMOS below).

The experience was mostly pretty good. I still need to figure out a few things and probably learn a few more conventions. I am excited to see that Meson has built-in support for such things as unit testing, code coverage, valgrind, static analyzers, and even linting.

Of course there always is something. After being very excited that Meson found all libraries immediately, I was slightly disappointed that it didn’t do so on FreeBSD. This was easy to fix, but feels a bit clumsy. I also wasn’t the first one to notice. Maybe this is something for the next month to look into…

Also, while I have not done this at all yet, I am eager to look into Muon. If it turns out to be a viable substitute, then even the Python dependency that I grudgingly accept for now would no longer be an issue.

_GraphQL

I finally started learning more about GraphQL. Probably not surprising, given that Sourcehut is currently migrating to a GraphQL based API. The GraphQL homepage has a lot of material to get you started. In the context of Sourcehut, I highly recommend checking out Simon’s hut tool. It’s great for many reasons, but specifically it lets you send custom GraphQL queries:

hut graphql meta <<EOF | jq '.me'
query {
	me { canonicalName }
}
EOF

If you are interested to learn more, check out the Sourcehut GraphQL documentation. There is even a playground to send custom queries (though the hut tool will be easier for serious usage).

However, at some point, the bug I was investigating turned out to not be GraphQL-related at all, sending me down a completely different rabbit hole. But learning about GraphQL was great and will definitely facilitate further work on the forge.

_CalDAV/CardDAV

I bet you didn’t see this one coming (I certainly didn’t)! The CardDAV and CalDAV protocols are quite old, but they are still the underpinning of most remote address book and calendaring solutions. Simon Ser has already written several related Go packages. We now started a new project to put them to good use.

Unfortunately the protocols are not exactly simple. They are extensions to WebDAV, which is already quite complex. They also use XML, which I hadn’t used in a while. Nevertheless, working with RFCs is always great. The specifications are usually of good quality, and in the end you can create software that is interoperable with a huge amount of existing solutions.

Read on below to find out what we are up to.

_CMOS

On my quest to reinvent everything for my blog, I started CMOS. It’s a thin layer around cmark, the CommonMark reference implementation. CMOS adds simple syntax highlighting with GNU Source-highlight (see GraphQL for a not-so-great example), and ID attributes to headings so you can link to them. The latter optionally come with anchors, which you can see in action by hovering over any section heading in this article, which was rendered with CMOS.

CMOS is exactly the markdown renderer I always wanted. Your mileage may vary if your use case is different. See the homepage for more details.

_Tokidoki

As hinted above, we started tokidoki, a CalDAV/CardDAV server written in Go. Given these protocols’ omni-presence and the limited number of available (open source) server implementations, we felt there was some need for a robust and scalable solution that is easy to deploy. We hope to deliver this with tokidoki. It’s heavy work in progress, but one branch already contains a reasonably working CardDAV server. All interfaces are still subject to change, though, so don’t go using this for anything serious yet.

_xbscli

I finally managed to track down what I am quite confident was the last incompatibility of the compression algorithm implementation with the official clients. I now consider writing to the API reasonable safe. A first convenience command (write) has been added, more to follow. See the updated homepage for details.

_IPMI exporter

I finally managed to give some lovin’ to the IPMI exporter again. The move to its current home in the prometheus-community Github org brought a lot of benefits, but required many changes. The Docker images broke along the way.

Most issues have been addressed, and new releases were made. The latest one (1.5.2) provides at least a working Docker container for amd64 again. I hope to bring back the other architectures soon. But on the plus side, the container is now easily available as prometheuscommunity/ipmi-exporter-linux-amd64:v1.5.2, no need to build it yourself anymore.

_Sourcehut

The focus last month was on fixing bugs. Some got fixed. Others have taken unexpected turns, but we are getting close. Some new stuff was found while triaging old patch submissions. You know, life.

There is some progress on the documentation, but I have been slow to incorporate the feedback. I’ll do my best to move this forward next month.