Re: [debian-mysql] Fixing the jessie->stretch upgrade path

[Norvald H. Ryeng]

On Fri, 12 May 2017 14:09:02 +0200
Ondřej Surý <ond...@sury.org> wrote:

> On Fri, May 12, 2017, at 13:31, Norvald H. Ryeng wrote:
> > On Fri, 12 May 2017 11:26:13 +0200
> > Ondřej Surý <ond...@sury.org> wrote:
> >   
> > > Dear release team and fellow MySQL/MariaDB maintainers,
> > > 
> > > the situation in stretch in regards to clean upgrade path from
> > > jessie is a little bit unfortunate. It works for most cases when
> > > something depends on default-mysql-server and pulls it as a
> > > dependency. But in situations where mysql-server was the top
> > > dependency, it simply uninstalls mysql-server-5.5 without any
> > > replacement.
> > > 
> > > I understand the reasons why we are here, but the situation where
> > > user needs to do:
> > > apt-get update
> > > # apt-get upgrade
> > > apt-get install default-mysql-server
> > > apt-get dist-upgrade
> > > 
> > > is very inconvenient for the users and I foresee this will cause
> > > a lot of complaints, because it's quite common to run just
> > > "mysql-server" on the server.
> > > 
> > > Therefore I am proposing a one time fix specifically targeted at
> > > stretch. I would like to prepare 'mysql-transitional' package that
> > > will create a couple of dummy/transitional packages structured
> > > like this:
> > > 
> > > mysql-server depends on default-mysql-server
> > > mysql-client depends on default-mysql-client
> > > 
> > > The version would be 5.5.999+mariadb, so it is always higher than
> > > version in jessie, but always lower than version in sid, as I
> > > don't want force epoch on mysql-5.7.  
> > 
> > I agree that this sounds like it will work for stretch, and it's
> > much better than bumping epoch on mysql-5.7.
> > 
> > As you say, it's a one time fix, but I'm a bit concerned about what
> > happens when those packages again are provided by MySQL. Let's think
> > through what will happen in buster. There are three options:  
> 
> And all of them would be easily solved by having the
> mariadb-server-10.X and mariadb-client-10.X Conflicts with
> mysql-server and mysql-client.

And as long as MySQL and MariaDB are not co-installable, they should
conflict. But below you say we must make the packages co-installable
to have both I'm a bit confused. Can you please elaborate?

> > 1) Buster contains only MariaDB. Will these packages also be in
> > buster? If not, what happens on upgrade from stretch to buster?
> > Will we have the same problem again?  
> 
> default-mysql-* will already be installed, it will pull new
> mariadb-*-10.x packages and mysql-server/mysql-client will be removed.
> Nothing must depend on mysql-server/mysql-client already, so those
> will be just dangling packages ready to be removed.
> 
> > 2) Buster contains both MySQL and MariaDB. MariaDB is default. The
> > mysql-server and mysql-client packages are provided by MySQL, but
> > default-mysql-server and default-mysql-client point to MariaDB. How
> > will the upgrade go? Some users have installed mysql-server or
> > mysql-client explicitly, while others have installed a different
> > package that depends on default-mysql-server or
> > default-mysql-client.  
> 
> I don't think this is going to happen, but if it does, we will have to
> make MariaDB and MySQL coinstallable with each other, because the
> packages might depend on specific flavour.

The default is to include MySQL in buster. The release team only made a
decision about stretch, so unless they make a new decision, MySQL will
be in buster. Therefore, we have to handle this case.

That said, I definitely wouldn't mind making the packages
co-installable, no matter what ends up in which version of Debian.

Best regards,

Norvald H. Ryeng

Re: [debian-mysql] Fixing the jessie->stretch upgrade path

[Norvald H. Ryeng]

On Fri, 12 May 2017 11:26:13 +0200
Ondřej Surý  wrote:

> Dear release team and fellow MySQL/MariaDB maintainers,
> 
> the situation in stretch in regards to clean upgrade path from jessie
> is a little bit unfortunate. It works for most cases when something
> depends on default-mysql-server and pulls it as a dependency. But in
> situations where mysql-server was the top dependency, it simply
> uninstalls mysql-server-5.5 without any replacement.
> 
> I understand the reasons why we are here, but the situation where user
> needs to do:
> apt-get update
> # apt-get upgrade
> apt-get install default-mysql-server
> apt-get dist-upgrade
> 
> is very inconvenient for the users and I foresee this will cause a lot
> of complaints, because it's quite common to run just "mysql-server" on
> the server.
> 
> Therefore I am proposing a one time fix specifically targeted at
> stretch. I would like to prepare 'mysql-transitional' package that
> will create a couple of dummy/transitional packages structured like
> this:
> 
> mysql-server depends on default-mysql-server
> mysql-client depends on default-mysql-client
> 
> The version would be 5.5.999+mariadb, so it is always higher than
> version in jessie, but always lower than version in sid, as I don't
> want force epoch on mysql-5.7.

