I am starting to think that the real problem is that Gentoo does not
have ebuilds for building kernels (binary kernels). At that point, it
would be easy to add USE flags and virtual packages to solve the
config check problem at the dependencies level once and for all.
--
Fabio Erculiani
Fabio Erculiani posted on Sat, 26 Jan 2013 10:34:25 + as excerpted:
I am starting to think that the real problem is that Gentoo does not
have ebuilds for building kernels (binary kernels). At that point, it
would be easy to add USE flags and virtual packages to solve the config
check
What I always wondered is why we have ebuilds for every kind of binary
except for kernels, yet we build official kernels with official
configs for our livecds.
--
Fabio Erculiani
On Sat, Jan 26, 2013 at 5:30 PM, Fabio Erculiani lx...@gentoo.org wrote:
What I always wondered is why we have ebuilds for every kind of binary
except for kernels, yet we build official kernels with official
configs for our livecds.
Yup. I don't think the solution is to have a USE flag for
Rich Freeman wrote:
having a standardized kernel with a few flags probably isn't a bad idea.
That doesn't scale at all. Suggest instead take a .config as input to
the emerge, maybe something like savedconfig for busybox, and add
shortcuts for common options.
That way, the same mechanism can be
On Sat, Jan 26, 2013 at 7:31 PM, Peter Stuge pe...@stuge.se wrote:
Rich Freeman wrote:
having a standardized kernel with a few flags probably isn't a bad idea.
That doesn't scale at all. Suggest instead take a .config as input to
the emerge, maybe something like savedconfig for busybox, and
On Fri, Jan 25, 2013 at 1:24 PM, Nuno J. Silva nunojsi...@ist.utl.pt wrote:
Is there any syntax to check if something is either disabled or built as
a module?
Very problematic. What is built in for the currently running kernel
can be fairly reliably determined by grepping /proc/config.gz - IF
On Fri, 25 Jan 2013 13:47:05 -0500
Rich Freeman ri...@gentoo.org wrote:
Very problematic. What is built in for the currently running kernel
can be fairly reliably determined by grepping /proc/config.gz - IF
support for that was enabled in the kernel. But, there is no
guarantee that this
On Fri, Jan 25, 2013 at 2:19 PM, Christopher Head ch...@chead.ca wrote:
Surely even that isn’t good enough, since the user could have built an
option as a module, tested it out, discovered it worked fine, and then
rebuilt the kernel with the option set to Y, but the .ko file would
still be
On 2013-01-25, Rich Freeman wrote:
On Fri, Jan 25, 2013 at 1:24 PM, Nuno J. Silva nunojsi...@ist.utl.pt wrote:
Is there any syntax to check if something is either disabled or built as
a module?
Very problematic. What is built in for the currently running kernel
can be fairly reliably
On Fri, Jan 25, 2013 at 2:47 PM, Nuno J. Silva nunojsi...@ist.utl.pt wrote:
Sorry, what's the difference between cheching =y and =m? I thought those
were both part of the kernel config...
I'm talking about /proc/config.gz, which only reflects .config at the
time that the kernel was built. So,
On 2013-01-25, Rich Freeman wrote:
On Fri, Jan 25, 2013 at 2:47 PM, Nuno J. Silva nunojsi...@ist.utl.pt wrote:
Sorry, what's the difference between cheching =y and =m? I thought those
were both part of the kernel config...
I'm talking about /proc/config.gz, which only reflects .config at
On Fri, Jan 25, 2013 at 3:06 PM, Nuno J. Silva nunojsi...@ist.utl.pt wrote:
Well, we could also get rid of issues with clashing USE flags by getting
rid of USE flags and offering monolithic binary packages with almost
every compatible feature enabled by default.
I'm not suggesting that we get
Nuno J. Silva posted on Fri, 25 Jan 2013 22:06:35 +0200 as excerpted:
I am almost sure the current check does *not* use config.gz but
/usr/src/linux/.config. At least, I've not had config.gz enabled for a
long time, and I've always seen the checks working. In fact, I think the
checks print
Rich Freeman posted on Tue, 22 Jan 2013 06:56:08 -0500 as excerpted:
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
On Thu, Jan 24, 2013 at 12:49 PM, Duncan 1i5t5.dun...@cox.net wrote:
That said, presumably udisks would choose not to make its check fatal,
altho changing the default to fatal could complicate things for existing
ebuilds until they're fixed.
That was basically my whole point - it can't be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 24/01/13 01:09 PM, Rich Freeman wrote:
On Thu, Jan 24, 2013 at 12:49 PM, Duncan 1i5t5.dun...@cox.net
wrote:
That said, presumably udisks would choose not to make its check
fatal, altho changing the default to fatal could complicate
things
On 1/24/2013 12:18, Ian Stakenvicius wrote:
On 24/01/13 01:09 PM, Rich Freeman wrote:
On Thu, Jan 24, 2013 at 12:49 PM, Duncan 1i5t5.dun...@cox.net
wrote:
That said, presumably udisks would choose not to make its check
fatal, altho changing the default to fatal could complicate
things for
On Thu, Jan 24, 2013 at 1:18 PM, Ian Stakenvicius a...@gentoo.org wrote:
a fatal die in pkg_pretend could be circumvented by an environment
variable such as ${PN}_I_KNOW_WHAT_IM_DOING being set. Just a thought.
If we're going to do this I'd definitely have the ${PN} bit as you
suggested.
On 01/24/13 13:25, Rich Freeman wrote:
On Thu, Jan 24, 2013 at 1:18 PM, Ian Stakenvicius a...@gentoo.org wrote:
a fatal die in pkg_pretend could be circumvented by an environment
variable such as ${PN}_I_KNOW_WHAT_IM_DOING being set. Just a thought.
If we're going to do this I'd definitely
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 24/01/13 01:55 PM, Michael Orlitzky wrote:
On 01/24/13 13:25, Rich Freeman wrote:
On Thu, Jan 24, 2013 at 1:18 PM, Ian Stakenvicius
a...@gentoo.org wrote:
a fatal die in pkg_pretend could be circumvented by an
environment variable such as
On Thu, Jan 24, 2013 at 1:58 PM, Ian Stakenvicius a...@gentoo.org wrote:
How about, you know what you're doing and are going to build a new
kernel as soon as the emerge finishes (since the emerge is also
bringing in a new gentoo-sources)??
Or my earlier example - USB_SUSPEND and such. If
On 01/24/13 13:58, Ian Stakenvicius wrote:
How about, you know what you're doing and are going to build a new
kernel as soon as the emerge finishes (since the emerge is also
bringing in a new gentoo-sources)??
If you're going to upgrade both anyway, you should be upgrading the
kernel
Il 24/01/2013 20:21, Michael Orlitzky ha scritto:
On 01/24/13 13:58, Ian Stakenvicius wrote:
How about, you know what you're doing and are going to build a new
kernel as soon as the emerge finishes (since the emerge is also
bringing in a new gentoo-sources)??
If you're going to upgrade both
On 01/24/13 15:26, viv...@gmail.com wrote:
If you're going to upgrade both anyway, you should be upgrading the
kernel first. That way if you lose power or the system crashes, the box
can reboot.
which can be the exact opposite order if instead you have to _disable_ a
feature in the kernel
On 01/24/13 15:39, Michael Orlitzky wrote:
On 01/24/13 15:26, viv...@gmail.com wrote:
If you're going to upgrade both anyway, you should be upgrading the
kernel first. That way if you lose power or the system crashes, the box
can reboot.
which can be the exact opposite order if instead you
On Thu, Jan 24, 2013 at 2:21 PM, Michael Orlitzky mich...@orlitzky.com wrote:
On 01/24/13 13:58, Ian Stakenvicius wrote:
How about, you know what you're doing and are going to build a new
kernel as soon as the emerge finishes (since the emerge is also
bringing in a new gentoo-sources)??
Il 24/01/2013 21:45, Michael Orlitzky ha scritto:
On 01/24/13 15:39, Michael Orlitzky wrote:
On 01/24/13 15:26, viv...@gmail.com wrote:
If you're going to upgrade both anyway, you should be upgrading the
kernel first. That way if you lose power or the system crashes, the box
can reboot.
On 01/24/13 19:29, viv...@gmail.com wrote:
actually it wasn't an issue that could made a system un-bootable but was
like this:
* udev-129 could live with CONFIG_SYSFS_DEPRECATED=y
* udev-130 require CONFIG_SYSFS_DEPRECATED not set
The example was given just to underline the fact that a
Michael Orlitzky posted on Thu, 24 Jan 2013 13:55:46 -0500 as excerpted:
On 01/24/13 13:25, Rich Freeman wrote:
On Thu, Jan 24, 2013 at 1:18 PM, Ian Stakenvicius a...@gentoo.org
wrote:
a fatal die in pkg_pretend could be circumvented by an environment
variable such as
On Fri, Jan 25, 2013 at 01:39:08AM +, Duncan wrote:
Meanwhile, my vote is for a NON-FATAL pkg_pretend warning. That gets run
at the beginning when people are still likely to be watching, so should
be good enough. Beyond that, gentoo can't keep the obtuse from ignoring
the warnings, so
On 01/24/2013 08:39 PM, Duncan wrote:
Now I've chosen to set that using package.env so it applies only to glibc,
but I imagine many users have it set in their make.conf, because a lot of
packages use it, and they were forced to set it for one or another at
some point.
Using package.env
On Thu, Jan 24, 2013 at 9:22 PM, Michael Orlitzky mich...@orlitzky.com wrote:
Using package.env is preferable, since it basically exists in lieu of
prefixing every environment variable with $PN. But I don't particularly
care about the details. I was just curious if there are real cases where
On 01/24/2013 10:12 PM, Rich Freeman wrote:
Otherwise we're just finding creative ways to drive away users. Sure,
we can call them stupid on their way out the door, but while I can't
speak for anybody else, I'm mainly here because I'd like to do some
good, and I wouldn't mind it if I found
Michael Orlitzky posted on Thu, 24 Jan 2013 21:22:10 -0500 as excerpted:
On 01/24/2013 08:39 PM, Duncan wrote:
Meanwhile, my vote is for a NON-FATAL pkg_pretend warning. That gets
run at the beginning when people are still likely to be watching, so
should be good enough. Beyond that,
Sergey Popov posted on Tue, 22 Jan 2013 10:22:34 +0400 as excerpted:
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?
36 matches
Mail list logo
