Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

2015-09-30 Thread Thomas Kluyver
On Wed, Sep 30, 2015, at 01:53 AM, Thomas Goirand wrote: > This has driven > some contributors away in the past, thinking we don't have team spirit. > IMO, that's truth, and this kind of thread is hurting again. Just to back this up: watching threads like this go past makes working on/with Debian

Re: Dealing with flit -- a simplified packaging of python modules

2015-09-24 Thread Thomas Kluyver
On Thu, Sep 24, 2015, at 03:30 AM, Paul Wise wrote: > Source tarballs containing generated/bundled files is a bug that > should be fixed. That's my point ;-). From our upstream point of view, it's not a bug that the distributions we put on PyPI contain generated/bundled files - we do it that way

Re: Dealing with flit -- a simplified packaging of python modules

2015-09-20 Thread Thomas Kluyver
On Sat, Sep 19, 2015, at 09:36 AM, Barry Warsaw wrote: > There have been countless attempts at moving the Python packaging > infrastructure to a declarative syntax over the years. I remember > talking to > Tarek at a Pycon *many* years ago about this. Maybe this time it'll > catch > on. :) I

Re: Dealing with flit -- a simplified packaging of python modules

2015-09-19 Thread Thomas Kluyver
On Fri, Sep 18, 2015, at 11:56 PM, Julien Puydt wrote: > here is a new way to package modules for Python: > https://github.com/takluyver/flit > > It means that something packaged using it doesn't use a setup.py or some > such, but a flit.ini ; see for example: >

Re: Dealing with flit -- a simplified packaging of python modules

2015-09-19 Thread Thomas Kluyver
On Sat, Sep 19, 2015, at 01:05 AM, Julien Puydt wrote: > Yes, you're also upstream for ptyprocess and terminado :-P Guilty as charged ;-) I work for Jupyter/IPython, so there are several dependencies from that that I'm responsible for. > I have nothing against declarative -- it's just that I

Re: Removing some python3-* packages

2015-08-24 Thread Thomas Kluyver
On Mon, Aug 24, 2015, at 04:30 PM, Robert Collins wrote: c) write convoluted tricky code to workaround the bugs and differing behaviour on 3.4 vs 3.5. I use unittest.mock from Python 3.4 on several packages, and it has not required convoluted code. I would be very surprised if that code breaks

Re: Help needed for broken clean target of python module

2015-06-22 Thread Thomas Kluyver
On Mon, Jun 22, 2015, at 12:20 PM, Andreas Tille wrote: /home/andreas/debian-maintain/alioth/debian-med_git/build-area/python-dendropy-4.0.2/dendropy/utility/textprocessing.py, line 44, in bytes_to_text s = codecs.decode(s, ENCODING) TypeError: must be string, not None Looks like

Re: /usr/bin/python in Python 2 and 3

2015-04-21 Thread Thomas Kluyver
On 21 April 2015 at 08:15, Barry Warsaw ba...@debian.org wrote: For third parties who want to distribute scripts that run out-of-the-box everywhere (installers, cross-platform system management or monitoring scripts, build scripts, etc.), Python 3 isn't an option. If we remove Python 2 from

Re: Bits from the Debian PyCon Hangout - /usr/bin/python

2015-04-15 Thread Thomas Kluyver
It's worth mentioning that in virtualenvs and conda envs, where there can only be one version of Python installed, 'python' refers to that whether it is Python 3 or 2. So it's already not a safe assumption that 'python' always means Python 2, even if you discount Arch. On 15 April 2015 at 21:04,

Re: PyCon BoF: Stretch goals for cPython, PyPy CFFI

2015-04-14 Thread Thomas Kluyver
On 14 April 2015 at 08:10, Barry Warsaw ba...@python.org wrote: But it fails unhelpfully when you use it in a shebang. $ /tmp/foo.py bash: /tmp/foo.py: /usr/bin/python: bad interpreter: No such file or directory Let's make the latter more helpful. From a script authors point of view,

Re: PyCon BoF: Stretch goals for cPython, PyPy CFFI

2015-04-14 Thread Thomas Kluyver
On 14 April 2015 at 08:57, Scott Kitterman deb...@kitterman.com wrote: I have scripts I use locally that are untouched in almost a decade that use /usr/bin/python. I'm thinking about scripts that are written and distributed to people running on different, unknown, Linux distros. Obviously if

Re: dh_python2 extension rename breaking module loading

