<davidlt[m]>
Bruce Hoult wrote on Telegram bridged to Matrix:
<davidlt[m]>
> It's good. I just plugged it in and turned it on. Haven't bothered to replace the preinstalled OS (in eMMC) because it does everything I need. The main thing: it has a much higher performance RVV 0.7.1 than the C906 boards. Good for local testing of things for SG2042 (which I only have ssh access to, on the other side of the world), just using up to 4 cores rather than 64. For things using just CPU and L1 cache it is ofter 40% faster
<davidlt[m]>
on some real-world things such as building riscv-gnu-toolchain it is actually 10% slower than VF2! With both using the same src/build tree on the same 2 TB Samsung USB3 SSD.
<davidlt[m]>
dtometzki: is your lpi4a running with a fan?
<dtometzki>
davidlt: yes a Fan was included.
<davidlt[m]>
Cool.
<davidlt[m]>
dtometzki: I would need root access to install all the dependencies, or we need to figure out if we can run podman rootless or/and install mock and write a config for it.
<dtometzki>
Yes I read your mail. I‘am today on the way to a customer. I will Check it tomorrow
<davidlt[m]>
Ok
<dtometzki>
Sorry for the delay. RISCV is only my hobby.
<davidlt[m]>
That's fine, no rush.
<davidlt[m]>
Time to update OpenSBi and rebuild U-Boot. Then I will look at that default mock config that I still didn't update.
<davidlt[m]>
Spent some time looking at mock configs. I have idea what I want.
<davidlt[m]>
OpenSBI built, time to rebuild U-Boot.
<davidlt[m]>
OS-A SEE is no more, it was renamed to BRS (Boot & Runtime Services).
<Entei[m]>
First I am installing qemu from rawhide repo. No more manually building with make
<davidlt[m]>
I would advice against manually building QEMU :)
<davidlt[m]>
Unless you know that you need it.
<davidlt[m]>
There is nothing interesting on the stable kernel queue. Usually it's because of MW.
<Entei[m]>
I will hopefully get the koji server working soon. Btw for builders we will start with machines in the network and run qemu on all of them. Do the builders need to have equal number of cores across them? Say I have two different machines, one of them can provide 16 cores, while the other can only do 8 cores, is there a way to distribute task? Or is it random?
<davidlt[m]>
You don't need to match machines. I used to run different vCPU and MEM builders.
<davidlt[m]>
The builder takes a job from Koji queue. You can manually assigned specific builds to a particular builders.
<davidlt[m]>
You can use also channels and assign builders to particular ones.
<davidlt[m]>
You can also write custom rules in Koji Hub.
<Entei[m]>
Oh that's good to hear
<davidlt[m]>
There is also priority and capacity.
<davidlt[m]>
Each new build in Koji gets capacity at 1.5 (max is 6).
<davidlt[m]>
Machines also have capacity and maxjobs settings.
<davidlt[m]>
I would advice to stay at maxjobs 1 (maybe go to 2, but that will depend on your operational experience).
<davidlt[m]>
So priority, capacity and channels are what decide where things land.
<Entei[m]>
So each kojibuilder will say run 2 mock containers?
<davidlt[m]>
Also there are rules in Koji Hub.
<davidlt[m]>
Yes. Depending on maxjobs and capacity settings.
<davidlt[m]>
to build SRPM package that load is 1.0
<davidlt[m]>
Most packages will be close to 4-6 in the load scale.
<davidlt[m]>
It's not really useful as pretty much all builds are expensive on riscv64.
<davidlt[m]>
That's why maxjobs=1 in the builders configuration, and then manual adjustment works fine for me.
<davidlt[m]>
I explicitly "pin" GCC builds to the particular boards.
<Entei[m]>
I am updating a single package qemu from rawhide repo, and apparently it's gonna update glibc from rawhide as well. What are the chances I will break everything?
<davidlt[m]>
Most likely none.
<davidlt[m]>
Rawhide very rarely breaks.
<davidlt[m]>
Most of Fedora/RISCV infra ran on Rawhide ;)
<conchuod>
davidlt[m]: How many unmatched boards do you have?!
<davidlt[m]>
We run 20 or more.
<davidlt[m]>
Okay, I still need to connect the last ones.
<conchuod>
With all those dinky fans, must be like 200 dB
<davidlt[m]>
It is. Most don't have fans replacement, but that's on TODO list too.
<Entei[m]>
I am getting package conflicts when updating qemu from rawhide repo. Do I have to uninstall qemu first?
<davidlt[m]>
Entei: why not use the one from Fedora directly or from COPR virt-preview?
<davidlt[m]>
conchuod: why do you ask?
<conchuod>
just clicked that link that's all.
<Entei[m]>
davidlt[m]: qemu 7.2 (the latest one available on Fedora 38) is unable to run more than 8 cores. Qemu 8 runs 20 cores for me
<davidlt[m]>
conchuod: we used to run almost 180 VMs before :)
<conchuod>
The number isn't really what surprises me in an of itself, it's how many you have.
<conchuod>
But I guess, given $old_dayjob, shouldn't really surprise me.
<davidlt[m]>
Nope, a different company sponsored that.
<davidlt[m]>
The large part of our infra was sponsored by WDC.
<davidlt[m]>
OpenSBI and U-Boot is done. Mock config is next.
<davidlt[m]>
Time to pull a board out and replace NVMe to Fedora 38 :)
davide has quit [Server closed connection]
davide has joined #fedora-riscv
<davidlt[m]>
Oh, testing that mock config will take some time :D
<davidlt[m]>
I didn't think about that.
<Entei[m]>
Where do builders get the package to rebuild? Till now my understanding is builder pulls rpms from a repo (which is in /mnt/koji) and from the same storage space it pulls srpms as well.
<Entei[m]>
But looking at koji client, the `koji build` command expects the build group and a git repo? In the server config I haven't seen any mention of setting up git repo
<davidlt[m]>
from dist-git
<davidlt[m]>
source tarballs from look aside cache
<davidlt[m]>
So far testing mock config is going well.
<davidlt[m]>
Testing now rebuilding the SRPM.
<Entei[m]>
That looks like a complicated setup.... downloading the srpm from same repo which it uses to download binary rpms to populate the chroot would have been great.
<Entei[m]>
What even is there on the dist-git? It is srpms or just tarballs?
<davidlt[m]>
dist-git is location where all git repositories are kept with all the history
<davidlt[m]>
look aside cache is source tarball location. The package maintainer uploads all the tarballs/files needed to build the package into the cache.
<davidlt[m]>
Koji takes SCM URL to build. That basically means repository + commit hash. Based on that information it will look into the cache to find required tarballs/files to build the package.
Kevinsadminaccou has quit [Server closed connection]
Kevinsadminaccou has joined #fedora-riscv
<davidlt[m]>
You can also submit SRPMs to Koji, but that's not great if you want to track your progress.
<davidlt[m]>
Trust me, you most likely will loose yourself within ~23K packages for some time.
<davidlt[m]>
And it will be hard to remember why you did some changes.
<Entei[m]>
So now I have to set up a SCM server as well? Because my spec files are going to be very different from what you guys are using...
<davidlt[m]>
Majority of those should not change. I do have dist-git overlay for Fedora/RISCV where I can experiment freely.