On Tue, Jan 10, 2023 at 5:11 AM David Abdurachmanov <david.abdurachmanov@xxxxxxxxx> wrote: > > 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. > There is precedent for the AltArch SIG to rebuild EPEL for an alternative architecture. I think the way it would be done today would necessarily need to be different from how it was done in the times we build 32-bit x86 and ARM support with CentOS 7, but it's absolutely doable. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
