the same with on ubuntu 12.04:

Scanning dependencies of target test-force

make[4]: Выход из каталога `/tmp/mariadb-5.5-5.5.35+maria/builddir'

make[4]: Вход в каталог `/tmp/mariadb-5.5-5.5.35+maria/builddir'

Running tests

OS=Linux

Logging: ./mysql-test-run.pl  --force

vardir: /tmp/mariadb-5.5-5.5.35+maria/builddir/mysql-test/var

Removing old var directory...

Creating var directory '/tmp/mariadb-5.5-5.5.35+maria/builddir/mysql-test/var'...

Checking supported features...

** ERROR: Could not find '*' in 

 at lib/mtr_cases.pm line 339

make[4]: *** [mysql-test/CMakeFiles/test-force] Ошибка 2

make[4]: Выход из каталога `/tmp/mariadb-5.5-5.5.35+maria/builddir'

make[3]: *** [mysql-test/CMakeFiles/test-force.dir/all] Ошибка 2

make[3]: Выход из каталога `/tmp/mariadb-5.5-5.5.35+maria/builddir'

make[2]: *** [mysql-test/CMakeFiles/test-force.dir/rule] Ошибка 2

make[2]: Выход из каталога `/tmp/mariadb-5.5-5.5.35+maria/builddir'

make[1]: *** [test-force] Ошибка 2

make[1]: Выход из каталога `/tmp/mariadb-5.5-5.5.35+maria/builddir'

make: *** [build-stamp] Ошибка 1

dpkg-buildpackage: ошибка: debian/rules build возвратил код ошибки 2

Also reported by Otto on IRC last night.
Reproduced by running dpkg-buildpackage, will look into it to see what's going on.

The reason of this failure (and why it is not reproducible with a manual out-of-source build) is that during package building some additional "magic" is performed, namely mysql-test datadir is copied into the builddir. It causes the glob_mysql_test_dir to be set to <basedir>/builddir/mysql-test rather than <basedir>/mysql-test as it should.
Further, this value is used to expand paths to look for plugin/storage engine tests. Instead of looking for mysql-test dirs in <basedir>/storage/<engine>/, MTR goes to <basedir>/builddir/storage/<engine>/ dirs, which don't contain mysql-test.

And why, exactly, dpkg-buildpackage does this kind of a thing?

