Debian Bug report logs - #620824
ITP: percona-xtrabackup -- hot backup utility for MySQL

version graph

Package: wnpp; Maintainer for wnpp is wnpp@debian.org;

Reported by: Laurent Bigonville <bigon@debian.org>

Date: Mon, 4 Apr 2011 13:30:01 UTC

Owned by: Stewart Smith <stewart.smith@percona.com>

Severity: wishlist

Fixed in version percona-xtrabackup/2.1.3-618-1

Done: Stewart Smith <stewart.smith@percona.com>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#620824; Package wnpp. (Mon, 04 Apr 2011 13:30:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Laurent Bigonville <bigon@debian.org>:
New Bug report received and forwarded. Copy sent to wnpp@debian.org. (Mon, 04 Apr 2011 13:30:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Laurent Bigonville <bigon@debian.org>
To: submit@bugs.debian.org
Subject: RFP: xtrabackup -- hot backup utility for MySQL that doesn't lock your database
Date: Mon, 4 Apr 2011 15:26:43 +0200
Package: wnpp
Severity: wishlist

* Package name    : xtrabackup
  Version         : 1.5
  Upstream Author : (c) 2009 Percona Inc.
* URL             : http://www.percona.com/software/percona-xtrabackup/
* License         : GPLv2
  Programming Lang: C
  Description     : hot backup utility for MySQL that doesn't lock your database
  Percona XtraBackup is an open-source hot backup utility for MySQL
  that doesn't lock your database during the backup. It can back up data
  from InnoDB, XtraDB, and MyISAM tables on MySQL 5.0 and 5.1 servers,
  and it has many advanced features.

Upstream already provides .deb, see http://www.percona.com/docs/wiki/repositories:apt

Cheers

Laurent Bigonville




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#620824; Package wnpp. (Fri, 01 Jul 2011 13:03:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ana Guerrero <ana@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Fri, 01 Jul 2011 13:03:09 GMT) Full text and rfc822 format available.

Message #10 received at 620824@bugs.debian.org (full text, mbox):

From: Ana Guerrero <ana@debian.org>
To: Laurent Bigonville <bigon@debian.org>, 620824@bugs.debian.org
Subject: Re: Bug#620824: RFP: xtrabackup -- hot backup utility for MySQL that doesn't lock your database
Date: Fri, 1 Jul 2011 15:02:04 +0200
On Mon, Apr 04, 2011 at 03:26:43PM +0200, Laurent Bigonville wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name    : xtrabackup
>   Version         : 1.5
>   Upstream Author : (c) 2009 Percona Inc.
> * URL             : http://www.percona.com/software/percona-xtrabackup/
> * License         : GPLv2
>   Programming Lang: C
>   Description     : hot backup utility for MySQL that doesn't lock your database
>   Percona XtraBackup is an open-source hot backup utility for MySQL
>   that doesn't lock your database during the backup. It can back up data
>   from InnoDB, XtraDB, and MyISAM tables on MySQL 5.0 and 5.1 servers,
>   and it has many advanced features.
> 
> Upstream already provides .deb, see http://www.percona.com/docs/wiki/repositories:apt
>

Hi!

Are you still working on it? Planning to upload it sonn?
I would like to test this :)

Thanks,

Ana




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#620824; Package wnpp. (Fri, 02 Nov 2012 06:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stewart Smith <stewart.smith@percona.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Fri, 02 Nov 2012 06:21:03 GMT) Full text and rfc822 format available.

Message #15 received at 620824@bugs.debian.org (full text, mbox):

From: Stewart Smith <stewart.smith@percona.com>
To: 620824@bugs.debian.org
Subject: Preparing upload for 2.0.4
Date: Fri, 02 Nov 2012 16:51:28 +1100
[Message part 1 (text/plain, inline)]
Hi all,

We're preparing the next Percona XtraBackup release (2.0.4) currently
and this is the one where we've worked on fixing lintian problems with
the packaging and it should be suitable to include in Debian.

As we prepare the release we'll update here.
-- 
Stewart Smith
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#620824; Package wnpp. (Tue, 02 Jul 2013 06:45:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stewart Smith <stewart.smith@percona.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Tue, 02 Jul 2013 06:45:08 GMT) Full text and rfc822 format available.

Message #20 received at 620824@bugs.debian.org (full text, mbox):

From: Stewart Smith <stewart.smith@percona.com>
To: debian-devel@lists.debian.org
Cc: 620824@bugs.debian.org
Subject: ITP: Percona XtraBackup - hot backup utility for MySQL
Date: Tue, 02 Jul 2013 16:41:05 +1000
[Message part 1 (text/plain, inline)]
Hi!

I'm Stewart and I work for Percona. One of the things I'm currently
working on is ensuring all our free and open source software projects
are packaged for all the major linux distributions - including my
beloved Debian.