2015-02-11 Thread Thomas Kluyver
On 11 February 2015 at 14:22, Scott Kitterman deb...@kitterman.com wrote: Given the filename, shouldn't it be import khmermodule? foomodule.so was a valid filename for a module 'foo' - though I only heard about this when that spelling was removed in Python 3.3:

Re: multiple modules in one source

2014-12-14 Thread Thomas Kluyver
On 14 December 2014 at 15:34, Brian May br...@microcomaustralia.com.au wrote: Not sure calling it multiple distinct Python packages is correct, currently there is only one setup.py, and hence only one egg file produced. e.g. package contains setup.py module1/__init__.py

Re: Help needed to test packages with Django 1.7

2014-08-04 Thread Thomas Kluyver
On 4 August 2014 10:29, Thomas Goirand z...@debian.org wrote: Also, fixing version 3 of beautifulsoup doesn't look very easy. It needs sgmllib, which is removed from Python 3, and it doesn't feel right to maintain sgmllib as a Python module for Python 3 (I tried, and with a few hacks, it

Re: favouring Python3 in the Debian policy

2014-05-07 Thread Thomas Kluyver
On 7 May 2014 14:11, Paul Tagliamonte paul...@ubuntu.com wrote: If I had more time to blow, I'd likely try a run at something SUDS API compatible in Python 3. Won't happen any time soon for me, but it's something I will eternally praise someone over. So many people have tried to forward-port

Re: Making packaging Python modules fun again (was: Re: Indeed, python-concurrent.futures is the same)

2014-01-26 Thread Thomas Kluyver
On 26 Jan 2014 16:33, Paul Tagliamonte paul...@debian.org wrote: On Mon, Jan 27, 2014 at 12:14:12AM +0100, Nicolas Dandrimont wrote: [ awesome points here ] Cheers, Nicolas Dandrimont Hear, Hear! Ditto - I agree with just about everything Nicolas said. I'd love to see this become a

Re: Indeed, python-concurrent.futures is the same

2014-01-25 Thread Thomas Kluyver
On 25 Jan 2014 07:37, Thomas Goirand z...@debian.org wrote: On 01/25/2014 06:01 PM, Sandro Tosi wrote: Sorry, what? and you didn't think to contact me first to almost rewrite the package? If there's problems, open bugs. Revert your changes or I'll do at the first occasion. and mainly, why

Re: CLI recommendations for version-specific /usr/bin scripts

2013-11-11 Thread Thomas Kluyver
On 11 November 2013 08:45, Barry Warsaw ba...@debian.org wrote: * Expose /usr/bin/foo with a shebang line of #!/usr/bin/python * Expose /usr/bin/foo-3 with a shebang line of #!/usr/bin/python3 In upstream IPython, we now install an ipython2 script on Python 2, paralleling the ipython3

Re: Packaging the new upstream release of ipython (i.e. 1.1.0)

2013-10-03 Thread Thomas Kluyver
Hi Jean-Christophe, On 29 September 2013 13:31, Jean-Christophe Jaskula jean.christophe.jask...@gmail.com wrote: The Ipython team has released a couple of major releases during the last months but I haven't seen any discussions about packaging them in debian. Just for curiosity, I decided to

Re: PEP 453 affects Debian packaging of Python packages

2013-09-20 Thread Thomas Kluyver
On 20 September 2013 01:11, Thomas Goirand z...@debian.org wrote: From a developer point of view: this leaves you dependent on other people to get the latest release of your software to users, which can be very frustrating. For instance, I'm a developer for IPython: we made a 1.0 release

Re: PEP 453 affects Debian packaging of Python packages

2013-09-20 Thread Thomas Kluyver
On 20 September 2013 10:52, Paul Tagliamonte paul...@debian.org wrote: If a library breaks API because the maintainer wanted another toy rewrite, we're not going to upload it and break half the archive. That's silly. This condescending attitude towards developers ('another toy rewrite')

Re: PEP 453 affects Debian packaging of Python packages

2013-09-20 Thread Thomas Kluyver
On 20 September 2013 12:08, Paul Tagliamonte paul...@debian.org wrote: Don't take this as me trashing on Python or Pythonistas. If you want to talk about this in person, I'm usually at PyCon. I'm also usually in the packaging BOF. Perhaps we can bring some of this up there this year?

Re: PEP 453 affects Debian packaging of Python packages

2013-09-20 Thread Thomas Kluyver
On 20 September 2013 16:00, Andrey Rahmatullin w...@wrar.name wrote: Packaging often takes much longer than a couple of days, especially if the packager is not experienced. And when the work is published somewhere, but not yet uploaded, there is no general way to know if it's published and

Re: PEP 453 affects Debian packaging of Python packages

2013-09-18 Thread Thomas Kluyver
On 18 September 2013 08:41, Piotr Ożarowski pi...@debian.org wrote: so instead of reinventing the wheel and trying to make something that works everywhere they should make it easier for others to convert whatever they provide (tarballs?) into .rpm, .deb or .exe. From a developer point of

Re: RFS: python3-sympy

2013-07-20 Thread Thomas Kluyver
I've updated the python3-sympy package in SVN to the new upstream release, 0.7.3. Is anyone interested in reviewing or uploading this? Thank-you, Thomas On 29 June 2013 23:17, Thomas Kluyver tak...@gmail.com wrote: On 6 June 2013 11:15, Thomas Kluyver tak...@gmail.com wrote: Please can

Re: starting to dive into python package bugs

2013-07-16 Thread Thomas Kluyver
On 16 July 2013 22:25, Stéphane Blondon stephane.blon...@gmail.com wrote: I checked the string exceptions in the code and they are not catched (see shell commands used at this end of this message). So I plan to wrap the string with an exception (Exception ou TypeError). To me, the errors

Re: starting to dive into python package bugs

2013-07-03 Thread Thomas Kluyver
On 3 July 2013 19:36, Barry Warsaw ba...@debian.org wrote: The reason is that if some code is trying to: except 'error message' this will fail if the raise site is changed. In fact it will already fail - recent Python 2 versions throw a TypeError if you attempt to raise a bare string

Re: setuptools 0.7

2013-06-29 Thread Thomas Kluyver
On 22 May 2013 16:28, Barry Warsaw ba...@python.org 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.

Re: RFS: python3-sympy

2013-06-29 Thread Thomas Kluyver
On 6 June 2013 11:15, Thomas Kluyver tak...@gmail.com wrote: Please can someone upload the new package python3-sympy Package name : python3-sympy Version : 0.7.2-2 URL : http://sympy.org/ Binary packages: python3-sympy It's already in the team svn: svn

Re: django-tables package

2013-06-19 Thread Thomas Kluyver
On 19 June 2013 05:47, Brian May br...@microcomaustralia.com.au wrote: How do I do this? I don't see any references to objects.inv in the upstream source code for django-filter, and I am not really sure what these files are used for. The files are an index of objects described in the Python

RFS: python3-sympy

2013-06-06 Thread Thomas Kluyver
Please can someone upload the new package python3-sympy Package name : python3-sympy Version : 0.7.2-2 URL : http://sympy.org/ Binary packages: python3-sympy It's already in the team svn: svn://svn.debian.org/python-modules/packages/python3-sympy/trunk/ From a previous

Re: Accepted python-defaults 2.7.3-5 (source all)

2013-05-07 Thread Thomas Kluyver
On 7 May 2013 18:46, Sandro Tosi sandro.t...@gmail.com wrote: debian-python doesn't deserve a similar communication (don't you dare thinking about coordination, it's out of question) because we're just a bunch of puppets waiting for orders by the ultimate master - well done. Selectively

Re: About canonical Vcs fields

2013-03-14 Thread Thomas Kluyver
On 14 March 2013 14:01, Scott Kitterman deb...@kitterman.com wrote: 3. Don't care to invest any thought or time in the question. That's pretty much my thinking. If someone wants to go through and automatically change svn. - anonscm., that's fine. I'm mildly against having a Lintian rule for

Re: Removing /usr/bin/nosetests-3.x scripts

2013-02-22 Thread Thomas Kluyver
On 22 February 2013 06:28, Dmitry Shachnev mity...@gmail.com wrote: After looking at all packages that build-depend on python3-nose, I've identified these packages as needing fix: I happen to recall that python-xdg is also affected, both in debian/rules [1] and autopkgtests [2]. I'm happy to

Re: python3 and /usr/share

2013-02-20 Thread Thomas Kluyver
On 20 February 2013 14:38, Olе Streicher debian-de...@liska.ath.cx wrote: I am trying to create packages for Python3 for the source package [1]. Following the guide [2], I get some success. However, the packages for Python2 and Python3 differ significantly: in the Python2 package, all machine

Re: How does team maintenace of python module works?

2013-02-20 Thread Thomas Kluyver
On 20 February 2013 14:53, Thomas Goirand z...@debian.org wrote: In what way the QA is different because it's a tag instead of a tarball ? I don't understand your reasoning. In both cases, you must make sure that what you are packaging is buildable, tested, QA, etc. I think the idea is that,

Re: How does team maintenace of python module works?

2013-02-19 Thread Thomas Kluyver
On 19 February 2013 17:55, Thomas Goirand z...@debian.org wrote: Thomas Kluyver Seems to be ok with migrating to Git (so, option D) I voted CDBA in the same e-mail that I introduced the poll ;-). Thanks for summarising the votes. Including Piotr Andreas, and putting people whose opinion

