Updating src tree:
P src/dist/pf/sbin/pflogd/pflogd.c
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/external/gpl3/gdb/dist/gnulib/configure
P src/external/gpl3/gdb/dist/gnulib/import/m4/rename.m4
U src/external/gpl3/gdb/lib/libb
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 2023.08.19.22.58.15.
An extract from the build.sh output follows:
# install /tmp/build/2023.08.19.22.58.15-i386/d
This is an automatically generated notice of new failures of the
NetBSD test suite.
The newly failing test cases are:
net/ipsec/t_ipsec_gif:ipsec_gif_ipv4_transport_ah_hmacsha512
net/ipsec/t_ipsec_gif:ipsec_gif_ipv4_transport_ah_null
net/ipsec/t_ipsec_gif:ipsec_gif_ipv4_transport_esp_
Now that the MKCROSSGDB and new libpcap issues seem to have been ironed
out, my builds (all arches) have resumed failing due to the following
(evbmips-mips64el shown, sparc, macppc, dreamcast, i386, amd64 show the
same failure):
[...]
#create fs/Atffile
dependall ===> tests/rump
dependall ===
The NetBSD-current/i386 build is working again.
The following commits were made between the last failed build and the
first successful build:
2023.08.19.14.22.41 rjs src/distrib/sets/lists/base/shl.mi 1.963
2023.08.19.14.22.41 rjs src/distrib/sets/lists/debug/shl.mi 1.323
Logs can be fou
Paul Ripke writes:
>> That seems a little excessive, to my eye? Is this "normal"? Having >1/4 of
>> RAM
>> apparently used mostly for file metadata, if I'm reading this correctly? I
>> don't recall the usage under -9, unfortunately, but I also never had a reason
>> to look.
In general, kernel m
Paul Ripke writes:
> Following up, I see buf2k allocated when I run 'git status' under
> netbsd/pkgsrc,
> netbsd/src, etc repos. I also see growth during /etc/daily. The filesystem is
> ffsv2 with log, on raidframe raid1 of wd[01]a.
You might try setting kern.maxvnodes to 64 and then back and s