| 18 Sep 2025 |
 aloisw | I can look into bumping (probably to 1.1.0?) this weekend. | 18:46:01 |
 emily | by next bump I mean, the next time the flake bumps | 18:47:41 |
| emily | although I guess the flake deps aren't used with the module. I dunno. I los track of all this | 18:47:53 |
| emily | * although I guess the flake deps aren't used with the module. I dunno. I lost track of all this | 18:47:56 |
| aloisw | Please do not worry, I should have subscribed to that PR. In any case due to the staging detour the delay should not cause negative effects. | 18:48:07 |
| emily | I'd pick 1.2.0: https://github.com/capnproto/capnproto/blob/v1.1.0/CMakeLists.txt | 18:48:27 |
| emily | (< 3.5 will not work with CMake 4) | 18:48:38 |
| aloisw | Why would "flake bump" matter there? Out of date dependencies are not so great. | 18:48:48 |
| emily | (you could backport more but why bother?) | 18:48:52 |
| emily | the path I imagined is Lix flake bumps Nixpkgs input → now Lix flake doesn't build. but perhaps more likely is Lix NixOS module → Lix package from the repo but with new Nixpkgs → Lix doesn't build? if that uses the custom packages too. | 18:49:27 |
| aloisw | Ah I see, that's why you asked. 1.2.0 should also not be a problem. (I only suggested 1.1.0 because that's the older supported version, so it is ensured that newer features aren't used accidentally.) | 18:50:26 |
|  daylin joined the room. | 21:16:20 |
| daylin changed their display name from daylin 💕 to daylin . | 21:16:50 |
| daylin set a profile picture. | 21:17:32 |
| emily | right | 21:34:10 |
| emily | (I stumbled into the old capnproto being an issue when I accidentally tried building from 2.93 with my Nixpkgs pinned to my CMake 4 work.) | 21:34:43 |
 Yureka (she/her) | Any opinions on baking a pasta binary into the Lix binary for static builds? Similar to the sandbox shell | 23:56:00 |
| 19 Sep 2025 |
 raitobezarius | I wonder how that meshes with pasta-path and what is the replacement here but it doesn't feel strange to me; is the use case completely self contained mono binary Lix? | 00:16:22 |
| aloisw | Maybe just disable the option then and make pasta unconditional? | 06:01:29 |
| Yureka (she/her) | Basically yes | 07:54:23 |
| Yureka (she/her) | Lix for remote building on a host where I am not privileged to create /nix/store/ | 07:54:57 |
| Yureka (she/her) | With the lix static bin/ added to path, and store = /home/.../store set in ~/.config/nix/nix.conf | 07:55:54 |
| Yureka (she/her) | I guess I can also set pasta_path = /path/to/pasta but it feels like a regression from the previous experience | 07:56:39 |
| raitobezarius | pasta unconditional seems a bit dangerous to me because of the bugs we saw | 09:45:10 |
| raitobezarius | sometimes not even under our control (e.g. kernel bug) | 09:45:16 |
| Yureka (she/her) | for the sandbox shell, isn't the option to embed it just on top of the ability to change it at run-time later? | 09:46:23 |
| raitobezarius | #if HAVE_EMBEDDED_SANDBOX_SHELL
if (i.second.source == "__embedded_sandbox_shell__") {
static unsigned char sh[] = {
#include "embedded-sandbox-shell.gen.hh"
};
auto dst = chrootRootDir + i.first;
createDirs(dirOf(dst));
writeFile(dst, std::string_view((const char *) sh, sizeof(sh)));
chmodPath(dst, 0555);
} else
#endif
bindPath(i.second.source, chrootRootDir + i.first, i.second.optional);
| 09:47:05 |
| raitobezarius | #if defined(__linux__) && defined(SANDBOX_SHELL)
sandboxPaths.setDefault(tokenizeString<StringSet>("/bin/sh=" SANDBOX_SHELL));
#endif
| 09:47:33 |
| raitobezarius | correct | 09:47:34 |
| raitobezarius | there's a runtime composition | 09:47:39 |
