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
> 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
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
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
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:
>
When matching EPYTHON, it would previously call sed and set
any_fixed=1 even though it was already correct. If all are correct, it
is supposed to raise a QA warning/error.
---
eclass/python-utils-r1.eclass | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
There's no need for two separate sed calls here.
---
eclass/python-utils-r1.eclass | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index e3cf82b4b58f..121f2382ba78 100644
--- a/eclass/python-utils-r1.eclass
+++
> 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
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
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
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
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
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
> 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
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.
> >
> >
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,
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
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
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,
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
> > > >
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
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
> On Sep 13, 2018, at 8:54 PM, Georg Rudoy <0xd34df...@gmail.com> wrote:
>
>> On 14.09.2018 at 0:44 user Richard Yao wrote:
>> This is a really odd design decision by the GCC developers. With other
>> compilers, the separation between front end and backend is strong enough
>> that you will
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
> 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:
>
>>
Il 13/09/18 20:55, Andreas Sturmlechner ha scritto:
> On Donnerstag, 13. September 2018 16:25:13 CEST Mike Gilbert wrote:
>> This may effect your plans to enable ninja by default, since it will
>> break any fortran package.
> Not much concerned about that; backend default can be overridden by
33 matches
Mail list logo
