Re: Using -Werror in CFLAGS for a debian package build
* Russ Allbery r...@debian.org [110724 03:23]: I, personally, consider all of those warnings bugs. Well, unused variables aren't problems per se, but often can give good hints where there *might* be some bug. Oh, sure, I agree. But sometimes it's not a good idea to immediately escalate a whole ton of minor bugs to FTBFS bugs. Especially as there are quite some gcc false positives, at least with uninitialized warnings. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110724115449.ga10...@pcpool00.mathematik.uni-freiburg.de
Re: Using -Werror in CFLAGS for a debian package build
* Russ Allbery r...@debian.org schrieb: If -Werror had not been disabled for this warning, my guess is that nearly every package using -Wall -Werror not previously tested with 4.6 would FTBFS. I, personally, consider all of those warnings bugs. Well, unused variables aren't problems per se, but often can give good hints where there *might* be some bug. So, IMHO, maintainers should always enable them for testing and try to fix the problems. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110520205351.GC14996@nibiru.local
Re: Using -Werror in CFLAGS for a debian package build
Enrico Weigelt weig...@metux.de writes: * Russ Allbery r...@debian.org schrieb: If -Werror had not been disabled for this warning, my guess is that nearly every package using -Wall -Werror not previously tested with 4.6 would FTBFS. I, personally, consider all of those warnings bugs. Well, unused variables aren't problems per se, but often can give good hints where there *might* be some bug. Oh, sure, I agree. But sometimes it's not a good idea to immediately escalate a whole ton of minor bugs to FTBFS bugs. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkk48obb@windlord.stanford.edu
Re: Using -Werror in CFLAGS for a debian package build
On Mon, 23 May 2011 at 01:44:03 +0200, Goswin von Brederlow wrote: Or the reverse gcc -Wformat=error gcc -Wno-error -Wformat -Werror=format You might also be interested in m4/tp-compiler-warnings.m4 in telepathy-glib. Usage looks like this: TP_COMPILER_WARNINGS([ERROR_CFLAGS], dnl Make warnings fatal if: [test x$official_release = xno], dnl Warn about these things: [all \ extra \ declaration-after-statement \ shadow \ strict-prototypes \ missing-prototypes \ sign-compare \ nested-externs \ pointer-arith \ format-security \ init-self], dnl But don't even warn about these things: [missing-field-initializers \ unused-parameter]) AC_SUBST([ERROR_CFLAGS]) We switch off -Werror by default for each tarball release, and switch it back on in git immediately after the release, so only developers get these fatal warnings (that's what the test of $official_release is for). S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110523065419.ga5...@reptile.pseudorandom.co.uk
Re: Using -Werror in CFLAGS for a debian package build
(note: this message quotes from multiple mails by different people) WouterFirst and foremost, I do not believe that setting -Werror in a Wouterdebian/rules file is the best way to maintain a package; -Werror is a Wouterdevelopment option which should not be used in a release build (which a WouterDebian package is). When a package sets -Werror in its debian/rules Wouterfile, it *will* FTBFS when the default compiler is changed, while not Wouternecessarily breaking the package itself. I don't think it adds value. The thing is that there are some warnings that really SHOULD be errors as code that generates them is almost certainly wrong. Generally a build failure is less serious than a subtuly broken package. A package maintainer could try and identify such warnings individually but I don't think many maintainers would be willing to go to that effort. Maybe what is really needed is a -Werror=serious or similar option that turns the worst warnings (stuff like converting a pointer to/from an integer of the wrong size, incompatible implicit declarations and other stuff that indicates something is SERIOUSLY wrong) into errors while leaving minor warnings (things that really just indicate that the code could do with a little cleanup) as warnings. RussI was a bit dubious about it as well, for the reasons you state, but Russplease note that GCC 4.6 introduced a major new warning about set but Russunused variables and, so far, every large or medium C code base that I Russhave has had at least once instance of that warning. And I'm usually Russpretty picky about such things. Russ RussIf -Werror had not been disabled for this warning, my guess is that nearly Russevery package using -Wall -Werror not previously tested with 4.6 would RussFTBFS. Is this really THAT big a deal? Is it really worth making dubious changes to build dependencies (gcc in this case but a similar saga is going on with dash) to temporarlly hide (and therefore make harder to fix) FTBFS bugs that are usually trivial to fix in the package that suffers from them (worst case you can just change the cflags in this case or set CONFIG_SHELL in the dash/configure case. Yes it may mean some packages may need a sourceful nmu rather than a binnmu to transition but is that really such a huge deal? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dd93475.8010...@p10link.net
Re: Using -Werror in CFLAGS for a debian package build
peter green plugw...@p10link.net writes: Is this really THAT big a deal? Is it really worth making dubious changes to build dependencies (gcc in this case but a similar saga is going on with dash) to temporarlly hide (and therefore make harder to fix) FTBFS bugs that are usually trivial to fix in the package that suffers from them (worst case you can just change the cflags in this case or set CONFIG_SHELL in the dash/configure case. I'm not sure. My personal inclination for my own packages would be along the lines you describe: just let them FTBFS and have people fix them. I wouldn't have minded that for my own packages, although it would have given this specific issue a bit more urgency than it felt like it deserved (but then I don't use -Werror for exactly that reason). But I'm also not on the release team, and I can imagine adding a couple hundred new FTBFS problems in the middle of transitions could have really ruined their week. It's problematic enough right now that GCC 4.6 seems to be struggling on armel; I have two packages that currently can't build due to internal compiler errors in armel. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y61ycx43@windlord.stanford.edu
Re: Using -Werror in CFLAGS for a debian package build
peter green plugw...@p10link.net writes: (note: this message quotes from multiple mails by different people) WouterFirst and foremost, I do not believe that setting -Werror in a Wouterdebian/rules file is the best way to maintain a package; -Werror is a Wouterdevelopment option which should not be used in a release build (which a WouterDebian package is). When a package sets -Werror in its debian/rules Wouterfile, it *will* FTBFS when the default compiler is changed, while not Wouternecessarily breaking the package itself. I don't think it adds value. The thing is that there are some warnings that really SHOULD be errors as code that generates them is almost certainly wrong. Generally a build failure is less serious than a subtuly broken package. A package maintainer could try and identify such warnings individually but I don't think many maintainers would be willing to go to that effort. Maybe what is really needed is a -Werror=serious or similar option that turns the worst warnings (stuff like converting a pointer to/from an integer of the wrong size, incompatible implicit declarations and other stuff that indicates something is SERIOUSLY wrong) into errors while leaving minor warnings (things that really just indicate that the code could do with a little cleanup) as warnings. There should be an option to tune the severity of individual warnings. Some warnings are seriously wrong code, other warnings though are allways completly harmless (e.g. unused vars). It would be nice if one could say gcc -Werror -Wunused=info to make warnings an error except -Wunused would be only informational and not an error. That way one could explicitly ignore save warnings and catch everything else. Or the reverse gcc -Wformat=error to turn only format warnings into errors. Once you have that level of control suitable aliase could be defined to toggle common sets of warnings into errors or info. Maybe something for next years GSoC? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4diuwqk.fsf@frosties.localnet
Re: Using -Werror in CFLAGS for a debian package build
Wouter Verhelst wrote: I was working on nbd-server upstream, and so had ran ./configure with CFLAGS='-Wall -Werror', which I consider good practice when writing C code. What I didn't notice immediately was that gcc was emitting some warnings, but that the -Werror option was not honored for those warnings. Investigating turned up #615157 (Cc'd): the gcc maintainers have decided to disable -Werror for some new warnings, because otherwise it would cause FTBFS bugs in packages that have -Werror set in their debian/rules file. Wouldn't it be possible to use the dpkg-buildflags framework for this? As far as I understand it, this framework sets the gcc options used to build Debian packages. Using it would allow to have an upstream-like gcc for the whole system, and Debian-specific options when building packages. (It would also have the side-effect of making sure all packages actually work fine when dpkg-buildflags sets something different as usually expected.) Opinions ? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ir5apo$kdd$1...@dough.gmane.org
Re: Using -Werror in CFLAGS for a debian package build
Didier Raboud o...@debian.org writes: Wouter Verhelst wrote: I was working on nbd-server upstream, and so had ran ./configure with CFLAGS='-Wall -Werror', which I consider good practice when writing C code. What I didn't notice immediately was that gcc was emitting some warnings, but that the -Werror option was not honored for those warnings. Investigating turned up #615157 (Cc'd): the gcc maintainers have decided to disable -Werror for some new warnings, because otherwise it would cause FTBFS bugs in packages that have -Werror set in their debian/rules file. Wouldn't it be possible to use the dpkg-buildflags framework for this? As far as I understand it, this framework sets the gcc options used to build Debian packages. Using it would allow to have an upstream-like gcc for the whole system, and Debian-specific options when building packages. (It would also have the side-effect of making sure all packages actually work fine when dpkg-buildflags sets something different as usually expected.) Opinions ? You would want to only have -Werror for your own packages, not for every package you compile. dpkg-buildflags doesn't know what package you are trying to build when it gets asked for the right flags to use. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aaehuwcu.fsf@frosties.localnet
Re: Bug#615157: Using -Werror in CFLAGS for a debian package build
On 05/17/2011 01:31 AM, Wouter Verhelst wrote: [...] see http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-werror;users=debian-...@lists.debian.org This package builds with -Werror, and GCC 4.6 triggers new warnings which will make the package fail to build. Currently a Debian patch just passes -Wno-error=unused-but-set-variable and -Wno-error=unused-but-set-parameter to avoid build failures, but this patch will be reverted with the GCC 4.6.1 release, and the severity of the report will be raised. The list of packages may contain some false positives. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dd239c1.8000...@debian.org
Re: Using -Werror in CFLAGS for a debian package build
Le Tue, May 17, 2011 at 01:31:14AM +0200, Wouter Verhelst a écrit : What I didn't notice immediately was that gcc was emitting some warnings, but that the -Werror option was not honored for those warnings. Investigating turned up #615157 (Cc'd): the gcc maintainers have decided to disable -Werror for some new warnings, because otherwise it would cause FTBFS bugs in packages that have -Werror set in their debian/rules file. Dear Wouter and Matthias, and everybody, while I do not question the choice made for GCC 4.6, I also note that after forwarding a disabled FTBFS bug upstream, I had within a day an answer that he could not reproduce the failure in an up-to-date Sid virtual machine. Of course he may have read the explanations more carefully, but he has a point: even after fixing the error that stopped the build, it is not straightforward to make sure that the successful build will still be successful after the GCC patch is reverted. Is there an easy way we can suggest to our upstreams to re-enable the errors ? That may be useful for them to update their code. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110517120050.ge31...@merveille.plessy.net
Re: Bug#615157: Using -Werror in CFLAGS for a debian package build
On 05/17/2011 02:00 PM, Charles Plessy wrote: Is there an easy way we can suggest to our upstreams to re-enable the errors ? That may be useful for them to update their code. - look out for / grep for the warnings - use gcc-snapshot - explicitly pass -Werror=unused-but... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dd2987b.7060...@debian.org
Using -Werror in CFLAGS for a debian package build
Hi -devel, I was working on nbd-server upstream, and so had ran ./configure with CFLAGS='-Wall -Werror', which I consider good practice when writing C code. What I didn't notice immediately was that gcc was emitting some warnings, but that the -Werror option was not honored for those warnings. Investigating turned up #615157 (Cc'd): the gcc maintainers have decided to disable -Werror for some new warnings, because otherwise it would cause FTBFS bugs in packages that have -Werror set in their debian/rules file. IMHO, this is the wrong way to handle such things. First and foremost, I do not believe that setting -Werror in a debian/rules file is the best way to maintain a package; -Werror is a development option which should not be used in a release build (which a Debian package is). When a package sets -Werror in its debian/rules file, it *will* FTBFS when the default compiler is changed, while not necessarily breaking the package itself. I don't think it adds value. That's a personal opinion, however, and we don't have a policy on this; so if a maintainer is willing to deal with the fallout of their packages failing to build when the default compiler is changed, that should probably be their problem. So long as they are ready to receive FTBFS bugs and fix them in a timely manner, oh well. It might still be an annoyance for a user who wants to build a package on a different compiler than what happens to be the default one, but it's not a fatal problem. And I can see how using -Werror *might* increase the quality of a package; some warnings are emitted on only some architectures, so having -Werror *could* ensure that architecture-specific bugs are eliminated before they potentially become a problem. It's not totally silly, but it still seems a bit excessive. At any rate, all that is undermined if gcc does not turn all warnings into errors; if a maintainer uses -Werror in a package, that means they *want* their package to FTBFS on warnings. Reducing the effect of -Werror would not seem to help these maintainers; presumably they want the warnings to be fixed in their source anyway, because eventually this breakage of -Werror will be reverted, and then their packages will FTBFS again. And while it's a very bad idea to introduce RC bugs in your reverse dependencies when we're near or in a freeze, I was under the impression that we're not currently in such a time, which would suggest that doing so would be acceptable currently. Additionally, reducing the effect of -Werror in that manner has an effect on those who use Debian sid as a development environment; put otherwise, the Debian default compiler is used for more than just Debian packages, and I don't think we should be mucking with it in this manner. Thoughts? -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a signature.asc Description: Digital signature
Re: Using -Werror in CFLAGS for a debian package build
Wouter Verhelst wou...@debian.org writes: What I didn't notice immediately was that gcc was emitting some warnings, but that the -Werror option was not honored for those warnings. Investigating turned up #615157 (Cc'd): the gcc maintainers have decided to disable -Werror for some new warnings, because otherwise it would cause FTBFS bugs in packages that have -Werror set in their debian/rules file. IMHO, this is the wrong way to handle such things. I was a bit dubious about it as well, for the reasons you state, but please note that GCC 4.6 introduced a major new warning about set but unused variables and, so far, every large or medium C code base that I have has had at least once instance of that warning. And I'm usually pretty picky about such things. If -Werror had not been disabled for this warning, my guess is that nearly every package using -Wall -Werror not previously tested with 4.6 would FTBFS. I don't like seeing us modify upstream compiler behavior in Debian this way, but I can understand not wanting to introduce what could have easily been hundreds of failures. (The problem, of course, is that those failures are still latent, and unless we're going to keep this going forward, we have cleanup to do so that we can go back to tracking GCC's normal behavior.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r57y9oqw@windlord.stanford.edu
Re: Using -Werror in CFLAGS for a debian package build
On 2011-05-17, Russ Allbery r...@debian.org wrote: I don't like seeing us modify upstream compiler behavior in Debian this way, but I can understand not wanting to introduce what could have easily been hundreds of failures. (The problem, of course, is that those failures are still latent, and unless we're going to keep this going forward, we have cleanup to do so that we can go back to tracking GCC's normal behavior.) I have seen several bug reports from the gcc maintainer saying | This package builds with -Werror, and GCC 4.6 triggers new warnings | which will make the package fail to build. Currently a Debian patch | just passes |-Wno-error=unused-but-set-variable and |-Wno-error=unused-but-set-parameter | to avoid build failures, but this patch will be reverted with the | GCC 4.6.1 release, and the severity of the report will be raised. Which I_think is a good compromise, and a case where I really think the gcc maintainer is doing good a communicating. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnit3fv7.p7v.nos...@sshway.ssh.pusling.com
Re: Using -Werror in CFLAGS for a debian package build
On Mon, May 16, 2011 at 05:04:07PM -0700, Russ Allbery wrote: Wouter Verhelst wou...@debian.org writes: What I didn't notice immediately was that gcc was emitting some warnings, but that the -Werror option was not honored for those warnings. Investigating turned up #615157 (Cc'd): the gcc maintainers have decided to disable -Werror for some new warnings, because otherwise it would cause FTBFS bugs in packages that have -Werror set in their debian/rules file. IMHO, this is the wrong way to handle such things. I was a bit dubious about it as well, for the reasons you state, but please note that GCC 4.6 introduced a major new warning about set but unused variables and, so far, every large or medium C code base that I have has had at least once instance of that warning. And I'm usually pretty picky about such things. Indeed; my own code runs into it as well. This is precisely why I'm unhappy about it; when I write code, I want the compiler to complain, loudly, when I do something dubious. When I build packages, I don't; instead, I then want the compiler to just compile. The difference should be in the CFLAGS that I pass it along, not in its defaults. If -Werror had not been disabled for this warning, my guess is that nearly every package using -Wall -Werror not previously tested with 4.6 would FTBFS. Yes, and I think we should allow that to happen. If a maintainer chooses to let their package fail because a new compiler version introduces new warnings, then we should not be second-guessing their reasons like this. I don't think it's smart for maintainers to use -Werror in their packages; but if they, after having informed themselves, choose to so anyway, then disabling warnings 'because it will make packages fail' is counter-productive. It's not like -Werror is the default. I don't like seeing us modify upstream compiler behavior in Debian this way, but I can understand not wanting to introduce what could have easily been hundreds of failures. (The problem, of course, is that those failures are still latent, and unless we're going to keep this going forward, we have cleanup to do so that we can go back to tracking GCC's normal behavior.) I'm not saying I don't understand the rationale; I do. But I don't agree with it; I don't think it's the right thing to do. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a signature.asc Description: Digital signature
