On alpha: /bin/sh ../../libtool --tag=CC --tag CC --mode=compile alpha-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -DOPENSC_CONF_PATH=\"/etc/opensc.conf\" -I../../src -O2 -mcpu=ev67 -mieee -pipe -Wall -Wextra -Wno-unused-parameter -Werror -c -o libopensc_la-reader-ctapi.lo `test -f 'reader-ctapi.c' || echo './'`reader-ctapi.c libtool: compile: alpha-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -DOPENSC_CONF_PATH=\"/etc/opensc.conf\" -I../../src -O2 -mcpu=ev67 -mieee -pipe -Wall -Wextra -Wno-unused-parameter -Werror -c reader-ctapi.c -fPIC -DPIC -o .libs/libopensc_la-reader-ctapi.o reader-ctapi.c: In function ‘ctapi_connect’: reader-ctapi.c:242:6: error: variable ‘r’ set but not used [-Werror=unused-but-set-variable] int r; ^ cc1: all warnings being treated as errors and on amd64: /bin/sh ../../libtool --tag=CC --tag CC --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -DOPENSC_CONF_PATH=\"/etc/opensc.conf\" -I../../src -O2 -march=native -pipe -Wall -Wextra -Wno-unused-parameter -Werror -c -o libopensc_la-card-miocos.lo `test -f 'card-miocos.c' || echo './'`card-miocos.c reader-ctapi.c: In function ‘ctapi_connect’: reader-ctapi.c:242:6: error: variable ‘r’ set but not used [-Werror=unused-but-set-variable] int r; ^
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=26457956de258b73a69556b983f74f31b25b2a36 commit 26457956de258b73a69556b983f74f31b25b2a36 Author: Alon Bar-Lev <alonbl@gentoo.org> AuthorDate: 2018-09-07 21:26:24 +0000 Commit: Alon Bar-Lev <alonbl@gentoo.org> CommitDate: 2018-09-07 21:26:46 +0000 dev-libs/opensc: fix -Werror and ctapi USE Closes: https://bugs.gentoo.org/show_bug.cgi?id=665464 Package-Manager: Portage-2.3.40, Repoman-2.3.9 dev-libs/opensc/files/opensc-0.18.0-build.patch | 34 +++++++++++++++++++++++++ 1 file changed, 34 insertions(+)
Thanks for the fix, but this isn't even the only bug reported against opensc because of Werror. Please fix the build system to not use Werror.
(In reply to Matt Turner from comment #2) > Thanks for the fix, but this isn't even the only bug reported against opensc > because of Werror. Please fix the build system to not use Werror. I did not see a useless error so far to make upstream change their policy. I am sending the fixes to upstream so we are good for now.
I think you're misunderstanding the issue with Werror. It's fine if developers want to use it, but for distros it just gums up the works. I'm not suggesting changing the build system upstream to remove Werror -- I'm suggesting stripping Werror out in Gentoo. Without Werror, the binaries installed by portage with and without your patch are identical. Werror just turns meaningless problems into blocking bugs. I'm surprised I'm having to make this argument to you.
I am fully aware of the implication and what Werror is. In normal case, upstream should not play with these flags unless a specific configuration option is used, for example --enable-strict. Filtering the flag by patching the autoconf and perform autoreconf is far more intrusive than just letting it go as long as upstream maintain package in good shape and accept patches to resolve issues.
(In reply to Alon Bar-Lev from comment #5) > I am fully aware of the implication and what Werror is. In normal case, > upstream should not play with these flags unless a specific configuration > option is used, for example --enable-strict. Filtering the flag by patching > the autoconf and perform autoreconf is far more intrusive than just letting > it go as long as upstream maintain package in good shape and accept patches > to resolve issues. I would probably accept that if I hadn't just discovered that the build was uselessly broken with USE=ctapi and that no one had noticed when stabilizing x86, amd64, ia64, ppc, ppc64, or arm.
<QA> Our policy on this is clear, -Werror shall not be enabled during build because it can cause random breakage on users' systems. Devmanual reference: https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed </QA>
Re-opening for Werror removal
(In reply to Mart Raudsepp from comment #8) > Re-opening for Werror removal Reclosing as I gave the rational.
<QA hat> The QA has stated the applicable policy, and you are expected to follow this policy. Please do not close this bug until this is handled accordingly. </QA hat>
(In reply to Michał Górny from comment #10) > <QA hat> > > The QA has stated the applicable policy, and you are expected to follow this > policy. Please do not close this bug until this is handled accordingly. > > </QA hat> QA policy == user happy and have no problem. QA policy != theoretical issues. In this case, there are no open bugs against this package, I as a maintainer fix all issues resulting from and including the Werror (as any bug). QA (aka quality) state of my packages is perfect. When I touch upstream package it should be for a *REAL* version that introduce noise to our users more than we can cope with. In this case I prefer not to touch package and push fixes (if needed) to friendly upstream. How to reach perfect QA state is up to maintainer, please do not open this bug again and respect other people.
GLEP 48 states clearly: 'Just because a particular QA violation has yet to cause an issue does not change the fact that it is still a QA violation.' Even though the evidence so far has proven that it *caused* an issue. The policy is clear here, and applicable to this package. As far as I'm aware, you haven't brought any argument to the contrary. Therefore, you are expected to follow the policy. If you believe the policy is wrong or needs a special exception for your package, then please follow the proper procedure for changing policies. However, until you do that and your change is accepted, you are still expected to follow the existing policy. If you believe QA is wrong to request you to follow the policy, you are free to request the Council to override the QA decision. However, until you do that and the Council overrides it, you are still expected to follow the QA decision.
Alon appears to have silently acquiesced in April: commit 8f7093361bd5d0227000fb17627e1bc2d365c993 Author: Alon Bar-Lev <alonbl@gentoo.org> Date: Tue Apr 2 21:10:40 2019 +0300 dev-libs/opensc: disable strict build Signed-off-by: Alon Bar-Lev <alonbl@gentoo.org> Package-Manager: Portage-2.3.62, Repoman-2.3.11
