| 3 Apr 2024 |
[0x4A6F] | Who is also up for nix riscv64 maintainership? | 06:44:44 |
[0x4A6F] | * Who is also up for nix riscv64 maintainership (thumbs up it then 👍️)? | 06:45:48 |
fgaz | I moved the pad to https://wiki.nixos.org/wiki/RISC-V. I only moved the links for now. Who is the copyright owner of the GHC stuff at the end? Could you add it to the wiki? | 06:57:03 |
fgaz | In reply to @0x4a6f:matrix.org
Oh you already noticed! | 06:58:32 |
[0x4A6F] | Yeah, did some rework on the wiki, glancing at the NixOS_on_Arm page :) | 07:02:38 |
[0x4A6F] | * Yeah, did some rework on the wiki, while glancing at the NixOS_on_Arm page. :) | 07:02:50 |
[0x4A6F] | We might organize through subpages, that is a cool feature of MediaWiki. | 07:11:14 |
Alex | In reply to @fgaz:matrix.org I moved the pad to https://wiki.nixos.org/wiki/RISC-V. I only moved the links for now. Who is the copyright owner of the GHC stuff at the end? Could you add it to the wiki? Sure. Would it belong best on a separate page, given that it's quite long? | 07:51:25 |
fgaz | In reply to @alex:tunstall.xyz Sure. Would it belong best on a separate page, given that it's quite long? Since [0x4A6F] added a GHC redlink I assume that's the intention | 07:53:03 |
Alex | In reply to @fgaz:matrix.org Since [0x4A6F] added a GHC redlink I assume that's the intention Ah it wasn't showing up as as red link because I wasn't signed in apparently. | 08:05:07 |
[0x4A6F] | And it wasn't saved because of that calc-captcha... | 16:16:40 |
[0x4A6F] | * And it wasn't saved because of that calc-captcha... -> https://wiki.nixos.org/wiki/RISC-V/GHC | 16:17:09 |
[0x4A6F] | Thanks Alex for that writeup and your work on cross bootstraping GHC. ❤️ | 16:17:31 |
Alex | In reply to @0x4a6f:matrix.org And it wasn't saved because of that calc-captcha... -> https://wiki.nixos.org/wiki/RISC-V/GHC Pain. I was going to copy it over to the wiki anyway. I guess I might touch it up a bit to make it more flake-friendly. | 16:43:31 |
Alex | In reply to @0x4a6f:matrix.org Thanks Alex for that writeup and your work on cross bootstraping GHC. ❤️ I still need to figure out what's causing the registerised segfaults, so it's not done yet. | 16:44:39 |
Alex | The rustc build is segfaulting on native builds too 🙃
Seems to be https://github.com/rust-lang/rust/issues/117022
Now beginning to wonder if all the GHC segfaults aren't also kernel-related... | 18:02:35 |
Alex |
- rustc segfaults due to the 6.5 kernel(?).
- uboot-tools is needed to build the 6.8 kernel.
- python3-cryptography is needed to build uboot-tools.
- rustc is needed to build python3-cryptography.
I'm glad I've never GCed on this system, because I might need to run an older kernel to upgrade the kernel... | 19:50:19 |
tau | https://github.com/NixOS/nixpkgs/issues/301340 | 20:01:35 |
tau | do you think all of the segfault errors on my builds are related to this kernel as well ? | 20:02:02 |
Alex | In reply to @hive:the-apothecary.club do you think all of the segfault errors on my builds are related to this kernel as well ? I doubt it, because QEMU uses the host system's kernel. | 20:02:25 |
tau | ah ok | 20:02:35 |
Alex | I guess you could try using a different version if you're on 6.5 though?
It just might work. I don't really understand the root cause of my segfaults well enough to say. | 20:03:23 |
tau | i'm on 6.8 | 20:03:44 |
| 4 Apr 2024 |
| Guilhem joined the room. | 09:22:20 |
hexa | anyway, debian is building on hifive unmatched 😄 | 09:23:54 |
hexa | my employer seems to host a bunch of these 👀 | 09:24:45 |
fgaz | hexa: as far as I know our main limitation is rack space (ping Mic92). the upcoming milk-v oasis seems like a more efficient use of that space | 09:31:27 |
hexa | huh? rack space where? | 09:31:43 |
hexa | TUM? | 09:32:01 |
Pratham Patel (you can mention me) | In reply to @fgaz:matrix.org hexa: as far as I know our main limitation is rack space (ping Mic92). the upcoming milk-v oasis seems like a more efficient use of that space The third RISC-V SoM from Sipeed is gonna have the same SG2380 SoC that the Oasis will too. Not sure on the max memory that they will ship. So for CPU-bound compiles, this SoM should be better if $ and space are an issue.
https://twitter.com/sipeedio/status/1774644666375524659
| 09:34:19 |