On Mon, Jan 9, 2023 at 3:22 PM Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > > On Mon, Jan 9, 2023 at 9:15 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > > > On Mon, Jan 9, 2023 at 8:47 AM Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > > > > > > On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov > > > <david.abdurachmanov@xxxxxxxxx> wrote: > > > > > > > > On Sun, Jan 8, 2023 at 2:28 AM Jeff Law <jlaw@xxxxxxxxxxxxxxxx> wrote: > > > > > > > > > > > > > > > > > > > > On 1/6/23 23:41, David Abdurachmanov wrote: > > > > > > > > > > > > Summary from multi-year discussions/feedback on this: > > > > > > - We don't have proper hardware to put into the data center that holds > > > > > > servers used by Fedora infrastructure. > > > > > Right. dev boards are not the solution here. It's got to be something > > > > > that can be racked and with enough performance to matter. > > > > > > > > > > > - Not enough single and multi thread performance to avoid large impact > > > > > > to Fedora development. > > > > > Agreed. Returning to a situation like we had with armv7 isn't > > > > > acceptable IMHO. > > > > > > > > > > > > > > > > > Other than that Fedora/RISCV 37 is the first Fedora version to be > > > > > > built fully natively using 20+ SiFive HiFive Unmatched boards. On a > > > > > > good day we can keep up (if the builds aren't too large, e.g. GCC). We > > > > > > don't really run Bodhi thus once package is built it's immediately > > > > > > available. We run a very minimal setup right now (ideas to expand > > > > > > that). > > > > > It's fantastic we've got that far. But clearly it's not viable long term. > > > > > > > > Agreed. We have been cooking Fedora/RISCV since 2016, but we really > > > > cannot move forward until the proper hardware (and things around it) > > > > becomes available. > > > > > > > > > > > > > > > > > > > > Another news is that Fedora/RISCV Koji server ( > > > > > > http://fedora.riscv.rocks/koji/ ) just moved into Fedora infra owned > > > > > > server. We are about to start work on Fedora 38/Rawhide. > > > > > Excellent. I'll have to update my chroots and containers as the F38 > > > > > bits start appearing. > > > > > > > > I am still tweaking the server configuration, but I should be ready > > > > for mass building soonish. > > > > I might want to wait for GCC 13 to land in Rawhide, which should > > > > happen soon (I think). > > > > > > > > > > > > > > > > > > > > > 2023 is potentially a transition year. Ventana Veyron V1 Development > > > > > > Platform looks good (I assume it has BMC). SOPHGO SG2042 should also > > > > > > show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023 (?) I am not > > > > > > yet convinced about their upstream support efforts (TBD). > > > > > Yes Veyron-v1 will have a BMC and will be rackable. I have no > > > > > significant insight into the T-HEAD efforts other than they do work a > > > > > fair amount with VRULL on compiler and related technology. > > > > > > > > I noticed that VRULL has been involved with T-HEAD on GCC and > > > > potentially kernel side for a few months now. This makes them much > > > > more optimistic about their SoC/HW support in general. > > > > > > > > > > > > > > > > > > > > > > > > > > If there is away to acquire Veyron V1 Development Platform I would be > > > > > > interested to talk, and figure out what that would take. Such hardware > > > > > > would be a game charger, and I do trust Ventana regarding upstream > > > > > > support :) > > > > > I'll be pushing to make systems available to Fedora and the GCC farm, > > > > > but in general Ventana is more aligned towards Ubuntu. My goal is to > > > > > have Fedora and Ubuntu on equal footing as quickly as possible. > > > > > > > > We have been trying to get stuff into GCC Compiler Farm for years now. > > > > There are a couple of boards IIRC. There are additional requirements > > > > on the software side (well, distributions) that we couldn't provide > > > > for quite some time. > > > > > > > > > > > > > > I do know rackable systems will be limited -- there's one particular > > > > > component needed on the rackable systems that is in very short supply. > > > > > We've got multiple orders in, but quantities are limited and lead times > > > > > are absolutely insane. > > > > > > > > FYI, I think, the new aarch64 builders are 8 core, 35G RAM and 8G > > > > swap. The older machines had 8G/core setup. There seems to be 8 (?) > > > > servers with 80 cores, but so far only 40-50 builders are enabled (no > > > > overcommitting on CPU as that's not a great idea [based on my own > > > > experience]). > > > > > > > > I expect Veyron V1 to deliver a decent single and multi thread > > > > performance, but we will need a lot of them. Probably 20-25 systems if > > > > we assume a similar configuration as aarch64 builders (8-core, 32-64G > > > > of RAM, 100-200G for storage). RAM and storage are cheap, but systems > > > > will continue to be a problem. If we could somehow get to this level > > > > we could stop investing into SBCs as they are stop-gap solutions for > > > > builders. > > > > > > > > Based on some guesses there isn't a lot of time either. I would love > > > > to bootstrap CentOS Stream 10. It would be nice to have Fedora + > > > > riscv64 in a good shape before that happens, but probably unrealistic. > > > > > > It is very unlikely that CentOS Stream 10 will include RISC-V as a > > > fully included architecture. Perhaps via a CentOS Stream SIG. > > > > > > > I believe that was the implication in the first place, hence > > mentioning CentOS Stream rather than RHEL. > > Better to be clear about direction up-front, so thanks for clarifying. > "CentOS Stream" is used as both an umbrella term and a specific OS and > it causes confusion sometimes. Yes, that would be CentOS Stream SIG. There is interest in this. > > > The Alternative Architectures SIG in CentOS would be where this would > > happen. But the work needs to be done in Fedora first. > > Alternative Arches would totally make sense to me. And agreed Fedora > needs to land first. Agreed. Doing some prediction based on the history, we have 2-3 Fedora releases before CentOS Stream 10 might happen. Without EPEL CentOS Stream (package wise) is not large. Of course the majority (if not all) users consider EPEL an important part of the experience. Cheers, david > > josh > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
