Week 3 of the year continues the concerted (if somewhat piecemeal) process of project spring cleaning. Shipping the Qt version of OpoLua remains a priority and I spent much of the day on release adjacent tasks. I also found my thoughts turning to grand ideas of finally packaging things like Reporter, changes, and InContext, but I must resist! (For the time being, at least.) That said, I did take a little time out to work on the endless task that is home infrastructure.

OpoLua

Last week, before getting distracted by packaging all the things, I identified a few remaining tasks for shipping OpoLua, our modern OPL runtime:

• download links
• screenshots
• documentation
• consolidate shared resources in the source tree

Of these, the highest priorities seemed to be ‘download links’, and ‘documentation’. Both of these will help users install the app: links to downloadable packages; and , for Linux, instructions for how to add our (as yet non-existent) package repositories.

Download Links

The OpoLua website is a Jekyll static site that lives the docs folder of the source tree, and is built as part of our GitHub Actions build workflow. This makes it really easy to inject details like the current version number into the site build and, armed with the jekyll-environment-variables plugin, it was easy to update the template to add a link to the latest GitHub release:

<p class="download-links">

    <a href="https://apps.apple.com/app/opolua/id1604029880">
      <img src="images/Download_on_the_App_Store_Badge_US-UK_RGB_blk_092917.svg" />
    </a>

    <br/>

    <a href="https://github.com/inseven/opolua/releases/tag/{{ site.env.VERSION_NUMBER }}">
      Download for macOS, Windows, and Linux
    </a>
    
</p>

While I’d like to increase the prominence of these new platforms (the App Store link dominates somewhat), something is better than nothing, and I’m pretty pleased with the result:

Documentation

As OpoLua has grown to target multiple platforms, support different OPL versions, and include a suite of CLI utilities, it’s become clear that short FAQ we created when we first shipped was insufficient. Keen to make room for growth, I added a documentation section, styled after Just The Docs:

Our documentation is sparse but now there’s somewhere to put it

To complement these structural changes, I also added highlight.js, Mermaid, and jekyll-gfm-admonitions, to provide us with conveniences for syntax highlighting, diagramming, and GitHub-style admonitions respectively.

Home Infrastructure

Over the past few days, I’ve been slowly pushing on with my home infrastructure setup. I finally resigned myself to using Ansible for managing my NAS/server—hopefully this will make it easier to keep the configuration in source control and increase my confidence as I continue to move away from Big Tech hosted services.

I also took delivery of a new 1U rack shelf and spent a little while moving my LincStation N2 NAS/server into the rack, indulging in the prerequisite CAD and 3D printing to mount the network switch alongside it:

Having spent an overly long day working on packaging OpoLua, Friday proved a slow one, with little visible progress: I took some time to plan out the remaining work to ship OpoLua; added Thursday’s binary Arch builds to the releases¹; and tidied up the repository a little. Good work, but unexciting.

Without a doubt, the highlight of the day was this screenshot from Alex, host of the Psion Discord and maintainer of Haiku’s MAME package:

I continue to be amazed by how portable Qt is, and there’s little better in life than a Haiku screenshot.

Continuing with my goal of trying to ship the Qt variant of OpoLua—our modern OPL interpreter—for macOS, Windows, and Linux, I spent much of the day diving into the ugly world of Linux packaging. To make things a little more palatable, I also treated myself to a small update to Reconnect, my Psion connectivity suite for macOS.

OpoLua

My primary focus for the day was to set up Linux smoke-test builds to ensure that we don’t unintentionally break builds on the platform. Having already figured out how to build on Ubuntu, setting up automated builds proved easy—a matter of adding a GitHub Actions job to the workflow, and crafting a lightweight build script. I continue to be impressed by Qt’s tooling, which reduces builds on almost all platforms to:

qmake6
make

