Bug 180659 - mysql fails to build in rawhide
Summary: mysql fails to build in rawhide
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: mysql
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tom Lane
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-02-09 19:30 UTC by Jesse Keating
Modified: 2013-07-03 03:08 UTC (History)
3 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2006-02-10 01:51:14 UTC


Attachments (Terms of Use)

Description Jesse Keating 2006-02-09 19:30:51 UTC
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)

Comment 1 Tom Lane 2006-02-10 01:51:14 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.