[added the owner of the old list]
Sam Ravnborg wrote:
> The vger postmasters has created linux-kbuild on my request.
>
> The old list at sourceforge had a few issues:
> - it was subscriber-only
> - it were relying on moderation
For me it is ok.
It was subscriber-only because this was a very low
Jesper Juhl wrote:
On 3/6/06, Giacomo A. Catenazzi <[EMAIL PROTECTED]> wrote:
Sam Ravnborg wrote:
sr> Suggestion:
sr> We are now warned about an incompatibility in kbuild and we will
sr> fix this asap. But that you postpone this particular behaviour
sr> change until
Sam Ravnborg wrote:
sr> Suggestion:
sr> We are now warned about an incompatibility in kbuild and we will
sr> fix this asap. But that you postpone this particular behaviour
sr> change until next make release. Maybe you add in this change as
sr> the first thing after the stable relase so
Peter Samuelson wrote:
> * 'or' placed between dependencies functions as a logical OR, and
> takes very low precedence. This complements the implicit AND
> performed between every pair of dependencies.
>
> x or x -> x, for any x
> n or m == m or n -> m
> n or y == y or n -> y
Keith Owens wrote:
>
> On Fri, 04 Jan 2002 16:42:02 +0100,
> "Giacomo A. Catenazzi" <[EMAIL PROTECTED]> wrote:
> >I have some problem with the KBUILD_SRCTREE, and
> >reading the kbuild-2.5 makefile and the CML2, I
> >think I'm not alone.
>
&g
Hello.
I have some problem with the KBUILD_SRCTREE, and
reading the kbuild-2.5 makefile and the CML2, I
think I'm not alone.
I don't like the actual syntax, so I propose some
improvements, and it is difficult to apply in non
gcc cases.
kbuild-2. should set the internal variable
kbuild_scrtree t
Hello.
I just created 'kpatch.sh'.
This bash shell apply automatically multiple kernel patches.
script/patch-kernel already exists in current kernels,
but it has some limit, which I would eliminate.
WARNING: It is in early beta stage: I made very
few tests.
My scripts:
- support all official k
"Eric S. Raymond" wrote:
>
> Linus Torvalds <[EMAIL PROTECTED]>:
> > Eric, this is the _wrong_approach_. I want /local/ files, not global ones.
>
> First: where should the prompt-string definitions for capability
> symbols that occur in multiple port trees live?
Proposal:
the main cml script in
"Eric S. Raymond" wrote:
> There is a third possibility. autoconfigure.sh is going to pass its
> results to cmlconfigure.py in a file with the format of a config.out.
> Right now all those results are symbol bindings (FOO=y, BAR=n).
> Conceivably autoconfigure.sh could also pass a directive like
"Eric S. Raymond" wrote:
>
> CONFIG_UTIL_LINUX=y
> CONFIG_UTIL_LINUX_VERSION=2.11g
> which: no pppd in
>(.:/home/esr/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/sbin/:/usr/sbin:/sbin:/usr/local/sbin:/usr/sbin)
> CONFIG_E2FS=y
> CONFIG_E2FS_VERSION=1.23
> which: no cardmgr in
>(.:/home/esr/b
Hello
After reading again the documentations and playing
again with kbuild I've found:
BUG:
$ make mrproper
$ make mrproper
Error: you must create a .config first
mrproper should not depend on .config (contents and
existance).
COMMENT:
Your documentation is extensive, but I didn't found
t
"Eric S. Raymond" wrote:
>
> Peter Samuelson <[EMAIL PROTECTED]>:
> > [esr]
> > > Besides, right now the configurator has a simple invariant. It will
> > > only accept consistent configurations
> >
> > So you are saying that the old 'vi .config; make oldconfig' trick is
> > officially unsupporte
Horst von Brand wrote:
>
> "Giacomo A. Catenazzi" <[EMAIL PROTECTED]> said:
>
> [...]
>
> > It whould nice also if we include the type of the license (GPL,...).
>
> If it's in-kernel, it is GPLed.
No if it is build into the kernel is GPL or GP
Alan Cox wrote:
>
> > Is there any kernel code that isn't GPLed?
No. Nearly all code is GPL or GPL compatible license.
>
> There are numerous bits that are dual licensed, some which are licensed
> under the BSD non-advertising type license and some of it licensed under the
> X license.
I resi
Alan Cox wrote:
>
> > Another is to be able to generate reports on exactly how much of the kernel
> > is in "Maintained" or "Supported" status. I think it would be worth
> > making this change just so we could know that.
>
> There is no correlation between claimed and actual levels of supported
"Eric S. Raymond" wrote:
>
> This is a proposal for an attribution metadata system in the Linux kernel
> sources. The goal of the system is to make it easy for people reading
> any given piece of code to identify the responsible maintainer. The motivation
> for this proposal is that the present
16 matches
Mail list logo
