Bug#824011: warzone2100: FTBFS in testing (maybe missing Build-Conflicts)

[Chris Lamb]

Hi, please do not CC me in further replies. Many thanks.  -lamby

On Wed, 18 May 2016, at 07:50 PM, Santiago Vila wrote:
> On Wed, May 18, 2016 at 08:12:52PM +0200, Markus Koschany wrote:
> > Am 18.05.2016 um 19:35 schrieb Santiago Vila:
> > > Just take a look at the countless FTBFS bugs filed by reproducible
> > > builds people. They are almost always serious, but many of them fail
> > > to meet the condition that the FTBFS has to happen in the official
> > > buildds.
> > 
> > Every RC bug filed by the reproducible build folks is always
> > reproducible in a clean chroot. I have seen many of those reports. I
> > have fixed many of them.
> 
> A clean chroot, but a "not clean environment", so to speak.
> 
> My point is that adding extra packages is just another way to make the
> environment "not clean".
> 
> Our build system should be ready for any sort of "not cleanliness",
> not only the ones that result from defining environment variables.
> 
> > > Example 1: A package which fails to build under a given locale.
> > > Official autobuilders have LANG=C, but failing to build from source
> > > when LANG=fr_FR is also considered serious.
> > 
> > > Example 2: A package fails to build in a strange timezone. Official
> > > autobuilders have TZ=UTC, but failing to build from source when TZ is
> > > different is also considered serious.
> > 
> > No. These two examples are reproducible build issues but are not RC.
> 
> Ok, let's provide bug numbers.
> 
> FTBFS under some locales:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795731
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808454
> 
> Both are "Severity: serious" because they are FTBFS.
> 
> FTBFS under some timezones:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795690
> 
> Also "Severity: serious" because it's FTBFS.
> 
> > [...]
> > > We want everybody to be able to build packages and have the same result,
> > > not just in the official buildds.
> > 
> > No. We are talking about sensible defaults. For the majority of people
> > this bug is a non-issue.
> 
> I build a lot of packages. debhelper is used by a lot of packages.
> Since I don't want to waste disk I/O, I have debhelper in my chroot
> installed by default. This makes automake to be installed by default.
> 
> I would say this is a more than sensible default for anybody who build
> a lot of packages.
> 
> > [...]
> > > They have not, otherwise we would not have invented build-conflicts.
> > 
> > Build-Conflicts is not a Policy requirement. We talked about that before.
> 
> Yes, and I said that your interpretation of policy in this paragraph
> is extremely narrow.
> 
> Of course it is not a policy requirement. If your package does not
> need any build-depends or build-conflicts, why would you add one?
> 
> Let me quote it again, with emphasis on two other words:
> 
>   Source packages that *require* certain binary packages to be installed
>   or *absent* at the time of building the package can declare
>   relationships to those binary packages.
> 
> I think we can agree that the package being discussed *requires*
> automake to be absent.
> 
> How does a *requirement* (that automake is absent) suddenly becomes optional?
> 
> Please don't say that policy says "can". This just means that you can
> use those fields if your package needs them.
> 
> Once that it's known that the package needs them (either build-depends
> or build-conflicts), they are *required*, not optional.
> 
> Thanks.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#824011: warzone2100: FTBFS in testing (maybe missing Build-Conflicts)

[Santiago Vila]

On Wed, May 18, 2016 at 08:12:52PM +0200, Markus Koschany wrote:
> Am 18.05.2016 um 19:35 schrieb Santiago Vila:
> > Just take a look at the countless FTBFS bugs filed by reproducible
> > builds people. They are almost always serious, but many of them fail
> > to meet the condition that the FTBFS has to happen in the official
> > buildds.
> 
> Every RC bug filed by the reproducible build folks is always
> reproducible in a clean chroot. I have seen many of those reports. I
> have fixed many of them.

A clean chroot, but a "not clean environment", so to speak.

My point is that adding extra packages is just another way to make the
environment "not clean".

Our build system should be ready for any sort of "not cleanliness",
not only the ones that result from defining environment variables.

