 | Nix Hackers | 898 Members |
| For people hacking on the Nix package manager itself | 190 Servers |
| Nix Hackers | 898 Members |
| For people hacking on the Nix package manager itself | 190 Servers |
| Sender | Message | Time |
|---|---|---|
| 15 Mar 2025 | ||
 roberth | * That's sort of what I had in mind for (d), declare statically with an "advanced attr" that an output is a redirect (or may be a rewrite) and then the builder would write to $out or $outRewriteor something.echo $drv^out >$outRewrite | 15:50:49 |
 emily |
the output of a join drv would be the actual final output, right? so if the output is cached no additional roundtrips? I may be misunderstanding though, is this when a cache has | 16:20:06 |
| emily | my feeling is that having a zillion tiny derivations should be made to be fast/good anyway because the more fancy incremental stuff you do the more you'll want that anyway | 16:20:50 |
| emily | or do you mean when pushing outputs? | 16:29:41 |
| 16 Mar 2025 | ||
 jade_ | i currently do not have the brain space to fully think out how the dyndrv ideas work, but i will say that, as puck mentioned in lix dev a while ago, it could be the case in the future that we allow for input addressed drvs with different drv hashes to resolve to the same output hash for stuff like provenance metadata and other use cases like that where it does not affect the build itself, in the same way as fods currently allow. so having to generate the drvs from inside a dyndrv could be a trouble for the extension of the drv format? | 01:48:45 |
| roberth | you're considering this? https://github.com/NixOS/nix/issues/10780 | 10:29:28 |
| roberth | it's already the case that drv hashes aren't 1:1 with input addressed output hashes, due to modulo hashing and FODs that occur in the derivation closure | 10:29:37 |
 puck | basically, yeah. i think .drv files (and, to some degree, their format) are distinct from "derivations" in a way that makes sense to rethink what they are and look like, because .drv files' hashes aren't stable to begin with | 10:31:42 |
| roberth | I don't think generating drvs inside there has to be a problem, as presumably you could canonicalize them on the nix side? | 10:31:44 |
| roberth | yeah, the issue tries to be more incremental in terms of change, but yeah, we basically could have a pipeline like exprs -eval-> instantiations of any suitable format -canonicalize-> derivations -build-> outputs | 10:34:34 |
| roberth | or variations of that | 10:35:04 |
 Martin Charles joined the room. | 17:58:53 | |
 John Ericson | hexa: We would like to no more about the bug that caused the builders to go to Lix | 18:59:34 |
| John Ericson | that earlier github thread went of the rails, but the original idea of having some more information written down still stands | 19:00:02 |
| John Ericson | Thanks to infinisil (!) I got a link that works on the element electron app to the prior conversation in infra #infra:nixos.org, the link is: https://matrix.to/#/!RROtHmAaQIkiJzJZZE:nixos.org/$G9MBOn9CfSLkLiPqMhoN7KMnBEl6R4uRkLbFBm_KWBs?via=nixos.org&via=matrix.org&via=nixos.dev | 19:37:51 |
| John Ericson | rereading that, it does look like that no one really knows what the bug is, and other coredumps that e.g. might come from tests suites doing SIGABORT mean we do not have a good paper trail to figure out retroactively | 19:39:02 |
| John Ericson | Do you agree with that? | 19:39:06 |
 hexa | I can roll back to nix in a few days | 20:25:01 |
| hexa | I'm currently running with a workaround for nix not cleaning up build dirs in /tmp | 20:25:26 |
| hexa | that got fixed in lix recently by pennae | 20:25:32 |
| hexa | crucial since we build in a tmpfs | 20:25:40 |
| 17 Mar 2025 | ||
| jade_ | yeah, and currently debugging protocol bugs is absolutely maddening. lix nightly currently has a known protocol bug due to concurrency and nar transfers and remote builders and gestures the whole protocol being extremely easy to screw up. this is the idea we had for improving the experience of debugging protocol misbehaviour; implementation has not yet started: https://git.lix.systems/lix-project/lix/issues/734 | 00:12:20 |
| jade_ | * yeah, and currently debugging protocol bugs is absolutely maddening. lix nightly currently has a known protocol bug due to concurrency and nar transfers and remote builders and gestures the whole protocol being extremely easy to screw up and it is sorta reproducible (unusual for a protocol bug!). this is the idea we had for improving the experience of debugging protocol misbehaviour; implementation has not yet started: https://git.lix.systems/lix-project/lix/issues/734 | 00:12:58 |
| jade_ | (we do not know of other protocol bugs in lix, fwiw) | 00:14:58 |
| jade_ | https://gerrit.lix.systems/c/lix/+/2639 here's the CL that fixed it IIRC, but i think there might be a second somewhere | 00:16:46 |
| jade_ | https://gerrit.lix.systems/c/lix/+/2666 ah it would be this | 00:17:08 |
| John Ericson | hexa: (or jade_) can you point me to the tmp cleaning commit? | 00:17:28 |
| jade_ | see above | 00:17:33 |
| John Ericson | OK | 00:17:37 |
| John Ericson | I am ripping out building from scheduling finally right now | 00:17:50 |