des@rsa /var/crash% gdb -k
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absol
Dag-Erling Smorgrav wrote:
> > ===>ipfilter
> > make: don't know how to make machine/lock.h Stop.
> > *** Error code 2
> Looks like a stale dependency file to me. Try 'make cleandir' twice,
> followed by the usual 'make depend && make && make install'.
Yes, but got no luck, stops at the sa
In message <[EMAIL PROTECTED]>, Dag-Erling Smorgrav writes:
>Daniel Eischen <[EMAIL PROTECTED]> writes:
>> Attached is a patch that attempts to work around recent stdio
>> breakage in -current. I've verified it compiles, but won't be
>> able to test it until at least tomorrow. If someone wants t
Donny Lee <[EMAIL PROTECTED]> writes:
> ===>ipfilter
> make: don't know how to make machine/lock.h Stop.
> *** Error code 2
Looks like a stale dependency file to me. Try 'make cleandir' twice,
followed by the usual 'make depend && make && make install'.
DES
--
Dag-Erling Smorgrav - [EMAIL
Hi there,
I'm not sure if this related to the thread of -current these days.
my world builds fine with the latest cvsup, maybe only 1 or 2 hrs
ago. no more luck, my kernel building stoped here:
===>ipfilter
make: don't know how to make machine/lock.h Stop.
*** Error code 2
Stop in
"Alexander N. Kabaev" wrote:
>
> > But I remember some posts about a lpt panic some days ago. I tried to
> > compile a new kernel because I think this is resolved, but I have to
> > solve some problems with my system at the moment.
>
> My -CURRENT used to crash every time lpr has been used but t
On Mon, 12 Feb 2001, Robert Watson wrote:
> On 12 Feb 2001, Dag-Erling Smorgrav wrote:
>
> > Jake Burkholder <[EMAIL PROTECTED]> writes:
> > > As I mentioned in the commit message, this changes the size and layout
> > > of struct kinfo_proc, so you'll have to recompile libkvm-using programs.
> >
> On Sun, Jan 28, 2001 at 01:27:04AM -0800, Julian Elischer wrote:
> > > This is the single most flagrant lack of cooperation I have experienced
> > > while working with the FreeBSD Project. I'm truly dumbfounded.
> >
> > It's not a lack of co-operation.. it's a lack of communication. I didn't
>
In message <[EMAIL PROTECTED]> Matt Dillon writes:
: How about a temporary LD_LIBRARY path to run the tools, pointing into
: /usr/obj somewhere?
We'd have to copy the current libraries to that location, or at least
into /tmp. These are *HOST* binaries after all. And the hacking to
do th
'make world' on -CURRENT has been broken since Feb 10 due to a change
in the size of struct __sFILE (which changes the address of stdin,
stdout and stderr). It will remain broken for a few more days while we
work out the best possible solution to this problem.
DO NOT TRY TO UPGRADE -STABLE OR A P
:In message <[EMAIL PROTECTED]> Matt Dillon writes:
::Would compiling the tools -static help?
:
:No. The tools that are deployed today are not static, and it is those
:that we copy. It will also delay discovery of the incompatibility
:until after the installworld is complete. I'm not sure
In message <[EMAIL PROTECTED]> Matt Dillon writes:
:Would compiling the tools -static help?
No. The tools that are deployed today are not static, and it is those
that we copy. It will also delay discovery of the incompatibility
until after the installworld is complete. I'm not sure that wo
Would compiling the tools -static help?
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Mon, 12 Feb 2001, David O'Brien wrote:
> On Mon, Feb 12, 2001 at 11:47:04AM -0500, Garrett Wollman wrote:
> > However, this may turn out to be so painful that we need to bump it
> > again.
>
> That is (1) against Handbook documented policy, (2) too hackish (we
> aren't Linux).
It's not bumpi
On Tue, Feb 13, 2001 at 02:29:54AM +0100, Dag-Erling Smorgrav wrote:
> We can keep that bias by using temporary three-digit majors in
> -CURRENT and backing down to a single-digit major right before the
> first -RELEASE. In this specific case, we'd go from 5 to 500 or 501,
Please read your -arch
On Mon, Feb 12, 2001 at 05:44:53PM -0800, Peter Wemm wrote:
> "David O'Brien" wrote:
> > Actually going from libc.so.500 to libc.so.{x<500} is easy.
> > Copy libc.so.500 into /usr/lib/compat. When the libc.so link is made to
> > libc.so.{x<500}, that is the lib version number that will get burned
On Tue, Feb 13, 2001 at 02:42:15AM +0100, Dag-Erling Smorgrav wrote:
> Warner Losh <[EMAIL PROTECTED]> writes:
> > I've had problems in the past going backwards on major versions of
> > shared libaries. The major problem is that if I have binaries that
> > refer to libc.so.503, then when the majo
Dag-Erling Smorgrav wrote:
> Warner Losh <[EMAIL PROTECTED]> writes:
> > I've had problems in the past going backwards on major versions of
> > shared libaries. The major problem is that if I have binaries that
> > refer to libc.so.503, then when the major number is reverted back to
> > 5, it is
On Mon, Feb 12, 2001 at 05:44:31PM -0800, Peter Wemm wrote:
> We could use dates, current time_t, anything.
/usr/lib/libc.so.whistler
(Sorry, working for MS I couldn't resist :-)
--
Jos Backus _/ _/_/_/"Modularity is not a hack."
_/ _/ _/
In message <[EMAIL PROTECTED]> Dag-Erling Smorgrav writes:
: When we back down to 5, we add magic to the Makefiles to move
: libc.so.5?? to /usr/lib/compat - that way they're only used when
: needed at runtime, not for linking new programs.
No need. I misunderstood how ELF libraries work. The l
"David O'Brien" wrote:
> Actually going from libc.so.500 to libc.so.{x<500} is easy.
> Copy libc.so.500 into /usr/lib/compat. When the libc.so link is made to
> libc.so.{x<500}, that is the lib version number that will get burned into
> objects. After the first `make world', rm /usr/lib/libc.so.
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> When we back down to 5, we add magic to the Makefiles to move
> libc.so.5?? to /usr/lib/compat - that way they're only used when
> needed at runtime, not for linking new programs.
Umm, never mind this gross hack; as Peter pointed out, it's not a
p
Warner Losh <[EMAIL PROTECTED]> writes:
> I've had problems in the past going backwards on major versions of
> shared libaries. The major problem is that if I have binaries that
> refer to libc.so.503, then when the major number is reverted back to
> 5, it is a nop because ld will use libc.so.503
In message <[EMAIL PROTECTED]> Alfred Perlstein writes:
: > Actually going from libc.so.500 to libc.so.{x<500} is easy.
: > Copy libc.so.500 into /usr/lib/compat. When the libc.so link is made to
: > libc.so.{x<500}, that is the lib version number that will get burned into
: > objects. After the
In message <[EMAIL PROTECTED]> "David O'Brien" writes:
: > What's wrong with shipping with say libc.so.505 in 5.0 and then say
: > libc.so.645 in 6.0?
:
: HACK.
I think it is an astheitc issue only. It is not a hack, but how ELF
shared libarires work. However, since it is easy to move from 505
Peter Wemm <[EMAIL PROTECTED]> writes:
> at which point any stdio using dynamic binary is hosed, including the
> *USELESS* copies in /tmp that installworld stashed away.
Is it possible to produce a static executable from a dynamic one,
provided the right libs are available? In that case, the init
* David O'Brien <[EMAIL PROTECTED]> [010212 17:35] wrote:
> On Mon, Feb 12, 2001 at 06:26:06PM -0700, Warner Losh wrote:
> > I don't see why we need only an increment of 1. What does this buy us
> > other than a minor warm fuzzy.
>
> It is hackish.
>
> > OpenBSD bumps libc bunchs of times per
On Mon, Feb 12, 2001 at 06:31:53PM -0700, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Peter Wemm writes:
> : If we had taken -current to 500, we could go to 501, 502, etc as
> : required to stop killing our developers, and prior to entering 5.0-BETA we
> : go back to the next sequentially
In message <[EMAIL PROTECTED]> Alfred Perlstein writes:
: Er, why isn't /tmp/install.XXX done with static binaries?
Because the binaries are host binaries and we have no control over
whether they are static or dynmaic. At best we could do is to copy
libraries over as well. But I think the major
In message <[EMAIL PROTECTED]> Peter Wemm writes:
: Warner Losh wrote:
: significance to the naming at all. The versioning is done at link time
: by the libfoo.so -> libfoo.so.N symlink.
Ah. That's different. If it is that easy, then my objection is
withdrawn. I wasted about 3 days trying to
Peter Wemm <[EMAIL PROTECTED]> writes:
> install -c libc.so.5 /usr/lib
> install -c libc_pic.a /usr/lib
> /usr/libexec/ld-elf.so.1: undefined symbol __sF in COPY relocation
>
> at which point any stdio using dynamic binary is hosed, including the
> *USELESS* copies in /tmp that installworld stash
On Mon, Feb 12, 2001 at 06:26:06PM -0700, Warner Losh wrote:
> I don't see why we need only an increment of 1. What does this buy us
> other than a minor warm fuzzy.
It is hackish.
> OpenBSD bumps libc bunchs of times per release cycle (they are up to
> libc.so.24 if my sources are current).
* Peter Wemm <[EMAIL PROTECTED]> [010212 17:28] wrote:
> Dag-Erling Smorgrav wrote:
> > Peter Wemm <[EMAIL PROTECTED]> writes:
> > > Sorry, I made the mistake of looking at this bikeshed and lost my nerve.
> > > The patch I was going to commit was:
> > > http://people.freebsd.org/~peter/stdio.diff
On Mon, 12 Feb 2001, Peter Wemm wrote:
> Daniel Eischen wrote:
>
> > Attached is a patch that attempts to work around recent stdio
> > breakage in -current. I've verified it compiles, but won't be
> > able to test it until at least tomorrow. If someone wants to
> > review it and verify it works
Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Dag-Erling Smorgrav writes:
> : Peter Wemm <[EMAIL PROTECTED]> writes:
> : > http://people.freebsd.org/~peter/stdio.diff3
> :
> : Except that we bump to 500 instead of 6, and back to 5 before
> : -RELEASE.
>
> I don't think this will work. It
In message <[EMAIL PROTECTED]> Peter Wemm writes:
: If we had taken -current to 500, we could go to 501, 502, etc as
: required to stop killing our developers, and prior to entering 5.0-BETA we
: go back to the next sequentially available major number (be it 5, or 6
: if RELENG_4 bumps again).
I
Warner Losh <[EMAIL PROTECTED]> writes:
> I'd like to see a bias against major bumps remain in place, but I
> think that this change requires one. That is, we still don't
> generally bump major verions, but are allowed to when the pain is
> major.
We can keep that bias by using temporary three-d
On Mon, Feb 12, 2001 at 06:21:58PM -0700, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Peter Wemm writes:
> : Personally, I think we place far too much weight on the major number thing.
> : I think we should be allowed to bump it when the alternative is 'major pain'
> : to developers.
>
>
> Mike Smith wrote:
> > > On Mon, Feb 12, 2001 at 02:20:30PM -0800, Mike Smith wrote:
> > >
> > > > You can do better than this. Put the lock in FILE, and define a new
> > > > structure FILE_old, which has the same size/layout as the old FILE
> > > > structure.
> > >
> > > How is this more ac
Dag-Erling Smorgrav wrote:
> Peter Wemm <[EMAIL PROTECTED]> writes:
> > Sorry, I made the mistake of looking at this bikeshed and lost my nerve.
> > The patch I was going to commit was:
> > http://people.freebsd.org/~peter/stdio.diff3
> > .. but this *totally* breaks installworld due to *BAD* brok
On Mon, Feb 12, 2001 at 05:20:51PM -0800, Peter Wemm wrote:
> It avoids the current problem:
> - RELENG_4 bumped from 3.0 to 4.0
> - this forced a premature 4.0->5.0 bump in -current
Actually "NO". I bumped libc.so because Garret said he had changes ready
for libc, but was waiting for someone to
In message <[EMAIL PROTECTED]> Dag-Erling Smorgrav writes:
: Peter Wemm <[EMAIL PROTECTED]> writes:
: > http://people.freebsd.org/~peter/stdio.diff3
:
: Except that we bump to 500 instead of 6, and back to 5 before
: -RELEASE.
I don't think this will work. It is hard to downgrade a major number
On Sun, Jan 28, 2001 at 01:27:04AM -0800, Julian Elischer wrote:
> > This is the single most flagrant lack of cooperation I have experienced
> > while working with the FreeBSD Project. I'm truly dumbfounded.
>
> It's not a lack of co-operation.. it's a lack of communication. I didn't
> see an an
In message <[EMAIL PROTECTED]> Peter Wemm writes:
: Personally, I think we place far too much weight on the major number thing.
: I think we should be allowed to bump it when the alternative is 'major pain'
: to developers.
The more I think about this, the more that I think that you are right.
I'
Mike Smith wrote:
> > On Mon, Feb 12, 2001 at 02:20:30PM -0800, Mike Smith wrote:
> >
> > > You can do better than this. Put the lock in FILE, and define a new
> > > structure FILE_old, which has the same size/layout as the old FILE
> > > structure.
> >
> > How is this more acceptable than bu
Daniel Eischen wrote:
> Attached is a patch that attempts to work around recent stdio
> breakage in -current. I've verified it compiles, but won't be
> able to test it until at least tomorrow. If someone wants to
> review it and verify it works, I'll commit it.
>
> Thanks,
> __BEGIN_DECLS
>
Dag-Erling Smorgrav wrote:
> Peter Wemm <[EMAIL PROTECTED]> writes:
> > http://people.freebsd.org/~peter/stdio.diff3
>
> Except that we bump to 500 instead of 6, and back to 5 before
> -RELEASE.
>
> When we've branched RELENG_5, if we need to bump libc's major in
> 6.0-CURRENT, we bump it to 600
On Tue, Feb 13, 2001 at 02:14:03AM +0100, Dag-Erling Smorgrav wrote:
>
> No, it doesn't, because you bumped the libc major. Set it to 500 like
> we discussedm, and commit (or I will, damnit).
Uh, NO. It was discussed on IRC, NOT -arch. It needs to go there before
doing something like this.
-
Peter Wemm <[EMAIL PROTECTED]> writes:
> Sorry, I made the mistake of looking at this bikeshed and lost my nerve.
> The patch I was going to commit was:
> http://people.freebsd.org/~peter/stdio.diff3
> .. but this *totally* breaks installworld due to *BAD* brokenness in
> installworld.
No, it doe
On Mon, Feb 12, 2001 at 05:09:19PM -0800, Peter Wemm wrote:
> I can deal with /usr/local and /usr/X11R6 recompiles, but when the
> installworld dies because the dynamic linked copy of /usr/bin/* in
> /tmp/XXX/* gets the /usr/lib/libc.so.5 clobbered and explodes, leaving
> a 100% totally screwed up
> On Mon, Feb 12, 2001 at 02:20:30PM -0800, Mike Smith wrote:
>
> > You can do better than this. Put the lock in FILE, and define a new
> > structure FILE_old, which has the same size/layout as the old FILE
> > structure.
>
> How is this more acceptable than bumping the major number? Are the
Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Dag-Erling Smorgrav writes:
> : Warner Losh <[EMAIL PROTECTED]> writes:
> : > I'd rather see this patch, or something similar, than bump the major
> : > version again. We can phase in a better way to obviate the need to do
> : > this in the futu
Peter Wemm <[EMAIL PROTECTED]> writes:
> http://people.freebsd.org/~peter/stdio.diff3
Except that we bump to 500 instead of 6, and back to 5 before
-RELEASE.
When we've branched RELENG_5, if we need to bump libc's major in
6.0-CURRENT, we bump it to 600, then 601 etc. as many times as we
want, a
Dag-Erling Smorgrav wrote:
> Warner Losh <[EMAIL PROTECTED]> writes:
> > I'd rather see this patch, or something similar, than bump the major
> > version again. We can phase in a better way to obviate the need to do
> > this in the future.
>
> Brian Feldman, Peter Wemm, David O'Brien and myself
On Mon, Feb 12, 2001 at 04:33:26PM -0800, Alex Zepeda wrote:
> How about this? :^)
Because bumping the shared version again needs *DISCUSSING*.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Dag-Erling Smorgrav writes:
> : Daniel Eischen <[EMAIL PROTECTED]> writes:
> : > Attached is a patch that attempts to work around recent stdio
> : > breakage in -current. I've verified it compiles, but won't be
> : > able to test it until at lea
On Mon, Feb 12, 2001 at 07:28:30PM -0500, Daniel Eischen wrote:
> Attached is a patch that attempts to work around recent stdio
> breakage in -current. I've verified it compiles, but won't be
> able to test it until at least tomorrow. If someone wants to
> review it and verify it works, I'll com
Warner Losh <[EMAIL PROTECTED]> writes:
> If there's something better than Daniel's solution that doesn't
> require a major bump and is compatible with the old libc.so.5 api,
> then I'm all for that. I'd love to test it out as well if there's any
> desire for that.
Yes, there is. Steal _cookie,
On 13 Feb 2001, Dag-Erling Smorgrav wrote:
> Warner Losh <[EMAIL PROTECTED]> writes:
> > I'd rather see this patch, or something similar, than bump the major
> > version again. We can phase in a better way to obviate the need to do
> > this in the future.
>
> Brian Feldman, Peter Wemm, David O'B
On Mon, Feb 12, 2001 at 11:47:04AM -0500, Garrett Wollman wrote:
> However, this may turn out to be so painful that we need to bump it
> again.
That is (1) against Handbook documented policy, (2) too hackish (we
aren't Linux).
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe f
On Sun, Feb 11, 2001 at 04:44:21PM -0800, Matt Dillon wrote:
>This is a major change to libc. The library maj must be bumped if you
>intend to change the sizeof(FILE), or every single third party application
>that uses stdio will break.
For -stable this would be true. We've already
On Tue, Feb 13, 2001 at 01:48:33AM +0100, Dag-Erling Smorgrav wrote:
> Peter will likely commit a patch sometime soon.
I am hoping it is posted for discussion to -arch before commit (so we get
this right).
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in th
In message <[EMAIL PROTECTED]> Dag-Erling Smorgrav writes:
: Warner Losh <[EMAIL PROTECTED]> writes:
: > I'd rather see this patch, or something similar, than bump the major
: > version again. We can phase in a better way to obviate the need to do
: > this in the future.
:
: Brian Feldman, Peter
Warner Losh <[EMAIL PROTECTED]> writes:
> I'd rather see this patch, or something similar, than bump the major
> version again. We can phase in a better way to obviate the need to do
> this in the future.
Brian Feldman, Peter Wemm, David O'Brien and myself have been
discussing possible solutions
On Mon, Feb 12, 2001 at 01:42:16PM -0800, Alex Zepeda wrote:
> Yup, I agree here. IMO so many things depend on the stdio bits, that a
> major number increase would have been desireable. So far, bzip2,
> pine/pico, GNU make, the GNU i18n stuff, fetchmail all needed to be
> rebuilt. Bumping the m
In message <[EMAIL PROTECTED]> Dag-Erling Smorgrav writes:
: Daniel Eischen <[EMAIL PROTECTED]> writes:
: > Attached is a patch that attempts to work around recent stdio
: > breakage in -current. I've verified it compiles, but won't be
: > able to test it until at least tomorrow. If someone want
In message <[EMAIL PROTECTED]> "David O'Brien" writes:
: On Mon, Feb 12, 2001 at 02:19:36PM -0700, Warner Losh wrote:
: > Changes of this magnitude require a bump of the major number, even
: > though we've already done that in -current. It breaks nearly
: > everything, including the upgrade path.
On Mon, Feb 12, 2001 at 04:20:04PM -0800, Alex Zepeda wrote:
> How is this more acceptable than bumping the major number? Are they
> really so precious that they can only be incremented once for a release
> cycle?
Yes. I don't want to be in a position where we wonder what happened to
libc.so.
Daniel Eischen <[EMAIL PROTECTED]> writes:
> Attached is a patch that attempts to work around recent stdio
> breakage in -current. I've verified it compiles, but won't be
> able to test it until at least tomorrow. If someone wants to
> review it and verify it works, I'll commit it.
Please. Let'
On Mon, Feb 12, 2001 at 02:19:36PM -0700, Warner Losh wrote:
> Changes of this magnitude require a bump of the major number, even
> though we've already done that in -current. It breaks nearly
> everything, including the upgrade path.
How does it break the upgrade path from 4.x to 5.0?? 5.0 has
In message <[EMAIL PROTECTED]> Daniel Eischen writes:
: Attached is a patch that attempts to work around recent stdio
: breakage in -current. I've verified it compiles, but won't be
: able to test it until at least tomorrow. If someone wants to
: review it and verify it works, I'll commit it.
T
On Mon, Feb 12, 2001 at 02:20:30PM -0800, Mike Smith wrote:
> You can do better than this. Put the lock in FILE, and define a new
> structure FILE_old, which has the same size/layout as the old FILE
> structure.
How is this more acceptable than bumping the major number? Are they
really so pr
Attached is a patch that attempts to work around recent stdio
breakage in -current. I've verified it compiles, but won't be
able to test it until at least tomorrow. If someone wants to
review it and verify it works, I'll commit it.
Thanks,
--
Dan Eischen
Index: include/stdio.h
==
Hello,
I have been playing with PnP and device hints. Using a device.hints
with hints for all the drivers, some " can't assing resources"
messages showed up at boot. Then I removed hints one by one, until
I ended up with these:
hint.fd.0.at="fdc0"
hint.fd.0.drive="0"
hint.atkbd.0.at="atkbdc"
hin
Warner Losh <[EMAIL PROTECTED]> writes:
> Alternatively, the upgrade path must be fixed.
I don't see any way to do that. Everything on your system that isn't
statically linked will need to be recompiled unless the libc major
number is bumped.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To
On Mon, 12 Feb 2001, Mike Smith wrote:
> > > Then wouldn't the "partially applied patch" rule apply? eg, back it
> > > out until the issues can be resolved. Breaking the upgrade path isn't
> > > acceptible.
> >
> > If you bump the library versions, doesn't that fix the upgrade
> > path?
>
> No
> > Then wouldn't the "partially applied patch" rule apply? eg, back it
> > out until the issues can be resolved. Breaking the upgrade path isn't
> > acceptible.
>
> If you bump the library versions, doesn't that fix the upgrade
> path?
No, because the library version bump has already happened
On Mon, 12 Feb 2001, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Daniel
>Eischen writes:
> : On Mon, 12 Feb 2001, Warner Losh wrote:
> : > To be blunt, the FILE * changes go too far, even for -current.
> :
> : Other than having to installworld twice, I've had zero problems.
> : But I don
On Mon, Feb 12, 2001 at 01:20:36PM +0700, John Indra wrote:
> Now I'm in the middle of make -j10 buildworld. Is -CURRENT in bad shape?
First thing to do when you're having problems building world is to STOP
using -j. If you aren't hitting a race condition, you won't get able to
figure out what i
On Mon, Feb 12, 2001 at 02:19:36PM -0700, Warner Losh wrote:
> Changes of this magnitude require a bump of the major number, even
> though we've already done that in -current. It breaks nearly
> everything, including the upgrade path. Alternatively, the locking
> changes need to be backed out.
Just upgraded both my kernel, and did a buildworld, both of which are
running quite well (CVSup'd as of this afternoon) ...
On Mon, 12 Feb 2001, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> John Indra writes:
> : Is -CURRENT in bad shape?
>
> Yes. Life sucks in current -> current upgrad
>
> Then wouldn't the "partially applied patch" rule apply? eg, back it
> out until the issues can be resolved. Breaking the upgrade path isn't
> acceptible.
I have to "me too" this; the change simply isn't OK. There are a variety
of ways that we can work around the issue and maintain binary
Hey this may be a spot where the FILE change is felt - my installworld bombed
in the perl/library install with a sed error.
I went to usr.bin/sed and did a make install to put in the new sed and then
make installworld completed ok.
FYI
Mark Hittinger
Earthlink
[EMAIL PROTECTED]
To Unsubscrib
In message <[EMAIL PROTECTED]> Daniel Eischen
writes:
: On Mon, 12 Feb 2001, Warner Losh wrote:
: > To be blunt, the FILE * changes go too far, even for -current.
:
: Other than having to installworld twice, I've had zero problems.
: But I don't recompile my applications often, and am probably
:
On Mon, 12 Feb 2001, Warner Losh wrote:
> To be blunt, the FILE * changes go too far, even for -current.
Other than having to installworld twice, I've had zero problems.
But I don't recompile my applications often, and am probably
still running things that depend on libc.so.4.
> Changes of this
>"Justin T. Gibbs" <[EMAIL PROTECTED]> wrote:
>>
>>It is not necessarily sufficient since the media may be changed after
>>open on certain types of devices that don't have a media lock.
>
>But don't you risk a panic if you do that?
By pulling the media out and flipping off the hardware write prot
"Justin T. Gibbs" <[EMAIL PROTECTED]> wrote:
>
>It is not necessarily sufficient since the media may be changed after
>open on certain types of devices that don't have a media lock.
But don't you risk a panic if you do that?
Tony.
--
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
THAMES
To be blunt, the FILE * changes go too far, even for -current.
Changes of this magnitude require a bump of the major number, even
though we've already done that in -current. It breaks nearly
everything, including the upgrade path. Alternatively, the locking
changes need to be backed out.
Alter
In message <[EMAIL PROTECTED]> John Indra writes:
: Is -CURRENT in bad shape?
Yes. Life sucks in current -> current upgrade land.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
At 11:47 AM 2/12/2001 -0500, Garrett Wollman wrote:
>< said:
>
>> The major number has already been bumped, I thought. If this is true
>> then we've only broken compatibility with older versions of -current
>> after the version number was bumped but before this change, right?
>
>However, this may
Bruce Evans <[EMAIL PROTECTED]> writes:
>On Fri, 9 Feb 2001, John W. De Boskey wrote:
>>I've been using the disklabel.c patch which allows easier
>> configuration by being able to specify a new disklabel of
>> the form:
>>I'd like to commit these if no one sees any major problems
>> with
< said:
> The major number has already been bumped, I thought. If this is true
> then we've only broken compatibility with older versions of -current
> after the version number was bumped but before this change, right?
However, this may turn out to be so painful that we need to bump it
again.
-
"Alexander N. Kabaev" wrote:
>
> > But I remember some posts about a lpt panic some days ago. I tried to
> > compile a new kernel because I think this is resolved, but I have to
> > solve some problems with my system at the moment.
>
> My -CURRENT used to crash every time lpr has been used but t
Soren Schmidt wrote:
> It seems Maxim Sobolev wrote:
> [Charset koi8-r unsupported, filtering to ASCII...]
> > Hi,
> >
> > I'm not sure whether it's related to ata driver, but starting from several days
> > ago (my previous kernel was from 30 January) my kernel panices on every more or
> > less a
It seems Maxim Sobolev wrote:
[Charset koi8-r unsupported, filtering to ASCII...]
> Hi,
>
> I'm not sure whether it's related to ata driver, but starting from several days
> ago (my previous kernel was from 30 January) my kernel panices on every more or
> less active ad0 usage (for example, dd if
Hi,
I'm not sure whether it's related to ata driver, but starting from several days
ago (my previous kernel was from 30 January) my kernel panices on every more or
less active ad0 usage (for example, dd if=/dev/ad0 of=/dev/null kills it
perfectly). The system in question is Toshiba Satellite Pro
> -Original Message-
> From: Phil Simms
> Sent: Tuesday, February 9, 2001 4:14 PM
> To: Barry Sanders
> Cc: Steve Hartman, Rhonda Smalley, Jimmy Ward, Big Dave, Dean
Fletcher
> Subject: FW: -- 3 New Hilarious Video Clips and some more jokes.
> Joke Lovers,
> He
> But I remember some posts about a lpt panic some days ago. I tried to
> compile a new kernel because I think this is resolved, but I have to
> solve some problems with my system at the moment.
My -CURRENT used to crash every time lpr has been used but the panic went away
when John Baldwin commi
On 12 Feb, Michael Harnois wrote:
> ../../dev/ata/ata-all.c:96: elements of array `ata_ids' have incomplete type
[...]
Workaround (compile in progress): remove the #if / #endif pair
which tests "NISA > 0"
Bye,
Alexander.
--
Where do you think you're going today?
http://www.Lei
On 12 Feb 2001, Dag-Erling Smorgrav wrote:
> Jake Burkholder <[EMAIL PROTECTED]> writes:
> > As I mentioned in the commit message, this changes the size and layout
> > of struct kinfo_proc, so you'll have to recompile libkvm-using programs.
>
> I thought the whole point with kinfo_proc was to a
1 - 100 of 118 matches
Mail list logo
