There is a move to Bring Back Blogging and having recently sorted out my own FreshRSS install I am completely in favour of such a thing. RSS feeds with complete posts, for preference, not just a teaser intro sentence/paragraph.

It’s also a reminder to me that I should blog more, and what better way to start 2023 than with my traditional recap of my Free Software activities in 2022. For previous years see 2019, 2020 + 2021

Conferences

I attended DebConf22 in Prizen, Kosova this year, and finally hit the end of my luck in avoiding COVID. 0/10, would not recommend. Thankfully I didn’t come down with symptoms until I got home (I felt fine and tested negative on arrival home, then started to feel terrible the next day and tested again), so I was able to enjoy the conference itself. I also made it to Linux Security Summit Europe 2022, which aligned with work related bits and was interesting. I suspect I would have been better going to LPC 2022 for the hallway track, though I did manage to get some overlap with folk being in town given that both were the same week.

Debian

Most of my contributions to Free software continue to happen within Debian.

We continue to operate a roughly 3 month rotation for Debian Keyring in terms of handling the regular updates, and I dealt with 2022.03.24, 2022.06.26, 2022.08.11, 2022.09.24, 2022.09.25 + 2022.12.24. There were a few out of cycle updates this year and I handled a couple of them.

My other contributions are largely within the Debian Electronics Packaging Team. gcc-xtensa-lx106 saw a few updates, to GCC 11 + enabling D (10 + 11), then to GCC 12 (12). binutils-xtensa-lx106 got some minor packaging cleanups, which also served to force a rebuild with the current binutils source (5).

libsigrokdecode got an upload to enable building with Python 3.10 (0.5.3-3). Related, I updated sdcc to a new upstream version (4.2.0+dfsg-1) - it’s used for the sigrok-firmware-fx2lafw package and I do have a tendency to play with microcontrollers, so it’s good to have a recent version available in the archive.

I continue to pay attention to OpenOCD, with a minor set of updates to pull in some fixes from master (0.11.0-2). I was pleased to see the release process for 0.12.0 kick off and have been uploading RCs as they come out (0.12.0~rc1-1, 0.12.0~rc2-1 + 0.12.0~rc3-1). Upstream have been interested in the upcoming bookworm release cycle and I’m hopeful we’ll get 0.12.0 proper in before freeze. libjaylink also saw an upstream release (0.3.1-1).

Package upload sponsorship isn’t normally something I get involved with, because I find I have to spend a lot of time checking over things before I’m comfortable doing the upload. However I did sponsor an initial upload for sugarjar and an update for mgba (0.10.0+dsfg-1, currently stuck in NEW). Credit to Michel for dealing swiftly with my review comments, and Ryan for producing a nicely reviewable set of changes.

As part of the Data Protection Team I responded to various inbound queries to that team. There was also some discussion on debian-vote as part of the DPL election that I engaged with, as well as discussions at DebConf about how we can do things better.

For Debian New Members I’m mostly inactive as an application manager - we generally seem to have enough available recently. If that changes I’ll look at stepping in to help, but I don’t see that happening (it got close this year but several people had stood up before I got around to offering). I continue to be involved in Front Desk, having various conversations throughout the year with the rest of the team and occasionally approving some of the checks for new applicants.

Towards the end of the year I got involved with the Debian Games Team, largely because I’m keen to try and get my Kodi working with libretro based emulators - I’d really like to be able to play old style games from the same interface as I can engage with locally stored movies, music and TV.

It turns out there are a lot of moving pieces to make that happen, some missing from Debian and others in need of some TLC. I updated retroarch to current upstream (1.13.0+dfsg-1 + 1.13.0+dfsg-2) but while I was doing so upstream did another release. I plan on uploading 1.14.0 once 1.13.0 has migrated to testing. It turned out I also needed to update libretro-core-info (1.13.0-1) and retroarch-assets (1.7.6+git20221024+dfsg-1). In terms of actual emulators I pulled in new versions for genesisplusgx (1.7.4+git20221128-1) and libretro-bsnes-mercury (094+git20220807-1).

On the Kodi side I haven’t uploaded anything yet. I’ve filed an ITP for rcheevos, which is a dependency for game.libretro and I have a fledgling package for game.libretro that I finally got working today. I’m not sure if I can get it cleaned up enough in time to make the bookworm release, but I’m hoping that at least the libretro piece is in a bit better shape now (though I’m aware there are more emulator cores that could do with being updated).

Linux

This year was a quiet year for personal Linux contributions. I submitted a minor fix for the qca8081 PHY with speeds lower than 2.5Gb/s that caused me issues on my RB5009.

Personal projects

2022 finally saw a minor releases of onak, 0.6.2, which resulted in a corresponding Debian upload (0.6.2-1). It has a couple of bug fixes but nothing major.. As I said last year it’s not dead, just resting, but Sequoia PGP is probably where you should be looking for a modern OpenPGP implementation.

I added some basic Debian packaging to mqtt-arp - I didn’t bother uploading it as it’s a fairly niche package, but I’m using it locally.

Work related

