duplicity-team team mailing list archive

[Michael Terry <mike@xxxxxxxxxxx>]

Sure, we could move them to the manual test directory instead.  I thought
we'd want to leave them on to keep the code clean as we go (the idea being
that someone making a branch would make sure it passes tests first).  But
they aren't mission-critical tests for sure.  :)
-mt

On 19 November 2014 15:41, Kenneth Loafman <kenneth@xxxxxxxxxxx> wrote:

> 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
>>>
>>
>>
>
> _______________________________________________
> 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
>
>