Skip Menu |

This queue is for tickets about the DBD-mysql CPAN distribution.

Report information
The Basics
Id: 118823
Status: resolved
Priority: 0/
Queue: DBD-mysql

People
Owner: MICHIELB [...] cpan.org
Requestors: gregoa [...] cpan.org
Cc: pali [...] cpan.org
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



From: gregoa [...] cpan.org
Subject: libdbd-mysql-perl: FTBFS on some architectures
We have the following bug reported to the Debian package of DBD-mysql (https://bugs.debian.org/844538): It doesn't seem to be a bug in the packaging, so you may want to take a look. Thanks! ------8<-----------8<-----------8<-----------8<-----------8<----- Source: libdbd-mysql-perl Version: 4.039-1 Severity: serious Justification: FTBFS on some release architectures Hi libdbd-mysql-perl FTBFS on some architectures, namely mips and s390x for the release architectures: https://buildd.debian.org/status/package.php?p=libdbd-mysql-perl https://buildd.debian.org/status/fetch.php?pkg=libdbd-mysql-perl&arch=mips&ver=4.039-1&stamp=1479285659 https://buildd.debian.org/status/fetch.php?pkg=libdbd-mysql-perl&arch=s390x&ver=4.039-1&stamp=1479285790 Regards, Salvatore ------8<-----------8<-----------8<-----------8<-----------8<----- Thanks for considering, gregor herrmann, Debian Perl Group
Hi there, On Thu 17 Nov 2016 15:22:34, GREGOA wrote: Show quoted text
> We have the following bug reported to the Debian package of DBD-mysql > (https://bugs.debian.org/844538): > > Source: libdbd-mysql-perl > Version: 4.039-1 > Severity: serious > Justification: FTBFS on some release architectures
Sorry for the breakage! Is there any *easy* way for me to spin up a MIPS instance on an x86 system? I tried once before and it was not a pleasant experience, mucking around with QEMU. I guess as Debian package maintainers, you'd have some way to easily emulate these environments, right? It would make things much easier for us to test any patches and not cause breakage the next time around. I even tried looking for buying a MIPS development board but while ARM boards are REALLY cheap, there aren't a lot of MIPS boards and I could not find one that ships to The Netherlands for < $200. Any advise would be welcome! -- Michiel
CC: debian-perl [...] lists.debian.org
Subject: Re: [rt.cpan.org #118823] libdbd-mysql-perl: FTBFS on some architectures
Date: Fri, 18 Nov 2016 01:45:59 +0100
To: Michiel Beijen via RT <bug-DBD-mysql [...] rt.cpan.org>
From: gregor herrmann <gregoa [...] debian.org>
On Thu, 17 Nov 2016 15:59:15 -0500, Michiel Beijen via RT wrote: Show quoted text
Show quoted text
> On Thu 17 Nov 2016 15:22:34, GREGOA wrote:
> > We have the following bug reported to the Debian package of DBD-mysql > > (https://bugs.debian.org/844538):
Show quoted text
> Is there any *easy* way for me to spin up a MIPS instance on an x86 > system? I tried once before and it was not a pleasant experience, > mucking around with QEMU. I guess as Debian package maintainers, > you'd have some way to easily emulate these environments, right? It > would make things much easier for us to test any patches and not > cause breakage the next time around.
I'm afraid I also only know about qemu for emulating mips systems on x86. But we have access to porter boxes of all architectures, so I could try a build with a patch. But as https://buildd.debian.org/status/package.php?p=libdbd-mysql-perl shows this is not only about mips but about various architectures, and the quick summary on IRC was "looks like a big-endian issue". Maybe this makes it easier? There was also an offer of a Debian Perl member to try and check on a powerpc machine of his (where it also fails); cc'ing our list for further cooperation. Thanks for attending to this issue so quickly! Cheers, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Joan Baez: A hard rain's a-gonna fall
Download signature.asc
application/pgp-signature 963b

Message body not shown because it is not plain text.

Subject: Re: [rt.cpan.org #118823] libdbd-mysql-perl: FTBFS on some architectures
Date: Fri, 18 Nov 2016 08:31:20 +0100
To: Michiel Beijen via RT <bug-DBD-mysql [...] rt.cpan.org>, debian-perl [...] lists.debian.org
From: Michiel Beijen <michiel.beijen [...] gmail.com>
Hi, On Fri, Nov 18, 2016 at 1:45 AM, gregor herrmann <gregoa@debian.org> wrote: Show quoted text
> I'm afraid I also only know about qemu for emulating mips systems on > x86. But we have access to porter boxes of all architectures, so I > could try a build with a patch. > > But as https://buildd.debian.org/status/package.php?p=libdbd-mysql-perl > shows this is not only about mips but about various architectures, > and the quick summary on IRC was "looks like a big-endian issue". > Maybe this makes it easier?
Yeah, I know it's an endianness issue. But I also know emulating s390 is not a thing, and there is someone building a Power-based raspberry-pi-like board but that has not launched and they ask lots of money for it. So far it seems emulating MIPS on my Intel-based laptop is the easiest way. I hope some of your packaging colleagues have some tips! -- Michiel
CC: Michiel Beijen <michiel.beijen [...] gmail.com>, Michiel Beijen via RT <bug-DBD-mysql [...] rt.cpan.org>
Subject: Re: [rt.cpan.org #118823] libdbd-mysql-perl: FTBFS on some architectures
Date: Fri, 18 Nov 2016 08:54:19 +0100
To: debian-perl [...] lists.debian.org
From: Dominique Dumont <dod [...] debian.org>
On Friday, 18 November 2016 08:31:20 CET Michiel Beijen wrote: Show quoted text
> So far it seems emulating MIPS on my Intel-based laptop > is the easiest way. I hope some of your packaging colleagues have some > tips!
You can create a mips chroot (which uses qemu under the hood) with debootstrap. You can follow the installation instructions given there, using mips instead of arm64: https://wiki.debian.org/Arm64Qemu This setup was used to work on porting moarvm on mips. Please get back to us if you face problems. All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Subject: Re: [rt.cpan.org #118823] libdbd-mysql-perl: FTBFS on some architectures
Date: Fri, 18 Nov 2016 11:26:19 +0200
To: Michiel Beijen via RT <bug-DBD-mysql [...] rt.cpan.org>, debian-perl [...] lists.debian.org
From: Niko Tyni <ntyni [...] debian.org>
On Fri, Nov 18, 2016 at 01:45:59AM +0100, gregor herrmann wrote: Show quoted text
> But as https://buildd.debian.org/status/package.php?p=libdbd-mysql-perl > shows this is not only about mips but about various architectures, > and the quick summary on IRC was "looks like a big-endian issue".
FWIW it goes away if I revert 97c8c22998e67e7c6cfe5635578e0464e9ac9513 ("Add support for 64bit types when perl is compiled with 64bit support"). We're configuring Perl with -Duse64bitint on both 32-bit and 64-bit platforms. I think the 64-bit integer support is not quite working yet; even on little-endian (regular x86_64), if I test for them: --- a/t/40server_prepare.t +++ b/t/40server_prepare.t @@ -59,11 +59,11 @@ ok($sth2 = $dbh->prepare('INSERT INTO dbd_mysql_t40serverprepare2 VALUES (?,?,?, ok($sth2->bind_param(1, 101, DBI::SQL_INTEGER), "binding int"); ok($sth2->bind_param(2, 102, DBI::SQL_SMALLINT), "binding smallint"); ok($sth2->bind_param(3, 103, DBI::SQL_TINYINT), "binding tinyint"); -ok($sth2->bind_param(4, 104, DBI::SQL_INTEGER), "binding bigint"); +ok($sth2->bind_param(4, (2<<32)+4, DBI::SQL_INTEGER), "binding bigint"); ok($sth2->execute(), "inserting data"); -is_deeply($dbh->selectall_arrayref('SELECT * FROM dbd_mysql_t40serverprepare2'), [[101, 102, 103, 104]]); +is_deeply($dbh->selectall_arrayref('SELECT * FROM dbd_mysql_t40serverprepare2'), [[101, 102, 103, (2<<32)+4]]); ok ($dbh->do(qq{DROP TABLE dbd_mysql_t40serverprepare2}), "cleaning up"); I get not ok 20 # Failed test at t/40server_prepare.t line 66. # Structures begin differing at: # $got->[0][3] = '4' # $expected->[0][3] = '8589934596' It looks like it's coercing 64-bit integers into 32-bit ones, which mostly works for small integers on little endian, but zeros out the result on big endian. I gather MYSQL_TYPE_LONG is an int (32-bit) despite the name and it seems to be the default everywhere in dbdimp.c. Blindly sprinkling MYSQL_TYPE_LONGLONG in the code fixes it; see the attached patch. I've tested it on amd64 (64-bit LE), s390x (64-bit BE), armhf (32-bit LE) and powerpc (32-bit BE). But maybe MYSQL_TYPE_LONGLONG should be limited to just SQL_BIGINTs? Hope this helps a bit anyway. -- Niko Tyni ntyni@debian.org

Message body is not shown because sender requested not to inline it.

On Pia Nov 18 04:26:38 2016, ntyni@debian.org wrote: Show quoted text
> On Fri, Nov 18, 2016 at 01:45:59AM +0100, gregor herrmann wrote: >
> > But as https://buildd.debian.org/status/package.php?p=libdbd-mysql- > > perl > > shows this is not only about mips but about various architectures, > > and the quick summary on IRC was "looks like a big-endian issue".
> > FWIW it goes away if I revert 97c8c22998e67e7c6cfe5635578e0464e9ac9513 > ("Add support for 64bit types when perl is compiled with 64bit > support"). > > We're configuring Perl with -Duse64bitint on both 32-bit and 64-bit > platforms. > > I think the 64-bit integer support is not quite working yet; even on > little-endian (regular x86_64), if I test for them: > > --- a/t/40server_prepare.t > +++ b/t/40server_prepare.t > @@ -59,11 +59,11 @@ ok($sth2 = $dbh->prepare('INSERT INTO > dbd_mysql_t40serverprepare2 VALUES (?,?,?, > ok($sth2->bind_param(1, 101, DBI::SQL_INTEGER), "binding int"); > ok($sth2->bind_param(2, 102, DBI::SQL_SMALLINT), "binding smallint"); > ok($sth2->bind_param(3, 103, DBI::SQL_TINYINT), "binding tinyint"); > -ok($sth2->bind_param(4, 104, DBI::SQL_INTEGER), "binding bigint"); > +ok($sth2->bind_param(4, (2<<32)+4, DBI::SQL_INTEGER), "binding > bigint"); > > ok($sth2->execute(), "inserting data"); > > -is_deeply($dbh->selectall_arrayref('SELECT * FROM > dbd_mysql_t40serverprepare2'), [[101, 102, 103, 104]]); > +is_deeply($dbh->selectall_arrayref('SELECT * FROM > dbd_mysql_t40serverprepare2'), [[101, 102, 103, (2<<32)+4]]); > > ok ($dbh->do(qq{DROP TABLE dbd_mysql_t40serverprepare2}), "cleaning > up"); > > I get > > not ok 20 > # Failed test at t/40server_prepare.t line 66. > # Structures begin differing at: > # $got->[0][3] = '4' > # $expected->[0][3] = '8589934596' > > It looks like it's coercing 64-bit integers into 32-bit ones, which > mostly > works for small integers on little endian, but zeros out the result on > big endian. > > I gather MYSQL_TYPE_LONG is an int (32-bit) despite the name and it > seems to be the default everywhere in dbdimp.c. Blindly sprinkling > MYSQL_TYPE_LONGLONG in the code fixes it; see the attached patch. I've > tested it on amd64 (64-bit LE), s390x (64-bit BE), armhf (32-bit LE) > and powerpc (32-bit BE). > > But maybe MYSQL_TYPE_LONGLONG should be limited to just SQL_BIGINTs? > Hope this helps a bit anyway.
Your test scenario with (2<<32)+4 and SQL_INTEGER is expected. SQL_INTEGER type maps to MYSQL_TYPE_LONG which is 32bit integer in mysql server. So libmysqlclient.so will truncate your 64bit integer value (2<<32)+4 to 32bit and send it to mysql server. So returned value 4 is expected. If you want to pass 64bit integer you need to use either SQL_BIGINT or SQL_VARCHAR. Your test with 64bit type should looks like this: $sth2->bind_param(4, (2<<32)+4, DBI::SQL_BIGINT) Can you try it? Also if you want to use 64bit integers in ODBC, you need to use type SQLBIGINT and not SQLINTEGER. So in my opinition this behaviour in mysql driver is correct. Defaulting to MYSQL_TYPE_LONGLONG for all integer values is not a good idea.
On Pia Nov 18 08:16:39 2016, PALI wrote: Show quoted text
> If you want to pass 64bit integer you need to use either SQL_BIGINT
There is big mess between perl types, DBI sql types and mysql types. Due to that SQL_BIGINT is broken too :-( Show quoted text
> Defaulting to MYSQL_TYPE_LONGLONG for all integer values is not a good > idea.
Looks like until conversion between perl/dbi/mysql types will be fixed there is no other way just default to 64bit MYSQL_TYPE_LONGLONG for perl's with 64bit scalars and MYSQL_TYPE_LONG for perl's with 32bit scalars. Now I enabled test t/41int_min_max.t for prepared statements too and it is failing... Going to look at it and try to fix it.
RT-Send-CC: debian-perl [...] lists.debian.org, debian-perl [...] lists.debian.org
On Pia Nov 18 09:31:34 2016, PALI wrote: Show quoted text
> On Pia Nov 18 08:16:39 2016, PALI wrote:
> > If you want to pass 64bit integer you need to use either SQL_BIGINT
> > There is big mess between perl types, DBI sql types and mysql types. > Due to that SQL_BIGINT is broken too :-( >
> > Defaulting to MYSQL_TYPE_LONGLONG for all integer values is not a > > good > > idea.
> > Looks like until conversion between perl/dbi/mysql types will be fixed > there is no other way just default to 64bit MYSQL_TYPE_LONGLONG for > perl's with 64bit scalars and MYSQL_TYPE_LONG for perl's with 32bit > scalars. > > Now I enabled test t/41int_min_max.t for prepared statements too and > it is failing... Going to look at it and try to fix it.
In attachment is a quick fix for types when mysql_server_prepare=1 is used. Please try this patch if it fix prepare statements also on big endian systems.
Subject: 0001-Fix-integer-types-when-server-side-prepare-statement.patch
From 602868738cdefda91d08eaa72705fe1023561d38 Mon Sep 17 00:00:00 2001 From: Pali <pali@cpan.org> Date: Fri, 18 Nov 2016 17:18:27 +0100 Subject: [PATCH] Fix integer types when server side prepare statements are enabled Fixed problems: * SQL_BIGINT was incorrectly handled as 32bit MYSQL_TYPE_LONG type instead 64bit MYSQL_TYPE_LONGLONG which led to integer overflow/underflow * 32bit MYSQL_TYPE_LONG was used for perl's IV storage when IV was 64bit and 64bit MYSQL_TYPE_LONGLONG was used when IV was 32bit * All unsigned types were handled as signed, so all high positive values were treated as negative * Numeric conversions in perl which led to overflow/underflow was ignored even when mysql strict mode was enabled * Test t/41int_min_max.t was running only for normal non-prepared statements * Test t/40server_prepare.t used incorrect SQL type for big (64bit) integers --- dbdimp.c | 31 +++++++++++++++++++++++++++---- t/40server_prepare.t | 4 ++-- t/41int_min_max.t | 9 ++++++++- 3 files changed, 37 insertions(+), 7 deletions(-) diff --git a/dbdimp.c b/dbdimp.c index c1ef3ff..24f13f6 100644 --- a/dbdimp.c +++ b/dbdimp.c @@ -360,8 +360,10 @@ static enum enum_field_types mysql_to_perl_type(enum enum_field_types type) case MYSQL_TYPE_YEAR: #if IVSIZE >= 8 case MYSQL_TYPE_LONGLONG: -#endif + enum_type= MYSQL_TYPE_LONGLONG; +#else enum_type= MYSQL_TYPE_LONG; +#endif break; #if MYSQL_VERSION_ID > NEW_DATATYPE_VERSION @@ -3508,7 +3510,7 @@ my_ulonglong mysql_st_internal_execute41( { for (i = mysql_stmt_field_count(stmt) - 1; i >=0; --i) { enum_type = mysql_to_perl_type(stmt->fields[i].type); - if (enum_type != MYSQL_TYPE_DOUBLE && enum_type != MYSQL_TYPE_LONG && enum_type != MYSQL_TYPE_BIT) + if (enum_type != MYSQL_TYPE_DOUBLE && enum_type != MYSQL_TYPE_LONG && enum_type != MYSQL_TYPE_LONGLONG && enum_type != MYSQL_TYPE_BIT) { /* mysql_stmt_store_result to update MYSQL_FIELD->max_length */ my_bool on = 1; @@ -3776,6 +3778,7 @@ int dbd_describe(SV* sth, imp_sth_t* imp_sth) break; case MYSQL_TYPE_LONG: + case MYSQL_TYPE_LONGLONG: buffer->buffer_length= sizeof(fbh->ldata); buffer->buffer= (char*) &fbh->ldata; buffer->is_unsigned= (fields[i].flags & UNSIGNED_FLAG) ? 1 : 0; @@ -4016,6 +4019,7 @@ process: break; case MYSQL_TYPE_LONG: + case MYSQL_TYPE_LONGLONG: if (DBIc_TRACE_LEVEL(imp_xxh) >= 2) PerlIO_printf(DBIc_LOGPIO(imp_xxh), "\t\tst_fetch int data %"IVdf", unsigned? %d\n", fbh->ldata, buffer->is_unsigned); @@ -4178,6 +4182,7 @@ process: break; case MYSQL_TYPE_LONG: + case MYSQL_TYPE_LONGLONG: /* Coerce to integer and set scalar as UV resp. IV */ if (fields[i].flags & UNSIGNED_FLAG) { @@ -4825,6 +4830,7 @@ int dbd_bind_ph(SV *sth, imp_sth_t *imp_sth, SV *param, SV *value, STRLEN slen; char *buffer= NULL; int buffer_is_null= 0; + int buffer_is_unsigned= 0; int buffer_length= slen; unsigned int buffer_type= 0; #endif @@ -4882,9 +4888,13 @@ int dbd_bind_ph(SV *sth, imp_sth_t *imp_sth, SV *param, SV *value, case SQL_NUMERIC: case SQL_INTEGER: case SQL_SMALLINT: - case SQL_BIGINT: case SQL_TINYINT: +#if IVSIZE >= 8 + case SQL_BIGINT: + buffer_type= MYSQL_TYPE_LONGLONG; +#else buffer_type= MYSQL_TYPE_LONG; +#endif break; case SQL_DOUBLE: case SQL_DECIMAL: @@ -4910,12 +4920,24 @@ int dbd_bind_ph(SV *sth, imp_sth_t *imp_sth, SV *param, SV *value, if (! buffer_is_null) { switch(buffer_type) { case MYSQL_TYPE_LONG: + case MYSQL_TYPE_LONGLONG: /* INT */ if (!SvIOK(imp_sth->params[idx].value) && DBIc_TRACE_LEVEL(imp_xxh) >= 2) PerlIO_printf(DBIc_LOGPIO(imp_xxh), "\t\tTRY TO BIND AN INT NUMBER\n"); buffer_length = sizeof imp_sth->fbind[idx].numeric_val.lval; imp_sth->fbind[idx].numeric_val.lval= SvIV(imp_sth->params[idx].value); buffer=(void*)&(imp_sth->fbind[idx].numeric_val.lval); + if (!SvIOK(imp_sth->params[idx].value)) + { + if (DBIc_TRACE_LEVEL(imp_xxh) >= 2) + PerlIO_printf(DBIc_LOGPIO(imp_xxh), + " Conversion to INT NUMBER was not successful -> '%s' --> (unsigned) '%"UVuf"' / (signed) '%"IVdf"' <- fallback to STRING\n", + SvPV_nolen(imp_sth->params[idx].value), imp_sth->fbind[idx].numeric_val.lval, imp_sth->fbind[idx].numeric_val.lval); + buffer_type = MYSQL_TYPE_STRING; + break; + } + if (SvIsUV(imp_sth->params[idx].value)) + buffer_is_unsigned= 1; if (DBIc_TRACE_LEVEL(imp_xxh) >= 2) PerlIO_printf(DBIc_LOGPIO(imp_xxh), " SCALAR type %"IVdf" ->%"IVdf"<- IS A INT NUMBER\n", @@ -4970,7 +4992,7 @@ int dbd_bind_ph(SV *sth, imp_sth_t *imp_sth, SV *param, SV *value, } /* Type of column was changed. Force to rebind */ - if (imp_sth->bind[idx].buffer_type != buffer_type) { + if (imp_sth->bind[idx].buffer_type != buffer_type || imp_sth->bind[idx].is_unsigned != buffer_is_unsigned) { if (DBIc_TRACE_LEVEL(imp_xxh) >= 2) PerlIO_printf(DBIc_LOGPIO(imp_xxh), " FORCE REBIND: buffer type changed from %d to %d, sql-type=%"IVdf"\n", @@ -4988,6 +5010,7 @@ int dbd_bind_ph(SV *sth, imp_sth_t *imp_sth, SV *param, SV *value, imp_sth->bind[idx].buffer_type= buffer_type; imp_sth->bind[idx].buffer= buffer; imp_sth->bind[idx].buffer_length= buffer_length; + imp_sth->bind[idx].is_unsigned= buffer_is_unsigned; imp_sth->fbind[idx].length= buffer_length; imp_sth->fbind[idx].is_null= buffer_is_null; diff --git a/t/40server_prepare.t b/t/40server_prepare.t index 0542d91..78658b0 100644 --- a/t/40server_prepare.t +++ b/t/40server_prepare.t @@ -59,11 +59,11 @@ ok($sth2 = $dbh->prepare('INSERT INTO dbd_mysql_t40serverprepare2 VALUES (?,?,?, ok($sth2->bind_param(1, 101, DBI::SQL_INTEGER), "binding int"); ok($sth2->bind_param(2, 102, DBI::SQL_SMALLINT), "binding smallint"); ok($sth2->bind_param(3, 103, DBI::SQL_TINYINT), "binding tinyint"); -ok($sth2->bind_param(4, 104, DBI::SQL_INTEGER), "binding bigint"); +ok($sth2->bind_param(4, '8589934697', DBI::SQL_BIGINT), "binding bigint"); ok($sth2->execute(), "inserting data"); -is_deeply($dbh->selectall_arrayref('SELECT * FROM dbd_mysql_t40serverprepare2'), [[101, 102, 103, 104]]); +is_deeply($dbh->selectall_arrayref('SELECT * FROM dbd_mysql_t40serverprepare2'), [[101, 102, 103, '8589934697']]); ok ($dbh->do(qq{DROP TABLE dbd_mysql_t40serverprepare2}), "cleaning up"); diff --git a/t/41int_min_max.t b/t/41int_min_max.t index 547b7f5..355b00a 100644 --- a/t/41int_min_max.t +++ b/t/41int_min_max.t @@ -22,7 +22,7 @@ if (!MinimumVersion($dbh, '4.1')) { "SKIP TEST: You must have MySQL version 4.1 and greater for this test to run"; } # nostrict tests + strict tests + init/tear down commands -plan tests => 19*8 + 17*8 + 4; +plan tests => (19*8 + 17*8 + 4) * 2; my $table = 'dbd_mysql_t41minmax'; # name of the table we will be using my $mode; # 'strict' or 'nostrict' corresponds to strict SQL mode @@ -117,6 +117,12 @@ sub test_int_type ($$$$) { }; } +$dbh->disconnect; + +for my $mysql_server_prepare (0, 1) { +$dbh= DBI->connect($test_dsn . ';mysql_server_prepare=' . $mysql_server_prepare, $test_user, $test_password, + { RaiseError => 1, PrintError => 1, AutoCommit => 0 }); + # Set strict SQL mode ok($dbh->do("SET SQL_MODE='STRICT_ALL_TABLES'"),"Enter strict SQL mode."); $mode = 'strict'; @@ -146,3 +152,4 @@ test_int_type(DBI::SQL_BIGINT, 'bigint unsigned', 0, 2**64-1); ok ($dbh->do("DROP TABLE $table")); ok $dbh->disconnect; +} -- 1.7.9.5
CC: debian-perl [...] lists.debian.org
Subject: Re: [rt.cpan.org #118823] libdbd-mysql-perl: FTBFS on some architectures
Date: Sat, 19 Nov 2016 19:35:59 +0200
To: Pali via RT <bug-DBD-mysql [...] rt.cpan.org>
From: Niko Tyni <ntyni [...] debian.org>
On Fri, Nov 18, 2016 at 11:21:28AM -0500, Pali via RT wrote: Show quoted text
Show quoted text
> In attachment is a quick fix for types when mysql_server_prepare=1 is used. Please try this patch if it fix prepare statements also on big endian systems.
Yes, that seems to work. Tested succesfully on amd64 (64-bit LE), s390x (64-bit BE), armhf (32-bit LE) and powerpc (32-bit BE) Many thanks for the quick fix! -- Niko Tyni ntyni@debian.org
It's fixed in https://github.com/perl5-dbi/DBD-mysql/commit/b2dcab35a4575ef754aea583bbc0ec4a1a162dfe and released as version 4.040 which is on CPAN now. -- Michiel
Subject: Re: [rt.cpan.org #118823] libdbd-mysql-perl: FTBFS on some architectures
Date: Sat, 19 Nov 2016 22:01:11 +0100
To: Michiel Beijen via RT <bug-DBD-mysql [...] rt.cpan.org>
From: gregor herrmann <gregoa [...] debian.org>
On Sat, 19 Nov 2016 15:03:11 -0500, Michiel Beijen via RT wrote: Show quoted text
Thanks! Uploading to Debian/unstable right now. Build results will show up soon at https://buildd.debian.org/status/package.php?p=libdbd-mysql-perl Cheers, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Funny van Dannen: Mädchenmusik
Download signature.asc
application/pgp-signature 963b

Message body not shown because it is not plain text.