general high-level discussion about spectrum
 help / color / mirror / Atom feed
From: Alyssa Ross <hi@alyssa.is>
To: discuss@spectrum-os.org
Cc: Demi Marie Obenour <demiobenour@gmail.com>,
	Yureka Lilian <yureka@cyberchaos.dev>
Subject: This Week in Spectrum, 2025-W40
Date: Mon, 06 Oct 2025 15:06:24 +0200	[thread overview]
Message-ID: <87bjmkdvsf.fsf@alyssa.is> (raw)

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

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/thread/FLBBMJ2GTD4SCGTIMDAT6GQDXJMDFGVH/

Hopefully next week will be less busy, and I'll be able to get my head
down a bit and do some programming.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

                 reply	other threads:[~2025-10-06 13:06 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bjmkdvsf.fsf@alyssa.is \
    --to=hi@alyssa.is \
    --cc=demiobenour@gmail.com \
    --cc=discuss@spectrum-os.org \
    --cc=yureka@cyberchaos.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).