libdbd-mysql-perl: FTBFS against mariadb-10.3 1:10.3.13-1

[gregoa]

We have the following bug reported to the Debian package of DBD-mysql, c.f. https://bugs.debian.org/923541

It doesn't seem to be a bug in the packaging, so you may want to take a look. Thanks!

AFAICS, DBD-mysql is tested against all kinds of MySQL and MariaDB versions on travis but apparently not against 10.3.13. Maybe this explains why this issue hasn't popped up there yet.

------8<-----------8<-----------8<-----------8<-----------8<-----

Source: libdbd-mysql-perl
Version: 4.050-1
Severity: serious
Tags: upstream ftbfs sid
Justification: fails to build from source (but built successfully in the past)

This is already discussed in
https://lists.debian.org/debian-perl/2019/02/msg00026.html
but filing it as a bug:

libdbd-mysql-perl fails its tests with

t/rt118977-zerofill.t ................... 
1..8
ok 1
ok 2
ok 3
ok 4
ok 5
ok 6
ok 7
not ok 8
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/8 subtests 

when built against mariadb-10.3 1:10.3.13-1.

This looks like #917303 which was fixed in 4.050-1 and this fix
worked with mariadb-10.3 1:10.3.12-2. Seems that there is a change in
mariadb between 10.3.12 and 10.3.13 which breaks the test again.


Cheers,
gregor

------8<-----------8<-----------8<-----------8<-----------8<-----

Thanks for considering, gregor herrmann, Debian Perl Group

[dveeden]

Hi, Thanks for reporting this. I'll look into this and post an update either today or tomorrow.

[dveeden]

I've isolated the change in behaviour in 10.3.13 and I'm working on a fix.

[gregoa]

On Tue, 05 Mar 2019 08:29:45 +0000, Daniël van Eeden wrote:

I've isolated the change in behaviour in 10.3.13 and I'm working on a fix.

That's great news, thank you very much!

[dveeden]

Reported this to MariaDB: https://jira.mariadb.org/browse/MDEV-18823

[dveeden]

The new 10.4 I added to the Travis tests breaks because this issue: https://github.com/datacharmer/dbdeployer/issues/67

I'll wait with adding 10.4.3 to Travis until this has been fixed. This will be handled in another issues and PR

[dveeden]

With v5.x DBD::mysql requires MySQL 8.x for building (which can still be used to connect to a MariaDB Server), so closing this issue now.

[gregoa]

That's a bit unfortunate … There is no MySQL in Debian since a couple of years (in the released/stable version, it's still in unstable for some reason). That means we'd have to scrap DBD-mysql as well; and I guess this will make many people unhappy.

[dveeden]

There are some options for now:

• Keep using DBD::mysql v4.x until a next stable version with MySQL gets released.
• Use the MySQL APT Repository (see Dockerfile for an example)

The reason for this is that MySQL and MariaDB have diverged. Both are fine options, but supporting both in the same code base is adding complexity. Even without this there are already many open issues that have accumulated over the past years that need to be addressed.

[dveeden]

Actually... I'll reopen this and will try to fix this for the v4 branch. Would that be ok?

[dveeden]

I tried the following. So the issue is the failing test for zerofill right (issue description and test match)?

docker -it debian:bookworm

# Add `deb-src` to /etc/apt/sources.list.d/debian.sources
apt-get update
apt-get build-dep libdbd-mysql-perl
apt-get install cpanminus
cd
cpanm DVEEDEN/DBD-mysql-4.051.tar.gz

apt-get install git
git clone https://github.com/perl5-dbi/DBD-mysql.git
cd DBD-mysql
git checkout v4
perl Makefile.PL
make
make test
# Result: PASS


mkdir /run/mysqld 
chown mysql /run/mysqld
/usr/sbin/mariadbd --user mysql &
make test

# Fails on t/rt118977-zerofill.t

[dveeden]

use v5.36;
use Data::Dumper;
use DBI;

my $dbh = DBI->connect('DBI:mysql:database=test', undef, undef);

my $res;
for my $mysql_server_prepare (0, 1) {
	say "Using mysql_server_prepare=$mysql_server_prepare";
	$dbh->{mysql_server_prepare} = $mysql_server_prepare;
	$dbh->do("DROP TABLE IF EXISTS t");
	$dbh->do("CREATE TEMPORARY TABLE t(id smallint(5) unsigned zerofill)");
	$dbh->do("INSERT INTO t(id) VALUES(1)");
	$res = $dbh->selectcol_arrayref("SELECT id FROM t")->[0];
	print Dumper($res);
}

Shows this:

Using mysql_server_prepare=0
$VAR1 = '00001';
Using mysql_server_prepare=1
$VAR1 = '1';

So this is related to prepared statements.

[dveeden]

@gregoa could you check the patch in #398 ?

[gregoa]

Sorry for being a bit too terse last night; the original bug is already fixed with your #308 from 2019. I meant to react to your statement "DBD-mysql 5.x won't build against MariaDB" (both here and in #308) as this means we won't be able to update DBD-mysql in Debian.

[dveeden]

Yes. For now Debian is constrained to update to v4.x and not v5.x.

If Debian wants DBD::mysql v5 then MySQL 8.x would be required. I would suggest to keep DBD::mysql as v4.x in Debian for now.