mysql-server FTBFS (focal) because of build tests

PROBLEM #1:

https://bugs.mysql.com/bug.php?id=98152
https://bugs.mysql.com/bug.php?id=98107

I think we reached the hard coded date on the test =). That part of the test was created by:

commit c60397ef198
Author: anozdrin/alik@station. <>
Date: Fri Oct 19 15:57:08 2007

    Patch for BUG#31111: --read-only crashes MySQL (events fail to load).

In 2007 =).

Changing 2020-01-01 to 2030-01-01 will likely make the issue to go away.

----

Bug comment says this was already changed in version 8.0.20:

"""
[3 Jan 13:47] Paul Dubois
Posted by developer:

Fixed in 5.6.48, 5.7.30, 8.0.20.

Work was done for test suite. No changelog entry needed.
"""

But they haven't released commits in github for the last two versions (not GA yet): 8.0.19 and 8.0.20. With that, we will have to go with a generic fix, keeping the delta until their upstream fix is available!

Problem 2 is an intermittent problem:

(PROBLEM #2)

CURRENT_TEST: main.subquery_sj_mat_bka

--- /home/rafaeldtinoco/work/sources/general/ubuntu/mysql-8.0-8.0.18/mysql-test/r/subquery_sj_mat_bka.result 2019-09-20 11:30:51.000000000 +0300
+++ /home/rafaeldtinoco/work/sources/general/ubuntu/mysql-8.0-8.0.18/builddir/mysql-test/var/9/log/subquery_sj_mat_bka.reject 2020-01-09 19:54:09.659290415 +0300
@@ -12800,10 +12800,10 @@
             -> Hash
                 -> Table scan on <subquery2>
                     -> Materialize with deduplication
- -> Filter: (t1.col_int_key is not null) (cost=3.40 rows=7)
- -> Filter: (t3.col_int is null) (cost=3.40 rows=7)
- -> Nested loop left join (cost=3.40 rows=7)
- -> Index scan on t1 using col_int_key (cost=0.95 rows=7)
+ -> Filter: (t1.col_int_key is not null) (cost=4.15 rows=7)
+ -> Filter: (t3.col_int is null) (cost=4.15 rows=7)
+ -> Nested loop left join (cost=4.15 rows=7)
+ -> Index scan on t1 using col_int_key (cost=1.70 rows=7)

This test calculates the cost of a query with BKA (Batched Key Access) feature enabled:

"""
set optimizer_switch='batched_key_access=on,mrr_cost_based=off';

--source t/subquery_sj_mat.test

set optimizer_switch=default;
"""

explain format=tree SELECT * FROM t4 WHERE (col_int_key) IN ( SELECT t1.col_int_key FROM t1 LEFT JOIN ( t2 JOIN t3 ON t3.col_int_key = t2.col_int ) USING ( pk ) WHERE t3.col_int IS NULL) ORDER BY col_int_key;

And it looks like optimizer switching makes test to have different costs sometimes. Nevertheless, after fixing (PROBLEM #1) I was able to fully build MySQL Server binary packages without triggering (PROBLEM #2).

dpkg-deb: building package 'mysql-server' in '../mysql-server_8.0.18-0ubuntu4_all.deb'.
dpkg-deb: building package 'mysql-testsuite-8.0' in '../mysql-testsuite-8.0_8.0.18-0ubuntu4_amd64.deb'.
dpkg-deb: building package 'mysql-source-8.0' in '../mysql-source-8.0_8.0.18-0ubuntu4_amd64.deb'.
dpkg-deb: building package 'mysql-client' in '../mysql-client_8.0.18-0ubuntu4_all.deb'.
dpkg-deb: building package 'mysql-testsuite' in '../mysql-testsuite_8.0.18-0ubuntu4_all.deb'.
dpkg-deb: building package 'mysql-router' in '../mysql-router_8.0.18-0ubuntu4_amd64.deb'.
dpkg-deb: building package 'mysql-server-8.0' in '../mysql-server-8.0_8.0.18-0ubuntu4_amd64.deb'.

Lars,

not sure how to propose this to Debian.

Would you mind pointing me out or merging those 2 debdiffs yourself ?

Eduardo,

There is a working PPA for you to check this out if you want:

https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1859100/+packages

before the merge is done.

You can also grab the debdiffs and apply to the version's you're using to test out the mysql-router MIR.

Thank you for pointing this issue out!

Eduardo,

@xnox has uploaded a diff patch for same issue here:

https://launchpad.net/ubuntu/+source/mysql-8.0/8.0.18-0ubuntu5

Thanks, I will try to test or at least let the build running on xnox's proposed mysql version.

2025 is too close for comfort for me, given that focal will have 10 years of support.

I picked 2037, as it's pre-32bit-end-of-time.

Stumbled onto this due to regressions raised by autopkgtests from my openssl upload.

On Thu, Jan 16, 2020 at 8:11 AM Dimitri John Ledkov
<email address hidden> wrote:
>
> 2025 is too close for comfort for me, given that focal will have 10
> years of support.

From the public bug:

https://bugs.mysql.com/bug.php?id=98152
https://bugs.mysql.com/bug.php?id=98107

This patch will be replaced when merging anything >= 8.0.20, thus the
closer date.
From upstream comments, hard coded dates are to be replaced by generic
DATE()+X format.

> I picked 2037, as it's pre-32bit-end-of-time.

Nice thought, didn't occur to me!

> Stumbled onto this due to regressions raised by autopkgtests from my
> openssl upload.

Looks like some builds are still failing for security tests, with the
uploaded patch:

https://pastebin.canonical.com/p/RZc57ZpVPq/

Running with "nocheck" still runs upstream build tests.

Following PPA contained code from the merge request:

https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1859100/+packages

and all tests passed :\.

I haven't changed the 20200101000000 entries as they were issuing
other errors - then date - on purpose and the return code type was
being checked (had some issues when changed them all). So I guess some
tests might fail randomly unless LP builders are not running the tests
at all.

I'll recheck.

I have just uploaded mysql-8.0_8.0.19-0ubuntu3 containing fixes for the 2020 year in mysql tests. I'll flag this as Fix Committed and Fix Released manually as only LP: #1862364 was referred in that changelog.

Related bugs:

https://bugs.launchpad.net/ubuntu/+source/mysql-8.0/+bug/1862364
https://bugs.launchpad.net/ubuntu/+source/mysql-8.0/+bug/1862770