Changing policy about -Werror

classic Classic list List threaded Threaded
119 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Richard Yao-2


> On Sep 10, 2018, at 5:48 PM, Richard Yao <[hidden email]> wrote:
>
>
>
>>> On Sep 10, 2018, at 5:27 PM, Kristian Fiskerstrand <[hidden email]> 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
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Mike Gilbert-2
In reply to this post by Rich Freeman
On Mon, Sep 10, 2018 at 5:31 PM Rich Freeman <[hidden email]> wrote:

>
> On Mon, Sep 10, 2018 at 5:01 PM Mike Gilbert <[hidden email]> wrote:
> >
> > On Mon, Sep 10, 2018 at 4:56 PM Kristian Fiskerstrand <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Thomas Deutschmann
In reply to this post by Kristian Fiskerstrand-2
On 2018-09-10 23:04, Kristian Fiskerstrand wrote:
> That it wasn't caught before being stabilized on several arches was
> indeed bad, but that likely says more about our stabilization procedures
> than the quality of the underlying package's upstream choices.

Eh, this depends on architecture. Not a general failure. See x86
build.log, https://paste.pound-python.org/show/F1361Zp3aCHJLje8sBRe/


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


signature.asc (650 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Andreas K. Huettel
In reply to this post by Andrew Savchenko
> 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
[hidden email]
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)



Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Alon Bar-Lev-2
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

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Jason Zaman-2
In reply to this post by Matt Turner-5
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
> <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Rich Freeman
On Wed, Sep 12, 2018 at 4:56 AM Jason Zaman <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Mike Pagano


On 9/12/18 10:50 AM, Rich Freeman wrote:

> On Wed, Sep 12, 2018 at 4:56 AM Jason Zaman <[hidden email]> wrote:
>>
>> Replying to a somewhat random post. There are two separate things here
>> that people are discussing here but are not the same thing.
>
> Three, really...
>
>>
>> 1) We want to know when a package has terrible warnings when installing
>> it so we can report upstream and know that something might have gone
>> wrong.
>
> There is also the case where we want these warnings to block
> installation, because the risk of there being a problem is too great.
>
>>
>> Stick this in your make.conf:
>> PORTAGE_ELOG_SYSTEM="echo save"
>> PORTAGE_ELOG_CLASSES="warn error log qa"
>> I'm pretty sure toralf's tinderbox already has these enabled but all
>> devs should too.
>
> The problem is that this will make the warnings non-fatal.
>
> Do we still tell users not to report these kinds of warnings in
> bugzilla?  If they're the sort we consider serious then we would want
> to know about it so that we can address it, vs just waiting for
> upstream to fix them in a future release.
>
> There might be a better solution than -Werror, such as a flag in an
> ebuild that makes the existing QA warning fatal and tells the user to
> log a bug.
>
Picking random email.

I would like to say I'm glad we can discuss our technical differences
like this with both sides expressing their opinion and reasoning.

I would hope in the future we start with this path and not with
disciplinary action or bugs requesting the removal of commit access.

We're showing here we can bring up our points without handing out "QA
strikes" or some other type of confrontational action.

Mike






signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Andreas K. Huettel
In reply to this post by Richard Yao-2
> 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
[hidden email]
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)



Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Richard Yao-2


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


Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Thomas Deutschmann
In reply to this post by Rich Freeman
On 2018-09-12 16:50, Rich Freeman wrote:
> There is also the case where we want these warnings to block
> installation, because the risk of there being a problem is too great.

I really disagree with that. So many devs have already said multiple
times in this thread that "-Werror" is only turning existing warnings
into fatal errors but "-Werror" itself doesn't add any new checks and
more often requires "-O3" to be useful.

So let's turn this around: Please show us a *real* case within Gentoo
where "-Werror" prevented a real problem which wouldn't otherwise being
noticed. E.g. show us a package which was merged on user's system,
replacing a working previous version of that package causing *real*
problems which could have been prevented if package would have set
"-Werror".

Unless you can do that we don't really need to discuss this. Simply
because everyone interested in "-Werror" *can* set that flag via CFLAGS,
even just per package, whereas the majority, not interested in this,
cannot do the same to filter "-Werror". Nobody advocating for "-Werror"
replied to that fact yet.


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


signature.asc (650 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Rich Freeman
On Wed, Sep 12, 2018 at 6:55 PM Thomas Deutschmann <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Chí-Thanh Christopher Nguyễn
In reply to this post by Alon Bar-Lev-2
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

Reply | Threaded
Open this post in threaded view
|

acceptable alternatives to -Werror, was: Changing policy about -Werror

Chí-Thanh Christopher Nguyễn
In reply to this post by Andrew Savchenko
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

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Chí-Thanh Christopher Nguyễn
In reply to this post by Thomas Deutschmann
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

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Matt Turner-5
In reply to this post by Rich Freeman
On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Rich Freeman
In reply to this post by Chí-Thanh Christopher Nguyễn
On Wed, Sep 12, 2018 at 7:32 PM Chí-Thanh Christopher Nguyễn
<[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Rich Freeman
In reply to this post by Matt Turner-5
On Wed, Sep 12, 2018 at 7:52 PM Matt Turner <[hidden email]> wrote:

>
> On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: acceptable alternatives to -Werror, was: Changing policy about -Werror

Rich Freeman
In reply to this post by Chí-Thanh Christopher Nguyễn
On Wed, Sep 12, 2018 at 7:35 PM Chí-Thanh Christopher Nguyễn
<[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

123456