In article <20160821004610.GA1302@netbox.brkly.local.domain>,
Mike wrote:
>-=-=-=-=-=-
>
>Hi Folks.
>It seems to me that last changes in completly broke NetBSD's
>write support on it (in expected way, as it used to work for a very
> long time before). I started having troubles about 2 weeks ago.
Updating src tree:
P src/distrib/sets/sets.subr
P src/distrib/sets/lists/base/shl.mi
P src/distrib/sets/lists/debug/shl.mi
P src/distrib/sets/lists/tests/mi
P src/distrib/sets/lists/xbase/mi
P src/distrib/sets/lists/xbase/shl.mi
P src/distrib/sets/lists/xcomp/md.amd64
cvs update: `src/distrib/sets
The NetBSD-current/i386 build is working again.
The following commits were made between the last failed build and the
successful build:
2016.08.20.01.03.34 mrg
src/external/mit/xorg/server/xorg-server/Xext/Makefile,v 1.7
2016.08.20.01.03.34 mrg
src/external/mit/xorg/server/xorg-server/h
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.08.19.22.37.04.
An extract from the build.sh output follows:
obsolete_stand fix:
postinstall fixes passed:
Hi Folks.
It seems to me that last changes in completly broke NetBSD's
write support on it (in expected way, as it used to work for a very
long time before). I started having troubles about 2 weeks ago.
At that time, I was hoping that this is just a temporary issue in
-current, and probably will
=== 4 extra files in DESTDIR =
Files in DESTDIR but missing from flist.
File is obsolete or flist is out of date ?
--
./usr/lib/i386/libpci.so.2.1
./usr/lib/libpci.so.2.1
./usr/libdata/debug/usr/lib/i386/libpci.so.2.1.debug
./usr/libdata/debug/u
On Fri 19 Aug 2016 at 16:31:00 +1000, matthew green wrote:
> to test, simply pass -V HAVE_XORG_SERVER_VER=118 to build.sh or set
> it in mk.conf.
I recently filed a PR about weird mouse defects, which turned out to be
about left-handed mice. Some xorg 1.11.x version has a fix for this.
See http://
On Fri, 19 Aug 2016, Joerg Sonnenberger wrote:
> To slightly expand that. You don't need nsd if you just want to serve a
> few local host names for a local network. You only need nsd if you want
> to provide an authoritive DNS server. IMO that is a decently small use
> case that it doesn't justi
On Fri, Aug 19, 2016 at 09:55:48AM +0100, Roy Marples wrote:
> For example, I would use nsd on exactly one machine in my environment,
> my public facing DNS server which is exactly where it belongs.
>
> On the other hand, all my other BSD machines run unbound as a local
> caching resolver.
To sli
On 19/08/2016 07:16, Christos Zoulas wrote:
> - Needs additional components nsd, openDNSSEC, ldns to match bind's
> functionality
Maybe we should take a step back and consider what functionality we need
rather than trying to match bind.
For example, I would use nsd on exactly one machine in my
10 matches
Mail list logo