<rwmjones>
so I wonder how they bootstrap all this? there's no obvious bootstrap in the pakcage
<davidlt[m]>
Not all golang* packages have a bootstrap option.
<davidlt[m]>
It's just exist from the old days :)
<davidlt[m]>
I just made some coffee, and uboot is still building, let me try a thing.
zsun has quit [Ping timeout: 268 seconds]
<fuwei>
davidlt[m]: ping
<davidlt[m]>
pong
<fuwei>
hi davidlt[m], we still using grubby to install vmlinuz?
<fuwei>
so the systemd patch is still needed ?
<fuwei>
Revert "Drop 20-grubby.install plugin for kernel-install"
<davidlt[m]>
Yes, until we switch. New GRUB2 release is not out yet.
<davidlt[m]>
There was a recent update on that.
<davidlt[m]>
Code free happens in May.
<fuwei>
yes , The riscv64 support in GRUB2 has upstreamed , right?
<davidlt[m]>
For the legacy boot mode IIRC.
<fuwei>
I saw some patches in mainline
<davidlt[m]>
Not for UEFI.
<fuwei>
for u-boot --> grub2--> kernel
<davidlt[m]>
Or if it does UEFI, then it cannot do initrd in UEFI. Like missing LoadFIle2 support for riscv64.
<davidlt[m]>
fuwei: Is it possible to buy that 64-core system already?
<davidlt[m]>
So sad AMD still doesn't support 48GB DIMMs with Ryzen 7000.
<fuwei>
for the 64-core, nearly , let me ask Tom then get back to you
<davidlt[m]>
Cool. We need those ASAP (for development speed up and builders too).
<davidlt[m]>
Pratham Patel: are you the official Arch Linux RISCV maintainer?
zsun has joined #fedora-riscv
<Esmil>
davidlt[m]: that would be felixonmars on #archlinuxriscv
<davidlt[m]>
Esmil: thanks
<thefossguy>
Arch doesn’t even officially support non-x86 arches
<thefossguy>
So no ;)
<thefossguy>
I’m just your average guy that wants to learn
<thefossguy>
So i created an image with Arch because its rolling release nature will help alleviate some issues :)
<fuwei>
Esmil: felixonmars ? That Chinese guy?
<thefossguy>
Yeah
<thefossguy>
He maintains most of the Arch Linux RISC-V stuff
<fuwei>
I often got help from him
<thefossguy>
He’s also the official maintainer Arch Linux
<fuwei>
we sometime met in Wuhang or Shanghai
<thefossguy>
Das kool
<rwmjones>
davidlt[m]: do we have a non-golang package to look at? I think it's best to give that golang mess to the golang guy who volunteered for it
<davidlt[m]>
rwmjones: I already made progress on golang today :)
<fuwei>
davidlt[m]: golang modules ?
<rwmjones>
how? it looks like such a mess ...
<davidlt[m]>
saw an opening today while giving yet another quick look.
<davidlt[m]>
I have one package done and compiling golang-x-tools now.
<rwmjones>
'eck ..
<davidlt[m]>
rwmjones: I borrowed bits from the official Koji.
<rwmjones>
oh I see, are they noarch?
<davidlt[m]>
The bits I needed were noarch :)
<davidlt[m]>
fuwei: We have some golang packages that aren't bootstraped because of large dependency cyclic dependency hell.
<fuwei>
davidlt[m]: we are trying to solve it too
<fuwei>
in our repo , the number of package is 18100
<fuwei>
but more than 1000 packages about golang have not been built
<davidlt[m]>
I just made progress on that.
<davidlt[m]>
So the ice might move in a few days. Just trying to build a few locally and import into Koji.
<davidlt[m]>
rwmjones: the next important and annoying thing would be GHC :)
<fuwei>
I guess we can borrow some packages from you, and go on
<davidlt[m]>
rwmjones: the top level task: get "pandoc" built.
<davidlt[m]>
The official RHEL / Fedora / etc. GHC maintainer knows about this issue. We have exchanged some emails over weeks/months.
<thefossguy>
[fuwei](<https://matrix.to/#/@fuwei:libera.chat>) are you a distro maintainer?
<fuwei>
davidlt[m]: on our side, we have pandoc-2.14.0.3-18.fc37, we are working 2.19 by borrowing your ghc module
<rwmjones>
davidlt[m]: sure I can have a look at pandoc
<rwmjones>
it's about the largest binary in the distro ...
<davidlt[m]>
rwmjones: it's much more problematic than that. We continue to use C backend, and somehow a few packages complain about failing to find interpreter for a target. Google has very little details about this.
<davidlt[m]>
rwmjones: we also have GHC + patched + LLVM 13 backend. That makes the whole thing slightly faster, but it seems there are issues or/and mixing GHC compiled with C-backend and LLVM-backend might not be compatible.
<davidlt[m]>
I untagged GHC build with LLVM 13 (there is also one with LLVM 12, but that one failed way too quickly).
<davidlt[m]>
One thing would be to debug GHC (perfect thing if you love Haskell) to figure out why it sometimes doesn't find interpreter.
<fuwei>
thefossguy: I don't know the link your sent , but I am just also working Fedora Image on some RISC-V dev board on a server (https://openkoji.iscas.ac.cn/koji/) , based on davidlt[m]'s work F33
<davidlt[m]>
There is like ~90% of packages compiled, but some direct dependencies are blocking getting to pandoc.
<davidlt[m]>
Incl. pandoc-types package.
<thefossguy>
fuwei: So THAT’S why you have access to a 64-core server 😅
<thefossguy>
Also, i dont recall sending any link
<davidlt[m]>
Some folks in China has some early EVBs.
<fuwei>
thefossguy: because I am in China, and the server is made in China
<davidlt[m]>
Also some of those are available publicly to access too.
rwmjones is now known as rwmjones|mtg
<thefossguy>
Tenstorrent has one ready too. If my source is correct.
<fuwei>
davidlt[m]: I got Milk-V too
<thefossguy>
Though theirs is more AI focused.
<davidlt[m]>
I know.
<davidlt[m]>
That's C920 OoO from Alibaba T-HEAD.
<fuwei>
yes
<davidlt[m]>
It's definitely not AI focused i would say. It could be used for that, but I don't see much use from Sv39 and AI in the same context.
<davidlt[m]>
For 64-core system it's quite limited memory capacity wise, and I bet bandwidth/latency/interconnect/etc. will be not great.
<fuwei>
for now , the max memory capacity for 64-core is 128GB
<fuwei>
but they have two-socket server now , 128-core with 256GB
jcajka has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
rwmjones|mtg is now known as rwmjones
<rwmjones>
davidlt[m]: oh so this one?
<rwmjones>
ghc-9.2.6: Couldn't find a target code interpreter. Try with -fexternal-interpreter
<rwmjones>
I'll see if I can find anything about that ...
<davidlt[m]>
rwmjones: yes
<davidlt[m]>
I think there are two (or more) options here:
<davidlt[m]>
1. Debug Haskell to figure out why this happens. I decided not to do it, too much time for me.
<davidlt[m]>
2. Talk to upstream. That's the most proper way, but didn't have time.
<davidlt[m]>
3. Retag GHC + LLVM13 build and attempt to rebuild the whole GHC ecossytem (<700 packages IIRC).
<rwmjones>
I'm going to ask on fedora devel first
<davidlt[m]>
OpenSUSE or/and Debian are using GHC + LLVM 13 (that's how we decided to test it).
<davidlt[m]>
I asked the main GHC maintainer and he didn't know much about this.
<davidlt[m]>
The consensus was that we most likely need to go upstream.