Re: [gentoo-dev] Changing policy about -Werror
On Sat, Sep 22, 2018 at 1:33 AM Chí-Thanh Christopher Nguyễn wrote: > > Richard Yao schrieb: > > >> To make code behave differently it needs substantial amount of code > >> to provide you an example. You need to him O2<->O3 behaviour delta > >> after all. But I will try (for a different warning, it should not matter > >> much). > > Thanks. I had been incorrect about -O3 giving not us some additional > > information for warnings. My apologies for the confusion. > >> > >> Below is a reduced example of a larger C++ program. > >> Many thanks to Ulya for providing recent example! > > Not that it matters now, but there are examples of packages building at -O2 > but failing to build at -O3 optimization levels, due to -Werror. > > One is dev-libs/libcss: https://bugs.gentoo.org/626752 > It is matter, and shows that for selected packages in which upstream has strict policy of no warning, each warning should be investigated as it may be a true issue. The tool compiler provide to find these edge condition should not be ignored nor overridden. The fact that a package "builds" does not mean it is free of bugs. Regards, Alon
Re: [gentoo-dev] Changing policy about -Werror
Richard Yao schrieb: To make code behave differently it needs substantial amount of code to provide you an example. You need to him O2<->O3 behaviour delta after all. But I will try (for a different warning, it should not matter much). Thanks. I had been incorrect about -O3 giving not us some additional information for warnings. My apologies for the confusion. Below is a reduced example of a larger C++ program. Many thanks to Ulya for providing recent example! Not that it matters now, but there are examples of packages building at -O2 but failing to build at -O3 optimization levels, due to -Werror. One is dev-libs/libcss: https://bugs.gentoo.org/626752 Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing policy about -Werror
On Fri, 14 Sep 2018 23:15:28 +0300 Alon Bar-Lev wrote: > > > > Unused variable is a good example of typical benign warning: > > > > it was there all the time, it's not a new bug and does not > > > > warrant need for an immediate fix. > > > > > > Unused variable is a good example of CRITICAL potential issue > > > > I understand you point. I disagree with it. > > > > My litmus test: if behaviour of the package did not change after > > the fix then the issue was not real. > > But how can you get the report to evaluate if it is real or not? You don't. You don't get a report until user explicitly asks for it or encounters real bug. I would follow the same model Gentoo does for FEATURES=test and FEATURES=strict/stricter. If people like reporting build or test issues and have enough time for it they will enable the flag. > while we are looking for the trigger to evaluate. My take on it: we are not looking for them on every users' machine and it's ok to miss bugs and false positives as a result. -- Sergei
Re: [gentoo-dev] Changing policy about -Werror
> On Sep 14, 2018, at 7:07 PM, Sergei Trofimovich wrote:
>
> On Fri, 14 Sep 2018 11:54:57 -0400
> Richard Yao wrote:
>
My read of this is that the warning occurs regardless of optimization
level, but it could somehow be improved by optimization.
As for the last, it is for uninitialized variable reads. However, I think
you are misinterpreting the claim. The way that optimization level could
affect warning generation would be if the warning generation came after
optimization passes that could hide reads. That means that -O3 would
prevent the warning.
> ...
>> Either provide code examples that generate warnings in a way that
>> demonstrates that I am incorrect
>
> To make code behave differently it needs substantial amount of code
> to provide you an example. You need to him O2<->O3 behaviour delta
> after all. But I will try (for a different warning, it should not matter
> much).
Thanks. I had been incorrect about -O3 giving not us some additional
information for warnings. My apologies for the confusion.
>
> Below is a reduced example of a larger C++ program.
> Many thanks to Ulya for providing recent example!
>
> In this example -O3 manages to inline/const-propagate deep enough
> and find out potential null-deref. -O2 was not able to do it.
>
> $ bash -x ./mk_.sh
> + LANG=C
> + g++-8.2.0 -O2 -c 1.cc -Wnull-dereference
> + g++-8.2.0 -O3 -c 1.cc -Wnull-dereference
> 1.cc: In function 'bool foo(std::vector)':
> 1.cc:3:22: warning: null pointer dereference [-Wnull-dereference]
> typename h = e - d >> *g;
>~~^
> 1.cc:3:22: warning: null pointer dereference [-Wnull-dereference]
> typename h = e - d >> *g;
>~~^
>
> $ cat 1.cc
> #include
> template a c(a d, a e, b f, int *g) {
> typename h = e - d >> *g;
> for (; h;) if (f(*d)) if (f(*d)) return d;
> return d;
> }
> template i o(i d, i e, b f, int *g) {
> return c(d, e, f, g);
> }
> template i oo(i d, i e, b f, int *g) {
> return c(d, e, f, g);
> }
> template j k(j d, j e, b f, int *g) {
> return o(d, e, f, g);
> }
> template j kk(j d, j e, b f, int *g) {
> return oo(d, e, f, g);
> }
> bool cmpp(int);
> bool foo(std::vector l) {
> std::vector::const_iterator ib,
> ie = l.end(), m, n = k(ib, ie, cmpp, 0) = kk(m, ie, cmpp, 0);
> return m == n;
> }
>
> --
>
> Sergei
>
Re: [gentoo-dev] Changing policy about -Werror
On Fri, 14 Sep 2018 11:54:57 -0400
Richard Yao wrote:
> >> My read of this is that the warning occurs regardless of optimization
> >> level, but it could somehow be improved by optimization.
> >>
> >> As for the last, it is for uninitialized variable reads. However, I think
> >> you are misinterpreting the claim. The way that optimization level could
> >> affect warning generation would be if the warning generation came after
> >> optimization passes that could hide reads. That means that -O3 would
> >> prevent the warning.
...
> Either provide code examples that generate warnings in a way that
> demonstrates that I am incorrect
To make code behave differently it needs substantial amount of code
to provide you an example. You need to him O2<->O3 behaviour delta
after all. But I will try (for a different warning, it should not matter
much).
Below is a reduced example of a larger C++ program.
Many thanks to Ulya for providing recent example!
In this example -O3 manages to inline/const-propagate deep enough
and find out potential null-deref. -O2 was not able to do it.
$ bash -x ./mk_.sh
+ LANG=C
+ g++-8.2.0 -O2 -c 1.cc -Wnull-dereference
+ g++-8.2.0 -O3 -c 1.cc -Wnull-dereference
1.cc: In function 'bool foo(std::vector)':
1.cc:3:22: warning: null pointer dereference [-Wnull-dereference]
typename h = e - d >> *g;
~~^
1.cc:3:22: warning: null pointer dereference [-Wnull-dereference]
typename h = e - d >> *g;
~~^
$ cat 1.cc
#include
template a c(a d, a e, b f, int *g) {
typename h = e - d >> *g;
for (; h;) if (f(*d)) if (f(*d)) return d;
return d;
}
template i o(i d, i e, b f, int *g) {
return c(d, e, f, g);
}
template i oo(i d, i e, b f, int *g) {
return c(d, e, f, g);
}
template j k(j d, j e, b f, int *g) {
return o(d, e, f, g);
}
template j kk(j d, j e, b f, int *g) {
return oo(d, e, f, g);
}
bool cmpp(int);
bool foo(std::vector l) {
std::vector::const_iterator ib,
ie = l.end(), m, n = k(ib, ie, cmpp, 0) = kk(m, ie, cmpp, 0);
return m == n;
}
--
Sergei
Re: [gentoo-dev] Changing policy about -Werror
On Sat, Sep 15, 2018 at 1:14 AM Richard Yao wrote: > > On Sep 14, 2018, at 5:28 PM, Fabian Groffen wrote: > > > > On 15-09-2018 00:07:12 +0300, Alon Bar-Lev wrote: > >>> > >>> Perhaps, if one persists on going this route, only do this for platforms > >>> that upstream supports, such that arches which will suffer from this > >>> (typically ppc, sparc, ...) don't have to be blocked by this. > >> > >> Exactly in these cases the -Werror is useful as if upstream expects no > >> warnings then any warning should block installation and trigger bug > >> report. In Gentoo in many cases we use packages on platform has no > >> access to, our feedback to upstream is valuable. A great example is > >> gnutls in which we collectively (maintainer, unstable users, > >> architecture teams, stable users) found issues on architectures that > >> almost nobody other than Gentoo has access to. > >> > > > > I don't believe Gentoo users are (supposed to be) an extension of > > upstreams. If upstreams insist on that, they should make their software > > non-free, adding a non-modification clause or something. In any case, > > it is not Gentoo's job IMHO. In the end it is Gentoo who needs to care > > for its users. I prefer we do that by giving them an option to become > > that extension of upstream, e.g. by USE=upstream-cflags, which Gentoo > > disables by default. > I am in complete agreement on this. Users should not be guinea pigs to help > upstream unless they opt into it. A new release of upstream is out, early adopters (what we call unstable users) are guinea pings. A new release is stabilized, users are guinea pings. A new toolchain that upstream did not test, users are guinea pings. A new dependency version or a Gentoo virtual with "compatible library", users are guinea pings. Let's say upstream does not have access to architecture X we at Gentoo decide to support this architecture, maintainer do not have access to this architecture as well, architecture team is guinea pings, but it does not actually use the package, then back to early adopters and users. This process has nothing to do with -Werror, our process relays on users as guinea pings, by definition developers and arch teams cannot test entire software and all permutation of the software. The -Werror (if supported by upstream and downstream, I outlined the conditions many times) is a tool (among other) to help stop the process at early stage when suspicious finding is there to allow deal with the situation to make sure that the software is compatible with an environment or permutation that upstream and maintainer do not have direct access to. It is a tool to help users to have better system integrity (once again, provided some conditions apply).
Re: [gentoo-dev] Changing policy about -Werror
I think you misunderstood what I wrote, or I wasn't clear enough. Richard summed up my intention nicely in his response. Fabian On 15-09-2018 00:46:24 +0300, Alon Bar-Lev wrote: > On Sat, Sep 15, 2018 at 12:29 AM Fabian Groffen wrote: > > > > On 15-09-2018 00:07:12 +0300, Alon Bar-Lev wrote: > > > > > > > > Perhaps, if one persists on going this route, only do this for platforms > > > > that upstream supports, such that arches which will suffer from this > > > > (typically ppc, sparc, ...) don't have to be blocked by this. > > > > > > Exactly in these cases the -Werror is useful as if upstream expects no > > > warnings then any warning should block installation and trigger bug > > > report. In Gentoo in many cases we use packages on platform has no > > > access to, our feedback to upstream is valuable. A great example is > > > gnutls in which we collectively (maintainer, unstable users, > > > architecture teams, stable users) found issues on architectures that > > > almost nobody other than Gentoo has access to. > > > > > > > I don't believe Gentoo users are (supposed to be) an extension of > > upstreams. > > This is exactly what I think that is special about Gentoo, and the > reason I use Gentoo. Unlike other distribution Gentoo is the closest > thing of using upstream. A maintainer in Gentoo who is not see himself > part of the upstream packages he maintains has far less impact than a > maintainer who does see himself as part of upstream or is upstream. > > Per your statement, we should not allow any architecture or setup that > upstream, such as exact versioning, architecture or toolchain. > > > If upstreams insist on that, they should make their software > > non-free, adding a non-modification clause or something. In any case, > > it is not Gentoo's job IMHO. > > Then we cannot re-distribute or patch, how is it related to the > discussion? We are talking about open source projects and I know it is > cliche... the "greater good" and helping the "free open source > movement" a a viable alternative. I thought this is what unite us > here. > > > In the end it is Gentoo who needs to care > > for its users. I prefer we do that by giving them an option to become > > that extension of upstream, e.g. by USE=upstream-cflags, which Gentoo > > disables by default. > > Do you think someone do not care about the users? Do you actually > think upstream does not care about users? I do not understand this > statement. If downstream maintainer believes that upstream is friendly > for the Gentoo overhead (which is higher than binary distributions) or > create the relationship in which Gentoo is 1st citizen at upstream, > why do you think users cannot use vanilla upstream? > > > As maintainer and/or enthusiastic user, like you wrote for gnutls, I > > would be more than happy to provide build logs/errors for all the arches > > I have access to. So like I wrote before, I think we should consider > > case-by-case basis to make it easy to do so. > > This entire discussion is to allow case-by-case and not black and > white approach recently enforced. > > Regards, > Alon > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
> On Sep 14, 2018, at 5:28 PM, Fabian Groffen wrote: > > On 15-09-2018 00:07:12 +0300, Alon Bar-Lev wrote: >>> >>> Perhaps, if one persists on going this route, only do this for platforms >>> that upstream supports, such that arches which will suffer from this >>> (typically ppc, sparc, ...) don't have to be blocked by this. >> >> Exactly in these cases the -Werror is useful as if upstream expects no >> warnings then any warning should block installation and trigger bug >> report. In Gentoo in many cases we use packages on platform has no >> access to, our feedback to upstream is valuable. A great example is >> gnutls in which we collectively (maintainer, unstable users, >> architecture teams, stable users) found issues on architectures that >> almost nobody other than Gentoo has access to. >> > > I don't believe Gentoo users are (supposed to be) an extension of > upstreams. If upstreams insist on that, they should make their software > non-free, adding a non-modification clause or something. In any case, > it is not Gentoo's job IMHO. In the end it is Gentoo who needs to care > for its users. I prefer we do that by giving them an option to become > that extension of upstream, e.g. by USE=upstream-cflags, which Gentoo > disables by default. I am in complete agreement on this. Users should not be guinea pigs to help upstream unless they opt into it. > > As maintainer and/or enthusiastic user, like you wrote for gnutls, I > would be more than happy to provide build logs/errors for all the arches > I have access to. So like I wrote before, I think we should consider > case-by-case basis to make it easy to do so. > > Fabian > > -- > Fabian Groffen > Gentoo on a different level
Re: [gentoo-dev] Changing policy about -Werror
> On Sep 14, 2018, at 4:20 PM, Michael Orlitzky wrote: > > On 09/14/2018 03:58 PM, Richard Yao wrote: >>> >>> No one has answered the question: what do you do when a stable package >>> breaks because of a new warning? >>> >>> ...> >> Wouldn’t this be largely covered as part of GCC stabilization? We could >> reserve the right to kill -Werror in a package where it blocks GCC >> stabilization if the maintainer does not handle it in a timely manner. >>> > > They would be uncovered during GCC stabilization, but then you're right > back in the original situation: how do you fix the stable package? The > only answer that doesn't violate some other policy is to patch it in a > new revision and wait for it to stabilize again. This depends on the issue. > > Other questions arise: Do we block stabilization of clang et al.? We probably should start doing that once Clang is able to build everything, but someone would need to volunteer to handle it. It is a big job. > > If we can simply remove -Werror because it's been a month, were the > warnings ever really important to begin with? That was a suggestion to handle maintainer non-response. You can already do whatever you want if the maintainer is non-responsive after telling him in a bug that you will do something if a response is not made in a reasonable period (e.g. 2 weeks). I am just pointing it out. > > How many packages do we want to make the toolchain team stop and fix > before they can do their jobs? Presumably, the maintainers would handle this. If they cannot, they should not be honoring upstream’s -Werror policy.
Re: [gentoo-dev] Changing policy about -Werror
On Sat, Sep 15, 2018 at 12:29 AM Fabian Groffen wrote: > > On 15-09-2018 00:07:12 +0300, Alon Bar-Lev wrote: > > > > > > Perhaps, if one persists on going this route, only do this for platforms > > > that upstream supports, such that arches which will suffer from this > > > (typically ppc, sparc, ...) don't have to be blocked by this. > > > > Exactly in these cases the -Werror is useful as if upstream expects no > > warnings then any warning should block installation and trigger bug > > report. In Gentoo in many cases we use packages on platform has no > > access to, our feedback to upstream is valuable. A great example is > > gnutls in which we collectively (maintainer, unstable users, > > architecture teams, stable users) found issues on architectures that > > almost nobody other than Gentoo has access to. > > > > I don't believe Gentoo users are (supposed to be) an extension of > upstreams. This is exactly what I think that is special about Gentoo, and the reason I use Gentoo. Unlike other distribution Gentoo is the closest thing of using upstream. A maintainer in Gentoo who is not see himself part of the upstream packages he maintains has far less impact than a maintainer who does see himself as part of upstream or is upstream. Per your statement, we should not allow any architecture or setup that upstream, such as exact versioning, architecture or toolchain. > If upstreams insist on that, they should make their software > non-free, adding a non-modification clause or something. In any case, > it is not Gentoo's job IMHO. Then we cannot re-distribute or patch, how is it related to the discussion? We are talking about open source projects and I know it is cliche... the "greater good" and helping the "free open source movement" a a viable alternative. I thought this is what unite us here. > In the end it is Gentoo who needs to care > for its users. I prefer we do that by giving them an option to become > that extension of upstream, e.g. by USE=upstream-cflags, which Gentoo > disables by default. Do you think someone do not care about the users? Do you actually think upstream does not care about users? I do not understand this statement. If downstream maintainer believes that upstream is friendly for the Gentoo overhead (which is higher than binary distributions) or create the relationship in which Gentoo is 1st citizen at upstream, why do you think users cannot use vanilla upstream? > As maintainer and/or enthusiastic user, like you wrote for gnutls, I > would be more than happy to provide build logs/errors for all the arches > I have access to. So like I wrote before, I think we should consider > case-by-case basis to make it easy to do so. This entire discussion is to allow case-by-case and not black and white approach recently enforced. Regards, Alon
Re: [gentoo-dev] Changing policy about -Werror
On 15-09-2018 00:07:12 +0300, Alon Bar-Lev wrote: > > > > Perhaps, if one persists on going this route, only do this for platforms > > that upstream supports, such that arches which will suffer from this > > (typically ppc, sparc, ...) don't have to be blocked by this. > > Exactly in these cases the -Werror is useful as if upstream expects no > warnings then any warning should block installation and trigger bug > report. In Gentoo in many cases we use packages on platform has no > access to, our feedback to upstream is valuable. A great example is > gnutls in which we collectively (maintainer, unstable users, > architecture teams, stable users) found issues on architectures that > almost nobody other than Gentoo has access to. > I don't believe Gentoo users are (supposed to be) an extension of upstreams. If upstreams insist on that, they should make their software non-free, adding a non-modification clause or something. In any case, it is not Gentoo's job IMHO. In the end it is Gentoo who needs to care for its users. I prefer we do that by giving them an option to become that extension of upstream, e.g. by USE=upstream-cflags, which Gentoo disables by default. As maintainer and/or enthusiastic user, like you wrote for gnutls, I would be more than happy to provide build logs/errors for all the arches I have access to. So like I wrote before, I think we should consider case-by-case basis to make it easy to do so. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
On Sat, Sep 15, 2018 at 12:02 AM Fabian Groffen wrote: > > On 14-09-2018 16:29:43 -0400, Rich Freeman wrote: > > On Fri, Sep 14, 2018 at 4:20 PM Michael Orlitzky wrote: > > > > > > On 09/14/2018 03:58 PM, Richard Yao wrote: > > > >> > > > >> No one has answered the question: what do you do when a stable package > > > >> breaks because of a new warning? > > > >> > > > >> ...> > > > > Wouldn’t this be largely covered as part of GCC stabilization? We could > > > > reserve the right to kill -Werror in a package where it blocks GCC > > > > stabilization if the maintainer does not handle it in a timely manner. > > > >> > > > > > > They would be uncovered during GCC stabilization, but then you're right > > > back in the original situation: how do you fix the stable package? The > > > only answer that doesn't violate some other policy is to patch it in a > > > new revision and wait for it to stabilize again. > > > > > > Other questions arise: Do we block stabilization of clang et al.? > > > > > > > Presumably we could make it a blocker, so then portage won't install > > the new stable toolchain. That buys time and only affects users of > > that particular package. But, as I pointed out before you can do that > > without using -Werror - just block installation with an unqualified > > toolchain. > > > > You would only use an approach like this for packages where QA was > > fairly important, so the inconvenience would be worth it. > > Perhaps, if one persists on going this route, only do this for platforms > that upstream supports, such that arches which will suffer from this > (typically ppc, sparc, ...) don't have to be blocked by this. Exactly in these cases the -Werror is useful as if upstream expects no warnings then any warning should block installation and trigger bug report. In Gentoo in many cases we use packages on platform has no access to, our feedback to upstream is valuable. A great example is gnutls in which we collectively (maintainer, unstable users, architecture teams, stable users) found issues on architectures that almost nobody other than Gentoo has access to.
Re: [gentoo-dev] Changing policy about -Werror
On 14-09-2018 16:29:43 -0400, Rich Freeman wrote: > On Fri, Sep 14, 2018 at 4:20 PM Michael Orlitzky wrote: > > > > On 09/14/2018 03:58 PM, Richard Yao wrote: > > >> > > >> No one has answered the question: what do you do when a stable package > > >> breaks because of a new warning? > > >> > > >> ...> > > > Wouldn’t this be largely covered as part of GCC stabilization? We could > > > reserve the right to kill -Werror in a package where it blocks GCC > > > stabilization if the maintainer does not handle it in a timely manner. > > >> > > > > They would be uncovered during GCC stabilization, but then you're right > > back in the original situation: how do you fix the stable package? The > > only answer that doesn't violate some other policy is to patch it in a > > new revision and wait for it to stabilize again. > > > > Other questions arise: Do we block stabilization of clang et al.? > > > > Presumably we could make it a blocker, so then portage won't install > the new stable toolchain. That buys time and only affects users of > that particular package. But, as I pointed out before you can do that > without using -Werror - just block installation with an unqualified > toolchain. > > You would only use an approach like this for packages where QA was > fairly important, so the inconvenience would be worth it. Perhaps, if one persists on going this route, only do this for platforms that upstream supports, such that arches which will suffer from this (typically ppc, sparc, ...) don't have to be blocked by this. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
On Fri, Sep 14, 2018 at 4:20 PM Michael Orlitzky wrote: > > On 09/14/2018 03:58 PM, Richard Yao wrote: > >> > >> No one has answered the question: what do you do when a stable package > >> breaks because of a new warning? > >> > >> ...> > > Wouldn’t this be largely covered as part of GCC stabilization? We could > > reserve the right to kill -Werror in a package where it blocks GCC > > stabilization if the maintainer does not handle it in a timely manner. > >> > > They would be uncovered during GCC stabilization, but then you're right > back in the original situation: how do you fix the stable package? The > only answer that doesn't violate some other policy is to patch it in a > new revision and wait for it to stabilize again. > > Other questions arise: Do we block stabilization of clang et al.? > Presumably we could make it a blocker, so then portage won't install the new stable toolchain. That buys time and only affects users of that particular package. But, as I pointed out before you can do that without using -Werror - just block installation with an unqualified toolchain. You would only use an approach like this for packages where QA was fairly important, so the inconvenience would be worth it. -- Rich
Re: [gentoo-dev] Changing policy about -Werror
On 09/14/2018 03:58 PM, Richard Yao wrote: >> >> No one has answered the question: what do you do when a stable package >> breaks because of a new warning? >> >> ...> > Wouldn’t this be largely covered as part of GCC stabilization? We could > reserve the right to kill -Werror in a package where it blocks GCC > stabilization if the maintainer does not handle it in a timely manner. >> They would be uncovered during GCC stabilization, but then you're right back in the original situation: how do you fix the stable package? The only answer that doesn't violate some other policy is to patch it in a new revision and wait for it to stabilize again. Other questions arise: Do we block stabilization of clang et al.? If we can simply remove -Werror because it's been a month, were the warnings ever really important to begin with? How many packages do we want to make the toolchain team stop and fix before they can do their jobs?
Re: [gentoo-dev] Changing policy about -Werror
On Fri, Sep 14, 2018 at 10:53 PM Sergei Trofimovich wrote: > > On Fri, 14 Sep 2018 19:40:13 +0300 > Alon Bar-Lev wrote: > > > > > No dependency of toolchain nor annotations. > > A strict policy of no warnings will require changes as dependencies > > including toolchain are progressing. > > This creates an overhead for selected packages. > > A maintainer and the non-stable team should be able to know the package > > status. > > Preferably this may be done by automation, I appreciate the work of > > Toralf Förster with tinderbox to automate check various cases. > > When a new slot of toolchain is available, maintainers should check > > their packages in any case, there are other issues and side affects > > that we experienced, especially in C++ packages. > > For these packages usually there are 3 for each slot: the current > > stable, the next stable and the non-stable, so the overhead is > > constrained. > > Sorry. I'm afraid I missed your answer. I'll restate the question again: > > If you do it then what is your workflow to fix breakages > appearing in stable packages caused by minor environment > changes like toolchain tweaks? > > I mean mechanically as a package maintainer. > > Since you did not mention it I see a few alternatives: > - revbump a package with a backport of a local fix and fast-track > stabilization without usual soak time in ~arch Fix in place if false positive. Revision bump if positive. > - pull new upstream version and fast-track stabilization without > usual soak time in ~arch No reason to wait for upstream if obvious positive just like any bug fix. > - no revbump, apply the patch as-is and hope it does not break > existing users. Correct. > - anything else? Patching the package (stable and unstable) to remove -Werror if too many of them and downstream maintainer reaches to a conclusion that the overhead is too high and benefit is little and provide this feedback to upstream to work together on a new release of upstream which resolves all warnings with newer toolchain. > > > > Unused variable is a good example of typical benign warning: > > > it was there all the time, it's not a new bug and does not > > > warrant need for an immediate fix. > > > > Unused variable is a good example of CRITICAL potential issue > > I understand you point. I disagree with it. > > My litmus test: if behaviour of the package did not change after > the fix then the issue was not real. But how can you get the report to evaluate if it is real or not? I fail to understand this argument that is repeated over and over. Everyone is smart after the did... while we are looking for the trigger to evaluate. > > > Toolchain just happend to get better at control flow graph > > > analysis. Fix can easily wait for next release and save > > > everyone's time. > > > > Once again, the number of permutation of build and architecture may > > reveal issues that are cannot be detected on maintainer machine. > > If a fix is a real issue that is found in stable package, do you > > suggest to wait for next release to save whose time? > > It's up to maintainer to decide on how to resolve the issue once > maintainer understands the scope of the problem. Correct. My believe is that it is up to maintainer to decide. > > Once again I outlined the cases in which -Werror can be preserved, I > > will repeat... (a) upstream has strict policy of no-warnings, (b) > > upstream added -Werror, (c) downstream opinion is that upstream is > > following the policy, (d) upstream is friendly, (e) downstream accepts > > the potential maintenance overhead. > > Your proposal is clear. Thanks for restating it. > > I still think keeping -Werror enabled by default makes more harm > than good. Yes, but we are not talking about by default, right? > > > Gentoo does not normally run tests on user's systems either. > > > Tests are arguably a lot more precise in pointing out real > > > problems in software. > > > > Correct. I believe that this may be revisit as well, for selected > > packages in which tests are stable run them on user machines. There is > > no reason why we cannot add a directive to ebuild to enable tests by > > default and let user to disable this to save CPU/time of build. > > Additional thanks for considering an option to disable tests back. > Any mechanism that is fully supported by upstream and downstream maintainer find it stable should be enabled by default. I do see the benefit of disabling tests not because they may break as per the same argument I would like to have these reported and investigated, but to save resources (time and CPU) which may be significant. Thanks, Alon
Re: [gentoo-dev] Changing policy about -Werror
> On Sep 14, 2018, at 3:29 PM, Michael Orlitzky wrote: > >> On 09/14/2018 01:52 PM, Rich Freeman wrote: >> >> Wouldn't the flip side of this be demonstrating that this has actually >> caused issues? If following upstream discovers no bugs and also >> causes no issues, why not leave it to maintainer discretion? >> > > We know it causes issues, there are hundreds of bugs about it (bugzilla > stops counting at 500 on a search for "Werror"). > > No one has answered the question: what do you do when a stable package > breaks because of a new warning? > > If there's no answer to that question that doesn't involve making an > unofficial in-place downstream-only edit to a piece of code that is (by > the opposing argument) intensely security-critical in a stable package, > then we're all wasting our time talking about this. Wouldn’t this be largely covered as part of GCC stabilization? We could reserve the right to kill -Werror in a package where it blocks GCC stabilization if the maintainer does not handle it in a timely manner. >
Re: [gentoo-dev] Changing policy about -Werror
On Fri, 14 Sep 2018 19:40:13 +0300 Alon Bar-Lev wrote: > On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich wrote: > > > > On Tue, 11 Sep 2018 12:44:38 +0300 > > Alon Bar-Lev wrote: > > > > I'm personally in favour of not allowing -Werror > > to be in build system unconditionally. > > > > Maintainer is free to implement --enable-werror any way > > it's convenient to run on their own extended sanity checks > > and optionally expose it to users. Be it USE flag or > > EXTRA_ECONF option. > > This discussion is not for downstream to have a more strict policy > than upstream. Correct. To clarify: I was talking only about packages with following properties: 1. existing -Werror enabled upstream by default (or unconditionally) 2. disabled by default downstream by default (WRT current policy) Nothing more. > > Do you intend to keep -Werror for case when ebuild goes > > stable as well? > > Correct. > > > If you do it then what is your workflow to fix breakages > > appearing in stable packages caused by minor environment > > changes like toolchain tweaks? > > Correct. > > > Add another round of stabilization on each arch team? It > > sounds like your default assumption that code needs to be > > changed in a semantically significant way: add annotations > > that might not like some toolchains, remove unused code. > > No dependency of toolchain nor annotations. > A strict policy of no warnings will require changes as dependencies > including toolchain are progressing. > This creates an overhead for selected packages. > A maintainer and the non-stable team should be able to know the package > status. > Preferably this may be done by automation, I appreciate the work of > Toralf Förster with tinderbox to automate check various cases. > When a new slot of toolchain is available, maintainers should check > their packages in any case, there are other issues and side affects > that we experienced, especially in C++ packages. > For these packages usually there are 3 for each slot: the current > stable, the next stable and the non-stable, so the overhead is > constrained. Sorry. I'm afraid I missed your answer. I'll restate the question again: If you do it then what is your workflow to fix breakages appearing in stable packages caused by minor environment changes like toolchain tweaks? I mean mechanically as a package maintainer. Since you did not mention it I see a few alternatives: - revbump a package with a backport of a local fix and fast-track stabilization without usual soak time in ~arch - pull new upstream version and fast-track stabilization without usual soak time in ~arch - no revbump, apply the patch as-is and hope it does not break existing users. - anything else? > > Unused variable is a good example of typical benign warning: > > it was there all the time, it's not a new bug and does not > > warrant need for an immediate fix. > > Unused variable is a good example of CRITICAL potential issue I understand you point. I disagree with it. My litmus test: if behaviour of the package did not change after the fix then the issue was not real. > > Toolchain just happend to get better at control flow graph > > analysis. Fix can easily wait for next release and save > > everyone's time. > > Once again, the number of permutation of build and architecture may > reveal issues that are cannot be detected on maintainer machine. > If a fix is a real issue that is found in stable package, do you > suggest to wait for next release to save whose time? It's up to maintainer to decide on how to resolve the issue once maintainer understands the scope of the problem. > Once again I outlined the cases in which -Werror can be preserved, I > will repeat... (a) upstream has strict policy of no-warnings, (b) > upstream added -Werror, (c) downstream opinion is that upstream is > following the policy, (d) upstream is friendly, (e) downstream accepts > the potential maintenance overhead. Your proposal is clear. Thanks for restating it. I still think keeping -Werror enabled by default makes more harm than good. > > Gentoo does not normally run tests on user's systems either. > > Tests are arguably a lot more precise in pointing out real > > problems in software. > > Correct. I believe that this may be revisit as well, for selected > packages in which tests are stable run them on user machines. There is > no reason why we cannot add a directive to ebuild to enable tests by > default and let user to disable this to save CPU/time of build. Additional thanks for considering an option to disable tests back. -- Sergei
Re: [gentoo-dev] Changing policy about -Werror
On 09/14/2018 01:52 PM, Rich Freeman wrote: > > Wouldn't the flip side of this be demonstrating that this has actually > caused issues? If following upstream discovers no bugs and also > causes no issues, why not leave it to maintainer discretion? > We know it causes issues, there are hundreds of bugs about it (bugzilla stops counting at 500 on a search for "Werror"). No one has answered the question: what do you do when a stable package breaks because of a new warning? If there's no answer to that question that doesn't involve making an unofficial in-place downstream-only edit to a piece of code that is (by the opposing argument) intensely security-critical in a stable package, then we're all wasting our time talking about this.
Re: [gentoo-dev] Changing policy about -Werror
On Fri, Sep 14, 2018 at 8:53 PM Michał Górny wrote:
>
> On Fri, 2018-09-14 at 20:48 +0300, Alon Bar-Lev wrote:
> > On Fri, Sep 14, 2018 at 8:33 PM Michał Górny wrote:
> >
> > > > Let's do this the other way around and be react based on facts and not
> > > > speculations.
> > > > Let's change the policy for a year for selected packages as I
> > > > outlined, monitor bugs and after a year see response times, affected
> > > > users and if downstream patches are accumulated. Then we can decide if
> > > > we need to patch upstream packages.
> > > > If we need to patch upstream package anyway, not follow upstream
> > > > policy and not accepting input for various of permutations and
> > > > architecture from all users, this discussion is nearly void.
> > > >
> > >
> > > ...and for how long did you exactly ignore the standing policy that
> > > suddenly we need a new testing period? How about we do the opposite
> > > and you prove a *single* bug found downstream using this method so far?
> > >
> > > Because so far this discussion is not much different than "let's make
> > > the ebuild fail for some values of ${RANDOM}, and add extra values when
> > > users complain". Though the variant with random has probably a greater
> > > chance of failing when *actual* security issues happen.
> >
> > OK, back to personal discussion, unfortunately you question this in
> > this principal thread.
> >
> > Personal response:
> > In all my years in Gentoo, I've never thought the maintainer lose his
> > judgement of how to maintain a package as long as the he/she provide a
> > great service to users.
> > I've never thought or read this (and other) paragraph as a strict
> > white and black nor the holy bible , but a suggestion of how to
> > provide a great service to user with the least overhead to maintainer,
> > the best practice, the common case.
> > I believe there was no complains from users about these packages, on
> > the opposite users report issues and are happy when resolved after
> > proper investigation.
> > I guess something had changed recently in Gentoo in which QA try to
> > take the maintainer judgement try to enforce a black and white
> > perspective and without looking at bug history and other sources.
> > I believe this is a regression and not a progression, I was very
> > disappointed to see this new side of Gentoo in which common sense for
> > a specific case cannot be discussed individually, nor that a fixed bug
> > is hijacked to discuss a principal issue without opening a separate
> > formal QA request to discuss properly, address some of the argument
> > raised by fellow developers and the reaction of requesting to ban
> > developers without any mature discussion. As you can see this in this
> > thread is not black and white.
> >
>
> I should point out *once again* that:
>
> a. nobody requested banning developers,
>
> b. Bugzilla access suspension was requested because of your hostility
> in closing the bug and not the technical issue in question --
> or in other words, to prevent you from closing the bug again.
>
> However, if you continue spreading harmful misinformation about my
> intentions in attempt to prove your point in technical matter, then
> I believe we have much more serious problem to address here.
Unfortunately you still continue the personal discussion in principal
thread. I will not cooperate with that as it missing the point. Throw
the entire process you are trying to enforce your view and your
interpretation of the process as if enforcing that may have benefit.
Your request to ban via bugzilla access was rejected with explanation.
The bug that was closed was fixed, if you wanted to have a principal
discussion you should had opened a different principal one and discuss
the issue in opened mind, reaching to a conclusion that we need to
escalate the discussion together. I beg you as I beg you in bugzilla,
please do not turn this thread to personal one, it is not productive.
Re: [gentoo-dev] Changing policy about -Werror
On 09/13/2018 07:36 AM, Richard Yao wrote: > > >> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann wrote: >> >>> On 2018-09-12 16:50, Rich Freeman wrote: >>> There is also the case where we want these warnings to block >>> installation, because the risk of there being a problem is too great. >> >> I really disagree with that. So many devs have already said multiple >> times in this thread that "-Werror" is only turning existing warnings >> into fatal errors but "-Werror" itself doesn't add any new checks and >> more often requires "-O3" to be useful. > The way that compilers work is that the warnings are generated in the front > end while the optimization level affects the backend. That means that -O3 has > no effect on the code that does error generation. This remark about -O3 being > needed to make -Werror useful is just plain wrong. I had a discussion off list about this. My remarks on this were incorrect. However, I strongly disagree that -O3 is necessary for diagnostics to be useful. >> So let's turn this around: Please show us a *real* case within Gentoo >> where "-Werror" prevented a real problem which wouldn't otherwise being >> noticed. E.g. show us a package which was merged on user's system, >> replacing a working previous version of that package causing *real* >> problems which could have been prevented if package would have set >> "-Werror". >> >> Unless you can do that we don't really need to discuss this. Simply >> because everyone interested in "-Werror" *can* set that flag via CFLAGS, >> even just per package, whereas the majority, not interested in this, >> cannot do the same to filter "-Werror". Nobody advocating for "-Werror" >> replied to that fact yet. >> >> >> -- >> Regards, >> Thomas Deutschmann / Gentoo Linux Developer >> C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 >> > > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
On Fri, 2018-09-14 at 20:48 +0300, Alon Bar-Lev wrote:
> On Fri, Sep 14, 2018 at 8:33 PM Michał Górny wrote:
>
> > > Let's do this the other way around and be react based on facts and not
> > > speculations.
> > > Let's change the policy for a year for selected packages as I
> > > outlined, monitor bugs and after a year see response times, affected
> > > users and if downstream patches are accumulated. Then we can decide if
> > > we need to patch upstream packages.
> > > If we need to patch upstream package anyway, not follow upstream
> > > policy and not accepting input for various of permutations and
> > > architecture from all users, this discussion is nearly void.
> > >
> >
> > ...and for how long did you exactly ignore the standing policy that
> > suddenly we need a new testing period? How about we do the opposite
> > and you prove a *single* bug found downstream using this method so far?
> >
> > Because so far this discussion is not much different than "let's make
> > the ebuild fail for some values of ${RANDOM}, and add extra values when
> > users complain". Though the variant with random has probably a greater
> > chance of failing when *actual* security issues happen.
>
> OK, back to personal discussion, unfortunately you question this in
> this principal thread.
>
> Personal response:
> In all my years in Gentoo, I've never thought the maintainer lose his
> judgement of how to maintain a package as long as the he/she provide a
> great service to users.
> I've never thought or read this (and other) paragraph as a strict
> white and black nor the holy bible , but a suggestion of how to
> provide a great service to user with the least overhead to maintainer,
> the best practice, the common case.
> I believe there was no complains from users about these packages, on
> the opposite users report issues and are happy when resolved after
> proper investigation.
> I guess something had changed recently in Gentoo in which QA try to
> take the maintainer judgement try to enforce a black and white
> perspective and without looking at bug history and other sources.
> I believe this is a regression and not a progression, I was very
> disappointed to see this new side of Gentoo in which common sense for
> a specific case cannot be discussed individually, nor that a fixed bug
> is hijacked to discuss a principal issue without opening a separate
> formal QA request to discuss properly, address some of the argument
> raised by fellow developers and the reaction of requesting to ban
> developers without any mature discussion. As you can see this in this
> thread is not black and white.
>
I should point out *once again* that:
a. nobody requested banning developers,
b. Bugzilla access suspension was requested because of your hostility
in closing the bug and not the technical issue in question --
or in other words, to prevent you from closing the bug again.
However, if you continue spreading harmful misinformation about my
intentions in attempt to prove your point in technical matter, then
I believe we have much more serious problem to address here.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Changing policy about -Werror
On Fri, Sep 14, 2018 at 1:33 PM Michał Górny wrote: > > On Fri, 2018-09-14 at 20:22 +0300, Alon Bar-Lev wrote: > > Let's do this the other way around and be react based on facts and not > > speculations. > > Let's change the policy for a year for selected packages as I > > outlined, monitor bugs and after a year see response times, affected > > users and if downstream patches are accumulated. Then we can decide if > > we need to patch upstream packages. > > If we need to patch upstream package anyway, not follow upstream > > policy and not accepting input for various of permutations and > > architecture from all users, this discussion is nearly void. > > > ...and for how long did you exactly ignore the standing policy that > suddenly we need a new testing period? How about we do the opposite > and you prove a *single* bug found downstream using this method so far? Wouldn't the flip side of this be demonstrating that this has actually caused issues? If following upstream discovers no bugs and also causes no issues, why not leave it to maintainer discretion? I'm not talking about hypothetical issues. I'm talking about specific issues with this specific example, that supposedly has already done all the testing necessary... -- Rich
Re: [gentoo-dev] Changing policy about -Werror
On Fri, Sep 14, 2018 at 8:33 PM Michał Górny wrote:
> > Let's do this the other way around and be react based on facts and not
> > speculations.
> > Let's change the policy for a year for selected packages as I
> > outlined, monitor bugs and after a year see response times, affected
> > users and if downstream patches are accumulated. Then we can decide if
> > we need to patch upstream packages.
> > If we need to patch upstream package anyway, not follow upstream
> > policy and not accepting input for various of permutations and
> > architecture from all users, this discussion is nearly void.
> >
>
> ...and for how long did you exactly ignore the standing policy that
> suddenly we need a new testing period? How about we do the opposite
> and you prove a *single* bug found downstream using this method so far?
>
> Because so far this discussion is not much different than "let's make
> the ebuild fail for some values of ${RANDOM}, and add extra values when
> users complain". Though the variant with random has probably a greater
> chance of failing when *actual* security issues happen.
OK, back to personal discussion, unfortunately you question this in
this principal thread.
Personal response:
In all my years in Gentoo, I've never thought the maintainer lose his
judgement of how to maintain a package as long as the he/she provide a
great service to users.
I've never thought or read this (and other) paragraph as a strict
white and black nor the holy bible , but a suggestion of how to
provide a great service to user with the least overhead to maintainer,
the best practice, the common case.
I believe there was no complains from users about these packages, on
the opposite users report issues and are happy when resolved after
proper investigation.
I guess something had changed recently in Gentoo in which QA try to
take the maintainer judgement try to enforce a black and white
perspective and without looking at bug history and other sources.
I believe this is a regression and not a progression, I was very
disappointed to see this new side of Gentoo in which common sense for
a specific case cannot be discussed individually, nor that a fixed bug
is hijacked to discuss a principal issue without opening a separate
formal QA request to discuss properly, address some of the argument
raised by fellow developers and the reaction of requesting to ban
developers without any mature discussion. As you can see this in this
thread is not black and white.
Re: [gentoo-dev] Changing policy about -Werror
On 09/13/2018 12:03 PM, Fabian Groffen wrote:
> On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
>>
>>
>>> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann wrote:
>>>
On 2018-09-12 16:50, Rich Freeman wrote:
There is also the case where we want these warnings to block
installation, because the risk of there being a problem is too great.
>>>
>>> I really disagree with that. So many devs have already said multiple
>>> times in this thread that "-Werror" is only turning existing warnings
>>> into fatal errors but "-Werror" itself doesn't add any new checks and
>>> more often requires "-O3" to be useful.
>> The way that compilers work is that the warnings are generated in the front
>> end while the optimization level affects the backend. That means that -O3
>> has no effect on the code that does error generation. This remark about -O3
>> being needed to make -Werror useful is just plain wrong.
>
> Huh? -O3 enables more checks, which can generate more warnings. -O3
> isn't "needed", but if upstream is so interested in clean and correct
> code, they should've fixed all warnings in the first place and thus
> enabled all of them.
That wasn't how I read this:
> Also, consider that for -Werror to be "better", you also need -O3 in
order to activate the "proper" compiler checks like "variable set but
never used" ones.
But I'll accept that I misunderstood.
> In fact, I expect every sane upstream to use "-O3
> -Wall -Werror" in one of their automated builds. Not that this catches
> anything useful on x86{,_64} when there is for instance use of signed
> and unsigned char types, so it isn't conclusive.
>
> The whole point in here is that -Werror doesn't add much if you care.
> The whole point why it is not desired in Gentoo is that users don't
> necessarily are developers, or even interested in fixing warnings --
> regardless whether they point to real problems or not.
>
> If there are real problems in a package (exposed by a compiler or not)
> then this should ideally stand out during ~arch testing, or even before
> when the Gentoo maintainer examines the build (might even use -Werror
> for his own purposes). If such code ends up in stable arch we just made
> a stabilisation mistake, or got royally messed up by upstream, depending
> how you look at it.
>
> Fabian
>
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
On Fri, 2018-09-14 at 20:22 +0300, Alon Bar-Lev wrote:
> On Fri, Sep 14, 2018 at 8:16 PM Richard Yao wrote:
> >
> > On 09/14/2018 12:40 PM, Alon Bar-Lev wrote:
> > > On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich
> > > wrote:
> > > >
> > > > On Tue, 11 Sep 2018 12:44:38 +0300
> > > > Alon Bar-Lev wrote:
> > > >
> > > > I'm personally in favour of not allowing -Werror
> > > > to be in build system unconditionally.
> > > >
> > > > Maintainer is free to implement --enable-werror any way
> > > > it's convenient to run on their own extended sanity checks
> > > > and optionally expose it to users. Be it USE flag or
> > > > EXTRA_ECONF option.
> > >
> > > This discussion is not for downstream to have a more strict policy
> > > than upstream. People try to hijack discussion and introduce noise to
> > > de-focus the discussion.
> > >
> > > Downstream policy cannot be more strict than upstream as then every
> > > change upstream is doing downstream need to rebase and invest in even
> > > more changes.
> > >
> > > This discussion is to follow upstream strict policy if upstream proves
> > > that it stands behind it and downstream is willing to follow.
> >
> > I don't think we should do that unless we provide a USE flag for users
> > to opt into the behavior. Forcing it on users is problematic for the
> > reasons others stated. However, letting them opt into the behavior is
> > reasonable.
> >
> > In the case of sys-fs/zfs, enabling -Werror (which includes -Wall) on
> > USE=debug is following upstream's wishes to build debug builds with -Werror.
>
> Let's do this the other way around and be react based on facts and not
> speculations.
> Let's change the policy for a year for selected packages as I
> outlined, monitor bugs and after a year see response times, affected
> users and if downstream patches are accumulated. Then we can decide if
> we need to patch upstream packages.
> If we need to patch upstream package anyway, not follow upstream
> policy and not accepting input for various of permutations and
> architecture from all users, this discussion is nearly void.
>
...and for how long did you exactly ignore the standing policy that
suddenly we need a new testing period? How about we do the opposite
and you prove a *single* bug found downstream using this method so far?
Because so far this discussion is not much different than "let's make
the ebuild fail for some values of ${RANDOM}, and add extra values when
users complain". Though the variant with random has probably a greater
chance of failing when *actual* security issues happen.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Changing policy about -Werror
On Fri, Sep 14, 2018 at 1:22 PM Alon Bar-Lev wrote: > > Let's do this the other way around and be react based on facts and not > speculations. > Let's change the policy for a year for selected packages as I > outlined, monitor bugs and after a year see response times, affected > users and if downstream patches are accumulated. Then we can decide if > we need to patch upstream packages. Obviously up to QA/Council, but I think this sounds like a practical approach. No need to "change the policy" so much as approve a temporary exception, perhaps for a defined period of time. -- Rich
Re: [gentoo-dev] Changing policy about -Werror
On Fri, Sep 14, 2018 at 8:16 PM Richard Yao wrote: > > On 09/14/2018 12:40 PM, Alon Bar-Lev wrote: > > On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich > > wrote: > >> > >> On Tue, 11 Sep 2018 12:44:38 +0300 > >> Alon Bar-Lev wrote: > >> > >> I'm personally in favour of not allowing -Werror > >> to be in build system unconditionally. > >> > >> Maintainer is free to implement --enable-werror any way > >> it's convenient to run on their own extended sanity checks > >> and optionally expose it to users. Be it USE flag or > >> EXTRA_ECONF option. > > > > This discussion is not for downstream to have a more strict policy > > than upstream. People try to hijack discussion and introduce noise to > > de-focus the discussion. > > > > Downstream policy cannot be more strict than upstream as then every > > change upstream is doing downstream need to rebase and invest in even > > more changes. > > > > This discussion is to follow upstream strict policy if upstream proves > > that it stands behind it and downstream is willing to follow. > I don't think we should do that unless we provide a USE flag for users > to opt into the behavior. Forcing it on users is problematic for the > reasons others stated. However, letting them opt into the behavior is > reasonable. > > In the case of sys-fs/zfs, enabling -Werror (which includes -Wall) on > USE=debug is following upstream's wishes to build debug builds with -Werror. Let's do this the other way around and be react based on facts and not speculations. Let's change the policy for a year for selected packages as I outlined, monitor bugs and after a year see response times, affected users and if downstream patches are accumulated. Then we can decide if we need to patch upstream packages. If we need to patch upstream package anyway, not follow upstream policy and not accepting input for various of permutations and architecture from all users, this discussion is nearly void.
Re: [gentoo-dev] Changing policy about -Werror
On 09/14/2018 12:40 PM, Alon Bar-Lev wrote: > On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich wrote: >> >> On Tue, 11 Sep 2018 12:44:38 +0300 >> Alon Bar-Lev wrote: >> >> I'm personally in favour of not allowing -Werror >> to be in build system unconditionally. >> >> Maintainer is free to implement --enable-werror any way >> it's convenient to run on their own extended sanity checks >> and optionally expose it to users. Be it USE flag or >> EXTRA_ECONF option. > > This discussion is not for downstream to have a more strict policy > than upstream. People try to hijack discussion and introduce noise to > de-focus the discussion. > > Downstream policy cannot be more strict than upstream as then every > change upstream is doing downstream need to rebase and invest in even > more changes. > > This discussion is to follow upstream strict policy if upstream proves > that it stands behind it and downstream is willing to follow. I don't think we should do that unless we provide a USE flag for users to opt into the behavior. Forcing it on users is problematic for the reasons others stated. However, letting them opt into the behavior is reasonable. In the case of sys-fs/zfs, enabling -Werror (which includes -Wall) on USE=debug is following upstream's wishes to build debug builds with -Werror. > > For your question: No. Downstream should not add -Werror to upstream > package, not in a parameter or USE flag, as this will probably break > and cause a queue of downstream patches. > >>> I would like to suggest a modify our policy with the following >>> exception clause: Package maintainer may decide to keep upstream >>> -Werror as long as he is willing to resolve all issues resulting from >>> -Werror as if it was a blocker bug. >> >> Do you intend to keep -Werror for case when ebuild goes >> stable as well? > > Correct. > >> If you do it then what is your workflow to fix breakages >> appearing in stable packages caused by minor environment >> changes like toolchain tweaks? > > Correct. > >> Add another round of stabilization on each arch team? It >> sounds like your default assumption that code needs to be >> changed in a semantically significant way: add annotations >> that might not like some toolchains, remove unused code. > > No dependency of toolchain nor annotations. > A strict policy of no warnings will require changes as dependencies > including toolchain are progressing. > This creates an overhead for selected packages. > A maintainer and the non-stable team should be able to know the package > status. > Preferably this may be done by automation, I appreciate the work of > Toralf Förster with tinderbox to automate check various cases. > When a new slot of toolchain is available, maintainers should check > their packages in any case, there are other issues and side affects > that we experienced, especially in C++ packages. > For these packages usually there are 3 for each slot: the current > stable, the next stable and the non-stable, so the overhead is > constrained. > >> Or patch package in-place without bumping? None of options >> sound optimal compared to dropping -Werror. > > Success of build is not the only concern although I see people here > that are interested only in that. > Patching upstream package and/or change upstream quality policy is > something that we should avoid as well to maintain upstream warranty. > >>> The package maintainer decision may be based on the package state and >>> the relationship with upstream, but basically, it is his decision as >>> long as issues are fixed in timely manner, it is his overhead after >>> all. >> >> I agree that maintainer's will and upstream's will should be >> respected and it's not something needs to be absolutely >> enforced all the time. >> >> Personally I disagree -Werror on end-user machine is worth >> it (or cppcheck, or coverity round-trip run is worth running >> on user's machine unconditionally). >> >> Unused variable is a good example of typical benign warning: >> it was there all the time, it's not a new bug and does not >> warrant need for an immediate fix. > > Unused variable is a good example of CRITICAL potential issue, the bug > that triggered this this discussion has a return code that was not > used. The permutation was not tested by upstream as it rarely used, it > was not tested by me either by the same reason, both is a mistake. > Fortunately, someone else tested this permutation and his build > failed, triggered a bug. If -Werror has not been used we would not > have known about this issue. In many cases these happen in > architecture that maintainer nor upstream have access to. In this > specific case I went over the code history to the time the return code > have been used and determined that this indeed should be ignored, > imagine the opposite. A patch was submitted to upstream to confirm > resolution as any issue in code, upstream confirmed and merged this in > timely fashion. Bottom line we all (Gentoo,
[gentoo-dev] Changing policy about -Werror
> On Sep 13, 2018, at 8:54 PM, Georg Rudoy <0xd34df...@gmail.com> wrote:
>
>> On 14.09.2018 at 0:44 user Richard Yao wrote:
>> This is a really odd design decision by the GCC developers. With other
>> compilers, the separation between front end and backend is strong enough
>> that you will never have this sort of thing. It does not seem necessary to
>> me either. :/
I didn't want to get into this, but GCC's backend is actually split into
a middle-end, that does architecture independent optimizations and a
backend, that generates assembly code (and likely does architecture
specific optimization):
https://en.wikibooks.org/wiki/GNU_C_Compiler_Internals/GNU_C_Compiler_Architecture
You can get it to dump what appears to be the input to the middle end by
doing -fdump-translation-unit. You can get GCC to dump each stage of the
middle end using -fdump-tree-all. Presumably, any warnings that depend
on optimization won't be generated, although someone would need to study
the code to verify that.
I suspect quite a few people talking about what -Werror -Wall does have
never actually touched the internals of a compiler and perhaps that
should change. I won't claim to be an expert, but I have minor
experience with front-end development, writing code to do error
generation, etcetera. Honestly, when I first looked at GCC's sources, I
decided that I would be happier never looking at them ever again, but I
am starting to reconsider that decision.
>
> You might be able to perform certain additional data/control flow analysis
> after things like inlining, dead code removal or devirtualization.
Do you have any examples? I am having some trouble making a test case
that shows a different in behavior at different optimization levels
either way.
Here is an example:
__attribute__((always_inline))
static inline int
test(int x) {
return x;
}
int main() {
int x;
return (test(x)*0);
}
GCC 7.3.0 will emit a warning regardless of optimization level provided
that -Wall is passed. However, it will not emit a warning for this at
any optimization level:
int main() {
int x;
return (x*0);
}
>
> Moving that logic to the frontend would require essentially duplicating
> what's the optimizer's gonna do anyway, which might have negative effects on
> compilation times (both with and without optimizations) and compiler code
> maintenance.
If it is easier to use the optimizer's infrastructure to figure this
out, then the code could be written to call it to do analysis as a
pseudo-optimization pass, which GCC actually appears to do when it runs
its "Function test" "optimization" pass. There is no code maintenance
burden.
Fabian was right about needing -Wall for -Werror to catch many things
because most warnings are off by default. However, I am extremely
skeptical that the optimization level has significant error. -Wall gives
us whatever we need and so far, I cannot find a code example showing
differences in warning generation at different optimization levels. I'll
accept the idea that the warning quality might change (although I don't
fully understand the reasoning for it) by the GCC documentation.
However, I find the idea that -O3 will make a warning appear that didn't
otherwise appear to be very difficult to accept. The documentation
claims that optimization passes can effect emission of warnings for
uninitialized variables, but the only way that I could imagine that
happening would be if an optimization pass made x*0 into 0 before the
code generating the warning is run. This is the complete opposite of
what is being claimed here. In some actual tests, I am unable to get GCC
to emit a warning for that at any optimization level. I am also unable
to get it to behave differently for uninitialized variables at different
optimization levels no matter what idea I try.
>
>
>
> --
> Georg Rudoy
>
>
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich wrote: > > On Tue, 11 Sep 2018 12:44:38 +0300 > Alon Bar-Lev wrote: > > I'm personally in favour of not allowing -Werror > to be in build system unconditionally. > > Maintainer is free to implement --enable-werror any way > it's convenient to run on their own extended sanity checks > and optionally expose it to users. Be it USE flag or > EXTRA_ECONF option. This discussion is not for downstream to have a more strict policy than upstream. People try to hijack discussion and introduce noise to de-focus the discussion. Downstream policy cannot be more strict than upstream as then every change upstream is doing downstream need to rebase and invest in even more changes. This discussion is to follow upstream strict policy if upstream proves that it stands behind it and downstream is willing to follow. For your question: No. Downstream should not add -Werror to upstream package, not in a parameter or USE flag, as this will probably break and cause a queue of downstream patches. > > I would like to suggest a modify our policy with the following > > exception clause: Package maintainer may decide to keep upstream > > -Werror as long as he is willing to resolve all issues resulting from > > -Werror as if it was a blocker bug. > > Do you intend to keep -Werror for case when ebuild goes > stable as well? Correct. > If you do it then what is your workflow to fix breakages > appearing in stable packages caused by minor environment > changes like toolchain tweaks? Correct. > Add another round of stabilization on each arch team? It > sounds like your default assumption that code needs to be > changed in a semantically significant way: add annotations > that might not like some toolchains, remove unused code. No dependency of toolchain nor annotations. A strict policy of no warnings will require changes as dependencies including toolchain are progressing. This creates an overhead for selected packages. A maintainer and the non-stable team should be able to know the package status. Preferably this may be done by automation, I appreciate the work of Toralf Förster with tinderbox to automate check various cases. When a new slot of toolchain is available, maintainers should check their packages in any case, there are other issues and side affects that we experienced, especially in C++ packages. For these packages usually there are 3 for each slot: the current stable, the next stable and the non-stable, so the overhead is constrained. > Or patch package in-place without bumping? None of options > sound optimal compared to dropping -Werror. Success of build is not the only concern although I see people here that are interested only in that. Patching upstream package and/or change upstream quality policy is something that we should avoid as well to maintain upstream warranty. > > The package maintainer decision may be based on the package state and > > the relationship with upstream, but basically, it is his decision as > > long as issues are fixed in timely manner, it is his overhead after > > all. > > I agree that maintainer's will and upstream's will should be > respected and it's not something needs to be absolutely > enforced all the time. > > Personally I disagree -Werror on end-user machine is worth > it (or cppcheck, or coverity round-trip run is worth running > on user's machine unconditionally). > > Unused variable is a good example of typical benign warning: > it was there all the time, it's not a new bug and does not > warrant need for an immediate fix. Unused variable is a good example of CRITICAL potential issue, the bug that triggered this this discussion has a return code that was not used. The permutation was not tested by upstream as it rarely used, it was not tested by me either by the same reason, both is a mistake. Fortunately, someone else tested this permutation and his build failed, triggered a bug. If -Werror has not been used we would not have known about this issue. In many cases these happen in architecture that maintainer nor upstream have access to. In this specific case I went over the code history to the time the return code have been used and determined that this indeed should be ignored, imagine the opposite. A patch was submitted to upstream to confirm resolution as any issue in code, upstream confirmed and merged this in timely fashion. Bottom line we all (Gentoo, upstream and any other distribution) enjoy better quality. > Toolchain just happend to get better at control flow graph > analysis. Fix can easily wait for next release and save > everyone's time. Once again, the number of permutation of build and architecture may reveal issues that are cannot be detected on maintainer machine. If a fix is a real issue that is found in stable package, do you suggest to wait for next release to save whose time? > Not every user is willing to create bugzilla account and figure > the path of reporting the breakage. Especially if
Re: [gentoo-dev] Changing policy about -Werror
> On Sep 13, 2018, at 11:35 PM, Matt Turner wrote: > > On Thu, Sep 13, 2018 at 5:44 PM Richard Yao wrote: >>> On Sep 13, 2018, at 7:21 PM, Matt Turner wrote: >>> >>> On Thu, Sep 13, 2018 at 4:13 PM Richard Yao wrote: > On Sep 13, 2018, at 12:03 PM, Fabian Groffen wrote: > >> On 13-09-2018 07:36:09 -0400, Richard Yao wrote: >> >> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann wrote: On 2018-09-12 16:50, Rich Freeman wrote: There is also the case where we want these warnings to block installation, because the risk of there being a problem is too great. >>> >>> I really disagree with that. So many devs have already said multiple >>> times in this thread that "-Werror" is only turning existing warnings >>> into fatal errors but "-Werror" itself doesn't add any new checks and >>> more often requires "-O3" to be useful. >> The way that compilers work is that the warnings are generated in the >> front end while the optimization level affects the backend. That means >> that -O3 has no effect on the code that does error generation. This >> remark about -O3 being needed to make -Werror useful is just plain wrong. > > Huh? -O3 enables more checks, which can generate more warnings. What checks are those? -O3 affects backend optimization while warnings are generated by the front end. Once the immediate representation is generated, there are no other warnings aside from those from the linker. >>> >>> https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html >>> >>> Search for "depend on" >>> >>> -> [...] estimated based on heuristics that depend on thelevel >>> argument and on optimization >>> >>> -> Because these warnings depend on optimization [...] >>> >>> Yes, warnings are dependent on optimization level. >> >> There are three such options. The first two are for format statements: >> >>> “When the exact number of bytes written by a format directive cannot be >>> determined at compile-time it is estimated based on heuristics that depend >>> on the level argument and on optimization. While enabling optimization will >>> in most cases improve the accuracy of the warning, it may also result in >>> false positives. “ >> >> My read of this is that the warning occurs regardless of optimization level, >> but it could somehow be improved by optimization. >> >> As for the last, it is for uninitialized variable reads. However, I think >> you are misinterpreting the claim. The way that optimization level could >> affect warning generation would be if the warning generation came after >> optimization passes that could hide reads. That means that -O3 would prevent >> the warning. >> >> This is a really odd design decision by the GCC developers. With other >> compilers, the separation between front end and backend is strong enough >> that you will never have this sort of thing. It does not seem necessary to >> me either. :/ > > I'm sorry, but you really don't know what you're talking about. Either provide code examples that generate warnings in a way that demonstrates that I am incorrect or withdraw that ad hominem. > I've > already told you once that you were just adding noise to this > conversation. I can understand the remarks about USE=debug being considered noise given that people seem to think that -Werror is a boolean thing where it is either on for any combination of USE flags or off for any combination of USE flags. However, discussing how compiler internals impacts how -Werror works is definitely not noise. You cannot have a discussion about how -Werror should be handled without understanding what I actually does.
Re: [gentoo-dev] Changing policy about -Werror
On Thu, Sep 13, 2018 at 5:44 PM Richard Yao wrote: > > On Sep 13, 2018, at 7:21 PM, Matt Turner wrote: > > > > On Thu, Sep 13, 2018 at 4:13 PM Richard Yao wrote: > >>> On Sep 13, 2018, at 12:03 PM, Fabian Groffen wrote: > >>> > On 13-09-2018 07:36:09 -0400, Richard Yao wrote: > > > >> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann > >> wrote: > >> > >> On 2018-09-12 16:50, Rich Freeman wrote: > >> There is also the case where we want these warnings to block > >> installation, because the risk of there being a problem is too great. > > > > I really disagree with that. So many devs have already said multiple > > times in this thread that "-Werror" is only turning existing warnings > > into fatal errors but "-Werror" itself doesn't add any new checks and > > more often requires "-O3" to be useful. > The way that compilers work is that the warnings are generated in the > front end while the optimization level affects the backend. That means > that -O3 has no effect on the code that does error generation. This > remark about -O3 being needed to make -Werror useful is just plain wrong. > >>> > >>> Huh? -O3 enables more checks, which can generate more warnings. > >> > >> What checks are those? -O3 affects backend optimization while warnings are > >> generated by the front end. Once the immediate representation is > >> generated, there are no other warnings aside from those from the linker. > > > > https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html > > > > Search for "depend on" > > > > -> [...] estimated based on heuristics that depend on thelevel > > argument and on optimization > > > > -> Because these warnings depend on optimization [...] > > > > Yes, warnings are dependent on optimization level. > > There are three such options. The first two are for format statements: > > > “When the exact number of bytes written by a format directive cannot be > > determined at compile-time it is estimated based on heuristics that depend > > on the level argument and on optimization. While enabling optimization will > > in most cases improve the accuracy of the warning, it may also result in > > false positives. “ > > My read of this is that the warning occurs regardless of optimization level, > but it could somehow be improved by optimization. > > As for the last, it is for uninitialized variable reads. However, I think you > are misinterpreting the claim. The way that optimization level could affect > warning generation would be if the warning generation came after optimization > passes that could hide reads. That means that -O3 would prevent the warning. > > This is a really odd design decision by the GCC developers. With other > compilers, the separation between front end and backend is strong enough that > you will never have this sort of thing. It does not seem necessary to me > either. :/ I'm sorry, but you really don't know what you're talking about. I've already told you once that you were just adding noise to this conversation.
Re: [gentoo-dev] Changing policy about -Werror
On 14.09.2018 at 0:44 user Richard Yao wrote: > This is a really odd design decision by the GCC developers. With other > compilers, the separation between front end and backend is strong enough that > you will never have this sort of thing. It does not seem necessary to me > either. :/ You might be able to perform certain additional data/control flow analysis after things like inlining, dead code removal or devirtualization. Moving that logic to the frontend would require essentially duplicating what's the optimizer's gonna do anyway, which might have negative effects on compilation times (both with and without optimizations) and compiler code maintenance. BTW I'm not sure the separation on backend/frontend makes sense for modern C++ compilers. clang surely does some optimizations, and llvm (at least, in theory) is certainly able to find certain issues after more optimizer passes. -- Georg Rudoy
Re: [gentoo-dev] Changing policy about -Werror
> On Sep 13, 2018, at 7:21 PM, Matt Turner wrote: > > On Thu, Sep 13, 2018 at 4:13 PM Richard Yao wrote: >>> On Sep 13, 2018, at 12:03 PM, Fabian Groffen wrote: >>> On 13-09-2018 07:36:09 -0400, Richard Yao wrote: >> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann >> wrote: >> >> On 2018-09-12 16:50, Rich Freeman wrote: >> There is also the case where we want these warnings to block >> installation, because the risk of there being a problem is too great. > > I really disagree with that. So many devs have already said multiple > times in this thread that "-Werror" is only turning existing warnings > into fatal errors but "-Werror" itself doesn't add any new checks and > more often requires "-O3" to be useful. The way that compilers work is that the warnings are generated in the front end while the optimization level affects the backend. That means that -O3 has no effect on the code that does error generation. This remark about -O3 being needed to make -Werror useful is just plain wrong. >>> >>> Huh? -O3 enables more checks, which can generate more warnings. >> >> What checks are those? -O3 affects backend optimization while warnings are >> generated by the front end. Once the immediate representation is generated, >> there are no other warnings aside from those from the linker. > > https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html > > Search for "depend on" > > -> [...] estimated based on heuristics that depend on thelevel > argument and on optimization > > -> Because these warnings depend on optimization [...] > > Yes, warnings are dependent on optimization level. There are three such options. The first two are for format statements: > “When the exact number of bytes written by a format directive cannot be > determined at compile-time it is estimated based on heuristics that depend on > the level argument and on optimization. While enabling optimization will in > most cases improve the accuracy of the warning, it may also result in false > positives. “ My read of this is that the warning occurs regardless of optimization level, but it could somehow be improved by optimization. As for the last, it is for uninitialized variable reads. However, I think you are misinterpreting the claim. The way that optimization level could affect warning generation would be if the warning generation came after optimization passes that could hide reads. That means that -O3 would prevent the warning. This is a really odd design decision by the GCC developers. With other compilers, the separation between front end and backend is strong enough that you will never have this sort of thing. It does not seem necessary to me either. :/
Re: [gentoo-dev] Changing policy about -Werror
On 13.09.2018 at 16:20 user Fabian Groffen wrote: >> > To illustrate harmless: >> > warning: this statement may fall through [-Wimplicit-fallthrough=] >> > The warning message already has it in it that it's just a pure guess. >> >> One that exposed a lot of unintentional fallthoughs which were fixed >> when reporting to upstream. > > Sure that's why the warning is there. But you ignore the point that the > same code compiled fine and ran fine for years without problems. I have more than a few examples of my code compiling fine and running "fine" for years (so that no observable defects were visible), yet newly introduced warnings or static analyzer runs showed the defects that resolved actual bugs when fixed. And, ironically, that also includes the fallthrough warnings [1-3]. And cases of me stumbling upon some other legacy code, compiling it with a newer compiler and going "WTF how it even managed to produce anything meaningful at all?" are not uncommon. Just my two C++ents here. [1] https://github.com/0xd34df00d/leechcraft/commit/663b69249cd61d1cbd490a3eee7909ae26d03240 [2] https://github.com/0xd34df00d/leechcraft/commit/fa8ff9dc315e894fada4aaf73534bdfc15121cb3 [3] https://github.com/0xd34df00d/leechcraft/commit/6b26961b52b6e8277db39b084f483d1959253313 -- Georg Rudoy
Re: [gentoo-dev] Changing policy about -Werror
On Thu, Sep 13, 2018 at 4:13 PM Richard Yao wrote: > > On Sep 13, 2018, at 12:03 PM, Fabian Groffen wrote: > > > >> On 13-09-2018 07:36:09 -0400, Richard Yao wrote: > >> > >> > On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann > wrote: > > On 2018-09-12 16:50, Rich Freeman wrote: > There is also the case where we want these warnings to block > installation, because the risk of there being a problem is too great. > >>> > >>> I really disagree with that. So many devs have already said multiple > >>> times in this thread that "-Werror" is only turning existing warnings > >>> into fatal errors but "-Werror" itself doesn't add any new checks and > >>> more often requires "-O3" to be useful. > >> The way that compilers work is that the warnings are generated in the > >> front end while the optimization level affects the backend. That means > >> that -O3 has no effect on the code that does error generation. This remark > >> about -O3 being needed to make -Werror useful is just plain wrong. > > > > Huh? -O3 enables more checks, which can generate more warnings. > > What checks are those? -O3 affects backend optimization while warnings are > generated by the front end. Once the immediate representation is generated, > there are no other warnings aside from those from the linker. https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html Search for "depend on" -> [...] estimated based on heuristics that depend on thelevel argument and on optimization -> Because these warnings depend on optimization [...] Yes, warnings are dependent on optimization level.
Re: [gentoo-dev] Changing policy about -Werror
> On Sep 13, 2018, at 12:03 PM, Fabian Groffen wrote:
>
>> On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
>>
>>
On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann wrote:
On 2018-09-12 16:50, Rich Freeman wrote:
There is also the case where we want these warnings to block
installation, because the risk of there being a problem is too great.
>>>
>>> I really disagree with that. So many devs have already said multiple
>>> times in this thread that "-Werror" is only turning existing warnings
>>> into fatal errors but "-Werror" itself doesn't add any new checks and
>>> more often requires "-O3" to be useful.
>> The way that compilers work is that the warnings are generated in the front
>> end while the optimization level affects the backend. That means that -O3
>> has no effect on the code that does error generation. This remark about -O3
>> being needed to make -Werror useful is just plain wrong.
>
> Huh? -O3 enables more checks, which can generate more warnings.
What checks are those? -O3 affects backend optimization while warnings are
generated by the front end. Once the immediate representation is generated,
there are no other warnings aside from those from the linker.
> -O3
> isn't "needed", but if upstream is so interested in clean and correct
> code, they should've fixed all warnings in the first place and thus
> enabled all of them. In fact, I expect every sane upstream to use "-O3
> -Wall -Werror" in one of their automated builds. Not that this catches
> anything useful on x86{,_64} when there is for instance use of signed
> and unsigned char types, so it isn't conclusive.
>
> The whole point in here is that -Werror doesn't add much if you care.
> The whole point why it is not desired in Gentoo is that users don't
> necessarily are developers, or even interested in fixing warnings --
> regardless whether they point to real problems or not.
>
> If there are real problems in a package (exposed by a compiler or not)
> then this should ideally stand out during ~arch testing, or even before
> when the Gentoo maintainer examines the build (might even use -Werror
> for his own purposes). If such code ends up in stable arch we just made
> a stabilisation mistake, or got royally messed up by upstream, depending
> how you look at it.
>
> Fabian
>
> --
> Fabian Groffen
> Gentoo on a different level
Re: [gentoo-dev] Changing policy about -Werror
On Tue, 11 Sep 2018 12:44:38 +0300 Alon Bar-Lev wrote: I'm personally in favour of not allowing -Werror to be in build system unconditionally. Maintainer is free to implement --enable-werror any way it's convenient to run on their own extended sanity checks and optionally expose it to users. Be it USE flag or EXTRA_ECONF option. > I would like to suggest a modify our policy with the following > exception clause: Package maintainer may decide to keep upstream > -Werror as long as he is willing to resolve all issues resulting from > -Werror as if it was a blocker bug. Do you intend to keep -Werror for case when ebuild goes stable as well? If you do it then what is your workflow to fix breakages appearing in stable packages caused by minor environment changes like toolchain tweaks? Add another round of stabilization on each arch team? It sounds like your default assumption that code needs to be changed in a semantically significant way: add annotations that might not like some toolchains, remove unused code. Or patch package in-place without bumping? None of options sound optimal compared to dropping -Werror. > The package maintainer decision may be based on the package state and > the relationship with upstream, but basically, it is his decision as > long as issues are fixed in timely manner, it is his overhead after > all. I agree that maintainer's will and upstream's will should be respected and it's not something needs to be absolutely enforced all the time. Personally I disagree -Werror on end-user machine is worth it (or cppcheck, or coverity round-trip run is worth running on user's machine unconditionally). Unused variable is a good example of typical benign warning: it was there all the time, it's not a new bug and does not warrant need for an immediate fix. Toolchain just happend to get better at control flow graph analysis. Fix can easily wait for next release and save everyone's time. Not every user is willing to create bugzilla account and figure the path of reporting the breakage. Especially if there are many breakages like that. Getting multiple various errors is probable if one imagines -Werror to be commonly allowed. This is user's overhead. Not just maintainer's. Gentoo does not normally run tests on user's systems either. Tests are arguably a lot more precise in pointing out real problems in software. > ARGUMENT: If a package compiled in the past using toolchain X then it > must continue to do so with any future toolchain. > > I do not understand when "build" is the test for runtime The argument was about "keep compiling". Runtime behaviour is a separate issue and (in my opinion) is an orthogonal topic. On another note I occasionally like to build Gentoo with clang's -Weverything (or equivalent set of gcc CFLAGS) to get the idea if there is a good useful warning out there to put into -Werror= list. Explicit -Werror= list allows code not to regress. But even that is prone to harmless infelicities in libc headers that can't be easily fixed. In case of opensc it just does not compile even if I pass -Wno-error: $ CC=clang CFLAGS="-O2 -Weverything -Wno-error" emerge -v1 opensc I don't expect 'opensc' upstream to fix this use for me and don't see it worth reporting to bugzilla. But maybe I'm wrong? -- Sergei
Re: [gentoo-dev] Changing policy about -Werror
On Thu, Sep 13, 2018 at 7:20 PM Fabian Groffen wrote: > > > To illustrate harmless: > > > warning: this statement may fall through [-Wimplicit-fallthrough=] > > > The warning message already has it in it that it's just a pure guess. > > > > One that exposed a lot of unintentional fallthoughs which were fixed > > when reporting to upstream. > > Sure that's why the warning is there. But you ignore the point that the > same code compiled fine and ran fine for years without problems. The fact that something is compiling and running fine meaning there are no issues (bugs) within code? Seriously? Even after no-warning with multiple compiler vendors, code coverage, unit testing, test on various of architecture developer has access to, static code analysis and running for years, bugs are there. Any method to help detect suspicious code, even if it produces amount of false positive, must be embraced of those who care about quality. New toolchains, new scanners, new architectures all can help to improve quality to make sure great service is provided to users. In Gentoo language, all these issues should be detected for selected packages by non-stable users, on architecture and permutations that upstream do not have access to, and to help upstream to filter false positives and find the positives ones. Even one case of funding real issue is sufficient to justify the maintenance costs, once again for selected packages in which upstream following strict quality policy and downstream follows. Once policy is applied, the amount of noise is very little, toolchain evolution is not as it was 10 years ago. Regards, Alon
Re: [gentoo-dev] Changing policy about -Werror
On 13-09-2018 18:56:13 +0300, Alon Bar-Lev wrote: > On Thu, Sep 13, 2018 at 6:51 PM Fabian Groffen wrote: > > > > On 12-09-2018 17:46:03 -0700, Matt Turner wrote: > > > On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman wrote: > > > With new GCC comes new warnings, and harmless as the vast majority are > > > they cause the build to break with Werror. > > > > To illustrate harmless: > > warning: this statement may fall through [-Wimplicit-fallthrough=] > > The warning message already has it in it that it's just a pure guess. > > One that exposed a lot of unintentional fallthoughs which were fixed > when reporting to upstream. Sure that's why the warning is there. But you ignore the point that the same code compiled fine and ran fine for years without problems. > Once again... we should discuss to leave -Werror when policy of > upstream to have no warnings and is maintaining that policy properly > while we at downstream may cooperate and avoid patching upstream but > discuss issues when found. On a developer's system, that would be nice. For ordinary users on the other hand: Leaving -Werror is leaving our users alone in the dark. Don't do that. -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
On 12-09-2018 20:09:54 -0400, Rich Freeman wrote: > On Wed, Sep 12, 2018 at 7:32 PM Chí-Thanh Christopher Nguyễn > wrote: > > > > Alon Bar-Lev schrieb: > > > We > > > are unique as permutations and architectures that are used by Gentoo > > > users are so diverse that we find issues that nobody else finds. > > > > This needs to be highlighted more, as it is why suggestions that the > > maintainer can simply put -Werror back on their own system are insufficient. > > > > Wouldn't running into new runtime issues be exactly the sort of reason > why we'd want to build with -Werror on packages where these issues are > unacceptable? Can you think of a way in which a new runtime issue would occur that -Werror would have guarded? And that issue would also get through maintainer and ~arch testing? Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
>
>
> > On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann wrote:
> >
> >> On 2018-09-12 16:50, Rich Freeman wrote:
> >> There is also the case where we want these warnings to block
> >> installation, because the risk of there being a problem is too great.
> >
> > I really disagree with that. So many devs have already said multiple
> > times in this thread that "-Werror" is only turning existing warnings
> > into fatal errors but "-Werror" itself doesn't add any new checks and
> > more often requires "-O3" to be useful.
> The way that compilers work is that the warnings are generated in the front
> end while the optimization level affects the backend. That means that -O3 has
> no effect on the code that does error generation. This remark about -O3 being
> needed to make -Werror useful is just plain wrong.
Huh? -O3 enables more checks, which can generate more warnings. -O3
isn't "needed", but if upstream is so interested in clean and correct
code, they should've fixed all warnings in the first place and thus
enabled all of them. In fact, I expect every sane upstream to use "-O3
-Wall -Werror" in one of their automated builds. Not that this catches
anything useful on x86{,_64} when there is for instance use of signed
and unsigned char types, so it isn't conclusive.
The whole point in here is that -Werror doesn't add much if you care.
The whole point why it is not desired in Gentoo is that users don't
necessarily are developers, or even interested in fixing warnings --
regardless whether they point to real problems or not.
If there are real problems in a package (exposed by a compiler or not)
then this should ideally stand out during ~arch testing, or even before
when the Gentoo maintainer examines the build (might even use -Werror
for his own purposes). If such code ends up in stable arch we just made
a stabilisation mistake, or got royally messed up by upstream, depending
how you look at it.
Fabian
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
On Thu, Sep 13, 2018 at 6:51 PM Fabian Groffen wrote: > > On 12-09-2018 17:46:03 -0700, Matt Turner wrote: > > On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman wrote: > > With new GCC comes new warnings, and harmless as the vast majority are > > they cause the build to break with Werror. > > To illustrate harmless: > warning: this statement may fall through [-Wimplicit-fallthrough=] > The warning message already has it in it that it's just a pure guess. One that exposed a lot of unintentional fallthoughs which were fixed when reporting to upstream. Once again... we should discuss to leave -Werror when policy of upstream to have no warnings and is maintaining that policy properly while we at downstream may cooperate and avoid patching upstream but discuss issues when found.
Re: [gentoo-dev] Changing policy about -Werror
On 12-09-2018 17:46:03 -0700, Matt Turner wrote: > On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman wrote: > > > > On Wed, Sep 12, 2018 at 7:52 PM Matt Turner wrote: > > > > > > On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman wrote: > > > > Now, I could buy that -Werror turns NEW warnings into fatal errors, > > > > due to the use of a newer toolchain, since upstream probably didn't > > > > test with that toolchain and thus wouldn't have seen the warning. > > > > > > Yes, exactly. This is one of the major things people have said repeatedly. > > > > > > Werror makes moving gcc forward much more difficult. > > > > > > > Sure, but wouldn't a block on newer versions of gcc cause similar headaches? > > Sure...? Who is suggesting that? I'm not sure where you're going with this. > > With new GCC comes new warnings, and harmless as the vast majority are > they cause the build to break with Werror. To illustrate harmless: warning: this statement may fall through [-Wimplicit-fallthrough=] The warning message already has it in it that it's just a pure guess. -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
On 13-09-2018 00:55:45 +0200, Thomas Deutschmann wrote: > Unless you can do that we don't really need to discuss this. Simply > because everyone interested in "-Werror" *can* set that flag via CFLAGS, > even just per package, whereas the majority, not interested in this, > cannot do the same to filter "-Werror". Nobody advocating for "-Werror" > replied to that fact yet. Unfortunately adding -Werror to CFLAGS is not just possible. Many configure checks rely on the compiler just generating something, ignoring warnings for various reasons. If you add -Werror to your CFLAGS you basically introduce breakage for some autoconf-based packages. What we really should be having is an easy way for post-configure CFLAGS addition. Just to support devs/users who insist on this for their setups. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
> On Thu, 13 Sep 2018, Mike wrote: > On 9/13/18 9:35 AM, Rich Freeman wrote: >> What regulation? No action was taken. >> >> We can't exactly stop people from asking governance bodies to do >> things. At most we can say no when they ask. >> >> Unless we want to make people ask if they can ask. Now, that would >> be regulation... :) > It was an attempt at a compliment of us working together. It just didn't come across like that (at least not to me). Never mind then. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
On 9/13/18 9:35 AM, Rich Freeman wrote: > On Thu, Sep 13, 2018 at 9:29 AM Mike wrote: >> >> And I apologize for writing that commit rights were requested to be >> removed. My mistake, bugzilla access rights were asked to be removed. >> ... >> >> I'm not a fan of more and more and more regulation that I see. Sorry if >> you don't like that opinion. >> > > What regulation? No action was taken. > > We can't exactly stop people from asking governance bodies to do > things. At most we can say no when they ask. > > Unless we want to make people ask if they can ask. Now, that would be > regulation... :) > It was an attempt at a compliment of us working together. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
On Thu, Sep 13, 2018 at 9:29 AM Mike wrote: > > And I apologize for writing that commit rights were requested to be > removed. My mistake, bugzilla access rights were asked to be removed. >... > > I'm not a fan of more and more and more regulation that I see. Sorry if > you don't like that opinion. > What regulation? No action was taken. We can't exactly stop people from asking governance bodies to do things. At most we can say no when they ask. Unless we want to make people ask if they can ask. Now, that would be regulation... :) -- Rich
Re: [gentoo-dev] Changing policy about -Werror
On 9/13/18 7:25 AM, Ulrich Mueller wrote: >> On Wed, 12 Sep 2018, Mike wrote: > >> Picking random email. > >> I would like to say I'm glad we can discuss our technical differences >> like this with both sides expressing their opinion and reasoning. > >> I would hope in the future we start with this path and not with >> disciplinary action or bugs requesting the removal of commit access. > >> We're showing here we can bring up our points without handing out "QA >> strikes" or some other type of confrontational action. > > Sorry, but I am tired of that antagonising of the QA team. > > There hasn't been any bug about commit access removal. And not sure what > you mean with "QA strike", but there also wasn't any direct QA action on > the package that triggered the current discussion. After being CCed to a > bug, the QA team has merely pointed out to the maintainer that the > package is not in agreement with the current policy (as it is defined in > the devmanual). > > IMHO this is the QA team's purpose. Or what would you expect us to do > instead? Remain silent if asked by another developer to evaluate an > issue? Then we could as well disband QA. > > Also note that there are several remedies if there is disagreement > between a maintainer and QA, like asking QA for an exception, appealing > to the council, or changing the policy in question. > > Ulrich > I'm sorry you feel I am antagonizing QA. I've never had a problem with QA, personally. And I apologize for writing that commit rights were requested to be removed. My mistake, bugzilla access rights were asked to be removed. I actually thought I was complimenting our process. Seeing people discuss their technical differences. I'm not a fan of more and more and more regulation that I see. Sorry if you don't like that opinion. And by "QA strike", I am referring to the policy that was posted and then rescinded. But, this is all off-topic of this thread. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann wrote: > >> On 2018-09-12 16:50, Rich Freeman wrote: >> There is also the case where we want these warnings to block >> installation, because the risk of there being a problem is too great. > > I really disagree with that. So many devs have already said multiple > times in this thread that "-Werror" is only turning existing warnings > into fatal errors but "-Werror" itself doesn't add any new checks and > more often requires "-O3" to be useful. The way that compilers work is that the warnings are generated in the front end while the optimization level affects the backend. That means that -O3 has no effect on the code that does error generation. This remark about -O3 being needed to make -Werror useful is just plain wrong. > So let's turn this around: Please show us a *real* case within Gentoo > where "-Werror" prevented a real problem which wouldn't otherwise being > noticed. E.g. show us a package which was merged on user's system, > replacing a working previous version of that package causing *real* > problems which could have been prevented if package would have set > "-Werror". > > Unless you can do that we don't really need to discuss this. Simply > because everyone interested in "-Werror" *can* set that flag via CFLAGS, > even just per package, whereas the majority, not interested in this, > cannot do the same to filter "-Werror". Nobody advocating for "-Werror" > replied to that fact yet. > > > -- > Regards, > Thomas Deutschmann / Gentoo Linux Developer > C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 >
Re: [gentoo-dev] Changing policy about -Werror
> On Wed, 12 Sep 2018, Mike wrote: > Picking random email. > I would like to say I'm glad we can discuss our technical differences > like this with both sides expressing their opinion and reasoning. > I would hope in the future we start with this path and not with > disciplinary action or bugs requesting the removal of commit access. > We're showing here we can bring up our points without handing out "QA > strikes" or some other type of confrontational action. Sorry, but I am tired of that antagonising of the QA team. There hasn't been any bug about commit access removal. And not sure what you mean with "QA strike", but there also wasn't any direct QA action on the package that triggered the current discussion. After being CCed to a bug, the QA team has merely pointed out to the maintainer that the package is not in agreement with the current policy (as it is defined in the devmanual). IMHO this is the QA team's purpose. Or what would you expect us to do instead? Remain silent if asked by another developer to evaluate an issue? Then we could as well disband QA. Also note that there are several remedies if there is disagreement between a maintainer and QA, like asking QA for an exception, appealing to the council, or changing the policy in question. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman wrote: > > On Wed, Sep 12, 2018 at 7:52 PM Matt Turner wrote: > > > > On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman wrote: > > > Now, I could buy that -Werror turns NEW warnings into fatal errors, > > > due to the use of a newer toolchain, since upstream probably didn't > > > test with that toolchain and thus wouldn't have seen the warning. > > > > Yes, exactly. This is one of the major things people have said repeatedly. > > > > Werror makes moving gcc forward much more difficult. > > > > Sure, but wouldn't a block on newer versions of gcc cause similar headaches? Sure...? Who is suggesting that? I'm not sure where you're going with this. With new GCC comes new warnings, and harmless as the vast majority are they cause the build to break with Werror.
Re: [gentoo-dev] Changing policy about -Werror
On Wed, Sep 12, 2018 at 7:52 PM Matt Turner wrote: > > On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman wrote: > > Now, I could buy that -Werror turns NEW warnings into fatal errors, > > due to the use of a newer toolchain, since upstream probably didn't > > test with that toolchain and thus wouldn't have seen the warning. > > Yes, exactly. This is one of the major things people have said repeatedly. > > Werror makes moving gcc forward much more difficult. > Sure, but wouldn't a block on newer versions of gcc cause similar headaches? -- Rich
Re: [gentoo-dev] Changing policy about -Werror
On Wed, Sep 12, 2018 at 7:32 PM Chí-Thanh Christopher Nguyễn wrote: > > Alon Bar-Lev schrieb: > > We > > are unique as permutations and architectures that are used by Gentoo > > users are so diverse that we find issues that nobody else finds. > > This needs to be highlighted more, as it is why suggestions that the > maintainer can simply put -Werror back on their own system are insufficient. > Wouldn't running into new runtime issues be exactly the sort of reason why we'd want to build with -Werror on packages where these issues are unacceptable? -- Rich
Re: [gentoo-dev] Changing policy about -Werror
On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman wrote: > Now, I could buy that -Werror turns NEW warnings into fatal errors, > due to the use of a newer toolchain, since upstream probably didn't > test with that toolchain and thus wouldn't have seen the warning. Yes, exactly. This is one of the major things people have said repeatedly. Werror makes moving gcc forward much more difficult.
Re: [gentoo-dev] Changing policy about -Werror
Thomas Deutschmann schrieb: So let's turn this around: Please show us a *real* case within Gentoo where "-Werror" prevented a real problem which wouldn't otherwise being noticed. E.g. show us a package which was merged on user's system, replacing a working previous version of that package causing *real* problems which could have been prevented if package would have set "-Werror". I think your request will be difficult to meet, precisely due to the strict policy against -Werror which means that it is already long gone from most packages which originally had it. From x11 packages (they used to be one of the major remaining -Werror packages, cf. bug #416069) I recall a few cases where broken stuff on user systems triggered -Werror build failures. But this was mostly people who installed something to /usr/local and forgot about it. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing policy about -Werror
Alon Bar-Lev schrieb: We are unique as permutations and architectures that are used by Gentoo users are so diverse that we find issues that nobody else finds. This needs to be highlighted more, as it is why suggestions that the maintainer can simply put -Werror back on their own system are insufficient. One should only be thankful for any tool to detect issues hidden within code, stop and re-evaluate when new issues are found. +1 Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing policy about -Werror
On Wed, Sep 12, 2018 at 6:55 PM Thomas Deutschmann wrote: > > On 2018-09-12 16:50, Rich Freeman wrote: > > There is also the case where we want these warnings to block > > installation, because the risk of there being a problem is too great. > > I really disagree with that. So many devs have already said multiple > times in this thread that "-Werror" is only turning existing warnings > into fatal errors but "-Werror" itself doesn't add any new checks and > more often requires "-O3" to be useful. > This seems unlikely. If upstream is using -Werror in their build system, then they'd be getting build errors if these warnings already existed at the time they released the version. Now, I could buy that -Werror turns NEW warnings into fatal errors, due to the use of a newer toolchain, since upstream probably didn't test with that toolchain and thus wouldn't have seen the warning. If the warning only appears with -O3, and the package isn't built with -O3, then -Werror is a no-op and is harmless. But, I think there is somewhat of a legitimate point in pointing out that -Werror is in some sense just a proxy for detecting when a toolchain is being used which wasn't tested by upstream. You could accomplish the same by sticking a ton of toolchain blockers in the package. Of course, I can't imagine the toolchain team would be terribly happy about that, but if you want to avoid using newer toolchains with older versions of a package that would probably the the appropriate way to do it. -- Rich
Re: [gentoo-dev] Changing policy about -Werror
On 2018-09-12 16:50, Rich Freeman wrote: > There is also the case where we want these warnings to block > installation, because the risk of there being a problem is too great. I really disagree with that. So many devs have already said multiple times in this thread that "-Werror" is only turning existing warnings into fatal errors but "-Werror" itself doesn't add any new checks and more often requires "-O3" to be useful. So let's turn this around: Please show us a *real* case within Gentoo where "-Werror" prevented a real problem which wouldn't otherwise being noticed. E.g. show us a package which was merged on user's system, replacing a working previous version of that package causing *real* problems which could have been prevented if package would have set "-Werror". Unless you can do that we don't really need to discuss this. Simply because everyone interested in "-Werror" *can* set that flag via CFLAGS, even just per package, whereas the majority, not interested in this, cannot do the same to filter "-Werror". Nobody advocating for "-Werror" replied to that fact yet. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
On Sep 12, 2018, at 4:28 PM, Andreas K. Huettel wrote: >> If a package really ought to have >> -Werror due to a very good reason and is properly maintained to support it, >> then there is nothing wrong with inventing a USE flag to give users the >> option of enforcing that. > > There is something very *much* wrong with that. > > 1) It's trivial to enforce -Werror via the packages.env mechanism on specific > packages (e.g. those that you maintain). That really does not help the users see which packages explicitly support -Werror if they want it. > > 2) Compared to that, an additional useflag introduces a lot of unnecessary > overhead at the package manager level *and* requires yet another level of > policies and Gentoo-specific definitions. It occurs to me that this is really a debug feature, so it really ought to be turned on for USE=debug. Use of USE=debug in production is largely discouraged, so this could be fine. However, this is very much a case by case thing. > > -- > Andreas K. Hüttel > dilfri...@gentoo.org > Gentoo Linux developer > (council, toolchain, perl, libreoffice, comrel) > > >
Re: [gentoo-dev] Changing policy about -Werror
> If a package really ought to have > -Werror due to a very good reason and is properly maintained to support it, > then there is nothing wrong with inventing a USE flag to give users the > option of enforcing that. There is something very *much* wrong with that. 1) It's trivial to enforce -Werror via the packages.env mechanism on specific packages (e.g. those that you maintain). 2) Compared to that, an additional useflag introduces a lot of unnecessary overhead at the package manager level *and* requires yet another level of policies and Gentoo-specific definitions. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, perl, libreoffice, comrel)
Re: [gentoo-dev] Changing policy about -Werror
On 9/12/18 10:50 AM, Rich Freeman wrote: > On Wed, Sep 12, 2018 at 4:56 AM Jason Zaman wrote: >> >> Replying to a somewhat random post. There are two separate things here >> that people are discussing here but are not the same thing. > > Three, really... > >> >> 1) We want to know when a package has terrible warnings when installing >> it so we can report upstream and know that something might have gone >> wrong. > > There is also the case where we want these warnings to block > installation, because the risk of there being a problem is too great. > >> >> Stick this in your make.conf: >> PORTAGE_ELOG_SYSTEM="echo save" >> PORTAGE_ELOG_CLASSES="warn error log qa" >> I'm pretty sure toralf's tinderbox already has these enabled but all >> devs should too. > > The problem is that this will make the warnings non-fatal. > > Do we still tell users not to report these kinds of warnings in > bugzilla? If they're the sort we consider serious then we would want > to know about it so that we can address it, vs just waiting for > upstream to fix them in a future release. > > There might be a better solution than -Werror, such as a flag in an > ebuild that makes the existing QA warning fatal and tells the user to > log a bug. > Picking random email. I would like to say I'm glad we can discuss our technical differences like this with both sides expressing their opinion and reasoning. I would hope in the future we start with this path and not with disciplinary action or bugs requesting the removal of commit access. We're showing here we can bring up our points without handing out "QA strikes" or some other type of confrontational action. Mike signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
On Wed, Sep 12, 2018 at 4:56 AM Jason Zaman wrote: > > Replying to a somewhat random post. There are two separate things here > that people are discussing here but are not the same thing. Three, really... > > 1) We want to know when a package has terrible warnings when installing > it so we can report upstream and know that something might have gone > wrong. There is also the case where we want these warnings to block installation, because the risk of there being a problem is too great. > > Stick this in your make.conf: > PORTAGE_ELOG_SYSTEM="echo save" > PORTAGE_ELOG_CLASSES="warn error log qa" > I'm pretty sure toralf's tinderbox already has these enabled but all > devs should too. The problem is that this will make the warnings non-fatal. Do we still tell users not to report these kinds of warnings in bugzilla? If they're the sort we consider serious then we would want to know about it so that we can address it, vs just waiting for upstream to fix them in a future release. There might be a better solution than -Werror, such as a flag in an ebuild that makes the existing QA warning fatal and tells the user to log a bug. -- Rich
Re: [gentoo-dev] Changing policy about -Werror
On Mon, Sep 10, 2018 at 01:51:15PM -0700, Matt Turner wrote: > On Mon, Sep 10, 2018 at 1:34 PM Chí-Thanh Christopher Nguyễn > wrote: > > > > Jason Zaman schrieb: > > >> No. With -Werror, upstream indicates that if a warning occurs, the build > > >> should fail and the resulting code not be installed on user systems. > > >> > > >> Instead, someone knowledgeable should look at the situation *first* and > > >> determine whether it is a bogus warning, a trivial issue, or something > > >> which > > >> warrants further attention. > > >> > > >> I have long disagreed with QA policy on this, and think that ebuilds > > >> should > > >> respect upstream here. Of course giving users the ability to override. > > > > > > I disagree. -Werror means that upstream wants it to build without > > > warnings on their distro with their version of the compiler with their > > > versions of all the libraries. > > > > It means, upstream wants it to build without warnings everywhere. And if a > > warning occurs (due to change in compiler, libraries, architecture, etc.), > > have a developer look at it first before installing the code on user > > systems. > > This sounds good in theory, but I think it's pretty well established > that in practice this isn't effective and instead is a large waste of > time. In fact, the foundational premise that it's possible to build > without warnings everywhere is simply wrong. > > Consider again the bug that started this. The maintainer had not built > this configuration. None of the arch teams had built this > configuration until I did for the last architecture Cc'd. The patch > committed doesn't change anything installed on the system, if not for > Werror preventing the code from building. Replying to a somewhat random post. There are two separate things here that people are discussing here but are not the same thing. 1) We want to know when a package has terrible warnings when installing it so we can report upstream and know that something might have gone wrong. 2) There are a lot of spurious warnings that are worthless and would just annoy *everyone*. They are still legit warnings so its not like they should go away but they should not break the build. -Werror trips up on both of these which is why everyone dislikes it. We want to inform people about only 1) not 2). The solution to this is https://gitweb.gentoo.org/proj/portage.git/tree/bin/install-qa-check.d/90gcc-warnings (There is also an equivalent clang-warnings check too). These spit out "QA Notice: Package triggers severe warnings which indicate that it may exhibit random runtime failures." and a huge list of them. These are a focused list of the worst warnings that should be fixed first before all the others. If your goal is to improve the quality of code in general this qa-check is much better than using Werror on everything. Stick this in your make.conf: PORTAGE_ELOG_SYSTEM="echo save" PORTAGE_ELOG_CLASSES="warn error log qa" I'm pretty sure toralf's tinderbox already has these enabled but all devs should too. -- Jason
Re: [gentoo-dev] Changing policy about -Werror
Hi, I was the one that (re)trigger this discussion, I thank bircoph for opening this up. First, let me apologize that I did not test the capi USE for long time, as this option is not used for long time by users, I am also apologize of treating bug from anyone (may it be user, developer or even qa) at the same SLA. It took one hour from report to fix including evaluation of the issue and submitting the fix to upstream. The package is non-stable for four months and stable in amd64 for a while without users reporting that because as expected feature is seldom used. Please avoid flaming me for this and address the principal subject at hand as it is important. I would like to suggest a modify our policy with the following exception clause: Package maintainer may decide to keep upstream -Werror as long as he is willing to resolve all issues resulting from -Werror as if it was a blocker bug. The package maintainer decision may be based on the package state and the relationship with upstream, but basically, it is his decision as long as issues are fixed in timely manner, it is his overhead after all. I am maintaining selected packages in which upstream is fully aware of -Werror implications, accepting any patches to resolve issues found by anyone. My judgment as Gentoo developer for these selected packages is to absorb additional overhead in maintaining these packages while helping upstream and users to enjoy higher quality. I've never assumed that an effort individual project is willing to invest is something that overrule by any other project as long as users receives a great service (bugzilla stats are available). I believe that a maintainer in Gentoo is a special role, we not only helping users, but we also help upstream to improve their packages. We are unique as permutations and architectures that are used by Gentoo users are so diverse that we find issues that nobody else finds. In addition to these, we also use latest and greatest toolchains, tools and utilities, this triggers issues at Gentoo even before other distributions. Gentoo non-stable users are a great asset as they are willingly helping to find these issues, with the understanding that their system may break. A good relationship between Gentoo downstream maintainer and upstream actually helps to find fixes long before other distributions are affected. Even when I was in Red Hat, my policy was Gentoo first, as a package that is built in Gentoo without tweaks will be built successfully in all distributions (except of Java maven packages in which we are far behind). Over the years, many Gentoo developers, I included, have built relationship with most active upstreams in my slot to push Gentoo interests into upstream, I invite you to portage tree to see in how many packages we drag patches from one version to another or to evaluate ebuild tweaks. This mutual respect also suggests that if upstream has a -Werror policy, in which every issue as minor as it can be must be taken care of before package is considered to be usable, I as downstream maintainer should help and apply the policy to help upstream to improve its policy. More and more upstream developers are aware of static code analysis benefits, they use every source of information possible, opening coverity to opensource made a great difference, the -Werror is yet another tool to find unexpected issues. The collective mindset was progressed greatly since 2009 where flameeyes opened bug#260867. At least once per 10 years one should re-evaluate his policies, the industry is changing. When upstream policy is to have zero warnings policy, suppressed by explicit suppression (code or compile argument), and when upstream is friendly and actively following the policy of investigating each incident and fix it properly, we can help for selected packages. ARGUMENT: If a package compiled in the past using toolchain X then it must continue to do so with any future toolchain. I do not understand when "build" is the test for runtime, for 30 years I tell my developers and students that "It compiles" and "It works" are two different statements. One should only be thankful for any tool to detect issues hidden within code, stop and re-evaluate when new issues are found. Let's take two recent examples from my queue: bug#665464 in which there was unused return code variable, this made me look into source code of upstream from master back in time until code was introduced to find out when return code was used and why it was removed, reaching to a conclusion that indeed return code should be ignored and submitting a patch to upstream to validate that, upstream confirmed and merged. Imagine what would happen if I would have found that it is a real issue and should be addressed? Both users and upstream would have benefit from finding and fixing the issue. bug#664198 in which -Werror found mismatched memcpy, this was an actual bug that must be fixed. Based on the above we have in recent month one false
Re: [gentoo-dev] Changing policy about -Werror
> So, if maintainer has enough manpower to support this flag, we > should allow to keep it. No. [Unless maintainer also joins toolchain team and tests everything with every release candidate of the compiler.] You have no idea how much unneccessary pain -Werror caused when gcc started warning on "misleading indentation". Also, I do not see the connection between security and -Werror. No new warnings are created and a simple grep finds things. Finally, any maintainer can add this to his CFLAGS him/herself if s/he wishes so. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, perl, libreoffice, comrel)
Re: [gentoo-dev] Changing policy about -Werror
On 2018-09-10 23:04, Kristian Fiskerstrand wrote: > That it wasn't caught before being stabilized on several arches was > indeed bad, but that likely says more about our stabilization procedures > than the quality of the underlying package's upstream choices. Eh, this depends on architecture. Not a general failure. See x86 build.log, https://paste.pound-python.org/show/F1361Zp3aCHJLje8sBRe/ -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
On Mon, Sep 10, 2018 at 5:31 PM Rich Freeman wrote: > > On Mon, Sep 10, 2018 at 5:01 PM Mike Gilbert wrote: > > > > On Mon, Sep 10, 2018 at 4:56 PM Kristian Fiskerstrand > > wrote: > > > > > > On 9/10/18 10:51 PM, Matt Turner wrote: > > > > Consider again the bug that started this. The maintainer had not built > > > > this configuration. None of the arch teams had built this > > > > configuration until I did for the last architecture Cc'd. The patch > > > > committed doesn't change anything installed on the system, if not for > > > > Werror preventing the code from building. > > > > > > one way to look at it though, is that it is a valuable upstream > > > contribution that this configuration produces the error, so Gentoo is > > > contributing to upstream development because of it. > > > > As an end user of Gentoo, I may not care about "contributing to > > upstream"; I just want the software to compile and install. > > > > For more critical packages (like the example of zfs) whether it > compiles and installs isn't 1/10th as important as whether it eats my > data... I was clearly responding to the "contributing upstream" argument, which has nothing to do with eating data.
Re: [gentoo-dev] Changing policy about -Werror
> On Sep 10, 2018, at 5:48 PM, Richard Yao wrote: > > > >>> On Sep 10, 2018, at 5:27 PM, Kristian Fiskerstrand wrote: >>> On 9/10/18 11:21 PM, Kristian Fiskerstrand wrote: On 9/10/18 11:19 PM, Chí-Thanh Christopher Nguyễn wrote: It is indeed an insurmountable task to write code that is warning-free from the beginning across architectures, compiler versions, etc. But that is not the goal anyway. It is examining the situation and taking appropriate action, and then applying a change to no longer cause that particular warning (or make it non-fatal if the warning is bogus/harmless). >>> >>> sure, but for upstreams that make this an explicit goal, do we really >>> want to apply additional downstream pataches with the additional >>> complexity that carries for build system (autotools re-generation that >>> might make it unsupported upstream etc) ? >>> >> >> in all fairness, for one of my upstream packages, SKS, we make -Werror >> part of non-release versions but remove it for releases. > This has been what sys-fs/zfs has been doing for years. The USE=-debug builds > get -Werror while USE=-debug builds omit it. I think this is probably the > solution here. USE=debug is meant to help catch bugs, even if some reports > might be false positives. What it means varies on a per-package basis. I > would call catching a security issue helping to catch bugs. There is a typo here. USE=+debug builds get -Werror while USE=-debug omit -Werror. > >> But there are >> certain crypto related packages where you want the ensure it is properly >> handle altogether, in particular where RNG is concerned as there isn't >> really a proper way to test for it afterwards.. for other packages the >> test suite is of great importance.. if the tests are proper there isn't >> a great need, but sadly packages today doesn't really come with proper >> test suits >> >> -- >> Kristian Fiskerstrand >> OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net >> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 >> > >
Re: [gentoo-dev] Changing policy about -Werror
> On Sep 10, 2018, at 5:27 PM, Kristian Fiskerstrand wrote: > >> On 9/10/18 11:21 PM, Kristian Fiskerstrand wrote: >>> On 9/10/18 11:19 PM, Chí-Thanh Christopher Nguyễn wrote: >>> It is indeed an insurmountable task to write code that is warning-free >>> from the beginning across architectures, compiler versions, etc. But >>> that is not the goal anyway. It is examining the situation and taking >>> appropriate action, and then applying a change to no longer cause that >>> particular warning (or make it non-fatal if the warning is bogus/harmless). >> >> sure, but for upstreams that make this an explicit goal, do we really >> want to apply additional downstream pataches with the additional >> complexity that carries for build system (autotools re-generation that >> might make it unsupported upstream etc) ? >> > > in all fairness, for one of my upstream packages, SKS, we make -Werror > part of non-release versions but remove it for releases. This has been what sys-fs/zfs has been doing for years. The USE=-debug builds get -Werror while USE=-debug builds omit it. I think this is probably the solution here. USE=debug is meant to help catch bugs, even if some reports might be false positives. What it means varies on a per-package basis. I would call catching a security issue helping to catch bugs. > But there are > certain crypto related packages where you want the ensure it is properly > handle altogether, in particular where RNG is concerned as there isn't > really a proper way to test for it afterwards.. for other packages the > test suite is of great importance.. if the tests are proper there isn't > a great need, but sadly packages today doesn't really come with proper > test suits > > -- > Kristian Fiskerstrand > OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net > fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 >
Re: [gentoo-dev] Changing policy about -Werror
> On Sep 10, 2018, at 5:18 PM, Chí-Thanh Christopher Nguyễn > wrote: > > Fabian Groffen schrieb: >>> On 09-09-2018 11:22:41 -0400, Richard Yao wrote: >>> -Werror has caught bugs that could have resulted in data loss in ZFS in the >>> past thanks to it being built in userspace as part of zdb. So it is useful >>> for integrity too, not just security (although arguably, integrity is part >>> of security). >> This is a misconception, as jer already pointed out. Instead: >> -Werror has forced you to take notice of problems that could have >> resulted in data loss in ZFS ... > > But in general it doesn't say when or how the problems became acute. Assuming > that the warning isn't bogus, it could have been the code relying on > undefined behavior, and the compiler changing the semantics of such behavior, > and introducing an accompanying warning at the same time. This is precisely why every warning is considered a bug and -Werror is set when USE=debug is in use. > > > Best regards, > Chí-Thanh Christopher Nguyễn >
Re: [gentoo-dev] Changing policy about -Werror
> On Sep 10, 2018, at 4:59 PM, Mart Raudsepp wrote: > > Ühel kenal päeval, E, 10.09.2018 kell 22:56, kirjutas Kristian > Fiskerstrand: >>> On 9/10/18 10:51 PM, Matt Turner wrote: >>> Consider again the bug that started this. The maintainer had not >>> built >>> this configuration. None of the arch teams had built this >>> configuration until I did for the last architecture Cc'd. The patch >>> committed doesn't change anything installed on the system, if not >>> for >>> Werror preventing the code from building. >> >> one way to look at it though, is that it is a valuable upstream >> contribution that this configuration produces the error, so Gentoo is >> contributing to upstream development because of it. > > And losing users and thus relevance in the process. Not everyone goes > to bugzilla always and then waits for a fix, or fixes it themselves. > Normal people wipe that stuff away and install an operating > system/distribution that doesn't cause them grief in its place. I would like to point out that if -Werror is set by say USE=debug, this is not an issue.
Re: [gentoo-dev] Changing policy about -Werror
> On Sep 10, 2018, at 10:19 AM, Fabian Groffen wrote: > >> On 09-09-2018 11:22:41 -0400, Richard Yao wrote: >> -Werror has caught bugs that could have resulted in data loss in ZFS in the >> past thanks to it being built in userspace as part of zdb. So it is useful >> for integrity too, not just security (although arguably, integrity is part >> of security). > > This is a misconception, as jer already pointed out. Instead: > > -Werror has forced you to take notice of problems that could have > resulted in data loss in ZFS ... It did. That is why it is used as a debug feature only when USE=debug is set. USE=-debug does not use -Werror. USE=debug on that package is meant for people who want to help upstream catch bugs. > > Also, consider that for -Werror to be "better", you also need -O3 in > order to activate the "proper" compiler checks like "variable set but > never used" ones. I have had “set but never used” errors on -O2. > >> Perhaps we could have another USE flag for -Werror where it is a security >> feature. e.g. USE=strict-compile-checks > > You better run a static code analyser, such as the one you can hook up > with Travis. It usually points out real security problems such as > races, which GCC doesn't do yet, as far as I'm aware. Let alone > trigger with -Werror. We are using Coverity, but there is no one tool that catches all issues such that the compiler’s checks are redundant. > > Fabian > > > -- > Fabian Groffen > Gentoo on a different level
Re: [gentoo-dev] Changing policy about -Werror
On 9/10/18 11:35 PM, Chí-Thanh Christopher Nguyễn wrote: > > I fully understand why in the general case this is considered undesirable. > > But in very specific cases it can make sense to err on the side of > caution, and the rigid -Werror policy gets in the way. This is what the > initial message by bircoph suggested. I would argue that this depends on the upstream; some upstreams doesn't know the downstream implications of this and are slow at responding at issues. Others are very clear about it and this is the desired behavior; and they actually fix it quickly when reported. There is a difference here, and on some level that is up to maintainer privilege to evaluate the difference. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
Kristian Fiskerstrand schrieb: On 9/10/18 11:19 PM, Chí-Thanh Christopher Nguyễn wrote: It is indeed an insurmountable task to write code that is warning-free from the beginning across architectures, compiler versions, etc. But that is not the goal anyway. It is examining the situation and taking appropriate action, and then applying a change to no longer cause that particular warning (or make it non-fatal if the warning is bogus/harmless). sure, but for upstreams that make this an explicit goal, do we really want to apply additional downstream pataches with the additional complexity that carries for build system (autotools re-generation that might make it unsupported upstream etc) ? I fully understand why in the general case this is considered undesirable. But in very specific cases it can make sense to err on the side of caution, and the rigid -Werror policy gets in the way. This is what the initial message by bircoph suggested. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing policy about -Werror
On 9/10/18 11:31 PM, Rich Freeman wrote: > For more critical packages (like the example of zfs) whether it > compiles and installs isn't 1/10th as important as whether it eats my > data... exactly -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
On Mon, Sep 10, 2018 at 5:01 PM Mike Gilbert wrote: > > On Mon, Sep 10, 2018 at 4:56 PM Kristian Fiskerstrand wrote: > > > > On 9/10/18 10:51 PM, Matt Turner wrote: > > > Consider again the bug that started this. The maintainer had not built > > > this configuration. None of the arch teams had built this > > > configuration until I did for the last architecture Cc'd. The patch > > > committed doesn't change anything installed on the system, if not for > > > Werror preventing the code from building. > > > > one way to look at it though, is that it is a valuable upstream > > contribution that this configuration produces the error, so Gentoo is > > contributing to upstream development because of it. > > As an end user of Gentoo, I may not care about "contributing to > upstream"; I just want the software to compile and install. > For more critical packages (like the example of zfs) whether it compiles and installs isn't 1/10th as important as whether it eats my data... -- Rich
Re: [gentoo-dev] Changing policy about -Werror
On 9/10/18 11:21 PM, Kristian Fiskerstrand wrote: > On 9/10/18 11:19 PM, Chí-Thanh Christopher Nguyễn wrote: >> It is indeed an insurmountable task to write code that is warning-free >> from the beginning across architectures, compiler versions, etc. But >> that is not the goal anyway. It is examining the situation and taking >> appropriate action, and then applying a change to no longer cause that >> particular warning (or make it non-fatal if the warning is bogus/harmless). > > sure, but for upstreams that make this an explicit goal, do we really > want to apply additional downstream pataches with the additional > complexity that carries for build system (autotools re-generation that > might make it unsupported upstream etc) ? > in all fairness, for one of my upstream packages, SKS, we make -Werror part of non-release versions but remove it for releases. But there are certain crypto related packages where you want the ensure it is properly handle altogether, in particular where RNG is concerned as there isn't really a proper way to test for it afterwards.. for other packages the test suite is of great importance.. if the tests are proper there isn't a great need, but sadly packages today doesn't really come with proper test suits -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
Mart Raudsepp schrieb: one way to look at it though, is that it is a valuable upstream contribution that this configuration produces the error, so Gentoo is contributing to upstream development because of it. And losing users and thus relevance in the process. Not everyone goes to bugzilla always and then waits for a fix, or fixes it themselves. Normal people wipe that stuff away and install an operating system/distribution that doesn't cause them grief in its place. This is indeed a problem with -Werror (I mentioned it in a previous message). Tinderboxing as k_f suggested could not possibly cover the vast number of configurations that users have either. An alternative to -Werror could be maybe some kind of "package health" status that would alert users if warnings happened in supposedly warning-free code. Portage already has a "Package triggers severe warnings" QA notice which could be extended for this purpose. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing policy about -Werror
On 9/10/18 11:19 PM, Chí-Thanh Christopher Nguyễn wrote: > It is indeed an insurmountable task to write code that is warning-free > from the beginning across architectures, compiler versions, etc. But > that is not the goal anyway. It is examining the situation and taking > appropriate action, and then applying a change to no longer cause that > particular warning (or make it non-fatal if the warning is bogus/harmless). sure, but for upstreams that make this an explicit goal, do we really want to apply additional downstream pataches with the additional complexity that carries for build system (autotools re-generation that might make it unsupported upstream etc) ? -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
Matt Turner schrieb: This sounds good in theory, but I think it's pretty well established that in practice this isn't effective and instead is a large waste of time. I think even the thread starter stated that -Werror is unnecessary in the vast majority of cases. In fact, the foundational premise that it's possible to build without warnings everywhere is simply wrong. Consider again the bug that started this. The maintainer had not built this configuration. None of the arch teams had built this configuration until I did for the last architecture Cc'd. The patch committed doesn't change anything installed on the system, if not for Werror preventing the code from building. It is indeed an insurmountable task to write code that is warning-free from the beginning across architectures, compiler versions, etc. But that is not the goal anyway. It is examining the situation and taking appropriate action, and then applying a change to no longer cause that particular warning (or make it non-fatal if the warning is bogus/harmless). Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing policy about -Werror
Fabian Groffen schrieb: On 09-09-2018 11:22:41 -0400, Richard Yao wrote: -Werror has caught bugs that could have resulted in data loss in ZFS in the past thanks to it being built in userspace as part of zdb. So it is useful for integrity too, not just security (although arguably, integrity is part of security). This is a misconception, as jer already pointed out. Instead: -Werror has forced you to take notice of problems that could have resulted in data loss in ZFS ... But in general it doesn't say when or how the problems became acute. Assuming that the warning isn't bogus, it could have been the code relying on undefined behavior, and the compiler changing the semantics of such behavior, and introducing an accompanying warning at the same time. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing policy about -Werror
On 9/10/18 11:04 PM, Kristian Fiskerstrand wrote: > On 9/10/18 11:01 PM, Mike Gilbert wrote: > >> It's quite a bit harder for a user to remove -Werror from the build >> system, assuming they can even interpret the error output. >> > > Sure, but at some point it matters whether this is a leaf package or > something that is a core dependency. > > That it wasn't caught before being stabilized on several arches was > indeed bad, but that likely says more about our stabilization procedures > than the quality of the underlying package's upstream choices. > What I'm saying here is mostly that more tinderboxing is a good thing to capture all kinds of issues, and for upstreams being responsive Gentoo is a good way of providing valuable input. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
On 9/10/18 11:01 PM, Mike Gilbert wrote: > It's quite a bit harder for a user to remove -Werror from the build > system, assuming they can even interpret the error output. > Sure, but at some point it matters whether this is a leaf package or something that is a core dependency. That it wasn't caught before being stabilized on several arches was indeed bad, but that likely says more about our stabilization procedures than the quality of the underlying package's upstream choices. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
On Mon, Sep 10, 2018 at 4:56 PM Kristian Fiskerstrand wrote: > > On 9/10/18 10:51 PM, Matt Turner wrote: > > Consider again the bug that started this. The maintainer had not built > > this configuration. None of the arch teams had built this > > configuration until I did for the last architecture Cc'd. The patch > > committed doesn't change anything installed on the system, if not for > > Werror preventing the code from building. > > one way to look at it though, is that it is a valuable upstream > contribution that this configuration produces the error, so Gentoo is > contributing to upstream development because of it. As an end user of Gentoo, I may not care about "contributing to upstream"; I just want the software to compile and install. As has been previously stated, people who care can add -Werror to their own CFLAGS. It's quite a bit harder for a user to remove -Werror from the build system, assuming they can even interpret the error output.
Re: [gentoo-dev] Changing policy about -Werror
On 9/10/18 10:56 PM, Kristian Fiskerstrand wrote: > On 9/10/18 10:51 PM, Matt Turner wrote: >> Consider again the bug that started this. The maintainer had not built >> this configuration. None of the arch teams had built this >> configuration until I did for the last architecture Cc'd. The patch >> committed doesn't change anything installed on the system, if not for >> Werror preventing the code from building. > > one way to look at it though, is that it is a valuable upstream > contribution that this configuration produces the error, so Gentoo is > contributing to upstream development because of it. > Adding to this, that arch testing for stabilization didn't catch this might say more about our stabilization procedures than the quality of the upstream package (that in this case routinely includes patches to fix these issues). And they are mostly cought in testing (~arch) -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
Ühel kenal päeval, E, 10.09.2018 kell 22:56, kirjutas Kristian Fiskerstrand: > On 9/10/18 10:51 PM, Matt Turner wrote: > > Consider again the bug that started this. The maintainer had not > > built > > this configuration. None of the arch teams had built this > > configuration until I did for the last architecture Cc'd. The patch > > committed doesn't change anything installed on the system, if not > > for > > Werror preventing the code from building. > > one way to look at it though, is that it is a valuable upstream > contribution that this configuration produces the error, so Gentoo is > contributing to upstream development because of it. And losing users and thus relevance in the process. Not everyone goes to bugzilla always and then waits for a fix, or fixes it themselves. Normal people wipe that stuff away and install an operating system/distribution that doesn't cause them grief in its place. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Changing policy about -Werror
On 9/10/18 10:51 PM, Matt Turner wrote: > Consider again the bug that started this. The maintainer had not built > this configuration. None of the arch teams had built this > configuration until I did for the last architecture Cc'd. The patch > committed doesn't change anything installed on the system, if not for > Werror preventing the code from building. one way to look at it though, is that it is a valuable upstream contribution that this configuration produces the error, so Gentoo is contributing to upstream development because of it. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
On Mon, Sep 10, 2018 at 1:34 PM Chí-Thanh Christopher Nguyễn wrote: > > Jason Zaman schrieb: > >> No. With -Werror, upstream indicates that if a warning occurs, the build > >> should fail and the resulting code not be installed on user systems. > >> > >> Instead, someone knowledgeable should look at the situation *first* and > >> determine whether it is a bogus warning, a trivial issue, or something > >> which > >> warrants further attention. > >> > >> I have long disagreed with QA policy on this, and think that ebuilds should > >> respect upstream here. Of course giving users the ability to override. > > > > I disagree. -Werror means that upstream wants it to build without > > warnings on their distro with their version of the compiler with their > > versions of all the libraries. > > It means, upstream wants it to build without warnings everywhere. And if a > warning occurs (due to change in compiler, libraries, architecture, etc.), > have a developer look at it first before installing the code on user systems. This sounds good in theory, but I think it's pretty well established that in practice this isn't effective and instead is a large waste of time. In fact, the foundational premise that it's possible to build without warnings everywhere is simply wrong. Consider again the bug that started this. The maintainer had not built this configuration. None of the arch teams had built this configuration until I did for the last architecture Cc'd. The patch committed doesn't change anything installed on the system, if not for Werror preventing the code from building.
Re: [gentoo-dev] Changing policy about -Werror
Jason Zaman schrieb: No. With -Werror, upstream indicates that if a warning occurs, the build should fail and the resulting code not be installed on user systems. Instead, someone knowledgeable should look at the situation *first* and determine whether it is a bogus warning, a trivial issue, or something which warrants further attention. I have long disagreed with QA policy on this, and think that ebuilds should respect upstream here. Of course giving users the ability to override. I disagree. -Werror means that upstream wants it to build without warnings on their distro with their version of the compiler with their versions of all the libraries. It means, upstream wants it to build without warnings everywhere. And if a warning occurs (due to change in compiler, libraries, architecture, etc.), have a developer look at it first before installing the code on user systems. There are things that upstream absolutely should be setting which make a big difference for security like FORTIFY_SOURCE but hardened already has that set so I get this and thus basically everything would fail to compile. $ gcc -O1 -D_FORTIFY_SOURCE=2 foo.c :0:0: warning: "_FORTIFY_SOURCE" redefined : note: this is the location of the previous definition This all on amd64 too. If we start with other arches or cross compilers or other things then -Werror is just not possible. But you have looked at the issue, decided that it is harmless, and can now make this particular warning non-fatal. Or report upstream, so they can do the Right Thing™ and don't redefine. $ gcc -O1 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 foo.c That is all what is desired. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing policy about -Werror
On 09-09-2018 11:22:41 -0400, Richard Yao wrote: > -Werror has caught bugs that could have resulted in data loss in ZFS in the > past thanks to it being built in userspace as part of zdb. So it is useful > for integrity too, not just security (although arguably, integrity is part of > security). This is a misconception, as jer already pointed out. Instead: -Werror has forced you to take notice of problems that could have resulted in data loss in ZFS ... Also, consider that for -Werror to be "better", you also need -O3 in order to activate the "proper" compiler checks like "variable set but never used" ones. > Perhaps we could have another USE flag for -Werror where it is a security > feature. e.g. USE=strict-compile-checks You better run a static code analyser, such as the one you can hook up with Travis. It usually points out real security problems such as races, which GCC doesn't do yet, as far as I'm aware. Let alone trigger with -Werror. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
On Mon, Sep 10, 2018 at 01:46:51AM +0200, Chí-Thanh Christopher Nguyễn wrote: > Michał Górny schrieb: > > Are you suggesting that > > upstream is going to detect all those situations and prevent them from > > occurring, or are you going to WONTFIX the resulting bugs? > > No. With -Werror, upstream indicates that if a warning occurs, the build > should fail and the resulting code not be installed on user systems. > > Instead, someone knowledgeable should look at the situation *first* and > determine whether it is a bogus warning, a trivial issue, or something which > warrants further attention. > > I have long disagreed with QA policy on this, and think that ebuilds should > respect upstream here. Of course giving users the ability to override. I disagree. -Werror means that upstream wants it to build without warnings on their distro with their version of the compiler with their versions of all the libraries. Even if upstream was using gentoo (they're not) they'd need to be testing both stable and unstable toolchains since there are frequently warnings that show up in one and not the other and also between gcc/clang. I agree with jer on this, if you want specific warnings to be errors use -Werror=foo or something not a blanket -Werror. There are things that upstream absolutely should be setting which make a big difference for security like FORTIFY_SOURCE but hardened already has that set so I get this and thus basically everything would fail to compile. $ gcc -O1 -D_FORTIFY_SOURCE=2 foo.c :0:0: warning: "_FORTIFY_SOURCE" redefined : note: this is the location of the previous definition This all on amd64 too. If we start with other arches or cross compilers or other things then -Werror is just not possible. -- Jason
Re: [gentoo-dev] Changing policy about -Werror
On Sun, Sep 9, 2018 at 1:50 PM Michael Orlitzky wrote: > > So if you're using -Werror to prevent a > "vulnerable" package from being installed, it doesn't work, and can > actually be harmful if it prevents me from using a better compiler. > Whether or not the new compiler is better, it is clearly untested with the package-version in question (otherwise these warnings would have been addressed). For something critical like a filesystem (zfs) that could be useful to know. I'm not convinced that this rule ought to be absolute. That said, I do agree with your later comments that this creates a messy situation by painting a user into a corner. Other than sticking painful ranged version dependencies on the toolchain into the package I'm not sure if there is a cleaner solution that guarantees that the package won't be built with a version of gcc that is untested with that specific package without a user override. I guess we could just have sensitive ebuilds output that it might eat your data if you didn't add -Werror to your CFLAGS and then leave it to the users to decide how much they care about build errors vs unlikely sorry-I-lost-your-10PiB-array errors. -- Rich
Re: [gentoo-dev] Changing policy about -Werror
Andrew Savchenko schrieb: So my proposal is: 1) Deprecate QA policy with unconditional demand of -Werror removal. 2) Add to devmanual's chapter on -Werror an exception clause about security-oriented software and maintainer's right to make final decision. Likely this proposal will not fly. I understand that -Werror is a precautionary measure against installing broken code on user systems, and I am all for using it when upstream says so. But it is understandably unwelcome by many on Gentoo. If ebuilds started to use -Werror in greater numbers, perceived tree quality would go down as build failures increase. "But it's for your own good!" you would tell users who are angry again that package XY didn't compile. -Werror gets in the way of users getting things done, and if that happens too often, you might drive those users out. So while I would very much like to see -Werror allowed, this is just not going to happen. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing policy about -Werror
Michał Górny schrieb: Are you suggesting that upstream is going to detect all those situations and prevent them from occurring, or are you going to WONTFIX the resulting bugs? No. With -Werror, upstream indicates that if a warning occurs, the build should fail and the resulting code not be installed on user systems. Instead, someone knowledgeable should look at the situation *first* and determine whether it is a bogus warning, a trivial issue, or something which warrants further attention. I have long disagreed with QA policy on this, and think that ebuilds should respect upstream here. Of course giving users the ability to override. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing policy about -Werror
On Sun, Sep 9, 2018 at 4:32 AM Andrew Savchenko wrote: > > Hi! > > Our current -Werror policy demands unconditional removal: > https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed > > I think this is wrong, see bugs 665464, 665538 for a recent > discussion why. Bug 665464 supports the exact opposite conclusion. Werror turned a trivial warning into a build failure. > My point is that in *most* cases -Werror indeed should be removed, > because upstream rarely can keep up with all possible configure, > *FLAGS, compiler versions and arch combinations. But! In some cases > — especially for security oriented software — this flag may be > pertain and may be kept at maintainer's discretion. > > The rationale is that -Werror usually points to dangerous > situations like uninitialized variables, pointer type mismatch or > implicit function declaration (and much more) which may lead to > serious security implications. Warnings are often over unimportant details (like in this bug). It is certainly not the case that they "usually point to dangerous situations". > So, if maintainer has enough manpower to support this flag, we > should allow to keep it. Of course if it will cause long-standing > troubles (e.g. bugs opened for a long time) QA should have power to > remove it or demand its removal. In the bug that started this, it was the case that the maintainer himself had not built the package with this configuration. Nor had any arch team that recently stabilized the package (x86, amd64, ia64, ppc, ppc64, arm). So again, the bug supports the opposite conclusion. The policy is sound, and I don't think we could have found a worse bug as supporting evidence that we should revise the policy.
Re: [gentoo-dev] Changing policy about -Werror
On 09/09/2018 07:32 AM, Andrew Savchenko wrote: > Hi! > > Our current -Werror policy demands unconditional removal: > https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed > > I think this is wrong, see bugs 665464, 665538 for a recent > discussion why. > > ... I agree with the QA team on this. For the upstream maintainer, -Werror is useful and deserves to be enabled. For the end-user, on the other hand, it has no real benefit. And for users of a source-based distribution, it is actively harmful. Here are some random points: * A -Werror failure doesn't actually prevent me from installing a package, it only prevents me from installing a package with a newer compiler (that often provides other security improvements, like Spectre mitigation). So if you're using -Werror to prevent a "vulnerable" package from being installed, it doesn't work, and can actually be harmful if it prevents me from using a better compiler. * The build failures from -Werror don't occur only with new installs. They also occur during rebuilds for things like USE changes or library ABI updates, leaving you with a broken system. * Upstream maintainers can't retroactively fix Gentoo versions. If some old version foo-1.0 builds with gcc-8.x and is stable, but then breaks with gcc-9.x due to a new warning, how is upstream going to fix that? They aren't -- and you aren't either without patching a supposedly stable package in-place. * Breakage with -Werror prevents upgrades of an already-installed package. If there's a security vulnerability in an old version and if -Werror is preventing me from upgrading (thanks to a gcc upgrade in the meantime), then you've just made things much worse. And so on.
Re: [gentoo-dev] Changing policy about -Werror
> On Sep 9, 2018, at 1:09 PM, Richard Yao wrote: > > > >> On Sep 9, 2018, at 12:11 PM, Michał Górny wrote: >> >> On Sun, 2018-09-09 at 11:22 -0400, Richard Yao wrote: On Sep 9, 2018, at 7:32 AM, Andrew Savchenko wrote: Hi! Our current -Werror policy demands unconditional removal: https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed I think this is wrong, see bugs 665464, 665538 for a recent discussion why. My point is that in *most* cases -Werror indeed should be removed, because upstream rarely can keep up with all possible configure, *FLAGS, compiler versions and arch combinations. But! In some cases — especially for security oriented software — this flag may be pertain and may be kept at maintainer's discretion. The rationale is that -Werror usually points to dangerous situations like uninitialized variables, pointer type mismatch or implicit function declaration (and much more) which may lead to serious security implications. So, if maintainer has enough manpower to support this flag, we should allow to keep it. Of course if it will cause long-standing troubles (e.g. bugs opened for a long time) QA should have power to remove it or demand its removal. So my proposal is: 1) Deprecate QA policy with unconditional demand of -Werror removal. 2) Add to devmanual's chapter on -Werror an exception clause about security-oriented software and maintainer's right to make final decision. >>> >>> -Werror has caught bugs that could have resulted in data loss in ZFS in the >>> past thanks to it being built in userspace as part of zdb. So it is useful >>> for integrity too, not just security (although arguably, integrity is part >>> of security). >>> >>> Currently, sys-fs/zfs turns on -Werror when USE=debug is set. So far, >>> nobody has complained about USE=debug enforcing -Werror. USE=debug by >>> definition ought to be an exception. >> >> Now that you know that you're violating a policy, please kindly fix >> that. > I already knew about the policy. However, USE=debug is by definition meant > for debug purposes. -Werror is helpful for debugging. There is nothing wrong > with turning it on for debugging. The normal builds don’t have USE=debug set > and -Werror is not used there. By the way, if people insist on applying this policy to USE=debug, I am inclined to mask the USE flag. This would satisfy the policy, but I don’t think that is better than how things are now. Users already are warned not to set USE=debug globally and if they are setting it on a specific package, they are opting into the package’s definition of debug functionality. I don’t see a problem with having -Werror as part of USE=debug. USE=debug on that package is meant to be an aid to upstream development and upstream in this case wants to know about any warnings. >>> Perhaps we could have another USE flag for -Werror where it is a security >>> feature. e.g. USE=strict-compile-checks >> >> Perhaps people could learn that Gentoo lets them alter CFLAGS, and stop >> inventing USE flags for every flag the compiler supports. >> Best regards, Andrew Savchenko >>> >>> >> >> -- >> Best regards, >> Michał Górny > >
Re: [gentoo-dev] Changing policy about -Werror
On Sep 9, 2018, at 12:32 PM, Ulrich Mueller wrote: >> On Sun, 09 Sep 2018, Andrew Savchenko wrote: > >> What I'm trying to do is to allow maintainers to keep -Werror if >> they really want to do this, understand what they are doing and >> have enough manpower to support this. > > Bug 665464 has just proven that this doesn't work. That bug would not > have happened if the policy had been followed. Also its fix (removal of > an unused variable) should have been applied only upstream. I don't see > a good reason for adding downstream patches that will make no difference > for the resulting binary. At least not when the upstream package is > maintained, and the issue will likely go away with one of the next > releases. > >> As can be seen from aforementioned bugs right now developer and >> upstream support this to their best and yet QA team tries to >> enforce -Werror drop using the brute force and ignoring active best >> effort support. This should not happen. > > See flameeyes's old blog post for the rationale why the current policy > is in place: > https://flameeyes.blog/2009/02/25/future-proof-your-code-dont-use-werror/ For every pointless check that fails -Werror, there is likely one that actually does matter. An unused variable could go either way if upstream intended to use that variable, but used another one by mistake (it happens). Allowing users to opt into -Werror behavior on specific packages whose maintainers have a good reason to do it and are keeping up with things would be alright. > > Ulrich >
