Re: [Duplicity-talk] Errors during test phase of installation.....

On Wed, Jan 18, 2017 at 8:38 AM, Kenneth Loafman <address@hidden> wrote:

No, this is not good, but what you describe is practically the same problem I got when testfiles was not being fully removed on Sierra, but from what I can tell from above, the offending tests are being skipped. To run a single test, do this on the user console from within duplicity:

$ python -u setup.py test -s testing.functional.test_badupload.BadUploadTest

A weird thought... is it possible that tar is not available to the tests?

...Ken

On Tue, Jan 17, 2017 at 12:02 PM, Scott Hannahs via Duplicity-talk <address@hidden> wrote:
The files seem to have somewhat restrictive execution and r/w access. But I build and test duplicity as a non privileged user. It seems to install and remove the testfiles directory structure while running. But I have 23 failures and 100 errors out of the 418 tests.

The summary is:
Ran 418 tests in 179.702s

FAILED (failures=23, errors=100, skipped=5)
Test failed: <unittest.runner.TextTestResult run=418 errors=100 failures=23>
error: Test failed: <unittest.runner.TextTestResult run=418 errors=100 failures=23>
phase test: warning

And the errors seem to be at the beginning of the tests. Here is the first N lines of the error output:
test_missing_file (testing.functional.test_badupload.BadUploadTest) ... FAIL
test_cleanup_after_partial (testing.functional.test_cleanup.CleanupTest) ... ERROR
test_remove_all_but_n (testing.functional.test_cleanup.CleanupTest) ... ERROR
test_remove_all_inc_of_but_n (testing.functional.test_cleanup.CleanupTest) ... ERROR
test_asym_cycle (testing.functional.test_final.FinalTest)
Like test_basic_cycle but use asymmetric encryption and signing ... ERROR
test_asym_with_hidden_recipient_cycle (testing.functional.test_final.FinalTest)
Like test_basic_cycle but use asymmetric encryption (hiding key id) and signing ... ERROR
test_basic_cycle (testing.functional.test_final.FinalTest)
Run backup/restore test on basic directories ... ERROR
test_empty_backup (testing.functional.test_final.FinalTest)
Make sure backup works when no files change ... ERROR
test_empty_restore (testing.functional.test_final.FinalTest)
Make sure error raised when restore doesn't match anything ... ERROR
test_long_filenames (testing.functional.test_final.FinalTest)
Test backing up a directory with long filenames in it ... ERROR
test_piped_password (testing.functional.test_final.FinalTest)
Make sure that prompting for a password works ... ERROR
test_remove_older_than (testing.functional.test_final.FinalTest)
Test removing old backup chains ... ERROR
test_single_regfile (testing.functional.test_final.FinalTest)
Test backing and restoring up a single regular file ... ERROR
test_asym_cycle (testing.functional.test_final.OldFilenamesFinalTest)
Like test_basic_cycle but use asymmetric encryption and signing ... ERROR
test_asym_with_hidden_recipient_cycle (testing.functional.test_final.OldFilenamesFinalTest)
Like test_basic_cycle but use asymmetric encryption (hiding key id) and signing ... ERROR
test_basic_cycle (testing.functional.test_final.OldFilenamesFinalTest)
Run backup/restore test on basic directories ... ERROR
test_empty_backup (testing.functional.test_final.OldFilenamesFinalTest)
Make sure backup works when no files change ... ERROR
test_empty_restore (testing.functional.test_final.OldFilenamesFinalTest)
Make sure error raised when restore doesn't match anything ... ERROR
test_long_filenames (testing.functional.test_final.OldFilenamesFinalTest)
Test backing up a directory with long filenames in it ... ERROR
test_piped_password (testing.functional.test_final.OldFilenamesFinalTest)
Make sure that prompting for a password works ... ERROR

Then there are a bunch of tests that are “ok”

