| 20 Sep 2023 |
 atemu12 | Usually, you can fetch sources from all kinds of places (or even just copy it from local) and produce the same nix store path | 10:25:59 |
| atemu12 | (When the content matches obv.) | 10:26:18 |
 @trofi:matrix.org | I usually strip out timestamps entirely (or stub out with 9999-01-01). But I can see when sometimes it's not desirable or infeasible. | 10:29:19 |
| atemu12 | raboof: Did you try my idea of the separate output? | 10:33:01 |
 raboof | I couldn't figure out a sensible way to read that out again | 10:34:35 |
| atemu12 | raboof: Just did a quick PoC aaaand error: multiple outputs are not supported in fixed-output derivations | 10:41:19 |
| atemu12 | How did you get far enough to worry about reading them? | 10:41:33 |
| raboof | I started with the part that seemed most problematic to me (thinking of ways how to consume the data, assuming it was there) | 10:42:15 |
| atemu12 | I see | 10:42:34 |
| atemu12 | A thing that occured to me, what are we actually trying to fix by doing tht? | 10:42:49 |
| atemu12 | * A thing that occured to me, what are we actually trying to fix by doing that? | 10:42:52 |
| raboof | by restricting multiple outputs in FODs? | 10:43:22 |
| atemu12 | No, getting the date from the tarball | 10:43:33 |
| atemu12 | Because in order to achieve reproducibility, we only need to set SOURCE_DATE_EPOCH=1 | 10:44:09 |
| raboof | ah - well, the meaning of SOURCE_DATE_EPOCH is the date of the last modification of (typically) the source code, which applications then can use for thing like showing "Welcome to Foo version X, 2023-09-20". Indeed setting it to 1 is just as reproducible, but less user-friendly (showing weird 1970 dates instead of 'meaningful' ones) and arguably somewhat abusing the concept. | 10:48:19 |
| atemu12 | Ah, so the point of this is a cosmetic improvement but retaining existing r13y | 10:50:20 |
| raboof | yes | 10:50:42 |
| atemu12 | I think in that case the better approach might really be just adding a mkDerivation arg with the epoch for those few% of packages where it'd matter | 10:50:57 |
| atemu12 | I like the idea of having the actual timestamp globally but breaking Nixpkgs' -source path convention is quite a steep hill and will probably even net you a veto from out BDFL ;) | 10:52:27 |
| atemu12 | * I like the idea of having the actual timestamp globally but breaking Nixpkgs' -source path convention is quite a steep hill and will probably even net you a veto from our BDFL ;) | 10:52:31 |
| raboof | how is this breaking nixpkgs' -source patch convention? | 10:53:09 |
| raboof | * how is this breaking nixpkgs' -source path convention? | 10:53:19 |
| atemu12 | As trofi mentioned, it breaks the ability to construct the same source path from any source as long as it's the same content | 10:53:46 |
| atemu12 | Because in addition to the content you must have a matching epoch | 10:53:59 |
| raboof | I see your point - 'same' is a tricky concept 😃. The widespread abuse of SOURCE_DATE_EPOCH in nixpkgs (setting it to a meaningless constant) irks me though, and "that's just the way it is in Nix" is not a very satisfying answer if we want to claim to be forerunners in reproducibility ;) | 11:00:55 |
| raboof | * I see your point - 'same' is a tricky concept 😃. The widespread abuse of SOURCE_DATE_EPOCH in nixpkgs (setting it to a meaningless constant) irks me though, and "that's just the way it is in nixpkgs" is not a very satisfying answer if we want to claim to be forerunners in reproducibility ;) | 11:01:18 |
| raboof | * I see your point - 'same' is a tricky concept 😃. The widespread abuse of SOURCE_DATE_EPOCH in nixpkgs (setting it to a meaningless constant, technically achieving reproducibility at the cost of correctness/accuracy) irks me though, and "that's just the way it is in nixpkgs" is not a very satisfying answer if we want to claim to be forerunners in reproducibility ;) | 11:01:56 |
| atemu12 | raboof: I agree with you on that | 11:03:01 |
| atemu12 | It's just very difficult to do it differently on the technical side of things | 11:03:23 |
| atemu12 | Without losing other technical properties | 11:03:34 |