I agree that this will work for stretch.

You say it's a one time fix, but I'm a bit concerned about what
happens after this fix, when those packages are provided by MySQL. Let's
think through what will happen in buster. There are three options:

1) Buster contains only MariaDB. Will these packages also be in buster?

2) Buster contains both MySQL and MariaDB. MariaDB is default. The
mysql-server and mysql-clienpackages are provided by MySQL

Re: [debian-mysql] Fixing the jessie->stretch upgrade path

[Norvald H. Ryeng]

On Fri, 12 May 2017 11:26:13 +0200
Ondřej Surý <ond...@sury.org> wrote:

> Dear release team and fellow MySQL/MariaDB maintainers,
> 
> the situation in stretch in regards to clean upgrade path from jessie
> is a little bit unfortunate. It works for most cases when something
> depends on default-mysql-server and pulls it as a dependency. But in
> situations where mysql-server was the top dependency, it simply
> uninstalls mysql-server-5.5 without any replacement.
> 
> I understand the reasons why we are here, but the situation where user
> needs to do:
> apt-get update
> # apt-get upgrade
> apt-get install default-mysql-server
> apt-get dist-upgrade
> 
> is very inconvenient for the users and I foresee this will cause a lot
> of complaints, because it's quite common to run just "mysql-server" on
> the server.
> 
> Therefore I am proposing a one time fix specifically targeted at
> stretch. I would like to prepare 'mysql-transitional' package that
> will create a couple of dummy/transitional packages structured like
> this:
> 
> mysql-server depends on default-mysql-server
> mysql-client depends on default-mysql-client
> 
> The version would be 5.5.999+mariadb, so it is always higher than
> version in jessie, but always lower than version in sid, as I don't
> want force epoch on mysql-5.7.

I agree that this sounds like it will work for stretch, and it's much
better than bumping epoch on mysql-5.7.

As you say, it's a one time fix, but I'm a bit concerned about what
happens when those packages again are provided by MySQL. Let's think
through what will happen in buster. There are three options:

1) Buster contains only MariaDB. Will these packages also be in buster?
If not, what happens on upgrade from stretch to buster? Will we have
the same problem again?

2) Buster contains both MySQL and MariaDB. MariaDB is default. The
mysql-server and mysql-client packages are provided by MySQL, but
default-mysql-server and default-mysql-client point to MariaDB. How
will the upgrade go? Some users have installed mysql-server or
mysql-client explicitly, while others have installed a different
package that depends on default-mysql-server or default-mysql-client.

3) Buster contains both MySQL and MariaDB. MySQL is default. The
mysql-server and mysql-client packages are provided by MySQL, and the
default-mysql-server and default-mysql-client packages point to MySQL.
I assume the dist-upgrade will move users back to MySQL, but will there
be other problems?

We should think through these scenarios so that we're sure we're not
creating bigger problems for ourselves in the future.

Best regards,

Norvald H. Ryeng

