Re: MySQL 5.5 EOL before Debian 8 LTS ends

2019-02-27 Thread Otto Kekäläinen
> 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

2019-02-27 Thread Holger Levsen
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

2019-02-01 Thread Emilio Pozuelo Monfort
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

2019-01-07 Thread Ola Lundqvist
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

2019-01-03 Thread Jan Ingvoldstad

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

2019-01-03 Thread Emilio Pozuelo Monfort
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

2019-01-03 Thread Otto Kekäläinen
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

2019-01-02 Thread Robie Basak
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

2018-12-31 Thread Otto Kekäläinen
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

2018-12-29 Thread Otto Kekäläinen
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

2018-12-27 Thread Jan Ingvoldstad

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

2018-12-27 Thread Lars Tangvald

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

2018-12-19 Thread Otto Kekäläinen
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

2018-12-19 Thread Holger Levsen
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

2018-12-17 Thread Norvald H. Ryeng
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

2018-12-17 Thread Emilio Pozuelo Monfort
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

2018-05-22 Thread Lars Tangvald



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

2018-05-21 Thread Matus UHLAR - fantomas

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

2018-05-19 Thread Emilio Pozuelo Monfort
On 22/01/18 16:35, 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?

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.

(Just giving some more options here.)

Emilio



Re: MySQL 5.5 EOL before Debian 8 LTS ends

2018-02-07 Thread Lars Tangvald

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

2018-01-24 Thread Lars Tangvald



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

2018-01-23 Thread Jan Ingvoldstad

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

2018-01-23 Thread Moritz Mühlenhoff
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

2018-01-23 Thread Markus Koschany


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

2018-01-23 Thread Lars Tangvald

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

2018-01-22 Thread Markus Koschany
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