Open GoogleCodeExporter opened 9 years ago
Thank you for running the tests!
> make check-TESTS
> not ok - 1 working success
This is a basic failure of the testsuite itself, which is based on the
testsuite for git.
Does your system have a "/bin/true"?
> # /bin/true
> not ok - 14 dshbak -d fails gracefully for non-writable dir
> #
> # mkdir test_output &&
> # chmod 500 test_output &&
> # echo -e "foo0: bar" | dshbak -d test_output 2>&1 | tee logfile | \
> # grep "Failed to open output file" &&
> # rm -rf test_output logfile
> #
> # still have 1 known breakage(s)
> # failed 1 among remaining 13 test(s)
This one tests the new dshbak -d functionality on a non writable directory.
dshbak should fail with the string "Failed to open output file".
After you run the tests, any failed test scripts should leave
a "trash-directory.<testid>" directory. Can you check for a
trash-directory.t1000-dshbak under 'tests' and see if the file
'logfile' contains anything? Otherwise you could try running the
bits of the test by hand:
mkdir test_output
chmod 500 test_output
echo -e "foo0: bar" | dshbak -d test_output
and send me the results. Maybe the grep is too simple.
> 1..14
> FAIL: ./t1000-dshbak.sh
Thanks,
mark
Original comment by mark.gro...@gmail.com
on 2 Mar 2011 at 5:47
> > make check-TESTS
> > not ok - 1 working success
>
> This is a basic failure of the testsuite itself, which is based on the
testsuite for git.
> Does your system have a "/bin/true"?
>
> > # /bin/true
Nope; Darwin has /usr/bin/true.
> > # still have 1 known breakage(s)
> > # failed 1 among remaining 13 test(s)
>
> This one tests the new dshbak -d functionality on a non writable directory.
> dshbak should fail with the string "Failed to open output file".
> After you run the tests, any failed test scripts should leave
> a "trash-directory.<testid>" directory. Can you check for a
> trash-directory.t1000-dshbak under 'tests' and see if the file
> 'logfile' contains anything? Otherwise you could try running the
> bits of the test by hand:
>
>
> mkdir test_output
> chmod 500 test_output
> echo -e "foo0: bar" | dshbak -d test_output
>
> and send me the results. Maybe the grep is too simple.
$ sudo ls -lR trash-directory.t1000-dshbak
total 16
-rw-r--r-- 1 fink-bld fink-bld 0 Mar 2 08:45 logfile
-rw-r--r-- 1 fink-bld fink-bld 78 Mar 2 08:45 output
-rw-r--r-- 1 fink-bld fink-bld 28 Mar 2 08:45 test_input
dr-x------ 2 fink-bld fink-bld 68 Mar 2 08:45 test_output
trash-directory.t1000-dshbak/test_output:
$ cat trash-directory.t1000-dshbak//output
----------------
foo00s0foo01s0foo02s0foo1s0foo3s0foo5s0
----------------
bar
$ cat trash-directory.t1000-dshbak//test_input
test
input
file
foo
bar
$ mkdir test_output && chmod 500 test_output && echo -e "foo0: bar" |
../../scripts/dshbak -d test_output
dshbak: Fatal: Failed to open output file 'test_output/foo0': Permission denied
Does that help? This makes me suspect that the issue may have to do with the
Fink build environment (that last command I ran as myself, rather than as the
Fink build user).
-steve
Original comment by hakamad...@gmail.com
on 2 Mar 2011 at 6:11
I will replace the /bin/true for the basic test success test with ':'
Is there a way to run the commands
$ mkdir test_output && chmod 500 test_output && echo -e "foo0: bar" | ../../scripts/dshbak -d test_output
in the Fink build environment to see where the test is failing? It is probably
just a bit of a fragile test. I'll try to think of a way to make it more robust.
Original comment by mark.gro...@gmail.com
on 2 Mar 2011 at 6:40
Does the Fink build run as a privileged user? That might explain
the failure of the dshbak -d test. Can you try applying the attached patch
and see if this resolved this particular test failure?
Original comment by mark.gro...@gmail.com
on 5 Mar 2011 at 12:19
Attachments:
This issue was updated by revision r1296.
This commit fixes one of the two failing test cases for this issue.
Original comment by mark.gro...@gmail.com
on 9 Mar 2011 at 3:24
This issue was updated by revision r1297.
Possible fix for failure in t1000-dshbak.sh
Original comment by mark.gro...@gmail.com
on 9 Mar 2011 at 3:25
I have tagged and uploaded pdsh-2.25 which I hope has resolved this issue.
If you can, let me know so I can close this issue.
Thanks!
Original comment by mark.gro...@gmail.com
on 9 Mar 2011 at 3:38
Mark,
Thanks for the update! 2.25 fixes the initial failure (the /bin/true issue),
but I'm still seeing the same failure from t5000-dshbak.sh. I'm sorry I didn't
respond to your earlier questions; it looks like you've now rolled the SANITY
patch into your release.
$ sudo ls -l trash-directory.t5000-dshbak/
total 16
-rw-r--r-- 1 fink-bld fink-bld 0 Mar 9 11:10 logfile
-rw-r--r-- 1 fink-bld fink-bld 78 Mar 9 11:10 output
-rw-r--r-- 1 fink-bld fink-bld 28 Mar 9 11:10 test_input
dr-x------ 2 fink-bld fink-bld 68 Mar 9 11:10 test_output
$ sudo cat trash-directory.t5000-dshbak/output
----------------
foo00s0foo01s0foo02s0foo1s0foo3s0foo5s0
----------------
bar
$ cat trash-directory.t5000-dshbak/test_input
test
input
file
foo
bar
-Steve
Original comment by hakamad...@gmail.com
on 9 Mar 2011 at 4:22
Yeah, the SANITY patch is definitely required if running as root or other
privileged user and I hoped it would also solve the problem described in this
issue as well.
Is there a way you could apply the attached patch, which adds set -x before
the affected test and adds debug and verbose output, and rerun under fink build?
Original comment by mark.gro...@gmail.com
on 9 Mar 2011 at 5:21
Attachments:
This issue was updated by revision r1314.
The test for dshbak -d on non-writable directiory was occaisionally
failing when cleaning up the directory and logfile. This is not
part of the test, so we don't care if the rm fails.
Original comment by mark.gro...@gmail.com
on 3 Apr 2011 at 6:28
Original issue reported on code.google.com by
hakamad...@gmail.com
on 2 Mar 2011 at 1:50