We're wanting to have Percona XtraBackup be part of Debian. Percona
XtraBackup is an online backup tool for MySQL, MariaDB, Percona Server
and Percona XtraDB Cluster. In the near future, we will also wanting our
packages for Percona Server and Percona XtraDB Cluster to be part of
Debian.

There is an open bug for Percona XtraBackup packaging:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620824

We are going to make "upload release to Debian" be part of our release
process. We tend to make a new minor bugfix release (i.e. 2.1.x) every
2-3 months and a new major release every 12 (2.0 in April 2012, 2.1 in
May 2013). We want to be an active and involved upstream.

There have been a couple of issues with our source tarballs and build
procedure that I've had to fix up before proposing that Percona
XtraBackup be included. I've made changes on top of our 2.1.3 release
that mean we now generate source tarballs that do not require an
active internet connection to build.

I've put up source tarball and packaging for unstable up at:
http://www.percona.com/downloads/TESTING/XtraBackup/xtrabackup-2.1.3/release-2.1.3/610/source/

All future releases will produce tarballs like this, so they'll be in a
more normal area of our downloads site - I'll also get one up in an
official place for the current 2.1.3 release.

I (and we, the rest of Percona) would really appreciate any
review/comments/suggestions on this packaging - we're really keen to
have Percona XtraBackup be in the Debian archives.

Why is the tarball so big and why did it require an internet connection?
Well, XtraBackup uses *part* of the MySQL code (actually, mostly parts
of InnoDB) to help it read InnoDB pages from disk and back them up
safely. It also uses part of the code to replay REDO logs to prepare a
backup before it can be restored. Due to various not-that-interesting
reasons (all of which we do consider bugs) we currently produce
different binaries for different MySQL versions (hence linking in code
From different MySQL versions).

It's important to note that we patch the InnoDB code inside MySQL to
make it usable by xtrabackup and that we cannot just use the MySQL code
already shipped in Debian for this without creating a nightmare for
the Debian MySQL packaging team, the security team and ourselves (it's
generally non-trivial to port this patch to new versions).

There should never be any security implications of linking against this
(not always up to date) MySQL code as we only use it to read (and write)
files to local disk.

Questions:

1) We have a transitional package called 'xtrabackup' that was (prior to
   2.0) the package name was in our own APT repositories. Does it make
   sense to keep this in the Debian packaging?

2) We have trademarks. We've tried to come up with a trademark policy
   that makes everybody happy (well, as happy as you can be when you're
   dealing with trademark law).
   It's at:
   http://www.percona.com/doc/percona-xtrabackup/2.1/trademark-policy.html
   We believe this should satisfy any requirements of Linux
   distributions, but if there's any concerns, don't hesitate to ask.

3) Supported architectures. We see x86-64, x86 and very, very rarely,
   SPARC. I'd say that both people running XtraBackup on a non-x86
   architecture are happy, but I'm pretty sure there's not even that
   many. While XtraBackup may compile (or even run) on other
   architectures, it currently makes approximately zero business sense
   for us to spend any time on it - although we're happy to take
   patches.

   Given this, how much "works and passes tests on all archs" is
   required to have packages accepted?

4) We plan on continuing to provide our own repositories as well and are
   wanting to not diverge in packaging from our repos and what's in
   Debian. Any tips/tricks are very welcome - we have "build debian
   packages" as part of or continuous integration efforts and plan to
   soon have "run the whole test suite on those packages" as part of it.


Thanks in advance for the feedback!
-- 
Stewart Smith
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#620824; Package wnpp. (Tue, 02 Jul 2013 07:24:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Wise <pabs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Tue, 02 Jul 2013 07:24:04 GMT) Full text and rfc822 format available.

Message #25 received at 620824@bugs.debian.org (full text, mbox):

From: Paul Wise <pabs@debian.org>
To: Stewart Smith <stewart.smith@percona.com>
Cc: debian-devel@lists.debian.org, 620824@bugs.debian.org
Subject: Re: ITP: Percona XtraBackup - hot backup utility for MySQL
Date: Tue, 2 Jul 2013 15:20:36 +0800
On Tue, Jul 2, 2013 at 2:41 PM, Stewart Smith wrote:

> I'm Stewart and I work for Percona. One of the things I'm currently
> working on is ensuring all our free and open source software projects
> are packaged for all the major linux distributions - including my
> beloved Debian.

Since you are part of upstream, please review our upstream guide and
the links in the external advice section:

http://wiki.debian.org/UpstreamGuide

> We're wanting to have Percona XtraBackup be part of Debian.

Excellent.

> There is an open bug for Percona XtraBackup packaging:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620824

Since you intend to package it, you should retitle this bug to intent
to package and set yourself as the owner of it:

http://www.debian.org/devel/wnpp/#l3
http://www.debian.org/Bugs/server-control#retitle
http://www.debian.org/Bugs/server-control#owner

