Bug #61425 Test suite run fails on the main.file_contents test case
Submitted: 6 Jun 2011 16:29 Modified: 11 Jun 2011 8:11
Reporter: Naveen Shetty Email Updates:
Status: Verified Impact on me:
Category:Tests Severity:S3 (Non-critical)
Version:5.5.12 OS:Linux (CentOS 5.5 i386 32bit (Final))
Assigned to: CPU Architecture:Any
Tags: main.file_contents, test suite failure on centOS 5.5

[6 Jun 2011 16:29] Naveen Shetty
We are getting the following error when the test suite is run on our install of the MySQL. 
main.explain                             [ pass ]    216
main.file_contents                       [ fail ]
        Test ended at 2011-05-24 18:23:00

CURRENT_TEST: main.file_contents
--- /usr/local/mysql-5.5.12/mysql-test/r/file_contents.result   2011-04-11 13:44:01.000000000 +0300
+++ /usr/local/mysql-5.5.12/mysql-test/r/file_contents.reject   2011-05-25 01:23:00.000000000 +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/local/mysql-5.5.12')
+INFO_SRC: No line 'MySQL source #.#.#' / No line 'revision-id: .....'
+Cannot open 'INFO_BIN' in '' (starting from bindir '/usr/local/mysql-5.5.12')
+INFO_BIN: No line about compiler information / No line 'Feature flags'
 End of tests

mysqltest: Result length mismatch

 - saving '/usr/local/mysql-5.5.12/mysql-test/var/log/main.file_contents/' to '/usr/local/mysql-5.5.12/mysql-test/var/log/main.file_contents/'

Only  1249  of 2141 completed.
mysql-test-run: *** ERROR: Not all tests completed


The details mentioned above are the final lines of the logs printed on screen.
When we ran the test suite again (forcing the suite to continue on failure) we noticed that this is the only test case that fails.  

How to repeat:
These are the environment details:
User, used for the compile, make, install and test-suite run: root
S/w versions:
Centos 5.5 (32bit Final)
CMake 2.8.4
GCC (C++) 4.4 (preview version) (4.1.2 packaged along with CentOS didn't work)
GNU Make 3.81

Install directories:
/usr/local/mysql - compiled binaries were added with the normal structure under this folder
/usr/local/mysql-5.5.12 - the source code is here

Here are the details for re-creation of the error:
1. Download the code to the folder structure mentioned.
2. Run 'cmake .' in the /usr/local/mysql-5.5.12 directory
3. On success run 'make .'
4. On success run 'make install'
5. On Run the test suite by going to the /usr/local/mysql/mysql-test folder and running the command './mtr'. Alternatively you could run the test case that failed alone, the results should be the same as we got the same error even then. Here is the command we used './mtr main.file_contents'.

Suggested fix:
The test script identifies the OS and then searches for the docs folder after making a search for the 'MySQL-server' folder. I am assuming that the pattern being searched is not the correct one especially for Centos 5.5.
[9 Jun 2011 21:39] Naveen Shetty
I am updating the status of the bug as it is leads to Test Suite failure on CentOS 5.5.
[11 Jun 2011 8:11] Sveta Smirnova
Thank you for the report.

Verified as described.
[27 Feb 2012 10:01] Honza Horak
This issue is happening also in Fedora. 

First, I wonder what correct value of MYSQL_BINDIR environment variable should be. I see it is '/usr' currently, which fails in the first match test:
$dir_bin =~ m|/usr/|
Is '/usr' right?

Later then, $dir_docs is not /usr/share/doc as it probably supposes to be, but it is still '/usr', because a substitution s|/lib|/share/doc| is a no-op, since $dir_bin doesn't contain '/lib' at all.

Second, there is a "Red Hat part", which doesn't actually correspond with the way, how docs are packaged in Fedora. It supposes to have $dir_docs/MySQL-server*, but docs are in $dir_docs/mysql-server* in Fedora. 

The following is a minimal patch, that fixes the testcase in Fedora and shouldn't influence other distros:

--- mysql-5.5.20/mysql-test/t/file_contents.test.fixpath	2012-02-27 10:34:23.847382472 +0100
+++ mysql-5.5.20/mysql-test/t/file_contents.test	2012-02-27 10:34:52.157028555 +0100
@@ -11,7 +11,7 @@
 print "\nChecking 'INFO_SRC' and 'INFO_BIN'\n";
 $dir_bin = $ENV{'MYSQL_BINDIR'};
-if ($dir_bin =~ m|/usr/|) {
+if ($dir_bin =~ m|/usr|) {
   # RPM package
   $dir_docs = $dir_bin;
   $dir_docs =~ s|/lib|/share/doc|;
@@ -20,7 +20,8 @@ if ($dir_bin =~ m|/usr/|) {
     $dir_docs = glob "$dir_docs/packages/MySQL-server*";
   } else {
     # RedHat: version number in directory name
-    $dir_docs = glob "$dir_docs/MySQL-server*";
+    $dir_docs = "$dir_bin/share/doc";
+    $dir_docs = glob "$dir_docs/mysql-server*";
 } elsif ($dir_bin =~ m|/usr$|) {
   # RPM build during development
[28 Feb 2012 2:50] [ name withheld ]
The issue for the Fedora RPMs is first that we weren't installing INFO_SRC
or INFO_BIN at all, and second that if we had been, they'd be in
/usr/share/mysql-server-something not /usr/share/MySQL-server-something.
However, I don't think that we should undertake a discussion of how to dodge
that package naming difference, because the real problem with this is that
putting these files in %doc violates multiple packaging guidelines.  In the
first place, %doc is only supposed to contain files that are documentation,
ie are not actually needed for the software to function.  If the regression
tests fail without them, they don't belong in %doc.  In the second place,
files in /usr/share/doc must be architecture-independent, and the INFO_BIN
file clearly is not.  So multilib installations would fail if we do it this way.

AFAICS the sanest place to put INFO_BIN is /usr/lib(64)/mysql/.  There's some
room for argument about INFO_SRC, but seems best to keep it beside INFO_BIN.
So for the moment I'm changing the Fedora RPMs to install these two files
there, and patching the file_contents test to look there.  It's a pretty ugly
patch though, because I can't find that the mtr environment provides any
guidance on where the installation library directory is.  Perhaps that could
be improved in the future?  This is related to bug #52223, which shows that
there's another test that would really like access to the correct value of