Bug 789530 - mysql tests fail when run from mysql-test RPM, apparently a path issue
Summary: mysql tests fail when run from mysql-test RPM, apparently a path issue
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mysql
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tom Lane
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-11 01:43 UTC by Tom Lane
Modified: 2012-03-17 23:48 UTC (History)
2 users (show)

Fixed In Version: mysql-5.5.21-1.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-06 20:26:01 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Tom Lane 2012-02-11 01:43:19 UTC
Description of problem:
Running the packaged mysql tests (mysql-test RPM) per directions fails with

main.mysql_plugin                        [ fail ]
        Test ended at 2012-02-10 20:33:07

CURRENT_TEST: main.mysql_plugin
120211  4:32:54 [ERROR] Can't find messagefile '/usr/libexec/share/mysql/errmsg.sys'

which of course is not where the errmsg.sys file lives in our packaging.  This works when the same test is run during RPM build, so it seems to be a context issue?

Version-Release number of selected component (if applicable):
mysql-test-5.5.20-2.fc16.x86_64

Comment 1 Honza Horak 2012-02-22 16:15:52 UTC
This is what actually happens: The mentioned test tries to copy errmsg.sys file from original place /usr/share/mysql/english/errmsg.sys to a new path /usr/libexec/share/mysql. This copying doesn't succeed, but the error is silently ignored, because --disable_abort_on_error is set in the test. If run as root, the test succeeds.

During build, it is not run as root, but the building process has all needed privileges to write to /usr/libexec/share/mysql in the buildroot, so the test passes during build too. 

There is already a verified upstream bug report at [1] with a patch that seems to work fine. Since the upstream MySQL-test rpm behaves the same, it could be fixed soon.

[1] http://bugs.mysql.com/bug.php?id=62907

Comment 2 Tom Lane 2012-02-22 16:29:53 UTC
Good detective work!

I see there's a 5.5.21 release already, so when I have time to package that, I'll include that patch.

Comment 3 Tom Lane 2012-02-27 07:11:22 UTC
Hmm, there's still more bit-rot here:

main.file_contents                       [ fail ]
        Test ended at 2012-02-27 01:59:01

CURRENT_TEST: main.file_contents
--- /usr/share/mysql-test/r/file_contents.result        2012-01-31 14:28:16.000000000 +0300
+++ /usr/share/mysql-test/r/file_contents.reject        2012-02-27 09:59:01.416251724 +0300
@@ -1,6 +1,8 @@
 
 Checking 'INFO_SRC' and 'INFO_BIN'
-INFO_SRC: Found MySQL version number / Found BZR revision id
-INFO_BIN: Found 'Compiler ... used' line / Found 'Feature flags' line
+Cannot open 'INFO_SRC' in '' (starting from bindir '/usr')
+INFO_SRC: No line 'MySQL source #.#.#' / No line 'revision-id: .....'
+Cannot open 'INFO_BIN' in '' (starting from bindir '/usr')
+INFO_BIN: No line about compiler information / No line 'Feature flags'
 
 End of tests

mysqltest: Result length mismatch

Comment 4 Honza Horak 2012-02-27 11:50:02 UTC
(In reply to comment #3)
> Hmm, there's still more bit-rot here:
> 
> main.file_contents                       [ fail ]
>         Test ended at 2012-02-27 01:59:01

This is also a reported bug:
http://bugs.mysql.com/bug.php?id=61425

The test-case doesn't seem very healthy and I've attached a minimal working patch there. It'll basically behave same during development as well as run manually (at least in case of Fedora). 

I was wondering why the test passed during development and it showed up, that the test went through M$ windows path and coincidentally found INFO_BIN and INFO_SRC files there.

Besides patching the main.file_contents test, we should pack the following two files:
mysql-5.5.20/Docs/INFO_BIN
mysql-5.5.20/Docs/INFO_SRC
into mysql-server under /usr/share/doc/mysql-server-5.5.20/INFO_*

Comment 5 Tom Lane 2012-02-28 04:44:58 UTC
Hmm ... those files absolutely don't belong under /usr/share/doc --- see the comments I added to the upstream bug report.  I've hacked up a temporary solution, but it'd be better if the mysql-test-run environment had an explicit idea of where the installation libdir is.

Anyway, as of the 5.5.21-1 build this is working again for me, though there's a lot of ugliness buried in those patches.  We'll see whether upstream cares about cleaning it up.

Comment 6 Fedora Update System 2012-02-28 05:46:39 UTC
mysql-5.5.21-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/mysql-5.5.21-1.fc16

Comment 7 Fedora Update System 2012-02-28 05:46:50 UTC
mysql-5.5.21-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/mysql-5.5.21-1.fc15

Comment 8 Fedora Update System 2012-02-28 05:46:59 UTC
mysql-5.5.21-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/mysql-5.5.21-1.fc17

Comment 9 Fedora Update System 2012-02-28 20:40:08 UTC
Package mysql-5.5.21-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing mysql-5.5.21-1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-2613/mysql-5.5.21-1.fc17
then log in and leave karma (feedback).

Comment 10 Fedora Update System 2012-03-06 20:26:01 UTC
mysql-5.5.21-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Fedora Update System 2012-03-17 23:42:05 UTC
mysql-5.5.21-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 12 Fedora Update System 2012-03-17 23:48:43 UTC
mysql-5.5.21-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.


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