It appears that the server actually crashes here, so it would be better to check it.
What are our options? Can we access the machine to run anything there manually? Or what else can we do with the box?

Re-opening - if we have to mark the test unstable, we can't just close the report.

cvicentiu, could you please check if it's still valid, and close if it's not? Thanks

Test failure avoided by not compiling.

Not a supported architecture.

MariaDB 10.5 a year ago still built on Alpha:
https://buildd.debian.org/status/logs.php?pkg=mariadb-10.5
https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.5&arch=alpha&ver=1%3A10.5.12-1&stamp=1628596323&raw=0

While Alpha is an esoteric architecture, mistakes that break cross-arch builds are typically due to misuse of C++ syntax/concepts and fixing them usually benefits all architectures.

So you have decided that from MariaDB 10.6 onwards it is OK to break Alpha builds (and all other architectures that share the same fundamental thing that was now broken, whatever it is).

Note that in MariaDB 10.6.9 also the builds on ia64, m68k, riscv64 and sparc64 started to fail. They used to work, and whatever broke them is probably a bug in MariaDB C/C++ code syntax/constructs. I think an open source database that tries to be universal and have large adoption should care about cross-architecture compatible code at least to the degree that existing platforms should continue to work, as that is most likely not that much work to do.

Details: https://alioth-lists.debian.net/pipermail/pkg-mysql-maint/2022-September/015984.html

FYI TheLinuxJedi

Supported by us is the architectures and configurations in buildbot.

Debian supported architectures are supported by Debian. Maintenance means putting an effort into fixing these supposedly simple things and submitting them upstream.

While care is taken on good constructs, without a CI to enforce it there's no responsibility.

Like other platforms like BSDs that we don't have in CI, its maintainers and interested parties do a great job in submitting patches to fix platform issues.

Alpha was a linker error, so wasn't unlikely C/C++ constructs. If there's someone that understands the required linking conventions of Alpha and they can offer a proposals on how to handle this and they are welcome at https://github.com/MariaDB/server/pulls.

While cross platform has always been a goal, without users to express interest or people wiling to point out error, there will be bugs that creep in. A 7 year old bug like this where no user raised interest in the lack of support, here or on the debian-mysql isn't important enough. Guessing solutions on platforms we don't have access to isn't a time effective solution.

There are enough user submitted bugs/feature requests on things that matter to them to occupy the development effort.

Alpha was a linker error, so wasn't unlikely C/C++ constructs.

Thanks for checking.

Note that while this bug has been open for 7 years, the the previous passed Alpha build from 1 year ago (https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.5&arch=alpha&ver=1%3A10.5.12-1&stamp=1628596323&raw=0) did not suffer from this as the test was on skiplist due to MDEV-13887 (which was originally detected in Buildbot).

Just leaving this info here in case somebody else wants to contribute and fix this test for all platforms.

Incidentally, riscv64 is failing because you were using a version of GCC which has known bug in RISC-V atomics. It was fixed in GCC in May IIRC.

As for m68k, I'm probably one of the only people in the world with an m68k machine capable of running MariaDB on it even if we could compile it. And that is only because I designed the firmware and hardware to be way outside of the original m68k spec.