[gentoo-dev] Changing policy about -Werror

[gentoo-dev] Changing policy about -Werror

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]

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.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 1466 bytes --]

Hi,

I disagree. Either discuss to drop the entire policy about "-Werror" or
don't but please do _not_ enter the game of differentiating between
"normal" and something you call "security-orientated" packages.

You will lose this game in the end.

If there's really a reason to allow "-Werror" it applies to *any*
package or there isn't a good reason. _Any_ package can be part of a
chained attack. Saying "Uh, this is a security-orientated package, we
must keep '-Werror' for..." -- for WHAT?! You are probably creating a
false sense of security...

Let me remind you of something like
https://daniel.haxx.se/blog/2016/10/14/a-single-byte-write-opened-a-root-execution-exploit/

No, "-Werror" wouldn't have prevent this, that's not my point. My point
is, that there's nothing like "security-orientated" packages. And in the
end you deal with chained attacks involving vectors you haven't thought
of before involving otherwise harmless packages.


Regarding a general drop of that policy: No, I wouldn't change that
policy at all. Gentoo is a rolling distribution and "-Werror" creates
undesired problems in most cases. Given that we have another rule that
any package must respect user's CFLAGS any user or dev who care can add
"-Werror" back to his/her CFLAGS... but don't force every user of Gentoo
to deal with that.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 636 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

On Sun, 9 Sep 2018 15:03:11 +0200 Thomas Deutschmann wrote:
> Hi,
> 
> I disagree. Either discuss to drop the entire policy about "-Werror" or
> don't but please do _not_ enter the game of differentiating between
> "normal" and something you call "security-orientated" packages.

You got me wrong. I'm not trying to build special rules for
security packages (since there is no margin between them and other
packages and you rightfully pointed out that any vulnerability may
play a role in a chained attack); they were just an example.

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.

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.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Ulrich Mueller]

>>>>> 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/

Ulrich

Re: [gentoo-dev] Changing policy about -Werror

[Richard Yao]

On Sep 9, 2018, at 12:32 PM, Ulrich Mueller <ulm@gentoo.org> 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
> 

Re: [gentoo-dev] Changing policy about -Werror

[Jeroen Roovers]

On Sun, 9 Sep 2018 14:32:21 +0300
Andrew Savchenko <bircoph@gentoo.org> wrote:

> Hi!
> 
> Our current -Werror policy demands unconditional removal:
> https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed

Which is great.

> I think this is wrong, see bugs 665464, 665538 for a recent
> discussion why.

That's just QA failing to be human in one report and then again in
another report. It happens all the time and cannot be fixed, so you seem
to instead suggest banning -Werror wrong because some developers think
they can sanely cat-herd -Werror's overreaching effects.

> 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.
  ^^^^^^^
Pertinent, you meant to say, I assume.

If you really have to support this mistaken (upstream) sense of
security, instead go for -Werror=<warning> (see gcc(1)) i.e. turn very
specific warnings into errors instead of turning _all_ warnings into
errors.

> The rationale is that -Werror usually points to dangerous
> situations like uninitialized variables, pointer type mismatch or
> implicit function declaration (and much more)

No it does not. It merely turns warnings (non-fatal) emitted by the
actual checks into errors (fatal). It does not cause any checks to be
performed or warnings to be issued by itself.

Setting or allowing a blanket -Werror therefore causes innocuous
warnings like this:

   warning: format not a string literal, argument types not checked
   [-Wformat-nonliteral]
   (In other words: FIXME: I didn't check this format because it was not
   a string literal and I cannot yet resolve those into an actual format
   defined elsewhere.*)

and this:

   # hppa2.0-unknown-linux-gnu-gcc -fstack-protector main.c
   cc1: warning: -fstack-protector not supported for this target

into hilarious errors.

To some those might look like succeeding security checks, but they're
really failing sanity checks.

> 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.

You have yet to give arguments for its removal. Like, proper and
particular examples of where -Werror benefits everyone. So far I've
seen only some hand-waving of the (in)security banner. 

Unless you meant to say that security is improved when you can't
install the software when of -Werror prevents it from being built,
because then you've already solved the entire problem of the software's
purported vulnerabilities, indeed.

> 2) Add to devmanual's chapter on -Werror an exception clause about
> security-oriented software and maintainer's right to make final
> decision.

That clause will be the laughing stock of the security community.


Regards,
     jer


* We have plenty of bug reports already where one "security researcher"
points out that the build fails when the former warning is triggered
when -Werror is injected, and it might indeed look like a lurking
security issue if it weren't for the fact that the format sanity check
never took place.

Re: [gentoo-dev] Changing policy about -Werror

[Richard Yao]

