 | NixOS Reproducible Builds | 545 Members |
| Report: https://reproducible.nixos.org Project progress: https://github.com/orgs/NixOS/projects/30 | 123 Servers |
| NixOS Reproducible Builds | 545 Members |
| Report: https://reproducible.nixos.org Project progress: https://github.com/orgs/NixOS/projects/30 | 123 Servers |
| Sender | Message | Time |
|---|---|---|
| 18 Aug 2021 | ||
 baloo | An error occurred (AccessDenied) when calling the CreateInvalidation operation: User: arn:aws:iam::223448837225:user/vault-token-r13y-publish-1629245456-7999 is not authorized to perform: cloudfront:CreateInvalidation on resource: arn:aws:cloudfront::223448837225:distribution/E2JKFLGW8FADQD | 03:58:14 |
| baloo | oh | 03:58:15 |
| baloo | https://buildkite.com/grahamc/r13y-dot-com/builds/855#54ff268f-62e5-4ec6-9f80-e8273655eeae/51-60 | 03:58:38 |
 siraben changed their display name from siraben to siraben (he/him). | 19:36:31 | |
| 19 Aug 2021 | ||
 nrdxp | I was trying to get a better understand on how nix manages the time for reproducible behavior, and it seems to me that time passes normally in a derivation sandbox and is then timestamped to the unix epoch after the build completes. However, I was wondering if there might be a mechanism to freeze the time during a build and I came across where foo.sh is: | 16:49:22 |
| nrdxp | Would this add any meaningful improvement to reproducible behavior? Seems like it should be simply enough to replicate this behavior if we wanted. | 16:50:14 |
| nrdxp | * Would this add any meaningful improvement to reproducible behavior? Seems like it should be simply enough to replicate if we wanted. | 16:52:20 |
| nrdxp | * Would this add any meaningful improvement to reproducible behavior (seems like it would, naively)? It should be simply enough to replicate if we wanted. | 16:54:38 |
 andi- | It would but it shouldn't. Packages should have a build system that doesn't care about specific times. There is already a somewhat standard env var to signal the time that should be used in e.g. binaries to display build time. | 16:59:14 |
| andi- | If we start changing the sandbox it is a quick win and it is nice to find impurities but really the builds need to be fixed. | 16:59:45 |
| nrdxp | Maybe we could use datefudge to help find impure builds then at least | 17:02:02 |
 chreekat | Y not both 🙂 | 17:02:11 |
| nrdxp | I agree with you andi-, but I also feel like trying to change the world is always an uphill and losing battle. So if upstream builders won't do anything maybe we should take the initiative? | 17:06:53 |
| andi- | Have we ever actually had an upstream that rejected non-nix specific reproducibility patches? | 17:14:18 |
| andi- | Given that Debian is leading this I don't see much of a battle | 17:14:33 |
| chreekat | I mean, there are approximately 20 hojillion software packages present and future that are yet to be made reproducible | 17:18:14 |
| andi- | Isn't it mostly about the build system anyway? | 17:29:47 |
| nrdxp | It's great to submit patches upstream, I certainly wouldn't argue against that. I just think it'd be nice behavior to have by default, since there will always be some build system somewhere that doesn't act the way we'd like. And even if we patched them all someday. Then a new one would come out shortly after and break everything again 😅 | 17:42:49 |
| nrdxp | * It's great to submit patches upstream, I certainly wouldn't argue against that. I just think it'd be nice behavior to have by default, since there will always be some build system somewhere that doesn't act the way we'd like. And even if we patched them all someday, Then a new one would come out shortly after and break everything again 😅 | 17:43:10 |
| nrdxp | * It's great to submit patches upstream, I certainly wouldn't argue against that. I just think it'd be nice behavior to have by default, since there will always be some build system somewhere that doesn't act the way we'd like. And even if we patched them all someday, then a new one would come out shortly after and break everything again 😅 | 17:43:21 |
| nrdxp | If I find some time, maybe I'll try to replicate the behavior in a small PR and see how it works | 17:44:22 |
| nrdxp | For the time being, we could probably automatically run datefudge -s against known non-reproducible derivations and see if it fixes any of them. Do we have a reproducible test suite? | 17:54:18 |
 tomberek | nrdxp: you can run ./check.sh from https://github.com/grahamc/r13y.com#how-can-i-run-this | 18:31:42 |
| tomberek | point it to a custom Nixpkgs with datefudge somewhere in mkDerivation and you can get a rough estimate of what is "fixed" by it | 18:32:31 |
| baloo | In reply to @andi:kack.itmost of them, or mis-use of build system, for which contributions are always welcomed in my experience. | 18:33:15 |
| nrdxp | well there is also just nix build --rebuild flag, I just didn't know if we were already doing this en masse somewhere | 18:33:31 |
| baloo | the r13y builders kind of do that. | 18:33:57 |
| baloo | they list the references of the iso_minimal recursively, and rebuilds each derivation and compare with what's made available on the mirrors/cache | 18:34:45 |
| baloo | https://github.com/grahamc/r13y.com/blob/master/src/eval/mod.rs | 18:35:39 |
| baloo | * they list the requisites of the iso_minimal recursively, and rebuilds each derivation and compare with what's made available on the mirrors/cache | 18:36:05 |