Re: troubles with buildworld/sendmail/sasl/clang

2013-03-21 Thread Claus Assmann
On Thu, Mar 21, 2013, Dimitry Andric wrote: > Use the port, or the attached patch, to disable usage of stdbool.h. It might be a better idea to change include/sm/os/sm_os_freebsd.h to set SM_CONF_STDBOOL_H See also libsm/README. ___ freebsd-stable@freeb

Re: new jail(8) ignoring devfs_ruleset?

2013-03-21 Thread Jamie Gritton
On 03/21/13 18:20, Miroslav Lachman wrote: Jamie Gritton wrote: On 03/21/13 17:59, Miroslav Lachman wrote: Jeremie Le Hen wrote: On Mon, Feb 18, 2013 at 09:54:42AM +0100, Harald Schmalzbauer wrote: schrieb Jamie Gritton am 16.02.2013 00:40 (localtime): On 02/15/13 09:27, Harald Schmalzbauer

Re: new jail(8) ignoring devfs_ruleset?

2013-03-21 Thread Miroslav Lachman
Jamie Gritton wrote: On 03/21/13 17:59, Miroslav Lachman wrote: Jeremie Le Hen wrote: On Mon, Feb 18, 2013 at 09:54:42AM +0100, Harald Schmalzbauer wrote: schrieb Jamie Gritton am 16.02.2013 00:40 (localtime): On 02/15/13 09:27, Harald Schmalzbauer wrote: Hello, like already posted, on 9.1-

Re: new jail(8) ignoring devfs_ruleset?

2013-03-21 Thread Jamie Gritton
On 03/21/13 17:59, Miroslav Lachman wrote: Jeremie Le Hen wrote: On Mon, Feb 18, 2013 at 09:54:42AM +0100, Harald Schmalzbauer wrote: schrieb Jamie Gritton am 16.02.2013 00:40 (localtime): On 02/15/13 09:27, Harald Schmalzbauer wrote: Hello, like already posted, on 9.1-R, I highly appreciate

Re: new jail(8) ignoring devfs_ruleset?

2013-03-21 Thread Miroslav Lachman
Jeremie Le Hen wrote: On Mon, Feb 18, 2013 at 09:54:42AM +0100, Harald Schmalzbauer wrote: schrieb Jamie Gritton am 16.02.2013 00:40 (localtime): On 02/15/13 09:27, Harald Schmalzbauer wrote: Hello, like already posted, on 9.1-R, I highly appreciate the new jail(8) and jail.conf capabili

Re: troubles with buildworld/sendmail/sasl/clang

2013-03-21 Thread Dimitry Andric
On Mar 21, 2013, at 15:16, Anton Shterenlikht wrote: > Kimmo Paasiala writes: ... > > > > /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8: > > > error: incompatible pointer types passing 'void ()' to parameter > of type > > > 'void (*)(char *, b

Re: Core Dump / panic sleeping thread

2013-03-21 Thread Konstantin Belousov
On Thu, Mar 21, 2013 at 07:59:25PM +0100, Michael Landin Hostbaek wrote: > > On Mar 21, 2013, at 8:58 AM, Konstantin Belousov wrote: > > > On Wed, Mar 20, 2013 at 09:14:37PM -0400, Rick Macklem wrote: > >> Well, read/write sharing of files over NFS is pretty rare, so I suspect > >> a truncation

Re: Core Dump / panic sleeping thread

2013-03-21 Thread Michael Landin Hostbaek
On Mar 21, 2013, at 8:58 AM, Konstantin Belousov wrote: > On Wed, Mar 20, 2013 at 09:14:37PM -0400, Rick Macklem wrote: >> Well, read/write sharing of files over NFS is pretty rare, so I suspect >> a truncation of a file by another client (or locally in the NFS server) >> is a rare event. As suc

Re: Panic : bad pte

2013-03-21 Thread David Demelier
Le mercredi 20 mars 2013 20:09:42 David Demelier a écrit : > 2013/3/19 Jeremy Chadwick : > > On Tue, Mar 19, 2013 at 06:34:24PM +0100, David Demelier wrote: > >> Hello, > >> > >> There it is, all my computers on FreeBSD 9.1-RELEASE had panic. I can > >> just say there is a problem in the 9.1-RELEA

Re: troubles with buildworld/sendmail/sasl/clang

2013-03-21 Thread Anton Shterenlikht
Kimmo Paasiala writes: > > =buildworld=== > > > > /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8: > > error: incompatible pointer types passing 'void ()' to parameter of type > > 'void (*)(c

Re: troubles with buildworld/sendmail/sasl/clang

2013-03-21 Thread Robert Huff
Kimmo Paasiala writes: > > =buildworld=== > > > > /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8: > > error: incompatible pointer types passing 'void ()' to parameter of type > > 'void (*)(char *, bool, MAILER *, struct mailer_con_info *,

Re: Core Dump / panic sleeping thread

2013-03-21 Thread Konstantin Belousov
On Wed, Mar 20, 2013 at 09:14:37PM -0400, Rick Macklem wrote: > Well, read/write sharing of files over NFS is pretty rare, so I suspect > a truncation of a file by another client (or locally in the NFS server) > is a rare event. As such, not invalidating the buffers here doesn't seem > like a big i