Spurred on by a quick win, and lulled into a false sense of security, I decided to try tackling packaging for Ubuntu. When I’ve built Debian packages in the past using the standard tooling, I’ve been frustrated by the need for distro-specific directory structures so, to avoid polluting our source tree, I decided to look for an alternative. This took me to fpm or ‘Effing Package Management’, a multi-distro packaging tool which proved incredibly powerful, allowing me to generate a .deb from the directory output of Qt’s make install using a single command:

ARCHITECTURE=`dpkg --print-architecture`
fpm \
    -s dir \
    -t deb \
    -p "opolua-ubuntu-24.04-$ARCHITECTURE-$VERSION_NUMBER-$BUILD_NUMBER.deb" \
    --name "opolua" \
    --version $VERSION_NUMBER \
    --architecture "$ARCHITECTURE" \
    --description "Runtime and viewer for EPOC programs and files." \
    --url "https://opolua.org" \
    --maintainer "Jason Morley <[email protected]>" \
    --depends libqt6core6 \
    --depends libqt6gui6 \
    --depends libqt6widgets6 \
    --depends libqt6multimedia6 \
    --depends libqt6core5compat6 \
    --chdir "$INSTALL_DIRECTORY" \
    .

(You’ll notice I’m getting the architecture with dpkg --print-architecture—using ARM and Intel runners with GitHub Actions matrix builds, the build script can output releases for both architectures.)

I shared the builds with a few members of the Psion Discord, and Colin kindly sent me a couple of screenshots of OpoLua running on Kubuntu—it’s a real reward to see others using our creation.

Jumpy! is a wonderful showcase for OPL

While there are still many different Linux distributions and versions to add to the build script (and I’d like to set up an apt repository to ensure folks can get automatic updates), I’m pretty pleased with this progress.

… But I couldn’t leave it there. I decided to try tackling Arch Linux—a distro I’ve little experience of. Starting this at 10pm was perhaps a poor choice. fpm did its job well, and I able to change a couple of flags and output a pacman binary package, but Alex quickly dissuaded me of the notion that this was good enough: binary packages are (understandably) frowned upon in Archland and PKGBUILD source builds (distributed via AUR) are preferable as they increase transparency.

PKGBUILD configuration files seem mostly well designed and, with Alex’s help, I was able to craft something that worked. The big challenge was how Git submodules are (or aren’t) handled: while there’s good support for Git, there’s absolutely no support for submodules—you have to manually recreate these in your prepare. For a project like OpoLua that relies heavily on recursive submodules, this is a miserable experience. makepkg (which processes PKGBUILD files) will check out each submodule at the top-level, and you have to rewrite all the submodule urls from the bottom up:

prepare() {

    cd "$srcdir/opolua"
    git submodule init
    git config submodule.LuaSwift.url "$srcdir/LuaSwift"
    git config submodule.diligence.url "$srcdir/diligence"
    git config submodule.scripts/changes.url "$srcdir/changes"
    git config submodule.scripts/build-tools.url "$srcdir/build-tools"
    git -c protocol.file.allow=always submodule update --recursive

    cd "$srcdir/opolua/dependencies/LuaSwift"
    git submodule init
    git config submodule.Sources/CLua/lua.url "$srcdir/lua"
    git -c protocol.file.allow=always submodule update

}

I’ve yet to work out how to synthesize per-release versions of the PKGBUILD file, or how to get those into AUR, but it’s good to have broken the back of this.

Reconnect Menu

While Apple’s Liquid Glass is incredibly divisive and widely derided (I personally dislike it), I’m keen for my apps to feel at home on the system—I don’t want to add to users' cognitive burden by rejecting platform choices. With that in mind, I’ve been slowly adopting the new menu icons, and I took a little time to add them to the Reconnect menu bar menu:

It’s not clear to me that this is an improvement—there’s a recent piece over at tonsky.me that captures many of the issues—but it’s where things are going. Perhaps I’ll use this investigation by Brent Simmons to give users a choice.