> We are going to make "upload release to Debian" be part of our release
> process.... We want to be an active and involved upstream.

Great.

> I've put up source tarball and packaging for unstable up at:
> http://www.percona.com/downloads/TESTING/XtraBackup/xtrabackup-2.1.3/release-2.1.3/610/source/

I'm unable to unpack the source package:

$ dpkg-source -x percona-xtrabackup_2.1.3-610-1.dsc
dpkg-source: warning: extracting unsigned source package
(percona-xtrabackup_2.1.3-610-1.dsc)
dpkg-source: error: File ./percona-xtrabackup_2.1.3-610.orig.tar.gz
has size 39459 instead of expected 141074103

You may want to run some commands from the source tree after a build:

http://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package

Also, I encourage you to sign your Debian packages and also your
upstream tarballs using OpenPGP keys. Here are some best practices for
OpenPGP:

https://we.riseup.net/riseuplabs+paow/openpgp-best-practices

> Why is the tarball so big and why did it require an internet connection?
> Well, XtraBackup uses *part* of the MySQL code (actually, mostly parts
> of InnoDB)

An alternative to including the MySQL InnoDB code might be to
build-depend on mysql-source-5.5, unpack and patch it during the build
process and add Built-Using: mysql-5.5 (= $version) to the resulting
binary package.

> 1) We have a transitional package called 'xtrabackup' that was (prior to
>    2.0) the package name was in our own APT repositories. Does it make
>    sense to keep this in the Debian packaging?

Seems reasonable to include it if you really want to. There seem to be
more folks using percona-xtrabackup than xtrabackup though:

$ GET http://popcon.debian.org/unknown/by_inst | grep -i xtrab
1590  percona-xtrabackup               150    36    82    32     0
(Not in sid)
2170  xtrabackup                        98     5    29     0    64
(Not in sid)
23575 percona-xtrabackup-test            3     0     2     1     0
(Not in sid)
31597 percona-xtrabackup-dbg             2     0     2     0     0
(Not in sid)
74903 szn-mysql-xtrabackup               1     0     1     0     0
(Not in sid)

> 2) We have trademarks. We've tried to come up with a trademark policy
>    that makes everybody happy (well, as happy as you can be when you're
>    dealing with trademark law).
>    It's at:
>    http://www.percona.com/doc/percona-xtrabackup/2.1/trademark-policy.html
>    We believe this should satisfy any requirements of Linux
>    distributions, but if there's any concerns, don't hesitate to ask.

I'd suggest mailing debian-legal about this question but based on the
trademark policy it appears that Debian would have to rename percona
if we wanted to add a security patch in stable?

You may want to listen to this FOSDEM talk entitled 'How to Share a Trademark':

http://faif.us/cast/2013/may/07/0x3C/

> 3) Supported architectures. We see x86-64, x86 and very, very rarely,
>    SPARC. I'd say that both people running XtraBackup on a non-x86
>    architecture are happy, but I'm pretty sure there's not even that
>    many. While XtraBackup may compile (or even run) on other
>    architectures, it currently makes approximately zero business sense
>    for us to spend any time on it - although we're happy to take
>    patches.
>
>    Given this, how much "works and passes tests on all archs" is
>    required to have packages accepted?

There is no requirement to work on all arches but regressions in
architecture support are release-critical. You need to have a good
test suite so that binary packages are not produced on architectures
where the software doesn't work. I expect you will want to make it
work on ARM since arm64 is coming soon and may become a popular
architecture for servers.

http://wiki.debian.org/Arm64Port

-- 
bye,
pabs

http://wiki.debian.org/PaulWise



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#620824; Package wnpp. (Tue, 02 Jul 2013 07:54:18 GMT) Full text and rfc822 format available.

Acknowledgement sent to Vincent Bernat <bernat@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Tue, 02 Jul 2013 07:54:18 GMT) Full text and rfc822 format available.

Message #30 received at 620824@bugs.debian.org (full text, mbox):

From: Vincent Bernat <bernat@debian.org>
To: Stewart Smith <stewart.smith@percona.com>, debian-devel@lists.debian.org, 620824@bugs.debian.org
Subject: Re: ITP: Percona XtraBackup - hot backup utility for MySQL
Date: Tue, 02 Jul 2013 09:35:59 +0200
[Message part 1 (text/plain, inline)]
 ❦  2 juillet 2013 09:20 CEST, Paul Wise <pabs@debian.org> :

>> Why is the tarball so big and why did it require an internet connection?
>> Well, XtraBackup uses *part* of the MySQL code (actually, mostly parts
>> of InnoDB)
>
> An alternative to including the MySQL InnoDB code might be to
> build-depend on mysql-source-5.5, unpack and patch it during the build
> process and add Built-Using: mysql-5.5 (= $version) to the resulting
> binary package.