> On Sep 9, 2018, at 7:32 AM, Andrew Savchenko <bircoph@gentoo.org> 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.

Perhaps we could have another USE flag for -Werror where it is a security feature. e.g. USE=strict-compile-checks
> 
> Best regards,
> Andrew Savchenko

Re: [gentoo-dev] Changing policy about -Werror

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2393 bytes --]

On Sun, 2018-09-09 at 11:22 -0400, Richard Yao wrote:
> > On Sep 9, 2018, at 7:32 AM, Andrew Savchenko <bircoph@gentoo.org> 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.

> 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Richard Yao]

> On Sep 9, 2018, at 12:11 PM, Michał Górny <mgorny@gentoo.org> wrote:
> 
> On Sun, 2018-09-09 at 11:22 -0400, Richard Yao wrote:
>>> On Sep 9, 2018, at 7:32 AM, Andrew Savchenko <bircoph@gentoo.org> 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.
> 
>> 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

[Richard Yao]

> On Sep 9, 2018, at 1:09 PM, Richard Yao <ryao@gentoo.org> wrote:
> 
> 
> 
>> On Sep 9, 2018, at 12:11 PM, Michał Górny <mgorny@gentoo.org> wrote:
>> 
>> On Sun, 2018-09-09 at 11:22 -0400, Richard Yao wrote:
>>>> On Sep 9, 2018, at 7:32 AM, Andrew Savchenko <bircoph@gentoo.org> 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

[Richard Yao]

> On Sep 9, 2018, at 12:11 PM, Michał Górny <mgorny@gentoo.org> wrote:
> 
> On Sun, 2018-09-09 at 11:22 -0400, Richard Yao wrote:
>>> On Sep 9, 2018, at 7:32 AM, Andrew Savchenko <bircoph@gentoo.org> 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.
> 
>> 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.

Do that and watch nearly everything break. 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. It is better than letting users discover that via random trial and error. That just wastes people’s time.
> 
>>> 
>>> Best regards,
>>> Andrew Savchenko
>> 
>> 
> 
> -- 
> Best regards,
> Michał Górny

Re: [gentoo-dev] Changing policy about -Werror

[Andreas K. Huettel]

> 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
dilfridge@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

Re: [gentoo-dev] Changing policy about -Werror

[Richard Yao]

On Sep 12, 2018, at 4:28 PM, Andreas K. Huettel <dilfridge@gentoo.org> 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
> dilfridge@gentoo.org
> Gentoo Linux developer 
> (council, toolchain, perl, libreoffice, comrel)
> 
> 
> 

Re: [gentoo-dev] Changing policy about -Werror

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Chí-Thanh Christopher Nguyễn]

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

[Richard Yao]

> On Sep 10, 2018, at 5:18 PM, Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> 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

[Richard Yao]

> On Sep 10, 2018, at 10:19 AM, Fabian Groffen <grobian@gentoo.org> 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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2221 bytes --]

On Sun, 2018-09-09 at 14:32 +0300, 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.

It may also point to a different coding style, user's flags (like
clang's 'argument unused during X' warnings.  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?

> 
> 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.

What you're saying basically boils down to 'it's fine that the package
randomly fails to build if somebody will fix it'.  However, some people
actually use Gentoo on real systems and really prefer when things
*build*.  While resolving warnings etc. is usually a worthwhile goal,
not at the cost of having users repeatedly hit failures, have to report
bugs about them and wait for the maintainer to fix them.

Not to mention that those fixes only work for new versions,
and therefore this whole idea turns downgrading (however undesirable you
might consider it) into a pointless effort of chasing old warnings.

This is just another example of writing programs for a single toolchain,
and adding more hacks every time someone tests with another one.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Chí-Thanh Christopher Nguyễn]

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

[Jason Zaman]

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
<command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined
<built-in>: 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

[Chí-Thanh Christopher Nguyễn]

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
> <command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined
> <built-in>: 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

[Matt Turner]

On Mon, Sep 10, 2018 at 1:34 PM Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> 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

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 704 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Mart Raudsepp]

[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

Ü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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Chí-Thanh Christopher Nguyễn]

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

[Richard Yao]

> On Sep 10, 2018, at 4:59 PM, Mart Raudsepp <leio@gentoo.org> 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

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1055 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Mike Gilbert]

On Mon, Sep 10, 2018 at 4:56 PM Kristian Fiskerstrand <k_f@gentoo.org> 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

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 648 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 915 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 519 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 636 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Rich Freeman]

On Mon, Sep 10, 2018 at 5:01 PM Mike Gilbert <floppym@gentoo.org> wrote:
>
> On Mon, Sep 10, 2018 at 4:56 PM Kristian Fiskerstrand <k_f@gentoo.org> 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

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 352 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Mike Gilbert]

