Re: [gentoo-dev] Changing policy about -Werror
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 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 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
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 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
Re: [gentoo-dev] Changing policy about -Werror
> 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 >> 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
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 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
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 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
> 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
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
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 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] Last rites: dev-lang/solidity
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 ebuild, or
something to the same effect should be done anyway, and it compiles
without '-Werror'.
--- a/solidity-0.4.18.ebuild 2017-12-20 21:09:16.0 +0100
+++ b/solidity-0.4.18.ebuild 2018-09-13 15:59:06.584892127 +0200
@@ -28,6 +28,11 @@
"${FILESDIR}"/${P}-fix-cmake-external-jsoncpp.diff
)
+src_prepare() {
+ sed -i '/add_compile_options(-Werror)/d' cmake/EthCompilerSettings.cmake
+ cmake-utils_src_prepare
+}
+
src_configure() {
local mycmakeargs=(
"-DBoost_USE_STATIC_LIBS=off"
HTH,
-dnh
--
| Ceci n'est pas une pipe
[gentoo-dev] Re: Changing policy about -Werror
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.
Re: [gentoo-dev] [PATCH 1/2] cmake-utils.eclass: Make ninja default backend in EAPI >= 7
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 overridden by package, > should its maintainer find out it breaks by EAPI-7 bump. > ...and soon enough we end up tracking packages whose default backend needed to be changed because the maintainer had to workaround bugs in a particular ninja version. Am I the only one who misses the times when programmers made working software and tried to fix bugs rather than releasing whatever satisfies some internal use case, and ignoring bugs that didn't affect it? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/2] cmake-utils.eclass: Make ninja default backend in EAPI >= 7
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 bump.
Re: [gentoo-dev] Changing policy about -Werror
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 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
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 > > > 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 signature.asc Description: PGP signature
[gentoo-dev] Last rites: sys-fs/bedup
# 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) # No upstream commits since 2016. Removal in 30 days. Bug #546144. sys-fs/bedup -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Changing policy about -Werror
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 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
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 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
signature.asc
Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
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 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
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 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
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 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 1/2] cmake-utils.eclass: Make ninja default backend in EAPI >= 7
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 attention to this bug comment, which would indicate a regression in the kitware branch of ninja that I was asked to merge by the Gentoo cmake maintainers. https://bugs.gentoo.org/663384#c1 If this comment proves to have the right conclusion, I will likely revert back to the vanilla upstream codebase until the kitware branch can be fixed. This may effect your plans to enable ninja by default, since it will break any fortran package.
Re: [gentoo-dev] Changing policy about -Werror
> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
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 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. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
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 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
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. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror
> 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 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 >
Re: [gentoo-dev] Changing policy about -Werror
> 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 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
> 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 signature.asc Description: PGP signature
[gentoo-dev] Re: The state of libav stabilisation
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 is already inaccessible without manual unmasking of the > use flag. I am not prepared to start reverting upstream commits for support[3]. > > If this is not going to change, maybe media-video/libav should be dropped to > ~arch. This is still better than dropping support per-package or plastering > package.use.stable.mask with libav entries. > > [1] https://bugs.gentoo.org/show_bug.cgi?id=libav-12 > [2] https://bugs.gentoo.org/617508 > [3] https://bugs.gentoo.org/665518 > > > I guess nobody had time to, libav-12 is working correctly on those arches. Thanks for reminding us. lu
Re: [gentoo-dev] [PATCH 2/2] cmake-utils.eclass: Enable BUILD_SHARED_LIBS by default in EAPI >= 7
---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:
> https://github.com/pezmaster31/bamtools/blob/master/CMakeLists.txt#L64
> ---
> eclass/cmake-utils.eclass | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> index ed81426ddcc..f180c8c3d7d 100644
> --- a/eclass/cmake-utils.eclass
> +++ b/eclass/cmake-utils.eclass
> @@ -623,6 +623,7 @@ cmake-utils_src_configure() {
> if [[ ${EAPI} != [56] ]]; then
> cat >> "${common_config}" <<- _EOF_ || die
> SET (CMAKE_INSTALL_DOCDIR
> "${EPREFIX}/usr/share/doc/${PF}" CACHE PATH "")
> + SET (BUILD_SHARED_LIBS ON CACHE BOOLEAN "")
> _EOF_
> fi
>
> --
> 2.18.0
works for me.
Re: [gentoo-dev] [PATCH 1/2] cmake-utils.eclass: Make ninja default backend in EAPI >= 7
---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
> Makefiles.
>
> For a benchmark, see:
> http://www.kaizou.org/2016/09/build-benchmark-large-c-project/
> ---
> eclass/cmake-utils.eclass | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> index e64502b3b9b..ed81426ddcc 100644
> --- a/eclass/cmake-utils.eclass
> +++ b/eclass/cmake-utils.eclass
> @@ -53,7 +53,8 @@ _CMAKE_UTILS_ECLASS=1
> # @DESCRIPTION:
> # Specify a makefile generator to be used by cmake.
> # At this point only "emake" and "ninja" are supported.
> -: ${CMAKE_MAKEFILE_GENERATOR:=emake}
> +# In EAPI 7 and above, the default is set to "ninja",
> +# whereas in EAPIs below 7, it is set to "emake".
>
> # @ECLASS-VARIABLE: CMAKE_MIN_VERSION
> # @DESCRIPTION:
> @@ -112,8 +113,13 @@ esac
> inherit toolchain-funcs ninja-utils flag-o-matic multiprocessing xdg-utils
>
> case ${EAPI} in
> - 7) ;;
> - *) inherit eapi7-ver eutils multilib ;;
> + [56])
> + : ${CMAKE_MAKEFILE_GENERATOR:=emake}
> + inherit eapi7-ver eutils multilib
> + ;;
> + *)
> + : ${CMAKE_MAKEFILE_GENERATOR:=ninja}
> + ;;
> esac
>
> EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test src_install
> --
> 2.18.0
+1 fwiw, I've been testing this in an overlay branch and it seems to work fine
so far (no ninja related errors on those packages I rebuilt).
Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror
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:) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-lang/solidity
# 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
