| 1 Apr 2025 |
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 |
Robert Hensing (roberth) | The --load-db format has come up before. It is entirely forward-incompatible, so we may need to introduce any additions as a new format | 14:09:42 |
p14 | In reply to @roberthensing:matrix.org The --load-db format has come up before. It is entirely forward-incompatible, so we may need to introduce any additions as a new format Glancing at the load db there are signs the signature is there; is it just not being imported properly, I wonder 🤔 | 14:39:37 |
John Ericson | emily ElvishJerricco OK we discussed a bunch and we're liking the sort of compromise you all proposed | 20:30:03 |
John Ericson | 2.28 in 25.05 has Mic92's combo build (or something like it) | 20:30:27 |
John Ericson | 2.28 after 25.05 is componentized | 20:30:36 |
John Ericson | 2.29 in all branches has componentized (2.29 is very unimportant on 25.05 except for new version dogfooders) | 20:31:03 |
John Ericson | Also when we re-introduce nix git, we should use the componentized version for that | 20:32:23 |
John Ericson | how does that sound? | 20:32:27 |
John Ericson | I would like to merge Robert Hensing (roberth)'s open PR right away, for sake of the newer versions and git, and also because I like how it makes a package set for the dependencies, even with the monolithic package for Nix itself | 20:33:19 |
John Ericson | Also, since you two (and others) have such strong opinions about this, it would be great if you signed yourselves up as maintainers in Nixpkgs for this :D | 20:35:00 |
John Ericson | especially because, as ElvishJerricco mentioned, actually the mkMesonPackage stuff and whatnot really ought to not be Nix-specific, but reused for other things like (potentially) systemd | 20:35:32 |
emily | SGTM, especially if we can get a componentized-compatible overrides interface for patching/build flags/env.NIX_CFLAGS_COMPILE on the monolithic one | 20:40:43 |
emily | sorry, I definitely do not have the time and do not feel I understand the packaging well enough to :( | 20:41:03 |
John Ericson | I guessed I mixed up my metaphors here, what about just on the monolithic package? | 20:42:03 |
John Ericson | (poly package maintenance for systemd is an orthogonal question) | 20:43:04 |
emily | is the idea to keep the monolithic package around? I assumed that we'd want to switch to the componentized one early in 25.11 to shake out any issues well ahead of release | 20:56:43 |
John Ericson | emily: yes, yeah the idea is to get rid it early in the cycle | 20:59:57 |
John Ericson | so we are not in this some position come november | 21:00:02 |
fzakaria | I asked this on twitter but maybe here is a better place. On my MacOS Nix installation (2.26) I'm surprised in my flake project how often I hit:
unpacking 'github:NixOS/nixpkgs/b7ba7f9f45c5cd0d8625e9e217c28f8eb6a19a76' into the Git cache.
| 22:55:51 |
fzakaria | Is this a bug in Nix or something I'm missing. | 22:56:04 |
| 3 Apr 2025 |
John Ericson | * so we are not in this same position come november | 03:12:00 |
| NixOS Moderation Bot banned @cafkafk:fem.gg (<no reason supplied>). | 11:41:55 |
Mic92 | fzakaria: what do you mean by often? is this for the same commit? | 12:16:39 |
Mic92 | I can also recommend: nixpkgs.url = "git+https://github.com/Mic92/nixpkgs?shallow=1&ref=main"; | 12:17:10 |
| @2xsaiko:tchncs.de changed their display name from 2xsaiko to 2xsaiko (moved! @saiko:knifepoint.net). | 12:52:04 |
teto | does the shallow do anything ? I would suspect it's the default | 17:50:38 |