I changed jobs at the start of the year and surprisingly this marks the first time I have had a role where I’ve been actively encouraged to work on Free software projects and push upstream, both at an organisational and team level. That’s been pretty cool and early on I managed a minor cosmetic fix in zstd, some certificate checking in a calnex tool and an optimisation for fetching sensor data on network switches.

There was also some performance investigation that led to the discovery and fixing of excessive heap allocation in a torrent library.

Finally I managed to submit my first kernel contribution that was part of a day job need rather than just a personal itch - it only took me 18 years from my first contribution being taken. That work enables IMA measurement logs to be carried over kexec on x86_64. I’ve got some additional patches (to export Intel TXT info via securityfs and support measurement of kexec initramfs components) but both haven’t had a lot of feedback and I need to do some clean-up and re-submit.

That wraps up 2022. For 2023 I’m hoping to get the remaining Kodi/libretro pieces in place in Debian - I think I’m close to having something that works well enough to upload, and I have some ideas about general infrastructure to make things easier longer term. I’m expecting to chase up the 2 stalled work-related kernel contributions (and I’ve spent some time trying to cleanup the early decompression logic too but not in a state suitable for submission yet). Conference-wise I hope to be at DebConf23. I’ll miss FOSDEM - it’s too close to a few other things I’ve got going on. And I’m sure some unplanned stuff will come up too. While this is still a fairly insignificant amount of contributions compared to others I see posting on Debian Planet I do feel I’ve managed to increase my involvement this year, and hopefully that’ll continue. Happy New Year, folks!

Ever since the demise of Google Reader I have been looking for a suitable replacement RSS reader. In the past I used to use Liferea but that was when I used a single desktop machine; these days I want to be able to read on my phone and multiple machines. I moved to Feedly and it’s been mostly ok, but I’m hitting the limit of feeds available in the free tier, and $72/year is a bit more than I can justify to myself. Especially when I have machines already available to me where I could self host something.

The problem, of course, is what to host. It seems the best options are all written in PHP, so I had to get over my adverse knee-jerk reaction to that. I ended up on FreshRSS but if it hadn’t worked out I’d have tried TinyTinyRSS. Of course I’m hosting on Debian, and the machine I chose to use was already running nginx and PostgreSQL. So I needed to install PHP:

$ sudo apt install php7.4-fpm php-curl php-gmp php-intl php-mbstring \
	php-pgsql php-xml php-zip