> > Example 1: A package which fails to build under a given locale.
> > Official autobuilders have LANG=C, but failing to build from source
> > when LANG=fr_FR is also considered serious.
> 
> > Example 2: A package fails to build in a strange timezone. Official
> > autobuilders have TZ=UTC, but failing to build from source when TZ is
> > different is also considered serious.
> 
> No. These two examples are reproducible build issues but are not RC.

Ok, let's provide bug numbers.

FTBFS under some locales:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795731
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808454

Both are "Severity: serious" because they are FTBFS.

FTBFS under some timezones:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795690

Also "Severity: serious" because it's FTBFS.

> [...]
> > We want everybody to be able to build packages and have the same result,
> > not just in the official buildds.
> 
> No. We are talking about sensible defaults. For the majority of people
> this bug is a non-issue.

I build a lot of packages. debhelper is used by a lot of packages.
Since I don't want to waste disk I/O, I have debhelper in my chroot
installed by default. This makes automake to be installed by default.

I would say this is a more than sensible default for anybody who build
a lot of packages.

> [...]
> > They have not, otherwise we would not have invented build-conflicts.
> 
> Build-Conflicts is not a Policy requirement. We talked about that before.

Yes, and I said that your interpretation of policy in this paragraph
is extremely narrow.

Of course it is not a policy requirement. If your package does not
need any build-depends or build-conflicts, why would you add one?

Let me quote it again, with emphasis on two other words:

  Source packages that *require* certain binary packages to be installed
  or *absent* at the time of building the package can declare
  relationships to those binary packages.

I think we can agree that the package being discussed *requires*
automake to be absent.

How does a *requirement* (that automake is absent) suddenly becomes optional?

Please don't say that policy says "can". This just means that you can
use those fields if your package needs them.

Once that it's known that the package needs them (either build-depends
or build-conflicts), they are *required*, not optional.

Thanks.

Bug#824011: warzone2100: FTBFS in testing (maybe missing Build-Conflicts)

[Markus Koschany]

Am 18.05.2016 um 19:35 schrieb Santiago Vila:
> On Wed, May 18, 2016 at 06:58:49PM +0200, Markus Koschany wrote:
> 
>> [...]
>>
>> To put it simply: There are countless circumstances under which programs
>> can FTBFS. There is a standard way to determine when a FTBFS is release
>> critical and when it is not. If it builds fine on our buildd network it
>> should be a strong indication against raising the severity to RC.
> 
> Well, I don't see that such standard is being applied as a general rule.
> 
> Just take a look at the countless FTBFS bugs filed by reproducible
> builds people. They are almost always serious, but many of them fail
> to meet the condition that the FTBFS has to happen in the official
> buildds.

Every RC bug filed by the reproducible build folks is always
reproducible in a clean chroot. I have seen many of those reports. I
have fixed many of them.

> Example 1: A package which fails to build under a given locale.
> Official autobuilders have LANG=C, but failing to build from source
> when LANG=fr_FR is also considered serious.

> Example 2: A package fails to build in a strange timezone. Official
> autobuilders have TZ=UTC, but failing to build from source when TZ is
> different is also considered serious.

No. These two examples are reproducible build issues but are not RC.

> [ I'm Cc:ing Chris Lamb here in case he wants to share with us
>   his criteria for deciding severities for FTBFS ]
> 
> So, your standard is clearly different from the usual standard I see
> applied everywhere, which is why I wonder where your standard comes
> from, as it does not follow the current practice I see.

It's the other way around.

> 
> The build-depends/build-conficts were created to ensure that packages
> always built the same, not just in the official buildds, but really in
> any system which meets the build-depends.
> 
> We want everybody to be able to build packages and have the same result,
> not just in the official buildds.

No. We are talking about sensible defaults. For the majority of people
this bug is a non-issue.

> In this case, nowhere in policy or in developers-reference it's stated
> that the chroot must be "clean" for the build to succeeed.

It is common practice, recommended by countless Debian folks to build
packages in a clean chroot before they are uploaded.

> The only condition for the build to succeed is that build-depends
> and build-conflicts are met.

The only condition for RC serverity is that the build fails to build
from source in a clean chroot environment. Everything else might still
be a bug but with a lower severity.

>> Contrary to your belief not every FTBFS is RC. For instance not every
>> Java or Python package can be built on every release architecture. I
>> certainly would like to see this fixed but I don't consider it to be
>> release critical at the moment because nobody intends to do the required
>> porting work.
> 
> It is only RC if it built successfully in the past in those archs.
> 
> Can you think of a better example? This one is not controversial at all.

