| 7 Oct 2021 |
 Alyssa Ross | nix-build (Nix) 2.3.15 | 20:59:36 |
 @trofi:matrix.org | Thank you! Will try a rollback of nix (Nix) 2.4pre20211006_53e4794 locally. | 21:09:20 |
| @trofi:matrix.org | Heh, warning: ignoring the user-specified setting 'repeat', because it is a restricted setting and you are not a trusted user. | 21:12:59 |
| @trofi:matrix.org | Filed https://github.com/NixOS/nix/issues/5352 | 21:17:34 |
| 8 Oct 2021 |
 j-k | The SOURCE_DATE_EPOCH env var is just falling back to 315532800. Does it not get set properly when using fetchFromGithub? | 11:23:27 |
 toonn | j-k: I think that's 0 for Windows' version of the epoch. | 13:57:40 |
| toonn | There was some Windows reason for this. Maybe to do with zip archives? | 13:58:01 |
| j-k | I saw an issue say it's the earliest some zip archive could take yeah | 13:58:12 |
| j-k | I was just wondering if there's a good way to actually get an accurate SOURCE_DATE_EPOCH?
I've seen chroma uses leaveDotGit and grabs details and then deletes it to avoid issues: https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/tools/text/chroma/default.nix#L17-L29
e.g. for SOURCE_DATE_EPOCH I'd swap the git command to $(git log -1 --pretty=%ct) etc https://reproducible-builds.org/docs/source-date-epoch/
| 14:00:57 |
| toonn | What's the reasoning behind setting it to latest commit? | 14:05:48 |
 raboof | toonn: IIRC git doesn't really keep file timestamps, so the 'latest commit timestamp' seems like a reasonable approximation of 'the date of this version of the sources'? | 14:06:56 |
| 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 |
