For a few days now I'm unable to compile -current modules on Alpha
either natively or cross-compiled due to the following error:
--- dependall-compat_crypto_50 ---
/raid/src/sys/opencrypto/ocryptodev.h: In function 'ocryptof_ioctl':
/raid/src/sys/opencrypto/ocryptodev.c:284:16: error: 'os_op.ses'
On Thu, Jan 16, 2020 at 12:03:27AM -0800, David Hopper wrote:
> For a few days now I'm unable to compile -current modules on Alpha
> either natively or cross-compiled due to the following error:
>
> --- dependall-compat_crypto_50 ---
> /raid/src/sys/opencrypto/ocryptodev.h: In function 'ocryptof_i
On Thu, 2020-01-16 at 09:17 +0100, Martin Husemann wrote:
> On Thu, Jan 16, 2020 at 12:03:27AM -0800, David Hopper wrote:
> > For a few days now I'm unable to compile -current modules on Alpha
> > either natively or cross-compiled due to the following error:
> >
> > --- dependall-compat_crypto_50
Hi,
Robert Swindells wrote:
could it be that the combination
MKLLVM = no
HAVE_LLVM=no
MKLLVMRT = no
is not supported?
You could test this by building without those options, you should get a
gcc toolchain.
I use MKLLVMRT=no for several architectures and did a full build a
couple of days ago.
http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=54856
I want to notify of the above in case it hasn’t organically crossed the
proper paths... trying to build an install img is failing, and I know
there’s been a lot of sysinst and kernel structure churn lately, so if this
seems obvious or
Hi,
Today's update brought 9.99.38, which fails to boot on my HP Envy 17
laptop with Intel 530 graphics and NVidia GeForce; latter not used. The
system uses EFI boot and the panic happens the moment it has to switch
the console in graphics mode. I managed to collect a dump; the trace is
as follows
Hi,
On Thu, Jan 16, 2020 at 06:14:40PM +, Chavdar Ivanov wrote:
> Today's update brought 9.99.38, which fails to boot on my HP Envy 17
> laptop with Intel 530 graphics and NVidia GeForce; latter not used. The
> system uses EFI boot and the panic happens the moment it has to switch
> the conso
Ok, thanks.
On Thu, 16 Jan 2020 at 22:17, Andrew Doran wrote:
>
> Hi,
>
> On Thu, Jan 16, 2020 at 06:14:40PM +, Chavdar Ivanov wrote:
>
> > Today's update brought 9.99.38, which fails to boot on my HP Envy 17
> > laptop with Intel 530 graphics and NVidia GeForce; latter not used. The
> > syst
I’ve got NetBSD-9.99.17 (amd64) installed and it has been running without any
problems which i have been using to work with NVMM. I do package builds on it
using pkgsrc-current and also do the build of wip/qemu-nvmm.
This morning I installed NetBSD-9.99.38 (Jan 15th build) on another disk. I
Updating src tree:
P src/common/lib/libc/arch/x86_64/string/memcmp.S
P src/external/bsd/libarchive/prepare-import.sh
P
src/external/bsd/libarchive/dist/libarchive/test/test_archive_write_set_format_filter_by_ext.c
P
src/external/bsd/libarchive/dist/libarchive/test/test_read_disk_directory_trave
FWIW, the last 'completely stable' -current on RPi 3B+ has been 9.99.17 as
well. I don't know what has happened, but there seem to be some
regressions from that time onward.
-Mike
On Thu, Jan 16, 2020 at 6:20 PM Robert Nestor wrote:
> I’ve got NetBSD-9.99.17 (amd64) installed and it has been
*[ 363906.7911703] unmounting file systems...[ 363909.1814446] unmounting
done[ 363909.1914472] rebootin[ 1.000] NetBSD/evbarm (fdt) booting
...[ 1.000] [ Kernel symbol table missing! ][ 1.000] pool
redzone disabled for 'kmem-8192'[ 1.000] Copyright (c) 1996, 1997,
1998, 199
On Thu, Jan 16, 2020 at 07:03:14PM -0600, Robert Nestor wrote:
> I’ve got NetBSD-9.99.17 (amd64) installed and it has been running without
> any problems which i have been using to work with NVMM. I do package builds
> on it using pkgsrc-current and also do the build of wip/qemu-nvmm.
>
> Thi
13 matches
Mail list logo
