| 6 Apr 2025 |
 emily | nix build /nix/store/foo.drv builds that drv, …^out builds that output | 13:25:52 |
| emily | there was a warning for it for many releases but it got removed | 13:25:58 |
| emily | the idea is that nix build X always produces X | 13:26:03 |
| emily | so nix build /nix/build/non-drv-store-path will try to substitute that path, e.g. | 13:26:16 |
 Las | Makes sense | 13:37:12 |
| Las | I think it’s a misnomer | 13:37:44 |
| Las | Should be nix realize | 13:37:49 |
 vcunat | FYI, some (cross-)builds got broken now on Hydra, e.g.
https://hydra.nixos.org/build/294450042/nixlog/1/tail | 14:59:18 |
| vcunat | I'm a bit surprised myself that -Wundef triggers on preprocessor this way. | 15:00:08 |
| vcunat | I suppose you'd simply do #ifdef __APPLE__ and #elif defined(__APPLE__). Most likely easier than fighting what compiler considers a warning. | 15:03:47 |
| vcunat | * I suppose you'd simply do #ifdef __APPLE__ and #elif defined(__APPLE__). Most likely it's easier than fighting what compiler considers a warning. | 15:04:00 |
| 7 Apr 2025 |
 SomeoneSerge (back on matrix) | In reply to @flokli:matrix.org
It's unfortunate derivations are added as aterm into the store in first place. IMHO they should only be valid for the lifetime of the evaluation itself, and not be put in the store RE: validity
Resolved drvs are ok though, aside from aterm? In the sense their contents are inherently consistent with path. Assuming nix doesn't change. | 06:37:08 |
 Mic92 | https://github.com/NixOS/nixpkgs/pull/396773 nixVersions.latest: 2.26 -> 2.28 | 11:30:47 |
| Mic92 | https://github.com/NixOS/nixpkgs/pull/396750 John Ericson nix-eval-jobs: 2.26.0 -> 2.28.0 | 12:14:46 |
 John Ericson | https://gist.github.com/Ericson2314/147281788b3b31cfbd4925dc49e3d59b | 15:15:00 |
| John Ericson | btw | 15:15:02 |
| John Ericson | for fixing headers downstream | 15:15:07 |
| John Ericson | tomberek: Mic92 was wondering about setting up the nix-community build bot for hydra for PRs | 15:34:43 |
| John Ericson | (hehe kinda ironic) | 15:34:49 |
| John Ericson | but this would require changing the nixos org settings | 15:34:55 |
| John Ericson | which I think you have the perms to do? | 15:35:03 |
| Mic92 | we first need to make the github app public in nix-community | 15:36:32 |
| 8 Apr 2025 |
|  @ser:sergevictor.eu joined the room. | 10:15:16 |
|  @yuri:peori.space left the room. | 11:23:13 |
| Las | What parts do I need to look at to fully understand the hash modulo stuff? | 12:09:34 |
 roberth | Definitely https://nix.dev/manual/nix/2.28/store/derivation/ and its sub-pages (see the menu, rendered as 4.4.*), as for code, maybe John Ericson has a hint? | 12:15:17 |
| Las |
But rather than somehow scanning all the other fields for inputs, Nix requires that all inputs be explicitly collected in the inputs field. It is instead the responsibility of the creator of a derivation (e.g. the evaluator) to ensure that every store object referenced in another field (e.g. referenced by store path) is included in this inputs field.
Isn't this not true Robert Hensing (roberth) ?
| 12:18:05 |
| Las | If I cat a .drv file it doesn't have explicit inputs | 12:18:27 |
| roberth | Yeah, the fields aren't named, but one of those , separated parts is specifically for declaring inputs using DerivingPaths | 12:19:24 |
| Las | Say I want to output a CA derivation, something like echo hello > /1rz4g4znpzjwh1xymhjpm42vipw92pr73vdgl6xs1hycac8kf2n9,
to be used in a downstream dynamic derivation.
I don't think this is possible if the placeholder path is also /1rz4g4znpzjwh1xymhjpm42vipw92pr73vdgl6xs1hycac8kf2n9 for the derivation
producing the derivation, which seems to be plausible since it seems to be determined by the output name only from testing? | 12:30:10 |
