Status update, July 2022

Welcome back to the next installment of monthly status update! Let’s see what we have in stock this time.

Somehow, almost everything that happened this month seems to somehow be connected, making it hard for me to group it into sections. Let’s experiment and see if we can do without, why not?

“Where shall I begin, please your Majesty?” he asked. “Begin at the beginning,” the King said gravely, “and go on till you come to the end: then stop.”

It all started with a new release of the IPMI exporter. This is of course good news, but every time I work on it, I run into a little issue. I currently do not have easy access to any real-world IPMI interfaces (i.e. BMCs), which sometimes makes it cumbersome to test certain changes or triage bug reports.

But relief might be on the horizon. I am happy to report that we started shopping for co-location providers for SourceHut in Amsterdam. Nothing is finalized, but I am excited to see this start taking shape. And to a tiny extend this is also because I hope to get some IPMI action going in the new setup.

Speaking of SourceHut: this month was dedicated to lists.sr.ht. We managed to track down and fix a very annoying bug, where sometimes some emails would not show up in the web interface. It turned out to be a problem with the assignment of emails to threads if the emails arrived out of order. The issue was fixed and we were able to retro-actively fix all broken threads in the database.

Adnano is still going strong implementing GraphQL APIs all over the place, including of course lists.sr.ht. The API includes a way to fetch email threads in a structured way that supports inline responses, provided by Simon’s go-emailthreads library. I went ahead and tried to use it to display patch reviews in the web interface, but unfortunately there are some issues to be worked out in the GraphQL database layer before this can happen.

Staying on the topic of emails, some progress was made on vomit, though much of it remains in my head for now. I decided to split out the configuration as a stand-alone crate. This way, different tools can re-use the same configuration file, as most email tools need the exact same settings anyway. For now, vmt and vsync both use it.

What I envision, though, is also having GUI tools use it. I have continued experimenting with the Rust Qt bindings. I am looking to create a GUI that is composable (think “sending an email does not require looking at your emails”), equally well-usable with keyboard and mouse, and generally very focused (only have GUI elements relevant to the current task) without restricting power users. I might be aiming high, but you have to have dreams, right? :)

I hope to have something presentable by next month, but for now I’ll point you to bfcal, my slightly ironic but also totally serious OSD calendar that I created while experimenting with GUI designs (I really use it!).

Also, for any mail tooling based on the vomit project to be really useful, vsync will need to be able to sync mailboxes two-way. Somewhat unfortunately, I made the classic mistake of taking on two unrelated tasks at once and started to implement the two-way sync relying heavily on the QRESYNC IMAP extension, only to find out half way that support for some of its features is missing in the rust-imap library. Fortunately, though, the crate is about to release a new major version soon. With some, luck this might allow yours truly to get the necessary changes merged soon, even though they affect the public API. What perfect timing!

OK, I admit it: one thing didn’t quite fit the narrative. I started to POSIXify makeimg (link is to a branch). Much like Alpine APKBUILDs are a POSIXified version of Arch PKGBUILDs (I’m oversimplifying), it became apparent that for makeimg to really make sense with Alpine, it too would have to undergo that treatment. There is still a long way to go, but a first step is done: the IMGBUILD file format is POSIX-compliant, which means one can now actually build Alpine images that do not have bash installed.

So there we go. This is the end, and I’ll stop. As always, my public inbox is open for questions and comments, or you can ping me on IRC, I am bitfehler on Libera.chat.