On Mon, Sep 10, 2018 at 5:31 PM Rich Freeman <rich0@gentoo.org> wrote:
>
> On Mon, Sep 10, 2018 at 5:01 PM Mike Gilbert <floppym@gentoo.org> wrote:
> >
> > On Mon, Sep 10, 2018 at 4:56 PM Kristian Fiskerstrand <k_f@gentoo.org> 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

[Chí-Thanh Christopher Nguyễn]

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

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 835 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1428 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Richard Yao]

> On Sep 10, 2018, at 5:27 PM, Kristian Fiskerstrand <k_f@gentoo.org> 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

[Richard Yao]

> On Sep 10, 2018, at 5:48 PM, Richard Yao <ryao@gentoo.org> wrote:
> 
> 
> 
>>> On Sep 10, 2018, at 5:27 PM, Kristian Fiskerstrand <k_f@gentoo.org> 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

[Chí-Thanh Christopher Nguyễn]

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

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 862 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Jason Zaman]

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
> <chithanh@gentoo.org> 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

[Rich Freeman]

On Wed, Sep 12, 2018 at 4:56 AM Jason Zaman <perfinion@gentoo.org> 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

[Mike]

[-- Attachment #1.1: Type: text/plain, Size: 1753 bytes --]



On 9/12/18 10:50 AM, Rich Freeman wrote:
> On Wed, Sep 12, 2018 at 4:56 AM Jason Zaman <perfinion@gentoo.org> 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






[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]

>>>>> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Mike]

[-- Attachment #1.1: Type: text/plain, Size: 2022 bytes --]



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.








[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Rich Freeman]

On Thu, Sep 13, 2018 at 9:29 AM Mike <mpagano@gentoo.org> 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

[Mike]

[-- Attachment #1.1: Type: text/plain, Size: 729 bytes --]



On 9/13/18 9:35 AM, Rich Freeman wrote:
> On Thu, Sep 13, 2018 at 9:29 AM Mike <mpagano@gentoo.org> 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.





[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

>>>>> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 1229 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 636 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Rich Freeman]

On Wed, Sep 12, 2018 at 6:55 PM Thomas Deutschmann <whissi@gentoo.org> 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

[Matt Turner]

On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman <rich0@gentoo.org> 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

[Rich Freeman]

On Wed, Sep 12, 2018 at 7:52 PM Matt Turner <mattst88@gentoo.org> wrote:
>
> On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman <rich0@gentoo.org> 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

[Matt Turner]

On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman <rich0@gentoo.org> wrote:
>
> On Wed, Sep 12, 2018 at 7:52 PM Matt Turner <mattst88@gentoo.org> wrote:
> >
> > On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman <rich0@gentoo.org> 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

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

On 12-09-2018 17:46:03 -0700, Matt Turner wrote:
> On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman <rich0@gentoo.org> wrote:
> >
> > On Wed, Sep 12, 2018 at 7:52 PM Matt Turner <mattst88@gentoo.org> wrote:
> > >
> > > On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman <rich0@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Alon Bar-Lev]

On Thu, Sep 13, 2018 at 6:51 PM Fabian Groffen <grobian@gentoo.org> wrote:
>
> On 12-09-2018 17:46:03 -0700, Matt Turner wrote:
> > On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman <rich0@gentoo.org> 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

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

On 13-09-2018 18:56:13 +0300, Alon Bar-Lev wrote:
> On Thu, Sep 13, 2018 at 6:51 PM Fabian Groffen <grobian@gentoo.org> wrote:
> >
> > On 12-09-2018 17:46:03 -0700, Matt Turner wrote:
> > > On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman <rich0@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Alon Bar-Lev]

On Thu, Sep 13, 2018 at 7:20 PM Fabian Groffen <grobian@gentoo.org> 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

[Georg Rudoy]

On 13.09.2018 at 16:20 user Fabian Groffen <grobian@gentoo.org> 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

[Chí-Thanh Christopher Nguyễn]

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

[Richard Yao]

> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann <whissi@gentoo.org> 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

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 2093 bytes --]

On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
> 
> 
> > On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann <whissi@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Richard Yao]

> On Sep 13, 2018, at 12:03 PM, Fabian Groffen <grobian@gentoo.org> wrote:
> 
>> On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
>> 
>> 
>>>> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann <whissi@gentoo.org> 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

[Matt Turner]

On Thu, Sep 13, 2018 at 4:13 PM Richard Yao <ryao@gentoo.org> wrote:
> > On Sep 13, 2018, at 12:03 PM, Fabian Groffen <grobian@gentoo.org> wrote:
> >
> >> On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
> >>
> >>
> >>>> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann <whissi@gentoo.org> 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

