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)
