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

[edgar . soldin]

Scott,

just saw this mail, so you may ignore my previous one ;). comments inline

On 05.02.2017 21:47, Scott Hannahs wrote:
> 
>> On Feb 5, 2017, at 8:28 AM, edgar.soldin--- via Duplicity-talk 
>> <address@hidden> wrote:
>>
>> On 04.02.2017 00:23, Scott Hannahs via Duplicity-talk wrote:
>>> 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.
>>
>> Scott,
>>
>> can you explain this a little bit more detailed? do you mean that untar-ing 
>> the duplicity tarball creates files/folders with improper permissions?
>>
>> what do those improper persmissions/owner values look like?
> 
> No, not the duplicity tar ball, but the testing tar ball which has all sorts 
> of weird permissions and dates just to test the functionality of duplicity.  

where does that come from?

>I am not sure exactly what the problem is, if I untar the testing tar ball 
>manually all the owners are set to that of the user.  

sounds reasonable. if the permissions from the tarball really matter and , you 
should extract w/ the -p switch enabled which ignores your local user mask and 
restores the permissions exactly as they were before packing. when run as root 
it even tries to restore the previous owner/group.

>But the permissions may be a problem during the cleanup part as mentioned by 
>Ken.  I am not sure of the exact tar command switches used in the extraction 
>of testifiles.tar.gz.  Let me go grep through the testing sources.

please do and come back.

same for the cleanup part. it might be needed to chmod everything to u+rwX 
before cleaning first.

> 
> The testing is attempted by the non-login user fink-bld as well as the 
> creation of the deb file.  However the testing seems to work when the whole 
> thing is run at root privilege.

my guess would be that fink-bld does not have a shell assigned and therefor 
does not setup the environment properly (especially umask and current user).

> I am also not sure why the large number of open files is required during the 
> testing phase.  I run duplicity on large directories daily with the standard 
> limits.  It may be the testing routines are keeping file handles open.

it's very likely that the test weren't programmed very carefully.

..ede/duply.net