On Fri, Oct 01, 1999 at 03:36:11PM -0400, Daniel Eischen wrote:
But this still doesn't entirely solve the problem. You still have
to build and install a new kernel before installing the world.
Of course! Installing the world _is_ upgrading your operating
system. I don't see anyone
Marcel Moolenaar wrote:
But this still doesn't entirely solve the problem. You still have
to build and install a new kernel before installing the world.
While this is typically what most -current folks do anyways, it
still prevents backing up to a previous kernel after the install
"Daniel C. Sobral" wrote:
Marcel Moolenaar wrote:
But this still doesn't entirely solve the problem. You still have
to build and install a new kernel before installing the world.
While this is typically what most -current folks do anyways, it
still prevents backing up to a
[CC: trimmed to -current]
But this still doesn't entirely solve the problem. You still have
to build and install a new kernel before installing the world.
While this is typically what most -current folks do anyways, it
still prevents backing up to a previous kernel after the
On Sat, 2 Oct 1999, Rodney W. Grimes wrote:
Read my lips: *NEVER* do a 'make world' until you've got a new bootable
kernel. You can go back to a 'kernel.old' in 5 seconds. Undoing a 'make
world' because a new kernel doesn't workd is a major drama.
These folks are 100% correct, some
On Sat, Oct 02, 1999 at 09:45:30AM -0700, Rodney W. Grimes wrote:
Read my lips: *NEVER* do a 'make world' until you've got a new bootable
kernel. You can go back to a 'kernel.old' in 5 seconds. Undoing a 'make
world' because a new kernel doesn't workd is a major drama.
These folks
When did we go wrong and start saying that users should build the world
before building a new kernel?If it was ``I'' that said it, I full
retract any such statement, I was WRONG!. It may have been said in the
patchkit days, or very early FreeBSD 1.x.
It's been "common culture" ever
On 2 October 1999 at 9:45, "Rodney W. Grimes" [EMAIL PROTECTED] wrote:
When did we go wrong and start saying that users should build the world
before building a new kernel?If it was ``I'' that said it, I full
retract any such statement, I was WRONG!. It may have been said in the
"Daniel C. Sobral" wrote:
"Rodney W. Grimes" wrote:
These folks are 100% correct, some place some where we made a mistake
and are telling users to do things in the wrong order. It might have
even been myself that caused this, I just can't recall when and who
said to build the world
Marcel Moolenaar [EMAIL PROTECTED] writes:
The problem
---
When doing a make world, tools are being built that are used by the
build process. This is to make sure that the tools are appropriate for
doing a make world. The problem we now face is that the sigset_t change
causes this
Marcel Moolenaar wrote:
Dag-Erling Smorgrav wrote:
How about this: early in make world, we check whether or not the
current kernel supports the new syscalls. If it does, good. If it
doesn't, we build and load a small module which installs syscalls
which translate the sigset_t stuff
Daniel Eischen wrote:
Marcel Moolenaar wrote:
Dag-Erling Smorgrav wrote:
How about this: early in make world, we check whether or not the
current kernel supports the new syscalls. If it does, good. If it
doesn't, we build and load a small module which installs syscalls
which
Hi,
In the recent discussion about the breakage of the upgrade path from
-stable to -current numerous suggestions and other kinds of remarks have
been made. In this light I have the following proposal. Please share
your thoughts...
NOTE: This proposal only discusses upgrading from -stable to
On Thu, Sep 30, 1999 at 12:13:32PM +0200, Marcel Moolenaar wrote:
The problem
---
When doing a make world, tools are being built that are used by the
build process. This is to make sure that the tools are appropriate for
doing a make world. The problem we now face is that the
Marcel Moolenaar wrote:
Pros
o It increases inoperability between -stable and -current.
I mean decreases inoperability or increases operability of course :-/
--
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking Databases
On Thu, Sep 30, 1999 at 12:13:32PM +0200, Marcel Moolenaar wrote:
So, the problem can be split into:
A) New syscalls using the new sigset_t (sigaction and so on)
B) A new sigframe (new siginfo, no sigcontext but ucontext_t)
"I'm probably missing something, but..." (TM)
The new syscall
On Thu, 30 Sep 1999, Marcel Moolenaar wrote:
Sub-problem B (sigframe) doesn't need to be handled, because:
1. none of the tools require ...
Correct, this is a "non-problem".
Sub-problem A (syscalls) can be easily handled if the syscalls are added
to a -stable kernel.
Wrong. I CANNOT
Hi,
In the recent discussion about the breakage of the upgrade path from
-stable to -current numerous suggestions and other kinds of remarks have
been made. In this light I have the following proposal. Please share
your thoughts...
NOTE: This proposal only discusses upgrading from
"Rodney W. Grimes" wrote:
IMHO, the only ``correct'' fix for the latest incarnation of the
problem is to finally once and for all fix the cross compilation
environment instead of using a half cooked tools: target to deal
with certain problems.
brainstorm:
Upgrading cannot be solved if it
"Rodney W. Grimes" wrote:
1. A compiler C running on machine 1 and capable of generating code
for machine 2 (the compiler includes headers and libraries),
2. Source code compatible with compiler C, but also with machine 2.
And also compatible with machine 1, that is the bugger right
Why are the tools being built using new syscalls? What causes this?
Mainly historical bugs. Includes are installed too early and they only
match the new syscalls. Tools are built using the new includes, so they
need new libraries to be consistent. Therefore the new libraries are
built
Mainly historical bugs. Includes are installed too early and they only
match the new syscalls. Tools are built using the new includes, so they
need new libraries to be consistent. Therefore the new libraries are
built before the new tools. These bugs were implemented in FreeBSD-1 by
On Fri, Oct 01, 1999 at 08:48:34AM +1000, David O'Brien wrote:
On Thu, Sep 30, 1999 at 06:25:56AM -0700, Rodney W. Grimes wrote:
Cons
o Upgrading from 3.3 and before to -current is only possible after
an upgrade to post 3.3.
Not good.
We recommend that 2.2.x people upgrade to
On Thu, Sep 30, 1999 at 06:25:56AM -0700, Rodney W. Grimes wrote:
Cons
o Upgrading from 3.3 and before to -current is only possible after
an upgrade to post 3.3.
Not good.
We recommend that 2.2.x people upgrade to the latest 2.2-STABLE offering
before trying to jump
24 matches
Mail list logo