Re: Request for release team decision on MySQL and MariaDB [was: Re: Bug#793316: [debian-mysql] Bug#793316: transition: mysql-5.6]

[Norvald H. Ryeng]

On Fri, 29 Jan 2016 20:39:52 +0100, Moritz Mühlenhoff <j...@inutil.org>  
wrote:



On Fri, Jan 15, 2016 at 04:09:58PM +0100, Norvald H. Ryeng wrote:

so I'll need the complete list of
requirements first. The Debian MySQL team has asked for a list, in
writing, several times now, but that list has not been produced.


Here's what it essentially boils down to:

- Public, non-discriminatory access, we don't sign NDAs
- Public mapping between CVE IDs and patches (or commit IDs to a public  
VCS)
- If the patches don't have meaningful commits messages on the nature of  
the
  change, provide a contact who is willing to answer questions for  
backports

  or impact


Thanks, Moritz!

Are these the final security team guidelines, or should we expect  
something more later on?


Regards,

Norvald H. Ryeng

Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB

[Norvald H. Ryeng]

On Wed, 27 Jan 2016 21:30:09 +0100, Steven Chamberlain  
<ste...@pyro.eu.org> wrote:



And apart from sponsoring Debian packaging work, Oracle seems
conspicuously missing from:
http://debconf16.debconf.org/sponsors.html
http://debconf15.debconf.org/
https://www.debian.org/mirror/sponsors
https://www.freexian.com/en/services/debian-lts.html


I don't want to link discussions of financial sponsorship with the fact  
that MySQL is in Debian or with the activities in the Debian MySQL  
maintainer team. Let us please keep those separate. If you want to discuss  
sponsorship, please let's do so in a completely different thread and on  
its own merits.


That said, I want to correct a small factual error:

MySQL was a silver sponsor of DebConf15 and is listed as such. I attended  
the conference and had a great time. In fact, I was the only member of the  
Debian MySQL maintainer team to attend.



Clint Byrum wrote:

[...] if it were written down somewhere as an actual policy. [...]


Norvald H. Ryeng wrote:

Tell us exactly what you want, in detail. If you don't then I don't
think your position is reasonable.


I don't recognize those words, and it's not in the style I usually express  
myself. Are you paraphrasing?



Robie Basak wrote:

So please: the security team needs to engage directly with Oracle by
responding to Norvald's email and enumerating exactly what is wrong.


I don't see that Debian has to do that, at all.  Other upstream projects
seem to 'just get it', so Oracle management is really expecting special
treatment.  IMHO I respond to bad dealings with a company by shopping
elsewhere, not helping them improve their business practices.


I'm not management, but no, we're not expecting special treatment. We're  
asking to know what the requirements that apply to all packages in the  
archive are. Changing security policies/practices is not done easily, and  
our users expect stability and predictability in this area. If Debian  
wants our policies/practice to change, presenting the requirements is the  
first step.


My job is to gather those requirements and present the complete story to  
management so that they can make a decision. If I have to go back to  
management again and again and ask for change because I uncover new  
requirements, I haven't done my job.


But we got some great news yesterday: the security team is working on at  
set of guidelines. I'm glad they do, and I look forward to a chance at  
finally resolving this. I'm optimistic.


Regards,

Norvald H. Ryeng

Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB

[Norvald H. Ryeng]

On Tue, 26 Jan 2016 23:45:59 +0100, Otto Kekäläinen <o...@seravo.fi> wrote:


Examples of technical arguments I'd prefer to use instead of general
disgust of Oracle arguments:

- Quality: mysql-5.6 has 135 open bugs despite never being part of a
Debian release and thus having exposure to the big Debian user masses.
Some of them are even RC. The package mariadb-10.0 has only 10 bugs,
which of 5 were filed by myself as TODO items with priority wishlist,
and it actually ships in Jessie for big audience.


I see 113 bugs in src:mysql-5.6 [1], but, OK, it's the same ballpark. Most  
of those are bugs filed against older MySQL versions. If you instead look  
at mysql-server-5.6 [2], you'll get a more accurate number: 12. Could the  
list be cleaned of old, irrelevant bug reports from MySQL 4.1, 5.0 and 5.1  
packaging? Yes, absolutely. But they're not really bothering us in the  
daily work, so other tasks have been prioritized.



- Quality: mysql-5.6 ships the same version number
libmysqlclient.so.18 as 5.5 but the ABI is different and according to
investigations by Robie Basak going back September 2014 [1] the
upgrade might break something, and while it is now partially remedied,
the ABI bump has never been done,


The major version is the same because they were supposed to be compatible.  
However, a small bug squeezed through in a little used feature, and that  
is why they're not fully compatible, and that's what stopped us from  
upgrading to 5.6 in jessie. It was analyzed thoroughly by upstream, and  
the risk of breaking anything is very small. Still, we erred on the safe  
side and didn't upgrade to 5.6 in jessie.


The major number 19 has been reserved for fixing this (which is why MySQL  
5.7 bumps to libmysqlclient.so.20), but it was decided that the downside  
of bumping the version number is greater than the benefits. Basically,  
you'll have to recompile all applications instead of a few that break  
(none of which are in Debian). It's been coordinated with upstream, and  
Debian is free to bump the version number to 19 if wanted.



the symbols file to track this all
is missing from the packaging, and there is a Lintian override to keep
Lintian quiet about the lack of a symbols file [2]


The problem with adding a symbol file is that the library exports more  
symbols than it should, so there's a lot of noise that looks like ABI  
incompatibility, while it isn't if you're looking at the symbols that are  
actually used by clients. The list of exported symbols can be restricted  
in 5.6, but that is definitely something that calls for a major number  
bump, which is why it hasn't been done.


Libmysqlclient in MariaDB has the same problem. There are build options  
that will restrict the list of exported symbols. If you use those, you'll  
get a library that exports a much smaller list of symbols, but without  
bumping the major version of the library, so again you're stuck with  
compatibility issues.


MySQL upstream did a library cleanup in 5.7 which fixed this, so in 5.7  
packaging we can add a symbols file. If we bump the 5.6 library to version  
19, we can do it in 5.6 too.



- Quality: mysql-5.6 only runs ~600 tests as part of their Debian
build, while MariaDB has 4000+ tests, making MySQL test coverage much
smaller than the MariaDB one, thus catching less issues on many of the
Debian platforms as Oracle MySQL probalby don't test those at all
in-house.


It was decided at the packaging sprint in London in December 2014 that the  
test runs should be reduced in order to reduce build time in Debian. Also,  
some timing sensitive tests are skipped to avoid spurious failures on VMs.  
This was done after consulting the upstream QA team, and the selected set  
of tests is believed to be enough to uncover bugs that may be introduced  
in packaging. A larger set of tests can be run by setting  
DEB_BUILD_OPTIONS to "fulltest", which will run more or less the same  
tests that are run per push upstream (still not the entire test suite).


Upstream would of course not mind if the full test suite with thousands of  
test was run after each build, but it would take many, many hours.


Regards,

Norvald H. Ryeng

[1]  
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=mysql-5.6;ordering=normal;archive=0;repeatmerged=0#_0_6_0

[2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=mysql-server-5.6

Re: Request for release team decision on MySQL and MariaDB [was: Re: Bug#793316: [debian-mysql] Bug#793316: transition: mysql-5.6]

[Norvald H. Ryeng]

On Thu, 14 Jan 2016 22:11:22 +0100, Moritz Mühlenhoff   
wrote:



On Mon, Jan 11, 2016 at 08:14:06PM +, Robie Basak wrote:

On Mon, Jan 11, 2016 at 07:27:30PM +0100, Moritz Mühlenhoff wrote:
> *Sigh*. And that is exactly the problem (and we've already pointed  
this

> out at DebConf half a year ago)
>
> We should really go ahead and move forward, the freeze isn't terribly  
far away.


I don't think it's reasonable to use a security question raised by
MariaDB as an excuse to kick out MySQL. Because whether you do so or
not, your situation with getting information about CVEs in relation to
MariaDB will not change.

Let's treat the situation with each on their own merits and be
constructive about this.


This policy equally hurts us for mysql alone. Debian LTS had go through
a messy 5.1-5.5 transition because of Oracle's policies.


That *is* something that might be able to be addressed directly by
Oracle, and if it does get addressed then MariaDB's situation could
improve too, and Debian wins.


We've already raised this at DebConf with Norvald from Oracle half a year
ago and nothing happened. Several other parties didn't get these infos
from Oracle in the past (not even Red Hat). The VirtualBox developers
were equally shut down by Oracle (after being cooperative for a while).


As a MySQL developer, I don't know anything about the VirtualBox
situation, so let's focus on MySQL.

Yes, there was a meeting at DebConf. I discovered the session in the
schedule and showed up wanting to meet the security team and talk
about some specific MySQL security issues. Apparently, it was planned
to be an internal security team meeting without other attendants, so
it was kind of an awkward start when I and a couple of other random
attendants showed up, but we used the opportunity to talk about a few
specific security issues that required larger code changes than the
usual security bugfix and if Debian would accept those changes in a
stable release.

I don't remember if it was me or the security team who raised the
issue of not being able to identify patches for CVEs, but if anything,
please take the fact that we sought out and showed up at the security
team meeting as a sign that we really want to resolve issues with our
security bug handling.

IIRC, when I asked at the meeting, I was told that identifying
individual patches is less important since MySQL is patched by
upgrading to the latest point release (and we document which CVEs are
fixed in which point release) instead of backporting security
bugfixes, and that the reason for wanting more details was primarily
to be able to test if MariaDB had the same vulnerabilities.

From that discussion, I got the understanding that the security team,
although not very happy about the situation, accepted that they're not
able to identify patches, and that taking point releases was an
acceptable alternative.

What you're saying now, is that publicly announcing which point
release fixes which CVE is not enough, and that a public announcement
of which CVE is which patch is a strict requirement to be in
Debian. Is that correct? In that case, this is the first time I'm made
aware of it. Is all software in Debian held to this standard?

If a public announcement linking CVEs and patches is an absolute
requirement, is this the only requirement? If so, please give me some
time to check if that is acceptable within policy or if a policy
exception can be granted. But I can't go back and ask for more if a
new requirement suddenly pops up, so I'll need the complete list of
requirements first. The Debian MySQL team has asked for a list, in
writing, several times now, but that list has not been produced.

Regards,

Norvald

Re: Request for release team decision on MySQL and MariaDB [was: Re: Bug#793316: [debian-mysql] Bug#793316: transition: mysql-5.6]

[Norvald H. Ryeng]

On Mon, 28 Dec 2015 13:28:18 +0100, Otto Kekäläinen <o...@seravo.fi> wrote:


Hello!

2015-12-23 16:39 GMT+02:00 Norvald H. Ryeng <norvald.ry...@oracle.com>:
..
I know we are a bit tight with info about security issues upstream, but  
all
security bugfixes are available at  
https://github.com/mysql/mysql-server as
individual commits, and a list of CVEs fixed is reported quarterly  
according

to a published schedule. Apparently that's not enough.


As a side note related to this, can you please tell us in what commit
CVE-2015-4913 and CVE-2015-4737 were fixed? You probably have access to  
some

internal security tracker where you can look this up, and both CVEs are
already relatively old, so you would not be releasing any sensitive  
security

info.


All I have is what is public: CVE-2015-4913 was included in the latest  
Critical Patch Update in October and was fixed in 5.5.46 and 5.6.27.  
CVE-2015-4737 was included in the July Critical Patch Update and was fixed  
in 5.5.44 and 5.6.24. Since Debian is already at 5.5.46, these don't  
affect Debian any more.


If you're asking because you want to know if these have been fixed in  
MariaDB, I think you should ask MariaDB upstream instead.


Regards,

Norvald

Re: Request for release team decision on MySQL and MariaDB [was: Re: Bug#793316: [debian-mysql] Bug#793316: transition: mysql-5.6]

[Norvald H. Ryeng]

On Mon, 11 Jan 2016 13:59:07 +0100, Otto Kekäläinen <o...@seravo.fi> wrote:


2016-01-11 13:54 GMT+02:00 Norvald H. Ryeng <norvald.ry...@oracle.com>:
On Mon, 28 Dec 2015 13:28:18 +0100, Otto Kekäläinen <o...@seravo.fi>  
wrote:



Hello!

2015-12-23 16:39 GMT+02:00 Norvald H. Ryeng <norvald.ry...@oracle.com>:
..


I know we are a bit tight with info about security issues upstream,  
but

all
security bugfixes are available at  
https://github.com/mysql/mysql-server

as
individual commits, and a list of CVEs fixed is reported quarterly
according
to a published schedule. Apparently that's not enough.



As a side note related to this, can you please tell us in what commit
CVE-2015-4913 and CVE-2015-4737 were fixed? You probably have access to
some
internal security tracker where you can look this up, and both CVEs are
already relatively old, so you would not be releasing any sensitive
security
info.



All I have is what is public: CVE-2015-4913 was included in the latest
Critical Patch Update in October and was fixed in 5.5.46 and 5.6.27.
CVE-2015-4737 was included in the July Critical Patch Update and was  
fixed
in 5.5.44 and 5.6.24. Since Debian is already at 5.5.46, these don't  
affect

Debian any more.

If you're asking because you want to know if these have been fixed in
MariaDB, I think you should ask MariaDB upstream instead.


Nobody outside Oracle can answer this. Oracle has reserved certain CVE
numbers for their use and as there no details in the CVE entries (just
a version number when it was fixed) nobody outside Oracle can actually
tell what the security issue or the fix was. Above you indicated that
those fixes are visible in individual commits, so I was trying my luck
if you would be able to give the information which commits those CVEs
are.


I usually don't work on security issues, and I don't have the mapping  
you're asking for.


These CVEs apply to MySQL and have been fixed in the announced versions.  
Likewise, MariaDB should know which CVEs apply to MariaDB and when they're  
fixed. I can't help you with that, and I think the correct address for  
such questions is MariaDB upstream.


Regards,

Norvald

Re: Request for release team decision on MySQL and MariaDB [was: Re: Bug#793316: [debian-mysql] Bug#793316: transition: mysql-5.6]

[Norvald H. Ryeng]

On Fri, 18 Dec 2015 22:31:05 +0100, Robie Basak <robie.ba...@ubuntu.com>  
wrote:



(removing Jonathan specifically; the debian-release ML should be
sufficient as this is for the release team generally now)

On Mon, Dec 14, 2015 at 05:45:24PM +, Robie Basak wrote:

Can I ask that this request (for the release team to make a decision
between the choices I outlined[1]) be tabled again at the IRC meeting I
understand will be taking place this Wednesday? Please let me know if
there's anything I can do to help you make a decision on this.


Following up, here's a summary of the outcome from the meeting
yesterday. There is also a full log[1] and the previous meeting[2] from
23 September is also relevant.


Thanks for attending the meeting and for the summary, Robie! Like you, I'm  
on vacation and have little opportunity to handle this until January. But  
I thought I'd throw in a request for a bit more information on one of the  
points:



20:12:56  2- no disclosure of security issues w/ patches


I know we are a bit tight with info about security issues upstream, but  
all security bugfixes are available at  
https://github.com/mysql/mysql-server as individual commits, and a list of  
CVEs fixed is reported quarterly according to a published schedule.  
Apparently that's not enough.


I fix the occasional security bug myself, but in the day to day work, I'm  
not involved in handling CVEs etc., so I need some more details about what  
Debian thinks is missing. It's hard for me to start a good discussion  
upstream without fully understanding the issue. Can someone (e.g., the  
security team?) please explain to me exactly what's requested and how  
you're expecting to use the information? Can Debian handle information  
given under NDA, or must all security bug info be public? When I  
understand the problem, I can pull together the right people upstream and  
see what we can do to fix it.


Merry Christmas,

Norvald H. Ryeng

Bug#793316: [debian-mysql] Bug#793316: Bug#793316: transition: mysql-5.6

[Norvald H. Ryeng]

On Wed, 16 Sep 2015 23:09:38 +0200, Jonathan Wiltshire <j...@debian.org>  
wrote:



Without wanting to point fingers, a significant source of opposition to
shipping more than one variant is the security team (with, IMO, fairly  
good reasoning).


Could you (or someone else) explain their reasoning? I talked to some of  
them at DebConf, and I got the impression they were pointing at the  
Release Team. It would be good to know exactly what the problem is, and  
then we can start solving it.


If there's anything the Debian MySQL Maintainers team or upstream can do,  
I'm sure we can work something out.


Regards,

Norvald H. Ryeng

Re: [debian-mysql] MySQL in Jessie

[Norvald H. Ryeng]

On Tue, 26 Aug 2014 19:21:06 +0200, Clint Byrum spam...@debian.org wrote:


Excerpts from Adam D. Barratt's message of 2014-08-26 09:33:39 -0700:

[fixing team@security.d.o CC]

On 2014-08-26 10:05, Bjoern Boschman wrote:
 there are already several patches prepared to start mysql-5.6
 transition for sid [0].

It's rather late for that - as per
https://lists.debian.org/debian-devel-announce/2013/12/msg8.html ,
the deadline for accepting new transitions is now less than two weeks
away.



Sounds like we need to get on our horses and get this moving ASAP.
Unfortunately I've no time in the next 2 weeks to contribute. So all I
can do is crack the whip. :-P


As I understand it, Robie and Björn already have everything ready. If I'm  
wrong and there's still something missing, I'd be happy to help out.  
Robie? Björn?


Norvald


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/op.xk80b6asfsw...@atum06.no.oracle.com

Re: [debian-mysql] MySQL in Jessie

[Norvald H. Ryeng]

On Wed, 27 Aug 2014 13:39:37 +0200, Bjoern Boschman bjo...@boschman.de  
wrote:



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 27.08.2014 13:17, schrieb Norvald H. Ryeng:

Sounds like we need to get on our horses and get this moving
ASAP. Unfortunately I've no time in the next 2 weeks to
contribute. So all I can do is crack the whip. :-P


As I understand it, Robie and Björn already have everything ready.
If I'm wrong and there's still something missing, I'd be happy to
help out. Robie? Björn?


http://anonscm.debian.org/cgit/pkg-mysql/mysql-5.6.git/
review and upload :)


Can't help you with the upload, but I can review.

Norvald


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/op.xk88onhdfsw...@atum06.no.oracle.com