Richard B. Johnson scripsit:
> FYI, I have never known a problem that python has solved, only
> changed.
The same can be said of computers in general.
--
John Cowan http://www.ccil.org/~cowan [EMAIL PROTECTED]
Please leave your values| Check your assumption
On Tue, Dec 04, 2001 at 06:30:45PM +0100, Christoph Hellwig wrote:
> On Tue, Dec 04, 2001 at 11:18:38AM -0600, Michael Elizabeth Chastain wrote:
> > As far as CML2 versus an mconfig-based solution, I am tilted towards CML2,
> > as it is simply a better language. I would be happy with either choic
[Cc: list trimmed]
Tom Rini wrote:
>
> [... The spec for CML2 is
> out there, and there's even a CML2-in-C project. If you don't want to
> use Python, go help (I believe Greg Banks is who ESR mentioned is in
> charge of it) that project out [...]
In charge of it? I *am* it. At least, I wa
On Tue, Dec 04, 2001 at 05:44:19PM +, Alan Cox <[EMAIL PROTECTED]> wrote:
| > After CML2 has proven itself in 2.5, I do plan to go back to Marcelo
| > and lobby for him accepting it into 2.4, on the grounds that doing so
| > will simplify his maintainance task no end. That's why I'm tracking
On December 4, 2001 06:50 pm, Daniel Phillips wrote:
> On December 4, 2001 05:52 pm, Giacomo Catenazzi wrote:
> > I don't think esr changed non problematic rules, but one:
> > all rules without help become automatically dependent to
> > CONFIG_EXPERIMENTAL. I don't like it, but I understand why
>
On Tue, 4 Dec 2001 19:54:41 -0500,
Ghozlane Toumi <[EMAIL PROTECTED]> wrote:
>in arch/i386/Makefile.defs.config
>why do you use code like
>
>ifneq ($(subst n,,$(CONFIG_M386)),)
> CFLAGS += -march=i386
>endif
>
>rather than
>
>ifeq($(CONFIG_M386),y)
> CFLAGS += -march=i386
>endif
ifeq(,y) onl
Hi Keith, all...
in arch/i386/Makefile.defs.config
why do you use code like
ifneq ($(subst n,,$(CONFIG_M386)),)
CFLAGS += -march=i386
endif
rather than
ifeq($(CONFIG_M386),y)
CFLAGS += -march=i386
endif
?
I fail to see in what way the ifeq break any cml{1,2} rule ...
thanks,
ghoz
_
On Wed, Dec 05, 2001 at 10:00:32AM +1100, Keith Owens wrote:
> On Tue, 4 Dec 2001 18:21:15 + (GMT),
> Alan Cox <[EMAIL PROTECTED]> wrote:
> >> make bzlilo modules modules_install: it would be a simble
> >> make install: (and you configure with CML1/CML2 what install
> >> means).
> >
> >How do
On Wed, 5 Dec 2001 00:05:53 +0100,
David Weinehall <[EMAIL PROTECTED]> wrote:
>Would it be easy to add hooks for make-rpm and make-kpkg and alike,
>as methods for make installable?
I don't want details for any packaging method in kbuild. kbuild's job
is to build and install the kernel, not wrap
On Tue, 4 Dec 2001, Dave Jones wrote:
> On Tue, 4 Dec 2001, Eric S. Raymond wrote:
>
> > After CML2 has proven itself in 2.5, I do plan to go back to Marcelo
> > and lobby for him accepting it into 2.4, on the grounds that doing so
> > will simplify his maintainance task no end.
> > ...
> > I'm
On Tue, Dec 04, 2001 at 08:53:11PM +0100, Dave Jones wrote:
> On Tue, 4 Dec 2001, David Weinehall wrote:
>
> > "So anyone happy with an older distro that didn't ship gcc-2.95.x, x > 2
> > gets screwed when they want to build a newer kernel. Nice."
>
> The difference being that recommended compil
On Tue, 2001-12-04 at 12:43, Dave Jones wrote:
> On Tue, 4 Dec 2001, Eric S. Raymond wrote:
>
> > After CML2 has proven itself in 2.5, I do plan to go back to Marcelo
> > and lobby for him accepting it into 2.4, on the grounds that doing so
> > will simplify his maintainance task no end.
> > ...
On Tue, 4 Dec 2001, Eric S. Raymond wrote:
> Alan Cox <[EMAIL PROTECTED]>:
> > > I'm pretty sure that's true any more, Alan. Red Hat shipped Python 2 in
> > > 7.1, so the RPM-based distros like KRUD and Mandrake have had it for
> > > seven months. Debian had it before that.
> >
> > RH shippe
On Tue, Dec 04, 2001 at 06:43:17PM +0100, Dave Jones wrote:
> On Tue, 4 Dec 2001, Eric S. Raymond wrote:
>
> > After CML2 has proven itself in 2.5, I do plan to go back to Marcelo
> > and lobby for him accepting it into 2.4, on the grounds that doing so
> > will simplify his maintainance task no
On Tue, Dec 04, 2001 at 01:43:20PM -0500, Eric S. Raymond wrote:
> David Weinehall <[EMAIL PROTECTED]>:
> > Yeah, let's lose the dependencies on perl, make, awk, sed, ld, ar,
> > nm, strip, objcopy, objdump, depmod, grep, xargs, find, gzip,
> > wish, tcl/tk and possibly others. That'd surely shave
On Tue, 2001-12-04 at 13:01, Alan Cox wrote:
> Feel free. You'll find python v1. There is a very early python2 on the
> optional power tools CD that some folks will have but downloaders generally
> dont bother with.
Also, I don't think any version of RedHat has Tkinter 2.0 yet ...
Rober
On Tue, Dec 04, 2001 at 06:08:57PM +0100, RaúlNúñez de Arenas Coronado wrote:
> Hi Matthias :)
>
> >Creating a dependency on Python? Is a non-issue.
>
> Maybe for you. For me it *is* an issue. I don't like more and
> more dependencies for the kernel. I mean, if I can drop kbuild and
> ke
On Tue, 4 Dec 2001 18:21:15 + (GMT),
Alan Cox <[EMAIL PROTECTED]> wrote:
>> make bzlilo modules modules_install: it would be a simble
>> make install: (and you configure with CML1/CML2 what install
>> means).
>
>How does it handle that when install means different things on each box of
>a set
> Are we not talking about the 2.5 kernel build tree? My understanding of the
> numbering of kernels is that the 2.4.x tree is stable; and the 2.5.x tree is
> the new development tree
Erik is talking about crapping in both trees, as opposed to 2.5 only
___
> > That's been the case all along, sans python2. Newer kernels need newer
> > tools. That's always been the case.
>
> Not during stable releases. In fact we've jumped through hoops several
times
> to try and keep egcs built kernels working
Are we not talking about the 2.5 kernel build tree? My u
> > So anyone perfectly happy with an older distro that didn't
> > ship python2-and-whatever-else gets screwed when they want to
> > build a newer kernel. Nice.
>
> That's been the case all along, sans python2. Newer kernels need newer
> tools. That's always been the case.
Not during stable rele
On 4 Dec 2001, Edward Muller wrote:
> That's been the case all along, sans python2. Newer kernels need newer
> tools. That's always been the case.
Between major versions yes. Not within the same stable release.
Dave
--
| Dave Jones.http://www.codemonkey.org.uk
| SuSE Labs
__
On Tue, 4 Dec 2001, David Weinehall wrote:
> "So anyone happy with an older distro that didn't ship gcc-2.95.x, x > 2
> gets screwed when they want to build a newer kernel. Nice."
The difference being that recommended compiler versions don't
change midway through a stable series. Neither should
Rik van Riel <[EMAIL PROTECTED]>:
> Ohhh, that sounds a lot like "I'm not the maintainer, I'm
> not responsible for the code I submit" ;)))
I will provide stable code and be responsible for its stability. It will be
Marcelo's call, not mine, on whether the strategic tradeoffs come out
in favor
On Tue, 4 Dec 2001, Martin Dalecki wrote:
> "Eric S. Raymond" wrote:
> >
> > Alan Cox <[EMAIL PROTECTED]>:
> > > > Creating a dependency on Python? Is a non-issue. Current systems that
> > > > are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python
> > > > is nice and it does not
On Tue, 4 Dec 2001, Eric S. Raymond wrote:
> > Don't do it!
> > A stable kernel should be stable also on the building tools.
>
> That will be Marcelo's call, not mine.
Ohhh, that sounds a lot like "I'm not the maintainer, I'm
not responsible for the code I submit" ;)))
*runs like hell*
Rik
--
On Tue, Dec 04, 2001 at 01:48:13PM -0500, Eric S. Raymond wrote:
> Tom Rini <[EMAIL PROTECTED]>:
> > I think one of the large arguments against CML2 right now is that it
> > needs Python 2.0+ to work, instead of 1.5.x. IIRC, back in the
> > begining, 1.5.x was used but then switched to 2.0 becaus
Tom Rini <[EMAIL PROTECTED]>:
> I think one of the large arguments against CML2 right now is that it
> needs Python 2.0+ to work, instead of 1.5.x. IIRC, back in the
> begining, 1.5.x was used but then switched to 2.0 because it allowed for
> a lot of code to be dropped.
>
> Eric, would it be no
I think one of the large arguments against CML2 right now is that it
needs Python 2.0+ to work, instead of 1.5.x. IIRC, back in the
begining, 1.5.x was used but then switched to 2.0 because it allowed for
a lot of code to be dropped.
Eric, would it be not-too-painful to either go back to 1.5.x m
David Weinehall <[EMAIL PROTECTED]>:
> Yeah, let's lose the dependencies on perl, make, awk, sed, ld, ar,
> nm, strip, objcopy, objdump, depmod, grep, xargs, find, gzip,
> wish, tcl/tk and possibly others. That'd surely shave a lot of diskspace
> off my buildsystem. It's not like I use any of them
Tom Rini <[EMAIL PROTECTED]>:
> > Maybe for you. For me it *is* an issue. I don't like more and
> > more dependencies for the kernel. I mean, if I can drop kbuild and
> > keep on building the kernel with the old good 'make config' I won't
> > worry, but otherwise I don't think that kernel buil
On Tue, Dec 04, 2001 at 06:26:27PM +, Alan Cox wrote:
> > > > Python2 - which means most users dont have it.
> >
> > Most users sure as hell shouldn't be playing with 2.5.x right now
> > anyways. With any sort of 'luck' it'll be 6 months at least before
> > 2.5.x becomes stable enough that i
On Tue, Dec 04, 2001 at 07:00:37PM +0100, Giacomo Catenazzi wrote:
> I agree.
> In this manner distributions can also build a version that don't
> need python2 (IIRC the freeze tool convert python to C program
> which require only few python libs.
>
> Eric if you want I can build a .deb package i
On Tue, Dec 04, 2001 at 06:21:15PM +, Alan Cox wrote:
> > make bzlilo modules modules_install: it would be a simble
> > make install: (and you configure with CML1/CML2 what install
> > means).
>
> How does it handle that when install means different things on each box of
> a set of them NFS s
On Tue, Dec 04, 2001 at 06:08:57PM +0100, Ra?l N??ez de Arenas Coronado wrote:
> Hi Matthias :)
>
> >Creating a dependency on Python? Is a non-issue.
>
> Maybe for you. For me it *is* an issue. I don't like more and
> more dependencies for the kernel. I mean, if I can drop kbuild and
> k
On Tuesdayen den 4 December 2001 18.08, RaúlNúñez de Arenas Coronado wrote:
> Hi Matthias :)
>
> >Creating a dependency on Python? Is a non-issue.
>
> Maybe for you. For me it *is* an issue. I don't like more and
> more dependencies for the kernel. I mean, if I can drop kbuild and
> k
> > > Python2 - which means most users dont have it.
>
> Most users sure as hell shouldn't be playing with 2.5.x right now
> anyways. With any sort of 'luck' it'll be 6 months at least before
> 2.5.x becomes stable enough that it will probably compile all the time
> again and not have a random f
On Tue, Dec 04, 2001 at 06:27:26PM +0100, Martin Dalecki wrote:
> Alan Cox wrote:
> >
> > > Creating a dependency on Python? Is a non-issue. Current systems that
> > > are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python
> > > is nice and it does not create such unmaintainable
> make bzlilo modules modules_install: it would be a simble
> make install: (and you configure with CML1/CML2 what install
> means).
How does it handle that when install means different things on each box of
a set of them NFS sharing the kernel tree. This is a real world example
Michael Elizabeth Chastain wrote:
> [mailing lists trimmed]
>
> Christoph Hellwig writes:
>
>>Indepenand of wether 2.6 will use CML1 or CML2 I hope it won't ship with
>>the actual config tool. It's so much nicer to have mconfig compiled once
>>in /usr/bin instead of compiling menuconfig all th
On December 4, 2001 05:52 pm, Giacomo Catenazzi wrote:
> I don't think esr changed non problematic rules, but one:
> all rules without help become automatically dependent to
> CONFIG_EXPERIMENTAL. I don't like it, but I understand why
> he makes this decision.
I love it.
--
Daniel
_
"Eric S. Raymond" wrote:
>
> Alan Cox <[EMAIL PROTECTED]>:
> > > Creating a dependency on Python? Is a non-issue. Current systems that
> > > are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python
> > > is nice and it does not create such unmaintainable mess. Whether
> >
> > Pyth
Alan Cox wrote:
>
> > Creating a dependency on Python? Is a non-issue. Current systems that
> > are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python
> > is nice and it does not create such unmaintainable mess. Whether
>
> Python2 - which means most users dont have it.
And th
> > RH shipped python2 beginning RH 7.2.
>
> Eh? I'm going to go check my old 7.1 CDs...
Feel free. You'll find python v1. There is a very early python2 on the
optional power tools CD that some folks will have but downloaders generally
dont bother with.
Trust me, I went through the same pain w
[EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> It's not the CML1 language spec that interests me, just the user
> interface. All I care about is being able to do make menuconfig and
> make oldconfig, and get the same results as before. What goes on
> "under the surface" doesn't interest me at all.
>
[mailing lists trimmed]
Christoph Hellwig writes:
> Indepenand of wether 2.6 will use CML1 or CML2 I hope it won't ship with
> the actual config tool. It's so much nicer to have mconfig compiled once
> in /usr/bin instead of compiling menuconfig all the time in the tree.
I agree, it's really a
Alan Cox <[EMAIL PROTECTED]>:
> > I'm pretty sure that's true any more, Alan. Red Hat shipped Python 2 in
> > 7.1, so the RPM-based distros like KRUD and Mandrake have had it for
> > seven months. Debian had it before that.
>
> RH shipped python2 beginning RH 7.2.
Eh? I'm going to go check
[EMAIL PROTECTED] wrote:
>
> In fact, here's all I want to know about the whole CML2/kbuild 2.5 issue. Right
> now I upgrade my kernel like this (simplified slightly):
>
>
> mv .config ..
> make mrproper
> mv ../.config .
> make oldconfig
> make dep
> make bzlilo modules modules_install
>
>
Alan Cox <[EMAIL PROTECTED]>:
> > Creating a dependency on Python? Is a non-issue. Current systems that
> > are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python
> > is nice and it does not create such unmaintainable mess. Whether
>
> Python2 - which means most users dont have
[EMAIL PROTECTED] said:
> I'm listening...what can I do for you?
Simply assure me that I don't have to scan every line of the CML2 files for
such changes, and that you'll make a reasonable effort to make the first set
of CML2 rules match the existing CML1 behaviour, without introducing any
cont
I suppose a polite title for me would be "maintainer emiritus"
of make config, make menuconfig, and make xconfig.
I'm in favor of abandoning the current tools because:
It's 3x maintenance to have 3 parsers for the same language.
It's difficult to do good syntax checking in scripts/Configure
David Woodhouse <[EMAIL PROTECTED]>:
> I do have objections to some of the other ideas which have been floated for
> changing the behaviour of the config rules, which aren't strictly related to
> the change in language.
I'm listening...what can I do for you?
--
http://www.tuxedo
[EMAIL PROTECTED] said:
> No, it's CONFIG_EXPERT. And this change is not wired in. Comment
> out this declaration in the top-level rulesfile:
> condition nohelp on EXPERT
> and it reverts to old behavior.
Good. Please make that the default when submitting the first version of
CML2. You ca
David Woodhouse <[EMAIL PROTECTED]>:
>
> [EMAIL PROTECTED] said:
> > I don't think esr changed non problematic rules, but one: all rules
> > without help become automatically dependent to CONFIG_EXPERIMENTAL. I
> > don't like it, but I understand why he makes this decision.
>
> That is precise
Giacomo Catenazzi <[EMAIL PROTECTED]>:
> I don't think esr changed non problematic rules, but one:
> all rules without help become automatically dependent to
> CONFIG_EXPERIMENTAL. I don't like it, but I understand why
> he makes this decision.
No, it's CONFIG_EXPERT. And this change is not wire
Matthias Andree <[EMAIL PROTECTED]>:
> Seriously: what do you fear? Losing the efforts you put into mconfig?
> Linux 2.2 and 2.4 will be around for quite some time (not sure about
> mconfig on 2.0, I don't use 2.0.x ATM).
Oops. I wasn't going to tell anyone this yet, but since you've made
this a
> Creating a dependency on Python? Is a non-issue. Current systems that
> are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python
> is nice and it does not create such unmaintainable mess. Whether
Python2 - which means most users dont have it.
__
[EMAIL PROTECTED] said:
> I don't think esr changed non problematic rules, but one: all rules
> without help become automatically dependent to CONFIG_EXPERIMENTAL. I
> don't like it, but I understand why he makes this decision.
That is precisely the kind of bogus change which should _not_ be d
David Woodhouse wrote:
>
> I do have objections to some of the other ideas which have been floated for
> changing the behaviour of the config rules, which aren't strictly related to
> the change in language.
The rules are nearly the same (but written in another language).
The problem was in c
[EMAIL PROTECTED] said:
> You can spend all week telling us how easy it would be to implement
> all the CML2 benefits that CML1 doesn't have, if you like -- but one
> of the rules of this game is that an ounce of working code beats a
> pound of handwaving.
FWIW I have no particular problem wit
Christoph Hellwig <[EMAIL PROTECTED]>:
> With mconfig [side-effect chasing] can be implemented easily [...]
> One toplevel config file can be implemented in CML1 easily,
You can spend all week telling us how easy it would be to implement
all the CML2 benefits that CML1 doesn't have, if you like -
On Monday 03 December 2001 20:13, Keith Owens wrote:
> I just had a quick look at arch/alpha makefiles.
>
> kernel/Makefile - no obvious conversion problems. asm_offsets moves to
> arch/alpha and is renamed to asm-offsets using the standard code.
Could you take a look a the attached makefile.in
On Tue, Dec 04, 2001 at 02:29:58PM +0100, Christoph Hellwig wrote:
> On Tue, Dec 04, 2001 at 08:16:40AM -0500, Eric S. Raymond wrote:
> > N separate implementations means N dialects and N**2 compatibility problems.
> > Nicer just to have *one* parser, *one* compiler, and *one* service class that
>
On Tue, Dec 04, 2001 at 08:16:40AM -0500, Eric S. Raymond wrote:
> N separate implementations means N dialects and N**2 compatibility problems.
> Nicer just to have *one* parser, *one* compiler, and *one* service class that
> supports several thin front-end layers, yes? No?
Oh man. When you thi
Christoph Hellwig <[EMAIL PROTECTED]>:
> There is a CML1 language specification, as written down in a file, namely
> Documentation/kbuild/config-language.txt in the kernel tree.
A specification which, according to its author, is incomplete.
> There is one tool (mconfig) which has a yacc-parser t
On Tue, Dec 04, 2001 at 07:48:15AM -0500, Eric S. Raymond wrote:
> And, by the way, there is no CML1 :-). Instead, there are four
> mutually incompatible dialects and a rulebase that breaks in different
> ways depending on which interpreter you use. Well, maybe just three
> mutual incompatible d
Christoph Hellwig <[EMAIL PROTECTED]>:
> There is no CML1 maintainer. There are people maintaining the different
> tools intepreting CML1. Some (e.g. the intree ones) are to ugly to consider,
> others are pretty nice.
I was referring to Michael Elizabeth Chastain, Keith Owens, and the other
peo
On Tue, Dec 04, 2001 at 07:28:08AM -0500, Eric S. Raymond wrote:
> Christoph Hellwig <[EMAIL PROTECTED]>:
> > On Mon, Dec 03, 2001 at 12:06:12PM +1100, Keith Owens wrote:
> > > The CML1 to CML2 conversion comes later, either in 2.5.3 or 2.5.4.
> >
> > Is the CML2 merge actually agreed on?
>
> Ye
Christoph Hellwig <[EMAIL PROTECTED]>:
> On Mon, Dec 03, 2001 at 12:06:12PM +1100, Keith Owens wrote:
> > The CML1 to CML2 conversion comes later, either in 2.5.3 or 2.5.4.
>
> Is the CML2 merge actually agreed on?
Yes, unless Linus has changed his mind since March. Which would be his
privilege
Alan Cox <[EMAIL PROTECTED]>:
> > Unfortunately, the syntax of CML1 is rebarbative, and its imperative
> > semantics cannot be mechanically translated to CML2's declarative
> > semantics by any means I'm aware of.
>
> The dependancy tree from CML1 is not that hard to obtain. It's not quite
> co
> Unfortunately, the syntax of CML1 is rebarbative, and its imperative
> semantics cannot be mechanically translated to CML2's declarative
> semantics by any means I'm aware of.
The dependancy tree from CML1 is not that hard to obtain. It's not quite
complete or correct though
> Is it not possible to write an automatic conversion tool that reads the
> existing CML1 files and outputs CML2 rules with identical behaviour?
Bad ones - yes. Its also possible to do everything CML2 does with the CML1
ruleset. All the information required is there. Howeve CML1 (all 4 dialects
On Mon, Dec 03, 2001 at 12:06:12PM +1100, Keith Owens wrote:
> The CML1 to CML2 conversion comes later, either in 2.5.3 or 2.5.4.
Is the CML2 merge actually agreed on?
I still strongly object to it and I know lots of kernel hackers are
the same opinion.
Christoph
--
Of course it doesn'
David Woodhouse <[EMAIL PROTECTED]>:
>
> [EMAIL PROTECTED] said:
> > The schedule I heard from Linus at the kernel summit was that both
> > changes were to go in between 2.5.1 and 2.5.2. I would prefer
> > sooner than later because I'm *really* *tired* of maintaining a
> > parallel rulebase.
[EMAIL PROTECTED] said:
> The schedule I heard from Linus at the kernel summit was that both
> changes were to go in between 2.5.1 and 2.5.2. I would prefer
> sooner than later because I'm *really* *tired* of maintaining a
> parallel rulebase.
Is it not possible to write an automatic conver
75 matches
Mail list logo
