RFS: scandir/0.1+git20130521-1 [ITP]
Hi everyone, I'm new to the team (thank you for letting me in) and I request sponsorship to upload the new package "scandir". * Package name: scandir Version : 0.1+git20130521-1 Upstream Author : Ben Hoyt * URL : https://github.com/benhoyt/scandir * License : BSD-3-clause Section : python It builds those binary packages: python-scandir - Python module which provides a better directory iterator python3-scandir - Python3 module which provides a better directory iterator To access further information about this package, please visit the following URL: http://mentors.debian.net/package/scandir Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/scandir/scandir_0.1+git20130521-1.dsc I also added my packaging in svn: http://anonscm.debian.org/viewvc/python-modules/packages/scandir/trunk/ svn://anonscm.debian.org/python-modules/packages/scandir/trunk/ The relevant ITP can be found here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711388 The official RFS is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711402 Let me know if anything is missing! Cheers, Nicolas -- 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/51d01960.6070...@nicolas-delvaux.org
Re: Bug#714302: RFP: python-discid -- Python binding of Libdiscid
As a follow-up I want to include some important links that were missing in my original mail. There didn't seem to be an actual link to the bug, although the bug # was included by reportbug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714302 Due to some missing linebreaks the link to an existing/working deb package was basically "hidden": https://code.launchpad.net/~jonnyjd/+junk/python-discid I would have sent an ITP or RFS, since the package already exists, but both don't make much sense since I can't really maintain the package myself without being a Debian user. I have several Debian VMs, but my development system is Arch Linux, where I also maintain some packages, including python-discid. I would however work closely with the maintainer like I have done with libdiscid (where I am also the upstream maintainer). -- JonnyJD signature.asc Description: This is a digitally signed message part.
Re: python-aeidon package
Hi Piotr, > Upstream switched to Python 3.X and I don't want to port it back to 2.X. > I can provide an older version of python-aeidon package (in a separate > source package) as a temporary solution, but I'd rather not release it > with Jessie. Ah. That's unfortunate. That's a pretty big break in compatibility. Thanks for your analysis of how ttkit could be ported to python 3. Unfortunately, there are at least two fairly major reverse-dependencies from the same upstream developers that will make this very difficult: pootle¹ and virtaal. Both of these are python 2-only and import translate. They have dependencies on things like python-django and python-gtk2². (And yes, perhaps we should split the translate-toolkit package into python-translate and translate-toolkit packages where the latter only ships the files in /usr/bin and their manpages so that it is more obvious that there is both a module API and a command line interface to translate-toolkit. It's not obvious to me whether it's worth doing that split for the sake of a few small files in /usr/bin.) I'll forward your analysis of this porting effort upstream, but I suspect that pootle and virtaal will prevent any porting of ttkit to python 3 for the time being; disabling subtitle support might be our only solution. I suspect (but have not checked) that the conversion to python 3 will also require some significant reworking of the translate-toolkit API to change what parts are done in bytes and what parts are in unicode/strings. ttkit is one of those places where python 3 will make the code much more robust and easier to work with but the conversion will be challenging. cheers Stuart ¹ I have now been trying to get pootle back into Debian for almost two years but I can never find a time where all its dependencies are actually in unstable and with compatible versions ☹. At present, it needs a newer python-django-south and an older python-django than what is available in sid. I'm starting to come to the conclusion that either pootle is very very unlucky or maintaining large python programs is impossible unless you minimise your exposure to modules that are outside your control and NIH as much as possible. Sadly, I think upstream is close to giving up on working with distributions and will encourage everyone to use virtualenv instead. If only API compatibility were more of a priority in python-land. ² I assume python-gtk2 is going to be a problem in itself some time soon. -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprintBE65 FD1E F4EA 08F3 23D4 3C6D 9FE8 B8CD 71C5 D1A8 -- 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/kqpdtf$ega$1...@ger.gmane.org
Re: setuptools 0.7
On 06/29/13 16:53, Thomas Kluyver wrote: > On 22 May 2013 16:28, Barry Warsaw wrote: > >> I think we should consider switching back to setuptools once 0.7 is >> released >> (defined as "available on PyPI), since this will clearly be the future of >> this >> component. We may have some fallout to deal with in other packages >> (e.g. virtualenv) that depend on this, and clearly setuptools/distribute >> is a >> central part of our stack. But it seems like now is a good time to shake >> that >> out for Jessie. >> > > PyPI now has the re-merged setuptools at version 0.7.4 - are we still > planning to package this as a new version of python-setuptools? yes, but not before python 3.3 as the defaults enters testing. one thing after the other. -- 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/51d0baaa.8050...@debian.org