[Richard Yao]

> On Sep 13, 2018, at 7:21 PM, Matt Turner <mattst88@gentoo.org> wrote:
> 
> On Thu, Sep 13, 2018 at 4:13 PM Richard Yao <ryao@gentoo.org> wrote:
>>> On Sep 13, 2018, at 12:03 PM, Fabian Groffen <grobian@gentoo.org> wrote:
>>> 
>>>> On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
>>>> 
>>>> 
>>>>>> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann <whissi@gentoo.org> 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

[Georg Rudoy]

On 14.09.2018 at 0:44 user Richard Yao <ryao@gentoo.org> 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

[gentoo-dev] Changing policy about -Werror

[Richard Yao]

[-- Attachment #1.1: Type: text/plain, Size: 3975 bytes --]



> On Sep 13, 2018, at 8:54 PM, Georg Rudoy <0xd34df00d@gmail.com> wrote:
> 
>> On 14.09.2018 at 0:44 user Richard Yao <ryao@gentoo.org> 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
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Matt Turner]

On Thu, Sep 13, 2018 at 5:44 PM Richard Yao <ryao@gentoo.org> wrote:
> > On Sep 13, 2018, at 7:21 PM, Matt Turner <mattst88@gentoo.org> wrote:
> >
> > On Thu, Sep 13, 2018 at 4:13 PM Richard Yao <ryao@gentoo.org> wrote:
> >>> On Sep 13, 2018, at 12:03 PM, Fabian Groffen <grobian@gentoo.org> wrote:
> >>>
> >>>> On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
> >>>>
> >>>>
> >>>>>> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann <whissi@gentoo.org> 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

[Richard Yao]

> On Sep 13, 2018, at 11:35 PM, Matt Turner <mattst88@gentoo.org> wrote:
> 
> On Thu, Sep 13, 2018 at 5:44 PM Richard Yao <ryao@gentoo.org> wrote:
>>> On Sep 13, 2018, at 7:21 PM, Matt Turner <mattst88@gentoo.org> wrote:
>>> 
>>> On Thu, Sep 13, 2018 at 4:13 PM Richard Yao <ryao@gentoo.org> wrote:
>>>>> On Sep 13, 2018, at 12:03 PM, Fabian Groffen <grobian@gentoo.org> wrote:
>>>>> 
>>>>>> On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
>>>>>> 
>>>>>> 
>>>>>>>> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann <whissi@gentoo.org> 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

[Sergei Trofimovich]

On Fri, 14 Sep 2018 11:54:57 -0400
Richard Yao <ryao@gentoo.org> 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<int>)':
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 <vector>
template <typename a, typename b> 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 <typename i, typename b> i o(i d, i e, b f, int *g) {
  return c(d, e, f, g);
}
template <typename i, typename b> i oo(i d, i e, b f, int *g) {
  return c(d, e, f, g);
}
template <typename j, typename b> j k(j d, j e, b f, int *g) {
  return o(d, e, f, g);
}
template <typename j, typename b> j kk(j d, j e, b f, int *g) {
  return oo(d, e, f, g);
}
bool cmpp(int);
bool foo(std::vector<int> l) {
  std::vector<int>::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

[Richard Yao]

> On Sep 14, 2018, at 7:07 PM, Sergei Trofimovich <slyfox@gentoo.org> wrote:
> 
> On Fri, 14 Sep 2018 11:54:57 -0400
> Richard Yao <ryao@gentoo.org> 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<int>)':
> 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 <vector>
> template <typename a, typename b> 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 <typename i, typename b> i o(i d, i e, b f, int *g) {
>  return c(d, e, f, g);
> }
> template <typename i, typename b> i oo(i d, i e, b f, int *g) {
>  return c(d, e, f, g);
> }
> template <typename j, typename b> j k(j d, j e, b f, int *g) {
>  return o(d, e, f, g);
> }
> template <typename j, typename b> j kk(j d, j e, b f, int *g) {
>  return oo(d, e, f, g);
> }
> bool cmpp(int);
> bool foo(std::vector<int> l) {
>  std::vector<int>::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

[Chí-Thanh Christopher Nguyễn]

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

[Alon Bar-Lev]

On Sat, Sep 22, 2018 at 1:33 AM Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> 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]

[-- Attachment #1.1: Type: text/plain, Size: 2382 bytes --]

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 <whissi@gentoo.org> 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
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Richard Yao]

[-- Attachment #1.1: Type: text/plain, Size: 1895 bytes --]

On 09/13/2018 07:36 AM, Richard Yao wrote:
> 
> 
>> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann <whissi@gentoo.org> 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
>>
> 
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Michael Orlitzky]

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

