| 7 Oct 2021 |
 @rick:matrix.ciphernetics.nl | Saw that the gnome_iso wasn't updated for a while either | 19:46:47 |
 baloo | Yeah but this is a different issue | 20:47:26 |
| baloo | The builders are running out of disk space | 20:47:41 |
 tomberek | I'll run mine: https://buildkite.com/tomberek/r13y/builds/22 | 20:47:59 |
 @trofi:matrix.org | is there an easy way to make all local builds to check for reproducibility? (I'd like to check every package my system uses). I tried specifying --repeat 1 and did not notice any effect. Example command:
$ nix-build -E 'with import <nixpkgs> {}; builtins.derivation { name = "flaky-foo"; builder = "${bash}/bin/bash"; args = [ "-c" "${coreutils}/bin/date +%N > $out" ]; system = builtins.currentSystem; }' --repeat 10
| 20:52:46 |
| @rick:matrix.ciphernetics.nl | Ran it (iso_minimal) a couple of days ago and it looked all good then :) | 20:53:58 |
| @rick:matrix.ciphernetics.nl | In reply to @trofi:matrix.org
is there an easy way to make all local builds to check for reproducibility? (I'd like to check every package my system uses). I tried specifying --repeat 1 and did not notice any effect. Example command:
$ nix-build -E 'with import <nixpkgs> {}; builtins.derivation { name = "flaky-foo"; builder = "${bash}/bin/bash"; args = [ "-c" "${coreutils}/bin/date +%N > $out" ]; system = builtins.currentSystem; }' --repeat 10
I think there are nix config options for that | 20:54:27 |
| @trofi:matrix.org | The option is repeat =. Does it get a different handling when in nix.conf? | 20:55:46 |
 Alyssa Ross | for nix.conf options usually you want to do e.g. --option repeat 1, don't you? | 20:57:26 |
| @trofi:matrix.org | 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 |
| @trofi:matrix.org | (and I would expect option handling error if flag was not recognised) | 20:59:10 |
| Alyssa Ross | > output '/nix/store/z9bwffzdzbm37c6gm1xjvg036v8n8kz2-flaky-foo-42' of '/nix/store/vsc0487zpr80fjxn6xj7wl7rcad5lsmd-flaky-foo-42.drv' differs from previous round | 20:59:21 |
| 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 |
