| 5 Mar 2026 |
Sergei Zimmerman (xokdvium) | worth -> with | 17:49:51 |
Sergei Zimmerman (xokdvium) | The mounts there are quite messed up probably | 17:50:58 |
Sergei Zimmerman (xokdvium) | I’m no Linux guru though and haven’t looked at that code too closely, so I’m not sure how to go about fixing it. I think there was a fixme about using overlayfs for the relocated store IIRC | 17:53:00 |
ysndr | Yea it’s user / mount namespace all the way.
At least root seems to not be mapper correctly (sudo is owned by nobody, as opposed to root) | 17:57:42 |
ysndr | * Yea it’s user / mount namespace all the way.
At least root seems to not be mapped correctly (sudo is owned by nobody, as opposed to root) | 17:57:47 |
Sergei Zimmerman (xokdvium) | Ah do we not set up a proper uid_map? | 18:07:34 |
| 6 Mar 2026 |
| gilligan (he/him) joined the room. | 01:45:50 |
| Azosion joined the room. | 03:32:29 |
dramforever | there's no way to do this without running nix shell with root permissions | 05:01:17 |
dramforever | see https://man7.org/linux/man-pages/man7/user_namespaces.7.html "In order for a process to write to the /proc/pid/uid_map", currently bullet 5, (b), bullet 1 | 05:02:16 |
dramforever | * see https://man7.org/linux/man-pages/man7/user_namespaces.7.html "In order for a process to write to the /proc/pid/uid_map ...", currently bullet 5, (b), bullet 1 | 05:02:25 |
dramforever | and we have to be in a new user namespace to create a mount namespace and start mounting stuff | 05:03:36 |
dramforever | * see https://man7.org/linux/man-pages/man7/user_namespaces.7.html "In order for a process to write to the /proc/pid/uid_map ...", currently bullet 5, (b), bullet 1
The data written to uid_map (gid_map) must consist of a single line that maps the writing process's effective user ID (group ID) in the parent user namespace to a user ID (group ID) in the user namespace.
| 05:04:37 |
dramforever | side note, don't you love it when all you need to understand is 1 and 2 and 3 and ( 4(a) or 4(b) ) and ( 5(a) or ( 5(b)1 and 5(b)2 and 5(b)3 ) ) | 05:06:11 |
dramforever | so just, to clarify, putting aside everything else, 5(b)1 says that if you don't have CAP_SETUID, then you can only map yourself in the parent userns to any uid in the child userns. everyone else in the parent userns becomes nobody in the child | 05:07:56 |
dramforever | * so just, to clarify, putting aside everything else, 5(b)1 says that if you don't have CAP_SETUID, then you can only map yourself in the parent userns to any uid in the child userns. everyone else in the parent userns becomes nobody in the child userns | 05:08:26 |
dramforever | * so just, to clarify, putting aside everything else, 5(b)1 says that if you don't have CAP_SETUID in the parent userns, then you can only map yourself in the parent userns to any uid in the child userns. everyone else in the parent userns becomes nobody in the child userns | 05:08:36 |
| RC Chuah joined the room. | 17:45:26 |
Azosion | Hey yall, via nix I installed "jasp-desktop", and it installed the binary "JASP" (in all caps), I'm pretty sure that most binaries are not capitialized, so is this a problem I could make a PR for, or is this normal for nix? (It is just a bit confusing that I cant just run the program with "jasp"). | 18:23:47 |
K900 | That's mostly up to upstream | 18:38:24 |
| Theuni changed their display name from Christian Theune to Theuni. | 19:57:47 |
| 7 Mar 2026 |
eveeifyeve | Did I hear someone say freebsd sandbox building? | 16:22:04 |
| 8 Mar 2026 |
| SomeoneSerge (matrix works sometimes) changed their display name from SomeoneSerge (back on matrix) to SomeoneSerge (matrix works sometimes). | 23:28:36 |
| 9 Mar 2026 |
| santg3ar changed their display name from gerasti to santg3ar. | 22:05:42 |
| 10 Mar 2026 |
fzakaria | Sharing this from Spack (spack.io) how they handle OpenGL or runtime type library dependencies:
If a binary is built in a CI/CD pipeline at /opt/spack/build/... and you download it to /home/user/super_long_project_name/spack/..., Spack needs to rewrite the RPATH in the ELF binary.
The Problem: You can safely shrink a string in a compiled binary, but if you try to replace a string with a longer one, you will overwrite adjacent memory and corrupt the executable.
The Solution: Spack uses a configuration called padded_length (often set to 128 characters or more). During the initial build, Spack intentionally pads the installation path with extra characters. This forces the compiler to generate massive, padded RPATH strings in the binary.
When you download the binary cache, Spack's relocation logic strips out the padding and inserts your local, shorter path. Because the original string was artificially inflated, Spack always has enough room to rewrite the path without breaking the binary.
| 00:18:29 |
fzakaria | tl;dr; Spack puts a 128 length padded entry in RPATH for the library (i.e. OpenGL).
At realisation, the ELF binary is modified to point to the live running library. | 00:19:15 |
dramforever | not reaaaly an option for nix | 02:24:10 |
dramforever | and for regular rpath rewriting while building, we've been patchelf-ing everything which handles making a new PT_DYNAMIC | 02:25:21 |
dramforever | so that's also not a problem | 02:25:25 |
dramforever | * so that's also "not" a problem | 02:25:35 |