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
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,
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
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
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
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
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
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
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
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
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
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
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,
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
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
-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
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
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
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,
19 matches
Mail list logo
