Percona Server with XtraDB

Rebuilding Debian Source Package fails because of missing build-dep: dpatch and automake

Reported by Stephan Adig on 2012-07-11
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Percona Server
Status tracked in 5.6
5.5
Medium
Ignacio Nin
5.6
Medium
Ignacio Nin

Bug Description

Dear Colleagues,

the source package which you can download from here:

http://www.percona.com/redir/downloads/Percona-Server-5.5/Percona-Server-5.5.24-26.0/deb/precise/x86_64/percona-server-5.5_5.5.24-rel26.0-256.precise.dsc
http://www.percona.com/redir/downloads/Percona-Server-5.5/Percona-Server-5.5.24-26.0/deb/precise/x86_64/percona-server-5.5_5.5.24-rel26.0-256.precise.tar.gz

FTBFS because of a missing build-dep in debian/control.

You are using dpatch in debian/rules, and without dpatch being in the build-dep line, a clean sbuild chroot won't build your package.
Furthermore, the underlying buildsystem of percona mysql server calls aclocal
This needs to be included in the build-deps as well.

Stephan Adig (sadig) on 2012-07-11
summary: Rebuilding Debian Source Package fails because of missing build-dep:
- dpatch
+ dpatch and automake
description: updated
tags: added: ftbfs
Stephan Adig (sadig) on 2012-07-11
tags: added: qa
Stewart Smith (stewart) wrote :

Thanks for the patch, I've assigned our build engineer to this bug so that we can:
a) apply the fix to 5.1 and 5.5 (and 5.6)
b) switch to using sbuild for building debs, to catch any of these problems in the future.

Changed in percona-server:
importance: Undecided → Medium
status: New → Fix Committed
assignee: nobody → Ignacio Nin (ignacio-nin)
Stephan Adig (sadig) wrote :

Thanks Stewart

for the fast response.

Right now, I'm running into more issues.

So, you provide debian packages for percona-toolkit.
The tarfile doesn't include any debian/ directory and as well no .spec file for RPM building.

So the question here is: how do you build these packages?

The reason why I'm asking is, I have to make sure, that I can rebuild those packages internally.

So, is it possible for you to provide the debian/ directory and .spec files into the toolkit package?

Should I file another bug for the percona-toolkit project here on LP?

Thanks for your help :)

\sh

Stephan Adig (sadig) wrote :

Hi Stewart,

the next issue is : percona-xtrabackup.
It's not possible to rebuild the source package in a clean chroot (via sbuild)

The debian/rules file using build.sh wants to download packages via wget, which is not allowed in a buildserver environment (no egress connections allowed)
And this even means, whoever built this in your company is eventually not using not a "clean" build environment which matches a clean debian/ubuntu environment ( i would guess it's the same for rhel/fedora packages?).

I don't want to bug you that much :) we are all busy.

We can have a off the record chat via email or jabber if you want :) contact details are on my LP person page :)

Regards,

\sh

Stephan Adig <email address hidden> writes:
> So, you provide debian packages for percona-toolkit.
> The tarfile doesn't include any debian/ directory and as well no .spec file for RPM building.
>
> So the question here is: how do you build these packages?
>
> The reason why I'm asking is, I have to make sure, that I can rebuild
> those packages internally.

That's a perfectly reasonable thing to ensure you can do.

So... not to sound like I'm passing the buck, but that's a sep dev
group, and if you file a bug against percona-toolkit then that's the
best way to get those guys attention :)

> Should I file another bug for the percona-toolkit project here on LP?

Yep, that'll get their attention, and also help us track it. I'm happy
to go and poke people with a big stick if they're slack at all :)

--
Stewart Smith

Stewart Smith (stewart) wrote :

Stephan Adig <email address hidden> writes:
> The debian/rules file using build.sh wants to download packages via wget, which is not allowed in a buildserver environment (no egress connections allowed)
> And this even means, whoever built this in your company is eventually
> not using not a "clean" build environment which matches a clean
> debian/ubuntu environment ( i would guess it's the same for
> rhel/fedora packages?).

Yep, that's what it does.

Unfortunately, the xtrabackup build procedure is a tad convoluted.

XtraBackup requires a slightly modified InnoDB/XtraDB. It currently
requires the InnoDB from 5.1, the InnoDB Plugin from 5.1, the XtraDB
plugin from PS 5.1 and the XTraDB plugin from PS 5.5 to build all the
binaries that make up the XtraBackup package.

The current procedure for doing that is that we grab source tarballs for
each of the above and then apply a patch we keep in the source
tree. This basically avoids shipping a truly giant source tree.

However, we could/should actually combine these for the source
tarball... which whould probably make Debian build system happy?

Importing it all into the source tree could create its own set of issues
(importing the MySQL history is hundreds of megabytes, and we'd need
several copies of it at different stages... and that sounds to start
like tempting the SCM gods to breathe their furious anger all over our
repo :)

We are well aware that this building against many MySQL versions is
not ideal.

It is our goal to condense this down to one source tere, using just the
latest InnoDB version. We're not quite there yet, as this is certainly
something we want to test thouroughly too.

> I don't want to bug you that much :) we are all busy.

Don't sweat about it - it is truly excellent to have other people
looking at the packaging.

> We can have a off the record chat via email or jabber if you want :)
> contact details are on my LP person page :)

Added on jabber.

--
Stewart Smith

Marked lp:1051709 a duplicate of this bug. In that bug I only hit the dpatch dependency (not the automake one - need to verify this).

Bernhard Schmidt (berni) wrote :

This bug is still present, percona-server-5.5_5.5.28-rel29.2-360.squeeze cannot be rebuilt without adding these dependencies. I think the "Fix committed" status is wrong.

Bernhard -

I am sorry that the bug is not fixed yet, but the status is correct. Only bugs in "Fix Released" state after the corresponding release has been made are considered fixed.

Ignacio Nin (ignacio-nin) wrote :

The bug for 5.5 was fixed as part of other fixes in commit 426.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers