King_InuYasha has quit [Read error: Connection reset by peer]
esv_ is now known as esv
jcajka has joined #fedora-riscv
sharkcz has quit [Ping timeout: 255 seconds]
sharkcz has joined #fedora-riscv
kalev has joined #fedora-riscv
pjw has quit [Ping timeout: 246 seconds]
pbrobinson has quit [Ping timeout: 246 seconds]
dgilmore has quit [Read error: Connection reset by peer]
jcm__ has quit [Read error: Connection reset by peer]
jcm__ has joined #fedora-riscv
dgilmore has joined #fedora-riscv
pjw has joined #fedora-riscv
pbrobinson has joined #fedora-riscv
<davidlt[m]>
FYI we have built majority of F37. The delta is about ~3000 packages I would say.
<davidlt[m]>
I might want to do a mass rebuild of F37 at some point (TBD).
<davidlt[m]>
I thinking that maybe for F38 we should avoid (but still do it) importing noarch packages and spend the build time on those too.
<davidlt[m]>
Pushing a us a step forward :)
sharkcz_ has joined #fedora-riscv
sharkcz has quit [Ping timeout: 260 seconds]
sharkcz_ is now known as sharkcz
<somlo>
davidlt[m]: can't wait to try it on Litex :)
Kevinsadminaccou has joined #fedora-riscv
<somlo>
btw, I'm getting ready to upstream irq support for LiteUART, which *should* take care of the crashes I've been observing
<somlo>
davidlt[m]: quick question (unrelated to the uart): would it make sense to set `CONFIG_ZRAM=y` for the Fedora (rv64gc) kernel instead of `CONFIG_ZRAM=m`?
<somlo>
it appears systemd thinks zram support is pretty non-negotiable, so why even bother having it as a module?
<somlo>
I mean, it's set to `m` on x86_64, so maybe this is a more general question for the kernel team...
<davidlt[m]>
I think this flag comes from common settings. Let me check.
<davidlt[m]>
Yeah, it's one common settings for all arches.
<somlo>
systemd will flat-out refuse to make any progress until it can start swap on zram, at least as far as I was able to tell :)
<davidlt[m]>
I guess you see this because system is booting extremely slowly?
<somlo>
it is indeed very slow (50MHz, what can you do :) )
<davidlt[m]>
My experience is that systemd tends to break on slow and non-multicore systems.
<davidlt[m]>
Default config is not tuned for very slow systems.
<somlo>
part of what I tried earlier on while debugging the liteuart was to skip loading modules entirely
<davidlt[m]>
Yeah, systemd might not like that :) You need to know which modules are required for particular systemd config.
<somlo>
and if zram support isn't either built in or the module isn't available, the difference is clear: *no* progress at all, loops waiting for zram (as opposed to slow progress)
<somlo>
so it's not modules in general, it's zram in particular that systemd will insist on being available :)
<davidlt[m]>
There is probably more than that.
<somlo>
there's always more, in my experience also :)
<davidlt[m]>
But ZRAM is probably not a thing of systemd directly, but some unit file from Fedora or something.
<somlo>
right, that makes sense
<somlo>
well, one more datapoint you might find interesting -- fedora works on 512 MB of RAM :D
<davidlt[m]>
expect if you attempt to use dnf ;)
<somlo>
maybe this would be worth bringing to fosdem (not for the 512 mb thing, but for the self-hosting -- run yosys on the machine that was built with yosys to rebuild the machine, that kind of thing :)
<somlo>
I did try to use dnf, it worked eventually (got bored of waiting for it in the video I shared, gotta record a better video now that console support is solid :) )
<davidlt[m]>
Yeah, record as much as you can and make FOSDEM talk :) Or Fedora Nest or something :)
<davidlt[m]>
I plan to be at FOSDEM (if it happens IRL [most likely?]).
<somlo>
heh -- my $DAYJOB doesn't pay for the time I spend working on this (it's now purely a hobby), but most likely I can get them to pay for a trip to FOSDEM, if I get on their case soon enough :D