---
date: 2024-12-05T01:28:59Z
update: 2024-12-09T23:34:00Z
---
An event where the goal is to write some code daily for the month of December.
It should probably noted this is not my first year participating, though it is my first year with a log entry that wasn't just a list of dates. 2022 was the first year, and activity was recorded at the time over a private shell account on a VM that the event organiser graciously hosted. Made a text-based custom map navigator that year inspired by text adventures and role-playing world building. Afterwards removed the repo of scripts made during the month and forgot to import the log.
Last year started well enough but things got busy, stopped after the 20th. Will see what happens this year.
This entry will be updated every few days until the end of the month, or life calls and demands what remains of the year, whichever occurs sooner.
Wrote a messy shell script to install a Wireguard server on Alpine Linux and add a number of peers. It's an automated version of the instructions on the Alpine wiki. Had a VM going up for renewal and decided to migrate to another server. Wireguard was one of the applications reinstalled successfully on a VM with the script. While not difficult to set up manually, it would save some time in case of another VM migration or reimaging. Might refactor the script later.
There seems to be an oddity with wireguard-tools (1.0.20210914-r4) whereby if the same interface were reconfigured multiple times, wg-quick will insert subnet drop rules. This was possibly to revoke access for the previously assigned subnets, but something may be wrong with the syntax, which caused all traffic on the net interface to be dropped. Reinstalling the package resets the configuration and resolves the issue.
Configure a Wireguard interface (wg)
Started adapting a build script to cross-compile a mainline kernel for my Asus Chromebook C201, based on the fantastic linux-edge Alpine Linux package script by mps and a kernel config from Arch Linux ARM. It builds slowly on my small VM and failed twice so far at the package stage due to small sections that hadn't modified correctly. linux-edge is set up to build for all architectures that Alpine currently supports but my version only targets armv7.
An Alpine Linux maintainer active in the PostmarketOS community also maintains a linux-veyron kernel downstream. However, Arch Linux ARM was the first OS had booted on the C201, before there were other options like PrawnOS, so it is a bit like coming full circle in reusing the linux-armv7 kernel config.
Update 2024-12-08: the patch is not necessary to use a custom source path outside of `~/aports`. Passing in an `APORTSDIR` environment variable will work, e.g. `APORTSDIR=~/my-custom-ports abuild rootbld`. The .rootbld-repositories files would be needed for custom package cache locations to be detected. Leaving the patch up as an artifact of December Adventure.
---
Stapled onto abuild (Alpine Linux's package build application) support for building outside of the default `~/aports` path using the `rootbld` option. Basically it allows using the rootbld like this:
cd ~/my-ports/repo/pkgname abuild rootbld
Previously it would have resulted in an error, `bwrap: Can't chdir to /home/user/my-custom-ports/repo/pkgname: No such file or directory`. This is done by copying the `pkgname/` directory into the build chroot before invoking bubblewrap.
The repo directory would still need a `.rootbld-repositories` file for it to work, similar to the ones found in aports. Add the `REPODEST` path (the output directory path set in `/etc/abuild.conf`) or a URL to the custom repo(s) if building packages that depend on other packages only found there.
$mirror/$version/main $mirror/$version/community /path/to/my-ports-repodest/repo
It will remain a local modification as people are probably not supposed to build outside of the aports git repo. Attached the patch on the off chance it may be useful for others. Works with a rebuild of abuild 3.14.1-r3.
A bit of terminology and background on the previous few days along as the logs may have been a bit confusing for people unfamiliar with Alpine Linux software packaging:
- abuild: a tool used to build packages based on instructions from APKBUILD files. Both abuild and APKBUILDs are written in shell script. `rootbld` is an option in abuild that enables building a package inside a chroot, usually a small filesystem in which to run processes. Mostly helps to keep source from different build runs separate and clean up temporary files.
- aports: the official Alpine Linux source tree for package build scripts. This includes the APKBUILD for each package, along with any patches, install scripts that are triggered to run before and after installation, and so on. Package additions, upgrades and fixes are done there, using git and a git hosting instance. An "aport" can also refer to an Alpine package. A "package" could be the build script of the software being packaged, or the resulting archive with an .apk extension that users download and install (currently a tarball with custom headers, no relation to the Android .apk format). A "repo" can either refer to aports (as a git repository), or one of the current three sections within aports where packages are placed: main, community and testing.
Some people have a personal or third-party source tree where they keep modifications of existing packages (e.g. to enable experimental/unsupported features), legacy software, or packages that might not be a good fit for aports, such as packages that require specific versions of dependencies that don't co-exist with ones in the aports repos.
Mine is tiny at the moment, just a few packages from my migration to Alpine as a desktop distro and found some packages had no direct equivalents or were missing, e.g. mypaint. Some have already been added to aports. A number of packages by other maintainers have also appeared since then like tmuxinator. Initially my goal had been to gradually move them to aports if the packaging was stable and didn't have often have breaking changes, but it calls for a certain amount of time commitment to ensure they remain in good shape. It is probably better to not officially maintain if could not provide an assurance they will be upgraded in a timely manner and fix issues if they arise.
December Adventure will likely consist of me revisiting the git repo to remove obsolete or unused package scripts, then import or add new scripts for some of the regularly used software and libraries (and where a bit of coding comes in). This has a different goal, which is to ease restoration of a working setup and fallback in case of software or hardware failure, and to have better control over the pace of package upgrades. Details have yet to be worked out. For now, would like fix up my C201 kernel build script, test that it actually boots with a minimal filesystem, before rebuilding (and potentially patching) more packages.
Tried out cross-compiling to armv7 with `abuild rootbld` and it worked, if a bit slowly on my single-core x86_64 VM. Combined it with the `buildrepo` command from the lua-aports package to cross-compile a small number of custom packages for armv7 after a repo cleanup and upgrading packages to newer releases. Among other features, buildrepo invokes abuild to build all the packages within a repo or set of repos.
Also have a first passing build of linux-veyron from the build script. It still needs some adjustments, e.g. it installs a number of device trees (.dtb) and the C201 should only need one. Fortunately at this point it's possible to rerun `abuild rootpkg` to adjust the packaged files and not have to recompile the kernel each time.
Kernel build script temporarily delayed by an issue with ibus (an input method editor) — its gschema files (xml files that enable changing settings with dconf editor) are using deprecated namespace paths and the glib schema generator utility is issuing warnings about it. Some users think the warnings are confusing as they mainly targeted towards app developers and would like their output suppressed within the schema generator. Generated a patch in an attempt to address the warnings, mainly string replacement. Touched code but didn't code anything today.
Kernel build sidetracked, this time by a search for an answer to a question one of the Alpine developers had on whether Qt6 QML (version 6.8.1) was broken on armhf. Haven't got an armhf device with Alpine installed and internet-connected, so the next option was an emulator/Qemu VM or to check it on the aports CI runners (aarch64 servers running in 32-bit). A slight complication is the application needs to be run under a display server like X or Weston, but it's possible to run it with Xvfb simulating X server.
Stuck the test inside an APKBUILD so it could be put through CI. It's very simple and probably doesn't count as coding, but serves the purpose.
check() {
mkdir -p "$builddir"
cp "$srcdir"/hello.qml "$builddir"/
xvfb-run -a /usr/lib/qt6/bin/qmlscene --quit hello.qml
}
A check function drops a copy of a sample script from the Qt documentation into the build directory, and runs the `qmlscene` executable on the sample script via xvfb-run. If successful, it will exit 0 when done, the script will proceed to the package function (not shown here) and complete the build. The check will fail if there is an error.
The test results indicated something seems to be broken on 32-bit ARM. The test segfaulted on armhf and armv7 while passing on the other arches. Also reproduced the segfault on an armv7 X server installation, where a window appears but the objects don't get rendered. Most of the testing was rebuilding qtdeclarative with different compiler flags to see if it would fix the segfault. No such luck yet.