Re: Bug#753590: ITP: python-pyqtgraph -- Scientific Graphics and GUI Library for Python
Il Sabato 5 Luglio 2014 17:26, Andreas Tille andr...@an3as.eu ha scritto: Hi Gianfranco, On Sat, Jul 05, 2014 at 10:41:09AM +0100, Gianfranco Costamagna wrote: Hi Andreas, thanks for doing this! I propose also to change the maintainer if you think is better, don't know ;) IMHO the maintainer should be a team (either Debian Science or Debian Python) and it seems reasonable to put the team in charge which is owning the VCS where the package is maintained. Since the package technically fits into Python and from content into Science there is no clear rule to decide. The Blends framework can be used in any case. It is no requirement to maintain a package in a certain team. Anyway I'm looking for a sponsor (I already have a busy one in debian-science), Since I think that the package clearly fits into Deban Science Blend I'm fine if you would use Sponsering of Blends: https://wiki.debian.org/DebianPureBlends/SoB (I changed from python to science for a really good reason: python uses svn and science uses git, and I'm a really a git user and supporter :p ) Wonderful, I added a line on that list. Just some questions: -I did not create the git on debian-science (I'm not yet accepted by the team), but I put the url as it will be if accepted (in the meanwhile the git is also here https://github.com/LocutusOfBorg/pyqtgraph ) -I'm not sure about the field Link to Web sentinel... One drawback of using Debian Python VCS is that it is not (yet) scanned for new packages and thus the package does not yet show up on the Science viewing page. Since I'm aware about this I would not mind about this requirement of SoB. and BTW the KGB bots in debian-science are broken (mdtx tried many times to unsuccessfully contact you, so I'm taking the opportunity to make you aware of the problem) I was contacted at least twice by somebody (may be mdtx - whoever this might be) and I answered in publich to the Debian Med maintainer list (I was contacted about Debian Med KGB) that I have no idea what needs to be done and I also have currently no time to make up my mind. I personally do not use KGB features and I expect somebody else in the team to do the necessary means to fix this. If this is considered unsuccessfully contact than yes, this was unsuccessful. But I have no idea why it should be me who should fix each and any piece of infrastructure. B-) So please in cases like this contact the team or use the BTS to report the problem. Sorry, I was not so clear, I wrote unsuccessfully because the irc user asked me many times about your mail, because he wasn't sure he ad the right mail address. For this problem please forget about it, as soon as I'll be accepted on the science team (I cannot see the kgb configuration file since I'm not in the science group) I'll take care of it. I have already setup this on pkg-boinc, so I have little knowledge about the troubleshooting of this stuff. I would like just ask you if you can forward to me the kgb mail you received, just to have a starting point about the problem. Have a nice sunday, Gianfranco Kind regards Andreas. -- http://fam-tille.de -- 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/1404645456.90757.yahoomail...@web171801.mail.ir2.yahoo.com
Bug#753949: smartypants: Please package newer upstream release (1.8.5)
Source: smartypants Severity: normal Hi! There have been a number of releases made since the last upload to Debian. I'd love to see a more recent release make it in before the freeze. Would you be interested in a co-maintainer? Ideally, we could add the package to the Debian Python Modules Team (DPMT). The same goes for python-typogrify which I filed #744978 on sometime back. Thanks! - Andrew Starr-Bochicchio -- System Information: Debian Release: jessie/sid APT prefers trusty-updates APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty'), (100, 'trusty-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13.0-29-generic (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20140706162237.23694.47769.reportbug@asb-laptop
Bug#753962: ITP: ghp-import -- Easily import docs to your gh-pages branch
Package: wnpp Severity: wishlist Owner: Andrew Starr-Bochicchio a...@debian.org * Package name: ghp-import Version : 0.4.1 Upstream Author : Paul Joseph Davis paul.joseph.da...@gmail.com * URL : https://github.com/davisp/ghp-import * License : Tumbolia Public License Programming Lang: Python Description : Easily import docs to your gh-pages branch ghp-import is a Python script meant to make using GitHub's gh-pages branches for hosting documentation simple. . Inside your repository just run `ghp-import $DOCS_DIR` where $DOCS_DIR is the path to the built documentation. This will write a commit to your gh-pages branch with the current documents in it. While I'm no fan of license proliferation, the Tumbolia Public License seems to meet the requitements of the DFSG. Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. opan saurce LOL Thoughts? Thanks! - Andrew Starr-Bochicchio -- 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/20140706171449.24962.47936.reportbug@asb-laptop
Passing arguments to nosetests in debian/rules:override_dh_auto_test
Hi, Currently I am packging oct2py[0] which is a bridge between python and GNU octave Since some unit tests had issues with memory, upstream started to pass some arguments to the nosetests[1], since this arguments are passed in upstream travis.yml and Makefile they aren't taken by dh_auto_test. I am using pybuild and I want to pass this arguments in the override_dh_auto_test section. How can I pass them? and which is the right way to do it? Cheers [0]: https://github.com/blink1073/oct2py [1]: https://github.com/blink1073/oct2py/issues/45 --- Josue Ortega «Happy Hacking» http://josueortega.org signature.asc Description: Digital signature
/usr/bin/django-admin in python-django
While I am happy with the majority of this package, not sure about this wrapper. It was designed to prevent conflicts between python-django and python3-django. As an example: (wheezy)root@aquitard:~# /usr/bin/django-admin dumpdata --settings=karaage.tests.settings Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/django/bin/django-admin.py, line 5, in module management.execute_from_command_line() File /usr/lib/python2.7/dist-packages/django/core/management/__init__.py, line 399, in execute_from_command_line utility.execute() File /usr/lib/python2.7/dist-packages/django/core/management/__init__.py, line 392, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File /usr/lib/python2.7/dist-packages/django/core/management/__init__.py, line 261, in fetch_command commands = get_commands() File /usr/lib/python2.7/dist-packages/django/core/management/__init__.py, line 107, in get_commands apps = settings.INSTALLED_APPS File /usr/lib/python2.7/dist-packages/django/conf/__init__.py, line 54, in __getattr__ self._setup(name) File /usr/lib/python2.7/dist-packages/django/conf/__init__.py, line 49, in _setup self._wrapped = Settings(settings_module) File /usr/lib/python2.7/dist-packages/django/conf/__init__.py, line 132, in __init__ % (self.SETTINGS_MODULE, e) ImportError: Could not import settings 'karaage.tests.settings' (Is it on sys.path? Is there an import error in the settings file?): No module named tests.settings The problem is that the django-admin wrapper chose the python3 version, but karaage.tests.settings is only available in Python2, even though I have python3-django installed. However, anything I do here will mean making changes from upstream. I guess I could also try to parse the --settings or DJANGO_SETTINGS_MODULE, try to determine automatically if the Python3 version exists. However I think this could get very messy very quickly and probably won't work in all cases. This is significant for me, as I have postinst scripts that do the following: django-admin collectstatic --settings=kgadmin.conf.settings --noinput Have changed that now to: python2.7 /usr/lib/python2.7/dist-packages/django/bin/django-admin.py \ collectstatic --settings=kgadmin.conf.settings --noinput Can change it for new packages, not for old packages though. I don't see any good solution for this though. Hopefully nobody else does this :-) -- Brian May br...@microcomaustralia.com.au
Re: Passing arguments to nosetests in debian/rules:override_dh_auto_test
On Mon, Jul 7, 2014 at 2:45 AM, Josue Ortega wrote: How can I pass them? and which is the right way to do it? According to the nosetests manual page the right way to do it is for upstream to delete the options from the Makefile and from travis.yaml and put them in a [nosetests] section in the setup.cfg file. Please read the manual page and send them a patch to do that. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6HVO+REozgZ+Y9ZLMmX9WOEv2YuPMk=zjcqjvvvg49...@mail.gmail.com
python3-django and mysqldb
According to Django 1.6 documentation: https://docs.djangoproject.com/en/1.6/ref/databases/#python-3 The recommended solution is to use an unofficial fork of mysqldb, such as https://github.com/clelland/MySQL-for-Python-3 According to Django 1.7 documentation, the recommended solution is to use the MySQL Connector/Python: See https://docs.djangoproject.com/en/1.7/ref/databases/#mysql-db-api-drivers Which is already in unstable: python-mysql.connector python3-mysql.connector It looks like these do contain the Django connectors required. So maybe we should update the Django package headers to suggest these instead of mysqldb, as mysqldb development appears to be dead. As far as I can tell this should be supported in Django 1.6 (assuming I am reading a particular line in the documentation correctly). -- Brian May br...@microcomaustralia.com.au
