re: bozohttpd(8): Make SSL protocol version selection a runtime option.

2020-10-29 Thread matthew green
this looks much better.  if someone doesn't beat me too it, i'll
merge this in soon.

thanks!


.mrg.


daily CVS update output

2020-10-29 Thread NetBSD source update


Updating src tree:
P src/Makefile
P src/external/public-domain/sqlite/Makefile.inc
P src/external/public-domain/sqlite/lib/Makefile
P src/external/public-domain/sqlite/lib/sqlite3.pc.in
P src/lib/Makefile
P src/sys/arch/sparc64/sparc64/autoconf.c
P src/sys/arch/sparc64/sparc64/ofw_patch.c
P src/sys/arch/sparc64/sparc64/ofw_patch.h
P src/sys/dev/i2c/files.i2c
P src/sys/dev/i2c/pcagpio.c
U src/sys/dev/i2c/pcf8574.c
P src/sys/dev/wscons/wsconsio.h
P src/usr.bin/make/parse.c
P src/usr.bin/make/unit-tests/Makefile
P src/usr.bin/make/unit-tests/directive-export.mk
P src/usr.bin/make/unit-tests/vardebug.exp
P src/usr.bin/make/unit-tests/vardebug.mk
P src/usr.bin/make/unit-tests/varmod-gmtime.mk
P src/usr.bin/make/unit-tests/varmod-localtime.mk
P src/usr.bin/make/unit-tests/varmod-quote.mk
P src/usr.sbin/mopd/mopcopy/mopcopy.c

Updating xsrc tree:


Killing core files:




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  36848683 Oct 30 03:03 ls-lRA.gz


Automated report: NetBSD-current/i386 build success

2020-10-29 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:

2020.10.29.20.11.17 nia src/lib/Makefile,v 1.286

Logs can be found at:


http://releng.NetBSD.org/b5reports/i386/commits-2020.10.html#2020.10.29.20.11.17


Re: Automated report: NetBSD-current/i386 build failure

2020-10-29 Thread Andreas Gustafsson
nia wrote:
> It should be fixed already.

It's not, it's now failing earlier in the build:

  
http://releng.netbsd.org/b5reports/i386/commits-2020.10.html#2020.10.29.16.35.33

-- 
Andreas Gustafsson, g...@gson.org


Re: Automated report: NetBSD-current/i386 build failure

2020-10-29 Thread Robert Elz
Yes, your commit message arrived here while I was typing the message
containing my (obviously incorrect, and now discarded) patch, along
with the rant.

kre



Re: Automated report: NetBSD-current/i386 build failure

2020-10-29 Thread Rin Okuyama

On 2020/10/30 1:58, nia wrote:

It should be fixed already.


Please also try build for sun2, which does not support shlib;
All programs linked to libsqlite3 need -lm explicitly.

Thanks,
rin


Re: Automated report: NetBSD-current/i386 build failure

2020-10-29 Thread nia
It should be fixed already.


Re: Automated report: NetBSD-current/i386 build failure

2020-10-29 Thread Robert Elz
Date:Thu, 29 Oct 2020 15:53:25 + (UTC)
From:NetBSD Test Fixture 
Message-ID:  <160398680587.14474.16594358311982355...@babylon5.netbsd.org>


  | 
/tmp/build/2020.10.29.12.38.06-i386/tools/lib/gcc/i486--netbsdelf/9.3.0/../../../../i486--netbsdelf/bin/ld:
 /tmp/build/2020.10.29.12.38.06-i386/destdir/usr/lib/libsqlite3.so: undefined 
reference to `log'
  | collect2: error: ld returned 1 exit status
  | *** [dig] Error code 1
  | --- dependall-games ---
  | --- dependall-bin ---

It is possible that the following patch will fix this, but right now
I'm in the middle of something else, and cannot do a build to verify
that this is the right change.

Nia: please always do a build.sh release before committing any significant
change.   An efficient way for me, is to work on several (unrelated)
changes, then do one release build (and fix any problems and repeat) and
then when all is OK, go back to each of the updates and commit them
individually.   How many of those there should be depends upon how
much you're working on at once, but if needed, doing the first
release build (which sometimes takes a while if enough has changed)
while you're doing something else (like sleeping) can also help.

kre

Index: Makefile
===
RCS file: /cvsroot/src/external/public-domain/sqlite/bin/Makefile,v
retrieving revision 1.5
diff -u -r1.5 Makefile
--- Makefile14 Feb 2013 21:07:25 -  1.5
+++ Makefile29 Oct 2020 16:35:15 -
@@ -5,7 +5,7 @@
 SRCS=  shell.c
 
 DPADD+=${LIBSQLITE3} ${LIBEDIT} ${LIBTERIMINFO}
-LDADD+=-lsqlite3 -ledit -lterminfo
+LDADD+=-lsqlite3 -ledit -lterminfo -lm
 
 BINDIR=/usr/bin
 




Automated report: NetBSD-current/i386 build failure

2020-10-29 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 2020.10.29.12.38.06.

An extract from the build.sh output follows:

dependall ===> share/man/man4/man4.sandpoint
--- dependall ---
--- dependall-external ---
--- dependall-mpl ---

/tmp/build/2020.10.29.12.38.06-i386/tools/lib/gcc/i486--netbsdelf/9.3.0/../../../../i486--netbsdelf/bin/ld:
 /tmp/build/2020.10.29.12.38.06-i386/destdir/usr/lib/libsqlite3.so: undefined 
reference to `log'
collect2: error: ld returned 1 exit status
*** [dig] Error code 1
--- dependall-games ---
--- dependall-bin ---

The following commits were made between the last successful build and
the failed build:

2020.10.29.12.38.06 nia src/external/public-domain/sqlite/Makefile.inc,v 1.8

Logs can be found at:


http://releng.NetBSD.org/b5reports/i386/commits-2020.10.html#2020.10.29.12.38.06


Re: Etherip(4) interoperability with NetBSD-9?

2020-10-29 Thread Michael van Elst
buh...@nfbcal.org (Brian Buhrow) writes:

>1.  I don't remember if the networking stack in NetBSD-9 is multi-threaded
>or not.  Can someone say how much concurrency is available in the NetBSD-9
>stack?

The socket part of the stack runs concurrently also in older NetBSD versions,
the upper part is still running under a global lock unless you build a kernel 
with option NET_MPSAFE. That is experimental and probably not suited yet for
a production environment.


>2.  Is there a way to get the NetBSD-9 stack to speak to NetBSD-5.2 using
>the etherip(4) protocol without having to update the NetBSD-5.2 machines?

No idea about etherip. But you could probably do something similar with
just gre(4) or openvpn in bridge mode.

-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."