Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On 1/22/2013 05:56, Rich Freeman wrote: On Tue, Jan 22, 2013 at 6:11 AM, viv...@gmail.com viv...@gmail.com wrote: IMHO the number of cases where CONFIG_CHECK is reliable is so small that making it fatal will only bloat make.conf and env with a new var for most users. Tend to agree. I just got an elog out of udisks complaining about USB_SUSPEND not being set, and I have no idea why I'd need that on a system that is powered 24x7. Even the kernel docs suggest that it should be disabled if users aren't sure if they need it. Maybe we need some way to distinguish between must-have and nice-to-have situations? Clearly failure to boot is in a different category than not-able-to-suspend. Rich I agree. During an update recently, I noticed that qemu complains if KVM_INTEL isn't set on an AMD CPU. Making this fatal would be stupid, but then nobody who runs qemu-kvm would ever get a fatal error about missing DEVTMPFS. -- ♫Dustin
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On Thu, Jan 24, 2013 at 1:10 AM, Robin H. Johnson robb...@gentoo.org wrote: On Wed, Jan 23, 2013 at 12:32:40PM +, Fabio Erculiani wrote: I hope this is going to be binary package manager friendly. In Sabayon for instance, kernel sources are not even installed and at the same time, /proc/config.gz may not even be available. There were some corner cases in where pkg_setup failed because this kernel config check stuff was trying to be smarter than the user. That was before we made it possible to have CONFIG_CHECK=~FOO without /proc/config.gz, for the bugs you yourself submitted, and I fixed years ago. I would expect that ALL Sabayon users would have CONFIG_CHECK_FATAL=0, because they run your kernel (if you have your kernel in a package, maybe even distribute a file that triggers it, so anybody else with their own kernel still has the default CONFIG_CHECK_FATAL=1). But we cannot assume that the environment in where packages are built is the same as the environment in where packages are installed and run. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 -- Fabio Erculiani
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
I hope this is going to be binary package manager friendly. In Sabayon for instance, kernel sources are not even installed and at the same time, /proc/config.gz may not even be available. There were some corner cases in where pkg_setup failed because this kernel config check stuff was trying to be smarter than the user. -- Fabio Erculiani
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On Wed, Jan 23, 2013 at 7:32 AM, Fabio Erculiani lx...@gentoo.org wrote: I hope this is going to be binary package manager friendly. In Sabayon for instance, kernel sources are not even installed and at the same time, /proc/config.gz may not even be available. There were some corner cases in where pkg_setup failed because this kernel config check stuff was trying to be smarter than the user. Another issue with this sort of thing is that the kernel in /usr/src/linux might not be the kernel that is running, and the kernel that is running might not be the kernel that is running upon the next boot. I think warnings just make sense, but if we're going to make them fatal then at least print out instructions on how to disable them. I suspect that a large number of users will end up disabling config checks though, in which case this feature will provide a false sense of security. If an upgrade could make a user's system unbootable then we should really be warning them about it BEFORE they merge the package. A news item before the change is committed to portage would be more appropriate. I don't want a fatal error during pkg_setup that isn't fatal for 90% of our users because of all the false alarms to be an excuse for developers to put the blame on the user. That amounts to telling our users that if they don't enable some make.conf option then half of the Gentoo devs will cause their builds to break randomly, and if they do enable it the other half of the Gentoo devs will cause their systems to not boot. Rich
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
I think that the problem is that it is trying to be smart when it's not really possible (unless you want to cover all the corner cases, which is a pain). -- Fabio Erculiani
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
2013/1/23 Fabio Erculiani lx...@gentoo.org I think that the problem is that it is trying to be smart when it's not really possible (unless you want to cover all the corner cases, which is a pain). Hum, but if we could not be smart enough we can at least try to be very annoying. what about a delay of some seconds, exactly like `emerge -C portage` or something very similar? Trying to cover the corner cases but without pretend to be omniscent?
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On Wed, Jan 23, 2013 at 12:32:40PM +, Fabio Erculiani wrote: I hope this is going to be binary package manager friendly. In Sabayon for instance, kernel sources are not even installed and at the same time, /proc/config.gz may not even be available. There were some corner cases in where pkg_setup failed because this kernel config check stuff was trying to be smarter than the user. That was before we made it possible to have CONFIG_CHECK=~FOO without /proc/config.gz, for the bugs you yourself submitted, and I fixed years ago. I would expect that ALL Sabayon users would have CONFIG_CHECK_FATAL=0, because they run your kernel (if you have your kernel in a package, maybe even distribute a file that triggers it, so anybody else with their own kernel still has the default CONFIG_CHECK_FATAL=1). -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On 22 January 2013 03:56, Zac Medico zmed...@gentoo.org wrote:
On 01/21/2013 07:45 PM, Mike Gilbert wrote:
My suspicion is that portage's environment save/restore process will
overwrite any setting I attempt to make on the destination host.
If necessary, you can use /etc/portage/bashrc to override
CONFIG_CHECK_FATAL for binary packages. Something like this would work:
[[ ${EMERGE_FROM} == binary ]] CONFIG_CHECK_FATAL=0
--
Thanks,
Zac
I guess the problem is when you create a binpkg and not when you
install it on the target. wild idea Would it be possible to make
this nonfatal if FEATURES contains binpkg or -B was passed to
emerge?/wild idea
--
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
Il 22/01/2013 04:38, Robin H. Johnson ha scritto:
I'm raising this patch because of the recent spate of bugs with the
latest udev that now fails to boot your system if CONFIG_DEVTMPFS is
not available in your kernel.
Bugs: 408947, 409393, 437320, 453074
CONFIG_CHECK has not been fatal for some years now, because there turned
out to be some cases where it cannot detect what the system really has
[1], or what is returned is wrong [2].
However, while this is has been superb in helping those corner-cases,
the fallout is that users frequently ignore the non-fatal warnings that
a configuration option is needed to run a binary later, and end up with
weird breakage.
This patch introduces a new option, CONFIG_CHECK_FATAL, defaulting to
enabled, that explicitly causes a die if:
- CONFIG_CHECK cannot be performed successfully.
- Any CONFIG_CHECK options fail.
For the aforementioned corner cases, those environments are used to
customizing their make.conf heavily, and they should add:
CONFIG_CHECK_FATAL=0
This patch does NOT change the handling of ~/tilde in CONFIG_CHECK
- options that are required at compile-time MUST NOT use ~/tilde.
- options that are only required at run-time MUST include the ~/tilde.
Footnotes:
1. If you are using a VM environment, where the kernel is provided
outside of your VM, and you don't have kernel sources, or
/proc/config.gz, you CANNOT detect what options the kernel is
configured with.
2. Building stages for example. You may have /proc bind-mounted from the
host system, but it does not reflect the environment you are building
for.
IMHO the number of cases where CONFIG_CHECK is reliable is so small that
making it fatal will only bloat make.conf and env with a new var for
most users.
However this move could make sense if (and only if) CONFIG_CHECK could
reliabily know where it's used.
It could be made fatal for example if all the following conditions are met:
- buildpkg is disabled
- /proc/config.gz (decompressed) is the same as
${KERNEL_BUILD_DIR}/.config and both exists
- /boot is mounted and the bootloader will load the currently running kernel
AIMHO it's very difficult (would say impossible) to implement this in a
cross package manager and reliable way.
So please don't
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On Tue, Jan 22, 2013 at 6:11 AM, viv...@gmail.com viv...@gmail.com wrote: IMHO the number of cases where CONFIG_CHECK is reliable is so small that making it fatal will only bloat make.conf and env with a new var for most users. Tend to agree. I just got an elog out of udisks complaining about USB_SUSPEND not being set, and I have no idea why I'd need that on a system that is powered 24x7. Even the kernel docs suggest that it should be disabled if users aren't sure if they need it. Maybe we need some way to distinguish between must-have and nice-to-have situations? Clearly failure to boot is in a different category than not-able-to-suspend. Rich
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On 01/22/2013 01:22 AM, Markos Chandras wrote:
On 22 January 2013 03:56, Zac Medico zmed...@gentoo.org wrote:
On 01/21/2013 07:45 PM, Mike Gilbert wrote:
My suspicion is that portage's environment save/restore process will
overwrite any setting I attempt to make on the destination host.
If necessary, you can use /etc/portage/bashrc to override
CONFIG_CHECK_FATAL for binary packages. Something like this would work:
[[ ${EMERGE_FROM} == binary ]] CONFIG_CHECK_FATAL=0
--
Thanks,
Zac
I guess the problem is when you create a binpkg and not when you
install it on the target. wild idea Would it be possible to make
this nonfatal if FEATURES contains binpkg or -B was passed to
emerge?/wild idea
The closest thing that PMS has defined is the MERGE_TYPE variable, which
is supported since EAPI 4. This variable has 3 possible values: source,
buildonly, or binary. Ebuilds can detect emerge --buildpkgonly by
checking for [[ ${MERGE_TYPE} == buildonly ]]. However, for normal
--buildpkg or FEATURES=buildpkg, the MERGE_TYPE is source.
--
Thanks,
Zac
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On 01/21/2013 10:22 PM, Sergey Popov wrote: 22.01.2013 08:23, Mike Gilbert wrote: I guess this change is ok, given that I can opt-out fairly easily. Zac's workaround for binary packages makes me feel better too. I am curious, can not this check be added to eclass? Or eclass does not know about type of merged package? Since EAPI 4 we have the MERGE_TYPE variable which has 3 possible values: source, buildonly, or binary. -- Thanks, Zac
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On Tue, Jan 22, 2013 at 06:51:54AM -0800, Zac Medico wrote:
On 01/21/2013 10:22 PM, Sergey Popov wrote:
22.01.2013 08:23, Mike Gilbert wrote:
I guess this change is ok, given that I can opt-out fairly easily. Zac's
workaround for binary packages makes me feel better too.
I am curious, can not this check be added to eclass? Or eclass does not
know about type of merged package?
Since EAPI 4 we have the MERGE_TYPE variable which has 3 possible
values: source, buildonly, or binary.
# MERGE_TYPE = EAPI 4+
# EMERGE_FROM = EAPI 0-3
_frombin=${MERGE_TYPE}${EMERGE_FROM}
[[ ${_frombin//binary} == ${_frombin} ]] [[ ${CONFIG_CHECK_FATAL+set} == set
]] || CONFIG_CHECK_FATAL=1
But probably easier to just set it in bashrc/catalystrc/make.conf
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On 01/21/2013 10:38 PM, Robin H. Johnson wrote: I'm raising this patch because of the recent spate of bugs with the latest udev that now fails to boot your system if CONFIG_DEVTMPFS is not available in your kernel. Bugs: 408947, 409393, 437320, 453074 CONFIG_CHECK has not been fatal for some years now, because there turned out to be some cases where it cannot detect what the system really has [1], or what is returned is wrong [2]. However, while this is has been superb in helping those corner-cases, the fallout is that users frequently ignore the non-fatal warnings that a configuration option is needed to run a binary later, and end up with weird breakage. This patch introduces a new option, CONFIG_CHECK_FATAL, defaulting to enabled, that explicitly causes a die if: - CONFIG_CHECK cannot be performed successfully. - Any CONFIG_CHECK options fail. For the aforementioned corner cases, those environments are used to customizing their make.conf heavily, and they should add: CONFIG_CHECK_FATAL=0 This patch does NOT change the handling of ~/tilde in CONFIG_CHECK - options that are required at compile-time MUST NOT use ~/tilde. - options that are only required at run-time MUST include the ~/tilde. Footnotes: 1. If you are using a VM environment, where the kernel is provided outside of your VM, and you don't have kernel sources, or /proc/config.gz, you CANNOT detect what options the kernel is configured with. 2. Building stages for example. You may have /proc bind-mounted from the host system, but it does not reflect the environment you are building for. How does this variable interact with binpkgs? For example, if I build a package on a system that does not have CONFIG_CHECK_FATAL=0, what happens if I try to install it on a system that does not have a usable kernel config? My suspicion is that portage's environment save/restore process will overwrite any setting I attempt to make on the destination host. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On 01/21/2013 07:45 PM, Mike Gilbert wrote:
My suspicion is that portage's environment save/restore process will
overwrite any setting I attempt to make on the destination host.
If necessary, you can use /etc/portage/bashrc to override
CONFIG_CHECK_FATAL for binary packages. Something like this would work:
[[ ${EMERGE_FROM} == binary ]] CONFIG_CHECK_FATAL=0
--
Thanks,
Zac
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/21/2013 10:56 PM, Zac Medico wrote:
On 01/21/2013 07:45 PM, Mike Gilbert wrote:
My suspicion is that portage's environment save/restore process will
overwrite any setting I attempt to make on the destination host.
If necessary, you can use /etc/portage/bashrc to override
CONFIG_CHECK_FATAL for binary packages. Something like this would work:
[[ ${EMERGE_FROM} == binary ]] CONFIG_CHECK_FATAL=0
does this means I need to start adding export CONFIG_CHECK_FATAL=0 to
my catalystrc?
- -Zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJQ/hFJAAoJEKXdFCfdEflK53UP/3Ngz3yBmkPz6E7sBZhjnJiW
CVaRlXvXs3sSn9zWdAxxVn1Z2z3RP387eb7jEXOoUAyIezwVfBLZIfPXUK8KN8rD
LRSntTv3E1AUpE+N0GlxRGVlKYnDf3g+EAi0M6iEjtcVBxsCNiH+UcmwHvPFp/oN
R4n79qD3jWEMMnm708RqkwKKu+/F4wfpUQe66UhAwd4yFDkndl/lwrtwmgztMjtF
W6V6Z1ZkWg0r0rRTxhuAYwMcYFKunfSzNCnaD72z0d184fwxcSw2N697vAPCXiLp
MbjCENLME3+dk088YvjNoZCCcga+9omsIKDG/gkgTJib4Ibrc028Ut0G1Oyxrx+R
6LzES1GRshlx0W9N+b+CmChffWfaGENXx2sSM5W6yD6eJtxGPw736JxGMQcpSltz
G+z+tLwDbx1rvHDBeAWzSU0k+W6Yx/QJ4L5D1LNaA/S3pEXwU6aK2ipoRpiNrJfC
aRWyJx1KGLF+vhrN70SiFASJyotmQwoFipgHjm5QbBiHn8sK0cq3gf9wb3nLRNoD
Ym7u9plg85y/W1Gme09vqlptMzwymIrCmXQHuBeqwILJ+lsVQBa1rL/0fnMyDftX
GLT35hIWM7OVUufuiKB6xiOLH0h/P9w45wUZBiPzldphd5wYr3TMkZFv4C8Qgc1/
1/h2B65Lw5wfF5SEuVo7
=oVpV
-END PGP SIGNATURE-
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On 01/21/2013 08:10 PM, Rick Zero_Chaos Farina wrote:
On 01/21/2013 10:56 PM, Zac Medico wrote:
On 01/21/2013 07:45 PM, Mike Gilbert wrote:
My suspicion is that portage's environment save/restore process will
overwrite any setting I attempt to make on the destination host.
If necessary, you can use /etc/portage/bashrc to override
CONFIG_CHECK_FATAL for binary packages. Something like this would work:
[[ ${EMERGE_FROM} == binary ]] CONFIG_CHECK_FATAL=0
does this means I need to start adding export CONFIG_CHECK_FATAL=0 to
my catalystrc?
I guess so, if you don't want those fatal config checks to kill your
catalyst builds.
--
Thanks,
Zac
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On 01/21/2013 10:38 PM, Robin H. Johnson wrote: CONFIG_CHECK has not been fatal for some years now, because there turned out to be some cases where it cannot detect what the system really has [1], or what is returned is wrong [2]. However, while this is has been superb in helping those corner-cases, the fallout is that users frequently ignore the non-fatal warnings that a configuration option is needed to run a binary later, and end up with weird breakage. This patch introduces a new option, CONFIG_CHECK_FATAL, defaulting to enabled, that explicitly causes a die if: - CONFIG_CHECK cannot be performed successfully. - Any CONFIG_CHECK options fail. Technical issues aside, I'm conflicted on this. In general, I don't believe in protecting people from shooting themselves. However, I also know how easy it is to ignore elog messages. I guess this change is ok, given that I can opt-out fairly easily. Zac's workaround for binary packages makes me feel better too. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
22.01.2013 08:23, Mike Gilbert wrote: I guess this change is ok, given that I can opt-out fairly easily. Zac's workaround for binary packages makes me feel better too. I am curious, can not this check be added to eclass? Or eclass does not know about type of merged package? -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