That's a very good question. The comment in the rules file says, and I quote:

        # Don't know why the following is necessary...

        cp unittest/unit.pl $(builddir)/unittest/

       cp -r mysql-test/* $(builddir)/mysql-test/

        cp -r sql/share/* $(builddir)/sql/share/

        cp -r scripts/*sql $(builddir)/scripts/

        if [ ! -f testsuite-stamp ] ; then \

I tried to remove cp -r mysql-test and it seemed at least start working, I will now try a clean build from scratch, but without this copy command.

I see. I suspect that a long time ago in a galaxy far, far away, mtr couldn't work from out-of-source builds. And this rule was added. Perhaps even in pre-cmake era.

I don't think any of this copying is needed, please, try to remove as much of that as possible.

I removed all 4 and didn't have a problem with the build, at least on my machine. I'm not sure that it won't backfire, so sent a email to maria-developers list asking for public opinion: https://lists.launchpad.net/maria-developers/msg06728.html.

It looks like there is also a cowardly solution:

=== modified file 'mysql-test/lib/mtr_cases.pm'

--- mysql-test/lib/mtr_cases.pm	2013-11-27 20:58:47 +0000

+++ mysql-test/lib/mtr_cases.pm	2014-01-30 18:40:26 +0000

@@ -337,7 +337,7 @@

 sub collect_default_suites(@)

 {

   my @dirs = my_find_dir(dirname($::glob_mysql_test_dir),

-                         [ @plugin_suitedirs ], '*');

+                         [ @plugin_suitedirs ], '*', NOT_REQUIRED);

   for my $d (@dirs) {

     next unless -f "$d/suite.pm";

     my $sname= basename($d);

How come 5.5.34 built fine while debian/rules was identical to that from 5.5.35? It seems that the changes to lib/mtr_cases.pm are the primary cause of the problem.

>> It seems that the changes to lib/mtr_cases.pm are the primary cause of the problem.

They are not the cause of the problem per se, they just made the problem surface.

hint with "+ [ @plugin_suitedirs ], '*', NOT_REQUIRED);"
solves error for me

It passes the tests after removing the four lines under "# Don't know why the following is necessary..." as well for me. It's worth mentioning that they were indeed necessary in 5.5.34, but apparently they aren't any longer.

By the way is it only me that gets "MTR's internal check of the test case 'rpl.rpl_ddl' failed." ? It does not make the test fail, but still it's something abnormal.

not only you.

In 5.5.35 MTR's internal check started to take into account temporary tables on the slave — that's why this warning started to appear. But as it doesn't fail the test and doesn't mean any real problem (temporary tables are dropped automatically anyway), it wasn't a priority for 5.5.35 release.

(hint: you can always check http://buildbot.askmonty.org/buildbot/ to see whether a problem is universally repeatable to specific to your environment)

I applied the patch by elenst in https://github.com/ottok/mariadb-5.5/commit/73eea9f but unfortunately the tests still fail with
Failing test(s): plugins.unix_socket

Build log at http://labs.seravo.fi/~otto/mariadb-repo/precise-amd64/mariadb-5.5_5.5.35-1_amd64.build-73eea9f-pbuilder.log

Right, this is a totally different problem from the one that https://github.com/ottok/mariadb-5.5/commit/73eea9f was solving.
The patch was to skip the test if the $USER variable is undefined, which was happening in one of the builds.
Now what is happening is that the datadir apparently contains <username>@localhost user which is not supposed to be there.
I will look into this one next.

Maybe the tile for this bug report should be "Debian builds of 5.5.35 failing due to test failures".

About the original '** ERROR: Could not find '*' in at lib/mtr_cases.pm line 339' issue:

It was visible in all previous builds before https://github.com/ottok/mariadb-5.5/commit/73eea9f and hasn't been visible since. If you don't see any regressions in the build logs (many links below) then the issue is fixed.

About the replace_result and $USER issue:

All tests now pass on my laptop in the latest run: http://labs.seravo.fi/~otto/mariadb-repo/logs/mariadb-5.5_5.5.35-1_amd64.build-a82d59a-laptop.log
The rpl.rpl_set_null_innodb fail I had yesterday on the laptop went away with no fixes, I assume it was a sporadic fail, I have seen it only ever once.

About the unix_socket issue:

When disabling tests I was able to build binary packages at http://labs.seravo.fi/~otto/mariadb-repo/?C=M;O=D for amd64: precise, trusty, wheezy, sid and for i386: precise. The other i386 fails due to TokuDB which does not build under i386 and pbuilder environment where the cmake if CMAKE_SYSTEM_PROCESSOR=amd64 does not detect pbuilder target processor correctly. I will now relaunch all of these to confirm that unix_socket issue is consistent (and not sporadic). If it helps, at least there are now binaries for the same revision which you can download and run the mariadb-test suite for binaries.

About TokuDB tests:

At https://launchpad.net/~mysql-ubuntu/+archive/mariadb/+packages (all builds at https://launchpad.net/~mysql-ubuntu/+archive/mariadb/+builds?build_text=&build_state=all) I have built successfully binary packages for precise and trusty when tests where disabled. When tests are enabled and I submitted saucy version for building, the i386 passes all tests and is successfull but the amd64 version fails in tokudb tests: https://launchpadlibrarian.net/164958444/buildlog_ubuntu-saucy-amd64.mariadb-5.5_5.5.35-1~saucy1~ppa2_FAILEDTOBUILD.txt.gz

This seems consistent for Launchpad (buildd) and is visible in a previous trusty/amd64 build too but not in my plain laptop or in pbuilder.

Maybe the tile for this bug report should be "Debian builds of 5.5.35 failing due to test failures".

This bug report was created by its author specifically about "** ERROR: Could not find '*' in" failure, and will stay as such.
The fix for it is removal of extra copying from debian/dist/*/rules. Upon your request, I did not push it to 5.5 tree, it's waiting for the batch of your changes.
The fix has been pushed to 10.0 tree here: http://bazaar.launchpad.net/~maria-captains/maria/10.0/revision/3975
The bug report will now be closed.
Other failures, if they need to be fixed on MariaDB side, should be filed separately.

About the original '** ERROR: Could not find '*' in at lib/mtr_cases.pm line 339' issue:
It was visible in all previous builds before https://github.com/ottok/mariadb-5.5/commit/73eea9f and hasn't been visible since. If you don't see any regressions in the build logs (many links below) then the issue is fixed.

No, the failure "ERROR: Could not find '*' in" has nothing to do with the change in unix_socket file. Maybe you pasted a wrong link.

About the replace_result and $USER issue:
All tests now pass on my laptop in the latest run: http://labs.seravo.fi/~otto/mariadb-repo/logs/mariadb-5.5_5.5.35-1_amd64.build-a82d59a-laptop.log

This failure was fixed by the change https://github.com/ottok/mariadb-5.5/commit/73eea9f.
It will be pushed to maria/5.5 tree and merged up to 10.0 tree.

The fix with removal of cp lines was pushed to 10.0 tree:
http://bazaar.launchpad.net/~maria-captains/maria/10.0/revision/3975

5.5 tree should be fixed separately by upcoming Otto's changes.

same on 5.5.36

That's expected, as said in the comment (and in the Fix Versions field), the fix was only pushed in 10.0, while 5.5 is awaiting package refactoring which is currently being performed.