Hi,
Today I was trying to install bubblemon-dockapp from ports/sysutils,
and it failed to compile. I've made a small change in a source file
(one #include was missing), and have built it successfully.
My system was rebuilt on Dec 7 (5.0-RC), and ports cvsuped on Dec 6.
Could somebody please tell
On Sun, Dec 08, 2002 at 01:17:15PM +0100, Marc Recht wrote:
> Hi!
>
> While compiling some third-party code I got this:
> gcc -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE_=600
> -D_XOPEN_SOURCE_EXTENDED=1 test.c
> In file included from test.c:2:
> /usr/include/sys/file.h:130: syntax error before "u_
Hi,
Recently I've discovered that I cannot ssh to my box.
After looking at the console, I found the following
messages:
Dec 9 10:09:05 nostromo kernel: pid 63040 (sshd), uid 0: exited on signal 11
Dec 9 10:09:05 nostromo sshd[63038]: fatal: buffer_put_cstring: s == NULL
It seems to be a bug in
On Mon, Dec 09, 2002 at 05:49:31PM +0100, Jens Rehsack wrote:
> Can you check the core dump for backtrace and send that?
I doesn't generate a coredump. Any way to enforce it?
I've just tried Protocol version 1, and everything was
perfect. I'll try to figure out which part of sshd is
generating th
On Mon, Dec 09, 2002 at 11:11:28AM +0200, Vasyl S. Smirnov wrote:
> [...]
> Dec 9 10:09:05 nostromo kernel: pid 63040 (sshd), uid 0: exited on signal 11
> Dec 9 10:09:05 nostromo sshd[63038]: fatal: buffer_put_cstring: s == NULL
> [...]
Some info I didn't mention in the
On Mon, Dec 09, 2002 at 12:59:44PM -0800, Kris Kennaway wrote:
> > On Mon, Dec 09, 2002 at 05:49:31PM +0100, Jens Rehsack wrote:
> > > Can you check the core dump for backtrace and send that?
>
> sysctl kern.sugid_coredump=1
> sysctl kern.corefile=/tmp/%N.core (or somewhere else writable by an unp
Hi again.
One more strange thing I've just discovered about sshd - two
example ssh sessions:
1.
> ssh nostromo
Password:
Connection closed by 10.100.76.33
(and the same sig 11/fatal messages on the console)
2.
> ssh nostromo
Password:
Password:
Password:
[EMAIL PROTECTED]'s password:
[an
Hi,
I suppose I've found the reason for such a strange sshd
behaviour - the problem is I was using login classes in
my master.passwd. Man for master.passwd says that login
classes aren't implemented yet - strange, in 4-STABLE
they seem to be working fine. Can someone explain this?
(or give some UR
