On Thursday 06 December 2001 12:25 pm, Alan Cox wrote:
So has anyone had time to test the Python version 1.5 based CML2 that
was posted? Would that make it more acceptable?
For 2.5 its a great leap forward. For 2.4 its irrelevant. Its simply not
the way stable kernel trees are run, even
On Thu, Dec 06, 2001 at 07:07:14PM +0100, Martin Dalecki wrote:
John Stoffel wrote:
The requirement for python2 is a bit of a pain, but hey, for 2.5, it's
not a problem.
It is just a BIT OF PAIN. It gives me more trouble than the trouble
I have even with the insufficiencies of the
John Stoffel wrote:
The requirement for python2 is a bit of a pain, but hey, for 2.5, it's
not a problem.
It is just a BIT OF PAIN. It gives me more trouble than the trouble
I have even with the insufficiencies of the current make system.
Basta.
On Thu, 6 Dec 2001 05:03:12 -0500,
Rob Landley [EMAIL PROTECTED] wrote:
P.S. Can we seperate add new subsystem y prime and remove old subsystem
y. LIke the new and old SCSI error handling, which have been in the tree in
parallel for some time? Did I hear Eric ever suggest removing the old
Rob Landley [EMAIL PROTECTED]:
P.S. Can we seperate add new subsystem y prime and remove old subsystem
y. LIke the new and old SCSI error handling, which have been in the tree in
parallel for some time? Did I hear Eric ever suggest removing the old
configurator for 2.4? Anybody?
The
On Tuesday 04 December 2001 12:43 pm, 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 Wed, 5 Dec 2001, Rob Landley wrote:
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.
1) Moving from 2.2-2.4, it wouldn't work at all without a newer compiler and
newer modutils, and it
Greg Banks [EMAIL PROTECTED]:
It seems my main contribution has been to provide
Eric with incentive to clarify his language spec and speed up his parser.
Stimulus for which I have been deeply grateful.
--
a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a
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, of
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
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.
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 wired in.
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 precisely the kind
[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 can
[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
[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):
apply latest patches
mv .config ..
make mrproper
mv ../.config .
make oldconfig
make dep
make bzlilo modules
[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
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 does it handle
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 with
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
Python2 - which means
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
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
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 mess.
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
keep on
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
keep on
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 it will
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 building
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 for
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, 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 any
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
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
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 of them
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 ...
Robert
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 a lot
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 shipped python2
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 end.
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
keep on
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 just going
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
he
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 choice
On Mon, 3 Dec 2001, Keith Owens wrote:
Hi Keith,
_If_ I can get CML2 support working before 2.5.1 comes out then we go
2.5.2-pre1 Add kbuild 2.5 with both CML1 and CML2 support.
2.5.2-pre2 Remove kbuild 2.4.
Do you plan to fix the x2 slowdown before removing kbuild 2.4 ?
Or is this
On Sun, 2 Dec 2001 20:19:46 -0500,
Eric S. Raymond [EMAIL PROTECTED] wrote:
Keith Owens [EMAIL PROTECTED]:
The CML1 to CML2 conversion comes later, either in 2.5.3 or 2.5.4.
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
43 matches
Mail list logo
