On Sun, Aug 24, 2025, 7:41 AM Mark Wielaard <m...@klomp.org> wrote:
> Hi, > > On Wed, Aug 13, 2025 at 08:53:44AM +0200, Richard Biener via Gcc wrote: > > On Tue, Aug 12, 2025 at 10:43 PM Andrew Pinski via Gcc <gcc@gcc.gnu.org> > wrote: > > > I think we should have a requirement of the bare minimum for a port is > a > > > maintainer. > > > I also vote to have a testresults for the target at least once a year. > > > > Having testresults also shows the port builds (as a cross at least) and > is > > able to build its target libraries. IMO broken ports are worse than > > unmaintained ones, esp. if we release with those. > > > > Ideally we'd have build bots with publically visible results that > > test the building part (doesn't have to run often), this should > > include building cross-binutils, newlib/glibc/avr-libc as fit. > > Before releasing I'd auto-deprecate all broken configs, I'd expect > > maintainers to analyze such failures (they might be bot issues). > > Having testresults would be secondary (but nice), that includes > > running the runtimes testsuite. > > > > That said, I'd like to move away from gcc-testresults as a vetting > > tool to something more modern. > > If the port has a (qemu) emulator we could create a x86_64 container > for it and run it once a month/week on one of the faster > builder.sourceware.org workers. > > https://sourceware.org/cgit/builder/tree/README > https://sourceware.org/cgit/builder/tree/builder/containers > > Are there any ports that can be tested that way? And does someone have > a description (or script) of such a (cross) build that we could turn > into a x86_64 container build? > For which architectures? We might have one if RTEMS ever ran on it. --joel > > Cheers, > > Mark >
