| 14 Sep 2023 |
|  jlesquembre changed their display name from José Luis Lafuente to jlesquembre. | 10:36:46 |
|  0xMRTT [envs.net] changed their display name from 0xMRTT to 0xMRTT (Old). | 20:59:38 |
| 16 Sep 2023 |
|  Paul Meyer (katexochen) changed their display name from katexochen to Paul Meyer (katexochen). | 08:20:13 |
|  @ojg76:matrix.org left the room. | 13:43:34 |
| 17 Sep 2023 |
|  Hubble the Wolverine (they/them) joined the room. | 09:58:34 |
|  tq5rpg joined the room. | 12:27:48 |
| 0xMRTT [envs.net] changed their display name from 0xMRTT (Old) to 0xMRTT [envs.net]. | 16:58:53 |
| 20 Sep 2023 |
|  nbathum (he or they) changed their display name from nbathum (he or they) to nbathum. | 04:58:29 |
| nbathum (he or they) removed their profile picture. | 04:58:40 |
 raboof | In reply to @raboof:matrix.org
It's so sad the NAR format doesn't preserve timestamps, so SOURCE_DATE_EPOCH is usually meaningless (i.e. https://github.com/NixOS/nixpkgs/issues/112595). I wonder if it would make sense to introduce a convention where fetchers that can reliably determine the source date could store that somewhere - like in a /SOURCE_DATE_EPOCH file. set-source-date-epoch-to-latest.sh could then pick that up. Is that a crazy idea? https://github.com/NixOS/nixpkgs/pull/256270 | 07:55:39 |
 @trofi:matrix.org | I like when slightly different inputs provide identical outputs. It feels like injecting minor details like timepstamps goes in the opposite direction. But maybe it's just me.
And unrelated point: if you have multiple source inputs (can you?) you will probably need max() of all inputs.
| 10:18:00 |
| raboof | I also like it when slightly different inputs provide identical outputs - though in Nix because of the store paths we already rarely achieve that. if the application is embedding timestamps, though, I like them to be meaningful instead of that random 1970 date. | 10:24:12 |
 atemu12 | raboof: I think they meant that the blah-source path would be different depending on the date | 10:25:31 |
| 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 |