I put my FreshRSS install in /srv/freshrss so I grabbed the 1.20.2 release from GitHub (actually 1.20.1 at the time, but I’ve upgraded to the latest since) and untared it in there. I gave www-data access to the data directory (sudo chown -R www-data /srv/freshrss/data) (yes, yes, I could have created a new user specifically for FreshRSS, but I’ve chosen not to for now). There’s no actual need to configure things up on the filesystem, you can do the initial setup from the web interface. Which is where the trouble came. I’ve been an Apache user since 1998 and as a result it’s what I know and what I go to. nginx is new to me. And I wanted my FreshRSS instance to live in a subdirectory of an existing TLS-enabled host, rather than have it’s own hostname. Now, at least FreshRSS copes with this (unlike far too many other projects), you just have to configure your webserver correctly. Which took me more experimentation than I’d like, but I’ve ended up with the following snippet:

    # PHP files handling
    location ~ ^/freshrss/.+?\.php(/.*)?$ {
        root /srv/freshrss/p;
        fastcgi_pass unix:/run/php/php-fpm.sock;
        fastcgi_split_path_info ^/freshrss(/.+\.php)(/.*)?$;
        set $path_info $fastcgi_path_info;
        fastcgi_param PATH_INFO $path_info;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    location ~ ^/freshrss(/.*)?$ {
        root /srv/freshrss/p;
        try_files $1 /freshrss$1/index.php$is_args$args;
    }

Other than the addition of the freshrss prefix this ends up differing slightly from the FreshRSS webserver configuration example. I ended up having to make the path info on the fastcgi_split_path_info optional, and my try_files in the bare directory location directive needed $is_args$args added or I just ended up in a redirect loop because the session parameters didn’t get passed through. I’m sure there’s a better way to do it, but I did a bunch of searching and this is how I ended up making it work.

Before firing up the web configuration I created a suitable database:

$ sudo -Hu postgres psql
psql (13.8 (Debian 13.8-0+deb11u1))
Type "help" for help.

postgres=# create database freshrss;
CREATE DATABASE
postgres=# create user freshrss with encrypted password 'hunter2';
CREATE ROLE
postgres=# grant all privileges on database freshrss to freshrss;
GRANT
postgres=# \q

I ran through the local configuration, creating myself a user and adding some feeds, then created a cronjob to fetch updates hourly and keep a log:

# mkdir /var/log/freshrss
# chown :www-data /var/log/freshrss
# chmod 775 /var/log/freshrss
# cat > /etc/cron.d/freshrss-refresh <EOF
33 * * * * www-data /srv/freshrss/app/actualize_script.php > /var/log/freshrss/update-$(date --iso-8601=minutes).log 2>&1
EOF

Experiences so far? Reasonably happy. The interface seems snappy enough, and works well both on mobile and desktop. I’m only running a single user instance at present, but am considering opening it up to some other folk and will see how that scales. And it clearly indicated a number of my feeds that were broken, so I’ve cleaned some up that are still around and deleted the missing ones. Now I just need to figure out what else I should be subscribed to that I’ve been putting off due to the Feedly limit!

Over the weekend I released a new version of onak, my OpenPGP compatible keyserver. At 2 years since the last release that means I’ve at least managed to speed up a bit, but it’s fair to say its development isn’t a high priority for me at present.

This release is largely driven by a collection of minor fixes that have built up, and the knowledge that a Debian freeze is coming in the new year. The fixes largely revolve around the signature verification that was introduced in 0.6.0, which makes it a bit safer to run a keyserver by only accepting key material that can be validated. All of the major items I wanted to work on post 0.6.0 remain outstanding.

For the next release I’d like to get some basic Stateless OpenPGP Command Line Interface support integrated. That would then allow onak to be tested with the OpenPGP interoperability test suite, which has recently added support for verification only OpenPGP implementations.

I realise most people like to dismiss OpenPGP, and the tooling has been fairly dreadful for as long as I’ve been using it, but I do think it fills a space that no competing system has bothered to try and replicate. And that’s the web of trust, which helps provide some ability to verify keys without relying on (but also without preventing) a central authority to do so.

Anyway. Available locally or via GitHub.

0.6.2 - 27th November 2022

• Don’t take creation time from unhashed subpackets
• Fix ECDSA/SHA1 signature check
• Fix handling of other signature requirement
• Fix deletion of keys with PostgreSQL backend
• Add support for verifying v3 signature packets

I have 2 very useful shell scripts related to resizing consoles. The first is imaginatively called resize and just configures the terminal to be the requested size, neatly resizing an xterm or gnome-terminal:

#!/bin/sh

# resize <rows> <columns>
/bin/echo -e '\033[8;'$1';'$2't'

The other is a bit more complicated and useful when connecting to a host via a serial console, or when driving a qemu VM with -display none -nographic and all output coming over a “serial console” on stdio. It figures out the size of the terminal it’s running in and correctly sets the local settings to match so you can take full advantage of a larger terminal than the default 80x24:

#!/bin/bash

echo -ne '\e[s\e[5000;5000H'
IFS='[;' read -p $'\e[6n' -d R -a pos -rs
echo -ne '\e[u'

# cols / rows
echo "Size: ${pos[2]} x ${pos[1]}"

stty cols "${pos[2]}" rows "${pos[1]}"

export TERM=xterm-256color

Generally I source this with . fix-term or the TERM export doesn’t get applied. Both of these exist in various places around the ‘net (and there’s a resize binary shipped along with xterm) but I always forget the exact terms to find it again when I need it. So this post is mostly intended to serve as future reference next time I don’t have them handy.

I bought myself a new keyboard last November, a Logitech G213. True keyboard fans will tell me it’s not a real mechanical keyboard, but it was a lot cheaper and met my requirements of having some backlighting and a few media keys (really all I use are the volume control keys). Oh, and being a proper UK layout.

While the G213 isn’t fully independent RGB per key it does have a set of zones that can be controlled. Also this has been reverse engineered, so there are tools to do this under Linux. All I really wanted was some basic backlighting to make things a bit nicer in the evenings, but with the ability to control colour I felt I should put it to good use.

As previously mentioned I have a personal desktop / work laptop setup combined with a UGREEN USB 3.0 Sharing Switch Box, so the keyboard is shared between both machines. So I configured up both machines to set the keyboard colour when the USB device is plugged in, and told them to use different colours. Instant visual indication of which machine I’m currently typing on!

Running the script on USB detection is easy, a file in /etc/udev/rules.d/. I called it 99-keyboard-colour.rules:

# Change the keyboard colour when we see it
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="046d", ATTR{idProduct}=="c336", \
        RUN+="/usr/local/sbin/g213-set"

g213-set is a simple bit of Python:

#!/usr/bin/python3

import sys

found = False
devnum = 0
while not found:
    try:
        with open("/sys/class/hidraw/hidraw" + str(devnum) + "/device/uevent") as f:
            for line in f:
                line = line.rstrip()
                if line == 'HID_NAME=Logitech Gaming Keyboard G213':
                    found = True
    except:
        break

    if not found:
        devnum += 1

if not found:
    print("Could not find keyboard device")
    sys.exit(1)

eventfile = "/dev/hidraw" + str(devnum)

#                                   z       r     g     b
command = [ 0x11, 0xff, 0x0c, 0x3a, 0, 1, 0xff, 0xff, 0x00, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ]

with open(eventfile, "wb") as f:
    f.write(bytes(command))

I did wonder about trying to make it turn red when I’m in a root terminal, but that gets a bit more complicated (I’m guessing I need to hook into GNOME Terminal some how?) and this simple hack gives me a significant win anyway.