Re: How does team maintenace of python module works?

2013-02-18 Thread Thomas Kluyver
On 18 February 2013 20:46, Ludovic Gasc gml...@gmail.com wrote: I vote D, and I can handle the migration from SVN to Git, I've done this several times for my work and WYMeditor. Are you interested? I'm interested personally, but the votes so far suggest there's no real will for any change -

Re: How does team maintenace of python module works?

2013-02-18 Thread Thomas Kluyver
On 18 February 2013 22:23, Ludovic Gasc gml...@gmail.com wrote: I propose to make a poll on the Web (Doodle or other) and ask the question in another thread, I'm not sure that each subscriber has read this long thread. I don't think I'll do that myself - the responses I have seen don't have

Re: How does team maintenace of python module works?

2013-02-16 Thread Thomas Kluyver
On 16 February 2013 09:10, Thomas Goirand z...@debian.org wrote: It would be really stupid to only want to claim to be working as part of the team, that's not at all what I want to do. I'd like to be able to help when I can, and receive help when I need, which is the point of a team. I

Re: How does team maintenace of python module works?

2013-02-14 Thread Thomas Kluyver
On 14 February 2013 12:12, Thomas Goirand z...@debian.org wrote: Is there a valid reason despite history? Is there a chance that this rule may be reconsidered? It'd be really nice, as I'm sure I wouldn't be the only one happy with such decision. I don't know the history, but I'll voice my