Then I get some python failures with traceback:
======================================================================
ERROR: test_cleanup_after_partial (testing.functional.test_cleanup.CleanupTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/sw/src/fink.build/duplicity-0.7.11-3/duplicity-0.7.11/testing/functional/test_cleanup.py", line 38, in test_cleanup_after_partial
good_files = self.backup("full", "testfiles/largefiles")
File "/sw/src/fink.build/duplicity-0.7.11-3/duplicity-0.7.11/testing/functional/__init__.py", line 143, in backup
result = self.run_duplicity(options=options, **kwargs)
File "/sw/src/fink.build/duplicity-0.7.11-3/duplicity-0.7.11/testing/functional/__init__.py", line 130, in run_duplicity
raise CmdError(return_val)
CmdError: 37

======================================================================
ERROR: test_remove_all_but_n (testing.functional.test_cleanup.CleanupTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/sw/src/fink.build/duplicity-0.7.11-3/duplicity-0.7.11/testing/functional/test_cleanup.py", line 56, in test_remove_all_but_n
full1_files = self.backup("full", "testfiles/empty_dir")
File "/sw/src/fink.build/duplicity-0.7.11-3/duplicity-0.7.11/testing/functional/__init__.py", line 143, in backup
result = self.run_duplicity(options=options, **kwargs)
File "/sw/src/fink.build/duplicity-0.7.11-3/duplicity-0.7.11/testing/functional/__init__.py", line 130, in run_duplicity
raise CmdError(return_val)
CmdError: 37

This just doesn’t seem good to me.

-Scott

On Jan 16, 2017, at 1:28 PM, Kenneth Loafman <address@hidden> wrote:

Any way to check to see if the testing/testfiles directory is being left around after a test? Maybe run it manually? If so, do a manual 'rm -r testing/testfiles' and see if El Capitan complains. That will go a long way to find out what's going on.

On Mon, Jan 16, 2017 at 12:05 PM, Scott Hannahs <address@hidden> wrote:
Ken,

The fink installation/testing system uses a sandbox directory and blows away the whole thing afterwards. So there shouldn’t be a previous testing directory unless specifically requested to keep the build folders. I think it creates those testing directories and files in the build directory structure.

This is on Mac OS X El Capitan (10.11). I haven’t tried to move to Sierra (10.12) quite yet. Though I think I can test that next week on another system if that is helpful. First I was going to try to reduce these errors to a manageable amount on El Cap.

Those two lines to skip some tests are in the code as they should be. I don’t quite see why the “TestLockedFoldersNotError” is related to the errors posted “test_cleanup_after_partial” and “test_remove_all_but_n” where duplicity crashed.

-Scott

On Jan 16, 2017, at 11:45 AM, Kenneth Loafman <address@hidden> wrote:

Hmm, those errors should have been fixed in 0.7.11 in testing/test_selection.py.TestLockedFoldersNotError. Mac Sierra made some funky changes that keeps you from deleting a directory with perms of 0o0000, thus causing test cleanup of those two tests to fail, and in general messing up the entire test cycle.

There should be two lines before each test def with:
@unittest.skipUnless(platform.platform().startswith('Linux'),
'Skip on non-Linux systems')

Plus, if you ran the tests already, then the directory testing/testfiles may still be around to screw up the next test run.

...Ken

On Mon, Jan 16, 2017 at 10:30 AM, Scott Hannahs <address@hidden> wrote:
Ok, but the standard error out has 581 k lines of output:
6700 lines end with “ERROR”
1000 lines end with “FAIL”
23K lines end with “ok”
37K lines start with “Traceback"

This seems disturbing? Especially the traceback failures in python. It is possible that I have not installed some necessary component.

But as I said, my backup script is working every night (with S3 backend). It just may not be working for a variety of backends?

There are a lot of “directory not empty” failures (about 5K). But the number of errors in the whole file is somewhat daunting to me at the moment. But if it is normal, I will move on and publish this installer package.

The whole error log is 36 MB and took 14,000 seconds to run.
It can be downloaded at http://www.p-hall.net/files/duplicity-error.txt

for the record, here is the installed components (and of course their defined dependencies)

duplicity 0.7.11-3
boto-py27 2.36.0-1
gnupg-unified 1.4.21-1
lftp 4.6.5-1
librsync 0.9.7-1006
lockfile-py27 0.12.2-1
paramiko-py27 1.7.6-1
pycryptopp-py27 0.7.1-1
python27 1:2.7.13-1
MacOSX 10.11.6

Here are the first two Traceback reports:
======================================================================
ERROR: test_cleanup_after_partial (testing.functional.test_cleanup.CleanupTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/sw/src/fink.build/duplicity-0.7.11-1/duplicity-0.7.11/testing/functional/test_cleanup.py", line 38, in test_cleanup_after_partial
good_files = self.backup("full", "testfiles/largefiles")
File "/sw/src/fink.build/duplicity-0.7.11-1/duplicity-0.7.11/testing/functional/__init__.py", line 143, in backup
result = self.run_duplicity(options=options, **kwargs)
File "/sw/src/fink.build/duplicity-0.7.11-1/duplicity-0.7.11/testing/functional/__init__.py", line 130, in run_duplicity
raise CmdError(return_val)
CmdError: 31

======================================================================
ERROR: test_remove_all_but_n (testing.functional.test_cleanup.CleanupTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/sw/src/fink.build/duplicity-0.7.11-1/duplicity-0.7.11/testing/functional/test_cleanup.py", line 56, in test_remove_all_but_n
full1_files = self.backup("full", "testfiles/empty_dir")
File "/sw/src/fink.build/duplicity-0.7.11-1/duplicity-0.7.11/testing/functional/__init__.py", line 143, in backup
result = self.run_duplicity(options=options, **kwargs)
File "/sw/src/fink.build/duplicity-0.7.11-1/duplicity-0.7.11/testing/functional/__init__.py", line 130, in run_duplicity
raise CmdError(return_val)
CmdError: 31

======================================================================

-Scott

> On Jan 16, 2017, at 10:41 AM, Kenneth Loafman <address@hidden> wrote:
>
> Those look like the normal errors we force for testing. Unless the tests end with ERROR or FAIL, all is good.
>
> ...Thanks,
> ...Ken
>
>

_______________________________________________
Duplicity-talk mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/duplicity-talk

From:	Kenneth Loafman
Subject:	Re: [Duplicity-talk] Errors during test phase of installation.....
Date:	Fri, 27 Jan 2017 10:20:00 -0600