Please see http://porkchop.redhat.com/beehive/logs/mysql-698844-s390x-spud.z900.redhat.com.log Errors are (from /usr/src/build/698854-s390x/BUILD/mysql-5.0.18/mysql-test/var/log/mysqltest-time) : mysqltest: At line 2147624200: Result length mismatch (the last lines may be the most important ones) Below are the diffs between actual and expected results: ------------------------------------------------------- *** r/sp-vars.result Wed Dec 21 22:50:25 2005 --- r/sp-vars.reject Thu Feb 9 03:36:37 2006 *************** *** 446,453 **** Warnings: Note 1305 PROCEDURE p2 does not exist DROP TABLE IF EXISTS t1; - Warnings: - Note 1051 Unknown table 't1' CREATE TABLE t1(log_msg VARCHAR(1024)); CREATE PROCEDURE p1(arg VARCHAR(255)) BEGIN --- 446,451 ---- ------------------------------------------------------- Please follow the instructions outlined at http://www.mysql.com/doc/en/Reporting_mysqltest_bugs.html to find the reason to this problem and how to report this. Aborting: sp-vars failed in default mode. To continue, re-run with '--force'. Ending Tests Shutting-down MySQL daemon Master shutdown finished Slave shutdown finished make: *** [test] Error 1 error: Bad exit status from /usr/src/build/698854-s390x/install-tmp/rpm-tmp.16512 (%build)
Worked fine when I built it. I noticed that in the failed run, spud was building both the s390 and s390x ports, and it was running the mysql regression tests in both buildroots at the time of the failure. I suspect that there is some interaction when multiple copies of the regression tests run concurrently in a single machine. Our RPMs already take several measures to prevent such interaction, such as forcing different TCP port numbers to be used, but perhaps there is still something there. Or maybe mysql is just flaky ;-). But I've seen test failures before with multiarch machines building both arches concurrently, and never when it's running by itself. Disinclined to spend more time on it right now.