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=db54efac07deee32f39bdec4e4b…
[2]: https://spectrum-os.org/lists/archives/spectrum-devel/20251021-fix-forwarde…
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-a6…
[4]: https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=25b…
[5]: https://spectrum-os.org/lists/archives/spectrum-devel/20251012222756.20947-…
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=a972ba0ce2be8fb32f4b44a7080…
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.
It was quite a week. Yureka and I were at XDC from Monday until
Wednesday. My talk, "An upstream-first approach to application
virtualization", was on Tuesday, and the video is now online[1]. I
didn't learn that much at the conference that was directly relevant to
Spectrum, but I was interested to learn from a lightning talk that
kmscon has been revived and was recently repackaged in Fedora[2]. I'm
still getting used to public speaking again, so the talk wasn't as
smooth as I'd have liked, but it was okay. After XDC, I stopped by the
Systems Meetup Dresden[3] and did a lighting talk. This one went much
better, but wasn't recorded, so you'll just have to believe me.
While we were away, All Systems Go[4] (AIUI basically the systemd
conference) took place in Berlin, and that meant a lot of Linux
mobile/desktop people were in town who are not normally. We were able
to get together over the following days, and in particular we had some
good conversations about what the future of Flatpak/Portals might look
like. It's great to be in the room for this sort of thing because it
means Spectrum's needs can be considered from the start. The designs
being considered would solve our biggest pain points, so I'm optimistic,
but there's of course the question of momentum / developer attention to
make it happen. Hopefully we can contribute to that.
[1]: https://video.tuwien.ac.at/events/xdc/v/Ow9xtIyJeTt?t=01h13m49s
[2]: https://github.com/Aetf/kmscon/
[3]: https://ukvly.org/
[4]: https://all-systems-go.io/
In between the talks at XDC (and during some of the talks about graphics
drivers I had no hope of understanding), I was pleasantly surprised to
find myself in a particularly productive state — it must have been the
conference atmosphere. It didn't make sense to try to work on anything
big, so I went through my backlog of small Spectrum improvements.
Image rebuild times during development have gone down by a further
non-trivial two seconds on a fast laptop, more code has been integrated
into the single Meson build system I aspire to, and a few other smaller
things. I also managed to completely clear my review queue, although it
of course started filling up again immediately after.
Demi's patch to automate the lists of files to include in images is
finally finished and committed, and her udev changes made progress, but
they've been blocked on further review from me, since with so much stuff
on I haven't had a chance since leaving XDC. She's also made a bit of
progress on system updates using systemd-sysupdate, about which we'll
hopefully have more to say soon.
Finally, we've been discussing for a couple of days now what to do about
a recently introduced build failure on x86_64. I'm already late getting
this update out, so I'm not going to go into detail, but basically it's
very unclear what the right way to build BPF programs that include
kernel UAPI headers is, or if there even is one. The common way of
using a distro's linux-headers/libc package is not correct, and likely
to lead to either loud compilation failures (as we're currently
experiencing) or silent hidden bugs[5]. If we can't find a good
solution, we can fall back to copying the definitions we need out of the
headers, but I'm hoping it won't come to that. Investigation continues.
This has also highlighted the need for pre-push testing on all supported
architectures — the reason this build failure got past me is that it
only happens on x86_64, and I was working on aarch64. I'll try to get
that addressed.
[5]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
Hopefully next week will be less busy, and I'll be able to get my head
down a bit and do some programming.
