| 26 May 2021 |
 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 |
 Synthetica | "Grandpa, why do I still need to compile GCC versions 6 through 84" | 11:09:20 |
 toonn | Why make the chain longer? | 11:14:18 |
| toonn | It's only as trustworthy as the seed anyway so you might as well trim it down as much as possible at each step. | 11:14:44 |
| andi- | the point is you only want to show that the seed is trustworthy once | 11:15:27 |
| andi- | and then never again | 11:15:29 |
| andi- | I am thinking more towards that cross-distro bootstrap.. if we can pull that off it would be nice to have that attestation as part of the regular bootstrap. Build stdenv using debian, fedora, nixpkgs bootstrap and they must all match the same output otherwise the nixpkgs stdenv build fails. | 11:16:39 |
| toonn | Yeah, so you build the seed bootstrap. Next time you slap a new GCC on top of that. Next time you peel it away to slap an even newer GCC on top of it. Keep doing this until the bootstrap can't build a version, then and only then keep the bootstrap+previous-GCC, wash, rinse and repeat. | 11:16:55 |
| andi- | Not sure I follow. | 11:18:50 |
