NetBSD Test Fixture wrote:
> ERROR: nbctfmerge: Caught signal 15 - exiting
> Removing mdnsd
> --- dependall-sys ---
> ERROR: nbctfmerge: Caught signal 15 - exiting
> Removing v7fs.kmod
These "signal 15" errors were from me killing two ctfmerge processes
that had hung; they had
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2016.02.06.18.23.26.
An extract from the build.sh output follows:
# compile cc1plus/cc1plus-checksum.o
/tmp/b
Updating src tree:
P src/common/lib/libc/stdlib/random.c
P src/lib/libedit/chartype.h
P src/lib/libedit/read.c
P src/libexec/ld.elf_so/sysident.h
P src/share/mk/bsd.own.mk
P src/sys/arch/evbarm/conf/ldscript.evbarm
P src/sys/arch/sgimips/dev/crmfb.c
P src/sys/compat/ndis/subr_ntoskrnl.c
P src/sys/
Christos Zoulas wrote:
In article <20160208104744.ga11...@asim.lip6.fr>,
Manuel Bouyer wrote:
There is a call to pool. What happens is that it gets a POLLIN event
for both fd 3 (which really has data to read) and fd 4 (wich doesn't).
The read callback for fd 4 expects to be called only when
In article <20160208104744.ga11...@asim.lip6.fr>,
Manuel Bouyer wrote:
>There is a call to pool. What happens is that it gets a POLLIN event
>for both fd 3 (which really has data to read) and fd 4 (wich doesn't).
>
>The read callback for fd 4 expects to be called only when there's really
>data t
This problem was fixed by skrll@. Thanks!
http://mail-index.netbsd.org/source-changes/2016/02/08/msg072514.html
On 2016/02/08 5:40, Rin Okuyama wrote:
Hi,
Build for earm fails in libexec/ld.elf_so:
% ./build.sh -U -m evbearmv7hf-eb tools release
...
/var/build/tools/bin/nbctfconvert
On Mon, Feb 08, 2016 at 11:47:44 +0100, Manuel Bouyer wrote:
> On Sun, Feb 07, 2016 at 08:49:32PM +0100, Manuel Bouyer wrote:
> > On Sun, Feb 07, 2016 at 03:23:58PM +0100, Manuel Bouyer wrote:
> > > It looks like the read(2) syscall returns a EAGAIN when the caller
> > > expect it to block if ther
On Sun, Feb 07, 2016 at 08:49:32PM +0100, Manuel Bouyer wrote:
> On Sun, Feb 07, 2016 at 03:23:58PM +0100, Manuel Bouyer wrote:
> > It looks like the read(2) syscall returns a EAGAIN when the caller
> > expect it to block if there's no data available.
>
> I could capture the pipe setup before gett
