| 8 Oct 2021 |
 toonn | It's nice that changing history, by making changes that don't affect the build for example, doesn't change the build though. | 14:07:18 |
| toonn | Maybe a more precise formulation is, why is time of latest commit better than as close as we can get to the epoch? | 14:08:07 |
| toonn | The one thing I can think of is if upstream or debian or something publish hashes built with that specific SOURCE_DATE_EPOCH. | 14:09:20 |
 raboof | toonn: I guess it depends on what you're using SOURCE_DATE_EPOCH for. If you want it to be a somehow "meaningful" date, the latest commit seems better. If you just want to blank out some file timestamps, I agree it'd be better to just set them to something close to epoch - but arguably using SOURCE_DATE_EPOCH for that is a bit of a 'hack' | 14:12:49 |
| raboof | * toonn: I guess it depends on what you're using SOURCE_DATE_EPOCH for. If you want it to be a somehow "meaningful" date, the latest commit seems better. If you just want to blank out some file timestamps, I agree it'd be better to just set them to some 'zero value' - but arguably using SOURCE_DATE_EPOCH for that is a bit of a 'hack' | 14:14:26 |
| toonn | Isn't SOURCE_DATE_EPOCH a bit of a hack in the first place? I only mean if this is a proposed change to Nix/Nixpkgs then I'd expect a very good reason because it messes with reuse. | 14:16:52 |
| raboof | I'm not sure I understand what you mean in practical terms? | 14:17:47 |
| raboof | SOURCE_DATE_EPOCH is not a Nix-specific thing if that's what you mean, https://reproducible-builds.org/specs/source-date-epoch/ | 14:22:58 |
| raboof | (oh j-k already linked that, sorry ;) ) | 14:23:20 |
 j-k | I've not seen anyone propose SOURCE_DATE_EPOCH as a replacement for 1970-01-01-ing all files in nix.....
It's just that when developers want to expose a date in their version command there are a couple options: Leave it to some default like unknown, force it to the start of unix time, or use a reproducible date that's relevant to when the source code last changed which is where SOURCE_DATE_EPOCH came from
With a growing interest in reproducability projects such as ossf/scorecard are moving their scorecard version output from BuildDate: 2012-whatever-whatever to BuildDate: 1633648561
Since it's a reproducible date I don't see any reason to not fill it out beyond not being bothered
| 14:41:02 |
 baloo | :( this morning r13y build did not include my fix :( | 16:06:41 |
| baloo | it's a couple hundred further in the history | 16:06:56 |
| baloo | tomorrow I guess | 16:06:59 |
| baloo | tomberek: build says 1458 out of 1461 (99.79%) paths in the minimal installation image are reproducible! | 16:08:47 |
| baloo | that is pretty sweet! | 16:08:51 |
| baloo | unchecked paths: /nix/store/f7jd75zihwqnrqfnnf882d987a0zsxbb-aws-c-common-0.6.8.drv /nix/store/57lzdibq4xcp6857bkvwjddfhclwy5a4-libpcap-1.10.1.tar.gz.drv | 16:09:10 |
| baloo | huuum | 16:09:11 |
 tomberek | baloo: where did you get this result? | 18:08:52 |
| baloo | From your buildkite. Anyone can download the artifacts | 18:19:51 |
| baloo | (The report is in the artifacts of the iso_minimal build) | 18:20:23 |
| tomberek | baloo: I'm looking at my latest artifact and not seeing that result. (maybe you or I grabbed the wrong one?) | 18:24:14 |
| baloo | https://buildkite.com/tomberek/r13y/builds/22 | 18:26:37 |
| baloo | I grabbed the iso_minimal report artifact here | 18:26:47 |
| baloo | I think | 18:26:49 |
| baloo | meh | 18:27:02 |
| baloo | I mixed up my tar files | 18:27:13 |
| baloo | 1449 out of 1517 (95.52%) paths in the nixos.iso_minimal.x86_64-linux installation image are reproducible! | 18:28:24 |
| baloo | okay, same thing then | 18:28:31 |
| baloo | ho, for ea4524e6cc7761c3cc271233fa97b5e7473f760a | 18:28:39 |
| baloo | still a couple hundred commits behind :( | 18:28:47 |