The problem is that it should Build-Depends on Percona MySQL which is
not yet available in Debian. I think the first step would be to provide
Percona MySQL packages. Currently, it seems that there is no easy way to
provide packages as alternative to MySQL but maybe work has already
started with MariaDB.
-- 
/* Fuck me gently with a chainsaw... */
        2.0.38 /usr/src/linux/arch/sparc/kernel/ptrace.c
[Message part 2 (application/pgp-signature, inline)]

Changed Bug title to 'ITP: Percona XtraBackup - hot backup utility for MySQL' from 'RFP: xtrabackup -- hot backup utility for MySQL that doesn't lock your database' Request was from Stewart Smith <stewart.smith@percona.com> to control@bugs.debian.org. (Tue, 02 Jul 2013 10:51:09 GMT) Full text and rfc822 format available.

Owner recorded as Stewart Smith <stewart.smith@percona.com>. Request was from Stewart Smith <stewart.smith@percona.com> to control@bugs.debian.org. (Tue, 02 Jul 2013 10:51:10 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#620824; Package wnpp. (Tue, 02 Jul 2013 11:39:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stewart Smith <stewart.smith@percona.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Tue, 02 Jul 2013 11:39:04 GMT) Full text and rfc822 format available.

Message #39 received at 620824@bugs.debian.org (full text, mbox):

From: Stewart Smith <stewart.smith@percona.com>
To: Paul Wise <pabs@debian.org>
Cc: debian-devel@lists.debian.org, 620824@bugs.debian.org
Subject: Re: ITP: Percona XtraBackup - hot backup utility for MySQL
Date: Tue, 02 Jul 2013 21:35:21 +1000
[Message part 1 (text/plain, inline)]
Paul Wise <pabs@debian.org> writes:
> On Tue, Jul 2, 2013 at 2:41 PM, Stewart Smith wrote:
>
>> I'm Stewart and I work for Percona. One of the things I'm currently
>> working on is ensuring all our free and open source software projects
>> are packaged for all the major linux distributions - including my
>> beloved Debian.
>
> Since you are part of upstream, please review our upstream guide and
> the links in the external advice section:
>
> http://wiki.debian.org/UpstreamGuide

Thanks for the pointer. It appears that we're pretty good on most things
mentioned there and some things we've got plans to address.

>> There is an open bug for Percona XtraBackup packaging:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620824
>
> Since you intend to package it, you should retitle this bug to intent
> to package and set yourself as the owner of it:
>
> http://www.debian.org/devel/wnpp/#l3
> http://www.debian.org/Bugs/server-control#retitle
> http://www.debian.org/Bugs/server-control#owner

Done.

>> I've put up source tarball and packaging for unstable up at:
>> http://www.percona.com/downloads/TESTING/XtraBackup/xtrabackup-2.1.3/release-2.1.3/610/source/
>
> I'm unable to unpack the source package:
>
> $ dpkg-source -x percona-xtrabackup_2.1.3-610-1.dsc
> dpkg-source: warning: extracting unsigned source package
> (percona-xtrabackup_2.1.3-610-1.dsc)
> dpkg-source: error: File ./percona-xtrabackup_2.1.3-610.orig.tar.gz
> has size 39459 instead of expected 141074103

I'll investigate this first thing in the morning (it's getting late),
although it looks as though the tar.gz didn't fully download (yes, it's
really 135MB)

> You may want to run some commands from the source tree after a build:
>
> http://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package

I think there's some good ideas here that we can add to our CI
infrastructure. I don't think there's anything that would be considered
a blocker though.

> Also, I encourage you to sign your Debian packages and also your
> upstream tarballs using OpenPGP keys. Here are some best practices for
> OpenPGP:
>
> https://we.riseup.net/riseuplabs+paow/openpgp-best-practices

Yep, we typically do this. We use a key for the company rather than our
individual ones for our current repositories. Is this an acceptable
approach for packages going into Debian? Or should we just have the few
individuals sign it if they're involved?

>> Why is the tarball so big and why did it require an internet connection?
>> Well, XtraBackup uses *part* of the MySQL code (actually, mostly parts
>> of InnoDB)
>
> An alternative to including the MySQL InnoDB code might be to
> build-depend on mysql-source-5.5, unpack and patch it during the build
> process and add Built-Using: mysql-5.5 (= $version) to the resulting
> binary package.

