| 19 Dec 2023 |
 pouspous | I might not get the purpose of system.extraDependencies | 15:13:26 |
| pouspous | I understand this option as being a list of packages that must remain on the system, even if not necessarily referenced by anything in the store, right ? | 15:15:02 |
 fgaz | In reply to @pouspous:matrix.org
oh I didn't know that's a shame. so cross-compiling (say from x86_64 to riscv64) packages in system.extraDependencies will still trigger a recompilation of those packages when request on the riscv machine ? that's correct, and is the reason why I wrote that conditional | 15:20:48 |
| fgaz | In reply to @pouspous:matrix.org
I understand this option as being a list of packages that must remain on the system, even if not necessarily referenced by anything in the store, right ? yes, and I use it as sort of a lighter version of system.includeBuildDependencies | 15:21:36 |
| pouspous | So why do cross-compiled packages in system.extraDependencies need recompilation when requested on the native machine, but not packages in environment.systemPackages. Them too should have a different hash right ? | 15:50:57 |
| pouspous | * So why do cross-compiled packages in system.extraDependencies need recompilation when requested on the native machine, but not packages in environment.systemPackages ? Them too should have a different hash right ? | 15:51:18 |
| pouspous | * So why do cross-compiled packages in system.extraDependencies need recompilation when requested on the native machine, but not packages in environment.systemPackages ? Them too should have a different hash, right ? | 15:51:29 |
| fgaz | pouspous: both require recompilation. If you try to nixos-rebuild from a star64 that was flashed with a cross image, it will try to rebuild everything from the ground up | 15:57:37 |
| pouspous | oh ok it all makes sens now, thanks ! | 15:58:52 |
| pouspous | is same-hash cross-compilation something planned or possible, or am I just suggesting a total blasphemy ? | 15:59:44 |
| fgaz | you are not :) https://github.com/NixOS/rfcs/pull/62 | 16:02:04 |
| pouspous | neet ! | 16:02:46 |
| 23 Dec 2023 |
 zrsk | Hey folks!
I'm working with some RISC-V derivations and I'm a bit annoyed by the building speed (I'm using binfmt on a quite powerful x86_64 machine). I know that there is this cache (indeed I'm using it, with the same exact nixpkgs used to populate it) but still many derivations are not cached and at the same time I would like a more updated nixpkgs.
Isn't there a community builder, right? Also I tried looking for cloud providers that offer RISC-V without luck, maybe there is one instead?
I was also considering buying an SBC but they don't look so powerful (I checked the VisionFive2 and the Star64), I fear that I would get performances similar to my emulated RISC-V. | 18:11:18 |
 raitobezarius | There's no powerful RISC-V beyond the MilkV out there for now | 18:11:39 |
| raitobezarius | I would recommend waiting for one extra year probably | 18:11:45 |
| raitobezarius | Or 6 months | 18:11:48 |
| zrsk | Which model? Doesn't it use the JH7110 as the VIsion5? | 18:14:39 |
| raitobezarius | no milkv uses a Sophgo chip | 18:14:56 |
| zrsk | Anyway I need this sooner than 6 months unluckily (using binfmt is acceptable for my needs, just a bit painful) | 18:15:05 |
| raitobezarius | MilkV | 18:15:03 |
| raitobezarius | as for the model name | 18:15:07 |
| raitobezarius | Then you can buy the MilkV | 18:15:18 |
| raitobezarius | But you will have some real world troubles I would expect | 18:15:25 |
| raitobezarius | But if binfmt speed is acceptable, I suppose anything native is acceptable | 18:15:36 |
| zrsk | It's acceptable now that I found that cache ahah
Anyway I need this because I was trying to integrate Nix to a project where applications are executed as docker containers in a RISC-V deterministic VM. I'm not interested into running things on real RISC-V hardware because at the end they will not anyway, I just want to not get old in the meanwhile | 18:18:42 |
| raitobezarius | Is it RISC-0 stuff? | 18:19:09 |
| zrsk | I had no idea what RISC-0 was until now. It's a blockchain project that uses these virtual machines to run arbitrary ("arbitrary", they have to correctly build on RISC-V, not always easy) linux programs and interact with them from smart contracts (ethereum) | 18:31:11 |
| raitobezarius | Yeah I thought I was inferring that the RISC-V deterministic VM was the RISC-0 virtual machine | 18:31:49 |
| zrsk | Just out of curiosity: these RISC-0 VMs allow emulates multiple processors? I've no idea what this other project I'm working uses under the hood, I believe something custom. But I know it has the big limitation that the VM is single core. | 18:33:43 |
| zrsk | * Just out of curiosity: these RISC-0 VMs allow emulating multiple processors? I've no idea what this other project I'm working uses under the hood, I believe something custom. But I know it has the big limitation that the VM is single core. | 18:33:54 |
