| 9 Jun 2026 |
 Primrose (== Léana) | * ah ok I see /nix/store is hardcoded isn't it | 11:06:14 |
 maralorn | Well, I haven’t even thought about the tests. I guess they wouldn’t need changing. | 11:06:21 |
| Primrose (== Léana) | I agree, I was just confused about what you meant to fix earlier. | 11:06:49 |
| maralorn | Yes, exactly the storePrefix is hardcoded in the parser and for filesystem access. | 11:06:49 |
| maralorn | And it would kinda make the parser context dependent unless we don’t want "not a store path" to be a parse error. | 11:08:06 |
| maralorn | I think the first step to abstract that away would be not access the filesystem at all. Do everything via talking to nix and try to copy the parameters which determine the store from the wrapper call. | 11:09:29 |
| maralorn | The solution for the timing issue on lix is really so ugly that we really should improve the json output. | 11:10:23 |
 alexfmpe | The json output of nix/lix ? | 11:11:17 |
| maralorn | Yes | 11:11:25 |
| maralorn | Of lix primarily. Because nix doesn’t have the timing behavior that kills nom at the moment. | 11:12:18 |
| maralorn | Having it consistent between both plattforms would obviously be the dream. | 11:12:38 |
|  John Ericson joined the room. | 16:20:06 |
| John Ericson | maralorn: I have a patch where I try to make the exception types in nix more structured | 16:20:20 |
| John Ericson | I started it pre LLM but it will take a lot of LLM to force it through probably | 16:20:31 |
| John Ericson | but that would great the foundation to start making the JSON logging a lot less stupid | 16:20:42 |
| John Ericson | this is why the newer JSON formats do not include the store dir in store paths | 16:21:06 |
| John Ericson | keeps the parsing context free | 16:21:11 |
| John Ericson | and allows Aeson/Serde/whatever instances to work | 16:21:24 |
|  ryndubei joined the room. | 21:40:19 |
| 10 Jun 2026 |
 zoë (@blokyk) | still getting some unfinished finished builds D: | 08:43:00 |
| zoë (@blokyk) | 
Download image.png | 08:43:02 |
| zoë (@blokyk) | (i will say that it's happened a lot less and the improvements from this release are great anyway) | 08:43:40 |
| maralorn | That's lix? Does the nom process keep running for a while without this going away? | 09:05:48 |
| zoë (@blokyk) | yep, lix 2.95.3 (though the builder uses cppnix 2.34.4, if that's relevant) | 09:06:38 |
| maralorn | That's a FOD, right? I wonder if they behave differently... | 09:06:42 |
| zoë (@blokyk) | once the build is finished nom exits normally | 09:07:00 |
| maralorn | No, I mean had nom already exited when you took that screenshot and how long did nom run after the build had finished? | 09:10:17 |
| maralorn | But I guess at least 4 seconds. | 09:10:35 |
| maralorn | At this point I wonder whether this is a bug in the lix daemon. | 09:10:58 |
| zoë (@blokyk) | no nom was still running when i took the screenshot, and it kept displaying those as unfinished until the whole build finished | 09:12:01 |
