Re: python-django build weirdness
On 25 September 2013 15:14, Brian May wrote: > Guess I should file a bug report against python-django then... > Submitted as #724637 -- Brian May
Re: python-django build weirdness
On Wednesday 25 September 2013 15:14:27 Brian May wrote: > Guess I should file a bug report against python-django then... Upstream refactored the tests suite during the 1.6 development, so maybe you could also check if the bug is already fixed and mention in the bug report. Thanks! Kind regards, -- Daniele Tricoli 'Eriol' http://mornie.org -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/16051556.gDGu7Vgpkz@mornie
Re: python-django build weirdness
On 24 September 2013 15:40, Chow Loong Jin wrote: > grepping for johndoe shows one match in > tests/regressiontests/utils/simplelazyobject.py, where the test case > creates a > johndoe user. > > I suspect the error comes from using unittest.TestCase instead of > django.test.TestCase. The latter does some cleanup and reinitialization > after > each testcase, which is necessary, but isn't happening here. Fixing the > import > line should do the trick. Guess I should file a bug report against python-django then... -- Brian May
Re: python-django build weirdness
On Tue, Sep 24, 2013 at 02:11:56PM +1000, Brian May wrote: > On 24 September 2013 13:16, Chow Loong Jin wrote: > > > Why don't you catch the AssertionError at this point and check what the > > extra > > User object is? > > > > [, , ] grepping for johndoe shows one match in tests/regressiontests/utils/simplelazyobject.py, where the test case creates a johndoe user. I suspect the error comes from using unittest.TestCase instead of django.test.TestCase. The latter does some cleanup and reinitialization after each testcase, which is necessary, but isn't happening here. Fixing the import line should do the trick. > I just tried it on the same path as you used, but it worked for me. My /tmp > > is > > on tmpfs though. > > > > Not surprised... -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: python-django build weirdness
On 24 September 2013 13:16, Chow Loong Jin wrote: > Why don't you catch the AssertionError at this point and check what the > extra > User object is? > [, , ] I just tried it on the same path as you used, but it worked for me. My /tmp > is > on tmpfs though. > Not surprised... -- Brian May
Re: python-django build weirdness
On Tue, Sep 24, 2013 at 11:23:14AM +1000, Brian May wrote: > Hello, > > >From a wheezy box, I am running the following commands: > > dget > http://ftp.de.debian.org/debian/pool/main/p/python-django/python-django_1.5.4-1.dsc > cd python-django-1.5.4 > dpkg-buildpackage -rfakeroot -sa 2>&1 | tee $logfile > > For different values of $logfile. > > If I run this from my home directory, it works. Every time. > > If I run this instead from /tmp/brian/tmp.rJDf6JJXaz - it fails. It always > fails at exactly the same point. > > == > FAIL: test_instance_is_maintained > (django.contrib.formtools.tests.wizard.wizardtests.tests.WizardFormKwargsOverrideTests) > -- > Traceback (most recent call last): > File > "/tmp/brian/tmp.rJDf6JJXaz/python-django-1.5.4/django/contrib/formtools/tests/wizard/wizardtests/tests.py", > line 375, in test_instance_is_maintained > self.assertEqual(2, User.objects.count()) > AssertionError: 2 != 3 Why don't you catch the AssertionError at this point and check what the extra User object is? I just tried it on the same path as you used, but it worked for me. My /tmp is on tmpfs though. -- Kind regards, Loong Jin signature.asc Description: Digital signature
python-django build weirdness
Hello, >From a wheezy box, I am running the following commands: dget http://ftp.de.debian.org/debian/pool/main/p/python-django/python-django_1.5.4-1.dsc cd python-django-1.5.4 dpkg-buildpackage -rfakeroot -sa 2>&1 | tee $logfile For different values of $logfile. If I run this from my home directory, it works. Every time. If I run this instead from /tmp/brian/tmp.rJDf6JJXaz - it fails. It always fails at exactly the same point. == FAIL: test_instance_is_maintained (django.contrib.formtools.tests.wizard.wizardtests.tests.WizardFormKwargsOverrideTests) -- Traceback (most recent call last): File "/tmp/brian/tmp.rJDf6JJXaz/python-django-1.5.4/django/contrib/formtools/tests/wizard/wizardtests/tests.py", line 375, in test_instance_is_maintained self.assertEqual(2, User.objects.count()) AssertionError: 2 != 3 -- Ran 5009 tests in 463.080s FAILED (failures=1, skipped=126, expected failures=5) I get identical results building using a clean, wheezy, schroot. However chose not to use my schroot setup here as it is simpler. Curiously the order of copying/creating files and the tests is different for both cases too (according to diff of the log). If I rerun the test on the same file system, I get identical results. My theory is the different ordering of the tests is causing the failure. So I thought maybe some sort of filesystem specific bug, maybe due to different iteration order of files or something. This doesn't make sense though, as I would expect different results every time. Also both filesystems are ext4, on LVM, using the same LVM VG, from the same source disk. /dev/mapper/aquitard-debian on / type ext4 (rw,relatime,errors=remount-ro,data=ordered) /dev/mapper/aquitard-home on /home type ext4 (rw,relatime,data=ordered) Both filesystems have plenty of space: /dev/mapper/aquitard-debian19G 17G 1.2G 94% / /dev/mapper/aquitard-home 19G 14G 4.1G 77% /home Yes, /tmp is in /, it doesn't have a separate filesystem. I considered the possibility that the build looks for /tmp and does something different (however dodgy that might be), however it looks like /aaa has the same issues as /tmp. Any ideas? Still doing some more tests, however this is just plain weird. Will try rebooting my system in case of some weird kernel issue (currently running 3.10-0.bpo.2-amd64). Also, I didn't have any problems with python-django version 1.5.1-2 -- Brian May