Re: How does team maintenace of python module works?

2013-02-14 Thread Thomas Kluyver
On 14 February 2013 16:41, Sandro Tosi sandro.t...@gmail.com wrote: so please search into the mailing list archive about the several iterations of such discussion and the outcome of them. The most recent discussion I found with a quick search started nearly 2 years ago. Nobody appeared to be

Re: How does team maintenace of python module works?

2013-02-14 Thread Thomas Kluyver
On 14 February 2013 20:29, Barry Warsaw ba...@python.org wrote: I look at the switch to dh_python2 as an example. I don't think it's a particularly good example, though. Lots of packages continue to use the older helpers, and not due to a lack of time - attempts to move away from the

Re: How does team maintenace of python module works?

2013-02-14 Thread Thomas Kluyver
On 14 February 2013 22:54, Matthias Klose d...@debian.org wrote: That causes problems when newcomers don't want to learn deprecated packaging methods, and aren't allowed to update packages to use the recommended helper. Agreed, so why not helping with it? Again, why not helping here?

python-xlrd

2013-02-06 Thread Thomas Kluyver
The python-xlrd package is maintained by Thomas Bläsing and the DPMT, but the packaged version is quite old. A PAPT thread from last year suggests that Thomas Bläsing is missing in action [1]. I've prepared a new version of the package, using a patch from the bug tracker, the latest upstream

Re: python-xlrd

2013-02-06 Thread Thomas Kluyver
On 6 February 2013 12:52, Sandro Tosi sandro.t...@gmail.com wrote: Yes I do: Thomas is set as the Maintainer (as opposed to the team being the Maintainer), so your are more forced to ask Thomas first given the huge changes you're planning to do: did you contact him (it doesn't seem so from

Re: python-xlrd

2013-02-06 Thread Thomas Kluyver
On 6 February 2013 19:30, Sandro Tosi sandro.t...@gmail.com wrote: please read our unwritten policy about Maintainer field at http://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin As a general rule of thumb, just set Maintainer to the team; there might be some exceptions, like in

Re: Private modules