We'd need to depend on very specific 5.1, 5.5 and 5.6 versions of both
MySQL and Percona Server (which isn't yet packaged) and we'd also have
to patch it.

Our short/medium term plan is to do away with having multiple server
source trees and binaries. We instead plan to just make a modified MySQL
branch where we just include the needed (modified) source. In an ideal
world the needed code would be buildable as a library and we'd get the
needed patches upstream. It is not an ideal world however :(


>> 1) We have a transitional package called 'xtrabackup' that was (prior to
>>    2.0) the package name was in our own APT repositories. Does it make
>>    sense to keep this in the Debian packaging?
>
> Seems reasonable to include it if you really want to. There seem to be
> more folks using percona-xtrabackup than xtrabackup though:

I'm not really attached either way... It appears that it may not be
worth having it. I'll defer to the experts on this one.

>> 2) We have trademarks. We've tried to come up with a trademark policy
>>    that makes everybody happy (well, as happy as you can be when you're
>>    dealing with trademark law).
>>    It's at:
>>    http://www.percona.com/doc/percona-xtrabackup/2.1/trademark-policy.html
>>    We believe this should satisfy any requirements of Linux
>>    distributions, but if there's any concerns, don't hesitate to ask.
>
> I'd suggest mailing debian-legal about this question but based on the
> trademark policy it appears that Debian would have to rename percona
> if we wanted to add a security patch in stable?

I'll bring it up there. We would see that as simply a patch that's
needed for that version to be included in that Os and thus not an issue.

> You may want to listen to this FOSDEM talk entitled 'How to Share a Trademark':
>
> http://faif.us/cast/2013/may/07/0x3C/

I'll have a look. We tried to think of linux distros and Debian when we
were forming the trademark policy. We'll see what Debian-legal says :)

>> 3) Supported architectures. We see x86-64, x86 and very, very rarely,
>>    SPARC. I'd say that both people running XtraBackup on a non-x86
>>    architecture are happy, but I'm pretty sure there's not even that
>>    many. While XtraBackup may compile (or even run) on other
>>    architectures, it currently makes approximately zero business sense
>>    for us to spend any time on it - although we're happy to take
>>    patches.
>>
>>    Given this, how much "works and passes tests on all archs" is
>>    required to have packages accepted?
>
> There is no requirement to work on all arches but regressions in
> architecture support are release-critical. You need to have a good
> test suite so that binary packages are not produced on architectures
> where the software doesn't work. I expect you will want to make it
> work on ARM since arm64 is coming soon and may become a popular
> architecture for servers.
>
> http://wiki.debian.org/Arm64Port

It's certainly something we may be interested at looking at... I guess
we'll see what the buildds say :)

We do have a test suite. It does (of course) depend on having server
binaries around to run backup and restore with. Our CI infrastructure
currently uses just binary tarballs of various server versions, but this
probably isn't ideal for Debain so we'll have to come up with another
solution. One thing to consider is that (like MySQL) running the test
suite takes a non-trivial amount of time.


-- 
Stewart Smith
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Stewart Smith <stewart.smith@percona.com>:
Bug#620824; Package wnpp. (Tue, 02 Jul 2013 12:15:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Wise <pabs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Stewart Smith <stewart.smith@percona.com>. (Tue, 02 Jul 2013 12:15:04 GMT) Full text and rfc822 format available.

Message #44 received at 620824@bugs.debian.org (full text, mbox):

From: Paul Wise <pabs@debian.org>
To: Stewart Smith <stewart.smith@percona.com>
Cc: debian-devel@lists.debian.org, 620824@bugs.debian.org
Subject: Re: ITP: Percona XtraBackup - hot backup utility for MySQL
Date: Tue, 2 Jul 2013 20:13:39 +0800
On Tue, Jul 2, 2013 at 7:35 PM, Stewart Smith wrote:

> I'll investigate this first thing in the morning (it's getting late),
> although it looks as though the tar.gz didn't fully download (yes, it's
> really 135MB)

Looks like your tarball is named incorrectly (tar.gz instead of
orig.tar.gz) and your website returns a HTTP 302 code (redirect) and
some HTML for the orig.tar.gz URL rather than a 404.

> I think there's some good ideas here that we can add to our CI
> infrastructure. I don't think there's anything that would be considered
> a blocker though.

Indeed.

> Yep, we typically do this. We use a key for the company rather than our
> individual ones for our current repositories. Is this an acceptable
> approach for packages going into Debian? Or should we just have the few
> individuals sign it if they're involved?

It is a reasonable approach for upstream tarballs. Uploads to Debian
need to be signed by one of the keys in the developer keyring or a
subkey of one of those keys.

