On Sun, Oct 16, 2016 at 6:58 AM, Rin Okuyama
wrote:
> uniq(1) is currently broken:
>
> % cat test
> 1
> 12
> 1
> 1
> % uniq test
> 1
> 12
> 1
> 1
>
> This bug was introduced to uniq.c rev. 1.19,
>
> http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/uniq/uniq.c#rev1.19
>
Your p
Updating src tree:
U src/crypto/external/bsd/openssl/lib/libcrypto/arch/powerpc64/Makefile
U src/crypto/external/bsd/openssl/lib/libcrypto/arch/powerpc64/aes-ppc.S
U src/crypto/external/bsd/openssl/lib/libcrypto/arch/powerpc64/aes.inc
U src/crypto/external/bsd/openssl/lib/libcrypto/arch/powerpc64/
On Sat, Oct 15, 2016 at 05:02:50PM +, Michael van Elst wrote:
> kiyoh...@kk.iij4u.or.jp (KIYOHARA Takashi) writes:
>
> >By the way, how should I handle a sensor? Is interface of a Linux
> >compatible provide so that application of Linux can access?
> >Who is doing such work at present?
>
> S
uniq(1) is currently broken:
% cat test
1
12
1
1
% uniq test
1
12
1
1
This bug was introduced to uniq.c rev. 1.19,
http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/uniq/uniq.c#rev1.19
where the size of buffer and the length of line are mixed up.
Please apply the attached p
On 2016-10-15 22:49, Rin Okuyama wrote:
Build fails due to intrctl(8) on ARM, whose char is unsigned. Please
apply the attached patch.
Well, considering that getopt() is returning an int, whoever wrote that
code did it wrong. So this is a general bug that might affect everyone,
not just arm.
Build fails due to intrctl(8) on ARM, whose char is unsigned. Please
apply the attached patch.
Thanks,
Rin
--- src/usr.sbin/intrctl/intrctl.c.orig 2016-10-16 05:31:55.270511416 +0900
+++ src/usr.sbin/intrctl/intrctl.c 2016-10-16 05:32:14.437245115 +0900
@@ -118,7 +118,7 @@
void
The debug set list for mips architectures has not kept up with recent
changes. The following files are seen as "extra" when "MKDEBUG_LIB=yes"
(evbmips-mips64el):
./usr/libdata/debug/lib/libc_fp.so.0.0.debug
./usr/libdata/debug/usr/lib/64/libc_fp.so.0.0.debug
./usr/libdata/debug/usr/lib/libc_f
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 2016.10.15.16.46.14.
An extract from the build.sh output follows:
--- kern-XEN3_DOM0 ---
---
/tmp/bracket/build
kiyoh...@kk.iij4u.or.jp (KIYOHARA Takashi) writes:
>By the way, how should I handle a sensor? Is interface of a Linux
>compatible provide so that application of Linux can access?
>Who is doing such work at present?
Sensors are currently supported by the envsys framework.
There is nothing like th
Hi
I have support to Gumstix Pepper. Tested on my Pepper 43C.
https://store.gumstix.com/computers/pepper-43c.html
ToDo:
Multi touch screen (my tifb patch not commit yet)
On board Wifi (TI WiLink 8@sdmmc)
Sensors (Gyroscope, Accelerometer, Magnetmeter @iic[12])
also, Touch screen and DV
Hi
From: KIYOHARA Takashi
Date: Sun, 03 Jul 2016 20:05:06 +0900 (JST)
> Gumstix DuoVero (Crystal + Parlor) supports.
>
> https://store.gumstix.com/coms/duovero-coms.html
Commited.
ToDo
TWL6030's ADC
TWL6040
DVI
Thanks,
--
kiyohara
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 200
The NetBSD-current/i386 build is working again.
The following commits were made between the last failed build and the
successful build:
2016.10.15.11.34.30 christos src/distrib/sets/lists/comp/md.i386,v 1.159
2016.10.15.11.41.54 christos src/distrib/sets/lists/comp/ad.arm,v 1.74
2016.
On Sat, 15 Oct 2016 10:09:52 +0200 (CEST) Havard Eidnes
wrote:
> > And while I'm on a roll I might as well promote -P as well. I think
> > that unless you know what you are doing, -d and -P is probably
> > switches you always want to apply when you do cvs update.
>
> I agree -- that's why my ~/.c
> And while I'm on a roll I might as well promote -P as well. I think
> that unless you know what you are doing, -d and -P is probably
> switches you always want to apply when you do cvs update.
I agree -- that's why my ~/.cvsrc contains:
update -d -P
diff -u
rdiff -u
Regards,
- Håvard
14 matches
Mail list logo
