-On [20010129 07:25], [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
>In article <[EMAIL PROTECTED]> you wrote:
> It seems to me that the same kind of libisc dependency
>must be provided for 'libexec/named-xfer', because it now stops
>buildworld with the 'isc_movefile' unresolved message.
Cor
Konnichiwa wa MATSUDA-san,
-On [20010129 07:40], Munehiro Matsuda ([EMAIL PROTECTED]) wrote:
>Buildworld failed with following error:
>
>cc -O -pipe -I/usr/src/libexec/named-xfer/../../contrib/bind/port/freebsd/include
>-I/usr/src/libexec/named-xfer/../../contrib/bind/bin/named
>-I/usr/src/lib
/etc/shells is such a simple file, I don't see much of point in
polluting it. There is not much of difference having a port install:
target edit /etc/shells verses editing /usr/local/etc/shells. It
should just edit /etc/shells.
-M
Latest -CURRENT died with this error messages:
--
/usr/src/lib/libc_r/uthread/uthread_aio_suspend.c: In function `_aio_suspend':
/usr/src/lib/libc_r/uthread/uthread_aio_suspend.c:45: warning: passing arg 1 of
`__sys_aio_suspend' discards qualifiers from pointer target type
/usr/src/lib/libc_r/ut
On Sun, 28 Jan 2001 23:53:50 -0500
"Louis A. Mamakos" <[EMAIL PROTECTED]> wrote:
LM> It doesn't seem unreasonable to have a single file with a list of allowable
LM> shells.
One thing - it is kind of cute having the allowable shells match
the mounted shells.
To Unsubscribe: send mail t
On Sun, 28 Jan 2001 22:19:29 -0800 (PST)
John Baldwin <[EMAIL PROTECTED]> wrote:
JB> People whine about the problem though, so having no solution doesn't
JB> help either. Since #include is syntatically a comment, it shouldn't
JB> mess up other programs, though the idea is that they will all use
Hi,
Buildworld failed with following error:
cc -O -pipe -I/usr/src/libexec/named-xfer/../../contrib/bind/port/freebsd/include
-I/usr/src/libexec/named-xfer/../../contrib/bind/bin/named
-I/usr/src/libexec/named-xfer/../../contrib/bind/include -I.-o named-xfer
named-xfer.o db_glue.o ns_glu
In article <[EMAIL PROTECTED]> you wrote:
> asmodai 2001/01/28 15:21:00 PST
>
> Modified files:
>usr.sbin/named Makefile
> Log:
> Add static dependency on libisc.a to get isc_movefile() on which named
> now depends. This keeps named the same as before the import, that is: only
On 29-Jan-01 Louis A. Mamakos wrote:
>> On Sun, Jan 28, 2001 at 10:13:49AM +0100, Steve O'Hara-Smith wrote:
>> >Hi,
>> >
>> >Asbestos suit on, round two.
>> >
>> >The patch below changes getusershell to support a #include syntax
>> > in /etc/shells.
>>
>> I guess this is what I ob
On 29-Jan-01 John Indra wrote:
> I noticed that DEVFS has been the default in GENERIC kernel. I have been
> -CURRENT tracker for the past couple of months and things like DEVFS is
> still new to me. Thus, a couple of questions arise and I am very glad if
> someone want to explain it to me, or may
In message <[EMAIL PROTECTED]>, John Indra writes:
>I noticed that DEVFS has been the default in GENERIC kernel. I have been
>-CURRENT tracker for the past couple of months and things like DEVFS is
>still new to me. Thus, a couple of questions arise and I am very glad if
>someone want to explain i
On a current from last Sunday I recompiled
a new kernel with just makeoptions DEBUG=-g
and options DDB added to GENERIC and when
I boot I see the first few spins of the loader
booting the kernel and then all video output stops.
After the boot finishs I get a login prompt but no
keyboard response
> On Sun, Jan 28, 2001 at 10:13:49AM +0100, Steve O'Hara-Smith wrote:
> > Hi,
> >
> > Asbestos suit on, round two.
> >
> > The patch below changes getusershell to support a #include syntax
> > in /etc/shells.
>
> I guess this is what I object to. I don't particularly like having
On 2001-Jan-27 00:33:23 -0800, Root Dude <[EMAIL PROTECTED]> wrote:
>I've broken the proc structure into 4 structures.
Leaving aside the issue of whether or your efforts were a waste of time,
I have some comments on the ordering of fields. Since the fields are
being re-arranged anyway, I'd like
On Sun, Jan 28, 2001 at 18:15 +0200, Paul Allenby wrote:
> "Rogier R. Mulhuijzen wrote:"
> >
> > >For the last week, each kernel built with fresh source code
^^^
> > >cannot exec sh. I've seen a lot of emails about this, but
> > >most w
I noticed that DEVFS has been the default in GENERIC kernel. I have been
-CURRENT tracker for the past couple of months and things like DEVFS is
still new to me. Thus, a couple of questions arise and I am very glad if
someone want to explain it to me, or maybe point to docs that I should read.
1.
On Sun, Jan 28, 2001 at 01:28:03PM -0600, Patrick Hartling wrote:
> ldd was telling me that it had both libc.so.3 and libc.so.5 which seemed
> very bad to me. When I recomipled LyX to see if that would fix things,
> I noticed that ld was giving a warning about libc.so.3 and libc.so.5
> potential
On Sun, Jan 28, 2001 at 10:13:49AM +0100, Steve O'Hara-Smith wrote:
> Hi,
>
> Asbestos suit on, round two.
>
> The patch below changes getusershell to support a #include syntax
> in /etc/shells.
I guess this is what I object to. I don't particularly like having a
new direct
On Sun, Jan 28, 2001 at 06:15:46PM +0200, Paul Allenby wrote:
> "Rogier R. Mulhuijzen wrote:"
> >
> >
> > >For the last week, each kernel built with fresh source code
> > >cannot exec sh. I've seen a lot of emails about this, but
> > >most were about the "correct" way to rebuild a system.
> > >I
Jake Burkholder wrote:
>
> > Bruce Evans wrote:
> > >
> > > The new gensetdefs gives unbootable kernels on i386's. They hang before
> > > printing anything.
> >
> > I verified that the output of gensetdefs.pl is identical to that of
> > gensetdefs(1). Does the kernel boot if gensetdefs(1) is use
Hi,
I wonder if anyone noticed that segfault messages are no longer appended
to the dmesg output. For me it looks like serious POLA violation. The
following script highlights the problem:
--- kaboom.sh ---
#!/bin/sh
dmesg -a > dmesg.old
cat > tst.c << EOF
#include
main () { return strlen((char
> Bruce Evans wrote:
> >
> > The new gensetdefs gives unbootable kernels on i386's. They hang before
> > printing anything.
>
> I verified that the output of gensetdefs.pl is identical to that of
> gensetdefs(1). Does the kernel boot if gensetdefs(1) is used?
>
Its not identical here, gensetd
Bruce Evans wrote:
>
> The new gensetdefs gives unbootable kernels on i386's. They hang before
> printing anything.
I verified that the output of gensetdefs.pl is identical to that of
gensetdefs(1). Does the kernel boot if gensetdefs(1) is used?
--
Marcel Moolenaar
mail: [EMAIL PROTECTED] /
>I also have a problem with my laptop that built world at the same
>time. Because
>of the above, I decided to restart it to put the kernel and programs in
>sync to
>see if that was causing the error. Murphy caught me in the act and my laptop
>now hangs on boot:-( I haven't tried rebooting an
Bruce Evans <[EMAIL PROTECTED]> writes:
> man(1) was broken in rev.1.39 of src/gnu/usr.bin/man/man/man.c:
Argh! I didn't test it with LC_* unset. Will fix.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the b
Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote:
} -On [20010127 22:30], Patrick Hartling ([EMAIL PROTECTED]) wrote:
} >Making a symlink from /usr/lib/libc.so.5 to /usr/lib/libc.so.3 seems to
} >have fixed my LyX problems. I'm guessing libc.so.5 and libc.so.3 were
} >causing conflicts, e
With this morning's make world, I get the following error with man. I've checked
six different machines with slightly different cvsup and build times and using
different cvsup locations. They all coincide.
FreeBSD dsl.mexcomusa.net 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Fri Jan 19
07:52:22 PST 2001
Hi,
Jake Burkholder wrote:
>Could you try this patch and let me know if it changes anything?
>
>Index: i386/isa/intr_machdep.c
>===
>RCS file: /home/ncvs/src/sys/i386/isa/intr_machdep.c,v
>retrieving revision 1.46
>diff -u -r1.46 int
The new gensetdefs gives unbootable kernels on i386's. They hang before
printing anything.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
"Rogier R. Mulhuijzen wrote:"
>
>
> >For the last week, each kernel built with fresh source code
> >cannot exec sh. I've seen a lot of emails about this, but
> >most were about the "correct" way to rebuild a system.
> >Is this a problem affecting only me?
>
> I haven't had any trouble.
>
> How
>For the last week, each kernel built with fresh source code
>cannot exec sh. I've seen a lot of emails about this, but
>most were about the "correct" way to rebuild a system.
>Is this a problem affecting only me?
I haven't had any trouble.
How do you rebuild your system? What is the exact erro
..somebody's trying to sneak in our frat and it ain't gonna be
nothing like that!! As a member of the same subscriber club YOU
JUST GOTTA SEE THIS FRAT MOVIE at http://www.frat-movie.com
I personally think each and every one of us must see it! SUPPORT
BLACK MOVIES! This one IS A MUST SEE!
1
Hi all
For the last week, each kernel built with fresh source code
cannot exec sh. I've seen a lot of emails about this, but
most were about the "correct" way to rebuild a system.
Is this a problem affecting only me?
Paul
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd
On Fri, 26 Jan 2001, Julian Elischer wrote:
> how 'current' are your systems?
> when did this behaviour start?
> (i.e. before or after the latest round of netgraph changes?)
it is before new netgraph...
i think the new netgraph cause the same problem as well..
To Unsubscribe: send mail to [E
-On [20010127 22:30], Patrick Hartling ([EMAIL PROTECTED]) wrote:
>Making a symlink from /usr/lib/libc.so.5 to /usr/lib/libc.so.3 seems to
>have fixed my LyX problems. I'm guessing libc.so.5 and libc.so.3 were
>causing conflicts, especially with the recent changes to libc, but I'm no
>expert. Wh
BTW Mark, your mail server is somehow incompatible with my ISP..
error message follows:
Hi. This is the qmail-send program at syncopation-01.iinet.net.au.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn'
Mark Murray 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 any lists that anyone was doing this
> > 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 any lists that anyone was doing this yet and thought I'd get
> the
Jason Evans wrote:
>
> On Sat, Jan 27, 2001 at 12:33:23AM -0800, Root Dude wrote:
> >
> > Here's a first step.
>
> This is very disappointing, Julian. You've duplicated work that I've
> already done, and if you've been paying attention at all, you know that it
> was already done. Even if you h
I'm running -current source from 26th Jan 2001 on an alpha and
getting the following error:
# ps -j
ps: sess: keyword not found
USER PID PPID PGID JOBC STAT TT TIME COMMAND
root 367 364 3671 DWp00:00.02 msu (su2)
root 368 367 3681 DW+ p00:00.14 -csh (tc
Hi,
Asbestos suit on, round two.
The patch below changes getusershell to support a #include syntax
in /etc/shells. It is against RELENG_4 and may require a bit of fiddling
to apply to -current (because of nsdispatch()).
Everything that I can find is using it (wel
Poul-Henning Kamp wrote:
>
> In message <[EMAIL PROTECTED]>, Root Dude writes:
> >
> >Here's a first step.
> >
> >I've broken the proc structure into 4 structures. [...]
>
> Uhm Julian,
>
> You are aware that other people are working on this stuff too ?
well considering that I was int he disc
Idea Receiver wrote:
>
> One of my current machines here are running PPPoE..
> for some reason, it will some times become extramly lag of its PPPoE
> connection. (for example, from 25ns ping time become 2500ns ping
> time). And will back to normal in few mins..
> However, i do not see the same pr
man(1) was broken in rev.1.39 of src/gnu/usr.bin/man/man/man.c:
$ man ls
Syntax error: "(" unexpected (expecting ")")
Error executing formatting or display command.
system command exited with status 512
Syntax error: "(" unexpected (expecting ")")
Error executing formatting or display command.
sy
44 matches
Mail list logo