| 26 May 2021 |
andi- | Simply not having any stdenv was so much fast :D | 10:38:31 |
andi- | In reply to @gytis-ivaskevicius:matrix.org How much value are we talking about? I think a guix style benefit would be nice but probably not realistic as they also execute guile within the build. | 10:39:16 |
Jonas Chevalier | that's another benefit of experimenting with scratchix | 10:39:58 |
Jonas Chevalier | it allows to play with ideas like that | 10:40:06 |
Gytis Ivaskevicius | In reply to @andi:kack.it I think a guix style benefit would be nice but probably not realistic as they also execute guile within the build. if i recall correctly they use the lispy shell which is basically unusable shell and more like proper lispy programming language | 10:40:33 |
andi- | Yeah, that is fine for build scripts | 10:41:03 |
toonn | Being able to reuse Guix work would be pretty cool though. | 10:41:14 |
andi- | Probably not practical as they have a nice integration from eval -> derivation where they can pass lipsy code, no? | 10:42:04 |
andi- | Instead we are stuck with our custom Nix interpreter that can't even be used outside of a store environment.. | 10:42:29 |
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 |