> We'd need to depend on very specific 5.1, 5.5 and 5.6 versions of both
> MySQL and Percona Server (which isn't yet packaged) and we'd also have
> to patch it.
>
> Our short/medium term plan is to do away with having multiple server
> source trees and binaries. We instead plan to just make a modified MySQL
> branch where we just include the needed (modified) source. In an ideal
> world the needed code would be buildable as a library and we'd get the
> needed patches upstream. It is not an ideal world however :(

I see, maybe you have chosen the way of least pain.

> I'm not really attached either way... It appears that it may not be
> worth having it. I'll defer to the experts on this one.

Maybe ask your userbase if they need it?

> I'll bring it up there. We would see that as simply a patch that's
> needed for that version to be included in that Os and thus not an issue.

The danger is if that approach to interpretation if the policy were to change.

> It's certainly something we may be interested at looking at... I guess
> we'll see what the buildds say :)
>
> We do have a test suite. It does (of course) depend on having server
> binaries around to run backup and restore with. Our CI infrastructure
> currently uses just binary tarballs of various server versions, but this
> probably isn't ideal for Debain so we'll have to come up with another
> solution. One thing to consider is that (like MySQL) running the test
> suite takes a non-trivial amount of time.

Please do enable the test suite for Debian builds and run them with
the binaries built during the build process.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#620824; Package wnpp. (Tue, 02 Jul 2013 12:21:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stewart Smith <stewart.smith@percona.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Tue, 02 Jul 2013 12:21:05 GMT) Full text and rfc822 format available.

Message #49 received at 620824@bugs.debian.org (full text, mbox):

From: Stewart Smith <stewart.smith@percona.com>
To: Vincent Bernat <bernat@debian.org>, debian-devel@lists.debian.org, 620824@bugs.debian.org
Subject: Re: ITP: Percona XtraBackup - hot backup utility for MySQL
Date: Tue, 02 Jul 2013 22:17:17 +1000
[Message part 1 (text/plain, inline)]
Vincent Bernat <bernat@debian.org> writes:
>  ❦  2 juillet 2013 09:20 CEST, Paul Wise <pabs@debian.org> :
>
>>> Why is the tarball so big and why did it require an internet connection?
>>> Well, XtraBackup uses *part* of the MySQL code (actually, mostly parts
>>> of InnoDB)
>>
>> An alternative to including the MySQL InnoDB code might be to
>> build-depend on mysql-source-5.5, unpack and patch it during the build
>> process and add Built-Using: mysql-5.5 (= $version) to the resulting
>> binary package.
>
> The problem is that it should Build-Depends on Percona MySQL which is
> not yet available in Debian. I think the first step would be to provide
> Percona MySQL packages. Currently, it seems that there is no easy way to
> provide packages as alternative to MySQL but maybe work has already
> started with MariaDB.

It would need to build-depend on specific MySQL and Percona Server
versions (which end up being on-disk compatible with various MariaDB
versions).

We're working on getting Percona Server ready to be included too, but
we'd be going for the current Percona Server versions not the ones we
patch heavily to then build XtraBackup with.

But, the main problem is that we need to patch the InnoDB source to build
XtraBackup and the patch isn't trivial to port to the latest versions
(and there's usually no benefit in doing so).

It's better to think of XtraBackup patching and including the parts of
InnoDB it needs and for reasons that are largely historical it's
multiple binaries for multiple versions of InnoDB.

Our short/medium term goal is to stop doing this and actually just have
one set of InnoDB code from the most recent MySQL/Percona Server version
and one XtraBackup binary that works on all server versions.

In an ideal world there'd be some library we could link against and have
the patches be accepted upstream.. but we're not in an ideal world. This
would make it more like something like xfsprogs which does end up
including some of the same code as the kernel (although we patch InnoDB
while xfsprogs seems to be about at the point where that isn't
necessary).

So while we do understand how it'd be great to build against the source
in mysql-source-5.5, it's just not really feasible to do so and maintain
quality and maintainability. We're hoping that our short/medium term of
just including the patched InnoDB bits we need in our source tree to
mostly solve the problem.

I hope this helps clarify.

-- 
Stewart Smith
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#620824; Package wnpp. (Tue, 02 Jul 2013 12:33:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stewart Smith <stewart.smith@percona.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Tue, 02 Jul 2013 12:33:12 GMT) Full text and rfc822 format available.

Message #54 received at 620824@bugs.debian.org (full text, mbox):

From: Stewart Smith <stewart.smith@percona.com>
To: Paul Wise <pabs@debian.org>
Cc: debian-devel@lists.debian.org, 620824@bugs.debian.org
Subject: Re: ITP: Percona XtraBackup - hot backup utility for MySQL
Date: Tue, 02 Jul 2013 22:31:16 +1000
[Message part 1 (text/plain, inline)]
Paul Wise <pabs@debian.org> writes:
> On Tue, Jul 2, 2013 at 7:35 PM, Stewart Smith wrote:
>
>> I'll investigate this first thing in the morning (it's getting late),
>> although it looks as though the tar.gz didn't fully download (yes, it's
>> really 135MB)
>
> Looks like your tarball is named incorrectly (tar.gz instead of
> orig.tar.gz) and your website returns a HTTP 302 code (redirect) and
> some HTML for the orig.tar.gz URL rather than a 404.

I'll ensure our process includes putting the tarball up named
correctly. The tarball in that directory should be the right one when
named correctly though (unless I brain-farted and got it wrong :)

>> Yep, we typically do this. We use a key for the company rather than our
>> individual ones for our current repositories. Is this an acceptable
>> approach for packages going into Debian? Or should we just have the few
>> individuals sign it if they're involved?
>
> It is a reasonable approach for upstream tarballs. Uploads to Debian
> need to be signed by one of the keys in the developer keyring or a
> subkey of one of those keys.

My guess is the reasonable thing to do is ensure that a few of us have
keys in the keyring then so that there's some redundancy (after all, we
have to let people take vacation :)

