Re: python-openssl unavailable in sid
On Mon, Sep 8, 2014 at 09:57:36 +1000, Brian May wrote: > As far as I can tell, this problem has been fixed. ftp-master didn't > respond, maybe it come good by itself? No, they fixed it last week. Cheers, Julien -- Julien Cristau Logilab http://www.logilab.fr/ Informatique scientifique & gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140908082836.ga24...@crater2.logilab.fr
django 1.7 change for backport to wheezy
Hello, Can I please get the following change in python-django git? Add the following to debian/control: X-Python-Version: >= 2.7 This will make backports to stable a lot easier. Otherwise the package builds fine, but won't install in Python 2.6 is installed. I would do it myself, but not 100% confident of the branches - I guess I should use the debian/experimental branch? Thanks -- Brian May
Terminal Pager at unit tests
Hi, Currently I am working on the debianization of oct2py[1] which is a bridge between Python an GNU Octave. When the tests are running the docstrings are displayed in a terminal pager making impossible run all tests without human interaction to close the pager. I've found this really annoying if someone wants to build the package even the build process might fail if it's running on an automated enviroment. I could't find an elegant way to disable the terminal pager. Since I've noticed that the terminal pager does not run when the package is built with cowbuilder I've added a workarround that is: override_dh_auto_test: python2 -m unittest discover -v > /dev/null python3 -m unittest discover -v > /dev/null This avoids the annoying pager, but I am not happy with this solution and I am not sure if it's correct. Anyone of you know how disable the terminal pager in an elegant way? Here is the repo url, if anyone wants to check it out[2] Thanks [1]: https://github.com/blink1073/oct2py [2]: http://anonscm.debian.org/viewvc/python-modules/packages/oct2py/ --- Josue Ortega «Happy Hacking» http://josueortega.org signature.asc Description: Digital signature
django 1.7 migrations
Hello, Just noticed, if you generate Django 1.7 migrations using Python 2, they won't be Python 3 compatible. i.e. strings such as 'name' will become b'name' in the migration, which doesn't work in python 3. The work around seems to be to remove the b'...' by hand or make the migrations using Python 3. Presumably if you use unicode strings everywhere or add the following to the top of model files, this wouldn't be an issue. Not tested it myself. from __future__ import unicode_literals I reported this upstream: https://code.djangoproject.com/ticket/23455 Thanks -- Brian May
Fwd: Processed: not a django1.7 bug
Hello, I just tidied up this bug. It started off as a Django1.7 bug, then it got retitled to a Python3 bug. Then I wondered if maybe I should have cloned it, and retitled the original back to the original value, and closed it. If you want to refine my efforts, feel free to do so. Thanks -- Forwarded message -- From: Debian Bug Tracking System Date: 9 September 2014 16:06 Subject: Processed: not a django1.7 bug To: Brian May Processing commands for cont...@bugs.debian.org: > user python-dja...@packages.debian.org Setting user to python-dja...@packages.debian.org (was br...@microcomaustralia.com.au). > usertag 755642 -django17 Usertags were: django17. Usertags are now: . > thanks Stopping processing here. Please contact me if you need assistance. -- 755642: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755642 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- Brian May
Re: django 1.7 change for backport to wheezy
Hi, On Tue, 09 Sep 2014, Brian May wrote: > Can I please get the following change in python-django git? > > Add the following to debian/control: > > X-Python-Version: >= 2.7 > > This will make backports to stable a lot easier. Otherwise the package > builds fine, but won't install in Python 2.6 is installed. > > I would do it myself, but not 100% confident of the branches - I guess I > should use the debian/experimental branch? Yes, please commit that on the debian/experimental branch. (Sorry that I lost this in the git conversion.) Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140909063146.ga31...@x230-buxy.home.ouaza.com
Re: django 1.7 change for backport to wheezy
On 9 September 2014 16:31, Raphael Hertzog wrote: > Yes, please commit that on the debian/experimental branch. > Will do that tomorrow. > (Sorry that I lost this in the git conversion.) > Thought I had made the change before. Not loosing my mind after all :-) Not a problem, easy to redo it. -- Brian May
Re: No __init__.py for namespaced module in Python 3.4
Hi barry, Thanks for your answer. On 09/06/2014 05:38 AM, Barry Warsaw wrote: > On Sep 05, 2014, at 11:16 PM, Thomas Goirand wrote: > >> Surprisingly, when I just do (as root): >> >> echo "" >/usr/lib/python3/dist-packages/oslo/__init__.py >> >> then everything works again, and subunit under Python3.4 can find the >> local version of oslo.serialization. > > Is there by any chance a /usr/lib/python3/dist-packages/oslo/__pycache__ > directory with an __init__.pyc file in it? No, there's no such thing. No __pycache__ directory at all there. > One thing you can do is run `python3 -v` to watch what Python tries to > import. It will be quite verbose though. > >> Currently, I'm disabling the unit tests for Python 3.4 in >> oslo.serialization, but this really doesn't seem to be the way to go, >> and I would like to find a way to fix this. > > Is this testable locally on a sid machine? By all means, please do try by yourself. The package is still in the NEW queue, so you'll have to get it from Git: git clone \ ssh://git.debian.org/git/openstack/python-oslo.serialization.git cd python-oslo.serialization ./debian/rules gen-orig-xz If you want to add Python3 tests, simply do: -set -ex ; for i in $(PYTHONS) ; do \ +set -ex ; for i in $(PYTHONS) $(PYTHON3S) ; do \ in the debian/rules file. BTW, I'm not sure I understand what Paultag tried to explained to me. :( Sure, I get the point about not having an __init__.py file so that "oslo" keeps being a namespace rather than a package. But is there something in Paultag's reply that would help having working unit tests in the python-oslo.serialization package? Or did I miss something? Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/540ea25a.5030...@debian.org
