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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20160518/6a4e3847/attachment.sig>