[Rich Freeman]

On Sun, Sep 9, 2018 at 1:50 PM Michael Orlitzky <mjo@gentoo.org> 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

[Matt Turner]

On Sun, Sep 9, 2018 at 4:32 AM Andrew Savchenko <bircoph@gentoo.org> 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

[Chí-Thanh Christopher Nguyễn]

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

[Andreas K. Huettel]

> 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
dilfridge@gentoo.org
Gentoo Linux developer 
(council, toolchain, perl, libreoffice, comrel)

Re: [gentoo-dev] Changing policy about -Werror

[Alon Bar-Lev]

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 positive and one
positive issues. These issues in most cases found by our non stable
user community, either these who are using individual packages as non
stable or these that are using a non-stable toolchain. Many of these
issues are triggering automation such as the one that Toralf Förster
is running that helps to improve Gentoo directly and the entire open
source eco-system indirectly. Stable users are seldom affected from
-Werror issues as our non stable process usually enables to resolve
these issues before stabilization.

ARGUMENT: Old packages in tree will not be built with newer toolchain
if -Werror is enabled.

The role of package maintainer is to make sure that everything in tree
is working regardless of -Werror, he has the choice either to remove
old incompatible packages or patch them to remove  -Werror.

There are different reasons why a package will not be built, for
example when nothrow destructors were introduced, we must had fixed
many packages to meet this new policy to avoid undesired program
termination.

The policy I take is to leave only recent stable package for each
slot, as there usually sufficient time when stabilization is starting
and ending.

ARGUMENT: -Werror cause even more issues when cross compiling a package

When -Werror is carefully maintained by both upstream and downstream,
and when cross compile is supported by both upstream and downstream,
there is no reason why -Werror have any side effect compared to
native. Every issue resulted out of -Werror must be evaluated and
resolved per the upstream policy of supporting -Werror.

Package maintainer has always the option to remove -Werror if package
is causing maintenance overhead which cannot be resolved in decent
resources.

ARGUMENT: User do not care about helping upstream to improve their packages

I believe Gentoo users do care about upstream, Gentoo unstable users
are unstable exactly for this purpose. For sure, Gentoo users
understand that the more Gentoo patches software the less support they
can receive directly from upstream.

It is sufficient to perform autoreconf to replace upstream tools to
void the warranty of upstream.

Users who is using Gentoo are advanced users compared to other
distributions and are fully aware of the upstream quality, in many
cases they help us to convince upstream to be receptive.

ARGUMENT: Maintainer must join toolchain team and test everything with
every release candidate of the compiler

The Gentoo unstable process is exactly designed for this phase,
without joining other project a developer can test his packages with
the recent version of dependent packages.

ARGUMENT: Any maintainer can add this to his CFLAGS him/herself if
s/he wishes so.

Unlike binary semi-commercial distributions, Gentoo do not provide an
automation infrastructure for developers to use. A Gentoo developer is
using his own system and resources to test packages at best effort,
delegating the rest of the permutations for unstable users, arch teams
and then to stable users.

Don't get me wrong, I would love to have an environment provided by
infra to allow me to run an ebuild candidate for all architectures and
all USE flag combinations in a single batch and to trigger rebuild
when every non-stable dependency is introduced or when @system is
modified.

I am thankful for Toralf Förster efforts to help us be closer to automation.

However, enabling the flag only at the architecture in which the
developer has access to has a very little value, the -Werror is a life
saver when it is causing build failure on environment the developer do
not have access to.

ARGUMENT: Add -Werror when a specific USE flag is set

This USE flag will probably not be enabled for most of users, and
enabled only after a damage happened.

One can expect automation to enable this flag, however, if we already
have automation then automation will assist of resolving the -Werror
issues so that issues will not be manifested later in pipeline.

We can conditionally patch the package in non-stable and stable,
however, any patch is evil and fork us from upstream as I described
above.

ARGUMENT: You have no idea how much unneccessary pain -Werror caused
when gcc started warning on "misleading indentation".

Whoever maintain -Werror packages as downstream or upstream has
idea... Please avoid these statements.

Even misleading indentation may be result of incorrect patch merge or
visually undetected branch that is not being executed at the right
flow, we are human after all.

Based on the above, I would like us to allow maintainer to decide when
and if he would like to maintain a package with -Werror based on by
statement at the top.

Regards,
Alon

Re: [gentoo-dev] Changing policy about -Werror

[Chí-Thanh Christopher Nguyễn]

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

[Rich Freeman]

On Wed, Sep 12, 2018 at 7:32 PM Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> 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

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 908 bytes --]

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
> <chithanh@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Sergei Trofimovich]

