daily CVS update output
Updating src tree: P src/distrib/sets/lists/tests/mi P src/distrib/utils/embedded/files/evbppc_wii_meta.xml P src/doc/3RDPARTY P src/etc/mtree/NetBSD.dist.tests U src/lib/libm/convertFreeBSD P src/sbin/blkdiscard/blkdiscard.8 P src/sbin/blkdiscard/blkdiscard.c P src/share/misc/style P src/sys/arch/evbppc/include/wii.h P src/sys/arch/evbppc/wii/autoconf.c P src/sys/arch/evbppc/wii/machdep.c P src/sys/arch/evbppc/wii/wii_locore.S P src/sys/dev/pci/ixgbe/ixgbe.c P src/sys/kern/sched_m2.c P src/tests/usr.bin/Makefile U src/tests/usr.bin/mtree/Makefile U src/tests/usr.bin/mtree/t_sets.sh Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 44379996 Jan 25 03:03 ls-lRA.gz
Re: Small mystery with grep -o -i
Kia ora koutou katoa, On Wed, 2024-01-24 at 22:13 +0100, Rhialto wrote: > T.. > he CHANGES file from upstream > https://git.savannah.gnu.org/git/grep.git > lists: > > ... > > related to commit 70e236167c3973fc428d2b5b297218fde9b68e73, committed > 2010-03-17 And the source browser is at. https://git.savannah.gnu.org/cgit/grep.git/commit/?id=70e236167c3973fc428d2b5b297218fde9b68e73 Ngā mihi, Lloyd
Automated report: NetBSD-current/i386 build success
The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the first successful build: 2024.01.25.01.43.58 mrg src/distrib/sets/lists/tests/mi 1.1301 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2024.01.html#2024.01.25.01.43.58
Automated report: NetBSD-current/i386 build failure
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon4.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2024.01.25.00.30.57.
An extract from the build.sh output follows:
cd /tmp/build/2024.01.25.00.30.57-i386/src/distrib/sets &&
DESTDIR=/tmp/build/2024.01.25.00.30.57-i386/destdir MACHINE=i386
MACHINE_ARCH=i386 AWK=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbawk
CKSUM=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbcksum
DB=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbdb
EGREP=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbgrep\ -E HOST_SH=/bin/sh
MAKE=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbmake
MKTEMP=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbmktemp
MTREE=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbmtree
PAX=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbpax COMPRESS_PROGRAM=gzip
GZIP=-n XZ_OPT=-9 TAR_SUFF=tgz
PKG_CREATE=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbpkg_create
SED=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbsed
TSORT=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbtsort\ -q /bin/sh
/tmp/build/2024.01.25.00.30.57-i386/src/distrib/sets/checkflist -L base -M
/tmp/build/2024.01.
25.00.30.57-i386/destdir/METALOG.sanitised
=== 2 extra files in DESTDIR =
Files in DESTDIR but missing from flist.
File is obsolete or flist is out of date ?
--
./usr/tests/usr.bin/mtree
./usr/tests/usr.bin/mtree/Atffile
= end of 2 extra files ===
*** Failed target: checkflist
*** Failed commands:
${_MKMSG_EXECUTE} "checkflist"
=> @echo '# ' "execute " "checkflist"
${SETSCMD} ${.CURDIR}/checkflist ${MAKEFLIST_FLAGS}
${CHECKFLIST_FLAGS} ${METALOG.unpriv}
=> cd /tmp/build/2024.01.25.00.30.57-i386/src/distrib/sets &&
DESTDIR=/tmp/build/2024.01.25.00.30.57-i386/destdir MACHINE=i386
MACHINE_ARCH=i386 AWK=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbawk
CKSUM=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbcksum
DB=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbdb
EGREP=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbgrep\ -E HOST_SH=/bin/sh
MAKE=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbmake
MKTEMP=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbmktemp
MTREE=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbmtree
PAX=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbpax COMPRESS_PROGRAM=gzip
GZIP=-n XZ_OPT=-9 TAR_SUFF=tgz
PKG_CREATE=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbpkg_create
SED=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbsed
TSORT=/tmp/build/2024.01.25.00.30.57-i386/tools/bin/nbtsort\ -q /bin/sh
/tmp/build/2024.01.25.00.30.57-i386/src/distrib/sets/checkflist -L base -M
/tmp/build/2024
.01.25.00.30.57-i386/destdir/METALOG.sanitised
*** [checkflist] Error code 1
nbmake[2]: stopped in /tmp/build/2024.01.25.00.30.57-i386/src/distrib/sets
nbmake[2]: 1 error
nbmake[2]: stopped in /tmp/build/2024.01.25.00.30.57-i386/src/distrib/sets
nbmake[1]: stopped in /tmp/build/2024.01.25.00.30.57-i386/src
nbmake: stopped in /tmp/build/2024.01.25.00.30.57-i386/src
ERROR: Failed to make release
The following commits were made between the last successful build and
the first failed build:
2024.01.25.00.30.57 riastradh src/distrib/sets/lists/tests/mi 1.1300
2024.01.25.00.30.57 riastradh src/etc/mtree/NetBSD.dist.tests 1.202
2024.01.25.00.30.57 riastradh src/tests/usr.bin/Makefile 1.39
2024.01.25.00.30.57 riastradh src/tests/usr.bin/mtree/Makefile 1.1
2024.01.25.00.30.57 riastradh src/tests/usr.bin/mtree/t_sets.sh 1.1
Logs can be found at:
http://releng.NetBSD.org/b5reports/i386/commits-2024.01.html#2024.01.25.00.30.57
Small mystery with grep -o -i
I came across a configure script that used this test: echo 'alma,korte,banan' | grep -oEia ',K[^,]+,' and expected the result to be ,korte, That looks fine: -o prints only the matching part from the line -E selects egrep syntax, which allows the + operator -i makes it case-insensitive, so that ,k matches ,K -a makes grep assume the input is ascii, which is a no-op here. However, on 9.3 it prints nothing. On 10.0_RC3, the same. By trying simpler versions, it appears it is the combination -o -i that causes the problem. If you leave out -i, and adjust pattern and input to have matching case, then the test case works. Another simplification, omitting -E and replacing + by *, has no effect. If you use another way to find what substring was matched, by replacing -o with --color=always, you find similar results. Interestingly, this: echo 'alma,korte,banan' | grep -Eia --color=always ',K[^,]+,' does actually print the input line as a match, but nothing in it is coloured as the match. I built (on the 9.3 system) the source from -current src/usr.bin/grep, and there it works. This confused me for a while - then I discovered that this isn't the version in actual use. That's the one in src/external/gpl2/grep. The GNU grep from pkgsrc (I tried grep-3.11) works on this example. So maybe all that is needed is to update our in-tree version. It is GPL 3+, though. The one we have seems to be version 2.5.1a(?), GPL 2+, The CHANGES file from upstream https://git.savannah.gnu.org/git/grep.git lists: * Noteworthy changes in release 2.6 (2010-03-23) [stable] ... grep -i -o would fail to report some matches; grep -i --color, while not missing any line containing a match, would fail to color some matches. related to commit 70e236167c3973fc428d2b5b297218fde9b68e73, committed 2010-03-17 Unfortunately this is a rather large commit, due to multibyte support. I expect that some of the changes are not directly related to this bug, but the parts that clearly are, are still not trivial. So I expect that patching just this bug isn't trivial, and simply importing a recent version from upstream is to be preferred. Ours is very, very old... -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
