| 26 May 2021 |
 Jonas Chevalier | When you write a nix template and then find out that some parameters need to be filled in at runtime | 10:43:12 |
| Jonas Chevalier | How many times I had to tack on some sed to fill the runtime info. Or some mix between bash at runtime and nix as eval time. | 10:44:14 |
 andi- | In a way the language that you use to describe the build environment must also drive it. | 10:45:28 |
| andi- | Or you always end up with the split we are having right now. | 10:45:38 |
| Jonas Chevalier | It reminds me of terraform that has two languages into one | 10:46:45 |
 toonn | Though you kinda always have to bridge to shell eventually. Because that's what most build tools expect. | 10:46:57 |
| andi- | Yes but usually you call a bash script and only care about the result. You never (or rarely?) consume the environment it created. You can just call another shell script from your clean shell env. Problem arises when you have to use the output of a previous phase. | 10:49:03 |
| andi- | Gytis Ivaskevicius: btw: the gccgo9 build did finish with this line:
cycle detected in the references of '/nix/store/37msxfm5cil2m4cvn06yb7miv68j9pk5-gccgo9-9.3.0-lib' from '/nix/store/xdyzifmvys1gna6fcbmvc6wahd5cy0vn-gccgo9-9.3.0'
| 10:50:15 |
| andi- | but otherwise looked good :D | 10:50:21 |
 Gytis Ivaskevicius | :D | 10:51:12 |
| Gytis Ivaskevicius | nice | 10:51:13 |
| andi- | So if you want to redo the Go bootstrap ping me for a review. I'd be very happy about it. | 10:52:16 |
| Gytis Ivaskevicius | Ill think about it. Currently i got quite a bit on my hands | 10:53:36 |
| andi- | Another exercise related to bootstrapping that I would love to do: build a bootstrap tarball on x86_64-linux with nixpkgs, then substitute our bootstrap tarball with the equivalent files from a debian/fedora/... and rebuild that bootstrap tarball. Ideally the results should be identialca. | 10:54:06 |
| andi- | * Another exercise related to bootstrapping that I would love to do: build a bootstrap tarball on x86_64-linux with nixpkgs, then substitute our bootstrap tarball with the equivalent files from a debian/fedora/... and rebuild that bootstrap tarball. Ideally the results should be identialcal | 10:54:09 |
| Gytis Ivaskevicius | Oh, actually thats pretty smart | 10:54:44 |
| andi- | If they are not we can see why and rule out those impurities. Once we can show that you can bootstrap nixpkgs from another distros sources (e.g. Guix MES bootstrapped toolchain) we have a bit more "trust" into those files. | 10:55:46 |
 Linux Hackerman | that's basically https://www.schneier.com/blog/archives/2006/01/countering_trus.html right? | 10:57:35 |
| andi- | perhaps a gentoo stage1 tarball would be a good starting point as those already exist | 10:57:39 |
| Gytis Ivaskevicius | well, currently its not going to be reproducible for sure | 11:00:07 |
| andi- | Well because our GCC isn't but otherwise? | 11:01:34 |
| andi- | Actually the slower GCC should be reproducible so not sure waht might be the issue | 11:02:44 |
| Gytis Ivaskevicius | Due to the issue that i sent earlier which is basically gcc/glibc and im not sure about all bin utils and stuff | 11:02:59 |
| Gytis Ivaskevicius | shell/utils might be screwed as well.Not sure tho | 11:03:46 |
| andi- | But once we can reproduce the tarballs (even cross distro?) it might be a good idea to do "one final" toolchain rotation, no? | 11:04:03 |
| andi- | So that we have a clean slate from which we can start. | 11:04:13 |
| Gytis Ivaskevicius | you basically mean extra stdenv stage? | 11:04:34 |
| Gytis Ivaskevicius | if so - boom https://github.com/NixOS/nixpkgs/issues/123467 | 11:05:05 |
| andi- | No, lets say we put in the effort to fix your said impurties and then go the extra mile to show that we can now reproduce the tarball based on a) the previousy nixpkgs see and b) another distros toolchain we could then do one "final" swap of the bootstrap seeds. That would let us start from a well defined bootstrap seed instead of the wild mixture it is now. | 11:05:51 |
| andi- | And from there on we only add newer compiler versions to the bootstrap (until in 20y we decide that the 30d bootstrap time is getting too long and cut the chain) | 11:06:25 |