>> We'd need to depend on very specific 5.1, 5.5 and 5.6 versions of both
>> MySQL and Percona Server (which isn't yet packaged) and we'd also have
>> to patch it.
>>
>> Our short/medium term plan is to do away with having multiple server
>> source trees and binaries. We instead plan to just make a modified MySQL
>> branch where we just include the needed (modified) source. In an ideal
>> world the needed code would be buildable as a library and we'd get the
>> needed patches upstream. It is not an ideal world however :(
>
> I see, maybe you have chosen the way of least pain.

We try to :)

>> I'm not really attached either way... It appears that it may not be
>> worth having it. I'll defer to the experts on this one.
>
> Maybe ask your userbase if they need it?

I'll reach out through our support org. I suspect we'd be fine
without it.

>> I'll bring it up there. We would see that as simply a patch that's
>> needed for that version to be included in that Os and thus not an issue.
>
> The danger is if that approach to interpretation if the policy were to
> change.

Okay. I'll bring it up on debian-devel and see if we need changes (it
just means I probably get to talk trademark law more... which is
generally something I try to avoid :)

>> It's certainly something we may be interested at looking at... I guess
>> we'll see what the buildds say :)
>>
>> We do have a test suite. It does (of course) depend on having server
>> binaries around to run backup and restore with. Our CI infrastructure
>> currently uses just binary tarballs of various server versions, but this
>> probably isn't ideal for Debain so we'll have to come up with another
>> solution. One thing to consider is that (like MySQL) running the test
>> suite takes a non-trivial amount of time.
>
> Please do enable the test suite for Debian builds and run them with
> the binaries built during the build process.

The problem we'll have to solve is running against MySQL (and Percona
Server) versions... and I'm not sure the best way to wrangle that (we
probably have to fix a bug or two in the test suite to ensure it works
against an installed binary - we currently download binary tarballs and
run against them).


-- 
Stewart Smith
[Message part 2 (application/pgp-signature, inline)]

Changed Bug title to 'ITP: percona-xtrabackup -- hot backup utility for MySQL' from 'ITP: Percona XtraBackup - hot backup utility for MySQL' Request was from Mònica Ramírez Arceda <monica@debian.org> to control@bugs.debian.org. (Tue, 02 Jul 2013 18:12:13 GMT) Full text and rfc822 format available.

Added tag(s) pending. Request was from Anibal Monsalve Salazar <anibal@debian.org> to control@bugs.debian.org. (Wed, 24 Jul 2013 08:06:04 GMT) Full text and rfc822 format available.

Reply sent to Stewart Smith <stewart.smith@percona.com>:
You have taken responsibility. (Fri, 06 Sep 2013 01:03:05 GMT) Full text and rfc822 format available.

Notification sent to Laurent Bigonville <bigon@debian.org>:
Bug acknowledged by developer. (Fri, 06 Sep 2013 01:03:05 GMT) Full text and rfc822 format available.

Message #63 received at 620824-close@bugs.debian.org (full text, mbox):

From: Stewart Smith <stewart.smith@percona.com>
To: 620824-close@bugs.debian.org
Subject: Bug#620824: fixed in percona-xtrabackup 2.1.3-618-1
Date: Fri, 06 Sep 2013 01:00:13 +0000
Source: percona-xtrabackup
Source-Version: 2.1.3-618-1

