| 19 Aug 2021 |
 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.it
Isn't it mostly about the build system anyway? most 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 |
| tomberek | it's not well exposed and the HTML is wrong, but iso_gnome is also built (my latest build of that is here: https://tomberek.info/r13y.com/) | 18:37:04 |
| baloo | it fails to build because of lack of disk space | 18:37:57 |
| tomberek | i ran it on my own buildkite builder with more space, yay! It'd be good to fix graham's | 18:38:54 |
| baloo | (on r13y, otherwise it would be shown) | 18:39:00 |
| tomberek | old version here: https://r13y.com/iso_gnome/index.html | 18:39:20 |
| nrdxp | does r13y have any parameters to modify a derivation if it is not reproducible, to try and make it so? | 18:41:18 |
| baloo | it only builds from nixpkgs master afaik | 18:42:14 |
| baloo | but I usually can reproduce (haha) the non-reproducible builds on my desktop | 18:42:33 |
| tomberek | no. it just reports it | 18:42:38 |
| nrdxp | so I guess I would have to make something that takes this list, and then runs each build with datefudge to see if it helps any of them. If it fixes a substantial amount of them, then we will have more information on whether such an endeavor would be worth it. | 18:48:45 |
| nrdxp | oh but this only tracks the iso, which is already mostly reproducible 🤔 | 18:50:43 |
| 20 Aug 2021 |
| nrdxp | I still agree with andi that package builders should do a more excellent job of making sure time doesn't matter for the final result. However, I "feel" somehow that a world where time is immutable fits better into the world of pure nix 🤔 | 01:02:42 |
| baloo | for what it's worth, datefudge works as an ld preload, I don't expect all that much support in nix environment | 03:26:08 |
| baloo | moreover, I don't think that covers anything that does system call directly (golang for example). | 03:26:58 |
| baloo | can't we use the new time namespace for that or an ebpf based syscall hook? to just return 0. is that in the linux-vdso.so? | 03:31:31 |
| baloo | Those system calls will likewise not be visible to
seccomp(2) filters. | 03:35:29 |
| baloo | one could bump the auxiliary vector to pass an empty one. | 03:36:27 |
| baloo | :D | 03:36:31 |
| baloo | prctl(PR_SET_MM, PR_SET_MM_AUXV, ...) | 03:54:28 |
