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

[Scott Hannahs]

Agree.  The fact that I can run most of the tests as root is fine for those who want to run the tests, I have put in some developer notes on the packaging.  I think you can delete those files and a simple test running as the non-priveleged account it is not the tar command that is creating the files that can’t be deleted.  Something else is weird.

Maybe when I get around to working on the next package version I will get that fully debugged.

-Scott

On Feb 3, 2017, at 3:19 PM, Kenneth Loafman <address@hidden> wrote:

I think you are right in your analysis.  The issue with permissions is something I encountered.  It works fine on Linux, but not on MacOS.  Running as root is one workaround.  The other is to just not run the tests on MacOS since it seems to be an issue with it's permissions (you should not be able to create something you can't delete).

On Thu, Feb 2, 2017 at 11:27 AM, Scott Hannahs <address@hidden> wrote:

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.

-Scott

On 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 test

running egg_info

writing requirements to duplicity.egg-info/requires.txt

writing duplicity.egg-info/PKG-INFO

writing 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_ext

copying 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/testing/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.584s

FAILED (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>

—————————————————————————————

-Scott

On 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: