#archlinux-ports | Logs for 2026-08-21

Back
[00:17:42] -!- drathir_tor has quit [Ping timeout: 252 seconds]
[00:19:44] -!- drathir_tor has joined #archlinux-ports
[02:28:21] -!- fermino has quit [Quit: ZNC - https://znc.in]
[03:31:25] -!- hcmb has quit [Ping timeout: 272 seconds]
[03:31:31] -!- hcmb_ has joined #archlinux-ports
[03:31:31] hcmb_ is now known as hcmb
[08:26:46] -!- SpieringsAE_sff has quit [Ping timeout: 252 seconds]
[09:54:31] -!- Revy has quit [Server closed connection]
[09:55:10] -!- SpieringsAE_sff has joined #archlinux-ports
[09:58:19] -!- SpieringsAE_sff has quit [Remote host closed the connection]
[09:58:41] -!- SpieringsAE_sff has joined #archlinux-ports
[10:37:39] -!- filmroellchen has joined #archlinux-ports
[10:39:31] -!- nl6720 has quit []
[10:45:46] -!- nl6720 has joined #archlinux-ports
[11:24:29] -!- cjc7373 has quit [Ping timeout: 245 seconds]
[11:25:36] -!- cjc7373 has joined #archlinux-ports
[11:51:32] -!- SpieringsAE_sff has quit [Ping timeout: 266 seconds]
[11:51:53] -!- SpieringsAE_sff has joined #archlinux-ports
[11:58:43] <gromit> bschnei: I'm currently running into issues when setting up a KinD cluster on the RPi 5 with ports: Aug 21 13:55:40 ports-rpi5 systemd[1]: docker-f9239eb6e0547ce76d57f05a094a59dac9f0da5852b2b5e758d81ba1cdf5a9ac.scope: Couldn't move process 10681 to requested cgroup '/system.slice/docker-f9239eb6e0547ce76d57f05a094a59dac9f0da5852b2b5e758d81ba1cdf5a9ac.scope/': Device or resource busy
[11:59:20] <gromit> If you wanna check, just install docker and kind from the repos and do a "kind create cluster"
[12:01:15] -!- cjc7373 has quit [Remote host closed the connection]
[12:03:18] <Antiz> gromit: Unrelated, but I can probably push a new pkgrel for kind to make it reproducible if that's of interest
[12:07:26] <gromit> Antiz: if its a trivial change you can just push it, for more complex stuff lets go with a MR
[12:07:34] <Antiz> gromit: Very trivial
[12:08:43] <Antiz> gromit: Might have eventual consequences on the debug package though.
[12:11:45] <Antiz> The fix is to strip debug symbols info.
[12:12:00] <Antiz> (Simply by adding "-s" to ldflags)
[12:12:25] <gromit> Huh, but thats not how we solve this for go packages in general right?
[12:13:41] <Antiz> Unfortunately it's mandatory for some go packages :/
[12:14:20] <gromit> Antiz: why is that? Do we have docs on that already?
[12:14:51] <Antiz> I think Fox had some WIP to make go debug symbols get along with reproducible builds, but right now we have some packages that must choose between debug symbols and reproducible builds unfortunately :/
[12:15:28] <Antiz> gromit: Checking if we have that documented somewhere
[12:23:15] <Antiz> I don't think it is documented somewhere unfortunately (or I cannot find it)
[12:25:17] <Antiz> I asked in #archlinux-reproducible if anyone knows if we have that documented somewhere
[12:26:03] <gromit> bschnei: it seems to work on the non-rpi5 kernel
[13:49:27] <Antiz> gromit: kp shared some insight about the problem.
[13:49:49] <Antiz> "the root cause would be code built from a temporary directory, with the full path embedded in debug symbols, there's some ID in the binary that is derived from a hash, which is going to vary due to this randomized temp path"
[13:50:51] <Antiz> So basically, something somewhere is using temporary directories in a way they probably shouldn't. Adding non-deterministic path data in debug symbols.
[13:51:14] <Antiz> Hence why stripping then (with -s and eventually -w) "fixes" it (at the cost of debug symbols / packages) of course.
[13:52:31] <Antiz> This needs more investigation, but so far the few packages that are affected by this kinda have to choose between debug symbols or reproducible builds (which is obviously not ideal). I won't push the change for "kind". I'll let you decide what you wanna do here. I'll eventually investigate the actual underlying cause later if possible though :)
[13:52:38] <Antiz> Would be nice to fix this once and for all :)
[13:55:57] <Antiz> (FWIW, Debian suffers from the issue. So it may not be Arch specific)
[14:18:32] <gromit> Antiz: This is probably a discussion for another channel at this point
[14:18:49] <gromit> Antiz: I think we should find a "proper" solution that uses a deterministic path instead
[14:19:07] <Antiz> Yup, just wanted to relay here as you're not in #archlinux-reproducible as far as I can tell
[14:19:21] <Antiz> And yeah I agree we should find a proper solution, I'll investigate that at some point if I'm able to
[14:19:29] * Antiz stops with the off-topic
[14:34:11] -!- rtp has quit [Server closed connection]
[14:34:21] -!- rtp has joined #archlinux-ports
[14:44:11] -!- d4s has quit [Remote host closed the connection]
[14:44:34] -!- d4s has joined #archlinux-ports
[15:23:19] -!- cjc7373 has joined #archlinux-ports
[15:25:36] -!- Humanfish451 has quit [Server closed connection]
[15:25:45] -!- Humanfish451 has joined #archlinux-ports
[15:37:01] -!- SpieringsAE_sff has quit [Remote host closed the connection]
[15:37:23] -!- SpieringsAE_sff has joined #archlinux-ports
[16:07:46] <bschnei> gromit: hmm I'm guessing this is a kernel config issue then. Any idea where I should look before I go ask AI? kernel config can be a real needle-in-haystack thing...
[16:10:16] <bschnei> we probably want to create an issue here: https://github.com so it doesn't get buried on IRC...
[16:10:17] <phrik> Title: Issues · bschnei/linux-rpi5 · GitHub (at github.com)
[16:16:51] -!- cjc7373 has quit [Remote host closed the connection]
[16:18:32] -!- cjc7373 has joined #archlinux-ports
[16:20:01] -!- cjc7373 has quit [Remote host closed the connection]
[16:20:49] -!- SpieringsAE has joined #archlinux-ports
[16:21:28] -!- cjc7373 has joined #archlinux-ports
[16:30:35] -!- SpieringsAE has quit [Quit: SpieringsAE]
[17:15:15] <bschnei> actually we package a very lightly modified vendor kernel for pi5. i did a quick search of issues upstream but didn't see anything. but it may be the right place for such an issue to be discussed: https://github.com
[17:15:16] <phrik> Title: Issues · raspberrypi/linux · GitHub (at github.com)
[17:17:15] <bschnei> https://github.com might be relevant
[17:17:16] <phrik> Title: memory cgroups cannot be enabled with recent kernel version · Issue #6980 · raspberrypi/linux · GitHub (at github.com)
[17:23:45] <bschnei> gromit: you might want to try if what is noted here corrects the issue. it seems they want to leave memory groups disabled in kernel config and expect users to change in in their cmdline.txt file: https://github.com
[17:23:46] <phrik> Title: Consider enabling memory cgroup by default in 64-bit Lite builds (for Docker users) · Issue #917 · RPi-Distro/pi-gen · GitHub (at github.com)
[17:44:48] -!- Atsutane has joined #archlinux-ports
[18:26:01] -!- Solskogen has quit [Server closed connection]
[18:29:14] -!- SpieringsAE_sff has quit [Remote host closed the connection]
[18:29:23] -!- SpieringsAE_sff has joined #archlinux-ports
[18:45:45] -!- SpieringsAE_sff has quit [Ping timeout: 267 seconds]