Bug#724311: ITP: python-pysolar -- Python library for precise ephemeris calculations
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-scie...@lists.debian.org, debian-python@lists.debian.org * Package name: python-pysolar Upstream Author : Brandon Stafford * URL : https://github.com/pingswept/pysolar/ * License : GPL/LGPL Programming Lang: Python Description : Python library for precise ephemeris calculations Here is a python library, similar to python-pyephem (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705339), but written in pure python. I don't believe it has refraction correction for sunrise/sunset calculations like pyephem does. I have made a couple of changes to its debian packaging in a pull request on the project's github repo: https://github.com/pingswept/pysolar/pull/6 -- 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/0344ed14-6a56-4d3e-8f46-49ee0fac1...@ammonit.com
Re: How to help with sphinx 1.2?
* Dmitry Shachnev , 2013-09-21, 16:24: Will you sponsor the new package (the package is mature enough for unstable, but let's upload it to experimental until the mentioned fixes are uploaded)? I won't have time to review or sponsor anything in the next few months. Sorry. -- Jakub Wilk -- 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/20130923172311.ga5...@jwilk.net
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
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
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 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
