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
> 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
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
> 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
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
Hello,
On Thu, 13 Sep 2018, Michal Górny wrote:
># Michal Górny (13 Sep 2018)
># Depends on old version of dev-libs/jsoncpp, blocking its pruning.
># Downstream maintainer is inactive to bump it. Removal in 30 days.
>dev-lang/solidity
As per the "no -Werror" policy, the following patch to the
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
On Thu, 2018-09-13 at 20:55 +0200, Andreas Sturmlechner wrote:
> 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
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 package,
should its maintainer find out it breaks by EAPI-7
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
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
# Michał Górny (30 Oct 2015)
# Uses unsafe ioctls that could result in data corruption. Upstream
# is working on replacing them in the wip/dedup-syscall branch.
# Keep it masked until they are done. sys-fs/duperemove is
# the suggested replacement for the meantime.
# Michał Górny (13 Sep 2018)
#
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
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
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
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
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
On Thu, Jul 26, 2018 at 2:35 AM wrote:
>
> From: David Seifert
>
> * Using the ninja backend as a default is the only way to
> massively improve src_compile core utilization, given that
> it seems unlikely that CMake will ever produce non-recursive
> Makefiles.
I just want to bring your
> 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
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
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
> On Sep 12, 2018, at 8:23 PM, Chí-Thanh Christopher Nguyễn
> 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
> 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
> 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
On 12/09/2018 12:38, Andreas Sturmlechner wrote:
> Is there anyone still working on libav support? It appears to me that
> transition[1] and stabilisation[2] trackers are stuck for a long time without
> activity. Missing libav-12 stabilisation means that in several stable
> packages, USE=libav
---Original Message---
On Thursday, 26 July 2018 at 08:35, s...@gentoo.org wrote:
> From: David Seifert
>
> * Many upstreams build static libraries by default, as this is
> simpler for distribution. Developers can still override this
> variable if required.
>
> Examples:
>
---Original Message---
On Thursday, 26 July 2018 at 08:35, s...@gentoo.org wrote:
> From: David Seifert
>
> * Using the ninja backend as a default is the only way to
> massively improve src_compile core utilization, given that
> it seems unlikely that CMake will ever produce non-recursive
>
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
# Michał Górny (13 Sep 2018)
# Depends on old version of dev-libs/jsoncpp, blocking its pruning.
# Downstream maintainer is inactive to bump it. Removal in 30 days.
dev-lang/solidity
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
32 matches
Mail list logo
