Bug#933063: [debian-mysql] Bug#933063: Bug#933063: Bug#933063: character_set_client: latin1?
Hi Otto,
this is the commit
/Georg
git show 29720950eeae75f1ea7ef1376a6149cabeb79d13
commit 29720950eeae75f1ea7ef1376a6149cabeb79d13
Author: Georg Richter
Date: Wed Sep 30 06:29:29 2020 +0200
Allow to specify the default character set in server builds with
-DCONC_DEFAULT_CHARSET
diff --git a/CMakeLists.txt b/CMakeLists.txt
index c85baf2..4045491 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -25,7 +25,7 @@ get_directory_property(IS_SUBPROJECT PARENT_DIRECTORY)
SET_PROPERTY(DIRECTORY PROPERTY INCLUDE_DIRECTORIES)
FOREACH(V WITH_MYSQLCOMPAT WITH_MSI WITH_SIGNCODE WITH_RTC WITH_UNIT_TESTS
WITH_DYNCOL WITH_EXTERNAL_ZLIB WITH_CURL WITH_SQLITE WITH_SSL
WITH_ICONV
-INSTALL_LAYOUT WITH_TEST_SRCPKG)
+DEFAULT_CHARSET INSTALL_LAYOUT WITH_TEST_SRCPKG)
SET(${V} ${${OPT}${V}})
ENDFOREACH()
On Tue, Oct 6, 2020 at 11:49 AM Otto Kekäläinen wrote:
> Hello Georg!
>
> Will you do this same `-DCONC_DEFAULT_CHARSET=utf8mb4` change upstream
> as I did in
> https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/ca5e93c754209f9c1a729bb057332ab3b0b76363
> ?
>
> Let me know if there is an upstream commit so I can document it in
>
> https://salsa.debian.org/mariadb-team/mariadb-10.5/-/blob/master/debian/patches/933063-client-utf8mb4-by-default.patch
> and easily drop it once that upstream commit is eventually imported
> into Debian.
>
> su 4. lokak. 2020 klo 12.39 Otto Kekäläinen (o...@debian.org) kirjoitti:
> >
> > Thanks!
> >
> > I confirm the patch from Georg fixes this and the result looks like:
> >
> > g++ b933063.cpp -l mariadbclient && ./a.out
> > character_set_client: utf8mb4
> > character_set_connection: utf8mb4
> > character_set_database: utf8mb4
> > character_set_filesystem: binary
> > character_set_results: utf8mb4
> > character_set_server: utf8mb4
> > character_set_system: utf8
> > character_sets_dir: /usr/share/mysql/charsets/
> > spider_remote_access_charset:
> > spider_use_table_charset: -1
> >
> >
> > I also extended Salsa-CI to automatically test for this so that this
> > simple client library linking build does not regress unnoticed:
> >
> https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commits/bugfix/933063-default-client-charset-utf8mb4
> >
> > Open
> https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/3c62617cf955ece894504e88a72b3ce207635d05
> > to view the changes.
> >
> >
> > Georg: Will you do this same `-DCONC_DEFAULT_CHARSET=utf8mb4` change
> upstream?
> >
>
--
Georg Richter, Senior Software Engineer
MariaDB Corporation Ab
Bug#933063: [debian-mysql] Bug#933063: character_set_client: latin1?
Hi Otto, according to the build log you didn't build server with option -DCONC_DEFAULT_CHARSET=utf8mb4 or do I miss something? /Georg On Thu, Oct 1, 2020 at 8:20 AM Otto Kekäläinen wrote: > When libmariadb-dev and libmariadbd-dev are installed one gets: > > # grep -rF DEFAULT_CHARSET /usr/include/ > /usr/include/mariadb/mariadb_ctype.h:#define MADB_DEFAULT_CHARSET_NAME > "latin1" > /usr/include/mariadb/server/my_config.h:#define > MYSQL_DEFAULT_CHARSET_NAME "latin1" > > Georg: at the very end of the build log at > > http://buildbot.askmonty.org/buildbot/builders/kvm-deb-buster-amd64/builds/3187/steps/compile/logs/stdio > you can see that files are included in the libmariadb-dev and other > packages. > > Are we missing something? > The config.h and ma_config.h files are now only in the mariadb sources > themselves. > > Olaf: what commands did you run to compile your example program? Any > pkg-config or mariadb_config involved? > -- Georg Richter, Senior Software Engineer MariaDB Corporation Ab
Bug#933063: [debian-mysql] Bug#933063: character_set_client: latin1?
Hi Otto,
looks like you use the command line client to check this - command line
client is different, it is using charset="auto" by default.
To check the mariadb_default_charset you can check the generated include
files:
georg@beethoven:~/work/mariadb/server/bld$ grep DEFAULT_CHARSET
libmariadb/include/*.h
libmariadb/include/config.h:#define MARIADB_DEFAULT_CHARSET "utf8mb4"
libmariadb/include/ma_config.h:#define MARIADB_DEFAULT_CHARSET "utf8mb4"
/Georg
On Wed, Sep 30, 2020 at 8:23 PM Otto Kekäläinen wrote:
> Tested this patch, unfortunately it didn't work:
>
>
> MariaDB [(none)]> status;
> --
> mariadb Ver 15.1 Distrib 10.5.5-MariaDB, for debian-linux-gnu
> (x86_64) using readline 5.2
>
> Connection id: 45
> Current database:
> Current user: root@localhost
> SSL: Not in use
> Current pager: stdout
> Using outfile: ''
> Using delimiter: ;
> Server: MariaDB
> Server version: 10.5.5-MariaDB-2-debug Debian unstable
> Protocol version: 10
> Connection: Localhost via UNIX socket
> Server characterset: utf8mb4
> Db characterset: utf8mb4
> Client characterset: latin1
> Conn. characterset: latin1
>
>
> commit 2e1239cd426dd6bb910363082f57d66c06f71254
> Author: Otto Kekäläinen
> Date: Tue Sep 29 21:27:02 2020 +0300
>
> Use build flag to enforce default charset as utf8mb4 (Closes: #933063)
>
> diff --git a/debian/patches/933063-client-utf8mb4-by-default.patch
> b/debian/patches/933063-client-utf8mb4-by-default.patch
> new file mode 100644
> index 0..573dcf2f7
> --- /dev/null
> +++ b/debian/patches/933063-client-utf8mb4-by-default.patch
> @@ -0,0 +1,14 @@
> +Author: Georg Richter
> + Looks like it was forgotten to add this option when building C/C as
> a sunproject inside server. I fixed that now:
> +
> +--- a/libmariadb/CMakeLists.txt
> b/libmariadb/CMakeLists.txt
> +@@ -25,7 +25,7 @@ get_directory_property(IS_SUBPROJECT PAR
> + SET_PROPERTY(DIRECTORY PROPERTY INCLUDE_DIRECTORIES)
> + FOREACH(V WITH_MYSQLCOMPAT WITH_MSI WITH_SIGNCODE WITH_RTC
> WITH_UNIT_TESTS
> + WITH_DYNCOL WITH_EXTERNAL_ZLIB WITH_CURL WITH_SQLITE WITH_SSL
> +-INSTALL_LAYOUT WITH_TEST_SRCPKG)
> ++DEFAULT_CHARSET INSTALL_LAYOUT WITH_TEST_SRCPKG)
> + SET(${V} ${${OPT}${V}})
> + ENDFOREACH()
> +
> diff --git a/debian/patches/series b/debian/patches/series
> index 043ed42cf..81eef0cdc 100644
> --- a/debian/patches/series
> +++ b/debian/patches/series
> @@ -14,3 +14,4 @@
> prevent-executable-stack-due-to-objects-compiled-fro.patch
> env-perl-usr-bin-perl.patch
> fix-spelling.patch
> ftbfs-x32.patch
> +933063-client-utf8mb4-by-default.patch
> diff --git a/debian/rules b/debian/rules
> index 819ac6ea0..3809e8f54 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -101,6 +101,7 @@ endif
> -DSYSTEM_TYPE="debian-$(DEB_HOST_GNU_SYSTEM)" \
> -DBUILD_CONFIG=mysql_release \
> -DWITH_SSL=bundled \
> + -DCONC_DEFAULT_CHARSET=utf8mb4 \
> -DPLUGIN_TOKUDB=NO \
> -DPLUGIN_CASSANDRA=NO \
> -DPLUGIN_AWS_KEY_MANAGEMENT=NO \
>
--
Georg Richter, Senior Software Engineer
MariaDB Corporation Ab
Bug#933063: [debian-mysql] Bug#933063: character_set_client: latin1?
Hi Otto,
you're right - looks like it was forgotten to add this option when building
C/C as a sunproject inside server. I fixed that now:
diff --git a/CMakeLists.txt b/CMakeLists.txt
index c85baf2..4045491 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -25,7 +25,7 @@ get_directory_property(IS_SUBPROJECT PARENT_DIRECTORY)
SET_PROPERTY(DIRECTORY PROPERTY INCLUDE_DIRECTORIES)
FOREACH(V WITH_MYSQLCOMPAT WITH_MSI WITH_SIGNCODE WITH_RTC WITH_UNIT_TESTS
WITH_DYNCOL WITH_EXTERNAL_ZLIB WITH_CURL WITH_SQLITE WITH_SSL
WITH_ICONV
-INSTALL_LAYOUT WITH_TEST_SRCPKG)
+DEFAULT_CHARSET INSTALL_LAYOUT WITH_TEST_SRCPKG)
SET(${V} ${${OPT}${V}})
ENDFOREACH()
With this patch you should be able to specify the character set in server
build with
cmake -DCONC_DEFAULT_CHARSET=utf8mb4
/Georg
On Tue, Sep 29, 2020 at 10:41 PM Otto Kekäläinen wrote:
> I tested this but it did not at least directly work:
>
> commit b8e537d55b467eb285a82842e73bb22732ef9ad6 (HEAD -> master-next)
> Author: Otto Kekäläinen
> Date: Tue Sep 29 21:27:02 2020 +0300
>
> Use build flag to enforce default charset as utf8mb4 (Closes: ##933063)
>
> diff --git a/debian/rules b/debian/rules
> index 819ac6ea0..12b162002 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -101,6 +101,7 @@ endif
> -DSYSTEM_TYPE="debian-$(DEB_HOST_GNU_SYSTEM)" \
> -DBUILD_CONFIG=mysql_release \
> -DWITH_SSL=bundled \
> + -DDEFAULT_CHARSET=utf8mb4 \
> -DPLUGIN_TOKUDB=NO \
> -DPLUGIN_CASSANDRA=NO \
> -DPLUGIN_AWS_KEY_MANAGEMENT=NO \
>
>
> --->
>
>
> MariaDB [(none)]> status
> --
> mariadb Ver 15.1 Distrib 10.5.5-MariaDB, for debian-linux-gnu
> (x86_64) using readline 5.2
>
> Connection id: 76
> Current database:
> Current user: root@localhost
> SSL: Not in use
> Current pager: stdout
> Using outfile: ''
> Using delimiter: ;
> Server: MariaDB
> Server version: 10.5.5-MariaDB-2-debug Debian 10
> Protocol version: 10
> Connection: Localhost via UNIX socket
> Server characterset: utf8mb4
> Db characterset: utf8mb4
> Client characterset: latin1
> Conn. characterset: latin1
> UNIX socket: /run/mysqld/mysqld.sock
> Uptime: 27 sec
>
> Threads: 22 Questions: 674 Slow queries: 0 Opens: 199 Open tables:
> 37 Queries per second avg: 24.962
> --
>
--
Georg Richter, Senior Software Engineer
MariaDB Corporation Ab
Bug#933063: [debian-mysql] Bug#933063: character_set_client: latin1?
Hi Otto, in server build you have to pass special options for C/C - I need to check it and will get back to you. /Georg On Tue, Sep 29, 2020 at 3:42 PM Otto Kekäläinen wrote: > Hi! > > ti 29. syysk. 2020 klo 7.39 Georg Richter (ge...@mariadb.com) kirjoitti: > > > > Hi, > > > > if server has default charset utf8mb4 on Debian, why don't you build C/C > with -DDEFAULT_CHARSET=utf8mb4 ? > > Yes, that might be a good solution. I wasn't aware of such an option. > > The upstream MariaDB 10.5 has this identical case, should that build > flag also be applied there and if so, on what branch do you suggest > (10.6 for future or older)? > -- Georg Richter, Senior Software Engineer MariaDB Corporation Ab
Bug#919395: mysql_time.h
Hi Otto, > execpt of mysql.h Connector/C shouldn't provide any other include files > prefixed with "mysql". > > find -name "mysql_time.h" in source tree doesn't return positive result. > > So does this mean that Connector/C is not supposed to be a drop-in > replacement for libmariadbclient18 et al? > Why? The only file you need to include in your client application is mysql.h (if you want to provide a client plugin also mysql/client_plugin.h) - mysql_time.h from server package is an internal include file, used by client and server. It is included in mysql.h. In Connector/C the MYSQL_TIME struct (and time related enumerations) is defined inside mysql.h. When building the sources of mariadb-10.3 some of these auxillary > files are still built, but libmariadbclient.so.18 is not itself built > anymore, so shouldn't it still be possible to offer backwards > compatibility? How do you suggest this is resolved? > Maybe Serg might answer?! /Georg
Bug#919395: mysql_time.h
Hi Otto, execpt of mysql.h Connector/C shouldn't provide any other include files prefixed with "mysql". find -name "mysql_time.h" in source tree doesn't return positive result. /Georg On Tue, Jan 15, 2019 at 4:21 PM Otto Kekäläinen wrote: > (Regarding https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919395 > and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919374) > > One of the failures is due to not finding header file mysql_time.h > > In Debian stable and testing the file > /usr/include/mysql/mysql_time.h is provided by libmariadbclient-dev > > In Debian unstable now the file > /usr/include/mariadb/server/mysql_time.h is provided by libmariadb-dev > and the file > /usr/include/mysql/mysql_time.h is provided by both > libmariadbclient-dev, libmysqlclient-dev > > > So at least this one is caused by MariaDB Connector/C server bundled > version had some of the header files moved from include/mysql to > include/server/mysql. > > I wonder if there was some particular design rationale for this > upstream? Should we deviate from that in Debian or have some fix that > is identical in upstream and Debian? > > This changed now also in Debian when packages migrated from using > libmariadbclient-dev to libmariadb-dev. The file > libmariadb-dev.install has only "usr/include/mariadb" defined and it > inherits the contents from whatever upstream code outputs there. The > file libmariadb-dev.links also already symlinks "usr/include/mariadb/ > usr/include/mysql" (added in > > https://salsa.debian.org/mariadb-team/mariadb-10.3/blob/master/debian/libmariadb-dev.links > ) > > For latest state see > https://salsa.debian.org/mariadb-team/mariadb-10.3/tree/master/debian > -- Georg Richter, Senior Software Engineer MariaDB Corporation Ab
Bug#917303: Request for help with MariaDB 10.3 / libdbd-mysql-perl packaging
Hi Otto, it doesn't make sense to zero a pointer, if the container (or speaking of C: structure) is freed afterwards. The documentation clearly states, that a handle (which was previously freed by mysql_close() ) needs to be initialized again. The pull request fixes the perl test case, but it didn't fix perl itself, which still abuses internal members of the connector, which are considered to be opaque. (And being opaque is the goal for next major release). /Georg On Mon, Jan 7, 2019 at 8:40 PM Otto Kekäläinen wrote: > Hello! > > gregor herrmann kirjoitti pe 4. tammikuuta 2019 klo > 1.23: > >> On Thu, 03 Jan 2019 22:04:48 +0200, Otto Kekäläinen wrote: >> >> > Just checking: are you Georg or Gregor currently working on this >> > issue, and do you have any estimate when we could expect either a >> > patch to MariaDB Connector C or a new upload of DBD-mysql so this >> > issue would be resolved? >> >> I had a look at DBD::mysql and DBD::MariaDB but without any success. >> I hope that someone with a better understanding than me from the >> Debian perl Group can try and find a solution. >> >> I've now pinged the upstream issue at: >> https://github.com/perl5-dbi/DBD-mysql/issues/275 > > > Thanks Gregor for working with upstreams to fix this. Nice Eric Herman was > also involved ;) > > Georg Richter, I hope you can review > https://github.com/MariaDB/mariadb-connector-c/pull/95 shortly, thanks! > > >> -- Georg Richter, Senior Software Engineer MariaDB Corporation Ab
Bug#917303: Request for help with MariaDB 10.3 / libdbd-mysql-perl packaging
About the reconnect bug: Latest code is setting the reconnect flag correctly via mysql_options (instead of accessing internal member), so I need to debug why it's failing. /Georg On Fri, Dec 28, 2018 at 1:31 PM gregor herrmann wrote: > On Fri, 28 Dec 2018 11:27:04 +0200, Otto Kekäläinen wrote: > > > pe 28. jouluk. 2018 klo 11.09 Georg Richter (ge...@mariadb.com) > kirjoitti: > > > no clue about dbd-mysql - we reported several bugs (and sent > > > fixes), but didn't get feedback since more than a year. Why don't > > > you ship DBD-mariadb instead? > > Gregor Hermann, do you want to switch to DBD-mariadb instead? > > DBD-mariadb is in the archive since a couple of months: > https://tracker.debian.org/libdbd-mariadb-perl > > Unfortunately, it's not a 1:1 replacement for DBD-mysql and many user > will want to continue using the latter in their existing codebase. > > Georg, maybe you can give us pointers to the bugs and fixes you > mentioned above? > > > 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 VIBE!AT & SPI Inc. -- Supporter Free Software Foundation > Europe >`- NP: Penelope Swales: Turning Point > -- Georg Richter, Senior Software Engineer MariaDB Corporation Ab
Bug#917303: Request for help with MariaDB 10.3 / libdbd-mysql-perl packaging
Hi, the zerofill test fails, since dbd-mysql binds a buffer with buffer_length=1, so MariaDB Connector/C can't add leading zeros and just returns 1. Perl seems to retrieve the information from metadata after mysql_stmt_store_result() call. According to the documentation ( https://dev.mysql.com/doc/refman/8.0/en/mysql-stmt-attr-set.html) you have to call mysql_stmt_attr_set(stmt, STMT_ATTR_UPDATE_MAX_LENGTH, ) to force mysql_stmt_store_result to update the max_length value in metadata - however its not set and therefore Connector/C doesn't return expected value. The correct behavior would be to check the metadata after mysql_stmt_prepare() and calculate the buffer_size or to force Connector/C to calculate the size via STMT_ATTR_UPDATE_MAX_LENGTH. I would prefer the latter one, since in some cases metadata after prepare can't be calculated correctly, e.g. for a "SELECT ? FROM DUAL" /Georg On Fri, Dec 28, 2018 at 1:31 PM gregor herrmann wrote: > On Fri, 28 Dec 2018 11:27:04 +0200, Otto Kekäläinen wrote: > > > pe 28. jouluk. 2018 klo 11.09 Georg Richter (ge...@mariadb.com) > kirjoitti: > > > no clue about dbd-mysql - we reported several bugs (and sent > > > fixes), but didn't get feedback since more than a year. Why don't > > > you ship DBD-mariadb instead? > > Gregor Hermann, do you want to switch to DBD-mariadb instead? > > DBD-mariadb is in the archive since a couple of months: > https://tracker.debian.org/libdbd-mariadb-perl > > Unfortunately, it's not a 1:1 replacement for DBD-mysql and many user > will want to continue using the latter in their existing codebase. > > Georg, maybe you can give us pointers to the bugs and fixes you > mentioned above? > > > 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 VIBE!AT & SPI Inc. -- Supporter Free Software Foundation > Europe >`- NP: Penelope Swales: Turning Point > -- Georg Richter, Senior Software Engineer MariaDB Corporation Ab
Bug#851132: [debian-mysql] Bug#851132: Bug#851132: Bug#851132: Bug#851132: Bug#851132: /usr/sbin/mysqld: ssl_ciphers not working; mariadb built without TLS support?
Hi Clint, I didn't check the compatibility layer for TLS/SSL stuff, there is no layer for crypto and hashing. I did a quick hack framework for crypto wrapper (supporting OpenSSL, WolfSSL and GnuTLS) at http://github.com/9EOR9/mrl. A main difference between OpenSSL and WolfSSL is, that WolfSSL expects always a ca from client - if you don't specify one verification needs to be skipped/turned off explicitly - I'm also not sure if the compatibility layer works well for OpenSSL 1.1 (which had a bunch of incompatible API changes). The best solution for MariaDB would be a wrapper library which could be used by both MariaDB Server and Connector/C - however WolfSSL would not fit for LGPL licensed Connector/C since it's GPL/commercial licensed. Also the GnuTLS compatibility layer didn't work well, another hack/proof of concept for Yassl replacement by GnuTLS can be found at https://github.com/MariaDB/server/tree/10.2-good_bye_yassl. We are aware of all the Yassl problems (no TLS v.1.2 and 1.3, no session ticket support, no session renegotiation, missing ciphers, limited block cipher support, etc) and are working on it. Connector/C 3.0 already supports GnuTLS beside OpenSSL, and SChannel for Windows platforms. /Georg On Thu, Jan 19, 2017 at 7:23 PM, Clint Byrum <spam...@debian.org> wrote: > Excerpts from Georg Richter's message of 2017-01-19 19:06:06 +0100: > > Hi, > > > > WolfSSL has another interface (it's not C++ anymore, but C) and can't > > replace Yassl on the fly. Beside TLS/SSL communication also hash > functions > > and crypto functions need to be migrated. > > > > That's interesting. WolfSSL also has an OpenSSL compatibility layer, > could that be used? > > https://www.wolfssl.com/wolfSSL/Docs-wolfssl-manual- > 13-openssl-compatibility.html > -- Georg Richter, Senior Software Engineer MariaDB Corporation Ab
Bug#851132: [debian-mysql] Bug#851132: Bug#851132: Bug#851132: Bug#851132: /usr/sbin/mysqld: ssl_ciphers not working; mariadb built without TLS support?
Hi, WolfSSL has another interface (it's not C++ anymore, but C) and can't replace Yassl on the fly. Beside TLS/SSL communication also hash functions and crypto functions need to be migrated. I'm currently working on a new tls/crypto wrapper for MariaDB, supporting OpenSSL/LibreSSL, GnuTLS and SChannel (Windows) - likely it will be part of 10.3 or a later 10.2 version of MariaDB server. /Georg On Thu, Jan 19, 2017 at 6:41 PM, Clint Byrum <spam...@debian.org> wrote: > Excerpts from Otto Kekäläinen's message of 2017-01-19 11:52:18 +0200: > > For the record, I also tested this on Ubuntu Yakkety with the version > > 10.0.28-0ubuntu0.16.10.1 and I get the same warning in syslog: > > > > mysqld: 170119 9:47:47 [Warning] Failed to setup SSL > > mysqld: 170119 9:47:47 [Warning] SSL error: Failed to set ciphers to use > > > > It seems something with how we do " -DWITH_SSL=bundled" and YaSSL is > > (and maybe always was) broken. > > > > Otto, have you tried building with WolfSSL, which is the updated and > renamed version of YaSSL? That would definitely be preferred over an > embedded version. > > https://tracker.debian.org/pkg/wolfssl > > ___ > pkg-mysql-maint mailing list > pkg-mysql-ma...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint -- Georg Richter, Senior Software Engineer MariaDB Corporation Ab
Bug#849125: [debian-mysql] Bug#849125: mariadb-connector-c: Fix include of my_stmt.h
Ups, sorry. It's in 2.3 now too. /Georg On Thu, Dec 29, 2016 at 10:54 AM, Andre Nathan <an...@digirati.com.br> wrote: > Hi Georg, > > Could you apply it to branch connector_c_2.3 too? It's still affected: > > https://github.com/MariaDB/mariadb-connector-c/blob/ > connector_c_2.3/include/mysql.h#L368 > > Best regards, > Andre > > On 12/23/2016 01:55 PM, Georg Richter wrote: > > Fix pushed to connector_c_2.2 branch, 3.0 (master) was not affected. > > > > commit 1deacd5782b9dc041c50f7359d24eaef9ba8f5a5 > > Author: Georg Richter <ge...@mariadb.com <mailto:ge...@mariadb.com>> > > Date: Fri Dec 23 16:53:14 2016 +0100 > > > > Fix for debian Bug#849125: fix include of my_stmt.h > > > > /Georg > > > > > > On Thu, Dec 22, 2016 at 8:24 PM, Andre Nathan <an...@digirati.com.br > > <mailto:an...@digirati.com.br>> wrote: > > > > Package: mariadb-connector-c > > Version: 2.3.1-1 > > Severity: important > > > > Hi, > > > > The mysql.h file has an #include directive as such: > > > > #include > > > > This causes an error in C programs that include "mysql.h", making the > > library unusable. There's an upstream fix > > (https://jira.mariadb.org/browse/CONC-143 > > <https://jira.mariadb.org/browse/CONC-143>) that claims to have > made it > > into version 2.2.0 of the connector, but it seems the error has crept > > back in. > > > > The fix is really simple, replacing the include statement above with > > > > #include "my_stmt.h" > > > > Thanks. > > > > ___ > > pkg-mysql-maint mailing list > > pkg-mysql-ma...@lists.alioth.debian.org > > <mailto:pkg-mysql-ma...@lists.alioth.debian.org> > > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ > pkg-mysql-maint > > <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ > pkg-mysql-maint> > > > > > > > > > > -- > > Georg Richter, Senior Software Engineer > > MariaDB Corporation Ab > > > -- Georg Richter, Senior Software Engineer MariaDB Corporation Ab
Bug#849125: [debian-mysql] Bug#849125: mariadb-connector-c: Fix include of my_stmt.h
Fix pushed to connector_c_2.2 branch, 3.0 (master) was not affected. commit 1deacd5782b9dc041c50f7359d24eaef9ba8f5a5 Author: Georg Richter <ge...@mariadb.com> Date: Fri Dec 23 16:53:14 2016 +0100 Fix for debian Bug#849125: fix include of my_stmt.h /Georg On Thu, Dec 22, 2016 at 8:24 PM, Andre Nathan <an...@digirati.com.br> wrote: > Package: mariadb-connector-c > Version: 2.3.1-1 > Severity: important > > Hi, > > The mysql.h file has an #include directive as such: > > #include > > This causes an error in C programs that include "mysql.h", making the > library unusable. There's an upstream fix > (https://jira.mariadb.org/browse/CONC-143) that claims to have made it > into version 2.2.0 of the connector, but it seems the error has crept > back in. > > The fix is really simple, replacing the include statement above with > > #include "my_stmt.h" > > Thanks. > > ___ > pkg-mysql-maint mailing list > pkg-mysql-ma...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint > -- Georg Richter, Senior Software Engineer MariaDB Corporation Ab