On Tue, 11 Sep 2018 12:44:38 +0300
Alon Bar-Lev <alonbl@gentoo.org> 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

[Alon Bar-Lev]

On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich <slyfox@gentoo.org> wrote:
>
> On Tue, 11 Sep 2018 12:44:38 +0300
> Alon Bar-Lev <alonbl@gentoo.org> 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 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.

Most of these issues are detected early at process by unstable users
which are opening bugs.

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.

> 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.

> > 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?

When downstream maintainer create healthy relationship with upstream,
and when mutual interest is to support clang then working together to
improve upstream support of clang instead doing that at downstream is
much better solution to the entire open source eco-system.

Regards,
Alon

Re: [gentoo-dev] Changing policy about -Werror

[Richard Yao]

[-- Attachment #1.1: Type: text/plain, Size: 8134 bytes --]

On 09/14/2018 12:40 PM, Alon Bar-Lev wrote:
> On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich <slyfox@gentoo.org> wrote:
>>
>> On Tue, 11 Sep 2018 12:44:38 +0300
>> Alon Bar-Lev <alonbl@gentoo.org> 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, 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 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.
> 
> Most of these issues are detected early at process by unstable users
> which are opening bugs.
> 
> 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.
> 
>> 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.
> 
>>> 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?
> 
> When downstream maintainer create healthy relationship with upstream,
> and when mutual interest is to support clang then working together to
> improve upstream support of clang instead doing that at downstream is
> much better solution to the entire open source eco-system.
> 
> Regards,
> Alon
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Alon Bar-Lev]

On Fri, Sep 14, 2018 at 8:16 PM Richard Yao <ryao@gentoo.org> wrote:
>
> On 09/14/2018 12:40 PM, Alon Bar-Lev wrote:
> > On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich <slyfox@gentoo.org> wrote:
> >>
> >> On Tue, 11 Sep 2018 12:44:38 +0300
> >> Alon Bar-Lev <alonbl@gentoo.org> 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

[Rich Freeman]

On Fri, Sep 14, 2018 at 1:22 PM Alon Bar-Lev <alonbl@gentoo.org> 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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2735 bytes --]

On Fri, 2018-09-14 at 20:22 +0300, Alon Bar-Lev wrote:
> On Fri, Sep 14, 2018 at 8:16 PM Richard Yao <ryao@gentoo.org> wrote:
> > 
> > On 09/14/2018 12:40 PM, Alon Bar-Lev wrote:
> > > On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich <slyfox@gentoo.org> wrote:
> > > > 
> > > > On Tue, 11 Sep 2018 12:44:38 +0300
> > > > Alon Bar-Lev <alonbl@gentoo.org> 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Alon Bar-Lev]

On Fri, Sep 14, 2018 at 8:33 PM Michał Górny <mgorny@gentoo.org> 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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3228 bytes --]

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 <mgorny@gentoo.org> 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Alon Bar-Lev]

On Fri, Sep 14, 2018 at 8:53 PM Michał Górny <mgorny@gentoo.org> 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 <mgorny@gentoo.org> 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

[Rich Freeman]

On Fri, Sep 14, 2018 at 1:33 PM Michał Górny <mgorny@gentoo.org> 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

[Michael Orlitzky]

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

[Richard Yao]

> On Sep 14, 2018, at 3:29 PM, Michael Orlitzky <mjo@gentoo.org> 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

[Michael Orlitzky]

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

[Rich Freeman]

On Fri, Sep 14, 2018 at 4:20 PM Michael Orlitzky <mjo@gentoo.org> 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

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]

On 14-09-2018 16:29:43 -0400, Rich Freeman wrote:
> On Fri, Sep 14, 2018 at 4:20 PM Michael Orlitzky <mjo@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Alon Bar-Lev]

On Sat, Sep 15, 2018 at 12:02 AM Fabian Groffen <grobian@gentoo.org> wrote:
>
> On 14-09-2018 16:29:43 -0400, Rich Freeman wrote:
> > On Fri, Sep 14, 2018 at 4:20 PM Michael Orlitzky <mjo@gentoo.org> 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

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Alon Bar-Lev]

On Sat, Sep 15, 2018 at 12:29 AM Fabian Groffen <grobian@gentoo.org> 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

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 3264 bytes --]

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 <grobian@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Changing policy about -Werror

[Richard Yao]

> On Sep 14, 2018, at 5:28 PM, Fabian Groffen <grobian@gentoo.org> 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

[Alon Bar-Lev]

On Sat, Sep 15, 2018 at 1:14 AM Richard Yao <ryao@gentoo.org> wrote:
> > On Sep 14, 2018, at 5:28 PM, Fabian Groffen <grobian@gentoo.org> 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

