| 20 May 2026 |
 Mic92 | It looks mostly fine I did just want to read the double userns stuff again on a bigger screen | 14:56:46 |
 dramforever | Mic92: so i don't know how to do it with https://man7.org/linux/man-pages/man1/unshare.1.html, might try later, but what i did in #15539 shows that you can definitely give yourself binfmt_misc without privileges | 15:06:04 |
| dramforever | * Mic92: so i don't know how to do it with https://man7.org/linux/man-pages/man1/unshare.1.html, might try later, but what i did in #15539 shows that you can definitely give yourself a binfmt_misc without privileges | 15:06:11 |
| dramforever | as said in the pr description #15539 works even on rootless nix | 15:06:29 |
| dramforever | so if you're willing to do surgery on the bad perl stuff, i think you can get away with not touching nix at all | 15:07:08 |
| dramforever | * so if you're willing to do derivation surgery on the bad perl stuff, i think you can get away with not touching nix at all | 15:07:17 |
| dramforever | i'm thinking about the implications of a more literal "Allow write access to binfmt_misc when using Linux kernel >= 6.7", as in the title of that lxc issue, but currently i'm inclined to think we don't want that | 15:08:48 |
| dramforever | you might also want to know that there's no way to add binfmt_misc interpreters for a userns, only fully replace, so theoretically you can run into problems with an inner binfmt_misc on an binfmt_misc-emulated-cross build but at that point you're stretching everything too hard | 15:14:56 |
| dramforever | * you might also want to know that there's no way to add binfmt_misc interpreters for a userns, only fully replace, so theoretically you can run into problems with an inner binfmt_misc on an binfmt_misc-emulated-cross build but at that point you're stretching everything too hard (does qemu user even work for this? maybe there are less strech scenarios. idk.) | 15:15:21 |
| dramforever | okay i read the actual man page and you can do the double userns dance with
unshare --map-root-user --pid --fork --load-interp ":py:E::py::$(which python3):" unshare --map-user "$(id -u)" --map-group "$(id -g)" bash | 15:38:02 |
| dramforever | * okay i read the actual man page and you can do the double userns dance with something like
unshare --map-root-user --pid --fork --load-interp ":py:E::py::$(which python3):" unshare --map-user "$(id -u)" --map-group "$(id -g)" bash | 15:38:13 |
| dramforever | make of that what you will | 15:41:57 |
| 21 May 2026 |
|  rajudev joined the room. | 00:00:26 |
|  inifynastic joined the room. | 03:48:01 |
|  goatedxchef joined the room. | 19:38:00 |
| 22 May 2026 |
|  DJ2BD joined the room. | 13:02:40 |
|  Benedek joined the room. | 14:48:13 |
|  Jon Hermansen changed their display name from jonhermansen to Jon Hermansen. | 19:18:39 |
| 23 May 2026 |
 eveeifyeve | Has anyone considered a pr to flake registries to make them just an array of objects that contain owner repo and type? | 00:48:52 |
| eveeifyeve | * Has anyone considered a pr to flake registries to make them just an array of objects that contain owner, repo and type instead of what we have currently? | 00:49:13 |
| eveeifyeve | * Has anyone considered a pr to flake registries to make them just an array of objects that contain owner, repo and type instead of what we have currently, which IMO seems to deduplicate a lot of inputs? | 00:49:46 |
| eveeifyeve | * Has anyone considered a pr to flake registries to make them just an array of objects that contain owner, repo and type instead of what we have currently? Which IMO seems to deduplicate a lot of inputs that doesn't be needed? | 00:50:06 |
| eveeifyeve | * Has anyone considered a pr to flake registries to make them just an array of objects that contain owner, repo and type instead of what we have currently? Which IMO seems to deduplicate a lot of inputs that doesn't be needed. | 00:50:08 |
| eveeifyeve | * Has anyone considered a pr to flake registries to make them just an array of objects that contain owner, repo and type instead of what we have currently? Which IMO seems to deduplicate a lot of inputs that doesn't be needed like the to and from. | 00:51:27 |
| eveeifyeve | Like if there is no two and from, it should automatically assume that it is the to and from. | 00:53:47 |
|  Yingchi Long changed their profile picture. | 11:24:21 |
|  mtmn joined the room. | 15:21:13 |
| 26 May 2026 |
|  phanirithvij changed their display name from loudgolem to phanirithvij. | 11:40:47 |
|  Matt Sturgeon joined the room. | 16:33:14 |
| Matt Sturgeon | Sorry to cross-post, and if this is off-topic.
I'm just wondering if anyone here is able to answer my question re unsafeDiscardStringContext vs unsafeDiscardOutputDependency (and the unsafeDiscardReferences attr) in the "nix language" room?
I'm unclear on the differences, when one might choose one over the other, whether they avoid building the (un)referenced derivation, etc.
https://matrix.to/#/!tDnwWRNkmmYtMXfaZl:nixos.org/$7ed1ckmSXBR3mQyk0RXYkXZM40_Thyd_4pVtBq1S4aw?via=nixos.org&via=matrix.org&via=tchncs.de
| 17:01:30 |
