Re: test-vc-list-files-cvs.sh failure on OS X 10.6.3
On 05/28/2010 12:30 AM, Gary V. Vaughan wrote: Obviously, the test is assuming GNU find (which is called gfind on my machine, but it doesn't come with Mac OS, which ships only BSD find), but with a cursory look around I couldn't see where the failing find was invoked. It looks for a 'cvsu', hoping to find the one from http://www.red-bean.com/cvsutils/ but in your case finding cvsu from http://savannah.gnu.org/projects/cvs-utils Maybe the test should not look for any cvs-utils at all, since there appears to be a fallback? Peter
Re: test-vc-list-files-cvs.sh failure on OS X 10.6.3
Hi Peter, On 28 May 2010, at 20:43, Peter O'Gorman wrote: On 05/28/2010 12:30 AM, Gary V. Vaughan wrote: Obviously, the test is assuming GNU find (which is called gfind on my machine, but it doesn't come with Mac OS, which ships only BSD find), but with a cursory look around I couldn't see where the failing find was invoked. It looks for a 'cvsu', hoping to find the one from http://www.red-bean.com/cvsutils/ but in your case finding cvsu from http://savannah.gnu.org/projects/cvs-utils Ha! Nice catch :) Actually, it's marginally stranger than that... I have a vestigial $HOME/bin install of cvsu from a version of savannah's cvs-utils that I had begun to make VCS neutral, initially when I began doing all my local development with GNU Arch, and later when I started trying to make more use of git... but couldn't quite let go of the cvs-utils crutch I'd gotten very comfortable with. Maybe the test should not look for any cvs-utils at all, since there appears to be a fallback? I suppose cvs-utils is all but dead now? At least I haven't actively used or contributed to it in quite a few years, and was genuinely surprised to find a cvsu in my PATH. Unless I'm way off base, I concur that looking for cvsutils is pretty optimistic at best, and likely to cause spurious test failures like mine at worst. Removing the cvsutils dependency seems like a good idea, and indeed removing the last traces of cvs-utils from my machine allows that failing test to PASS again. If there's a good reason to keep the cvsu call in the test, then it should at least be made robust to the difference between the cvsutils and cvs-utils versions. But that seems like more bother than it's worth to me. Cheers, -- Gary V. Vaughan (g...@gnu.org)
test-vc-list-files-cvs.sh failure on OS X 10.6.3
While checking for regressions in very old m4 patches I hadn't gotten round to submitting, I notice that the HEAD revision of both branch-1.4 and branch-1.6 fail this test: ; cd Devo/m4--release--1.4 ; git pull ./bootstrap mkdir +build cd +build ../configure make all check [[...]] PASS: test-vc-list-files-git.sh FAIL: test-vc-list-files-cvs.sh PASS: test-version-etc.sh PASS: test-wchar PASS: test-wcrtomb.sh PASS: test-wctype PASS: test-xalloc-die.sh PASS: test-xmemdup0 PASS: test-xvasprintf === 1 of 115 tests failed See tests/test-suite.log Please report to bug...@gnu.org === [[...]] ; cat tests/test-suite.log GNU M4 1.4.14.1-a90f: tests/test-suite.log 1 of 102 tests failed. (1 test was not run). .. contents:: :depth: 2 SKIP: test-c-stack2.sh (exit: 77) = cannot tell stack overflow from crash; consider installing libsigsegv FAIL: test-vc-list-files-cvs.sh (exit: 1) = find: illegal option -- - ind: illegal option -- - ind: illegal option -- t ind: illegal option -- y ind: illegal option -- p ind: illegal option -- e ind: illegal option -- = ind: illegal option -- A ind: illegal option -- F ind: illegal option -- G ind: illegal option -- M find: ind: No such file or directory --- expected2010-05-28 11:36:21.0 +0700 +++ actual 2010-05-28 11:36:21.0 +0700 @@ -1,3 +1,3 @@ -b -c -d/a +.: +? actual +? expected Obviously, the test is assuming GNU find (which is called gfind on my machine, but it doesn't come with Mac OS, which ships only BSD find), but with a cursory look around I couldn't see where the failing find was invoked. With gfind in my PATH, I also tried rerunning the testsuite with: ; FIND=gfind make check ...but I get the same failure. Cheers, -- Gary V. Vaughan (g...@gnu.org)