[Richard Yao]

> On Sep 14, 2018, at 4:20 PM, Michael Orlitzky <mjo@gentoo.org> 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

[Sergei Trofimovich]

On Fri, 14 Sep 2018 19:40:13 +0300
Alon Bar-Lev <alonbl@gentoo.org> wrote:

> On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich <slyfox@gentoo.org> wrote:
> >
> > On Tue, 11 Sep 2018 12:44:38 +0300
> > Alon Bar-Lev <alonbl@gentoo.org> 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

[Alon Bar-Lev]

On Fri, Sep 14, 2018 at 10:53 PM Sergei Trofimovich <slyfox@gentoo.org> wrote:
>
> On Fri, 14 Sep 2018 19:40:13 +0300
> Alon Bar-Lev <alonbl@gentoo.org> 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

[Sergei Trofimovich]

On Fri, 14 Sep 2018 23:15:28 +0300
Alon Bar-Lev <alonbl@gentoo.org> 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

[gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror

[Chí-Thanh Christopher Nguyễn]

Hi!

So from the discussion I gather that -Werror has both desirable and 
undesirable effects. Question is, can we somehow mitigate the undesirable 
effects while still retaining the desirable effects as much as possible?

Requirements:
* Bother the user enough that they will report the problem, but not enough 
that they will leave Gentoo for another distro, which means:
* Do not fail to build/install when a warning is encountered
* Do not silently install the package anyway when a warning is encountered

Rough suggestion:

1. Introduce a new value in ebuilds for PROPERTIES, named "warningfree" (or 
something similar for RESTRICT if that is preferable).
2. Introduce a new package set, named @broken-warningfree. If a package is in 
this set, emerge will display a notification each time it runs (like with 
@preserved-rebuild).
3. Extend install-qa-check.d/90gcc-warnings so that optionally all compiler 
warnings will be caught
4. If PROPERTIES="warningfree" is set, 90gcc-warnings catches all compiler 
warnings
5. If PROPERTIES="warningfree" is set, and there is a warning caught, add the 
package to the @broken-warningfree set on install
6. If there is no warning caught, remove the package from the 
@broken-warningfree set (if it is currently in there)
7. When ebuild maintainers remove -Werror from a package, they can set 
PROPERTIES="warningfree" at their discretion

Also possible is to introduce FEATURES="strict-warnings" or similar, which 
will cause the build to fail if warnings are encountered in a warningfree 
ebuild. I need to think more how this could work with binpkgs though.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror

[Rich Freeman]

On Wed, Sep 12, 2018 at 7:35 PM Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
>
>
> Requirements:
>
> * Do not fail to build/install when a warning is encountered

On a particularly critical package like a filesystem, wouldn't we want
to still fail to install when a warning is encountered?

> Also possible is to introduce FEATURES="strict-warnings" or similar, which
> will cause the build to fail if warnings are encountered in a warningfree
> ebuild.

I guess this depends on whether warningfree is only used where -Werror
would otherwise be used.  Packages could presumably also warn users
when installing without this feature set not to complain too much if
our defaults destroy their data and to consider setting the flag...
:)

I get that users might quit if packages don't install, but I'm not
sure that a filesystem corruption is going to make them any happier...

-- 
Rich

Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror

[Chí-Thanh Christopher Nguyễn]

Rich Freeman schrieb:
>> Requirements:
>>
>> * Do not fail to build/install when a warning is encountered
> 
> On a particularly critical package like a filesystem, wouldn't we want
> to still fail to install when a warning is encountered?

Installation will proceed, but the user will get a big fat warning that the 
sys-fs/zfs package is potentially broken.

> I get that users might quit if packages don't install, but I'm not
> sure that a filesystem corruption is going to make them any happier...

If the user recognizes this as a critical package, then they can do the 
research before deciding on whether to use the package as is, attempt to 
downgrade, or wait until a fix is released.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror

[Rich Freeman]

On Wed, Sep 12, 2018 at 8:23 PM Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
>
> Rich Freeman schrieb:
> >> Requirements:
> >>
> >> * Do not fail to build/install when a warning is encountered
> >
> > On a particularly critical package like a filesystem, wouldn't we want
> > to still fail to install when a warning is encountered?
>
> Installation will proceed, but the user will get a big fat warning that the
> sys-fs/zfs package is potentially broken.
>
> > I get that users might quit if packages don't install, but I'm not
> > sure that a filesystem corruption is going to make them any happier...
>
> If the user recognizes this as a critical package, then they can do the
> research before deciding on whether to use the package as is, attempt to
> downgrade, or wait until a fix is released.

