On Sat, Sep 22, 2018 at 1:33 AM Chí-Thanh Christopher Nguyễn
wrote:
>
> Richard Yao schrieb:
>
> >> To make code behave differently it needs substantial amount of code
> >> to provide you an example. You need to him O2<->O3 behaviour delta
> >> after all. But I will try (for a different warning, i
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 a
On Fri, 14 Sep 2018 23:15:28 +0300
Alon Bar-Lev wrote:
> > > > Unused variable is a good example of typical benign warning:
> > > > it was there all the time, it's not a new bug and does not
> > > > warrant need for an immediate fix.
> > >
> > > Unused variable is a good example of CRITICAL pot
> On Sep 14, 2018, at 7:07 PM, Sergei Trofimovich wrote:
>
> On Fri, 14 Sep 2018 11:54:57 -0400
> Richard Yao wrote:
>
My read of this is that the warning occurs regardless of optimization
level, but it could somehow be improved by optimization.
As for the last, it is f
On Fri, 14 Sep 2018 11:54:57 -0400
Richard Yao wrote:
> >> My read of this is that the warning occurs regardless of optimization
> >> level, but it could somehow be improved by optimization.
> >>
> >> As for the last, it is for uninitialized variable reads. However, I think
> >> you are misint
On Sat, Sep 15, 2018 at 1:14 AM Richard Yao wrote:
> > On Sep 14, 2018, at 5:28 PM, Fabian Groffen wrote:
> >
> > On 15-09-2018 00:07:12 +0300, Alon Bar-Lev wrote:
> >>>
> >>> Perhaps, if one persists on going this route, only do this for platforms
> >>> that upstream supports, such that arches w
I think you misunderstood what I wrote, or I wasn't clear enough.
Richard summed up my intention nicely in his response.
Fabian
On 15-09-2018 00:46:24 +0300, Alon Bar-Lev wrote:
> On Sat, Sep 15, 2018 at 12:29 AM Fabian Groffen wrote:
> >
> > On 15-09-2018 00:07:12 +0300, Alon Bar-Lev wrote:
> >
> On Sep 14, 2018, at 5:28 PM, Fabian Groffen wrote:
>
> On 15-09-2018 00:07:12 +0300, Alon Bar-Lev wrote:
>>>
>>> Perhaps, if one persists on going this route, only do this for platforms
>>> that upstream supports, such that arches which will suffer from this
>>> (typically ppc, sparc, ...)
> On Sep 14, 2018, at 4:20 PM, Michael Orlitzky wrote:
>
> On 09/14/2018 03:58 PM, Richard Yao wrote:
>>>
>>> No one has answered the question: what do you do when a stable package
>>> breaks because of a new warning?
>>>
>>> ...>
>> Wouldn’t this be largely covered as part of GCC stabilizati
On Sat, Sep 15, 2018 at 12:29 AM Fabian Groffen wrote:
>
> On 15-09-2018 00:07:12 +0300, Alon Bar-Lev wrote:
> > >
> > > Perhaps, if one persists on going this route, only do this for platforms
> > > that upstream supports, such that arches which will suffer from this
> > > (typically ppc, sparc,
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 t
On Sat, Sep 15, 2018 at 12:02 AM Fabian Groffen wrote:
>
> On 14-09-2018 16:29:43 -0400, Rich Freeman wrote:
> > On Fri, Sep 14, 2018 at 4:20 PM Michael Orlitzky wrote:
> > >
> > > On 09/14/2018 03:58 PM, Richard Yao wrote:
> > > >>
> > > >> No one has answered the question: what do you do when a
On 14-09-2018 16:29:43 -0400, Rich Freeman wrote:
> On Fri, Sep 14, 2018 at 4:20 PM Michael Orlitzky wrote:
> >
> > On 09/14/2018 03:58 PM, Richard Yao wrote:
> > >>
> > >> No one has answered the question: what do you do when a stable package
> > >> breaks because of a new warning?
> > >>
> > >>
On Fri, Sep 14, 2018 at 4:20 PM Michael Orlitzky wrote:
>
> On 09/14/2018 03:58 PM, Richard Yao wrote:
> >>
> >> No one has answered the question: what do you do when a stable package
> >> breaks because of a new warning?
> >>
> >> ...>
> > Wouldn’t this be largely covered as part of GCC stabiliza
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
On Fri, Sep 14, 2018 at 10:53 PM Sergei Trofimovich wrote:
>
> On Fri, 14 Sep 2018 19:40:13 +0300
> Alon Bar-Lev wrote:
>
> >
> > No dependency of toolchain nor annotations.
> > A strict policy of no warnings will require changes as dependencies
> > including toolchain are progressing.
> > This c
> On Sep 14, 2018, at 3:29 PM, Michael Orlitzky wrote:
>
>> On 09/14/2018 01:52 PM, Rich Freeman wrote:
>>
>> Wouldn't the flip side of this be demonstrating that this has actually
>> caused issues? If following upstream discovers no bugs and also
>> causes no issues, why not leave it to mai
On Fri, 14 Sep 2018 19:40:13 +0300
Alon Bar-Lev wrote:
> On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich wrote:
> >
> > On Tue, 11 Sep 2018 12:44:38 +0300
> > Alon Bar-Lev wrote:
> >
> > I'm personally in favour of not allowing -Werror
> > to be in build system unconditionally.
> >
> > Main
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
On Fri, Sep 14, 2018 at 8:53 PM Michał Górny wrote:
>
> On Fri, 2018-09-14 at 20:48 +0300, Alon Bar-Lev wrote:
> > On Fri, Sep 14, 2018 at 8:33 PM Michał Górny wrote:
> >
> > > > Let's do this the other way around and be react based on facts and not
> > > > speculations.
> > > > Let's change the
On 09/13/2018 07:36 AM, Richard Yao wrote:
>
>
>> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann wrote:
>>
>>> On 2018-09-12 16:50, Rich Freeman wrote:
>>> There is also the case where we want these warnings to block
>>> installation, because the risk of there being a problem is too great.
>>
>
On Fri, 2018-09-14 at 20:48 +0300, Alon Bar-Lev wrote:
> On Fri, Sep 14, 2018 at 8:33 PM Michał Górny wrote:
>
> > > Let's do this the other way around and be react based on facts and not
> > > speculations.
> > > Let's change the policy for a year for selected packages as I
> > > outlined, monit
On Fri, Sep 14, 2018 at 1:33 PM Michał Górny wrote:
>
> On Fri, 2018-09-14 at 20:22 +0300, Alon Bar-Lev wrote:
> > Let's do this the other way around and be react based on facts and not
> > speculations.
> > Let's change the policy for a year for selected packages as I
> > outlined, monitor bugs a
On Fri, Sep 14, 2018 at 8:33 PM Michał Górny wrote:
> > Let's do this the other way around and be react based on facts and not
> > speculations.
> > Let's change the policy for a year for selected packages as I
> > outlined, monitor bugs and after a year see response times, affected
> > users and
On 09/13/2018 12:03 PM, Fabian Groffen wrote:
> On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
>>
>>
>>> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann wrote:
>>>
On 2018-09-12 16:50, Rich Freeman wrote:
There is also the case where we want these warnings to block
installation, b
On Fri, 2018-09-14 at 20:22 +0300, Alon Bar-Lev wrote:
> On Fri, Sep 14, 2018 at 8:16 PM Richard Yao wrote:
> >
> > On 09/14/2018 12:40 PM, Alon Bar-Lev wrote:
> > > On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich
> > > wrote:
> > > >
> > > > On Tue, 11 Sep 2018 12:44:38 +0300
> > > > Alon
On Fri, Sep 14, 2018 at 1:22 PM Alon Bar-Lev wrote:
>
> Let's do this the other way around and be react based on facts and not
> speculations.
> Let's change the policy for a year for selected packages as I
> outlined, monitor bugs and after a year see response times, affected
> users and if downs
On Fri, Sep 14, 2018 at 8:16 PM Richard Yao wrote:
>
> On 09/14/2018 12:40 PM, Alon Bar-Lev wrote:
> > On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich
> > wrote:
> >>
> >> On Tue, 11 Sep 2018 12:44:38 +0300
> >> Alon Bar-Lev wrote:
> >>
> >> I'm personally in favour of not allowing -Werror
On 09/14/2018 12:40 PM, Alon Bar-Lev wrote:
> On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich wrote:
>>
>> On Tue, 11 Sep 2018 12:44:38 +0300
>> Alon Bar-Lev wrote:
>>
>> I'm personally in favour of not allowing -Werror
>> to be in build system unconditionally.
>>
>> Maintainer is free to imp
On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich wrote:
>
> On Tue, 11 Sep 2018 12:44:38 +0300
> Alon Bar-Lev wrote:
>
> I'm personally in favour of not allowing -Werror
> to be in build system unconditionally.
>
> Maintainer is free to implement --enable-werror any way
> it's convenient to ru
> On Sep 13, 2018, at 11:35 PM, Matt Turner wrote:
>
> On Thu, Sep 13, 2018 at 5:44 PM Richard Yao wrote:
>>> On Sep 13, 2018, at 7:21 PM, Matt Turner wrote:
>>>
>>> On Thu, Sep 13, 2018 at 4:13 PM Richard Yao wrote:
> On Sep 13, 2018, at 12:03 PM, Fabian Groffen wrote:
>
>>
On Thu, Sep 13, 2018 at 5:44 PM Richard Yao wrote:
> > On Sep 13, 2018, at 7:21 PM, Matt Turner wrote:
> >
> > On Thu, Sep 13, 2018 at 4:13 PM Richard Yao wrote:
> >>> On Sep 13, 2018, at 12:03 PM, Fabian Groffen wrote:
> >>>
> On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
>
>
On 14.09.2018 at 0:44 user Richard Yao wrote:
> This is a really odd design decision by the GCC developers. With other
> compilers, the separation between front end and backend is strong enough that
> you will never have this sort of thing. It does not seem necessary to me
> either. :/
You mig
> On Sep 13, 2018, at 7:21 PM, Matt Turner wrote:
>
> On Thu, Sep 13, 2018 at 4:13 PM Richard Yao wrote:
>>> On Sep 13, 2018, at 12:03 PM, Fabian Groffen wrote:
>>>
On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
>> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann
>>>
On 13.09.2018 at 16:20 user Fabian Groffen wrote:
>> > To illustrate harmless:
>> > warning: this statement may fall through [-Wimplicit-fallthrough=]
>> > The warning message already has it in it that it's just a pure guess.
>>
>> One that exposed a lot of unintentional fallthoughs which were f
On Thu, Sep 13, 2018 at 4:13 PM Richard Yao wrote:
> > On Sep 13, 2018, at 12:03 PM, Fabian Groffen wrote:
> >
> >> On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
> >>
> >>
> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann
> wrote:
>
> On 2018-09-12 16:50, Rich Freeman wro
> On Sep 13, 2018, at 12:03 PM, Fabian Groffen wrote:
>
>> On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
>>
>>
On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann wrote:
On 2018-09-12 16:50, Rich Freeman wrote:
There is also the case where we want these warnings to block
On Tue, 11 Sep 2018 12:44:38 +0300
Alon Bar-Lev wrote:
I'm personally in favour of not allowing -Werror
to be in build system unconditionally.
Maintainer is free to implement --enable-werror any way
it's convenient to run on their own extended sanity checks
and optionally expose it to users. Be
On Thu, Sep 13, 2018 at 7:20 PM Fabian Groffen wrote:
> > > To illustrate harmless:
> > > warning: this statement may fall through [-Wimplicit-fallthrough=]
> > > The warning message already has it in it that it's just a pure guess.
> >
> > One that exposed a lot of unintentional fallthoughs whi
On 13-09-2018 18:56:13 +0300, Alon Bar-Lev wrote:
> On Thu, Sep 13, 2018 at 6:51 PM Fabian Groffen wrote:
> >
> > On 12-09-2018 17:46:03 -0700, Matt Turner wrote:
> > > On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman wrote:
> > > With new GCC comes new warnings, and harmless as the vast majority are
On 12-09-2018 20:09:54 -0400, Rich Freeman wrote:
> On Wed, Sep 12, 2018 at 7:32 PM Chí-Thanh Christopher Nguyễn
> wrote:
> >
> > Alon Bar-Lev schrieb:
> > > We
> > > are unique as permutations and architectures that are used by Gentoo
> > > users are so diverse that we find issues that nobody els
On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
>
>
> > On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann wrote:
> >
> >> On 2018-09-12 16:50, Rich Freeman wrote:
> >> There is also the case where we want these warnings to block
> >> installation, because the risk of there being a problem is too
On Thu, Sep 13, 2018 at 6:51 PM Fabian Groffen wrote:
>
> On 12-09-2018 17:46:03 -0700, Matt Turner wrote:
> > On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman wrote:
> > With new GCC comes new warnings, and harmless as the vast majority are
> > they cause the build to break with Werror.
>
> To illus
On 12-09-2018 17:46:03 -0700, Matt Turner wrote:
> On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman wrote:
> >
> > On Wed, Sep 12, 2018 at 7:52 PM Matt Turner wrote:
> > >
> > > On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman wrote:
> > > > Now, I could buy that -Werror turns NEW warnings into fatal er
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 fil
> 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
On 9/13/18 9:35 AM, Rich Freeman wrote:
> On Thu, Sep 13, 2018 at 9:29 AM Mike wrote:
>>
>> And I apologize for writing that commit rights were requested to be
>> removed. My mistake, bugzilla access rights were asked to be removed.
>> ...
>>
>> I'm not a fan of more and more and more regulatio
On Thu, Sep 13, 2018 at 9:29 AM Mike wrote:
>
> And I apologize for writing that commit rights were requested to be
> removed. My mistake, bugzilla access rights were asked to be removed.
>...
>
> I'm not a fan of more and more and more regulation that I see. Sorry if
> you don't like that opini
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
> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann wrote:
>
>> On 2018-09-12 16:50, Rich Freeman wrote:
>> There is also the case where we want these warnings to block
>> installation, because the risk of there being a problem is too great.
>
> I really disagree with that. So many devs have al
> 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 b
On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman wrote:
>
> On Wed, Sep 12, 2018 at 7:52 PM Matt Turner wrote:
> >
> > On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman wrote:
> > > Now, I could buy that -Werror turns NEW warnings into fatal errors,
> > > due to the use of a newer toolchain, since upstre
On Wed, Sep 12, 2018 at 7:52 PM Matt Turner wrote:
>
> On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman wrote:
> > Now, I could buy that -Werror turns NEW warnings into fatal errors,
> > due to the use of a newer toolchain, since upstream probably didn't
> > test with that toolchain and thus wouldn't
On Wed, Sep 12, 2018 at 7:32 PM Chí-Thanh Christopher Nguyễn
wrote:
>
> Alon Bar-Lev schrieb:
> > We
> > are unique as permutations and architectures that are used by Gentoo
> > users are so diverse that we find issues that nobody else finds.
>
> This needs to be highlighted more, as it is why sug
On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman wrote:
> Now, I could buy that -Werror turns NEW warnings into fatal errors,
> due to the use of a newer toolchain, since upstream probably didn't
> test with that toolchain and thus wouldn't have seen the warning.
Yes, exactly. This is one of the majo
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
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 ins
On Wed, Sep 12, 2018 at 6:55 PM Thomas Deutschmann wrote:
>
> On 2018-09-12 16:50, Rich Freeman wrote:
> > There is also the case where we want these warnings to block
> > installation, because the risk of there being a problem is too great.
>
> I really disagree with that. So many devs have alrea
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 e
On Sep 12, 2018, at 4:28 PM, Andreas K. Huettel wrote:
>> If a package really ought to have
>> -Werror due to a very good reason and is properly maintained to support it,
>> then there is nothing wrong with inventing a USE flag to give users the
>> option of enforcing that.
>
> There is somet
> 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 -Werro
On 9/12/18 10:50 AM, Rich Freeman wrote:
> On Wed, Sep 12, 2018 at 4:56 AM Jason Zaman wrote:
>>
>> Replying to a somewhat random post. There are two separate things here
>> that people are discussing here but are not the same thing.
>
> Three, really...
>
>>
>> 1) We want to know when a packa
On Wed, Sep 12, 2018 at 4:56 AM Jason Zaman wrote:
>
> Replying to a somewhat random post. There are two separate things here
> that people are discussing here but are not the same thing.
Three, really...
>
> 1) We want to know when a package has terrible warnings when installing
> it so we can
On Mon, Sep 10, 2018 at 01:51:15PM -0700, Matt Turner wrote:
> On Mon, Sep 10, 2018 at 1:34 PM Chí-Thanh Christopher Nguyễn
> wrote:
> >
> > Jason Zaman schrieb:
> > >> No. With -Werror, upstream indicates that if a warning occurs, the build
> > >> should fail and the resulting code not be install
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
> 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 o
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
On Mon, Sep 10, 2018 at 5:31 PM Rich Freeman wrote:
>
> On Mon, Sep 10, 2018 at 5:01 PM Mike Gilbert wrote:
> >
> > On Mon, Sep 10, 2018 at 4:56 PM Kristian Fiskerstrand
> > wrote:
> > >
> > > On 9/10/18 10:51 PM, Matt Turner wrote:
> > > > Consider again the bug that started this. The maintain
> On Sep 10, 2018, at 5:48 PM, Richard Yao wrote:
>
>
>
>>> On Sep 10, 2018, at 5:27 PM, Kristian Fiskerstrand wrote:
>>>
On 9/10/18 11:21 PM, Kristian Fiskerstrand wrote:
On 9/10/18 11:19 PM, Chí-Thanh Christopher Nguyễn wrote:
It is indeed an insurmountable task to write c
> On Sep 10, 2018, at 5:27 PM, Kristian Fiskerstrand wrote:
>
>> On 9/10/18 11:21 PM, Kristian Fiskerstrand wrote:
>>> On 9/10/18 11:19 PM, Chí-Thanh Christopher Nguyễn wrote:
>>> It is indeed an insurmountable task to write code that is warning-free
>>> from the beginning across architectures
> On Sep 10, 2018, at 5:18 PM, Chí-Thanh Christopher Nguyễn
> wrote:
>
> Fabian Groffen schrieb:
>>> On 09-09-2018 11:22:41 -0400, Richard Yao wrote:
>>> -Werror has caught bugs that could have resulted in data loss in ZFS in the
>>> past thanks to it being built in userspace as part of zdb.
> On Sep 10, 2018, at 4:59 PM, Mart Raudsepp wrote:
>
> Ühel kenal päeval, E, 10.09.2018 kell 22:56, kirjutas Kristian
> Fiskerstrand:
>>> On 9/10/18 10:51 PM, Matt Turner wrote:
>>> Consider again the bug that started this. The maintainer had not
>>> built
>>> this configuration. None of the
> On Sep 10, 2018, at 10:19 AM, Fabian Groffen wrote:
>
>> On 09-09-2018 11:22:41 -0400, Richard Yao wrote:
>> -Werror has caught bugs that could have resulted in data loss in ZFS in the
>> past thanks to it being built in userspace as part of zdb. So it is useful
>> for integrity too, not j
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 messag
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 takin
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
On Mon, Sep 10, 2018 at 5:01 PM Mike Gilbert wrote:
>
> On Mon, Sep 10, 2018 at 4:56 PM Kristian Fiskerstrand wrote:
> >
> > On 9/10/18 10:51 PM, Matt Turner wrote:
> > > Consider again the bug that started this. The maintainer had not built
> > > this configuration. None of the arch teams had bu
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 examin
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 alwa
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
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 p
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
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 pack
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
On Mon, Sep 10, 2018 at 4:56 PM Kristian Fiskerstrand wrote:
>
> On 9/10/18 10:51 PM, Matt Turner wrote:
> > Consider again the bug that started this. The maintainer had not built
> > this configuration. None of the arch teams had built this
> > configuration until I did for the last architecture
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
>
Ü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 l
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 sys
On Mon, Sep 10, 2018 at 1:34 PM Chí-Thanh Christopher Nguyễn
wrote:
>
> Jason Zaman schrieb:
> >> No. With -Werror, upstream indicates that if a warning occurs, the build
> >> should fail and the resulting code not be installed on user systems.
> >>
> >> Instead, someone knowledgeable should look
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
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).
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
On Sun, Sep 9, 2018 at 1:50 PM Michael Orlitzky wrote:
>
> So if you're using -Werror to prevent a
> "vulnerable" package from being installed, it doesn't work, and can
> actually be harmful if it prevents me from using a better compiler.
>
Whether or not the new compiler is better, i
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 un
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 ins
On Sun, Sep 9, 2018 at 4:32 AM Andrew Savchenko wrote:
>
> Hi!
>
> Our current -Werror policy demands unconditional removal:
> https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed
>
> I think this is wrong, see bugs 665464, 665538 for a recent
>
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
> discussi
> On Sep 9, 2018, at 1:09 PM, Richard Yao wrote:
>
>
>
>> On Sep 9, 2018, at 12:11 PM, Michał Górny wrote:
>>
>> On Sun, 2018-09-09 at 11:22 -0400, Richard Yao wrote:
On Sep 9, 2018, at 7:32 AM, Andrew Savchenko wrote:
Hi!
Our current -Werror policy demands uncon
On Sep 9, 2018, at 12:32 PM, Ulrich Mueller wrote:
>> On Sun, 09 Sep 2018, Andrew Savchenko wrote:
>
>> What I'm trying to do is to allow maintainers to keep -Werror if
>> they really want to do this, understand what they are doing and
>> have enough manpower to support this.
>
> Bug 665
> On Sep 9, 2018, at 12:11 PM, Michał Górny wrote:
>
> On Sun, 2018-09-09 at 11:22 -0400, Richard Yao wrote:
>>> On Sep 9, 2018, at 7:32 AM, Andrew Savchenko wrote:
>>>
>>> Hi!
>>>
>>> Our current -Werror policy demands unconditional removal:
>>> https://devmanual.gentoo.org/ebuild-writing/
1 - 100 of 108 matches
Mail list logo
