| 15 Mar 2025 |
 Robert Hensing (roberth) | Only the Nix implementations need to get this right, which seems feasible | 15:31:25 |
 emily | how does outputOf currently get represented in the derivation? | 15:34:39 |
| Robert Hensing (roberth) | just in the inputs. We use a semistructured ATerm for the derivation references field, and iirc store-path-shaped placeholders in the other attributes | 15:38:54 |
| emily | if the separate derivation is considered a problem, perhaps "join the output" could be a field on the .drv itself? | 15:40:02 |
| emily | you would still need a cp derivation for the arbitrary case to reconstruct (c) though | 15:40:12 |
| Robert Hensing (roberth) | Not a fan of the Go types schema language, but otherwise it looks alright. Could be combined with JSON schema perhaps, via varlink's catch-all object | 15:42:50 |
| Robert Hensing (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:30 |
| Robert Hensing (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:41 |
| Robert Hensing (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 |
especially wrt binary cache roundtrips
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 .drvs but no outputs? is that common?
| 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 |
| Robert Hensing (roberth) | you're considering this? https://github.com/NixOS/nix/issues/10780
| 10:29:28 |
| Robert Hensing (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 |
| Robert Hensing (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 |
| Robert Hensing (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 |
| Robert Hensing (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 |
