← Back to team overview

duplicity-team team mailing list archive

Re: Fwd: Re: Failing tests

 

Michael, is there something we can use so that testing.test_code.CodeTest
does not get run during a build?  It's failing now in test_pep8 and
test_pylint.  If we can't ignore those in a build, maybe we need to move
them to manual?

On Wed, Nov 19, 2014 at 10:23 AM, Kenneth Loafman <kenneth@xxxxxxxxxxx>
wrote:

> Sorry for the delay.  I tried it and it worked.  Will get a fix out soon.
>
>
> On Fri, Nov 14, 2014 at 6:10 AM, <edgar.soldin@xxxxxx> wrote:
>
>> the removal of the file_naming.py changeset mentioned below seems to fix
>> short filenames test.
>>
>> Ken: can you hack that locally quickly? sparing me the creation of a
>> branch?
>>
>> need to find another solution to enable par2+ then.. ede
>>
>>
>> -------- Forwarded Message --------
>> Subject: Re: [Duplicity-team] Failing tests
>> Date: Fri, 14 Nov 2014 11:41:40 +0100
>> From: edgar.soldin@xxxxxx
>> To: duplicity-team <duplicity-team@xxxxxxxxxxxxxxxxxxx>
>>
>> probably my fault, in the bigger branch i also "fixed" an assertion with
>> some change to file_naming.py
>>
>> http://bazaar.launchpad.net/~duplicity-team/duplicity/0.7-series/revision/1014
>>
>> problem is that par2+ is hitting it, some problem with the fact that pa2+
>> just uses the same filename plus a .par2 suffix on the backend.
>>
>> just removed it and run the tests locally, frustratingly seem to be
>> unable to run one test alone. will come back with results.
>>
>> ..ede
>>
>> On 13.11.2014 20:38, Kenneth Loafman wrote:
>> > Now that we've cleaned up some of the other errors, I think something
>> has broken short filenames.  The same tests with old filenames work.
>> >
>> >
>> > On Thu, Nov 13, 2014 at 10:05 AM, Michael Terry <mike@xxxxxxxxxxx
>> <mailto:mike@xxxxxxxxxxx>> wrote:
>> >
>> >     On 13 November 2014 09:53, Kenneth Loafman <kenneth@xxxxxxxxxxx
>> <mailto:kenneth@xxxxxxxxxxx>> wrote:
>> >
>> >         My bad.  They are there after all.  Wouldn't it be better just
>> to get tox running than going the setup.py route.  I found that tox did
>> most of the work for you by setting up the virutualenv for each version of
>> Python and left little to be done manually.
>> >
>> >
>> >     You mean in the debian build?  Tox sets up a virtualenv sure, but
>> the debian build wants to test against the actual environment.
>> >
>> >     -mt
>> >
>> >
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~duplicity-team
>> Post to     : duplicity-team@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~duplicity-team
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>

Follow ups

References