Re: [gentoo-dev] Changing policy about -Werror
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.
Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror
Rich Freeman schrieb: 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. But, you've ALREADY overwritten the previous version of the package that presumably didn't have this problem. What if downgrading doesn't cause the problem to go away? What if it is due to some dependency or toolchain change? Users would presumably want to roll back to the binaries that were working just a few minutes ago, not build new ones that might or might not have the same issue. Users could weigh their options and then decide on how to best proceed. In case of zfs, they still have time until next reboot to fix this. Or the maintainer can set PROPERTIES="interactive" in anticipation of such a situation and ask "Are you sure you want to install this [y/N]?". Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror
On Wed, 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. > > > 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. But, you've ALREADY overwritten the previous version of the package that presumably didn't have this problem. What if downgrading doesn't cause the problem to go away? What if it is due to some dependency or toolchain change? Users would presumably want to roll back to the binaries that were working just a few minutes ago, not build new ones that might or might not have the same issue. -- Rich
Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror
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
Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror
On Wed, Sep 12, 2018 at 7:35 PM Chí-Thanh Christopher Nguyễn 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
Re: [gentoo-dev] Changing policy about -Werror
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? -- Rich
Re: [gentoo-dev] Changing policy about -Werror
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? -- Rich
Re: [gentoo-dev] Changing policy about -Werror
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.
Re: [gentoo-dev] Changing policy about -Werror
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
[gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror
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
Re: [gentoo-dev] Changing policy about -Werror
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
Re: [gentoo-dev] Changing policy about -Werror
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 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
Re: [gentoo-dev] Changing policy about -Werror
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 Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
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 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 > dilfri...@gentoo.org > Gentoo Linux developer > (council, toolchain, perl, libreoffice, comrel) > > >
Re: [gentoo-dev] Changing policy about -Werror
> 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 dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, perl, libreoffice, comrel)
Re: [gentoo-dev] Changing policy about -Werror
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 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 Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
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 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
[gentoo-dev] The state of libav stabilisation
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 https://bugs.gentoo.org/show_bug.cgi?id=libav-12 [2] https://bugs.gentoo.org/617508 [3] https://bugs.gentoo.org/665518
Re: [gentoo-dev] Changing policy about -Werror
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 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