We believe that the bug you reported is fixed in the latest version of
percona-xtrabackup, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 620824@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Stewart Smith <stewart.smith@percona.com> (supplier of updated percona-xtrabackup package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Fri, 19 Jul 2013 16:18:36 +1000
Source: percona-xtrabackup
Binary: percona-xtrabackup percona-xtrabackup-dbg percona-xtrabackup-test xtrabackup
Architecture: source amd64 all
Version: 2.1.3-618-1
Distribution: unstable
Urgency: low
Maintainer: Debian MySQL Maintainers <pkg-mysql-maint@lists.alioth.debian.org>
Changed-By: Stewart Smith <stewart.smith@percona.com>
Description: 
 percona-xtrabackup - Open source backup tool for InnoDB and XtraDB
 percona-xtrabackup-dbg - Debug symbols for Percona XtraBackup
 percona-xtrabackup-test - Test suite for Percona XtraBackup
 xtrabackup - Transitional package for percona-xtrabackup
Closes: 620824
Changes: 
 percona-xtrabackup (2.1.3-618-1) unstable; urgency=low
 .
   [ Stewart Smith ]
   * Initial packaging for Debian (Closes: #620824)
 .
   [ Clint Byrum ]
   * Remove inaccurate Vcs-* fields.
   * Remove MAKE_J setting as it is handled by dpkg build tools.
   * Remove unnecesssary debian/percona-xtrabackup.dirs
   * Updating standards to 3.9.4, no changes necessary.
   * Add embedded-library libmysqlclient to
     percona-xtrabackup.lintian-overrides.
Checksums-Sha1: 
 05e153cc8702438a756623b446810e0eef48ba0a 1958 percona-xtrabackup_2.1.3-618-1.dsc
 580264fc7c3825ba9593941f22fac99b6122c5f6 140946667 percona-xtrabackup_2.1.3-618.orig.tar.gz
 0af15289b8938329db871c4164660ffe7da872c8 14301 percona-xtrabackup_2.1.3-618-1.debian.tar.gz
 a4ab173e3bd37057dafb16cf3fbcb7c6ea3c2356 8331814 percona-xtrabackup_2.1.3-618-1_amd64.deb
 e0f0acc17676a44a7c1052065325d3f728080560 37028160 percona-xtrabackup-dbg_2.1.3-618-1_amd64.deb
 ac6b53075bbcf88e52246d302e16c88aadfade8a 9823140 percona-xtrabackup-test_2.1.3-618-1_amd64.deb
 9b79f2557c6a990109d09da6eaac488d868d44ac 14018 xtrabackup_2.1.3-618-1_all.deb
Checksums-Sha256: 
 4fadf445fe811fa5042d6704c1b65bbd76b07f6dae853679b441fb3122098a2f 1958 percona-xtrabackup_2.1.3-618-1.dsc
 f1699b513bad2bb9592b779b5d86f17f903ff6fd6665f86a394ecdc9c94c6c0e 140946667 percona-xtrabackup_2.1.3-618.orig.tar.gz
 fcdcc42c0abce84bb1262c11e4b5b36b97c73c959bd4ab9e006b73a7319ee434 14301 percona-xtrabackup_2.1.3-618-1.debian.tar.gz
 a2fa71ec46e9a98c19e160c43feb8071d623d3b0585e23047385942c0167d682 8331814 percona-xtrabackup_2.1.3-618-1_amd64.deb
 ed0323bd4f6ccaad5917f416547843710d0d7dbdbf836c1bcac40796063e1e16 37028160 percona-xtrabackup-dbg_2.1.3-618-1_amd64.deb
 5bca5c2d5613fa796a295d722604659ba9c4b270482250ddb9b6695a035d0ded 9823140 percona-xtrabackup-test_2.1.3-618-1_amd64.deb
 b0c6602e7949cff0fc79f55ab2f1df6011a8603ac877a86258430f8bd9306286 14018 xtrabackup_2.1.3-618-1_all.deb
Files: 
 20f9c0050138d6b0e8801fc544283434 1958 database extra percona-xtrabackup_2.1.3-618-1.dsc
 c30ececcb57b0cd35ec6ecbce76f8a2c 140946667 database extra percona-xtrabackup_2.1.3-618.orig.tar.gz
 05ba3f3c1969fcfc440897c1b409d217 14301 database extra percona-xtrabackup_2.1.3-618-1.debian.tar.gz
 f6a6cf32dd45fa17c144d2235410b333 8331814 database extra percona-xtrabackup_2.1.3-618-1_amd64.deb
 6173ff3bcb681744c91ff3a2278d1682 37028160 debug extra percona-xtrabackup-dbg_2.1.3-618-1_amd64.deb
 38171f8b8d624c233f332af7cdd6a831 9823140 database extra percona-xtrabackup-test_2.1.3-618-1_amd64.deb
 54ad63c6cafef452139dd778e1380adf 14018 oldlibs extra xtrabackup_2.1.3-618-1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJR73SaAAoJEFOMB2b0vLOOtI8IAL/5ylD8iHdHHE11pZhGZoZe
i3ttm/7iwnOXXxXMH/uSPT6tMVyzAd1LbOh8ZfNOUSBGyIc8AhtwAea0S2Zq/naK
Zglr36aIsoEkqPBzG5O2dAouJCIift7cVY6esH/c5O0WMWlZ96VsiLLsCnjcR34A
padoFeGd3QzJUcy7CXGusOlql7+uGw9i2mSc2u67laCdXub5Q+oVXKjxtwONNW+I
Jkx3y6QQl+E/6hHRl4pbxL7P7PLbuekKhI4XaokLrrY6pTIysx9miWd3dothA1cF
HpUGx2ACCWHZMKVoKUYYKKjBWAxCCYrU1kbaDNpuy8ivmfRWZ+xFlUs6ast9E+o=
=Tk1f
-----END PGP SIGNATURE-----




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Fri, 04 Oct 2013 07:27:10 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 23 18:45:36 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.