| 4 Dec 2021 |
 wucke13 | * That would be lovely. Maybe I can convince one of the kernkonzept guys to help with it. However, the current build process is really not so nice for packaging in nix. They use one call to make to prepare a build directory (much like a configure script) and then another call make to configure everything (using menuconfig 🙄) and then a third call to make to build the kernel. The same story for the os. And then a final call to make to build the actual image for one particular configuration. | 17:33:58 |
 John Ericson | wucke13: You can just do it all in one big derivation, but yeah, sounds annoying | 17:45:54 |
 alexfmpe | you can just copy the previous output into a tmp folder and make that writable no? | 17:46:34 |
| John Ericson | I fine these projects that are conceptually mini distributions of multiple packages with some non-trivial bootstrapping tend to always do bad hand-rolled solution | 17:46:34 |
| wucke13 | I would much much like to decouple both for build times. Using parallel building on fairly nice 8 core machine I still need more than 3 minutes to compile kernel and os | 17:46:41 |
| alexfmpe | probably going to bloat the nix store a bit with all the intermediates | 17:46:45 |
| wucke13 | In reply to @alexfmpe:matrix.org
you can just copy the previous output into a tmp folder and make that writable no? How exactly would you make it writable? | 17:47:18 |
| John Ericson | Err you don't? | 17:47:25 |
| John Ericson | You just copy the stuff from the store into each derivation's temp scratch space and do more stuff there | 17:47:48 |
| wucke13 | The copied stuff, of course not the original residing in the nix store | 17:47:54 |
| John Ericson | oh just chmod it! | 17:48:07 |
| John Ericson | or cp --no-preserverve-thinnggy | 17:48:19 |
| wucke13 | should u+rw suffice? | 17:48:20 |
| John Ericson | (I forget exact name) | 17:48:31 |
| John Ericson | I would do +rw | 17:48:41 |
| John Ericson | there is only one user | 17:48:46 |
| John Ericson | in the sandbox | 17:49:00 |
| John Ericson | and perms are normalized "at rest" in the store | 17:49:14 |
| wucke13 | I will try and report back on the next problem :D | 17:49:15 |
| John Ericson | ok good luck! | 17:49:21 |
| wucke13 | Is there a nice way to configure a menuconfig build without running menuconfig, e.g. from nix? | 17:49:34 |
| alexfmpe | hmm but you're coyping the previous things from the nix store, does that have the same user as the one inside the sandbox? | 17:49:46 |
| wucke13 | In reply to @alexfmpe:matrix.org
hmm but you're coyping the previous things from the nix store, does that have the same user as the one inside the sandbox? Nope, things in the nix store are for example all readonly (and maybe executable), so just cp from the store does not work due to things being ro | 17:53:00 |
| 5 Dec 2021 |
 Mic92 | Seeing how easy binfmt is in practice, I am no longer too motivated to fix cross-compiling issues :) https://github.com/NixOS/patchelf/pull/349/files | 14:49:36 |
 sterni | alpine does use binfmt_misc for riscv64 support | 16:12:38 |
| sterni | but binfmt is so fucking slow you really only want to use it for testing stuff | 16:12:57 |
| sterni | I tried debugging aarch64 GHC with binfmt — agonizing | 16:13:24 |
|  abose joined the room. | 23:22:58 |
| 8 Dec 2021 |
 Pascal | I don't seem to understand how stdenv works. Is anyone able to enlighten me as to why
nix shell --impure -L --show-trace --expr 'let npf = import <unstable>; in (with npf { crossSystem = (npf {}).hostPlatform // { useLLVM = true; linker = "lld"; }; }; netcdf.override { stdenv = clang11Stdenv; })'
results in this error message:
error: attribute 'llvmPackages_7' missing
```?
| 16:46:58 |
| Pascal | ... Or is there any other/better way to compile something using clang/lld? (BTW, I get the same error message when using clangStdenv.) | 16:52:31 |
