Re: MySQL 5.5 EOL before Debian 8 LTS ends
> Thinking about this some more, maybe we could attempt this, backporting > security > fixes from MariaDB 10.1 or forward-porting them from MariaDB 5.5 (still > supported until April 2020). That way we don't force any 10.0 -> 10.1 > migration > on our users (though MySQL 5.5 users will still have to migrate). This will be > more work than backporting new upstream releases, but if we limit ourselves to > security fixes and possibly some minor stability fixes, it may be feasible. I am experimenting at https://salsa.debian.org/mariadb-team/mariadb-10.1/commits/jessie if it is feasible to get 10.1 running on Jessie at all. The good news is that it least builds without any modifications. The bad news is that mariadb-common depends on mysql-common (>= 5.6.25) to ensure /usr/share/mysql-common/configure-symlinks is available. Having and indentical mariadb-10.1 package in Jessie and Stretch would decrease the maintenance burden, but Jessie would also need an updated mysql-common package introduced..
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Hi Otto, On Wed, Feb 27, 2019 at 04:32:24PM +0200, Otto Kekäläinen wrote: > > Thinking about this some more, maybe we could attempt this, backporting > > security > > fixes from MariaDB 10.1 or forward-porting them from MariaDB 5.5 (still > > supported until April 2020). That way we don't force any 10.0 -> 10.1 > > migration > > on our users (though MySQL 5.5 users will still have to migrate). This will > > be > > more work than backporting new upstream releases, but if we limit ourselves > > to > > security fixes and possibly some minor stability fixes, it may be feasible. > > I am experimenting at > https://salsa.debian.org/mariadb-team/mariadb-10.1/commits/jessie if > it is feasible to get 10.1 running on Jessie at all. nice. > The good news is that it least builds without any modifications. *g* > The bad news is that mariadb-common depends on mysql-common (>= > 5.6.25) to ensure /usr/share/mysql-common/configure-symlinks is > available. Having and indentical mariadb-10.1 package in Jessie and > Stretch would decrease the maintenance burden, but Jessie would also > need an updated mysql-common package introduced.. adding a new package, if sensible, is something which can be done. and it seems sensible here. -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: MySQL 5.5 EOL before Debian 8 LTS ends
On 03/01/2019 11:20, Emilio Pozuelo Monfort wrote: > On 03/01/2019 10:40, Otto Kekäläinen wrote: >> Hello! >> >> to 3. tammik. 2019 klo 3.40 Robie Basak (robie.ba...@canonical.com) >> kirjoitti: >>> >>> Hi Otto and the LTS team, >>> >>> On Mon, Dec 31, 2018 at 10:50:34AM +0200, Otto Kekäläinen wrote: I think that is *if* makes sense to engineer some automatic upgrade path in an LTS release, then it would be to introduce MariaDB 10.1 into Jessie. >>> >>> If this is explicitly opted in to by users then I have no objection. >>> >>> However since the MySQL -> MariaDB crossgrade is not easily reversible >>> (MariaDB modifies the on-disk schema/format), I don't think this is a >>> good idea to do automatically. Users may, on upgrade past Jessie, choose >>> to continue with MySQL coming from a source that isn't Debian stable >>> (eg. by using unstable, directly from upstream, or a change of >>> distribution). Automatically converting their database to not-MySQL >>> would make that difficult, and would be a violation of the stable >>> release promise for those users. I think that affected users would quite >>> rightly be upset about it. >> >> You can always cross-migrate via logical database dumps as .sql files >> instead of in-place binary files. >> >> Anyway the big question here is does the LTS team want to go through >> the hassle of doing a version upgrade in a stable release. > > The alternative to upgrading to MariaDB 10.1 is to keep supporting 10.0 for > the > lifetime of jessie. Obviously I'd prefer if we could do that for stability > reasons, but I'm not sure we can commit to that without upstream's support. Thinking about this some more, maybe we could attempt this, backporting security fixes from MariaDB 10.1 or forward-porting them from MariaDB 5.5 (still supported until April 2020). That way we don't force any 10.0 -> 10.1 migration on our users (though MySQL 5.5 users will still have to migrate). This will be more work than backporting new upstream releases, but if we limit ourselves to security fixes and possibly some minor stability fixes, it may be feasible. Cheers, Emilio
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Hi If we can avoid migration I think that is the safest approach. I just had a failed upgrade (in current stable) and I'm guessing it can be a problem in other cases too. Migrating through .sql files works, but please note that this can be a very disk and time consuming process. For small databases it is not a big problem but consider that databases can be many GB in size and in such cases the downtime can be considerable, and also it may not even be possible to complete it. However if we do not have any upstream support, maybe we need to go this route. But in such case, maybe we need to check with our sponsors on what kind of databases they have and what kind of migration strategy is feasible for them. // Ola On Thu, 3 Jan 2019 at 11:25, Jan Ingvoldstad wrote: > On 2019-01-03 10:40, Otto Kekäläinen wrote: > > > You can always cross-migrate via logical database dumps as .sql files > > instead of in-place binary files. > > This is not guaranteed to work, and you need to take special care with > mysqldump and mysql options for such migration dumps. > > For instance, if a table contains datetime entries '-00-00 > 00:00:00', or duplicate primary keys, it's not necessarily trivial to > migrate using the ordinary, safe options for migrating. > > -- > Cheers, > Jan > > -- --- Inguza Technology AB --- MSc in Information Technology / o...@inguza.comFolkebogatan 26\ | o...@debian.org 654 68 KARLSTAD| | http://inguza.com/Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: MySQL 5.5 EOL before Debian 8 LTS ends
On 2019-01-03 10:40, Otto Kekäläinen wrote: You can always cross-migrate via logical database dumps as .sql files instead of in-place binary files. This is not guaranteed to work, and you need to take special care with mysqldump and mysql options for such migration dumps. For instance, if a table contains datetime entries '-00-00 00:00:00', or duplicate primary keys, it's not necessarily trivial to migrate using the ordinary, safe options for migrating. -- Cheers, Jan
Re: MySQL 5.5 EOL before Debian 8 LTS ends
On 03/01/2019 10:40, Otto Kekäläinen wrote: > Hello! > > to 3. tammik. 2019 klo 3.40 Robie Basak (robie.ba...@canonical.com) kirjoitti: >> >> Hi Otto and the LTS team, >> >> On Mon, Dec 31, 2018 at 10:50:34AM +0200, Otto Kekäläinen wrote: >>> I think that is *if* makes sense to engineer some automatic upgrade path in >>> an LTS release, then it would be to introduce MariaDB 10.1 into Jessie. >> >> If this is explicitly opted in to by users then I have no objection. >> >> However since the MySQL -> MariaDB crossgrade is not easily reversible >> (MariaDB modifies the on-disk schema/format), I don't think this is a >> good idea to do automatically. Users may, on upgrade past Jessie, choose >> to continue with MySQL coming from a source that isn't Debian stable >> (eg. by using unstable, directly from upstream, or a change of >> distribution). Automatically converting their database to not-MySQL >> would make that difficult, and would be a violation of the stable >> release promise for those users. I think that affected users would quite >> rightly be upset about it. > > You can always cross-migrate via logical database dumps as .sql files > instead of in-place binary files. > > Anyway the big question here is does the LTS team want to go through > the hassle of doing a version upgrade in a stable release. The alternative to upgrading to MariaDB 10.1 is to keep supporting 10.0 for the lifetime of jessie. Obviously I'd prefer if we could do that for stability reasons, but I'm not sure we can commit to that without upstream's support. > I've tested that the current mariadb-10.1 version in Stretch also > builds in Jessie as-is > (https://salsa.debian.org/mariadb-team/mariadb-10.1/-/jobs), but some > work should be invested into properly write gitlab-ci.yml tests and > automation to ensure there are a minimal amount of surprises if real > systems go though an upgrade. Anyway, as a first step MariaDB 10.1 > should be put into jessie-backports so that those who want to opt-in > for such a move right now, could do it. Do we have any contributors > who would like to help out with this task? jessie-backports is closed to new uploads[1]. We could put test packages on people.debian.org and request feedback. Cheers, Emilio [1] https://lists.debian.org/debian-backports-announce/2018/07/msg0.html
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Hello! to 3. tammik. 2019 klo 3.40 Robie Basak (robie.ba...@canonical.com) kirjoitti: > > Hi Otto and the LTS team, > > On Mon, Dec 31, 2018 at 10:50:34AM +0200, Otto Kekäläinen wrote: > > I think that is *if* makes sense to engineer some automatic upgrade path in > > an LTS release, then it would be to introduce MariaDB 10.1 into Jessie. > > If this is explicitly opted in to by users then I have no objection. > > However since the MySQL -> MariaDB crossgrade is not easily reversible > (MariaDB modifies the on-disk schema/format), I don't think this is a > good idea to do automatically. Users may, on upgrade past Jessie, choose > to continue with MySQL coming from a source that isn't Debian stable > (eg. by using unstable, directly from upstream, or a change of > distribution). Automatically converting their database to not-MySQL > would make that difficult, and would be a violation of the stable > release promise for those users. I think that affected users would quite > rightly be upset about it. You can always cross-migrate via logical database dumps as .sql files instead of in-place binary files. Anyway the big question here is does the LTS team want to go through the hassle of doing a version upgrade in a stable release. I've tested that the current mariadb-10.1 version in Stretch also builds in Jessie as-is (https://salsa.debian.org/mariadb-team/mariadb-10.1/-/jobs), but some work should be invested into properly write gitlab-ci.yml tests and automation to ensure there are a minimal amount of surprises if real systems go though an upgrade. Anyway, as a first step MariaDB 10.1 should be put into jessie-backports so that those who want to opt-in for such a move right now, could do it. Do we have any contributors who would like to help out with this task?
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Hi Otto and the LTS team, On Mon, Dec 31, 2018 at 10:50:34AM +0200, Otto Kekäläinen wrote: > I think that is *if* makes sense to engineer some automatic upgrade path in > an LTS release, then it would be to introduce MariaDB 10.1 into Jessie. If this is explicitly opted in to by users then I have no objection. However since the MySQL -> MariaDB crossgrade is not easily reversible (MariaDB modifies the on-disk schema/format), I don't think this is a good idea to do automatically. Users may, on upgrade past Jessie, choose to continue with MySQL coming from a source that isn't Debian stable (eg. by using unstable, directly from upstream, or a change of distribution). Automatically converting their database to not-MySQL would make that difficult, and would be a violation of the stable release promise for those users. I think that affected users would quite rightly be upset about it. Robie signature.asc Description: PGP signature
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Hello Debian LTS team! I think that is *if* makes sense to engineer some automatic upgrade path in an LTS release, then it would be to introduce MariaDB 10.1 into Jessie. Upgrading from MySQL 5.5 and MariaDB 10.0 to MariaDB 10.1 is pretty safe, and the maintenance period of MariaDB 10.1 would match the Debian LTS needs. MariaDB 10.1 is very stable, and already maintained in Stretch anyway. MariaDB 10.1 also has a good track record of being used for a massive MySQL 5.5 -> and MariaDB 10.0 -> upgrades, so it definitely is the least risky of the upgrade options now and in the long term. However, if such a feat is attempted, there should be extensive (and automatic) testing first. In order to prepare that I filed a MR on the Salsa-CI system that jessie would be a supported target for Salsa-CI in the first place.. https://salsa.debian.org/salsa-ci-team/images/merge_requests/26 If any of the Debian LTS members have write permissions to the Salsa-CI-team repos, please merge :)
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Hello! pe 28. jouluk. 2018 klo 9.27 Jan Ingvoldstad (jan-debian-lts-2...@oyet.no) kirjoitti: > > On 2018-12-27 18:51, Lars Tangvald wrote: > > > Upgrading to 5.6 would be less risky than MariaDB 10.1, but it's a > > similar sort of risk. > > I don't know what the risk with switching to MariaDB 10.1 would be, but > as a general principle, MariaDB lags behind (the already annoyingly > delayed) Oracle security patches often days, sometimes weeks. Just to set facts clear: most of the Oracle CVE's are fixed in MariaDB releases way before the Oracle releases, some times even 6 months ahead. What happens when the Oracle CVEs are released is to a large degree just an update to the list of CVEs on what version of MariaDB fixed what. Sometimes there for sure are cases when Oracle publishes something first, but it would be very wrong to say that MariaDB is in any way 'annoyingly delayed'. If we take as an example MySQL 5.5.62 released on 2018-10-22, it contained the following CVE fixes: - CVE-2018-3133 - Fixed in MariaDB 5.5.59 released on 2018-01-19 - CVE-2018-3174 - Fixed in MariaDB 5.5.62 released on 2018-10-26 - CVE-2018-3282 - Fixed in MariaDB 5.5.62 released on 2018-10-26 Source: https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-62.html https://mariadb.com/kb/en/library/mariadb-5559-release-notes/ https://mariadb.com/kb/en/library/mariadb-5562-release-notes/ https://mariadb.com/kb/en/library/security/ However, the severity if these CVEs vary very much and there are many details that blur what should be used as a relevant argument and what not, so I would not use this as a main factor in the decision. > Based on our experience with a few thousand databases, though, upgrading > from 5.5 to 5.6 is as good as invisible for DB users and software using > MySQL. > > A few users noticed the differences between MySQL 5.5 and MariaDB 10.0 > (5.6-based), nearly no-one noticed the upgrade from MariaDB 10.0 to 10.3. MariaDB has a tradition of honoring backwards compatibility, thus the upgrade from 10.0 to 10.3 should go pretty smooth, but to be safe we should maybe build some gitlab-ci.yml file to test this particular scenario extensively to be safer. Pull requests on https://salsa.debian.org/mariadb-team/mariadb-10.3/pipelines are welcome :) > It would be very welcome if upgrade scripts in Debian would substitute > configuration options correctly, with the usual dselect option list of > "compare, keep current, install package maintainer's" versions. Good idea! Would you want to contribute such functionality to the MariaDB preinstall scripts (or even upstream mariadb_upgrade binary)? https://wiki.debian.org/Teams/MySQL/patches https://mariadb.org/get-involved/ > The risk mostly lies in software relying on the removed features listed > in the URL you linked > (https://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html#mysql-nutshell-removals). > > As a side note, anyone using MySQL WorkBench with MariaDB 10.x or MySQL > 5.5 will probably be very annoyed about the version warnings. I expect > the current issues with 5.6 compatibility alerts to be fixed. :) This "bug" has been known for years and it does not look like Oracle will fix their product to be any more MariaDB-compatible (https://www.mysql.com/products/workbench/). Only thing here is to either patch it in Debian, or suggest users to migrate to alternatives (https://mariadb.com/kb/en/library/graphical-and-enhanced-clients/).
Re: MySQL 5.5 EOL before Debian 8 LTS ends
On 2018-12-27 18:51, Lars Tangvald wrote: Upgrading to 5.6 would be less risky than MariaDB 10.1, but it's a similar sort of risk. I don't know what the risk with switching to MariaDB 10.1 would be, but as a general principle, MariaDB lags behind (the already annoyingly delayed) Oracle security patches often days, sometimes weeks. Based on our experience with a few thousand databases, though, upgrading from 5.5 to 5.6 is as good as invisible for DB users and software using MySQL. A few users noticed the differences between MySQL 5.5 and MariaDB 10.0 (5.6-based), nearly no-one noticed the upgrade from MariaDB 10.0 to 10.3. It would be very welcome if upgrade scripts in Debian would substitute configuration options correctly, with the usual dselect option list of "compare, keep current, install package maintainer's" versions. The risk mostly lies in software relying on the removed features listed in the URL you linked (https://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html#mysql-nutshell-removals). As a side note, anyone using MySQL WorkBench with MariaDB 10.x or MySQL 5.5 will probably be very annoyed about the version warnings. I expect the current issues with 5.6 compatibility alerts to be fixed. :) -- Cheers, Jan
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Hi, On 19.12.2018 17:01, Holger Levsen wrote: Hi Emilio, thanks for bringing up this issue on the LTS list. On Mon, Dec 17, 2018 at 10:49:57AM +0100, Emilio Pozuelo Monfort wrote: MySQL 5.5 should be EOL this month if nothing has changed, although I don't see an announcement on [1] yet. Maybe it will be published next month when the next CPU (critical patch update) is released. Norvald, do you know if 5.5 is effectively EOL already? Or will it receive another update next month? [Norvald replied, saying that 5.5.62 in October was the last 5.5 release.] Right. 5.5.62 was the final 5.5 release. Also note that mariadb 10.0 is EOL in three months[2]. I think this rules out mariadb 10.0 as a sensible upgrade path here. (Also, switching from mysql to mariadb in an LTS security upload???) I don't think it makes much sense to upload mysql-5.6, since stretch has no mysql at all. Since users will have to migrate to MariaDB anyway (or to externally provided MySQL packages if they so choose), they can do so now. following that logic they could also upgrade to Stretch now... :) For mariadb 10.0, we may be able to backport important security fixes, or we could backport 10.1 which will be supported upstream until October 2020. I would lean towards one of those last two options. I think I'm rather *leaning* towards mysql-5.6 or declaring mysql-5.5 unsupported/EOL in jessie, but that's really leaning, nothing more. (And then I believe mysql-5.6 in jessie isnt simple/feasable neither, so... :/ Other comments/suggestions? Upgrading to 5.6 would be less risky than MariaDB 10.1, but it's a similar sort of risk. Building: Since both 5.5 and 5.6 have libmysqlclient18 I don't expect many issues, but 5.6 and 5.5 "leaked" symbols, so even internal symbols were published. Third-party packages using internal symbols in 5.5 may fail to build with 5.6. User experience: 5.5 and 5.6 will be very similar for most users (particularly, init scripts in third-party packages shouldn't be impacted), but anyone still using jessie and 5.5 may have pretty strict stability requirements. There's a summary of changes here: https://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html -- Lars
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Hello! ke 19. jouluk. 2018 klo 18.01 Holger Levsen (hol...@layer-acht.org) kirjoitti: > > Also note that mariadb 10.0 is EOL in three months[2]. > > I think this rules out mariadb 10.0 as a sensible upgrade path here. > (Also, switching from mysql to mariadb in an LTS security upload???) Do we have any stats on how large the Debian 8 installation base is? I guess we could try to push for an extended maintenance or at least security update period for it if there are compelling arguments. Note that the Ubuntu 16.04 LTS release also has MariaDB 10.0.
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Hi Emilio, thanks for bringing up this issue on the LTS list. On Mon, Dec 17, 2018 at 10:49:57AM +0100, Emilio Pozuelo Monfort wrote: > MySQL 5.5 should be EOL this month if nothing has changed, although I don't > see > an announcement on [1] yet. Maybe it will be published next month when the > next > CPU (critical patch update) is released. Norvald, do you know if 5.5 is > effectively EOL already? Or will it receive another update next month? [Norvald replied, saying that 5.5.62 in October was the last 5.5 release.] > Also note that mariadb 10.0 is EOL in three months[2]. I think this rules out mariadb 10.0 as a sensible upgrade path here. (Also, switching from mysql to mariadb in an LTS security upload???) > I don't think it makes much sense to upload mysql-5.6, since stretch has no > mysql at all. Since users will have to migrate to MariaDB anyway (or to > externally provided MySQL packages if they so choose), they can do so now. following that logic they could also upgrade to Stretch now... :) > For mariadb 10.0, we may be able to backport important security fixes, or we > could backport 10.1 which will be supported upstream until October 2020. > > I would lean towards one of those last two options. I think I'm rather *leaning* towards mysql-5.6 or declaring mysql-5.5 unsupported/EOL in jessie, but that's really leaning, nothing more. (And then I believe mysql-5.6 in jessie isnt simple/feasable neither, so... :/ Other comments/suggestions? -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: MySQL 5.5 EOL before Debian 8 LTS ends
On Mon, 17 Dec 2018 10:49:57 +0100 Emilio Pozuelo Monfort wrote: > MySQL 5.5 should be EOL this month if nothing has changed, although I > don't see an announcement on [1] yet. Maybe it will be published next > month when the next CPU (critical patch update) is released. Norvald, > do you know if 5.5 is effectively EOL already? Or will it receive > another update next month? It will not. The plan is to stop on 5.5.62 (released in October). Best regards, Norvald
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Hi, On 22/05/2018 07:10, Lars Tangvald wrote: > > > On 05/21/2018 03:22 PM, Matus UHLAR - fantomas wrote: Am 22.01.2018 um 13:42 schrieb Lars Tangvald: > First off, thanks for handling the 5.5.59 update for Wheezy. I had the > security announcement date mixed up so picked it up too late, sorry. > > MySQL 5.5 is expected to be EOL in December (it was first released > December 15, 2010, and we have 8 year security support), while Jessie > LTS is until April 2020 > How are such cases handled? Will the source package be removed, or is it > possible to have it upgraded to a more recent version? >> >>> On 22/01/18 16:35, Markus Koschany wrote: These are both possible options but given the significance of MySQL we would rather prefer to upgrade to a supported release provided this is viable for Jessie. >> > If an upgrade is possible, while we did a successful transition in > Ubuntu from 5.5 to 5.7, there were significant changes from 5.6 to 5.7, > requiring small changes to a lot of third-party packages as well as to > the default server behavior, so 5.6 (which is supported until 2021) > would be a better option. >> I also think it makes sense to take a smaller step and upgrade from 5.5 to 5.6. Are there any known issues with 5.6 or can you share any information about expected regressions with reverse-dependencies? >> >> On 19.05.18 20:41, Emilio Pozuelo Monfort wrote: >>> jessie ships mysql-5.5 and mariadb-10.0. Given that stretch no longer ships >>> mysql but only mariadb, we could just let mysql-5.5 go end of life, mark it >>> as >>> unsupported (or drop the server part), and keep supporting mariadb-10.0. >>> Users >>> will need to move to mariadb at some point anyway. The only problem is that >>> mariadb-10.0 goes EOL on March 2019. mariadb-10.1 is EOL on October 2020, >>> so if >>> we decided to provide that in jessie that would be enough. >> >> There are packages in jessie that depend on mysql (or libmysql), not on >> mariadb. >> >> IMHO If it's possible to migrate to mysql-5.6 and later from mysql-5.6 to >> stretch, it would be a better alternative than deprecate it. >> > If we can agree on this, I can work on updating the packaging (we did have 5.6 > in sid at one point, but would need to check that it didn't have any big > changes). > > Otto: MariaDB 10.1 supports migration from MySQL 5.6, right? This would be > important for users later upgrading to Stretch. MySQL 5.5 should be EOL this month if nothing has changed, although I don't see an announcement on [1] yet. Maybe it will be published next month when the next CPU (critical patch update) is released. Norvald, do you know if 5.5 is effectively EOL already? Or will it receive another update next month? Also note that mariadb 10.0 is EOL in three months[2]. I don't think it makes much sense to upload mysql-5.6, since stretch has no mysql at all. Since users will have to migrate to MariaDB anyway (or to externally provided MySQL packages if they so choose), they can do so now. For mariadb 10.0, we may be able to backport important security fixes, or we could backport 10.1 which will be supported upstream until October 2020. I would lean towards one of those last two options. Cheers, Emilio [1] https://www.mysql.com/support/eol-notice.html [2] https://mariadb.org/about/maintenance-policy/
Re: MySQL 5.5 EOL before Debian 8 LTS ends
On 05/21/2018 03:22 PM, Matus UHLAR - fantomas wrote: Am 22.01.2018 um 13:42 schrieb Lars Tangvald: First off, thanks for handling the 5.5.59 update for Wheezy. I had the security announcement date mixed up so picked it up too late, sorry. MySQL 5.5 is expected to be EOL in December (it was first released December 15, 2010, and we have 8 year security support), while Jessie LTS is until April 2020 How are such cases handled? Will the source package be removed, or is it possible to have it upgraded to a more recent version? On 22/01/18 16:35, Markus Koschany wrote: These are both possible options but given the significance of MySQL we would rather prefer to upgrade to a supported release provided this is viable for Jessie. If an upgrade is possible, while we did a successful transition in Ubuntu from 5.5 to 5.7, there were significant changes from 5.6 to 5.7, requiring small changes to a lot of third-party packages as well as to the default server behavior, so 5.6 (which is supported until 2021) would be a better option. I also think it makes sense to take a smaller step and upgrade from 5.5 to 5.6. Are there any known issues with 5.6 or can you share any information about expected regressions with reverse-dependencies? On 19.05.18 20:41, Emilio Pozuelo Monfort wrote: jessie ships mysql-5.5 and mariadb-10.0. Given that stretch no longer ships mysql but only mariadb, we could just let mysql-5.5 go end of life, mark it as unsupported (or drop the server part), and keep supporting mariadb-10.0. Users will need to move to mariadb at some point anyway. The only problem is that mariadb-10.0 goes EOL on March 2019. mariadb-10.1 is EOL on October 2020, so if we decided to provide that in jessie that would be enough. There are packages in jessie that depend on mysql (or libmysql), not on mariadb. IMHO If it's possible to migrate to mysql-5.6 and later from mysql-5.6 to stretch, it would be a better alternative than deprecate it. If we can agree on this, I can work on updating the packaging (we did have 5.6 in sid at one point, but would need to check that it didn't have any big changes). Otto: MariaDB 10.1 supports migration from MySQL 5.6, right? This would be important for users later upgrading to Stretch. -- Lars
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Am 22.01.2018 um 13:42 schrieb Lars Tangvald: First off, thanks for handling the 5.5.59 update for Wheezy. I had the security announcement date mixed up so picked it up too late, sorry. MySQL 5.5 is expected to be EOL in December (it was first released December 15, 2010, and we have 8 year security support), while Jessie LTS is until April 2020 How are such cases handled? Will the source package be removed, or is it possible to have it upgraded to a more recent version? On 22/01/18 16:35, Markus Koschany wrote: These are both possible options but given the significance of MySQL we would rather prefer to upgrade to a supported release provided this is viable for Jessie. If an upgrade is possible, while we did a successful transition in Ubuntu from 5.5 to 5.7, there were significant changes from 5.6 to 5.7, requiring small changes to a lot of third-party packages as well as to the default server behavior, so 5.6 (which is supported until 2021) would be a better option. I also think it makes sense to take a smaller step and upgrade from 5.5 to 5.6. Are there any known issues with 5.6 or can you share any information about expected regressions with reverse-dependencies? On 19.05.18 20:41, Emilio Pozuelo Monfort wrote: jessie ships mysql-5.5 and mariadb-10.0. Given that stretch no longer ships mysql but only mariadb, we could just let mysql-5.5 go end of life, mark it as unsupported (or drop the server part), and keep supporting mariadb-10.0. Users will need to move to mariadb at some point anyway. The only problem is that mariadb-10.0 goes EOL on March 2019. mariadb-10.1 is EOL on October 2020, so if we decided to provide that in jessie that would be enough. There are packages in jessie that depend on mysql (or libmysql), not on mariadb. IMHO If it's possible to migrate to mysql-5.6 and later from mysql-5.6 to stretch, it would be a better alternative than deprecate it. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Boost your system's speed by 500% - DEL C:\WINDOWS\*.*
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Hi, On 01/23/2018 10:32 PM, Markus Koschany wrote: Am 23.01.2018 um 11:41 schrieb Lars Tangvald: Hi, On 01/22/2018 04:35 PM, Markus Koschany wrote: [...] I also think it makes sense to take a smaller step and upgrade from 5.5 to 5.6. Are there any known issues with 5.6 or can you share any information about expected regressions with reverse-dependencies? I can't find much of anything that has changed from 5.5 to 5.6 in terms of default behavior, except for NO_ENGINE_SUBSTITUTION being the default sql_mode (https://dev.mysql.com/doc/refman/5.6/en/sql-mode.html#sqlmode_no_engine_substitution). I'll do some more digging, but I don't think there should be much impact on reverse-dependencies. Some options were removed https://dev.mysql.com/doc/refman/5.6/en/server-options.html (often renamed). We did see quite a few regressions of that type for users upgrading from 5.5 to 5.7, but almost all were because the default 5.5 config in Ubuntu packaging contained options that were removed in 5.7. What do you (and other on this list) think about the following plan: We could introduce a mysql-5.6 package already at the start of Jessie LTS in June, so that LTS users are able to test this new version without having to switch from 5.5. Then in 2019, when the security support for MySQL has ended, we perform an upgrade from 5.5 to 5.6. Is this a viable plan and could both packages coexist? Regards, Markus Ubuntu 14.04 something like this; 5.6 is available but 5.5 is the default. This works for the packages with versioned names: server, client and testsuite, while the rest would be dropped from the 5.6 source. Robie, this was implemented before my time, but I seem to remember comments about it causing some issues in Ubuntu. Do you recall what that was? -- Lars
Re: MySQL 5.5 EOL before Debian 8 LTS ends
On 01/24/2018 08:02 AM, Moritz Mühlenhoff wrote: On Tue, Jan 23, 2018 at 11:41:57AM +0100, Lars Tangvald wrote: I can't find much of anything that has changed from 5.5 to 5.6 in terms of default behavior, except for NO_ENGINE_SUBSTITUTION being the default sql_mode (https://dev.mysql.com/doc/refman/5.6/en/sql-mode.html#sqlmode_no_engine_substitution). I'll do some more digging, but I don't think there should be much impact on reverse-dependencies. Some options were removed https://dev.mysql.com/doc/refman/5.6/en/server-options.html (often renamed). We did see quite a few regressions of that type for users upgrading from 5.5 to 5.7, but almost all were because the default 5.5 config in Ubuntu packaging contained options that were removed in 5.7. That sounds far too disruptive for an LTS; better declare announce the server part of mysql (where all the vulnerabilities apply) as unsupported in advance and in December change the package to only build the libmysqlclient parts. The client library part is usually not affected by any security issues and that way you don't risk any regressions. Usually, yes, but what happens when this is not the case? Keep in mind that the issues we got reported in Ubuntu was because the removed options were in the 5.5 default config file shipped in Ubuntu. There's no such settings in the 5.5 to 5.6 upgrade. People then have a year to migrate their servers to jessie (or ideally update/reimage to stretch) This is about Jessie, which currently has 5.5. -- Lars Cheers, Moritz
Re: MySQL 5.5 EOL before Debian 8 LTS ends
On 2018-01-24 08:02, Moritz Mühlenhoff wrote: That sounds far too disruptive for an LTS; better declare announce the server part of mysql (where all the vulnerabilities apply) as unsupported in advance and in December change the package to only build the libmysqlclient parts. The client library part is usually not affected by any security issues and that way you don't risk any regressions. People then have a year to migrate their servers to jessie (or ideally update/reimage to stretch) Additionally, Oracle already provides MySQL 5.6 for both Wheezy and Jessie according to https://dev.mysql.com/downloads/repo/apt/, so there appears to be little need for the LTS team to make a specific effort to support MySQL 5.6 server when 5.5 security support reaches EOL. Or are there plans in Oracle to drop support for old-stable etc.? -- Cheers, Jan
Re: MySQL 5.5 EOL before Debian 8 LTS ends
On Tue, Jan 23, 2018 at 11:41:57AM +0100, Lars Tangvald wrote: > I can't find much of anything that has changed from 5.5 to 5.6 in terms of > default behavior, except for NO_ENGINE_SUBSTITUTION being the default > sql_mode > (https://dev.mysql.com/doc/refman/5.6/en/sql-mode.html#sqlmode_no_engine_substitution). > I'll do some more digging, but I don't think there should be much impact on > reverse-dependencies. > > Some options were removed > https://dev.mysql.com/doc/refman/5.6/en/server-options.html (often renamed). > We did see quite a few regressions of that type for users upgrading from 5.5 > to 5.7, but almost all were because the default 5.5 config in Ubuntu > packaging contained options that were removed in 5.7. That sounds far too disruptive for an LTS; better declare announce the server part of mysql (where all the vulnerabilities apply) as unsupported in advance and in December change the package to only build the libmysqlclient parts. The client library part is usually not affected by any security issues and that way you don't risk any regressions. People then have a year to migrate their servers to jessie (or ideally update/reimage to stretch) Cheers, Moritz
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Am 23.01.2018 um 11:41 schrieb Lars Tangvald: > Hi, > > On 01/22/2018 04:35 PM, Markus Koschany wrote: [...] >> I also think it makes sense to take a smaller step and upgrade from 5.5 >> to 5.6. Are there any known issues with 5.6 or can you share any >> information about expected regressions with reverse-dependencies? > I can't find much of anything that has changed from 5.5 to 5.6 in terms > of default behavior, except for NO_ENGINE_SUBSTITUTION being the default > sql_mode > (https://dev.mysql.com/doc/refman/5.6/en/sql-mode.html#sqlmode_no_engine_substitution). > I'll do some more digging, but I don't think there should be much impact > on reverse-dependencies. > > Some options were removed > https://dev.mysql.com/doc/refman/5.6/en/server-options.html (often > renamed). We did see quite a few regressions of that type for users > upgrading from 5.5 to 5.7, but almost all were because the default 5.5 > config in Ubuntu packaging contained options that were removed in 5.7. What do you (and other on this list) think about the following plan: We could introduce a mysql-5.6 package already at the start of Jessie LTS in June, so that LTS users are able to test this new version without having to switch from 5.5. Then in 2019, when the security support for MySQL has ended, we perform an upgrade from 5.5 to 5.6. Is this a viable plan and could both packages coexist? Regards, Markus signature.asc Description: OpenPGP digital signature
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Hi, On 01/22/2018 04:35 PM, Markus Koschany wrote: Hi, Am 22.01.2018 um 13:42 schrieb Lars Tangvald: Hi, First off, thanks for handling the 5.5.59 update for Wheezy. I had the security announcement date mixed up so picked it up too late, sorry. MySQL 5.5 is expected to be EOL in December (it was first released December 15, 2010, and we have 8 year security support), while Jessie LTS is until April 2020 How are such cases handled? Will the source package be removed, or is it possible to have it upgraded to a more recent version? These are both possible options but given the significance of MySQL we would rather prefer to upgrade to a supported release provided this is viable for Jessie. If an upgrade is possible, while we did a successful transition in Ubuntu from 5.5 to 5.7, there were significant changes from 5.6 to 5.7, requiring small changes to a lot of third-party packages as well as to the default server behavior, so 5.6 (which is supported until 2021) would be a better option. I also think it makes sense to take a smaller step and upgrade from 5.5 to 5.6. Are there any known issues with 5.6 or can you share any information about expected regressions with reverse-dependencies? I can't find much of anything that has changed from 5.5 to 5.6 in terms of default behavior, except for NO_ENGINE_SUBSTITUTION being the default sql_mode (https://dev.mysql.com/doc/refman/5.6/en/sql-mode.html#sqlmode_no_engine_substitution). I'll do some more digging, but I don't think there should be much impact on reverse-dependencies. Some options were removed https://dev.mysql.com/doc/refman/5.6/en/server-options.html (often renamed). We did see quite a few regressions of that type for users upgrading from 5.5 to 5.7, but almost all were because the default 5.5 config in Ubuntu packaging contained options that were removed in 5.7. -- Lars Regards, Markus
Re: MySQL 5.5 EOL before Debian 8 LTS ends
Hi, Am 22.01.2018 um 13:42 schrieb Lars Tangvald: > Hi, > > First off, thanks for handling the 5.5.59 update for Wheezy. I had the > security announcement date mixed up so picked it up too late, sorry. > > MySQL 5.5 is expected to be EOL in December (it was first released > December 15, 2010, and we have 8 year security support), while Jessie > LTS is until April 2020 > How are such cases handled? Will the source package be removed, or is it > possible to have it upgraded to a more recent version? These are both possible options but given the significance of MySQL we would rather prefer to upgrade to a supported release provided this is viable for Jessie. > If an upgrade is possible, while we did a successful transition in > Ubuntu from 5.5 to 5.7, there were significant changes from 5.6 to 5.7, > requiring small changes to a lot of third-party packages as well as to > the default server behavior, so 5.6 (which is supported until 2021) > would be a better option. I also think it makes sense to take a smaller step and upgrade from 5.5 to 5.6. Are there any known issues with 5.6 or can you share any information about expected regressions with reverse-dependencies? Regards, Markus signature.asc Description: OpenPGP digital signature
MySQL 5.5 EOL before Debian 8 LTS ends
Hi, First off, thanks for handling the 5.5.59 update for Wheezy. I had the security announcement date mixed up so picked it up too late, sorry. MySQL 5.5 is expected to be EOL in December (it was first released December 15, 2010, and we have 8 year security support), while Jessie LTS is until April 2020 How are such cases handled? Will the source package be removed, or is it possible to have it upgraded to a more recent version? If an upgrade is possible, while we did a successful transition in Ubuntu from 5.5 to 5.7, there were significant changes from 5.6 to 5.7, requiring small changes to a lot of third-party packages as well as to the default server behavior, so 5.6 (which is supported until 2021) would be a better option. -- Lars
