On Wed, 25 Nov 2015 17:44:43 +1100 Brian May <b...@debian.org> wrote:
> Brian May <b...@debian.org> writes: > > > Will try to test it and see if it solves the problem. > > So this bug was linked to two packages: django-testscenarios and > lava-server. > > I am not able to test these packages as I get unrelated errors instead > when I try to test with each of these packages. I also tried upstream > git versions, however got similar issues. Upstream git, master branch, for lava-server has the fixes we expect to need for django1.8 applied. There is a staging-repo containing packages which could be used for testing (packages built in a Jessie schroot). http://images.validation.linaro.org/staging-repo/ With the package installed to create the database privileges, the unit tests are run using: $ ./ci-run or for verbose: $ ./ci-run -v2 django-testscenarios master branch also has the fixes applied: https://git.linaro.org/lava/django-testscenarios.git version 0.8 $ LC_ALL=C python setup.py test The version of django-testscenarios in unstable installs cleanly - the test failures cause the package build to fail. You will also need python-testtools (>= 1.8.0-3) installed. Unit tests on the master branch of lava-server pass with django1.8 if python-testtools is downgraded to the version in stable (which is why this bug got filed against python-testtools initially). I'm using this method to be able to continue development upstream. However, the reason why the original bug against python-testtools got raised to serious was partially because the breakage *hid* other unit test issues which were only revealed by the combination of the updated python-django and updated python-testtools. i.e. The reason for the IntegrityError may still exist in the unit tests but the location of that failure is hidden by this bug. So I expect that some unit tests in the current git master branch of lava-server may still fail but I cannot fix those until a fix for this bug at least makes it possible to run *all* of the unit tests instead of bailing out at the first attempt at self.assertRaises() *and* the test failures produce the correct traceback in the lava-server code, not in django/core or testtools/testcase. Currently, the test database is not destroyed in the lava-server unit tests because the testtools raise this unhandled AttributeError. With this bug fixed, I would expect to see the django-testscenarios would complete all unit tests successfully and I would expect that lava-server unit tests would complete and destroy the test database, possibly reporting a number of FAILED tests and some skipped tests, depending on whether you have /dev/loop* devices on the test system. > Should I uploaded the patched version of Django anyway? If you are finding problems testing, I would prefer that the upload was not made to unstable. Could you upload to experimental or to some other location which I can use for further testing? If these are not the problems you are seeing or if the above doesn't work on your tests, please let me know. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
pgp6mZi5Q_cbl.pgp
Description: OpenPGP digital signature