| 10 Apr 2026 |
 raitobezarius | ah btw, if you have cgroups | 11:18:04 |
| raitobezarius | you can do nice things | 11:18:06 |
| raitobezarius | just list all the cgroups | 11:18:08 |
| raitobezarius | they contain the drvHash in their names | 11:18:12 |
| raitobezarius | by that, I mean: https://gerrit.lix.systems/c/lix/+/4773 | 11:19:12 |
 emily | right. that is nice but not sure I can assume it. (can builds make child cgroups? I guesS you need to check hierarchy if so?) | 11:20:49 |
| emily | * | 11:20:56 |
| emily | also can you actually query the daemon for a hash w/o drv name or do you need to walk the store? 🤔 | 11:21:28 |
| raitobezarius | build can make child cgroups | 11:36:49 |
| raitobezarius | you can probably directly query the sqlite database i think :D | 11:37:07 |
| raitobezarius | you can prevent that manually if you listen on cgroup appearances | 11:37:25 |
| raitobezarius | and write in subtree_control | 11:37:31 |
|  @ktrompfl:matrix.org joined the room. | 11:54:28 |
| emily | not sure that's better :D | 12:15:43 |
| emily | systemd stores env var style metadata about cgroups or such right? I guess the full drvPath could go in there? | 12:16:22 |
| raitobezarius | This doesn't ring a bell to me, what are you thinking of? | 12:16:45 |
| emily | I may be completely hallucinating a memory | 12:17:41 |
| raitobezarius | I think I know systemd stores things like INVOCATION_ID and so on, but I don't really know where they live, I think they're in the sd PID1 memory or something | 12:20:17 |
| raitobezarius | I know there's some desires to add xattrs to cgroups inodes to store more data, in relation with the Flatpak sandboxing work and real-time permission bestow/removal | 12:20:46 |
| raitobezarius | But the kernel feature is not even ready yet | 12:20:50 |
| emily | yeah I was thinking more attaching stuff to systemd scope units | 12:22:18 |
| raitobezarius | There might be something but my brain cannot come up with a hit on this sort of question | 12:23:15 |
| @ktrompfl:matrix.org | Hey, I'm not sure if this is the right place to ask, but I have a question about a rust package (https://github.com/Ktrompfl/jay/tree/nix-flake) which builds fine with CppNix 2.31.3 but fails to build with Lix 2.94.1 due to some failing tests.
These tests fail on creating an io_uring instance with os error 38, most likely due to the sandboxed build environment.
Is this intended and the package should just skip the respective tests or is this a problem with either CppNix or Lix? | 12:30:27 |
|  Sergei Zimmerman (xokdvium) joined the room. | 12:31:36 |
 K900 | Yes, intended | 12:32:44 |
| K900 | io_uring is banned in the sandbox | 12:32:49 |
| K900 | Because it's currently not practical to actually sandbox effectively | 12:32:56 |
| @ktrompfl:matrix.org | Ok, thank you! | 12:34:42 |
 sterni | does anyone have a guess what is going on here? https://buildkite.com/afnix/lix/builds/1124#019d767e-d754-4569-852c-51bfa85ce70c | 14:02:50 |
 Yureka (she/her) | I bisected it to the staging cycle which updated perl to 5.42 | 14:03:32 |
