On Thu, 2005-09-22 at 10:46 +0200, Paul de Vrieze wrote:
> On Wednesday 21 September 2005 19:52, Chris Gianelloni wrote:
> > On Wed, 2005-09-21 at 17:47 +0100, John Mylchreest wrote:
> > > anyways). After much deliberation I feel the actual best way to deal
> > > with this, is to have an override e
On Wed, Sep 21, 2005 at 05:47:09PM +0100, John Mylchreest wrote:
> First of all, falling back on `uname -r` isn't going to happen for
> several reasons. I can understand for some why this might seem sensible
> (what happens if you remove your kernel sources for example). But the
> fact remains that
On Wednesday 21 September 2005 19:52, Chris Gianelloni wrote:
> On Wed, 2005-09-21 at 17:47 +0100, John Mylchreest wrote:
> > anyways). After much deliberation I feel the actual best way to deal
> > with this, is to have an override envvar which will bypass a die, and
> > simply warn instead. This
On Wednesday 21 September 2005 10:33 am, Henrik Brix Andersen wrote:
> What about the other issue which was brought up? Ebuilds enheriting
> linux-info.eclass requires a configured kernel source? Personally, I
> don't see anything wrong with that, if the above solution is
> implemented (non-fatal c
On Wed, 2005-09-21 at 17:47 +0100, John Mylchreest wrote:
> anyways). After much deliberation I feel the actual best way to deal
> with this, is to have an override envvar which will bypass a die, and
> simply warn instead. This will mean that those people who cross-compile
> regularly, or building
On Wed, 2005-09-21 at 12:03 -0400, Chris Gianelloni wrote:
> The current /usr/src/linux method works quite well for releases. The
> only issue we're having is a non-fatal check being fatal, which is going
> to be fixed.
OK, so being the huy who wrote and looks after all this stuff, here is
my 2c
On Wed, 2005-09-21 at 17:05 +0200, Martin Schlemmer wrote:
> > > The only real argument is that it makes it difficult for people who cross
> > > compile packages for use on other systems only, in which case it might
> > > make
> > > sense for the possibility to override the behaviour.
> >
> > Cro
On Wed, 2005-09-21 at 16:33 +0200, Henrik Brix Andersen wrote:
> What about the other issue which was brought up? Ebuilds enheriting
> linux-info.eclass requires a configured kernel source? Personally, I
> don't see anything wrong with that, if the above solution is
> implemented (non-fatal checks
On Wed, 2005-09-21 at 09:26 -0400, Chris Gianelloni wrote:
> On Wed, 2005-09-21 at 14:17 +0100, Daniel Drake wrote:
> > Quoting Georgi Georgiev <[EMAIL PROTECTED]>:
> > > I can only think of a couple of solution:
> > >
> > > - Remove these unnecessary checks completely: Follow the example of all
>
On Wed, 2005-09-21 at 10:27 +0200, Paul de Vrieze wrote:
> On Wednesday 21 September 2005 09:42, Georgi Georgiev wrote:
> >
> > * Determining the location of the kernel source code
> > * Unable to find kernel sources at /usr/src/linux
> > * This package requires Linux sources.
> > * Please make
On Wed, Sep 21, 2005 at 10:22:08AM -0400, Chris Gianelloni wrote:
> I see absolutely no problem with that, so long as it is a warning.
>
> I mean, you can make it beep, pause, display in flashing red lights and
> email [EMAIL PROTECTED] about it for all I care, but it shouldn't *die* on
> somethin
On Wed, 2005-09-21 at 16:57 +0300, Alin Nastac wrote:
> Chris Gianelloni wrote:
>
> >CONFIG_PPP is *not* required to build ppp, so it shouldn't be in the
> >ebuild as a requirement.
> >
> >
> >
> I agree with this statement but I also see the warning as a must.
> user should be warned that its k
Chris Gianelloni wrote:
>CONFIG_PPP is *not* required to build ppp, so it shouldn't be in the
>ebuild as a requirement.
>
>
>
I agree with this statement but I also see the warning as a must.
user should be warned that its kernel does not support CONFIG_PPP or,
depending on activefilter flag, CO
On Wed, 2005-09-21 at 14:17 +0100, Daniel Drake wrote:
> Quoting Georgi Georgiev <[EMAIL PROTECTED]>:
> > I can only think of a couple of solution:
> >
> > - Remove these unnecessary checks completely: Follow the example of all
> > other distributions and do not depend on anything kernel-ish for
On Wednesday 21 September 2005 15:11, Chris Gianelloni wrote:
> On Wed, 2005-09-21 at 06:43 -0500, Andrew Gaffney wrote:
> > Paul de Vrieze wrote:
> > > I kindof wonder why it doesn't try the sources of the running
> > > kernel. They are easilly found at "/lib/modules/`uname -v`/build".
> > > Of co
On Wed, 2005-09-21 at 06:43 -0500, Andrew Gaffney wrote:
> Paul de Vrieze wrote:
> > I kindof wonder why it doesn't try the sources of the running kernel. They
> > are easilly found at "/lib/modules/`uname -v`/build". Of course as a
>
> You mean `uname -r` :)
Also, that only works if ppp is a m
Quoting Georgi Georgiev <[EMAIL PROTECTED]>:
> I can only think of a couple of solution:
>
> - Remove these unnecessary checks completely: Follow the example of all
> other distributions and do not depend on anything kernel-ish for such
> packages. A recompilation of the kernel with different o
Paul de Vrieze wrote:
I kindof wonder why it doesn't try the sources of the running kernel. They
are easilly found at "/lib/modules/`uname -v`/build". Of course as a
You mean `uname -r` :)
--
Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/
Gentoo Linux Developer
On Wed, Sep 21, 2005 at 04:42:49PM +0900, Georgi Georgiev wrote:
> The linux-info.eclass is used by a few packages to check for appropriate
> kernel configuration options.
[snip]
This is basically bug #103878 :)
> What do you people think the proper solution is?
I suggest adding a $CONFIG_WARN
Georgi Georgiev wrote:
>I can only think of a couple of solution:
>
>- Remove these unnecessary checks completely: Follow the example of all
> other distributions and do not depend on anything kernel-ish for such
> packages. A recompilation of the kernel with different options can
> easily caus
maillog: 21/09/2005-10:27:21(+0200): Paul de Vrieze types
> On Wednesday 21 September 2005 09:42, Georgi Georgiev wrote:
> >
> > * Determining the location of the kernel source code
> > * Unable to find kernel sources at /usr/src/linux
> > * This package requires Linux sources.
> > * Please mak
On Wednesday 21 September 2005 09:42, Georgi Georgiev wrote:
>
> * Determining the location of the kernel source code
> * Unable to find kernel sources at /usr/src/linux
> * This package requires Linux sources.
> * Please make sure that /usr/src/linux points at your running kernel,
> * (or the
On Wed, 21 Sep 2005 16:42:49 +0900
Georgi Georgiev <[EMAIL PROTECTED]> wrote:
> I can only think of a couple of solution:
>
> - Remove these unnecessary checks completely: Follow the example of
> all other distributions and do not depend on anything kernel-ish for
> such packages. A recompilation
The linux-info.eclass is used by a few packages to check for appropriate
kernel configuration options.
Now, packages that install kernel modules, i.e. packages that inherit
linux-mod.eclass are right to check for those options in pkg_setup and
abort unless these are available. After all, these pac
24 matches
Mail list logo
