NixOS Reproducible Builds | 544 Members | |
| Report: https://reproducible.nixos.org Project progress: https://github.com/orgs/NixOS/projects/30 | 124 Servers |
| Sender | Message | Time |
|---|---|---|
| 7 Oct 2021 | ||
| Ran it (iso_minimal) a couple of days ago and it looked all good then :) | 20:53:58 | |
In reply to @trofi:matrix.orgI think there are nix config options for that | 20:54:27 | |
The option is repeat =. Does it get a different handling when in nix.conf? | 20:55:46 | |
for nix.conf options usually you want to do e.g. --option repeat 1, don't you? | 20:57:26 | |
Does it work for you? nix-build -E 'with import <nixpkgs> {}; builtins.derivation { name = "flaky-foo-42"; builder = "${bash}/bin/bash"; args = [ "-c" "${coreutils}/bin/date +%N > $out" ]; system = builtins.currentSystem; }' --option repeat 10 Does not fail here. | 20:58:45 | |
| (and I would expect option handling error if flag was not recognised) | 20:59:10 | |
| > output '/nix/store/z9bwffzdzbm37c6gm1xjvg036v8n8kz2-flaky-foo-42' of '/nix/store/vsc0487zpr80fjxn6xj7wl7rcad5lsmd-flaky-foo-42.drv' differs from previous round | 20:59:21 | |
| nix-build (Nix) 2.3.15 | 20:59:36 | |
Thank you! Will try a rollback of nix (Nix) 2.4pre20211006_53e4794 locally. | 21:09:20 | |
Heh, warning: ignoring the user-specified setting 'repeat', because it is a restricted setting and you are not a trusted user. | 21:12:59 | |
| Filed https://github.com/NixOS/nix/issues/5352 | 21:17:34 | |
| 8 Oct 2021 | ||
The SOURCE_DATE_EPOCH env var is just falling back to 315532800. Does it not get set properly when using fetchFromGithub? | 11:23:27 | |
| j-k: I think that's 0 for Windows' version of the epoch. | 13:57:40 | |
| There was some Windows reason for this. Maybe to do with zip archives? | 13:58:01 | |
| I saw an issue say it's the earliest some zip archive could take yeah | 13:58:12 | |
| I was just wondering if there's a good way to actually get an accurate 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 | 14:00:57 | |
| What's the reasoning behind setting it to latest commit? | 14:05:48 | |
| 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 | |
| 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 | |
| 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 | |
| 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 | |
| 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 | |
| * 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 | |
| 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 | |
| I'm not sure I understand what you mean in practical terms? | 14:17:47 | |
| 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 | |
| (oh j-k already linked that, sorry ;) ) | 14:23:20 | |
| I've not seen anyone propose 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 With a growing interest in reproducability projects such as ossf/scorecard are moving their | 14:41:02 | |
| :( this morning r13y build did not include my fix :( | 16:06:41 | |
| it's a couple hundred further in the history | 16:06:56 | |