2012-12-24 Thread Thomas Kluyver
On 22 December 2012 22:00, Bas Wijnen wij...@debian.org wrote: 6. Make /usr/bin/program a symlink to the actual file in the private directory. It will then search in its real place. (I've seen this used by angrydd.) This (symlinking /usr/bin/program) appears to be the recommended way to deal

Re: GUI tool for packaging

2012-11-15 Thread Thomas Kluyver
Hi Clint, On 15 November 2012 03:53, Clint Byrum cl...@ubuntu.com wrote: https://launchpad.net/pkgme At one point I was interested in writing a ruby backend for this, but got distracted and moved to other focus, but I think it solves what you are talking about, without need to develop a

Re: GUI tool for packaging

2012-11-15 Thread Thomas Kluyver
On 15 November 2012 15:18, Andrey Rahmatullin w...@wrar.name wrote: Bottom line: if you want to get a good package, it's not always possible to fully automate that, especially in cases of complex (and proprietary) software like that you mentioned, and so a GUI wizard can't do everything

Re: GUI tool for packaging

2012-11-14 Thread Thomas Kluyver
On 14 November 2012 11:43, Jakub Wilk jw...@debian.org wrote: I don't think so, sorry. Could you expand on this at all? Do you think that packaging should be left to the experts? Or that the existing systems are easy enough for newcomers to learn? Thomas

Re: Python fdb

2012-11-13 Thread Thomas Kluyver
(Resending to the list) Hi Philippe, On 13 November 2012 12:36, Philippe Makowski pmakow...@espelida.com wrote: I never packaged any thing for Debian yet, I have to learn everything about Debian rules and tools for packaging. I'm trying to start a GUI application to simplify Debian

Re: Sympy 0.7.2

2012-11-12 Thread Thomas Kluyver
Returning to the original topic: I've now svn-injected python3-sympy [1], and successfully built it in a PPA [2]. [1] http://anonscm.debian.org/viewvc/python-modules/packages/python3-sympy/ [2] https://launchpad.net/~takluyver/+archive/python3 Thanks, Thomas On 8 November 2012 13:32, Jakub

GUI tool for packaging

2012-11-09 Thread Thomas Kluyver
This is an idea I've had knocking around for a while. Packaging is complex - there are lots of different tools and syntaxes you have to understand to do a good job of it - quilt, debhelper, watch files, etc. - along with specialist terminology. I know various CLI tools aim to simplify things, but

Re: pyxs review

2012-11-09 Thread Thomas Kluyver
On 9 November 2012 12:44, Maykel Moya mm...@mmoya.org wrote: Even in the case of the more restrictive license applying only to debian/* work? Could you/someone elaborate a little the implications of this (link to fine documentation is welcomed)? I'm not sure if there's a Debian rule about

Re: Advise on packaging a new Python module

2012-11-08 Thread Thomas Kluyver
On 8 November 2012 14:15, Andreas Tille andr...@an3as.eu wrote: As far as I have followed this thread I have not seen an answer to this part of your mail. I admit I have no idea how to support Python 2 *and* 3 but wild-guessing from my experience with Debian tools I doubt any manual code

Re: RFS: pyxdg 0.24-1

2012-11-06 Thread Thomas Kluyver
(Resending to the list - sorry) On 6 November 2012 12:36, Thomas Kluyver tho...@kluyver.me.uk wrote: On 6 November 2012 12:03, Dmitrijs Ledkovs x...@debian.org wrote: Can you add an autopkgtest that runs the upstream testsuite? I've had a go - can you have a glance at the attached patch

Re: RFS: pyxdg 0.24-1

2012-11-06 Thread Thomas Kluyver
On 6 November 2012 12:54, Dmitrijs Ledkovs x...@debian.org wrote: Looks good. Commit and I will sponsor your package. Done. Thanks, Dmitrijs. Thomas

Re: RFS: pyxdg 0.24-1

2012-11-06 Thread Thomas Kluyver
On 6 November 2012 13:18, Dmitrijs Ledkovs x...@debian.org wrote: I am thinking to upload to experimental instead of unstable. It's a few upstream releases jump and a python3 package is introduced. This makes this changes unsuitable for unstable considering that we are currently frozen and

Re: Sympy 0.7.2

2012-10-29 Thread Thomas Kluyver
On 29 October 2012 04:42, Dmitry Shachnev mity...@gmail.com wrote: What was the MathJax complain about? I maybe can help you with that. dh_sphinxdoc: debian/python-sympy/usr/share/doc/python-sympy/html/ https://c328740.ssl.cf1.rackcdn.com/mathjax/latest/MathJax.js?config=TeX-AMS_HTML-fullis

Re: Sympy 0.7.2

2012-10-28 Thread Thomas Kluyver
On Oct 25, 2012 6:31 PM, Thomas Kluyver tho...@kluyver.me.uk wrote: I assume that building the binary packages from a single source package is preferred? sympy devs reckon we should use the separate release tarballs. Is that acceptable for Debian? Thomas

Re: Sympy 0.7.2

2012-10-28 Thread Thomas Kluyver
On 28 October 2012 08:47, Jakub Wilk jw...@debian.org wrote: I assume that building the binary packages from a single source package is preferred? sympy devs reckon we should use the separate release tarballs. Is that acceptable for Debian? Yes. OK. I've committed the minor changes

Re: #! /usr/bin/python{,3} -Es

2012-10-26 Thread Thomas Kluyver
On 26 October 2012 09:19, Floris Bruynooghe f...@devork.be wrote: Several people have said they don't think this is a good idea. But why not? There is a bad effect if you don't rewrite the shebang to /usr/bin/python[3] -ES that we know of, but is there any example of where such a shebang

Re: #! /usr/bin/python{,3} -Es

2012-10-26 Thread Thomas Kluyver
On 26 October 2012 11:53, Chow Loong Jin hyper...@debian.org wrote: What is the definition of system script? Any script installed via dpkg, perhaps? I wouldn't have said so - I install plenty of Python scripts from packages, like /usr/bin/ipython, that I wouldn't call system scripts. I don't

Re: #! /usr/bin/python{,3} -Es

2012-10-26 Thread Thomas Kluyver
On 26 October 2012 14:20, Paul Tagliamonte paul...@debian.org wrote: django-admin if I'm using a virtualenv? Perhaps I'm missing the point? Will this just break all virtualenv support? To my mind, django-admin is not a system script. A system script would be something like the

Sympy 0.7.2

2012-10-25 Thread Thomas Kluyver
The attached patch is a first stab at packaging SymPy 0.7.2, which supports Python 3. There's some polishing to be done, such as adding an isympy3 script, but it at least builds. I assume that building the binary packages from a single source package is preferred? The upstream releases on Google

Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz

2012-10-02 Thread Thomas Kluyver
On 2 October 2012 09:01, Nicolas Chauvat nicolas.chau...@logilab.fr wrote: PS: by the way, would anyone know of a way to use chroot or something similar to allow any user to have any number of virtual environments that use apt-get to install stuff and fall-back to the system if something is

Re: PyCon 2013 -- anyone going? ideas for the talks?

2012-09-22 Thread Thomas Kluyver
On 21 September 2012 19:32, Paul Boddie p...@boddie.org.uk wrote: From following discussions on python-dev, I imagine that it might be interesting for people to be shown how following the basic best practices around metadata and configuration information can get you most of the way to making a

Re: PyCon 2013 -- anyone going? ideas for the talks?

2012-09-21 Thread Thomas Kluyver
With apologies in advance for straying off topic ;-) On 21 September 2012 14:18, Yaroslav Halchenko deb...@onerussian.com wrote: Previously I have done a similar talk with an accent on a scientific Python stack in Debian [1] which I thought was quite well accepted. We're having a big

Re: Xpra to publicly expose its modules

2012-09-18 Thread Thomas Kluyver
On 18 September 2012 18:00, Dmitry Smirnov only...@member.fsf.org wrote: At the moment I can't recall a good example but there are some exceptions like when package in mainly used as application. IPython is packaged as 'ipython', 'ipython3', etc., and it also includes a public module. Thomas

Re: Availability of Numpy, WX, Matplotlib and Scipy under Python3

2012-09-03 Thread Thomas Kluyver
Hi Nigel, On 3 September 2012 14:57, Nigel Sedgwick n...@camalg.co.uk wrote: The application makes heavy use of numpy and wx and will soon make heavy use of scipy, matplotlib and various other python libraries that are widely used. Python 3 versions of numpy and scipy are already in wheezy.

Re: Please add me to the team

2012-08-10 Thread Thomas Kluyver
On 10 August 2012 11:33, Jakub Wilk jw...@debian.org wrote: I'm confused. Why do you ask _us_ if you can inject a package into Debian Med repo? I think he's checking that it's OK to get help here with some packaging that won't live in the DPMT repository. That's presumably fine, but if he's not

Re: pyxdg 0.23

2012-08-01 Thread Thomas Kluyver
Thanks Barry, On 1 August 2012 19:51, Barry Warsaw ba...@python.org wrote: - I bumped d/compat to 9 and BD on debhelper = 9 - In the d/control python-xdg and python3-xdg stanzas, I added the appropriate Python 2 or Python 3 text in the first line of Description: I've applied both of these,

RFS: pyxdg 0.23-1

2012-08-01 Thread Thomas Kluyver
Hello, I'd like to request a sponsor to upload a new version of pyxdg. Package name: pyxdg Version : 0.23-1 Upstream Author : Sergey Kuleshov svyato...@gentoo.org; Heinrich Wendel h_wen...@cojobo.net; Thomas Kluyver tho...@kluyver.me.uk URL : http://freedesktop.org/wiki

Re: pyxdg 0.23

2012-07-31 Thread Thomas Kluyver
On 31 July 2012 08:02, Jakub Wilk jw...@debian.org wrote: If the team is in the Maintainer field, you are invited to commit and upload stuff yourself. However, in case of big or controversial changes (*cough* #654978 *cough*) it's still a good idea to ask the human maintainer(s) first. Do

pyxdg 0.23

2012-07-30 Thread Thomas Kluyver
The attached diff updates pyxdg with a new upstream version, which includes Python 3 support (bug #591017). I'm not sure of the etiquette for doing this sort of thing. Should I contact the list (like this), directly contact the individual named as the uploader - in this case, Piotr Lewandowski -

Re: RFR: python-secretstorage

2012-06-22 Thread Thomas Kluyver
On 22 June 2012 08:47, Dmitry Shachnev mity...@gmail.com wrote: There is a small test script in the tarball (I plan to add real unit-tests in the next releases), but it requires dbus and gnome-keyring daemons running, so I don't think it's possible to run it at the build time. I recently did

Re: RFR: python-secretstorage

2012-06-22 Thread Thomas Kluyver
On 22 June 2012 12:37, Simon McVittie s...@debian.org wrote: FYI this shouldn't be necessary on Linux if you're either under X or running dbus-daemon manually, but it's still needed on kFreeBSD and probably Hurd, even if you run dbus-daemon manually. The tests failed during an archive rebuild

Re: RFR: cairosvg -- SVG converter based on Cairo

2012-06-08 Thread Thomas Kluyver
On 7 June 2012 17:09, Michael Fladischer mich...@fladi.at wrote: SVG converter based on Cairo This description seems a bit ambiguous - does it convert from or to SVG? What's the format on the other end of the conversion? But perhaps this is obvious to anyone who'd want to install it. Clicking

Re: Future of python2.6 in Debian

2012-06-06 Thread Thomas Kluyver
On 6 June 2012 11:51, Toni Mueller t...@debian.org wrote: Since some time, it's Plone   4.[01] that requires Python 2.6. Only the still-in-beta Plone 4.2   even works with Python 2.7 (but 2.6 is still supported). For my own interest, what does the current version do that prevents it from

Re: RFS: python-notify2

2012-05-28 Thread Thomas Kluyver
On 25 May 2012 15:39, Thomas Kluyver tho...@kluyver.me.uk wrote: Should I try to launch the dbus server for my tests (like I'm already launching the notification daemon), or just disable all the tests which require a running dbus server (which is all of them, at present)? I've disabled

Re: RFS: python-notify2

2012-05-28 Thread Thomas Kluyver
On 28 May 2012 12:05, Thomas Kluyver tho...@kluyver.me.uk wrote: Alternatively, if there's a good way to get dbus running on the buildd, I'd be happy to re-enable the tests. Thanks to Jakub for a patch which should sort it out. I've applied it in svn. Thomas -- To UNSUBSCRIBE, email

Re: RFS: python-notify2

2012-05-25 Thread Thomas Kluyver
On 19 May 2012 19:00, Thomas Kluyver tho...@kluyver.me.uk wrote: So the most important thing for the tests is to check my interpretation of the notifications spec against an established implementation. That's simple enough for local testing (I just see a series of notifications), but doing

Re: RFS: python-notify2

2012-05-19 Thread Thomas Kluyver
On 14 May 2012 23:27, Thomas Kluyver tho...@kluyver.me.uk wrote: - The tests: Running the tests during the build requires dbus and a notification daemon, which in turn requires an X server running. I've come up with a recipe that works in a pbuilder, but is it suitable for the autobuilders

Re: RFS: python-notify2

2012-05-19 Thread Thomas Kluyver
On 19 May 2012 15:20, Piotr Ożarowski pi...@debian.org wrote: if you're not sure and package works with all Python{,3} versions currently supported by Debian, it's OK to skip these fields As far as I know, that's the case. The tests pass with all supported versions. uploaded Thanks, Piotr!

Re: RFS: python-notify2

2012-05-19 Thread Thomas Kluyver
On 19 May 2012 18:19, Barry Warsaw ba...@python.org wrote: Ideally, upstream would mock these for the majority of, if not all the tests. It would be fine if there were non-unittests (i.e. integration tests) that used the real dbus, but these could be disabled for the builds. (Upstream is also

RFS: python-notify2

2012-05-14 Thread Thomas Kluyver
)? Package name: python-notify2 Version : 0.3-1 Upstream Author : Thomas Kluyver tho...@kluyver.me.uk URL : http://pypi.python.org/pypi/notify2 License : BSD Section : python It builds these binary packages: python-notify2 - Desktop notifications API

Re: Double build failures

2012-05-04 Thread Thomas Kluyver
On 4 May 2012 19:06, Dmitrijs Ledkovs x...@debian.org wrote: ok. what is the relationship between 'distribute' 'packaging'? Let's see if I get all these right: distutils: basic packaging functionality, part of the Python standard library setuptools: third party module to add functionality that

Re: please help with a pbuilder error on local debug.

2012-05-04 Thread Thomas Kluyver
On 4 May 2012 23:33, Tim Michelsen timmichel...@gmx-topmail.de wrote: how to solve pbuilder-satisfydepends-dummy dependencies? https://answers.launchpad.net/ubuntu/+source/pbuilder/+question/196073 Looking at which packages it says aren't installable, I would guess that your pbuilder

Re: RFS: python3-dateutil

2012-04-18 Thread Thomas Kluyver
On 18 April 2012 18:03, Jakub Wilk jw...@debian.org wrote: But anyway, I bumped timestamp in the changelog, built, signed and uploaded the package. Thanks. Thanks Jakub, and thanks for taking the time to go through all these things with me. Thomas -- To UNSUBSCRIBE, email to

Re: RFS: python3-dateutil

2012-04-17 Thread Thomas Kluyver
On 16 April 2012 21:30, Jakub Wilk jw...@debian.org wrote: The extended description is supposed to make sense even when it's displayed alone, without the synposis. So it certainly cannot start with “It features:”. Done. I'd misunderstood the format, I thought that it was simply continuation of

Re: RFS: python3-dateutil

2012-04-14 Thread Thomas Kluyver
On 14 April 2012 11:12, Jakub Wilk jw...@debian.org wrote: Could you update the latter item? Yep, done. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:

Re: RFS: python3-dateutil

2012-04-10 Thread Thomas Kluyver
On 5 April 2012 11:38, Jakub Wilk jw...@debian.org wrote: Indeed, adding --check-dirname-level=0 fixes the problem for me. I've added that, and checked that it still works for me. Thanks, Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe.

Re: RFS: python3-dateutil

2012-04-04 Thread Thomas Kluyver
On 4 April 2012 22:14, Jakub Wilk jw...@debian.org wrote: Hmm, didn't help here: No bright ideas. What uscan version do you have? $ uscan --version This is uscan, from the Debian devscripts package, version 2.11.6ubuntu1 I took a closer look at your watch file: I've followed all of your

Re: RFS: python3-dateutil

2012-04-03 Thread Thomas Kluyver
On 2 April 2012 23:23, Jakub Wilk jw...@debian.org wrote: Your get-orig-source target tries to support being invoked from any directory, but this doesn't work: You're right. I've used `pwd` now instead of . and it appears to work. I was following the example here:

Re: RFS: python3-dateutil

2012-04-02 Thread Thomas Kluyver
On 1 April 2012 10:53, Jakub Wilk jw...@debian.org wrote: Wouldn't it be better to update zoneinfo.gettz() tests to use tz.gettz(), instead of disabling them entirely? Please add get-orig-source target. The copyright file mentions dateutil/zoneinfo/zoneinfo-2011d.tar.gz, which doesn't exist

Re: RFS: python3-dateutil

2012-03-28 Thread Thomas Kluyver
On 28 March 2012 21:10, Jakub Wilk jw...@debian.org wrote: I see that you disabled tests for zoneinfo, which I interpret as a yes answer to my question. Well, I can't see how such behaviour is useful[0], but at very least it deserves a big red warning in README.Debian. As far as I can see, the

Re: Numpy dh_python2

2012-03-17 Thread Thomas Kluyver
On 17 March 2012 15:00, Sandro Tosi mo...@debian.org wrote: that stuff is done and the package is uploaded: Thanks for your contribution! Great, thanks for putting in the time to finalise it. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of

Re: Numpy dh_python2

2012-03-16 Thread Thomas Kluyver
On 16 March 2012 13:35, Sandro Tosi mo...@debian.org wrote: Thanks a lot for your work! I just gave it a quick look (i.e. reading the patch) and it seems that would work (at least for the packaging part). It would be also nice if you could post your patch at 601...@bugs.debian.org, so also the

Numpy dh_python2

2012-03-15 Thread Thomas Kluyver
I was looking at packaging numpy for Python 3 (bug #601593, LP #795605). As a step towards this, I was trying to convert it from pysupport to dh_python2, following the 'transition to dh_python2' guide. But I hit a section that I don't really understand, in override_dh_pysupport: # add to public

  1   2   >