| 11 Jul 2024 |
 charuto | is something like https://milkv.io/jupiter or similar SBCs not good candidates in terms of hardware? | 01:16:34 |
 artemist | That specific board has no mainline linux and only 8 cores of unknown but probably poor performance. The Milk-V pioneer is a bit closer (64 cores, more RAM supported), but mainline linux on it isn't usable yet. It's mATX which you can get rack cases for, but you're still DIYing with dev hardware | 02:43:55 |
| artemist | I suspect loongarch will be ready for servers before risc-v, but there are probably very few nixos users on it | 02:47:21 |
|  myrkskog joined the room. | 03:16:34 |
 dramforever | that makes sense, more of the riscv effort is focused on the embedded side just because there the customizablility matters more | 05:57:05 |
|  linj joined the room. | 13:32:44 |
 John Ericson | dramforever: I am very found for cross compilation because the work I've put in, of course :) | 15:46:08 |
| John Ericson | But I wanted to point out a nice thing that can be done is cross compiling the packages, and then running tests natively | 15:46:28 |
| John Ericson | to need fewer Risc-V builders (whether physical or an emulator) | 15:47:08 |
| John Ericson | Also, content-addressing derivations, which really need to get rolled out this year, should help make mixing native and cross builds less tedious | 15:47:43 |
 aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @Ericson2314:matrix.org
Also, content-addressing derivations, which really need to get rolled out this year, should help make mixing native and cross builds less tedious Content addressed is only blocked by one or two hydra problems now | 16:03:27 |
| John Ericson | yes | 16:04:01 |
| John Ericson | basically just me having too many things I worry about at once :) | 16:04:13 |
| John Ericson | the hydra problems aren't even that bad | 16:04:19 |
|  @pasukon:matrix.org removed their display name pasukon. | 16:06:41 |
| @pasukon:matrix.org left the room. | 16:06:51 |
| artemist | I thought there were still soundness issues with rewriting ca-derivations creating invalid nars, though maybe that was a while ago | 20:31:41 |
 trofi | It's probably not as bad as cross-compilation itself :) | 21:42:43 |
| trofi | https://github.com/NixOS/nixpkgs/pull/316334 is one of many examples how native and cross toolchains differ (and thus will likely not be able to share much as they do not produce identical outputs). | 21:45:00 |
| 12 Jul 2024 |
|  @valconius:matrix.org left the room. | 01:16:11 |
| dramforever | one thing i was hoping for was cross'd nixos tests | 06:11:24 |
| dramforever | it really didn't want to work last time i checked for some reason but given that it's just running qemu i "hope" it should just be fixing platform assumptions | 06:12:05 |
| John Ericson | dramforever: oh that's a good point, yes it should be made to work | 13:12:30 |
| John Ericson | artemist: Yeah if that still exists, it's not hard to fix, and I think it might not | 13:13:02 |
| John Ericson | trofi: I agree, but in the case of GCC I think that is an especially frustrating package in the current state :) hopefully others will be better | 13:13:57 |
| trofi | all separateDebugInfo = true; packages (like glibc) are also affected as they encode into binary a checksum of debug sections in .debug.link section, those almost always contain $out :) | 14:24:47 |
| trofi | And I think ./configure almost never generates identical config.h for cross vs native due to inability to test runtime features (like iconv() runtime bugs in gnulib) | 14:26:52 |
| trofi | It's a fun exercise to attempt identical binary output for cross-vs-native, but it's very hard even for x86_64-linux-on-x86_64-linux case :) | 14:27:51 |
 Mindavi | In reply to @trofi:matrix.org
all separateDebugInfo = true; packages (like glibc) are also affected as they encode into binary a checksum of debug sections in .debug.link section, those almost always contain $out :) Looked into that again yesterday but couldn't find a solution yet :( | 14:57:20 |
| trofi | There probably is no simple solution. -ggdb2 vs -ggdb3 are expected to produce different debug infos even if binaries are identical otherwise. I personally disable separateDebugInfo locally (and use --build-id=none while at it as it has identical problem for CA derivations). | 15:04:36 |
