[06:28:22] <moritzm>	 urandom: forcing a puppet run on the install servers should be all, if that's still an issue, let me know and I can have a closer look
[07:36:54] <Emperor>	 'docker pull --platform linux/386 debian/eol:squeeze' was not a thing I was expecting to read today. [context: https://graydon2.dreamwidth.org/317484.html on retro-boostrapping rust 14 years later]
[09:02:31] <vgutierrez>	 moritzm: by any chance do you know what mounts /sys/fs/bpf on bookworm?
[09:05:21] <moritzm>	 systemd does it, but I'd need to have a closer look by which mechanism
[09:05:38] <moritzm>	 either some tmpfiles snippet or maybe directly in udev?
[09:05:55] <vgutierrez>	 I've checked tmpfiles and I didn't see it
[09:05:57] <vgutierrez>	 let's see udev...
[09:06:56] <moritzm>	 I just found, but it fails to mention the exact mechanism as well: https://github.com/systemd/systemd/blob/main/NEWS#L12065 
[09:07:38] <vgutierrez>	 no mention to bpf on /usr/lib/udev/rules.d/ sigh
[09:08:45] <moritzm>	 oh, it's hardcoded directly in the codebase: https://github.com/systemd/systemd/blob/main/src/shared/mount-setup.c#L112
[09:09:01] <vgutierrez>	 my problem issue is that /sys/fs/bpf gets mounted with mode=700 and liberica runs with uid > 0 so it fails to pin eBPF programs/maps/links
[09:09:06] <vgutierrez>	 s/problem/current/
[09:09:22] <moritzm>	 it's probably dine that way so that other systemd infra can rely on it very early on
[09:09:53] <moritzm>	 hmmh, I see. the mode is even hard-coded there as well
[09:10:36] <vgutierrez>	 so I'm guessing that relaxing the mode doesn't seem like a great idea at least according to systemd developers :)
[09:13:47] <vgutierrez>	 the quick fix would be setting User=root on the service definition (this is the liberica-fp one) https://www.irccloud.com/pastebin/ffcbpzOY/
[09:13:55] <moritzm>	 or we could maybe have a second liberica-init which runs as root for the bpf setup and gets started with ExecStartPre?
[09:14:17] <moritzm>	 unless liberica also needs to make changes at run time
[09:14:46] <vgutierrez>	 liberica needs to be able to unpin the eBPF programs/maps/links if requested
[09:14:52] <moritzm>	 ok
[09:15:21] <vgutierrez>	 not a big deal considering we will just bump to root the systemd units handling eBPF code
[09:15:30] <vgutierrez>	 control plane itself will still run as non-root
[09:15:40] <moritzm>	 yeah, this seems fine
[17:12:55] <andrewbogott>	 mutante: ok for me to merge 'Revert "phabricator: comment out scap::target in migration class"' ?
[17:13:17] <mutante>	 andrewbogott: yes
[17:13:38] <andrewbogott>	 done
[17:13:41] <mutante>	 thanks
[23:43:51] <Krinkle>	 bblack: regarding m-dot sunsetting, I'm thinking about what prep we can do and the associated risks. One thing is fixing the missing Vary:X-Subdomain header in MobileFrontend.
[23:43:55] <Krinkle>	 context for others: https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsetting#Engineering_prep
[23:47:05] <Krinkle>	 What kinds of risks do you foresee / how careful should we introduce this? In theory, it's a no-op, if we assume m-dot URLs go from always lacking to always having it. There aren't variations today on the same URL (afaik).
[23:47:40] <Krinkle>	 That is, given no change to any public URls, no change to routing, can we "just" start emitting this from MobileFrontend-enabled MW backend responses?
[23:48:23] <Krinkle>	 We'd likely want to emit it from non-MF urls as well (i.e. desktop URLs) where the header is simply never set, but we can still advertise the fact that it varies.
[23:49:10] <Krinkle>	 that would prepare us for the next stage and tick this off. I'm looking for what kinds of tests, approval, or metrics to monitor.