I was talking about Java and Python packages. Almost all of them are
arch:all. Some can be built on amd64 and i386 but fail on armhf for
example. I have seen bug reports with severity serious but they were all
downgraded. This is the perfect example that shows that people
(rightfully) aim for a perfect technical solution, we acknowledge the
problem but it is still not RC.

>> The issue here at hand is that you don't use a _clean_ chroot like the
>> ones produced by either pbuilder, cowbuilder or sbuild. In my chroot
>> only automake1.11 gets installed.
> 
> So I must ask: Where did you get the idea that chroots have to be clean?

See above. Clean chroots are common practice. They are promoted by
Debian Mentors and mentioned as "best practices" in many tutorials, e.g.
the commonly known

https://wiki.ubuntu.com/PbuilderHowto

Obviously the intention is to mimic the conditions on the buildd.

> They have not, otherwise we would not have invented build-conflicts.

Build-Conflicts is not a Policy requirement. We talked about that before.

> 
>> And no, I wouldn't tell someone to install a missing build-dependency
>> because then the build would fail in a clean chroot environment too
>> which would be a serious issue.
> 
> Glad to know.
> 
> But then, why did you suggest that I remove automake from my chroot?
> You did it with "...". It was irony? It was sarcasm?
> 
> Were you seriously suggesting that the problem was in my chroot?

Everyone has different personality traits. Some people like busywork and
others are more pragmatic. It really helps sometimes to be a bit more
flexible. No, that was no sarcasm, just a simple advice. I knew you
wouldn't take it but I had to try.

Cheers,

Markus





signature.asc
Description: OpenPGP digital signature

Bug#824011: warzone2100: FTBFS in testing (maybe missing Build-Conflicts)

[Santiago Vila]

On Wed, May 18, 2016 at 06:58:49PM +0200, Markus Koschany wrote:

> [...]
> 
> To put it simply: There are countless circumstances under which programs
> can FTBFS. There is a standard way to determine when a FTBFS is release
> critical and when it is not. If it builds fine on our buildd network it
> should be a strong indication against raising the severity to RC.

Well, I don't see that such standard is being applied as a general rule.

Just take a look at the countless FTBFS bugs filed by reproducible
builds people. They are almost always serious, but many of them fail
to meet the condition that the FTBFS has to happen in the official
buildds.

Example 1: A package which fails to build under a given locale.
Official autobuilders have LANG=C, but failing to build from source
when LANG=fr_FR is also considered serious.

Example 2: A package fails to build in a strange timezone. Official
autobuilders have TZ=UTC, but failing to build from source when TZ is
different is also considered serious.

[ I'm Cc:ing Chris Lamb here in case he wants to share with us
  his criteria for deciding severities for FTBFS ]

So, your standard is clearly different from the usual standard I see
applied everywhere, which is why I wonder where your standard comes
from, as it does not follow the current practice I see.

The build-depends/build-conficts were created to ensure that packages
always built the same, not just in the official buildds, but really in
any system which meets the build-depends.

We want everybody to be able to build packages and have the same result,
not just in the official buildds.

In this case, nowhere in policy or in developers-reference it's stated
that the chroot must be "clean" for the build to succeeed.

The only condition for the build to succeed is that build-depends
and build-conflicts are met.

> Contrary to your belief not every FTBFS is RC. For instance not every
> Java or Python package can be built on every release architecture. I
> certainly would like to see this fixed but I don't consider it to be
> release critical at the moment because nobody intends to do the required
> porting work.

It is only RC if it built successfully in the past in those archs.

Can you think of a better example? This one is not controversial at all.

> The issue here at hand is that you don't use a _clean_ chroot like the
> ones produced by either pbuilder, cowbuilder or sbuild. In my chroot
> only automake1.11 gets installed.

So I must ask: Where did you get the idea that chroots have to be clean?

They have not, otherwise we would not have invented build-conflicts.

> And no, I wouldn't tell someone to install a missing build-dependency
> because then the build would fail in a clean chroot environment too
> which would be a serious issue.

Glad to know.

