Bug#824011: warzone2100: FTBFS in testing (maybe missing Build-Conflicts)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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