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



-------------- 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/7a573981/attachment-0001.sig>