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
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 ---
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
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
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
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'
+
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/
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
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
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
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
11 matches
Mail list logo