t5000-tar-tree.sh failing

t5000-tar-tree.sh failing

[Uwe Kleine-König]

Hello,

when I run make test, I get:

	*** t5000-tar-tree.sh ***
	Initialized empty Git repository in .git/
	*   ok 1: populate workdir
	*   ok 2: add files to repository
	*   ok 3: git-tar-tree
	*   ok 4: validate file modification time
	*   ok 5: git-get-tar-commit-id
	*   ok 6: extract tar archive
	*   ok 7: validate filenames
	*   ok 8: validate file contents
	*   ok 9: git-tar-tree with prefix
	*   ok 10: extract tar archive with prefix
	*   ok 11: validate filenames with prefix
	*   ok 12: validate file contents with prefix
	*   ok 13: git-archive --format=zip
	* FAIL 14: extract ZIP archive
		(mkdir d && cd d && $UNZIP ../d.zip)
	* FAIL 15: validate filenames
		(cd d/a && find .) | sort >d.lst &&
		     diff a.lst d.lst
	* FAIL 16: validate file contents
		diff -r a d/a
	*   ok 17: git-archive --format=zip with prefix
	* FAIL 18: extract ZIP archive with prefix
		(mkdir e && cd e && $UNZIP ../e.zip)
	* FAIL 19: validate filenames with prefix
		(cd e/prefix/a && find .) | sort >e.lst &&
		     diff a.lst e.lst
	* FAIL 20: validate file contents with prefix
		diff -r a e/prefix/a
	* failed 6 among 20 test(s)

I think the problem is:

	zeisberg@cepheus:~/gsrc/git$ unzip
	bash: unzip: command not found

Probably the subversion tests suffer the same (for svn instead of
unzip).

Do we want the tests to depend on all that or would it be sensible to
output a warning that a program is missing?  Or maybe introduce test
"13.5:  check is unzip is available".  Then it would be more obvious for
the tester what went wrong?

Best regards
Uwe

-- 
Uwe Kleine-König

primes where sieve (p:xs) = [ x | x<-xs, x `rem` p /= 0 ]; \
primes = map head (iterate sieve [2..])

Re: t5000-tar-tree.sh failing

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 592 bytes --]

Hi,

On Thu, 21 Dec 2006, Uwe Kleine-König wrote:

> [...]
> 	* FAIL 14: extract ZIP archive
> 		(mkdir d && cd d && $UNZIP ../d.zip)
> [...]
>
> I think the problem is:
> 
> 	zeisberg@cepheus:~/gsrc/git$ unzip
> 	bash: unzip: command not found

Yep. That's the problem.

> Probably the subversion tests suffer the same (for svn instead of 
> unzip).
> 
> Do we want the tests to depend on all that or would it be sensible to
> output a warning that a program is missing?

Why not enclose the tests in a

	if unzip -h >/dev/null 2>/dev/null; then

		# all these tests

	fi

Hmm?

Ciao,
Dscho

Re: t5000-tar-tree.sh failing

[Brian Gernhardt]

On Dec 21, 2006, at 9:00 AM, Johannes Schindelin wrote:

>
> Why not enclose the tests in a
>
> 	if unzip -h >/dev/null 2>/dev/null; then
>
> 		# all these tests
>
> 	fi
>
> Hmm?

Several other test frameworks provide a "skip" method to indicate why  
we've skipped something.  We could do something similar...

if skip 'unzip -h' 'tests need unzip'; then
    # unzip tests
fi

skip() {
   # Have not checked to see if this is anything resembling working code
   if eval $1 > /dev/null 2>&1; then
     true
   else
     echo "* skipping tests: $2" 1>&2
     false
   fi
}

Mostly so that skipped tests are obvious, provide a reason, and have  
a standardized display format.  Again, too busy in actual work to try  
to do this myself right now, but might hack at it this afternoon if  
nobody else (hopefully someone more fluent in shell than I am) does.

~~ Brian

Re: t5000-tar-tree.sh failing

[Uwe Kleine-Koenig]

Hello,

Brian Gernhardt wrote:
> Several other test frameworks provide a "skip" method to indicate why  
> we've skipped something.  We could do something similar...
> 
> if skip 'unzip -h' 'tests need unzip'; then
>    # unzip tests
> fi
> 
> skip() {
>   # Have not checked to see if this is anything resembling working code
>   if eval $1 > /dev/null 2>&1; then
>     true
>   else
>     echo "* skipping tests: $2" 1>&2
>     false
>   fi
> }
> 
> Mostly so that skipped tests are obvious, provide a reason, and have  
> a standardized display format.  Again, too busy in actual work to try  
> to do this myself right now, but might hack at it this afternoon if  
> nobody else (hopefully someone more fluent in shell than I am) does.

I'm not sure if (in this case) a missing unzip should be as silent as
you suggest.  The danger is, that s.o. makes a change, runs `make test`
and is then conviced that nothing broke.  So I think that the test
should fail, but with a more descriptive error than it is now. 

The downside is, you need unzip, svn, what ever more to run the test
suite.

Best regards
Uwe

-- 
Uwe Kleine-Koenig

http://www.google.com/search?q=gigabyte+in+bit

Re: t5000-tar-tree.sh failing

[Brian Gernhardt]

On Dec 21, 2006, at 1:59 PM, Uwe Kleine-Koenig wrote:

> I'm not sure if (in this case) a missing unzip should be as silent as
> you suggest.  The danger is, that s.o. makes a change, runs `make  
> test`
> and is then conviced that nothing broke.  So I think that the test
> should fail, but with a more descriptive error than it is now.
>
> The downside is, you need unzip, svn, what ever more to run the test
> suite.

I was attempting to say that if we're skipping tests we should say  
so, and not just drop them silently like the code that Johannes  
posted.  Really, I guess the ideal would be for there to be a test  
harness that would run all the tests and report skips and errors in a  
report at the end rather than in the middle.

~~ Brian

Re: t5000-tar-tree.sh failing

[Johannes Schindelin]

Hi,

On Thu, 21 Dec 2006, Uwe Kleine-Koenig wrote:

> I'm not sure if (in this case) a missing unzip should be as silent as
> you suggest.  The danger is, that s.o. makes a change, runs `make test`
> and is then conviced that nothing broke.

Well, the tests are not distributed with the binary packages. For a 
reason. The maintainer of the binary packages has to check if the tests 
succeed. An she better know what she's doing!

So, if Joe Average compiles git, does not have unzip installed, and runs 
the tests, chances are that he does not want to be bothered about the zip 
tests failing because of the absence of unzip.

>  So I think that the test should fail, but with a more descriptive error 
> than it is now.

Sorry. Does not work here. I _only_ look at the messages if the test suite 
fails somewhere, with a loud error message at the end.

Ciao,
Dscho