 | Nix Package Manager development | 861 Members |
| For people hacking on Nix: https://github.com/NixOS/nix Nix maintainers can be reached here. | 185 Servers |
| Nix Package Manager development | 861 Members |
| For people hacking on Nix: https://github.com/NixOS/nix Nix maintainers can be reached here. | 185 Servers |
| Sender | Message | Time |
|---|---|---|
| 19 Oct 2025 | ||
 raboof | nix-store -q --graphml (of nix-store -q --tree) on a derivation shows what derivations it depends on, but not which specific outputs. That seems fairly easy to add (famous last words), should I? Or is there a better way to get this information anyway? | 13:10:27 |
| raboof | * nix-store -q --graphml (or nix-store -q --tree) on a derivation shows what derivations it depends on, but not which specific outputs. That seems fairly easy to add (famous last words), should I? Or is there a better way to get this information anyway? | 13:10:46 |
 @azahi:azahi.cc left the room. | 15:46:49 | |
| 20 Oct 2025 | ||
 fzakaria | is that --outputs or something | 03:03:28 |
| fzakaria | i can never remember all the query flags | 03:03:33 |
 Jean changed their profile picture. | 04:36:54 | |
 Martin Schwaighofer | In reply to @jfly:matrix.org I think if you're not looking at the paths or derivations the semantics of that would be the same. Maybe it would be a conceptual simplification. | 17:26:05 |
| Martin Schwaighofer | I really like the idea of having a more explicit resolution step, that all derivations go through, which could model this and the distinction between content- and input-addressed derivations. To me, this is is the way to make this stuff easier to understand in Nix. We would teach users about two dependency trees, an unresolved one, and a resolved one, and the resolution step to get from one to the other. The unresolved one is based on recursive hashes of inputs, like input-addressed paths, the resolved one is based on content hashes of inputs, like content-addressed paths. You can model both input-addressed derivations and content-addressed derivations uniformly this way, it's just that how you address things on disk is different, and which versions of the derivations have more abstract or explicit placeholders for which data. The unresolved tree would contain the unresolved input hash of the FOD, the resolved tree would contain the hard-coded content hash. Expanding on that view, and in practice, you would have to do resolution in two steps. First resolve all of the FODs to their hard-coded content hashes and base IA paths on that (equivalent to the hash-modulo thing), and then interactively resolve and build all of other derivations between the closest satisfied FODs and the build target. You could do ``` nix derivation show --{unresolved,fod-resolved,resolved} nixpkgs#hello ``` to understand and teach this. CA derivations have resolved versions already, but it's not surfaced that nicely to users yet. You can also drop input-addressing, or not change it, but still expose and teach it that way. | 17:28:10 |
| Martin Schwaighofer | I think the hash modulo thing is meant to prevent the path of C changing as well. | 17:36:46 |
| Martin Schwaighofer | * I really like the idea of having a more explicit resolution step, that all derivations go through, which could model this and the distinction between content- and input-addressed derivations. To me, this is is the way to make this stuff easier to understand in Nix. We would teach users about two dependency trees, an unresolved one, and a resolved one, and the resolution step to get from one to the other. The unresolved one is based on recursive hashes of inputs, like input-addressed paths, the resolved one is based on content hashes of inputs, like content-addressed paths. You can model both input-addressed derivations and content-addressed derivations uniformly this way, it's just that how you address things on disk is different, which versions of the derivations have more abstract or explicit placeholders for which data, and how strict they are with resolution. The unresolved tree would contain the unresolved input hash of the FOD, the resolved tree would contain the hard-coded content hash. Expanding on that view, and in practice, you would have to do resolution in two steps. First resolve all of the FODs to their hard-coded content hashes and base IA paths on that (equivalent to the hash-modulo thing), and then interactively resolve and build all of other derivations between the closest satisfied FODs and the build target. You could do ``` nix derivation show --{unresolved,fod-resolved,resolved} nixpkgs#hello ``` to understand and teach this. CA derivations have resolved versions already, but it's not surfaced that nicely to users yet. You can also drop input-addressing, or not change it, but still expose and teach it that way. | 17:40:30 |
 lovesegfault | Alright, there's a lot of room for bike shedding, but the RequiredSignatures in nix-cache-info idea is up: https://github.com/NixOS/nix/pull/14313 | 22:32:52 |