But, you've ALREADY overwritten the previous version of the package
that presumably didn't have this problem.  What if downgrading doesn't
cause the problem to go away?  What if it is due to some dependency or
toolchain change?  Users would presumably want to roll back to the
binaries that were working just a few minutes ago, not build new ones
that might or might not have the same issue.

-- 
Rich

Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror

[Chí-Thanh Christopher Nguyễn]

Rich Freeman schrieb:
>> If the user recognizes this as a critical package, then they can do the
>> research before deciding on whether to use the package as is, attempt to
>> downgrade, or wait until a fix is released.
> 
> But, you've ALREADY overwritten the previous version of the package
> that presumably didn't have this problem.  What if downgrading doesn't
> cause the problem to go away?  What if it is due to some dependency or
> toolchain change?  Users would presumably want to roll back to the
> binaries that were working just a few minutes ago, not build new ones
> that might or might not have the same issue.

Users could weigh their options and then decide on how to best proceed. In 
case of zfs, they still have time until next reboot to fix this.

Or the maintainer can set PROPERTIES="interactive" in anticipation of such a 
situation and ask "Are you sure you want to install this [y/N]?".


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror

[Mike Auty]

[-- Attachment #1.1: Type: text/plain, Size: 638 bytes --]

Hiya,

On 13/09/2018 01:23, Chí-Thanh Christopher Nguyễn wrote:
> Installation will proceed, but the user will get a big fat warning that
> the sys-fs/zfs package is potentially broken.

This seems like a sure-fire way to make users paranoid and/or
desensitized?  People will learn to ignore warnings if we make them big
red and flashing but then say they're only potential breakages (and they
subsequently discover that most everything runs fine).  If they learn to
ignore big red flashing warnings it'll be more difficult when they're
not potential breakages but actual ones we've accurately identified...

Mike  5:)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror

[Chí-Thanh Christopher Nguyễn]

Mike Auty schrieb:
>> Installation will proceed, but the user will get a big fat warning that
>> the sys-fs/zfs package is potentially broken.
> 
> This seems like a sure-fire way to make users paranoid and/or
> desensitized?  People will learn to ignore warnings if we make them big
> red and flashing but then say they're only potential breakages (and they
> subsequently discover that most everything runs fine).  If they learn to
> ignore big red flashing warnings it'll be more difficult when they're
> not potential breakages but actual ones we've accurately identified...

Maybe "big fat warning" was a bit of an overstatement. I meant the same kind 
of notice that @preserved-rebuild set produces today. Or the "configuration 
files need updating" message.

Much like the aforementioned, the affected package might continue to work 
totally fine, or be broken in subtle ways. It might bother the user enough to 
report a bug, but hopefully not enough to turn them away from Gentoo.

Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror

[Richard Yao]

> On Sep 12, 2018, at 8:23 PM, Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:
> 
> Rich Freeman schrieb:
>>> Requirements:
>>> 
>>> * Do not fail to build/install when a warning is encountered
>> On a particularly critical package like a filesystem, wouldn't we want
>> to still fail to install when a warning is encountered?
> 
> Installation will proceed, but the user will get a big fat warning that the sys-fs/zfs package is potentially broken.

The way that it works is that a user explicitly must enable USE=debug for -Werror to apply. The package itself’s use of -Werror in USE=debug does not prevent corruption issues so much as it detects them because the kernel code is built in userspace. sys-fs/zfs-kmod is what matters for this. USE=debug does not turn on -Werror there because we don’t inject it into the kernel build system. If such a bug is detected and a user proceeds to use the rebuilt kernel module, things could go poorly.

Anyway, I seem to have injected noise into the conversation by bringing this up because the discussion is whether -Werror by default should be allowed. I only commented because I felt that it should be an exception in the case of USE=debug or an explicit USE flag for Werror (e.g. USE=Werror).
> 
>> I get that users might quit if packages don't install, but I'm not
>> sure that a filesystem corruption is going to make them any happier...
> 
> If the user recognizes this as a critical package, then they can do the research before deciding on whether to use the package as is, attempt to downgrade, or wait until a fix is released.
> 
> 
> Best regards,
> Chí-Thanh Christopher Nguyễn
> 

[gentoo-dev] Re: Changing policy about -Werror

[Nikos Chantziaras]

On 09/09/2018 14:32, Andrew Savchenko wrote:
> 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.

Not sure if user feedback is welcome or not, but consider:

A piece of security oriented software gets an update (v2) that closes a 
security hole in v1. User tries to update to v2, but the emerge fails 
because of -Werror. User stays on v1 and thus remains vulnerable.

-Werror achieved the exact opposite of what the intent was.