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
ti 15. tammik. 2019 klo 20.27 Georg Richter (ge...@mariadb.com) kirjoitti: > > 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? 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? Below is the file listing I sent you on December 10th, which I did not get much replies to. Maybe you want to re-review it and comment if something is misplaced? ti 11. jouluk. 2018 klo 10.38 Otto Kekäläinen (o...@debian.org) kirjoitti: > > Below is a comparison of what the binary release of Connector/C has > and what the upstream MariaDB Server Debian repository packages > contain. > > Do you spot any misplaced files or anticipate problems here? > > At least the auth_gssapi is in another package in the server, and > remote.io.so is not included in the server produced libmariadb3.deb at > all. And there are way too many header files shipped in > libmariadb-dev. > > Connector/C binary release from MariaDB.org > > drwxr-xr-x ./lib > drwxr-xr-x ./lib/pkgconfig > -rw-r--r-- ./lib/pkgconfig/libmariadb.pc > drwxr-xr-x ./lib/mariadb > -rw-r--r-- ./lib/mariadb/libmariadb.so.3 > drwxr-xr-x ./lib/mariadb/plugin > -rw-r--r-- ./lib/mariadb/plugin/mysql_clear_password.so > -rw-r--r-- ./lib/mariadb/plugin/sha256_password.so > -rw-r--r-- ./lib/mariadb/plugin/auth_gssapi_client.so > -rw-r--r-- ./lib/mariadb/plugin/remote_io.so > -rw-r--r-- ./lib/mariadb/plugin/dialog.so > lrwxrwxrwx ./lib/mariadb/libmariadb.so -> libmariadb.so.3 > -rw-r--r-- ./lib/mariadb/libmariadbclient.a > drwxr-xr-x ./include > drwxr-xr-x ./include/mariadb > -rw-r--r-- ./include/mariadb/mariadb_ctype.h > -rw-r--r-- ./include/mariadb/ma_list.h > -rw-r--r-- ./include/mariadb/ma_tls.h > -rw-r--r-- ./include/mariadb/mariadb/ma_io.h > -rw-r--r-- ./include/mariadb/errmsg.h > -rw-r--r-- ./include/mariadb/mysqld_error.h > -rw-r--r-- ./include/mariadb/mariadb_dyncol.h > -rw-r--r-- ./include/mariadb/mariadb_com.h > -rw-r--r-- ./include/mariadb/ma_pvio.h > drwxr-xr-x ./include/mariadb/mariadb > -rw-r--r-- ./include/mariadb/mysql.h > drwxr-xr-x ./include/mariadb/mysql > -rw-r--r-- ./include/mariadb/mysql/plugin_auth.h > -rw-r--r-- ./include/mariadb/mysql/client_plugin.h > -rw-r--r-- ./include/mariadb/mysql/plugin_auth_common.h > -rw-r--r-- ./include/mariadb/mariadb_stmt.h > -rw-r--r-- ./include/mariadb/mariadb_version.h > drwxr-xr-x ./bin > -rwxr-xr-x ./bin/mariadb_config > > > MariaDB Server 10.3/10.4 from MariaDB.org > > libmariadb3 > drwxr-xr-x root/root ./ > drwxr-xr-x root/root ./usr/ > drwxr-xr-x root/root ./usr/lib/ > drwxr-xr-x root/root ./usr/lib/mysql/ > drwxr-xr-x root/root ./usr/lib/mysql/plugin/ > -rw-r--r-- root/root ./usr/lib/mysql/plugin/client_ed25519.so > -rw-r--r-- root/root ./usr/lib/mysql/plugin/dialog.so > -rw-r--r-- root/root ./usr/lib/mysql/plugin/mysql_clear_password.so > -rw-r--r-- root/root ./usr/lib/mysql/plugin/sha256_password.so > drwxr-xr-x root/root ./usr/lib/x86_64-linux-gnu/ > -rw-r--r-- root/root ./usr/lib/x86_64-linux-gnu/libmariadb.so.3 > drwxr-xr-x root/root ./usr/share/ > drwxr-xr-x root/root ./usr/share/doc/ > drwxr-xr-x root/root ./usr/share/doc/libmariadb3/ > -rw-r--r-- root/root ./usr/share/doc/libmariadb3/changelog.gz > -rw-r--r-- root/root ./usr/share/doc/libmariadb3/copyright > > libmariadb3-compat > drwxr-xr-x root/root ./ > drwxr-xr-x root/root ./usr/ > drwxr-xr-x root/root ./usr/lib/ > drwxr-xr-x root/root ./usr/lib/x86_64-linux-gnu/ > lrwxrwxrwx root/root ./usr/lib/x86_64-linux-gnu/libmysqlclient.so.19 > lrwxrwxrwx root/root ./usr/lib/x86_64-linux-gnu/libmysqlclient.so.20 > drwxr-xr-x root/root ./usr/share/ > drwxr-xr-x root/root ./usr/share/doc/ > drwxr-xr-x root/root ./usr/share/doc/libmariadb3-compat/ > -rw-r--r-- root/root ./usr/share/doc/libmariadb3-compat/changelog.gz > -rw-r--r-- root/root ./usr/share/doc/libmariadb3-compat/copyright > > libmariadbclient18 > drwxr-xr-x root/root ./ > drwxr-xr-x root/root ./usr/ > drwxr-xr-x root/root ./usr/lib/ > drwxr-xr-x root/root ./usr/lib/x86_64-linux-gnu/ > lrwxrwxrwx root/root ./usr/lib/x86_64-linux-gnu/libmariadbclient.so.18 > drwxr-xr-x root/root ./usr/share/ > drwxr-xr-x root/root ./usr/share/doc/ > drwxr-xr-x root/root ./usr/share/doc/libmariadbclient18/ > -rw-r--r-- root/root ./usr/share/doc/libmariadbclient18/changelog.gz > -rw-r--r-- root/root ./usr/share/doc/libmariadbclient18/copyright > > libmariadb-dev > drwxr-xr-x root/root ./ > drwxr-xr-x root/root ./usr/ > drwxr-xr-x root/root ./usr/bin/ >
Bug#919395: Fwd: Help request: analyze build failures in packages that depend on MariaDB
-- Forwarded message -
From: Sergei Golubchik
Hi, Otto!
On Jan 15, Otto Kekäläinen wrote:
> Hello!
>
> Introducing MariaDB 10.3 (and the libmaraidb3 it includes) changed
> somewhat how packages build compared to MariaB 10.1. In effect there
> are bunch of regressions on those depending packages that need to be
> addressed either in those other programs, or by fixing something in
> MariaDB.
>
> This is quite a big task and I need help. Please check out the latest
> status of this in the bug report
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919395
Here are all different errors:
error: 'MYSQL' {aka 'struct st_mysql'} has no member named 'reconnect'
This is not a bug. MYSQL.reconnect was not part of the API, even in 5.5
https://dev.mysql.com/doc/refman/5.5/en/c-api-auto-reconnect.html
error: 'MYSQL_SERVER_VERSION' undeclared
this looks like a bug. MYSQL_SERVER_VERSION is documented here:
https://dev.mysql.com/doc/refman/5.5/en/c-api-server-client-versions.html
error: 'MYSQL_PORT' undeclared here
I couldn't find it documented, but I think it should be fixed too
fatal error: mysql/mysql_time.h: No such file or directory
this doesn't seem to be a part of the API,
one should only include mysql.h
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#918677: transition: pacemaker
On 15/01/2019 17:23, wf...@niif.hu wrote: > Hi, > > The uploads are done, but the testing migration of pacemaker and pcs > probably deadlocked due to the autopkgtest of the latter. Unstable pcs > needs unstable pacemaker, so they can only go together, which may need > manual intervention on your part. The way this is normally handled is by adding a Breaks on the new pacemaker against the broken pcs. That way the autopkgtests are run for the new pcs version, and britney migrates the two packages at the same time. > Furthermore, it may be prudent to take dlm along to minimize breakage in > testing, because it embeds the SO version of libstonithd. > > To make this more transparent in the future, I plan to split out the > dlm_stonith binary into a separate package (with inflated dependencies) > and replace the dlopen() with ordinary dynamic linking. This will need > to go through NEW, so I'll do that separately, if you're OK with it. Yes, let's not entangle that with this transition if it's not necessary. Emilio
Processed: stardict: FTBFS with mariadb-10.3: wikipediaImage.cpp:34:76: error: 'MYSQL_PORT' was not declared in this scope
Processing control commands: > block 919395 with -1 918394 Bug #919395 [release.debian.org] transition: mariadb-10.3 919395 was blocked by: 919393 918387 917758 918393 919374 919373 919379 919375 919395 was not blocking any bugs. Added blocking bug(s) of 919395: 918394 and 919408 -- 919395: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919395 919408: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919408 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#918677: transition: pacemaker
Hi, The uploads are done, but the testing migration of pacemaker and pcs probably deadlocked due to the autopkgtest of the latter. Unstable pcs needs unstable pacemaker, so they can only go together, which may need manual intervention on your part. Furthermore, it may be prudent to take dlm along to minimize breakage in testing, because it embeds the SO version of libstonithd. To make this more transparent in the future, I plan to split out the dlm_stonith binary into a separate package (with inflated dependencies) and replace the dlopen() with ordinary dynamic linking. This will need to go through NEW, so I'll do that separately, if you're OK with it. -- Thanks, Feri
Processed: Re: Bug#904418: transition: json-c
Processing control commands: > tags -1 -confirmed Bug #904418 [release.debian.org] transition: json-c Removed tag(s) confirmed. -- 904418: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904418 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#904418: transition: json-c
Control: tags -1 -confirmed On 15/01/2019 15:56, Boyuan Yang wrote: > Hi there, > > On Wed, 26 Dec 2018 10:41:24 +0100 Emilio Pozuelo Monfort > wrote: >> Control: tags -1 confirmed >> >> On 07/12/2018 20:01, Birger Schacht wrote: >>> >>> (i've never followed a transition nor used ratt before, i hope that was >>> the right way to move forward) >> >> Alright, let's do this. >> >> Cheers, >> Emilio > > I noticed that we've missed the transition freeze. Does that mean that json-c > 0.13 will miss Debian Buster? > > Anyway I've prepared a 0.12.1-2 upload in the git repo in case the transition > will not take place. Please let me know the next step for json-c in Debian. Yeah, sorry but I'd rather we concentrate on finishing the transitions that are still ongoing rather than starting new ones (particularly one like this which has a few failing rdeps with the new version). So yeah 0.12.1-2 should be alright for sid/buster, and 0.13 will have to wait for bullseye after the freeze. Cheers, Emilio
Processed: tagging 919395
Processing commands for cont...@bugs.debian.org: > tags 919395 + pending Bug #919395 [release.debian.org] transition: mariadb-10.3 Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 919395: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919395 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#904418: transition: json-c
Hi there, On Wed, 26 Dec 2018 10:41:24 +0100 Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > > On 07/12/2018 20:01, Birger Schacht wrote: > > > > (i've never followed a transition nor used ratt before, i hope that was > > the right way to move forward) > > Alright, let's do this. > > Cheers, > Emilio I noticed that we've missed the transition freeze. Does that mean that json-c 0.13 will miss Debian Buster? Anyway I've prepared a 0.12.1-2 upload in the git repo in case the transition will not take place. Please let me know the next step for json-c in Debian. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#919395: mysql_time.h
(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
Processed: transition: mariadb-10.3
Processing control commands: > forwarded -1 https://release.debian.org/transitions/html/mysql-default.html Bug #919395 [release.debian.org] transition: mariadb-10.3 Set Bug forwarded-to-address to 'https://release.debian.org/transitions/html/mysql-default.html'. > block -1 with 917758 919373 918387 919374 919375 918393 919379 919393 Bug #919395 [release.debian.org] transition: mariadb-10.3 919395 was not blocked by any bugs. 919395 was not blocking any bugs. Added blocking bug(s) of 919395: 919379, 919375, 919393, 918387, 917758, 918393, 919374, and 919373 -- 919395: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919395 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#919395: transition: mariadb-10.3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/mysql-default.html Control: block -1 with 917758 919373 918387 919374 919375 918393 919379 919393 Hi, let's create a proper transition bug for mariadb. The switch from mariadb-10.1 to mariadb-10.3 contains the following two sub-transitions: * libmariadbd18 -> libmariadbd19 This does only affect amarok, a binnmu should be sufficient. (Not covered by the existing tracker.) * libmariadbclient18 -> libmariadb3 According to the tracker this affects about 140 packages. I just finished another test rebuild round (ignoring packages not in testing and packages already successfully built against mariadb-10.3). The following packages FTBFS with mariadb-10.3: Level 1: jabberd2#917758 kannel #919373 libodb-mysql#919374 lua-sql #918387 monitoring-plugins #919375 mosquitto-auth-plugin #915346 (unrelated FTBFS) pmacct #919379 python-mysqldb #919393 Level 2: opensips#918393 Andreas
Help you to edit the photos
Want editing your photos? We can help. No matter you need photos background cutting out , or adding clipping path, or even retouching. We are the right studio that who can help you for your photo editing with the quality you need. Let me know if interested. Thanks, Nancy
Re: Bug#919341: libtool-bin: amd64 /usr/bin/libtool is a zero byte file
Package: lintian Version: 2.5.121 Hi lintian maintainers, On 15/01/2019 06:03, Cyril Brulebois wrote: > Control: severity -1 grave > Control: tag -1 patch > > Cyril Brulebois (2019-01-15): >> For some reasons, libtool and its manpage (from the libtool-bin binary) >> are “sanitized” in binary-indep, which might explain why it's only >> showing up on the maintainer build which was likely using “-b”. >> >>> $ dpkg-deb -c libtool-bin_2.4.6-7_amd64.deb >>> -rwxr-xr-x root/root 0 2019-01-12 09:10 ./usr/bin/libtool >>> -rw-r--r-- root/root20 2019-01-12 09:10 >>> ./usr/share/man/man1/libtool.1.gz >> >> The manpage is a gzipped empty file. > > I'm afraid the situation is pretty bad, as an empty executable doesn't > do anything but also produces no errors; so I fear any packages having > been built using this version of libtool-bin on amd64 has likely missed > a step or two without that getting noticed… Could we add a lintian tag for empty executables, particularly in PATH? Then we could turn that into an autoreject (after analysing the results when lintian.debian.org is updated) and help prevent this kind of brokenness in the future. Thanks, Emilio
Bug#919314: marked as done (nmu: node-leveldown_1.5.0+dfsg-1, node-sqlite3_4.0.2+ds1-1)
Your message dated Tue, 15 Jan 2019 10:31:15 +0100 with message-id <712dfa14-71ba-0d6a-27d9-4c890c358...@debian.org> and subject line Re: Bug#919314: nmu: node-leveldown_1.5.0+dfsg-1, node-sqlite3_4.0.2+ds1-1 has caused the Debian Bug report #919314, regarding nmu: node-leveldown_1.5.0+dfsg-1, node-sqlite3_4.0.2+ds1-1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 919314: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919314 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu node-leveldown_1.5.0+dfsg-1 . ANY . unstable . -m "Rebuild against nodejs-abi-64" nmu node-sqlite3_4.0.2+ds1-1 . ANY . experimental . -m "Rebuild against nodejs-abi-64" Looks like a small transition is here ongoing ... Andreas --- End Message --- --- Begin Message --- On 14/01/2019 22:02, Andreas Beckmann wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > nmu node-leveldown_1.5.0+dfsg-1 . ANY . unstable . -m "Rebuild against > nodejs-abi-64" > nmu node-sqlite3_4.0.2+ds1-1 . ANY . experimental . -m "Rebuild against > nodejs-abi-64" Scheduled. Emilio--- End Message ---
