!LemuOOvbWqRXodtSsw:nixos.org

NixOS Reproducible Builds

544 Members
Report: https://reproducible.nixos.org Project progress: https://github.com/orgs/NixOS/projects/30124 Servers

Load older messages


SenderMessageTime
7 Oct 2021
@rick:matrix.ciphernetics.nlRick (Mindavi)Ran it (iso_minimal) a couple of days ago and it looked all good then :)20:53:58
@rick:matrix.ciphernetics.nlRick (Mindavi)
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@trofi:matrix.org The option is repeat =. Does it get a different handling when in nix.conf? 20:55:46
@qyliss:fairydust.spaceAlyssa Ross for nix.conf options usually you want to do e.g. --option repeat 1, don't you? 20:57:26
@trofi:matrix.org@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@trofi:matrix.org(and I would expect option handling error if flag was not recognised)20:59:10
@qyliss:fairydust.spaceAlyssa Ross> output '/nix/store/z9bwffzdzbm37c6gm1xjvg036v8n8kz2-flaky-foo-42' of '/nix/store/vsc0487zpr80fjxn6xj7wl7rcad5lsmd-flaky-foo-42.drv' differs from previous round20:59:21
@qyliss:fairydust.spaceAlyssa Rossnix-build (Nix) 2.3.1520:59:36
@trofi:matrix.org@trofi:matrix.org Thank you! Will try a rollback of nix (Nix) 2.4pre20211006_53e4794 locally. 21:09:20
@trofi:matrix.org@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@trofi:matrix.orgFiled https://github.com/NixOS/nix/issues/535221:17:34
8 Oct 2021
@j-k:matrix.orgj-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:matrix.orgtoonn j-k: I think that's 0 for Windows' version of the epoch. 13:57:40
@toonn:matrix.orgtoonn There was some Windows reason for this. Maybe to do with zip archives? 13:58:01
@j-k:matrix.orgj-kI saw an issue say it's the earliest some zip archive could take yeah13:58:12
@j-k:matrix.orgj-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:matrix.orgtoonn What's the reasoning behind setting it to latest commit? 14:05:48
@raboof:matrix.orgraboof 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:matrix.orgtoonn 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:matrix.orgtoonn 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:matrix.orgtoonn 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:matrix.orgraboof 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:matrix.orgraboof * 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:matrix.orgtoonn 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:matrix.orgraboofI'm not sure I understand what you mean in practical terms?14:17:47
@raboof:matrix.orgraboofSOURCE_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:matrix.orgraboof(oh j-k already linked that, sorry ;) )14:23:20
@j-k:matrix.orgj-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_:matrix.orgbaloo:( this morning r13y build did not include my fix :(16:06:41
@baloo_:matrix.orgbalooit's a couple hundred further in the history16:06:56

Show newer messages


Back to Room ListRoom Version: 6