But then, why did you suggest that I remove automake from my chroot?
You did it with "...". It was irony? It was sarcasm?

Were you seriously suggesting that the problem was in my chroot?

Thanks.

Bug#824011: warzone2100: FTBFS in testing (maybe missing Build-Conflicts)

[Markus Koschany]

Am 18.05.2016 um 17:39 schrieb Santiago Vila:
> On Mon, 16 May 2016, Markus Koschany wrote:
> 
>> How come I am not surprised about your reaction and this reminds me of
>> the discussion we had about Bullet and the bug you eventually closed.
> 
> If you refer to Bug #818148, it was clearly a violation of Policy 4.6,
> which says that in case of errors the build must stop.
> 
> My mistake (sorry for that) was to file the bug against bullet,
> because the problem was really in doxygen:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818379
> 
> but other than that, it was completely justified to use serious severity,
> because it was a violation of Policy 4.6, a must directive.

Santiago, I don't want to write to much about this issue anymore because
that is unrelated to warzone2100. So please consider this to be my last
comments. It was clearly not a bug in Bullet and it is at least
debatable whether this should be a release critical issue. But that's a
call the doxygen maintainer now has to make and the Release Team.
Speaking for myself I think it is a non-issue.

You can't just use the Debian Policy without considering other important
social issues too. The Policy should help the project to create a common
technical base for Debian but it is not the law or a judicial codex. It
is not a dogma. If Policy gets in the way to do the right thing, then we
should change it. I think there are more pressing matters which should
be fixed first before we start to construe rare situations and claim
that they are common issues for all users. They are not. There is always
a perfect technical solution for everything but that doesn't always mean
that it is also the most economical or desirable. It is my belief that
we should spend our time and manpower for more beneficial tasks which
really further Debian's cause.

And last but not least: It is just my opinion, this is a public bug
mailing list. Everyone can respond to bug reports. The difference is
that I respond to your reports while others just ignore you.

> If you are looking for parallelisms, I would highlight your refusal to
> reproduce the bug following the steps in the bug report itself.
> 
> You did that in #818148, and apparently you are doing it again here.
>

That is not true. I told you that I consider #824011 to be a bug but not
to be a release critical one.

> For this bug, here are the steps to reproduce:
> 
>> * Create a stretch chroot (with debootstrap).
>>
>> * Install debhelper in the chroot. This will automatically install
>>  "automake" as a dependency.
>>
>> * Then try to build warzone2100 with a command line like this:
>>
>> sbuild -d stretch -A warzone2100_3.1.1-3
> 
> So: Did you manage to reproduce the problem following those steps?
> 
> There is also a question still unanswered: Since you suggested me to
> remove automake by hand to "solve the problem", would you also tell
> someone to install a build-depends by hand in case you forget to put
> it in the control file also to "solve the problem"?
> 
> Thanks.

To put it simply: There are countless circumstances under which programs
can FTBFS. There is a standard way to determine when a FTBFS is release
critical and when it is not. If it builds fine on our buildd network it
should be a strong indication against raising the severity to RC.

Contrary to your belief not every FTBFS is RC. For instance not every
Java or Python package can be built on every release architecture. I
certainly would like to see this fixed but I don't consider it to be
release critical at the moment because nobody intends to do the required
porting work.

The issue here at hand is that you don't use a _clean_ chroot like the
ones produced by either pbuilder, cowbuilder or sbuild. In my chroot
only automake1.11 gets installed.

And no, I wouldn't tell someone to install a missing build-dependency
because then the build would fail in a clean chroot environment too
which would be a serious issue.


Regards,

Markus





signature.asc
Description: OpenPGP digital signature

Bug#824011: warzone2100: FTBFS in testing (maybe missing Build-Conflicts)

[Santiago Vila]

On Mon, 16 May 2016, Markus Koschany wrote:

> How come I am not surprised about your reaction and this reminds me of
> the discussion we had about Bullet and the bug you eventually closed.

If you refer to Bug #818148, it was clearly a violation of Policy 4.6,
which says that in case of errors the build must stop.

My mistake (sorry for that) was to file the bug against bullet,
because the problem was really in doxygen:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818379

but other than that, it was completely justified to use serious severity,
because it was a violation of Policy 4.6, a must directive.


