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 <[email protected]> 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 <[email protected]> > 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, <[email protected]> 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: [email protected] >>> To: duplicity-team <[email protected]> >>> >>> 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 <[email protected] >>> <mailto:[email protected]>> wrote: >>> > >>> > On 13 November 2014 09:53, Kenneth Loafman <[email protected] >>> <mailto:[email protected]>> 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 : [email protected] >>> Unsubscribe : https://launchpad.net/~duplicity-team >>> More help : https://help.launchpad.net/ListHelp >>> >> >> > > _______________________________________________ > Mailing list: https://launchpad.net/~duplicity-team > Post to : [email protected] > Unsubscribe : https://launchpad.net/~duplicity-team > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~duplicity-team Post to : [email protected] Unsubscribe : https://launchpad.net/~duplicity-team More help : https://help.launchpad.net/ListHelp
