Failure running tests.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Failure running tests.

duplicity-talk mailing list
Scott,

I created a test user (non-admin) and the tests fail like yours.  This helps a lot.

Will see what I can do.

...Ken




On Fri, Sep 13, 2019 at 10:39 AM Kenneth Loafman <[hidden email]> wrote:
It's in run_duplicity in functional/__init__.py.

...Ken 

On Fri, Sep 13, 2019 at 10:24 AM Scott Hannahs <[hidden email]> wrote:
but I don’t see the —archive-dir option for the test_replacement suite of tests.  Shouldn’t that be necessary to make the test use testing/cache?  Did I miss that?

-Scott


> On Sep 13, 2019, at 11:09 AM, Kenneth Loafman <[hidden email]> wrote:
>
> Scott.
>
> Yes, testing only writes to the testing/* directories and testing/cache takes the place of ~/.cache/duplicity.
>
> ...Ken
>


_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: Failure running tests.

duplicity-talk mailing list
That narrows it down!  That is great progress.

Thanks,
Scott

> On Sep 14, 2019, at 11:48 AM, Kenneth Loafman <[hidden email]> wrote:
>
> Scott,
>
> I created a test user (non-admin) and the tests fail like yours.  This helps a lot.
>
> Will see what I can do.
>
> ...Ken
>


_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: Failure running tests.

duplicity-talk mailing list
Scott,

Found the problem.  It's the way duplicity handles the /tmp directory.  You can see this yourself with:

$ mkdir /tmp/foo
$ ls -l /tmp

and observe that /tmp/foo user is you, but the group is wheel.  On Linux that would be your gid.

What's happening is that duplicity is building a sigtar file in /tmp, then copying it to testing/testfiles/cache, or trying to.  As soon as the copy is complete, duplicity tries to chown the sigtar  file to the same as the one in /tmp, which is test:wheel and test does not have the rights to set a wheel gid.

$ TMPDIR=~/tmp tox -e py37
works for all tests.  

I'm going to have to think about the changes needed, perhaps as simple as telling non-admin users to override TMPDIR.

On the second traceback, that was caused by Pythons poor exception reporting standards.  In some cases the args returned are (number, mee ssage), in others (message, number).  I tweaked it so it would look for the first string in the tuple and used that for the error message.  That's probably wrong in some cases.

...Ken



On Sat, Sep 14, 2019 at 1:35 PM Scott Hannahs <[hidden email]> wrote:
That narrows it down!  That is great progress.

Thanks,
Scott

> On Sep 14, 2019, at 11:48 AM, Kenneth Loafman <[hidden email]> wrote:
>
> Scott,
>
> I created a test user (non-admin) and the tests fail like yours.  This helps a lot.
>
> Will see what I can do.
>
> ...Ken
>


_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: Failure running tests.

duplicity-talk mailing list
Ken,

Ahh…  That make sense.

Not a python person, but the C routines should give a user temporary directory with better permissions.  See the man page for “confstr” and the variable “_CS_DARWIN_USER_TEMP_DIR”  This allows creation of temporary files and directories with read/write and correct group permissions.  These are in the /private/var/folders hierarchy.

The shell has also a utility (getconf) to get a user writeable folder using that method:
% getconf DARWIN_USER_TEMP_DIR
/var/folders/vp/g0v5g0m555z7448gjtzfrthc0000kr/C/
% ls -l /var/folders/vp/g0v5g0m555z7448gjtzfrthc0000kr/C
total 0
drwxr-xr-x  3 fink-bld  fink-bld   96 Apr 28 12:44 com.apple.DeveloperTools
drwx------  7 fink-bld  fink-bld  224 Apr 28 12:44 com.apple.trustd
drwx------  5 fink-bld  fink-bld  160 Aug 20 18:13 mds

This also has the added facility for automatic cleanup.  I think if space gets low this area is purged after 3 days?  But I try not to rely on that.  I am not sure if this is POSIX or BSD routine, but it might be a standard solution.

-Scott


On Sep 20, 2019, at 4:55 PM, Kenneth Loafman <[hidden email]> wrote:

Scott,

Found the problem.  It's the way duplicity handles the /tmp directory.  You can see this yourself with:

$ mkdir /tmp/foo
$ ls -l /tmp

and observe that /tmp/foo user is you, but the group is wheel.  On Linux that would be your gid.

What's happening is that duplicity is building a sigtar file in /tmp, then copying it to testing/testfiles/cache, or trying to.  As soon as the copy is complete, duplicity tries to chown the sigtar  file to the same as the one in /tmp, which is test:wheel and test does not have the rights to set a wheel gid.

$ TMPDIR=~/tmp tox -e py37
works for all tests.  

I'm going to have to think about the changes needed, perhaps as simple as telling non-admin users to override TMPDIR.

On the second traceback, that was caused by Pythons poor exception reporting standards.  In some cases the args returned are (number, mee ssage), in others (message, number).  I tweaked it so it would look for the first string in the tuple and used that for the error message.  That's probably wrong in some cases.

...Ken



On Sat, Sep 14, 2019 at 1:35 PM Scott Hannahs <[hidden email]> wrote:
That narrows it down!  That is great progress.

Thanks,
Scott

> On Sep 14, 2019, at 11:48 AM, Kenneth Loafman <[hidden email]> wrote:
>
> Scott,
>
> I created a test user (non-admin) and the tests fail like yours.  This helps a lot.
>
> Will see what I can do.
>
> ...Ken
>



_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: Failure running tests.

duplicity-talk mailing list
Scott,

It was a fairly simple solution, using getconf like you suggested.

Will get 0.8.05 out soon, but the fix is on the trunk now.

...Ken


On Fri, Sep 20, 2019 at 5:21 PM Scott Hannahs <[hidden email]> wrote:
Ken,

Ahh…  That make sense.

Not a python person, but the C routines should give a user temporary directory with better permissions.  See the man page for “confstr” and the variable “_CS_DARWIN_USER_TEMP_DIR”  This allows creation of temporary files and directories with read/write and correct group permissions.  These are in the /private/var/folders hierarchy.

The shell has also a utility (getconf) to get a user writeable folder using that method:
% getconf DARWIN_USER_TEMP_DIR
/var/folders/vp/g0v5g0m555z7448gjtzfrthc0000kr/C/
% ls -l /var/folders/vp/g0v5g0m555z7448gjtzfrthc0000kr/C
total 0
drwxr-xr-x  3 fink-bld  fink-bld   96 Apr 28 12:44 com.apple.DeveloperTools
drwx------  7 fink-bld  fink-bld  224 Apr 28 12:44 com.apple.trustd
drwx------  5 fink-bld  fink-bld  160 Aug 20 18:13 mds

This also has the added facility for automatic cleanup.  I think if space gets low this area is purged after 3 days?  But I try not to rely on that.  I am not sure if this is POSIX or BSD routine, but it might be a standard solution.

-Scott


On Sep 20, 2019, at 4:55 PM, Kenneth Loafman <[hidden email]> wrote:

Scott,

Found the problem.  It's the way duplicity handles the /tmp directory.  You can see this yourself with:

$ mkdir /tmp/foo
$ ls -l /tmp

and observe that /tmp/foo user is you, but the group is wheel.  On Linux that would be your gid.

What's happening is that duplicity is building a sigtar file in /tmp, then copying it to testing/testfiles/cache, or trying to.  As soon as the copy is complete, duplicity tries to chown the sigtar  file to the same as the one in /tmp, which is test:wheel and test does not have the rights to set a wheel gid.

$ TMPDIR=~/tmp tox -e py37
works for all tests.  

I'm going to have to think about the changes needed, perhaps as simple as telling non-admin users to override TMPDIR.

On the second traceback, that was caused by Pythons poor exception reporting standards.  In some cases the args returned are (number, mee ssage), in others (message, number).  I tweaked it so it would look for the first string in the tuple and used that for the error message.  That's probably wrong in some cases.

...Ken



On Sat, Sep 14, 2019 at 1:35 PM Scott Hannahs <[hidden email]> wrote:
That narrows it down!  That is great progress.

Thanks,
Scott

> On Sep 14, 2019, at 11:48 AM, Kenneth Loafman <[hidden email]> wrote:
>
> Scott,
>
> I created a test user (non-admin) and the tests fail like yours.  This helps a lot.
>
> Will see what I can do.
>
> ...Ken
>



_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
12