Re: [gentoo-dev] Changing policy about -Werror
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 a general failure. See x86 build.log, https://paste.pound-python.org/show/F1361Zp3aCHJLje8sBRe/ -- 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 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 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. > > > > > > 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. > > > > As an end user of Gentoo, I may not care about "contributing to > > upstream"; I just want the software to compile and install. > > > > 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... I was clearly responding to the "contributing upstream" argument, which has nothing to do with eating data.
Re: [gentoo-dev] Changing policy about -Werror
> 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 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 then applying a change to no longer cause that particular warning (or make it non-fatal if the warning is bogus/harmless). >>> >>> sure, but for upstreams that make this an explicit goal, do we really >>> want to apply additional downstream pataches with the additional >>> complexity that carries for build system (autotools re-generation that >>> might make it unsupported upstream etc) ? >>> >> >> in all fairness, for one of my upstream packages, SKS, we make -Werror >> part of non-release versions but remove it for releases. > This has been what sys-fs/zfs has been doing for years. The USE=-debug builds > get -Werror while USE=-debug builds omit it. I think this is probably the > solution here. USE=debug is meant to help catch bugs, even if some reports > might be false positives. What it means varies on a per-package basis. I > would call catching a security issue helping to catch bugs. There is a typo here. USE=+debug builds get -Werror while USE=-debug omit -Werror. > >> But there are >> certain crypto related packages where you want the ensure it is properly >> handle altogether, in particular where RNG is concerned as there isn't >> really a proper way to test for it afterwards.. for other packages the >> test suite is of great importance.. if the tests are proper there isn't >> a great need, but sadly packages today doesn't really come with proper >> test suits >> >> -- >> Kristian Fiskerstrand >> OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net >> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 >> > >
Re: [gentoo-dev] Changing policy about -Werror
> 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, compiler versions, etc. But >>> that is not the goal anyway. It is examining the situation and taking >>> appropriate action, and then applying a change to no longer cause that >>> particular warning (or make it non-fatal if the warning is bogus/harmless). >> >> sure, but for upstreams that make this an explicit goal, do we really >> want to apply additional downstream pataches with the additional >> complexity that carries for build system (autotools re-generation that >> might make it unsupported upstream etc) ? >> > > in all fairness, for one of my upstream packages, SKS, we make -Werror > part of non-release versions but remove it for releases. This has been what sys-fs/zfs has been doing for years. The USE=-debug builds get -Werror while USE=-debug builds omit it. I think this is probably the solution here. USE=debug is meant to help catch bugs, even if some reports might be false positives. What it means varies on a per-package basis. I would call catching a security issue helping to catch bugs. > But there are > certain crypto related packages where you want the ensure it is properly > handle altogether, in particular where RNG is concerned as there isn't > really a proper way to test for it afterwards.. for other packages the > test suite is of great importance.. if the tests are proper there isn't > a great need, but sadly packages today doesn't really come with proper > test suits > > -- > Kristian Fiskerstrand > OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net > fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 >
Re: [gentoo-dev] Changing policy about -Werror
> 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. So it is useful >>> for integrity too, not just security (although arguably, integrity is part >>> of security). >> This is a misconception, as jer already pointed out. Instead: >> -Werror has forced you to take notice of problems that could have >> resulted in data loss in ZFS ... > > But in general it doesn't say when or how the problems became acute. Assuming > that the warning isn't bogus, it could have been the code relying on > undefined behavior, and the compiler changing the semantics of such behavior, > and introducing an accompanying warning at the same time. This is precisely why every warning is considered a bug and -Werror is set when USE=debug is in use. > > > Best regards, > Chí-Thanh Christopher Nguyễn >
Re: [gentoo-dev] Changing policy about -Werror
> 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 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. >> >> 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 always and then waits for a fix, or fixes it themselves. > Normal people wipe that stuff away and install an operating > system/distribution that doesn't cause them grief in its place. I would like to point out that if -Werror is set by say USE=debug, this is not an issue.
Re: [gentoo-dev] Changing policy about -Werror
> 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 just security (although arguably, integrity is part >> of security). > > This is a misconception, as jer already pointed out. Instead: > > -Werror has forced you to take notice of problems that could have > resulted in data loss in ZFS ... It did. That is why it is used as a debug feature only when USE=debug is set. USE=-debug does not use -Werror. USE=debug on that package is meant for people who want to help upstream catch bugs. > > Also, consider that for -Werror to be "better", you also need -O3 in > order to activate the "proper" compiler checks like "variable set but > never used" ones. I have had “set but never used” errors on -O2. > >> Perhaps we could have another USE flag for -Werror where it is a security >> feature. e.g. USE=strict-compile-checks > > You better run a static code analyser, such as the one you can hook up > with Travis. It usually points out real security problems such as > races, which GCC doesn't do yet, as far as I'm aware. Let alone > trigger with -Werror. We are using Coverity, but there is no one tool that catches all issues such that the compiler’s checks are redundant. > > Fabian > > > -- > Fabian Groffen > Gentoo on a different level
Re: [gentoo-dev] Changing policy about -Werror
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 message by bircoph suggested. I would argue that this depends on the upstream; some upstreams doesn't know the downstream implications of this and are slow at responding at issues. Others are very clear about it and this is the desired behavior; and they actually fix it quickly when reported. There is a difference here, and on some level that is up to maintainer privilege to evaluate the difference. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
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 taking appropriate action, and then applying a change to no longer cause that particular warning (or make it non-fatal if the warning is bogus/harmless). sure, but for upstreams that make this an explicit goal, do we really want to apply additional downstream pataches with the additional complexity that carries for build system (autotools re-generation that might make it unsupported upstream etc) ? 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 message by bircoph suggested. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing policy about -Werror
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 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
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 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. > > > > 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. > > As an end user of Gentoo, I may not care about "contributing to > upstream"; I just want the software to compile and install. > 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... -- Rich
Re: [gentoo-dev] Changing policy about -Werror
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 examining the situation and taking >> appropriate action, and then applying a change to no longer cause that >> particular warning (or make it non-fatal if the warning is bogus/harmless). > > sure, but for upstreams that make this an explicit goal, do we really > want to apply additional downstream pataches with the additional > complexity that carries for build system (autotools re-generation that > might make it unsupported upstream etc) ? > in all fairness, for one of my upstream packages, SKS, we make -Werror part of non-release versions but remove it for releases. But there are certain crypto related packages where you want the ensure it is properly handle altogether, in particular where RNG is concerned as there isn't really a proper way to test for it afterwards.. for other packages the test suite is of great importance.. if the tests are proper there isn't a great need, but sadly packages today doesn't really come with proper test suits -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
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 always and then waits for a fix, or fixes it themselves. Normal people wipe that stuff away and install an operating system/distribution that doesn't cause them grief in its place. This is indeed a problem with -Werror (I mentioned it in a previous message). Tinderboxing as k_f suggested could not possibly cover the vast number of configurations that users have either. An alternative to -Werror could be maybe some kind of "package health" status that would alert users if warnings happened in supposedly warning-free code. Portage already has a "Package triggers severe warnings" QA notice which could be extended for this purpose. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing policy about -Werror
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 then applying a change to no longer cause that > particular warning (or make it non-fatal if the warning is bogus/harmless). sure, but for upstreams that make this an explicit goal, do we really want to apply additional downstream pataches with the additional complexity that carries for build system (autotools re-generation that might make it unsupported upstream etc) ? -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
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 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. 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 then applying a change to no longer cause that particular warning (or make it non-fatal if the warning is bogus/harmless). Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing policy about -Werror
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 part of security). This is a misconception, as jer already pointed out. Instead: -Werror has forced you to take notice of problems that could have resulted in data loss in ZFS ... But in general it doesn't say when or how the problems became acute. Assuming that the warning isn't bogus, it could have been the code relying on undefined behavior, and the compiler changing the semantics of such behavior, and introducing an accompanying warning at the same time. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing policy about -Werror
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 package or > something that is a core dependency. > > 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. > What I'm saying here is mostly that more tinderboxing is a good thing to capture all kinds of issues, and for upstreams being responsive Gentoo is a good way of providing valuable input. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
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 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. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
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 Cc'd. The patch > > committed doesn't change anything installed on the system, if not for > > Werror preventing the code from building. > > 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. As an end user of Gentoo, I may not care about "contributing to upstream"; I just want the software to compile and install. As has been previously stated, people who care can add -Werror to their own CFLAGS. It's quite a bit harder for a user to remove -Werror from the build system, assuming they can even interpret the error output.
Re: [gentoo-dev] Changing policy about -Werror
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 >> committed doesn't change anything installed on the system, if not for >> Werror preventing the code from building. > > 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. > Adding to this, that arch testing for stabilization didn't catch this might say more about our stabilization procedures than the quality of the upstream package (that in this case routinely includes patches to fix these issues). And they are mostly cought in testing (~arch) -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
Ü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 last architecture Cc'd. The patch > > committed doesn't change anything installed on the system, if not > > for > > Werror preventing the code from building. > > 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 always and then waits for a fix, or fixes it themselves. Normal people wipe that stuff away and install an operating system/distribution that doesn't cause them grief in its place. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Changing policy about -Werror
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 system, if not for > Werror preventing the code from building. 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. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
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.
Re: [gentoo-dev] Changing policy about -Werror
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. There are things that upstream absolutely should be setting which make a big difference for security like FORTIFY_SOURCE but hardened already has that set so I get this and thus basically everything would fail to compile. $ gcc -O1 -D_FORTIFY_SOURCE=2 foo.c :0:0: warning: "_FORTIFY_SOURCE" redefined : note: this is the location of the previous definition This all on amd64 too. If we start with other arches or cross compilers or other things then -Werror is just not possible. But you have looked at the issue, decided that it is harmless, and can now make this particular warning non-fatal. Or report upstream, so they can do the Right Thing™ and don't redefine. $ gcc -O1 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 foo.c That is all what is desired. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] [PATCH 0/2] Update libtool and autotools with EAPI7 dependencies
On 9/7/2018 9:46 AM, Brian Evans wrote: > Since these tools are run on a build host, they should be in BDEPENDS > for new EAPIs. > > I've also taken the liberty of declaring what EAPIs are supported as > the lists will need to be adjusted in the future. > > Comments welcome. > > Brian > > > Now committed.. commit 4a0b5227a8b85cc97fee1647587964e6576123ff Author: Brian Evans Date: Mon Sep 10 13:09:05 2018 -0400 eclass: libtool - Update to the latest stable elt-patches As suggested by Chewi on the gentoo-dev ML Signed-off-by: Brian Evans commit fda978185cde8189cfe7acf81079a163dcb78a40 Author: Brian Evans Date: Fri Sep 7 09:37:17 2018 -0400 eclass: autotools - Mark compatible EAPIs and introduce BDEPEND The autotools commands are run on the build host. As such, their packages needs to be in BDEPEND for EAPI 7. Also taking this opportunity to list compatible EAPIs to consider future adjustments. Signed-off-by: Brian Evans commit 5b58f83e6a23b001f6bdd5393e82cc6ab36072d2 Author: Brian Evans Date: Fri Sep 7 09:33:55 2018 -0400 eclass: libtool - Mark compatible EAPIs and introduce BDEPEND The eltpatch command is run on the build host. As such, it needs to be in BDEPEND for EAPI 7. Also taking this opportunity to list compatible EAPIs to consider future adjustments. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changing policy about -Werror
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). This is a misconception, as jer already pointed out. Instead: -Werror has forced you to take notice of problems that could have resulted in data loss in ZFS ... Also, consider that for -Werror to be "better", you also need -O3 in order to activate the "proper" compiler checks like "variable set but never used" ones. > Perhaps we could have another USE flag for -Werror where it is a security > feature. e.g. USE=strict-compile-checks You better run a static code analyser, such as the one you can hook up with Travis. It usually points out real security problems such as races, which GCC doesn't do yet, as far as I'm aware. Let alone trigger with -Werror. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
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 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. Even if upstream was using gentoo (they're not) they'd need to be testing both stable and unstable toolchains since there are frequently warnings that show up in one and not the other and also between gcc/clang. I agree with jer on this, if you want specific warnings to be errors use -Werror=foo or something not a blanket -Werror. There are things that upstream absolutely should be setting which make a big difference for security like FORTIFY_SOURCE but hardened already has that set so I get this and thus basically everything would fail to compile. $ gcc -O1 -D_FORTIFY_SOURCE=2 foo.c :0:0: warning: "_FORTIFY_SOURCE" redefined : note: this is the location of the previous definition This all on amd64 too. If we start with other arches or cross compilers or other things then -Werror is just not possible. -- Jason
