Kris Kennaway wrote:
> > > > > I vote this too. We don't need stripped down libreadline under
> > > > > 'libreadline' name pretend to be full version (f.e. for
> > > > > autoconf, etc.)
[ ... remember this sentence; it answers your question ... ]
> > I'm saying "fix it both places, or it obvious
On Thu, 19 Jul 2001, Jim Bryant wrote:
> Vincent Poy wrote:
> >
> > On Wed, 18 Jul 2001, Dima Dorfman wrote:
> >
> > > Vincent Poy <[EMAIL PROTECTED]> writes:
> > > > linking kernel.debug
> > > > linprocfs.o: In function `_linprocfs_mount':
> > > > /usr/src/sys/compat/linprocfs/linprocfs.c:748: u
Vincent Poy wrote:
>
> On Wed, 18 Jul 2001, Dima Dorfman wrote:
>
> > Vincent Poy <[EMAIL PROTECTED]> writes:
> > > linking kernel.debug
> > > linprocfs.o: In function `_linprocfs_mount':
> > > /usr/src/sys/compat/linprocfs/linprocfs.c:748: undefined reference to
> > > `pfs_mount'
> >
> > You co
On Wed, 18 Jul 2001, Dima Dorfman wrote:
> Vincent Poy <[EMAIL PROTECTED]> writes:
> > linking kernel.debug
> > linprocfs.o: In function `_linprocfs_mount':
> > /usr/src/sys/compat/linprocfs/linprocfs.c:748: undefined reference to
> > `pfs_mount'
>
> You compiled in linprocfs but not pseudofs. D
Vincent Poy <[EMAIL PROTECTED]> writes:
> linking kernel.debug
> linprocfs.o: In function `_linprocfs_mount':
> /usr/src/sys/compat/linprocfs/linprocfs.c:748: undefined reference to
> `pfs_mount'
You compiled in linprocfs but not pseudofs. Don't do that: the former
depends on the latter.
To Uns
linking kernel.debug
linprocfs.o: In function `_linprocfs_mount':
/usr/src/sys/compat/linprocfs/linprocfs.c:748: undefined reference to
`pfs_mount'
linprocfs.o: In function `_linprocfs_init':
/usr/src/sys/compat/linprocfs/linprocfs.c:748: undefined reference to
`pfs_init'
linprocfs.o: In function
Anyone else experiencing this?
I am cvsupping right now, and see no changes today to the network stack or to routed.
jim
--
ET has one helluva sense of humor!
He's always anal-probing right-wing schizos!
_
Do You Yahoo!?
Get your free @ya
Well, damn.
I've run it through a couple of reboots with a fresh current SMP
kernel and it boots like a champ...
Where were you a couple of weeks ago when I started trying to solve
this problem? ;-) At least I learned a lot about debugging kernels...
thanks for your guess!
dave c
> This is
On Wed, 18 Jul 2001, Garance A Drosihn wrote:
> At 11:18 PM -0700 7/17/01, Peter Wemm wrote:
> >If I had to guess, I'd put the total [genuine] -current userbase
> >at between 20 and 50 people. And many of those intentionally lag
> >by a few weeks to a month or two.
>
> At the kernel-confab at us
At 11:18 PM -0700 7/17/01, Peter Wemm wrote:
>If I had to guess, I'd put the total [genuine] -current userbase
>at between 20 and 50 people. And many of those intentionally lag
>by a few weeks to a month or two.
At the kernel-confab at usenix, I heard some people talking about
how "current wasn'
In message <[EMAIL PROTECTED]>, Bruce Ev
ans writes:
>On Tue, 17 Jul 2001, Ian Dowse wrote:
>> effect in the load calculation, but even for the shorter 5-minute
>> timescale, this will average out to typically no more than a few
>> percent (i.e the "5 minutes" will instead normally be approx 4.8
>
* Matthew Jacob <[EMAIL PROTECTED]> [010718 16:56] wrote:
>
> Still on by default.
In my queue then.
--
-Alfred Perlstein [[EMAIL PROTECTED]]
Ok, who wrote this damn function called '??'?
And why do my programs keep crashing in it?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscr
Still on by default.
On Wed, 18 Jul 2001, Alfred Perlstein wrote:
> * Matthew Jacob <[EMAIL PROTECTED]> [010718 16:33] wrote:
> >
> > So, I took a SCSi disk away. Diskcheckd started complaining. However,
> > a camcontrol rescan couldn't make the disk go away until I killed off
> > diskcheckd,
Hello all,
before leaving for vacation next week, i thought i'd put up the result
of my work of the last couple of weeks for a review for those who are
interested.
The patch itself is available at
http://people.freebsd.org/~joerg/fdpatch.txt.gz
The following README file (see below) is also ava
* Matthew Jacob <[EMAIL PROTECTED]> [010718 16:33] wrote:
>
> So, I took a SCSi disk away. Diskcheckd started complaining. However,
> a camcontrol rescan couldn't make the disk go away until I killed off
> diskcheckd, which then closed the disk, allowing the rescan to remove it.
> Bad. Bad. Bad.
So, I took a SCSi disk away. Diskcheckd started complaining. However,
a camcontrol rescan couldn't make the disk go away until I killed off
diskcheckd, which then closed the disk, allowing the rescan to remove it.
Bad. Bad. Bad.
ev/da4
Jul 18 14:31:15 diskcheckd[202]: error reading 512 bytes fro
Hello -
This leave patche gets rid of white space before the input, and after the +,
if there is one.
I also moved the #define's to the top of the source file, and change 1 to
STDOUT_FILENO.
The patch is included with this email, and is available online at
In article <[EMAIL PROTECTED]>,
Dave Cornejo <[EMAIL PROTECTED]> wrote:
> I have isolated the point at which current no longer runs as Jan 31 -
> Feb 1 of this year. Prior version work fine, in Feb & Mar I get
> either "Kernel trap 9 with interrupts disabled" or I think the same
> thing with tra
The port netpbm builds and installs fine on current.
When trying to build the docs in /usr/docs the program peps calls
/usr/local/bin/pnmtopng
This is from the netpbm port.
(/usr/local/bin)505}./pnmtopng
/usr/libexec/ld-elf.so.1: /usr/lib/crtn.o: unsupported file type
(/usr/local/bin)506} ldd
hi, there!
On Tue, 17 Jul 2001, Garance A Drosihn wrote:
> >Personally, I think it's worth it to get rid of a GNU dependency
> >in the base system, as well as reducing the overall amount of
> >functional code duplication.
>
> I may be misunderstanding what you mean here, but I don't think
> we
In article
[EMAIL PROTECTED]> you
write:
>As far as I understand, the entire 1M bytes of lower physical memory
>is supposed to be mapped when vm86_intcall() is run. Apparently
>0xc, where the video BIOS ROM resides, is mapped OK. But, somehow
>0xa, where the video ram is, went missing.
On Wed, Jul 18, 2001 at 10:17:25AM -0700, Terry Lambert wrote:
> Maxim Sobolev wrote:
> > > > I vote this too. We don't need stripped down libreadline under
> > > > 'libreadline' name pretend to be full version (f.e. for autoconf, etc.)
> > >
> > > The cryptography libraries have set a precedent h
On Wed, Jul 18, 2001 at 10:18:06AM -0700, Brooks Davis wrote:
> I've been seeing the following failure in my installworlds for the past
> week or so. I've been getting around it with make -k, but it's kinda
> annoying. Just now I took a look at etc/mtree/BSD.user.dist and noticed
> that the dire
I've been seeing the following failure in my installworlds for the past
week or so. I've been getting around it with make -k, but it's kinda
annoying. Just now I took a look at etc/mtree/BSD.user.dist and noticed
that the directory we're actualy creating is de_DE.ISO_8859-1 not
de_DE.ISO8859-1.
Maxim Sobolev wrote:
> > > I vote this too. We don't need stripped down libreadline under
> > > 'libreadline' name pretend to be full version (f.e. for autoconf, etc.)
> >
> > The cryptography libraries have set a precedent here. I
> > could argue the same thing about the presence of a full DES
>
Terry Lambert wrote:
> "Andrey A. Chernov" wrote:
> > > > Okay. So it sounds like there's a "shim" to libedit which would be
> > > > the API replacement for libreadline. Could we call that something
> > > > cute like 'libreadlinele' ('le' for 'libedit') or 'libeditrl', but
> > > > leave libread
"Andrey A. Chernov" wrote:
> > > Okay. So it sounds like there's a "shim" to libedit which would be
> > > the API replacement for libreadline. Could we call that something
> > > cute like 'libreadlinele' ('le' for 'libedit') or 'libeditrl', but
> > > leave libreadline as a separate port?
> >
> >
What do people think of moving sys/kern/tty_snoop.c to
sys/dev/snp/snp.c? It doesn't belong in kern/; I'm guessing it was
put there originally because it was dependent on some custom hacks in
tty.c, but since those are gone I think there's no reason not to put
it where it belongs.
To Unsubscrib
On Wed, 18 Jul 2001, David Malone wrote:
> I would have thought that any file included with
>
> #include <...>
>
> would count as a system header file, but it seems gcc has some
> other criteron for deciding. I've managed to trace it back to cpp
> writing out lines like:
>
> # 1 "/usr/include/
On Tue, 17 Jul 2001, Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Bruce Ev
> ans writes:
> >
> >I think that is far too much variation. 5 seconds is hard-coded into
> >the computation of the load average (constants in cexp[]), so even a
> >variation of +-1 ticks breaks the computation slig
> On Tue, Jul 17, 2001 at 07:55:18PM +0100, David Malone wrote:
> > I suspect that this is my fault for not doing a buildworld after
> > turning on WARNS stuff in inetd.
> YES! Why are you committing these "very easy to break the build, as
> we've seen" changes w/o full `make buildworld' testing
I am trying to track down a vm86 problem in -CURRENT. The trouble is
that this is an intermittent problem and is not always reproducible.
The last one I managed to capture was:
==
VESA: set_mode(): 24(18) -> 259(103)
VESA: abou
Greetings all:
I was originally running 20010618 -CURRENT and all
worked well. So I went and cvsup to the latest
-CURRENT on 20010716 and I did a make buildworld,
this process died with something about include.h so I
continued with just make in /usr/src and it finished
so I went to make buildk
33 matches
Mail list logo