| 21 Oct 2025 | ||
| fzakaria | Sergei Zimmerman (xokdvium): that makes sense The confusing part is that the inputDrvs for non-FODs are not replaced with their output path but FODs are when caculating the out paths. The drv's path though is just the hash of the ATerm ?This has the side-effect of causing brand new drvs for the whole system tree since drvs are just the hash of their ATerm without substitution? | 00:02:43 |
| fzakaria | I was going to explore the Katai struct. Is nars.sh and nar-access.sh the only NAR tests? | 00:04:46 |
 Sergei Zimmerman (xokdvium) | In reply to @fzakaria:one.ems.hostSome invalid cases in libutil-tests/archive.cc also | 00:05:36 |
| fzakaria | should nix nar ls work on NAR that only have a single file ? | 04:28:31 |
| fzakaria | I started the kaitai spec here: https://github.com/fzakaria/nix-nar-kaitai-spec/tree/main tested directories and regular files so far. There is a test program that is mostly AI generated i need to fix | 05:08:27 |
| fzakaria | https://github.com/fzakaria/nix-nar-kaitai-spec/blob/main/NAR.ksy | 05:08:55 |
| raboof | no, --outputs will list all outputs of the derivation. --tree and --graph(ml) are basically recursive versions of --references which shows the inputs (but only shows 'derivation X depends on derivation Y', not 'derivation X depends on output Z of derivation Y') | 11:13:45 |
 Julian | Hey there, I am currently investigating nix assertion errors that consistently appear once in a while in our CI. Only MacOS machines are affected by this and the error persists until the nix store is garbage collected. It also only persists on the same user on the machine. This is the assertion that is violated though the check has since been moved in master. We currently run nix version 2.31.2. So essentially the two nix store paths differ due to existing and non-existing submodule directories, without their content and also somewhat their parent directory, see: Does anybody see what could be wrong here or where to look for bugs in nix? I will probably continue to debug this, but there's a lot going on in nix that I am not aware of yet. | 13:29:59 |
| Sergei Zimmerman (xokdvium) | Generally flake inputs with submodules should not be cached for this reason (the fetchToStore cache entry from the fingerprint -> store path). Maybe that’s the broken part? | 13:53:43 |
| Sergei Zimmerman (xokdvium) | does it end up in the cache with submodules enabled and disabled? | 13:56:32 |
| Sergei Zimmerman (xokdvium) | For the same git revision | 13:56:51 |
| Julian | Sergei Zimmerman (xokdvium): What specifically do you mean with submodules enabled/disabled? And which cache specifically? | 13:57:38 |
| Sergei Zimmerman (xokdvium) | The fetcher cache. | 13:58:44 |
| Julian | Sergei Zimmerman (xokdvium): Only the revision with no empty submodule directories is in the fetcher cache fetcher-cache-v4.sqlite. For the build to work, the store path should include empty submodule directories (or atleast for hashes to match). | 14:15:12 |
| Julian | So I guess there must be some code that puts invalid entries into the fetcher cache? And this specifically only happens when the repository contains submodules that are not fetched? | 14:16:40 |
| Sergei Zimmerman (xokdvium) | In reply to @juliankuners:matrix.orgWhen submodules are fetched it should not try to use the fetcher cache at all. That’s the issue I think. There’s some logic for it there, but it must have been broken somehow | 14:17:59 |
| Sergei Zimmerman (xokdvium) | (As in, it should not use the fetchToStore cache entry) | 14:18:27 |
| Sergei Zimmerman (xokdvium) | Because submodules are wonky and caching them correctly in a way that the narHash stays the same is hard | 14:19:20 |
| Sergei Zimmerman (xokdvium) | This must have surfaced because fetchToStore caching was broken for a while and only got fixed recently in https://github.com/NixOS/nix/pull/14050 | 14:20:54 |