<rwmjones>
I'm sure that's the right approach, criu of containers is a somewhat niche feature
<fuwei_rh>
thanks
<rwmjones>
basically it only applies if you're using kubernetes and need to migrate containers between nodes without stopping & starting them, it's quite unusual
<fuwei_rh>
ah, OK, got it , thanks :-)
<fuwei_rh>
we are using ifnarch now
<davidlt[m]>
rwmjones: I think it's glued
<davidlt[m]>
yeah, criu doesn't support riscv
<davidlt[m]>
crun has --disable-criu
zsun has quit [Quit: Leaving.]
<davidlt[m]>
crun.spec looks intresting
<rwmjones>
davidlt[m]: nujive is up again
<rwmjones>
I just removed the cpu fan to try to improve airflow
jcajka has quit [Quit: Leaving]
<davidlt[m]>
That's what I do
<davidlt[m]>
What temps did you get during heat wave?
<rwmjones>
I thought I'd checked it, but I can't see that in the scrollback now
<rwmjones>
the room itself was 40C, so ..
<fuwei_rh>
rwmjones: we rebuilt runc, and works well
<davidlt[m]>
isn't default runtime crun these days?
<fuwei_rh>
rwmjones: podman rpms packages have been built (f36/rawhide)
<fuwei_rh>
davidlt[m]: for my env , it depends runc
<davidlt[m]>
I checked my system and default is crun for OCI runtime
<fuwei_rh>
davidlt[m]: I am not familiar with podman, but for my F36, this is runc, but not crun
<fuwei_rh>
I am confused with crun and runc :-(
<fuwei_rh>
but it works now
<davidlt[m]>
what? crun is a newer one and based on C, while runc was the first reference implementation of OCI runtime and used Golang
<davidlt[m]>
They found out that Golang as a language IIRC has some limitation and thus at some point runc (C implementation) happened
<davidlt[m]>
rwmjones: there are a several Fedora/RISCV Koji instances now out there in the world, we should figure out what to do with all that
<fuwei_rh>
maybe Carlos can answer this question , but I just try to solve the dependency problem :-)
<fuwei_rh>
davidlt[m]: we did build a lot of goland packages for podman :-)
<fuwei_rh>
s/goland/golang
<fuwei_rh>
davidlt[m]: rwmjones for now, we are working on mass rebuild for rawhide, and stop working on f36,
<davidlt[m]>
fuwei_rh: IIUC you are doing stuff for StarFive, D1 and similar?
<davidlt[m]>
Like I am not planning on supporting D1 until that is somewhat resolved upstream
<davidlt[m]>
I know there is StarFive Koji, and there is another Koji in China (openkoji), and there might another one too, just don't recall it
<fuwei_rh>
not for now, I am working on qemu , but just play with JH7100 and D1,
<davidlt[m]>
Ah cool, as those boards most likely will not get support from me
<davidlt[m]>
JH7100 is pretty much dead, all efforts are for JH7110, which most likely will get be supported
<fuwei_rh>
I did make D1 image last week , just because someone want an image for D1, :https://openkoji.iscas.ac.cn/pub/dl/riscv/Allwinner/Nezha_D1/images-release/Fedora/
<davidlt[m]>
D1 might be supported at the end (there are some patches based on alternative errata framework)
<fuwei_rh>
true , JH7100 is dated
<rwmjones>
davidlt[m]: yup
<fuwei_rh>
I am waiting for JH7110
<fuwei_rh>
I got a K510 too
<davidlt[m]>
Sadly Beagleboards got delayed
<fuwei_rh>
yes
<davidlt[m]>
I recall K510 announcement, but not sure if there are any boards
<davidlt[m]>
The most interesting boards to support would be PINE64 RISC-V board, StarFive new board with JH7110 and two new BeagleBoards
<fuwei_rh>
but I am very looking forward to BeagleV (there are two this year)
<davidlt[m]>
PINE64 and BeagleBoards are bound to be quite popular
<davidlt[m]>
Ah yes, and a new SiFive board
<davidlt[m]>
Yeah, they were supposed to be announced in Embedded World, but I think chip shortage delayed everything
<davidlt[m]>
Which might be a problem for any board these days