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, co
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 conf/GENERIC
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. Bak
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 unpacke
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 m
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 requir
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:
/tmp/bracket/build/2019.04.15.20.40.53-i386/tools
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
2019.04.15.23
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 src/externa
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 check
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 clu
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
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 it
13 matches
Mail list logo