dgilmore changed the topic of #fedora-riscv to: Fedora on RISC-V https://fedoraproject.org/wiki/Architectures/RISC-V || Logs: https://libera.irclog.whitequark.org/fedora-riscv || Alt Arch discussions are welcome in #fedora-alt-arches
Eighth_Doctor has quit [Read error: Software caused connection abort]
Eighth_Doctor has joined #fedora-riscv
davidlt has joined #fedora-riscv
<davidlt[m]> nirik: will do in a few hours
davidlt has quit [Ping timeout: 268 seconds]
zsun has joined #fedora-riscv
davidlt has joined #fedora-riscv
esv has quit [Remote host closed the connection]
esv has joined #fedora-riscv
jcajka has joined #fedora-riscv
esv_ has joined #fedora-riscv
esv has quit [Ping timeout: 260 seconds]
jcajka has quit [Ping timeout: 252 seconds]
somlo has quit [Read error: Connection reset by peer]
jcajka has joined #fedora-riscv
esv_ has quit [Ping timeout: 260 seconds]
davidlt has quit [Remote host closed the connection]
davidlt has joined #fedora-riscv
esv_ has joined #fedora-riscv
esv_ is now known as esv
somlo has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
<davidlt[m]> XuanTie C908 is the latest RISC-V processor of the XuanTie series launched by T-Head Semiconductor. It has adopted the RV64GCB[V] instruction and is compatible with RVA22 profile. XuanTie C908 utilizes a high-efficiency,dual-issued, and 9-stage in-order pipeline. It is equipped with an AI acceleration engine. It is designed to be suited for applications such as Intelligent Interaction, AR/VR.
<davidlt[m]> nirik: pub key sent over the email.
jcajka has quit [Quit: Leaving]
<nirik> davidlt[m]: thanks.
<nirik> hum. ah... thats what happened. So yeah, m6gd.4xlarge is a aarch64 type. ;) Is that ok, or did you want a x86_64? I don't know that it matters too much...
<davidlt[m]> I bet it doesn't matter, but you are a better expert here :)
<nirik> there might be weird corner cases. I don't know any koji hubs running on aarch64... but it all should work.
<davidlt[m]> Yeah. Most likely ST performance is slightly worse (?), and maybe less optimizations in things like postgresql, or something like that.
<davidlt[m]> I mean, it's basically optimization thing.
<davidlt[m]> That table doesn't list arch.
<davidlt[m]> So you make a call. Worst case scenario, we need to stop again and move to a new instance with x86_64.
<nirik> sure, ok
<davidlt[m]> Again, in general I cannot come up with some Fedora infra software piece that would explicitly require x86_64.
<davidlt[m]> So yeah, I am making my life easier ;) You make the call as the expert here :)
ol has joined #fedora-riscv
<nirik> how much space to you have in / ? how big is the db?
<davidlt[m]> db is 21G, growing fast. Current volume size is 40G. Most likely will need to be increased again within a year or so.
<nirik> ok, so shall I do 50 to give some room?
<nirik> or 75?
<davidlt[m]> 75 and we don't need to think about it for 2 years or so :)
<nirik> sounds good
<davidlt[m]> koji storage is 6T almost completely full.
<davidlt[m]> Technically Koji Hub stops working once free space drops to ~141G or so for some reason.
<davidlt[m]> Today Kojira created repos per day consume 40-60G.
<nirik> yeah.
<nirik> I'm making a 16T volume... thats the max you can make with EBS.
<davidlt[m]> That's for default 7 day config, which we should increase to at least 10-14 days.
<ol> Hello enerybody! As a result of googling for "fedora risc-v" I found this package-building machine: http://riscv.rocks/koji/
<ol> It currently builds RISC-V packages for Fedora 37, mostly at night time. Does anybody know what it means? Is this Fedora 37 RISC-V release in preparation?
<davidlt[m]> Our current stats are: 2652 for 7 days, 5693 for 30 days. That's successful builds. The numbers are going up.
<davidlt[m]> Yeah, most boards are powered off (I sleep). Thus I don't run them 24/7 (yet).
<davidlt[m]> Yes, we built majority of F37 already. I will be working on a new disk image for SiFive HiFive Unmatched soonish.
<davidlt[m]> Already attempted one to check what's broken / what's still not yet rebuilt.
<nirik> davidlt[m]: email back your way with the ip of the instance. your key is on it. I've done almost nothing else on it. If you would like me to do anything further on it, just let me know. We can see if this will meet our needs. If it doesn't we can always adjust and spin up a new one. ;)
<davidlt[m]> Well at least bulk of data (EBS) most likely don't need to be moved.
<davidlt[m]> Most of time will probably go into (1) remembering how to configure the everything and tune it (2) moving data.
<davidlt[m]> Also applying all those Koji database schema updates, etc.
<nirik> moving data I expect will take a while. ;(
<ol> <davidlt[m]> "Yes, we built majority of F37..." <- Will any other (more affordable) be supported? Like VisionFive 2, for example.
<davidlt[m]> Oleg Girko: yes, but that will depend on upstreaming efforts too.
<davidlt[m]> I already have PINE64 Star64 developer sample, still waiting for StarFive VisionFive V2.
<davidlt[m]> nirik: kinda, but I know how to pump data fast, but it will be a week long downtime once this happens anyways.
<ol> Let me introduce myself. I'm Oleg, and I ported OBS (Open Build Service) to Fedora. I own my own OBS server where I build some interesting packages for Fedora. Now I'm evaluating whether to add RISC-V workers to my OBS server to build packages for RISC-V architecture. I need two things for this: RISC-V package repos for Fedora and RISC-V computer(s) to use as workers.
<davidlt[m]> nirik: we will probably do this once I am completely out of free space, which currently is 1 day (max 2) of run-time ;)
<davidlt[m]> Oleg Girko: cool. JH7110 based boards will be your best option (performance/cost).
<nirik> davidlt[m]: I'd suggest starting the sync now/soon before anything else. It's likely to take the most time and then if nothing else you will have a copy in aws. ;)
<davidlt[m]> Today I cannot provide a stable repository to work with, but that's quickly improving. There is already a test one for Fedora 37.
<davidlt[m]> nirik: I think most of the data could be moved within 24 hour window. I learned how to move tons of data fast :) fiber helps too ;)
<ol> davidlt[m]: Ideally, a board with at least 16G of RAM will be needed to perform builds completely in memory. Are you aware of boards with 16G of RAM?
<ol> davidlt[m]: Can you give me a link please?
<davidlt[m]> The only downside of moving data fast is that it required lots of ram (exist) and plenty of compute power, which is annoying.
<davidlt[m]> The only board with 16G of RAM is SiFive HiFive Unmatched, which is not sold anymore. A next-gen (way more powerful) will be announced in December (Intel/SiFive colab).
<davidlt[m]> Note, this is generated via Koji and most likely will be garbage collected in 1 or 2 weeks (don't recall the setting).
<ol> davidlt[m]: Thank you!
<ol> Are there any RISC-V boards that have DIMM slots?
<davidlt[m]> No
<davidlt[m]> nirik: so far I am failing to login, but hey it's Friday evening, maybe I am just done :)
<nirik> huh, odd. you are logging in as root right?
<davidlt[m]> ah
<davidlt[m]> It's root :)
<davidlt[m]> I used to root login being disabled :)
<nirik> yeah, thats default on cloud images, but I think it's stupid. ;)
<davidlt[m]> nirik: is there already volumes for /mnt/koji or/and database?
<ol> Alternatively, VisionFive 2 with 8G of RAM and NVMe SSD would work as well, building packages without tmpfs, but it will relatively quickly wear off NVMe SSD.
<davidlt[m]> Oleg Girko: most likely you will replace a board before that happens :)
<nirik> nope, I didn't do anything. ;) do a lsblk and you will see the 16TB volume, you can format and mount it... for database I was thinking it could just go on / but you could carve off some from the other volume if you like
<davidlt[m]> Even with 16G of RAM we run with tmpfs disabled.
<ol> davidlt[m]: Why?
<davidlt[m]> Not enough RAM at link stage.
<ol> davidlt[m]: No, I don't build packages that are *this* large.
<davidlt[m]> In that case you are fine :)
<davidlt[m]> nirik: there is a second NVMe. That is for? I might use part of it for postgresql.
<ol> It requires 7G of temporary files during tests.
<davidlt[m]> Well that will not fit into tmpfs :)
<nirik> davidlt[m]: oh, I guess 16T isn't the limit, it's lower than that and it gave me one at the limit and the rest as another. ;) Sure, what works for postgres
<davidlt[m]> Ok
<davidlt[m]> nirik: are these backed up by AWS by default, or do I need to care about redundancy or something?
<nirik> they are not backed up... but they should be pretty reliable.
<ol> davidlt[m]: Also, in OBS you can specify conatraints for selecting workers for package build, so some especially big packages can be built on workers with more RAM, for example.
davidlt has quit [Ping timeout: 255 seconds]
<Eighth_Doctor> nirik: do you think we can get packager dev/test riscv64 environments?
<Eighth_Doctor> seems debian finally got a porterbox up for their contributors: https://blog.aurel32.net/riscv64-porterbox.html
<nirik> well, that would be nice, but we don't have any hardware currently... might be after the new board announcement in dec we can get some of those...
gotmax[m] has joined #fedora-riscv
<ol> <nirik> "well, that would be nice, but we..." <- What board announcement?
<ol> <nirik> "https://riscvsummit2022.sched...." <- It would be interesting to know how affordable this SoC will be.
<nirik> yeah. I guess we will know when that talk happens hopefully...
<ol> nirik: We'll see. So far, I would not call SiFive SoCs affordable.
leah2 has quit [*.net *.split]
leah2 has joined #fedora-riscv