This Week in Spectrum, 2025-W43

Alyssa Ross
2025-10-27T13:17:50Z

[-- Attachment #1: Type: text/plain, Size: 3457 bytes --]

Hi! I'm back after being unwell for a couple of weeks. As such, I'll
be covering things that have happened since the last update.

Demi fixed the BPF x86_64 build failure mentioned last time by avoiding
the use of userspace headers in BPF compilation environments[1]. While
she was at it, she also submitted a refactor and possible small
performance improvement, which is still awaiting review.

[1]: https://spectrum-os.org/git/spectrum/commit/?id=db54efac07deee32f39bdec4e4b8b73674df18c7
[2]: https://spectrum-os.org/lists/archives/spectrum-devel/20251021-fix-forwarder-build-v4-2-b978718c004d@gmail.com

Yureka fixed some recently introduced build regressions in Nixpkgs[3],
including a fix for iproute2 which was applied upstream[4], and then
submitted a patch to update Spectrum's pinned Nixpkgs[5]. I am
absolutely delighted with this, because it's the first time anybody else
has taken on this regular maintenance work. Unfortunately, when I
tested the Nixpkgs update, I found that the networking integration test
no longer passed. A still-running bisect indicates this is probably due
to the update to Linux 6.17. If so, it's probably been caught by
somebody else and fixed already, so which means hopefully the fix will
just be to update to an even newer Nixpkgs and cross our fingers no new
build regressions have been introduced in the meantime. Yureka has also
been working on automatically testing Spectrum builds against newer
Nixpkgs versions, which I hope might pave the way for semi-automatic
updates at some point, and/or automated notifications of regressions.

[3]: https://spectrum-os.org/lists/archives/spectrum-devel/82249ddc-ae1a-4e3a-a6ae-bb4717243fca@yuka.dev
[4]: https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=25b2834cc974729229afcd308f127995405f85c5
[5]: https://spectrum-os.org/lists/archives/spectrum-devel/20251012222756.20947-2-yureka@cyberchaos.dev

I've been working on running Flatpak applications in VMs. This is a bit
more complicated than the AppImages we already support, because rather
than relying on the system to provide libraries, Flatpaks are installed
to a shared OSTree repository, so that they can be hermetic while still
not duplicating huge amounts of common libraries between applications.
We don't want to just pass through the whole Flatpak repository to
application VMs, because then any application would be able to see which
other applications were installed, so to do Flatpak VMs we need to
determine which paths are actually needed by an application, and pass
through just those. I've written a program that sets up bind mounts for
a Flatpak application and its runtime to pass through to a VM (but not
extensions yet), and also the glue in the Spectrum application VM to
actually run a passed through Flatpak. I haven't had a chance to do a
full end to end test yet, but I think everything should just about work.

Thanks to work from Demi[6], file modes in Spectrum images are now fixed,
rather than being affected by the build environment. As well as being
an important reproducibility fix, this will be important to start
running things as non-root users, where modes actually become relevant.

[6]: https://spectrum-os.org/git/spectrum/commit/?id=a972ba0ce2be8fb32f4b44a708024cdcddd890e6

Demi has been working on implementing OS updates using
systemd-sysupdate, and just got to the point where everything works!
Hopefully we'll see that on the list soon.