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? Cheers, Mark
