<davidlt[m]>
djdelorie: reminder, investigate what happened to the board. If it's alive and well, let's keep it cooking until it reconnects to the Koji.
<davidlt[m]>
rwmjones nirik check your email, reconfigure kojid.conf with new values, make sure tmpfs is not used for /tmp, you have some swap and reboot the nodes.
<davidlt[m]>
Let's keep motivation high and we will get that GCC 13 build (one day) ;)
<davidlt[m]>
Conan Kudo: I cannot wait to see this one in real life.
<davidlt[m]>
It's just sad that it wasn't released in 2022 :/
<Eighth_Doctor>
davidlt: maybe we can get these for Fedora RISC-V?
<Eighth_Doctor>
nirik, davidlt: with the riscv koji moving to fedora infra, will it get an fp.o address now (like riscv.koji.fedoraproject.org) similar to the old secondary arch koji instances?
<davidlt[m]>
Conan Kudo: that could be part of solution, but TBD. A lot of things to look at and discuss.
<davidlt[m]>
Personal preference, but I would prefer to avoid any additional Koji instances in the future.
<davidlt[m]>
So you might have noticed that the board has OCP DC-SCM. That slot is there for a reason ;)
<davidlt[m]>
There is also 64-core T-HEAD C910 systems (well, some demo sample at least) with loads of DDR.
<davidlt[m]>
Could be an option, but also a lot of TBD.
<davidlt[m]>
Intel/SiFive/etc. will deliver upstream experience. They actually are already working on it for quite some time based on upstream mailing-lists.
<davidlt[m]>
Small bits in various directions.
<davidlt[m]>
I don't really expect proper FW/SW work for T-HEAD stuff, but again TBD.
<dtometzki>
Hi davidlt my linux knowledge is good, i know how to build own sources (kernel, apps etc). But i have no experience with package build, koji or Mock.
cmagina has quit [Changing host]
cmagina has joined #fedora-riscv
<davidlt[m]>
dtometzki: have you contributed changes back to Fedora dist-git before? (via PR or/and RHBZ tickets)
esv_ is now known as esv
<dtometzki>
davidlt: I think i know how changes and git fedora works
<davidlt[m]>
dtometzki: ok, so there is simple thing that requires fixing and doesn't require too much effort. Perfect for starting.
<davidlt[m]>
So there are a bunch of packages in Fedora that check for valgrind support in a wrong way. They basically assume things.
<davidlt[m]>
Today riscv64 is not supported by valgrind, but that's WIP (not posted to the mailing-list yet).
<davidlt[m]>
%{valgrind_arches} holds arch that support valgrind, but there are a bunch of packages that never check it. Some hardcode arches, some just assume valgrind runs on anything.
<davidlt[m]>
The easiest way to find them would be to checkout full dist-git (~23K packages) and scan all *.spec files for valgrind and check if spec contains valgrind_arches,
<davidlt[m]>
You notice that .X.riscv64 pattern in Release: field.
<davidlt[m]>
This means there are changes that aren't pushed to dist-git, might be good as-is, might require rework before sending. Some might require upstream solution.
<davidlt[m]>
For valgrind stuff is just dist-git spec file fixing.