Re: no options COMPAT_43

2019-04-15 Thread Masanobu SAITOH
On 2019/04/16 6:21, Paul Goyette wrote: > On Mon, 15 Apr 2019, Paul Goyette wrote: > >> There may be some other option you have enabled which requires COMPAT_43 >> >> Try to boot your new kernel and use modstat(8) to see what other modules >> might require the compat_43 module. > > A quick

daily CVS update output

2019-04-15 Thread NetBSD source update
Updating src tree: P src/bin/sh/sh.1 P src/doc/CHANGES P src/external/bsd/jemalloc/lib/Makefile.inc P src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vfsops.c P src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c P src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_znode.c P

Automated report: NetBSD-current/i386 build success

2019-04-15 Thread NetBSD Test Fixture
The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2019.04.15.22.37.13 gutteridge src/usr.sbin/cpuctl/cpuctl.8,v 1.19 2019.04.15.22.38.48 sevan src/share/examples/npf/host-npf.conf,v 1.9

Automated report: NetBSD-current/i386 build failure

2019-04-15 Thread NetBSD Test Fixture
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 2019.04.15.20.40.53. An extract from the build.sh output follows:

Re: no options COMPAT_43

2019-04-15 Thread Paul Goyette
On Mon, 15 Apr 2019, Paul Goyette wrote: There may be some other option you have enabled which requires COMPAT_43 Try to boot your new kernel and use modstat(8) to see what other modules might require the compat_43 module. A quick check on my recent amd64 build shows that compat_linux

Re: problems upgrading go112 (and go111) on NetBSD-8.99.32/amd64

2019-04-15 Thread Greg A. Woods
Thanks Benny for your suggestions! At Mon, 15 Apr 2019 13:57:18 +0200, Benny Siegert wrote: Subject: Re: problems upgrading go112 (and go111) on NetBSD-8.99.32/amd64 > > Try rebuilding lang/go14 perhaps? Yes, I've tried that a couple of times. I even tried re-installing a much older build of

Re: Funky Display Output:

2019-04-15 Thread John D. Baker
On Sat, 13 Apr 2019, John D. Baker wrote: > I suppose as an outlier data point, the intel driver works fine on an > ancient i82810e-based system with no DRM/KMS nor UMS at all. A machine with a real i82915 device works fine without any tweaks required, albeit I am not sure now if I updated this

Re: Mesa update

2019-04-15 Thread Patrick Welche
On Thu, Apr 11, 2019 at 04:54:03PM +, co...@sdf.org wrote: > On Thu, Apr 11, 2019 at 04:49:09PM +, co...@sdf.org wrote: > > argh. now I see it too. I had pkgsrc xorg in the middle and in the RPATH > > complicating testing :_/ > > Ah, disregard, I had the old libGL.so.3.0 (because I

Re: com(4) dialout device behavior change?

2019-04-15 Thread John D. Baker
On Mon, 15 Apr 2019, John D. Baker wrote: > I reverted these in my custom kernel config and my serial ports work > normally again (still need to revert the RTS/CTS loop in the adapter > to know for sure). Put adapter back to the original wiring and port still works properly. -- |/"\ John D.

Re: problems upgrading go112 (and go111) on NetBSD-8.99.32/amd64

2019-04-15 Thread Chavdar Ivanov
FYI I just rebuilt go112 using updated go14 as a bootstrap on two days old amd64 -current. On Mon, 15 Apr 2019 at 12:58, Benny Siegert wrote: > > Try rebuilding lang/go14 perhaps? > > You could also try editing lang/go112/Makefile and setting > GOROOT_BOOTSTRAP to /usr/pkg/go111. > > On Sun, Apr

Re: problems upgrading go112 (and go111) on NetBSD-8.99.32/amd64

2019-04-15 Thread Benny Siegert
Try rebuilding lang/go14 perhaps? You could also try editing lang/go112/Makefile and setting GOROOT_BOOTSTRAP to /usr/pkg/go111. On Sun, Apr 14, 2019 at 11:26 PM Greg A. Woods wrote: > > So, the following has been happening (and for go111), but I don't > understand the errors, nor have I any

Re: no options COMPAT_43

2019-04-15 Thread Paul Goyette
There may be some other option you have enabled which requires COMPAT_43 Try to boot your new kernel and use modstat(8) to see what other modules might require the compat_43 module. On Mon, 15 Apr 2019, Masanobu SAITOH wrote: Hi. I tried to make a kernel without COMPAT_43 from

no options COMPAT_43

2019-04-15 Thread Masanobu SAITOH
Hi. I tried to make a kernel without COMPAT_43 from conf/GENERIC. I added "no options COMPAT_43" at the end of conf/GENERIC or conf/GENERIC.local, but compile/GENERIC/opt_compat_43.h had: #define COMPAT_43 1 Is this behavior intended? When I added "no options COMPAT_43" twice,

Re: com(4) dialout device behavior change?

2019-04-15 Thread Martin Husemann
On Mon, Apr 15, 2019 at 01:17:52AM -0500, John D. Baker wrote: > Turns out there's something wrong with the: > > com* at acpi? Since those don't do much, please check how the acpi variants interrupt and whethere you get one of those interrupts ever. Not much point in bisecting this to a

Re: com(4) dialout device behavior change?

2019-04-15 Thread John D. Baker
On Sun, 14 Apr 2019, John D. Baker wrote: > As a sanity check, I booted -current GENERIC rather than the machine's > custom kernel and the serial port works fine (although I'm still using > the rewired adapter with RTS/CTS looped). Rebooting with the custom > kernel and it sends (because CTS is