If you are looking for parallelisms, I would highlight your refusal to
reproduce the bug following the steps in the bug report itself.

You did that in #818148, and apparently you are doing it again here.

For this bug, here are the steps to reproduce:

> * Create a stretch chroot (with debootstrap).
> 
> * Install debhelper in the chroot. This will automatically install
>  "automake" as a dependency.
>
> * Then try to build warzone2100 with a command line like this:
> 
> sbuild -d stretch -A warzone2100_3.1.1-3

So: Did you manage to reproduce the problem following those steps?

There is also a question still unanswered: Since you suggested me to
remove automake by hand to "solve the problem", would you also tell
someone to install a build-depends by hand in case you forget to put
it in the control file also to "solve the problem"?

Thanks.

Bug#824011: warzone2100: FTBFS in testing (maybe missing Build-Conflicts)

[Santiago Vila]

On Mon, 16 May 2016, Markus Koschany wrote:

> [...]  Try to respect your fellow maintainers for once or ask
> yourself if probably you are the one who has come to the wrong
> conclusion. Not every bug is release critical.

This is not a conclusion of mine.

FTBFS bugs are of serious severity, they have always been.

> warzone2100 build-depends on automake1.11. I know the paragraph about
> Build-Conflicts and I understand why the package FTBFS for you.

It does not FTBFS "for me". It fails to build from source for
*anybody* who has automake installed.

Bear in mind that automake is not a random package, it's a dependency
of debhelper, which is currently used by most packages in the archive.

A chroot may have automake installed. Build-Depends is for packages
that you need installed, but nowhere it's said that you can only
install those, and this is why Build-Conflicts exist.

> My conclusion is that warzone2100 simply requires automake1.11 to
> build.

That's not a good conclusion because it's incomplete.

warzone2100 does not only need "automake1.11" to build, it also needs
"automake" *not* to be present.

> Using Build-Conflicts would be one way to solve this issue for you,

Again, this is not a problem "for me" or "in my computer", it is a
problem in the source package (otherwise I would not have bothered to
report this as a bug).

> the other one is to make the build system compatible with either of
> them.

Yes, we agree on that, you will notice I didn't say Build-Conflicts
was the only solution, but it's certainly the easier.

> You could also remove the other automake version from your chroot...

Again, you put the blame on me, and talk as if this were "my problem"
or as if I were part of the problem for having automake installed in
my chroot, and not a problem in the package.

I repeat: This is what Build-Conflicts is for.

When a package needs another one to build, we put it in Build-Depends.

When a package needs another one *not* to be present to build, we put
in Build-Conficts.

If you forget to put a package in Build-Depends, there is a FTBFS and
you would not suggest people to install the package by hand to solve
the problem, would you? I want to believe that you would add
Build-Depends without much discussion.

For the same reason, if you forget to put a package in Build-Conflicts,
there is a FTBFS if the package is installed.

Why, then, are you suggesting that I remove "automake" by hand?

I'm just following simple logic here. If failure to declare a
Build-Depends is a serious bug, failure to declare a Build-Conflicts
should not be different, because the end result (a FTBFS) is the same.

> > I'll quote policy for you to save time:
> > 
> >   Build-Depends, Build-Depends-Indep, Build-Conflicts, Build-Conflicts-Indep
> > 
> >  Source packages that require certain binary packages to be installed
> >  or *absent* at the time of building the package can declare
> >  relationships to those binary packages.
> > 
> > This is the case here. This package requires normal automake to be
> > *absent* because it needs automake1.11 and gets confused if there is
> > another automake floating around.
> 
> Exactly, they _can_ declare relationships. No _must_ directive here.

Of course, you only declare relationships that you *need*. If your
package does not need any relationship, there is no need to use any.

Here, policy just explains the allowed vocabulary when writing control
files, but does not say what you want to say with such vocabulary,
that will depend on the actual needs of the package.

In this case, we absolutely need automake not to be present, because
the package FTBFS if it's present, and that's a real *need*, not
just "you might better not to have automake installed".

Otherwise: Are you trying to imply that Build-Depends are optional and
you can tell people that they have to install packages by hand if a
package fails to build from source?

Would you tell someone that not using a required Build-Depends is not
a serious bug because it's not a Policy Violation, because Policy just
says you "can" use Build-Depends?

