daily CVS update output

2018-09-28 Thread NetBSD source update
Updating src tree: P src/crypto/external/bsd/openssl/lib/libcrypto/arch/powerpc64/ec.inc P src/distrib/acorn32/cdroms/installcd/Makefile P src/distrib/alpha/cdroms/installcd/Makefile P src/distrib/amd64/cdroms/installcd/Makefile P src/distrib/amiga/cdroms/installcd/Makefile P

Automated report: NetBSD-current/i386 build failure

2018-09-28 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 2018.09.28.23.40.45. An extract from the build.sh output follows: --- cleandir-libexec --- --- __doclean ---

Re: Problems using cvs after last update

2018-09-28 Thread maya
On Fri, Sep 28, 2018 at 09:03:08PM +0100, Arthur Barlow wrote: > I am using Current amd64. Last Friday, (the 22nd of September), I updated > my /usr/src directory with anonymous cvs and recompiled the lastest > distribution and kernel build. After rebooting and updating all my files > with

Re: progress(1) and "*.tar.xz" sets

2018-09-28 Thread Joerg Sonnenberger
On Fri, Sep 28, 2018 at 12:58:52PM -0500, John D. Baker wrote: > Has any consideration been given to augmenting the 'progress(1)' utility > to handle more compression formats than just "gzip"? You are aware that it doesn't work very well for gzip itself? I.e. the header it depends on is truncated

progress(1) and "*.tar.xz" sets

2018-09-28 Thread John D. Baker
Has any consideration been given to augmenting the 'progress(1)' utility to handle more compression formats than just "gzip"? When updating, I have been in the habit of using something like: for file in foo.tgz bar.tgz ; do progress -ezf $file tar xpf - -C /targetdir done With the

Re: "libmpfr.so.4" not found

2018-09-28 Thread Patrick Welche
libmpfr might be a read herring: cd /usr/src/tools/xz-include make dependall and configure ends with: + ac_val=/usr/src/tools/xz-include/../../external/public-domain/xz/dist + for ac_var=subdirs + eval 'ac_val=$subdirs' + ac_val='' + for ac_var=sysconfdir + eval 'ac_val=$sysconfdir' +

"libmpfr.so.4" not found

2018-09-28 Thread Patrick Welche
On one -current/amd64 box, I see e.g. --- bt_close.d --- /usr/src/tools/host-mkdep/obj/host-mkdep -f bt_close.d.tmp -- -I. -I./include -I/usr/src/tools/compat -I/usr/sr c/tools/compat/sys -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D__DBINTERFACE_PRIVATE /usr/src/tools/compat/

panic with NPF tables and debug/lockdebug on amd64

2018-09-28 Thread Geoff Wing
Hi, I'm seeing a kassert panic with NPF tables and kernel options DEBUG/LOCKDEBUG config: include "arch/amd64/conf/GENERIC" options DEBUG options LOCKDEBUG My /etc/npf.conf has tables with type hash and type tree Does anyone else have this

Re: sysutils/lsof stopped working for non-root user

2018-09-28 Thread Chavdar Ivanov
whereas fstat still works on OpenBSD: --- $ doas pkg_add lsof doas (x...@o62.lorien.lan) password: quirks-2.367 signed on 2017-10-03T11:21:28Z Can't find lsof Obsolete package: lsof (ancient software that doesn't work) <<= $ fstat|head -5 USER CMD PID FD MOUNT

Re: sysutils/lsof stopped working for non-root user

2018-09-28 Thread Chavdar Ivanov
I personally don't care much; while I can admit to using it from time to time (and recompiling it whenever osabi changes, as I usually run -current), I try to think about a scenario whereby a non-root user is expected to use it, perhaps in a script not under his control. It kinda seems logical and

Re: sysutils/lsof stopped working for non-root user

2018-09-28 Thread maya
On Thu, Sep 27, 2018 at 07:34:25PM -0700, John Nemeth wrote: > On Sep 27, 2:56pm, Christos Zoulas wrote: > } On Sep 27, 8:51am, ci4...@gmail.com (Chavdar Ivanov) wrote: > } > } | So is this expected and intended consequence, bug or still unfinished > } | part of the project? Just curious (it