| 1 Apr 2025 |
|  Hemant Baviskar set a profile picture. | 09:30:34 |
 p14 | I am trying to use nix-store —load-db with a closureInfo registration file. In the closure I put a fixed output deviation for nixpkgs itself: I am baking a machine image with nixpkgs available.
One problem though is I can’t easily get my hands on the nixpkgs path. I tried to use fetchClosure, but this doesn’t work on a machine whose nixpkgs path was registered using nix-store —load-db. So it fails when built using the machine image. ‘Nix path-info’ shows that the ca:fixed: metadata is missing, which results in fetchClosure saying that it is input addressed but inputAddressed = false.
Should the ca metadata be missing in this scenario? Is there a way to put it there? | 13:09:32 |
|  Sandro 🐧 changed their display name from Sandro 🐧 to Sandro 🐧 [c3d2]. | 13:58:06 |
| Sandro 🐧 changed their display name from Sandro 🐧 [c3d2] to Sandro 🐧. | 13:59:29 |
 toonn | I don't really follow the reasoning here, https://github.com/NixOS/nixpkgs/issues/393359#issuecomment-2767289529 The build system for Nix 2.24 is already packaged, no? So why would 25.05 sticking to that version of Nix mean having to maintain two build systems? GHC very intentionally did a gradual shift and the Make based build system hasn't been supported as of 9.6.1 from 2023-03-10 latest | 15:37:04 |
| toonn | release is 9.12.2, so that's long past. | 15:37:10 |
| 2 Apr 2025 |
| p14 | In reply to @p14:matrix.org
I am trying to use nix-store —load-db with a closureInfo registration file. In the closure I put a fixed output deviation for nixpkgs itself: I am baking a machine image with nixpkgs available.
One problem though is I can’t easily get my hands on the nixpkgs path. I tried to use fetchClosure, but this doesn’t work on a machine whose nixpkgs path was registered using nix-store —load-db. So it fails when built using the machine image. ‘Nix path-info’ shows that the ca:fixed: metadata is missing, which results in fetchClosure saying that it is input addressed but inputAddressed = false.
Should the ca metadata be missing in this scenario? Is there a way to put it there? Robert Hensing (roberth): I saw your reaction, was what I wrote clear enough, does this sound like an issue or misuse? | 12:46:19 |
 Martin Schwaighofer | Why do I see this difference between the builders of the same unresolved and resolved content-addressed derivation? 🤔
diff /nix/store/q2nzjyqf4w19w3mgbkn34k2as5hrvwh1-builder.sh /nix/store/ckzrg0f0bdyx8rf703nc61r3hz5yys9q-builder.sh
22c22
< printf '%s ' "${propagatedUserEnvPkgs[@]}" > $out/nix-support/propagated-user-env-packages
---
> printf '%s ' $propagatedUserEnvPkgs > $out/nix-support/propagated-user-env-packages
| 13:10:54 |
 Robert Hensing (roberth) | I haven't found time to look into this properly, whether this is a bug or a missing feature, or both. The main constraint for closureInfo etc, is that the info needs to be reproducible, so for example no signatures or other mutable store metadata. ca:fixed: seems like something that should be possible to include | 14:08:20 |