That would be quite an unorthodox interpretation of Policy indeed.

Bug#824011: warzone2100: FTBFS in testing (maybe missing Build-Conflicts)

[Markus Koschany]

Control: severity -1 normal

How come I am not surprised about your reaction and this reminds me of
the discussion we had about Bullet and the bug you eventually closed.
Again, if you disagree with maintainer decisions, then just don't raise
the severity again. Try to respect your fellow maintainers for once or
ask yourself if probably you are the one who has come to the wrong
conclusion. Not every bug is release critical.

Try to make your point but if the maintainer still disagrees and you
think he or she is totally wrong, please forward this issue to the CTTE.
Full stop. No severity bumping will ever make your argument right or
solve an issue quicker.

Am 16.05.2016 um 03:27 schrieb Santiago Vila:
> severity 824011 serious
> thanks
> 
> On Mon, May 16, 2016 at 02:17:23AM +0200, Markus Koschany wrote:
> 
>> I have just rebuilt warzone2100 in a clean sid cowbuilder chroot.
> 
> Well, if that's all you did, then I would say that you didn't
> understand the nature of the problem.
> 
> I'll try to explain better below.
> 
>> Everything went fine. Currently automake 1.11 is automatically installed
>> but this might change in the future so we should keep an eye on this
>> issue. I don't consider this to be release critical at the moment as
>> long as warzone2100 can be built from source in a default chroot
>> environment but I leave the rest to pabs, if he should feel differently
>> about that.
> 
> That's precisely the problem: chroots do *not* have to be "default",
> and that's precisely why Build-Conflicts exists at all.
> 
> Moreover, my chroot was pretty "standard" as it had debhelper installed
> by default, nothing really strange.
> 
> This is a FTBFS bug. Please read Debian Policy about Build-Conflicts
> before modifying severity again.

warzone2100 build-depends on automake1.11. I know the paragraph about
Build-Conflicts and I understand why the package FTBFS for you. My
conclusion is that warzone2100 simply requires automake1.11 to build.
Using Build-Conflicts would be one way to solve this issue for you, the
other one is to make the build system compatible with either of them.
You could also remove the other automake version from your chroot...


> I'll quote policy for you to save time:
> 
>   Build-Depends, Build-Depends-Indep, Build-Conflicts, Build-Conflicts-Indep
> 
>  Source packages that require certain binary packages to be installed
>  or *absent* at the time of building the package can declare
>  relationships to those binary packages.
> 
> This is the case here. This package requires normal automake to be
> *absent* because it needs automake1.11 and gets confused if there is
> another automake floating around.

Exactly, they _can_ declare relationships. No _must_ directive here. It
is not a Policy violation if you don't use Build-Conflicts. The package
builds fine from source in my environment and on the buildd. Thus it is
a bug when it FTBFS with another version of automake installed but not a
serious one.

I suggest to keep this bug report open but at severity normal and try to
fix this when upgrading to the latest upstream release which we should
do before the next freeze.

Regards,

Markus






signature.asc
Description: OpenPGP digital signature

Bug#824011: warzone2100: FTBFS in testing (maybe missing Build-Conflicts)

[Santiago Vila]

tags 824011 + patch
thanks

Patch attached.

In either case, I recommend that you still try to reproduce the bug to
fully understand it. Here is the way to reproduce it:

* Create a stretch chroot (with debootstrap).

* Install debhelper in the chroot. This will automatically install
  "automake" as a dependency.

* Then try to build warzone2100 with a command line like this:

sbuild -d stretch -A warzone2100_3.1.1-3

You will get a nice FTBFS like the one I attached in the initial bug report.

This is what happens: sbuild knows that it has to install automake1.11
because it's in the build-depends, so it does install it, but
then configure still detects normal automake (because nowhere it's said
that it has to be removed), and it fails.

When the Build-Conflicts is in place, sbuild knows that it has to remove
"automake" (in addition to installing automake1.11), and you can see
this in the build log:

The following packages will be REMOVED:
  automake*

As I said in the previous email, Build-Conflicts exist precisely
to deal with cases like this one.

Another solution would be to modify debian/rules so that automake1.11
is detected instead of automake when both are installed. I don't know
how to do that, but if you manage to do that way, it would also fix
the bug.

