|
From: | Kenneth Loafman |
Subject: | Re: [Duplicity-talk] Errors during test phase of installation..... |
Date: | Fri, 3 Feb 2017 14:19:14 -0600 |
Ken,I am sorry, I did not get back to you on this…. I thought I had written the email.I have resolved almost all the test issues. The main problem was that in setting up and running the test, there are a huge number of open files simultaneously and this runs up against the Mac OS X default setting for number of open files per process. That defaults to 256 files. It turns out that the duplicity test needs more than that simultaneous open files and if I set that limit to 8192 most of the tests pass. I think all the remaining test issues are due to the missing paramiko version 2.X backend.The clues was the “AssertionError 37” which had insufficient file system resources or something like that when I looked at the code. So when I give it a lot more file resources it works. This is only during the testing phase since I think I have been running it on big directories with the default values.The other big error was that the un-tar of the test files would set file permissions and owners so that the test user could not delete them. I set a note that the testing phase has to run as root. It shouldn’t but that seems to be an issue. If the no-owner no-group flags were set on the untar command for the test directories it might work. But that may mess up some of the tests.The librsyncmodule is compiled correctly. As I said, I have installed it and run duplicity for a long time using the rsync and now S3 backend.-ScottOn Feb 2, 2017, at 12:16 PM, Kenneth Loafman <address@hidden> wrote:When you run 'setup.py' test command, it has to compile the _librsyncmodule.c module to make the interface _librsync.so module, which is the interface to the system installed librsync.so module and then copy it. Just part of Python's setup process.I'm still unable to reproduce your problem. Are there restrictive permissions in the /sw/src/fink.build directories?On Sun, Jan 29, 2017 at 3:38 PM, Scott Hannahs <address@hidden> wrote:Ken,tar seems to be available to the tests. I ran just the first test (it fails) as a stand alone as you suggest.The command used was:sudo python2.7 -u setup.py test -s testing.functional.test_badupload.BadUploadTest > ~/Desktop/badupload.out.txt 2> ~/Desktop/badupload.err.txt This is the “test missing file” in the "bad upload” test.The standard out seems normal, but I am unclear as to why it is copying the librsync library which is already installed. Maybe it is not where the testing routines expect it?running testrunning egg_infowriting requirements to duplicity.egg-info/requires.txt writing duplicity.egg-info/PKG-INFOwriting top-level names to duplicity.egg-info/top_level.txt writing dependency_links to duplicity.egg-info/dependency_links.txt reading manifest file 'duplicity.egg-info/SOURCES.txt' writing manifest file 'duplicity.egg-info/SOURCES.txt' running build_extcopying build/lib.macosx-10.11-x86_64-2.7/duplicity/_librsync.so -> duplicity —————————————————————————————The error output shows an assertion error. As far as I can tell it is getting a return value of 37 and expected a return value of 44???? From grepping the sources this means that there are not enough file descriptors? I think the Mac OS X default is a paltry 256.test_missing_file (testing.functional.test_badupload.BadUploadTest) ... FAIL ============================================================ ========== FAIL: test_missing_file (testing.functional.test_badupload.BadUploadTest) ------------------------------------------------------------ ---------- Traceback (most recent call last):File "/sw/src/fink.build/duplicity-0.7.11-3A/duplicity-0.7.11/tes ting/functional/test_badupload .py", line 40, in test_missing_file self.assertEqual(e.exit_status, 44, str(e)) AssertionError: 37------------------------------------------------------------ ---------- Ran 1 test in 1.584sFAILED (failures=1)Test failed: <unittest.runner.TextTestResult run=1 errors=0 failures=1> error: Test failed: <unittest.runner.TextTestResult run=1 errors=0 failures=1> —————————————————————————————-ScottOn Jan 18, 2017, at 9: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:
[Prev in Thread] | Current Thread | [Next in Thread] |