Bug#919395: Heads up to release team about MariadB 10.3
[ changed recients to #919395 (transition bug) + pkg-mysql-maint, dropping upstream developers ] On 2019-01-18 11:44, Emilio Pozuelo Monfort wrote: > The problem was that the old libdbd-mariadb-perl didn't work with the new > mariadb-10.3, so without a Breaks relationship in mariadb-10.3, there was an > autopkgtests regression that was blocking the mariadb-10.3 migration. Yes, a > Breaks could have been added, but that would have caused extra delays and I > wanted to avoid that. That didn't work out: Trying easy from autohinter: mariadb-10.3/1:10.3.12-1 mysql-defaults/1.0.5 start: 22+0: a-1:a-0:a-0:a-0:i-18:m-1:m-0:m-1:p-0:s-1 orig: 22+0: a-1:a-0:a-0:a-0:i-18:m-1:m-0:m-1:p-0:s-1 easy: 32+0: a-2:a-1:a-1:a-1:i-19:m-2:m-1:m-2:p-1:s-2 * amd64: libmariadbclient-dev * arm64: libmariadbclient-dev * armel: libmariadbclient-dev * armhf: libmariadbclient-dev * i386: libmariadbclient-dev * mips: libmariadbclient-dev * mips64el: libmariadbclient-dev * mipsel: libmariadbclient-dev * ppc64el: libmariadbclient-dev * s390x: libmariadbclient-dev FAILED Is it possible to get this information earlier? I.e. before britney attempts to migrate the package and produces the failure? Perhaps by doing a britney "dry-run" attempting to migrate each package from sid ignoring age values ... and then reporting in the PTS,tracker "britney dry-run succeeded/failed (link to logfile)" Getting back to the current case: I assume this is caused by libmariadbclient-dev being turned into a virtual package provided by libmariadb-dev. I'll test whether reintroducing a transitional package would improve the situation. Might require a trip through NEW, though. A transitional package would also be needed to provide a smooth upgrade path for people that consciously installed libmariadbclient-dev in stretch. Andreas
Bug#919395: Heads up to release team about MariadB 10.3
On 2019-01-19 21:14, Andreas Beckmann wrote: > Getting back to the current case: I assume this is caused by > libmariadbclient-dev being turned into a virtual package provided by > libmariadb-dev. I'll test whether reintroducing a transitional package > would improve the situation. Might require a trip through NEW, though. > A transitional package would also be needed to provide a smooth upgrade > path for people that consciously installed libmariadbclient-dev in stretch. That seems to work better with a transitional package. @otto: you can find it in branch anbe/libmariadbclient-dev Andreas
Bug#919395: Heads up to release team about MariadB 10.3
su 20. tammik. 2019 klo 1.44 Andreas Beckmann (a...@debian.org) kirjoitti: > > On 2019-01-19 21:14, Andreas Beckmann wrote: > > Getting back to the current case: I assume this is caused by > > libmariadbclient-dev being turned into a virtual package provided by > > libmariadb-dev. I'll test whether reintroducing a transitional package > > would improve the situation. Might require a trip through NEW, though. > > A transitional package would also be needed to provide a smooth upgrade > > path for people that consciously installed libmariadbclient-dev in stretch. > > That seems to work better with a transitional package. > @otto: you can find it in branch anbe/libmariadbclient-dev ACK https://salsa.debian.org/mariadb-team/mariadb-10.3/commit/a61f9d0654cae49f337cb8262be18a1241f30f85 Is there some way for me to test this transition manually? I have tested many times upgrading systems with Stretch/MariaDB 10.1 to Sid/MariaDB 10.3 but did not bump into any issues.
Bug#919395: Heads up to release team about MariadB 10.3
On 2019-01-20 12:04, Otto Kekäläinen wrote: > Is there some way for me to test this transition manually? I have > tested many times upgrading systems with Stretch/MariaDB 10.1 to > Sid/MariaDB 10.3 but did not bump into any issues. I tried this manually in pbuilder/buster to understand what problem britney encountered. I didn't see this in my piuparts tests. # britney reported problems for libmariadbclient-dev # and tried to migrate both src:mariadb-10.3 and src:mysql-defaults apt-get install libmariadbclient-dev default-mysql-client-dev sources.list += sid, apt-get update apt-get install libmariadbclient-dev default-mysql-client-dev # selects 1:10.3.12-1 where available # boom - libmariadbclient-dev is no longer installable, so the migration # would require immediate removal of mariadb-10.1 to succeed which would # have more implications # let's add -2 with the new transitional package sources.list += /tmp/mariadb, apt-get update apt-get install libmariadbclient-dev default-mysql-client-dev # selects -2 # worked fine While on a normal upgrade path libmariadbclient-dev might just get removed, britney actually cares that the installability of the packages in testing does not regress. Andreas
Bug#919395: Heads up to release team about MariadB 10.3
Hi, mariadb-10.3 finally migrated to testing and mariadb-10.1 was just removed from unstable, so it should leave testing soon as well. Please schedule the remaining binNMUs s.t. the packages drop the dependency on the transitional libmariadbclient18 package. Thanks Andreas
Bug#919395: Heads up to release team about MariadB 10.3
On 27/01/2019 15:18, Andreas Beckmann wrote: > Hi, > > mariadb-10.3 finally migrated to testing and mariadb-10.1 was just > removed from unstable, so it should leave testing soon as well. > > Please schedule the remaining binNMUs s.t. the packages drop the > dependency on the transitional libmariadbclient18 package. I have scheduled level 1. Will do level 2 later. Emilio
Bug#919395: Heads up to release team about MariadB 10.3
On 2019-01-28 15:45, Emilio Pozuelo Monfort wrote: >> Please schedule the remaining binNMUs s.t. the packages drop the >> dependency on the transitional libmariadbclient18 package. > > I have scheduled level 1. Will do level 2 later. There is one package not covered by the tracker since it only indirectly depends on default-libmysqlclient-dev. nmu kannel-sqlbox_0.7.2-5 . ANY . unstable . -m "Rebuild against libmariadb3" I'd also like to get rid of the transitional libmariadbclient18 package now, or do you have any objections there? Andreas
Bug#919395: Heads up to release team about MariadB 10.3
On 2019-01-31 13:55, Andreas Beckmann wrote: > There is one package not covered by the tracker since it only > indirectly depends on default-libmysqlclient-dev. > > nmu kannel-sqlbox_0.7.2-5 . ANY . unstable . -m "Rebuild against libmariadb3" Ping? And please give-back lua-sql, the FTBFS is fixed with that latest mariadb-10.3 upload. Andreas
Bug#919395: Heads up to release team about MariadB 10.3
On 08/03/2019 12:48, Andreas Beckmann wrote: > On 2019-01-31 13:55, Andreas Beckmann wrote: >> There is one package not covered by the tracker since it only >> indirectly depends on default-libmysqlclient-dev. >> >> nmu kannel-sqlbox_0.7.2-5 . ANY . unstable . -m "Rebuild against libmariadb3" > > Ping? > > And please give-back lua-sql, the FTBFS is fixed with that latest > mariadb-10.3 upload. Done and done. Emilio
Bug#919395: Heads up to release team about MariadB 10.3
On 08/03/2019 12:48, Andreas Beckmann wrote: > On 2019-01-31 13:55, Andreas Beckmann wrote: >> There is one package not covered by the tracker since it only >> indirectly depends on default-libmysqlclient-dev. >> >> nmu kannel-sqlbox_0.7.2-5 . ANY . unstable . -m "Rebuild against libmariadb3" > > Ping? > > And please give-back lua-sql, the FTBFS is fixed with that latest > mariadb-10.3 upload. > > > Andreas >
Bug#919395: Heads up to release team about MariadB 10.3
Hi, please give-back qt4-x11. A build has succeeded today in my pbuilder sid amd64 and i386 chroot, so this was probably a compiler realted issue, it was failing previously nowhere near mysql/mariadb touching code. gb qt4-x11_4:4.8.7+dfsg-17 . ANY Andreas
Bug#919395: Heads up to release team about MariadB 10.3
On 20/03/2019 00:49, Andreas Beckmann wrote: > Hi, > > please give-back qt4-x11. A build has succeeded today in my pbuilder sid > amd64 and i386 chroot, so this was probably a compiler realted issue, it > was failing previously nowhere near mysql/mariadb touching code. > > gb qt4-x11_4:4.8.7+dfsg-17 . ANY Scheduled. Emilio
Bug#919395: Heads up to release team about MariadB 10.3
Hi, On 2019-03-20 12:28, Emilio Pozuelo Monfort wrote: > On 20/03/2019 00:49, Andreas Beckmann wrote: >> please give-back qt4-x11. A build has succeeded today in my pbuilder sid > Scheduled. That worked. What needs to be done to make the three late binNMUs migrate to testing? Does not seem to happen on its own ... Andreas
Bug#919395: Heads up to release team about MariadB 10.3
Hi, On 3/23/19 2:26 AM, Andreas Beckmann wrote: On 2019-03-20 12:28, Emilio Pozuelo Monfort wrote: On 20/03/2019 00:49, Andreas Beckmann wrote: please give-back qt4-x11. A build has succeeded today in my pbuilder sid Scheduled. That worked. What needs to be done to make the three late binNMUs migrate to testing? Does not seem to happen on its own ... BinNMUs and new binaries also need an unblock during the freeze (this was a fairy recent change in britney), so they didn't migrate on their own. I unblocked them and they migrated. Ivo
Bug#919395: Heads up to release team about MariadB 10.3
Hi, I think with the removal of the transitional libmariadbclient18 from testing we can consider this transition as finished. The corresponding manual tracker should be archived as well, there are only a few sid-only packages left depending on cruft. Andreas