Hope this helps.

Thanks.--- a/debian/control
+++ b/debian/control
@@ -41,6 +41,8 @@ Build-Depends:
  xsltproc,
  xvfb,
  zip
+Build-Conflicts:
+ automake
 Standards-Version: 3.9.8
 Homepage: http://www.wz2100.net/
 Vcs-Svn: svn://anonscm.debian.org/pkg-games/packages/trunk/warzone2100/

Bug#824011: warzone2100: FTBFS in testing (maybe missing Build-Conflicts)

[Santiago Vila]

severity 824011 serious
thanks

On Mon, May 16, 2016 at 02:17:23AM +0200, Markus Koschany wrote:

> I have just rebuilt warzone2100 in a clean sid cowbuilder chroot.

Well, if that's all you did, then I would say that you didn't
understand the nature of the problem.

I'll try to explain better below.

> Everything went fine. Currently automake 1.11 is automatically installed
> but this might change in the future so we should keep an eye on this
> issue. I don't consider this to be release critical at the moment as
> long as warzone2100 can be built from source in a default chroot
> environment but I leave the rest to pabs, if he should feel differently
> about that.

That's precisely the problem: chroots do *not* have to be "default",
and that's precisely why Build-Conflicts exists at all.

Moreover, my chroot was pretty "standard" as it had debhelper installed
by default, nothing really strange.

This is a FTBFS bug. Please read Debian Policy about Build-Conflicts
before modifying severity again.

I'll quote policy for you to save time:

  Build-Depends, Build-Depends-Indep, Build-Conflicts, Build-Conflicts-Indep

 Source packages that require certain binary packages to be installed
 or *absent* at the time of building the package can declare
 relationships to those binary packages.

This is the case here. This package requires normal automake to be
*absent* because it needs automake1.11 and gets confused if there is
another automake floating around.

Thanks.

Bug#824011: warzone2100: FTBFS in testing (maybe missing Build-Conflicts)

[Markus Koschany]

Control: severity -1 normal

On Wed, 11 May 2016 11:34:14 +0200 (CEST) Santiago Vila
 wrote:
> Package: warzone2100
> Version: 3.1.1-3
> Severity: serious
> 
> Dear maintainer:
> 
> This package fails to build from source in stretch:
> 
> -
>  debian/rules build
> dh build --parallel --with autoreconf
>dh_testdir
>dh_update_autotools_config
>debian/rules override_dh_autoreconf
> make[1]: Entering directory '/<>'
> dh_autoreconf ./autogen.sh
> + checking for automake >= 1.12 ... found 1.15, ok.
> Sorry, automake 1.12+ is not supported yet, please use 1.11.

[...]

Hi,

I have just rebuilt warzone2100 in a clean sid cowbuilder chroot.
Everything went fine. Currently automake 1.11 is automatically installed
but this might change in the future so we should keep an eye on this
issue. I don't consider this to be release critical at the moment as
long as warzone2100 can be built from source in a default chroot
environment but I leave the rest to pabs, if he should feel differently
about that.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#824011: warzone2100: FTBFS in testing (maybe missing Build-Conflicts)

[Santiago Vila]

Package: warzone2100
Version: 3.1.1-3
Severity: serious

Dear maintainer:

This package fails to build from source in stretch:

-
 debian/rules build
dh build --parallel --with autoreconf
   dh_testdir
   dh_update_autotools_config
   debian/rules override_dh_autoreconf
make[1]: Entering directory '/<>'
dh_autoreconf ./autogen.sh
+ checking for automake >= 1.12 ... found 1.15, ok.
Sorry, automake 1.12+ is not supported yet, please use 1.11.
dh_autoreconf: ./autogen.sh returned exit code 1
debian/rules:10: recipe for target 'override_dh_autoreconf' failed
make[1]: *** [override_dh_autoreconf] Error 2
make[1]: Leaving directory '/<>'
debian/rules:7: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
-

The full build log is attached.

Note: My stretch chroot has debhelper installed by default to save
some time, so it has "automake" installed by default. If the package
does not build when "automake" is installed, then it should use a
Build-Conflicts.

Thanks.

warzone2100_3.1.1-3_amd64-20160511-1125.gz
Description: application/gzip