Python 3 packaging

[Thomas Kluyver]

Hi,

I've been having a go at repackaging some Python modules where I know the
same codebase can be compiled for Python 3. So far, that's pyzmq and
python-qt4. I've not done any packaging before, so I've no idea if I'm doing
it the best way, but I've worked out something that seems to build the
expected packages: https://launchpad.net/~takluyver/+archive/python3

What's the best way to submit these packaging changes to Debian?

Thanks,
Thomas

Re: Python 3 packaging

[Thomas Kluyver]

Scott:
> I've got python3 packaging for python-qt4 in svn already as a work in
progress. I think you'll find it's more complicated than what you've got,
but maybe I was over thinking it.

I had a feeling that might be the case, but I wanted something that I can
use now, and at least my python3-qt4 binary package seems to work. Good
luck with getting it done properly.

Bernd:
> Join the Debian python modules team and commit your changes to the svn
and ask for review :)

I'll look into it, but I don't really feel qualified yet. Getting even
enough of a handle on packaging to get working binary packages built was a
long hard slog, and I don't feel like I really understand what I was doing.
Also, I'm on an Ubuntu system, and I don't know how much difference that
makes. If needs be, I can run Debian in a VM, or as a pbuilder image.

Thanks,
Thomas

Re: Request for Review - Nuitka the Python compiler

[Thomas Kluyver]

On 15 November 2011 23:49, Kay Hayen  wrote:

> Hm, what about "nuitka-python" as a binary name of what is now Python, is
> that OK? It seems the readable variant.
>

nuitka-python is what I'd call it, from your description. I'm not actually
a Debian packager, though.

Thomas

Re: Packaging pypy

[Thomas Kluyver]

On 30 November 2011 22:22, Kay Hayen  wrote:

> It could turn every "module.py" into a "module.so" with more or less
> dubious benefits.


Note that there are a few differences between compiled and pure Python
modules. E.g.
- Tracebacks to errors won't show code from compiled files.
- Functions assigned to a class attribute get bound to instances (i.e. get
automatically passed self) if they're defined in Python, but compiled
functions do not. I had to fix something recently where a standard library
function had moved from pure-Python to C, and broken code that bound it to
a class.
- I can arbitrarily add extra attributes to instances of Python classes,
but not to instances of compiled classes.

Also, I occasionally go and tweak installed Python files, which is
obviously impractical if they have to be translated and compiled.

I know you're not suggesting we turn this on tomorrow. But I think
replacing pure-python modules with compiled modules should always be a
deliberate choice, not something distributions do automatically.

StringIO already has compiled equivalents, of course - cStringIO, and the
compiled io package in Python 2.7 and 3.x.

Thomas

Re: Packaging pypy

[Thomas Kluyver]

On 30 November 2011 23:50, Kay Hayen  wrote:

> That is only if the ".py" file doesn't exist, right? Why wouldn't it. To
> me, compilation is not about removing the source code. Not at all, it's
> only about acceleration.
>
> Nuitka's "compiled_function" is way more compatible that "PyCFunction" if
> that is your concern.
>

Neat! I'll try to get round to having a look at Nuitka at some point (in
terms of using it, not packaging it - sorry, I can't help there).

Thomas

python-tornado & Python 3

[Thomas Kluyver]

Hello,

Using the recently posted style guide for Python libraries (
http://wiki.debian.org/Python/LibraryStyleGuide), I've updated the
packaging of python-tornado to build a python3-tornado package as well.
This is a test case, and I hope to do the same for other packages once I'm
comfortable with the process. Can someone point me to the best way to
submit the packaging change to Debian, bearing in mind that I'm not really
familiar with the procedures and terminology around Debian?

Thanks,
Thomas Kluyver

Re: python-tornado & Python 3

[Thomas Kluyver]

Thanks, Yaroslav,

On 9 March 2012 14:31, Yaroslav Halchenko  wrote:

> the best way would be  to join Debian Python Modules Team and help
> maintaining this library in Debian by directly committing to team's SVN
> repository and then seeking review/sponsorship.
>

I'll try to follow this route. I've got an alioth account, and applied for
membership of DPMT - do I need to do anything to get the membership
approved, or is it just a question of waiting until someone has time for it?

Best wishes,
Thomas

Re: python-tornado & Python 3

[Thomas Kluyver]

On 12 March 2012 14:49, Yaroslav Halchenko  wrote:

> well -- it might be beneficial meanwhile to share your changes one way
> or another (patch, git, mentors) so someone could review them
>

OK, I've attached the patch (against the debian/ directory) to this e-mail.
The built packages are in my PPA:
https://launchpad.net/~takluyver/+archive/python3

Thanks,
Thomas


python-tornado_2.1.0-2.patch
Description: Binary data

Re: python-tornado & Python 3

[Thomas Kluyver]

On 13 March 2012 21:40, Julian Taylor  wrote:

> thanks for the patch, I have applied it to the team repository along
> with some more minor fixes to other parts of the package.
>
> http://anonscm.debian.org/viewvc/python-modules/packages/python-tornado/trunk/
>

Great, thanks Julian.


> I think its ready for an upload.
>

Is that something I should do? Where does it get uploaded to?

Best wishes,
Thomas

qscintilla2: package Python 3 bindings

[Thomas Kluyver]

Following on from tornado, the attached patch updates the packaging for
qscintilla2 to build Python 3 bindings. It's roughly following the
python-qt4 packaging (which it depends on).

Thanks,
Thomas


qscintilla2-2.6.1-4.patch
Description: Binary data

Re: qscintilla2: package Python 3 bindings

[Thomas Kluyver]

On 14 March 2012 04:13, Scott Kitterman  wrote:

> I did have to make some additional changes, such as using a policy
> compliant
> binary name in python3, as we did for PyQt4 (python3-pyqt4.qsci) and using
> dh_sip3 for the python3 package.  You can see the details in the DPMT SVN
> if
> you want.
>

I've been and looked, and it mostly makes sense to me. A couple of
questions:

Is the policy for binary package names simply to use python3- followed by
the lowercased name that you'd import?

You changed the packaging to build for all supported Python 3 versions,
rather than only the default (although I think only 3.2 is currently
supported, anyway). I'd originally had it like that, but when I looked at
the PyQt4 packaging, it was only targeting the default version (py3versions
-vd), so I followed suit for qscintilla. How do we decide which option to
use?

Thanks,
Thomas

Re: qscintilla2: package Python 3 bindings

[Thomas Kluyver]

On 14 March 2012 16:02, Simon McVittie  wrote:

> That's too late for it to be relevant for Wheezy, tbh. I don't think a
> first beta should be in a Debian stable release, and the release team
> hopes to freeze in June (at which point advancing from beta to final is
> not a thing that should happen).
>

I imagine it can get into Ubuntu's Q cycle, for release in October, though.

Thomas

Numpy & dh_python2

[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 modules list ;\
echo $$installedfile >>
./debian/python-numpy/usr/share/python-support/python-numpy.public ;\

What's the significance of the public modules list? Is there an
equivalent for dh_python2?

Thanks,
Thomas


-- 
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/caovn4qg0bdjn2rumjtf3ajp-_txdyvzmscafarcnfhrfzwz...@mail.gmail.com

Re: Numpy & dh_python2

[Thomas Kluyver]

On 15 March 2012 12:45, Yaroslav Halchenko  wrote:
> So, my blunt guess would be that with dh_python2 you would not need this
> and just would need to place the .a appropriately.

Thanks, I'll give it a shot.

When the comments talk about adding files *back*, is it pysupport that
removes them? How is it determining which files to remove?

Sandro:
> I won't migrate to dh_python2, so it would be a waste of your time.

Why not? I thought python-support was deprecated, and everything was
supposed to move to dh_python2?

So, is it practical to use dh_python3 for python 3 while keeping
python-support for python 2?

Thomas


-- 
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/caovn4qhs5o4d-lh2u8o6w-tovekts8yqvynf72zmixwqcyf...@mail.gmail.com

Re: Numpy & dh_python2

[Thomas Kluyver]

After some trial and error, I've got it building python3-numpy
(leaving python-support in place for Python 2) - a patch is attached.
I've checked that I can install and import the built package.

Changes and suggestions are welcome, and I expect there are better
ways to do bits of it. I'm away for the weekend, so it'll be a few
days before I can work on it again. For now, I've ignored the dh_numpy
and ABI/API versions, but I guess we'll want to make Py3 versions of
them.

Thanks,
Thomas


py3-numpy.patch
Description: Binary data

Re: Numpy & dh_python2

[Thomas Kluyver]

On 16 March 2012 13:35, Sandro Tosi  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 BTS will be notified of the
> available patch.

Great, thanks Sandro, I'll post it to the bug. Let me know if there's
anything else I should be doing with it.

Best wishes,
Thomas


-- 
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/caovn4qgpt7vg32n0po1sag39li9qgl3td+kmgors8pya_yd...@mail.gmail.com

Re: Numpy & dh_python2

[Thomas Kluyver]

On 17 March 2012 15:00, Sandro Tosi  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 "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caovn4qhbq4am5mdmrxh7wt+0zsastmo7ecr30-yghapowda...@mail.gmail.com

IPython Notebook & Python 3

[Thomas Kluyver]

The attached patch takes a shot at packaging the IPython notebook for
Python 3 (this was the impetus behind packaging python3-tornado
recently). I'm not quite sure how the symlinks to jquery files in
ipython3-notebook.links should work - at present, it's a
straightforward copy of the ipython-notebook.links file.

Thanks,
Thomas


ipy-py3-nb.patch
Description: Binary data

Re: IPython Notebook & Python 3

[Thomas Kluyver]

On 20 March 2012 20:58, Julian Taylor  wrote:
> thanks for the effort, but I already did this myself after you patched
> tornado [0].

Excellent, thanks. Are you pursuing getting that change into Debian? I
noticed today that python3-tornado has worked through to Ubuntu
Precise.

> Though I really do want to split out all the static stuff into a -common
> package and reuse that for ipython-notebook and ipython3-notebook.
> Currently it duplicates everything and makes lintian go crazy
> (images-usr-lib etc).
> A patch for that would be great :)

Are we now talking about the JS/CSS etc. for the IPython notebook
itself, rather than the jquery files (which are already symlinked)?
Would the -notebook packages then symlink the relevant files into
their own directory structures?

For anyone else following this, Julian's changes to package
ipython3-notebook are here:
http://bazaar.launchpad.net/~jtaylor/ipython/debian-daily/revision/9

Thanks,
Thomas


-- 
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/CAOvn4qgM0Kz-eF2qvNoYaB=nbuqnwn-geatqyte70dx8_av...@mail.gmail.com

RFS: python3-dateutil

[Thomas Kluyver]

Hi all,

I'd like to request sponsorship of a new package, python3-dateutil,
which is very similar to the existing python-dateutil. Upstream
decided to continue development for Python 3 only, so version numbers
>= 2 are py3, and versions <2 are for py2. This is going to be a
dependency of matplotlib when that's released for Python 3.

Package name: python3-dateutil
Version : 2.0-2
Upstream Author : Gustavo Niemeyer 
URL : http://labix.org/python-dateutil
License : BSD
Section : python

It builds these binary packages:
python3-dateutil - powerful extensions to the standard datetime
module in Python 3

I've uploaded it to Debian mentors:
  http://mentors.debian.net/package/python3-dateutil

Injected it into the DPMT SVN repository:
  http://anonscm.debian.org/viewvc/python-modules/packages/python3-dateutil/

And built binary packages in a PPA that can be installed for testing:
  https://launchpad.net/~takluyver/+archive/python3

The ITP is #665415 - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665415

Thanks for your time,
Thomas


-- 
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/CAOvn4qgzAL3bcu=0qd+8inuzuqwqf7huca70xk50vqkbgsw...@mail.gmail.com

Re: RFS: python3-dateutil

[Thomas Kluyver]

Thanks Jakub and Geoffroy,

(below, Done = changes committed to SVN. I'll reupload to mentors shortly)

On 24 March 2012 10:59, Jakub Wilk  wrote:
> Please merge the two changelog entries.

Done. I thought I should bump the number if I'd published the package
anywhere, evidently I was wrong about that.

> "debhelper (>= 8)" instead of "debhelper (>= 8.0.0)" would be more friendly
> to backporters.

Done. Note this is what the file created by dh_make has (although that
could have been updated in a newer version than I have).

> Please add Vcs-* fields (and remove the commented-out ones, sigh...).

Done.

> s/monday/Monday/ in the package description.

Done.

> Lintian emits:
> P: python3-dateutil source: unversioned-copyright-format-uri
> http://dep.debian.net/deps/dep5

Done. Again, dh_make.

> The stand-alone license paragraph in the copyright file is not properly
> formatted. The same rules as for the long description in debian/control are
> used for this field. Please see Policy §5.6.13 for details.

I've added an extra space before the numbered section so it won't be
word-wrapped. Is there another problem?

> What is the license of zoneinfo-2011d.tar.gz ?

The packaging deletes it, so I'd assumed it doesn't need license
information. Upstream doesn't mention anything specific, and looking
at python-dateutil, there's no license information for it there
either.

> Please honour DEB_BUILD_OPTIONS=nocheck.
> Please run tests for all supported Python 3 versions, not only for the
> default one.

Done.

> The watch file doesn't work:

Done (Copied from python-dateutil)

> test.py adds “build/lib.-” to sys.path, but with Python
> 3.2 build directory for architecture-independent packages is simply
> “build/lib”[0].

Patched, will forward upstream.

> The NEWS file says that “There's no such thing as a "PSF License".”, but
> there
> is still “license = "PSF License"” in setup.py.

Will check with upstream. The LICENSE file is BSD.

> The README file is out of date:
> - The examples use syntax that is no longer valid in Python 3.
> - “python-dateutil-1.0.tar.bz2” and “python-dateutil-1.0-1.noarch.rpm” are
> mentioned in the Download section.

Patched, will forward upstream.

> Has the Use-C-locale-when-calling-date patch been forwarded upstream?

No - it was made in python-dateutil and apparently not forwarded.
Upstream's version is cross-platform (Windows has a date command), so
I guess it's not something the whole package would want.

> dateutil.zoneinfo.gettz() always returns None. Is that how it's supposed to
> work?

I think this is a consequence of our removing the zoneinfo data file.
It should probably be patched to use a system copy, but
python-dateutil seems to live without that functionality.

Geoff:
> You don't install any of upstream documentations. Why?
> You could add a debian/python3-dateutil.docs file containing NEWS and README 
> to
> have these files installed in /usr/share/doc/python3-dateutil.
> Refer to dh_installdocs(1) for further informations.
> Same for example.py that you could ship with the package using
> dh_installexamples if it's relevant for users to have this file (I haven't
> checked myself).

Thanks, I didn't know how to do that. I've added docs and examples to
the package.

Best wishes,
Thomas


--
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/CAOvn4qjJz5EiuAXt=n85bhbh04xn2+t_yvp6h8qki5omtxm...@mail.gmail.com

Re: RFS: python3-dateutil

[Thomas Kluyver]

On 24 March 2012 13:16, Geoffroy Youri Berret  wrote:
> In the worse case (non dfsg licence) you need to repack upstream to have
> a dfsg suffixed package.

I think it's just a tarball of the same data that's in the tzdata
package - in which case, it's public domain. I'll add it as a section
in the copyright file.

Thomas


-- 
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/caovn4qhgnku6tyumrn0qawnbeojjykm+s-rkuvpxbpisgy3...@mail.gmail.com

Re: RFS: python3-dateutil

[Thomas Kluyver]

On 24 March 2012 21:21, Ben Finney  wrote:
> That's what makes the most sense to me. Some DDs don't like it, some
> prefer it, and most will (IME) not mind very much either way.
>
> My advice: Do what you've done, and see what the particular sponsor
> prefers.

Thanks, Ben. I've reverted it to 2.0-1 for now, but it's useful to
hear about these opinions for future work.

Thomas


-- 
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/CAOvn4qj1hQfuQ8GcE+Tvm=PZViHB_vw5OkGWQOx3s+C07=y...@mail.gmail.com

Re: RFS: python3-dateutil

[Thomas Kluyver]

On 24 March 2012 22:41, Jakub Wilk  wrote:
> I don't accept "it's dh_make's fault!" excuses, sorry. :P

I'm not aiming to make excuses - I'm suggesting that dh_make could be
updated to produce the preferred style of output, if that hasn't
already happened. I see Ben's just phrased this better than I can.

> Apart from the fact the license and copyright status of the file is not
> documented in debian/copyright, there's another problem: the tarball appears
> to be a collection of binary blobs, for which we have no source.
>
> I'm afraid that you'll have to either ask upstream to include the actual
> source for zoneinfo or repack the source.

I know Debian is stringent about these things, but is this really
necessary? We're not even using the file, and upstream says where the
files are from (see
http://labix.org/python-dateutil#head-7b64fa6ed6e02b68e9cb7c3d42d6fb7b4cb133e9).
The Python 2 version has already been accepted in Debian with an
equivalent (slightly older) file.

> Now please honour Policy §4.6. :)

Done, in that I've added 'set -e' before the loop.

> BTW, is there a reason you use "set -ex" in override_dh_auto_install but
> only "set -e" in override_dh_auto_build? I'd prefer more consistency. :)

I've standardised them on 'set -e'.

> There is also dateutil.tz.gettz(), which is supposed to use the system
> timezone database, but it doesn't work either:

I'll look into fixing this.

Thanks,
Thomas


--
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/caovn4qgqwbdt0vrt0whnyopvxc-fojqo-l3mynrxtrcr_fd...@mail.gmail.com

Re: RFS: python3-dateutil

[Thomas Kluyver]

On 26 March 2012 21:28, Jakub Wilk  wrote:
>>> Apart from the fact the license and copyright status of the file is not
>>> documented in debian/copyright, there's another problem: the tarball appears
>>> to be a collection of binary blobs, for which we have no source.
>>>
>>> I'm afraid that you'll have to either ask upstream to include the actual
>>> source for zoneinfo or repack the source.
>>
>>
>> I know Debian is stringent about these things, but is this really
>> necessary?
>
>
> I believe so.

Right, I've repackaged the source, and put it on Debian mentors again:
http://mentors.debian.net/package/python3-dateutil

Thanks,
Thomas


-- 
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/caovn4qh_a5cughua50a1gch1dhujffw5ft+82z0a7tfhoef...@mail.gmail.com

Re: RFS: python3-dateutil

[Thomas Kluyver]

On 28 March 2012 21:10, Jakub Wilk  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 zoneinfo subpackage is used as a fallback by
dateutil.tz.gettz() if it can't find the equivalent system timezone
data files (the binary package has a dependency on tzdata).
zoneinfo.gettz() appears to account for the possibility that its local
data file doesn't exist, and returns None. I'm inclined to leave this
behaviour intact in case code depends on it, although it's not how I'd
design it myself. I've added a note in README.Debian pointing people
to dateutil.tz.gettz().

Thomas


-- 
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/CAOvn4qie-yBr-novh71RXNY-_Qd=W3dz24nw2u2+nML+B_4O=g...@mail.gmail.com

Re: RFS: python3-dateutil

[Thomas Kluyver]

On 1 April 2012 10:53, Jakub Wilk  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 in .orig.tar anymore.

All done.

I seem to have locked the package out of mentors.debian.net; I'll try
uploading it again tomorrow.

Thomas


-- 
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/caovn4qiaxbcclkw832h9-rgb92h2te0tr_vd6sngxnnr2d4...@mail.gmail.com

Re: RFS: python3-dateutil

[Thomas Kluyver]

On 2 April 2012 23:23, Jakub Wilk  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:
https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball

> Please merge changelog entries for 2.0+dfsg1-1 and 2.0-1.

Done.

Thomas


-- 
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/caovn4qhgem+yzrpgwbym2sneccbdcobdpilv4racmm9qu4x...@mail.gmail.com

Re: RFS: python3-dateutil

[Thomas Kluyver]

On 4 April 2012 22:14, Jakub Wilk  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 suggestions, and checked that it still
works. Previously, I'd just copied the watch file from
python-dateutil; evidently it wasn't as good an example as I had
hoped.

Thanks,
Thomas


-- 
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/caovn4qiv6bw0syaqcgkfwi4e5zd4ajos3x+wcrblhocksyr...@mail.gmail.com

Re: RFS: python3-dateutil

[Thomas Kluyver]

On 5 April 2012 11:38, Jakub Wilk  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". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOvn4qiGDkeeNvH_n_z3hm61iC4nvV06smxEaR9Z6U=srcq...@mail.gmail.com

Re: RFS: python3-dateutil

[Thomas Kluyver]

On 14 April 2012 11:12, Jakub Wilk  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: 
http://lists.debian.org/caovn4qi4hvyeg2dqa9qer10nxay9ennotf254rtwjhp52dm...@mail.gmail.com

Re: RFS: python3-dateutil

[Thomas Kluyver]

On 16 April 2012 21:30, Jakub Wilk  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 the field on the line "Description: ".

Thomas


--
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/caovn4qjbsri7252nxhymqk_ehdsny9bsdgcaavr7scmzzkg...@mail.gmail.com

Re: RFS: python3-dateutil

[Thomas Kluyver]

On 18 April 2012 18:03, Jakub Wilk  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 debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caovn4qhxk6ngw-dp+djxwcwysuxcxzycqkanmwdynt73jon...@mail.gmail.com

Re: Double build failures

[Thomas Kluyver]

On 4 May 2012 19:06, Dmitrijs Ledkovs  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 distutils lacked
distribute: continuation of setuptools after setuptools development stopped
packaging, aka distutils2: Improving on distutils but not backwards
compatible, will be integrated into the standard library for Python
3.3, and might then make setuptools/distribute obsolete.

Please correct me if I've got any of that wrong.

Thomas


-- 
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/CAOvn4qiG6-kqWUh2vsHV03=6hoY9=sqy8ryo-rh2+xrvo3e...@mail.gmail.com

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

[Thomas Kluyver]

On 4 May 2012 23:33, Tim Michelsen  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 environment isn't set up to get packages from
universe. For my pbuilder, I copied the .pbuilderrc file from here:

https://wiki.ubuntu.com/PbuilderHowto#Multiple_pbuilders

Note this line for Ubuntu (there's an equivalent for Debian):
COMPONENTS="main restricted universe multiverse"

After you've changed the repositories a pbuilder environment sees, I
think you need to run with --override-config for it to pick up the
change. Or if you're unsure, you can just delete the environment
tarball and create a new one.

Thomas


-- 
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/caovn4qic9zj9wri5nfksv4ocnlrvfe6ts6y_pf3dcdcby7b...@mail.gmail.com

RFS: python-notify2

[Thomas Kluyver]

Hi all,

I'd like to request sponsorship of a new package, python-notify2.

This is intended as a replacement for pynotify (aka notify-python,
python-notify), so it broadly copies the API from that package,
although it's not a drop in replacement. Why is a replacement needed?

- notify2 is compatible with Gtk 3 and Qt 4. pynotify can't even be
imported in the same process as the gobject introspection bindings for
Gtk 3, and its callbacks depend on the Gtk 2 event loop.
- notify2 is compatible with Python 3; pynotify probably can't easily
be made to support Python 3.
- notify2 has useful docstrings and function signatures for introspection
- Getting things wrong with pynotify can easily segfault your process.
notify2 should just raise a Python exception.
- notify2 is written in Python, not C, so it's shorter, more readable,
and easier to maintain.

A few points I'd like to ask about:

- 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, and is there a better way to do it?
- Examples: There are a handful of examples. At present, these end up
in both of the binary packages, under
/usr/share/doc//examples/ . I tried to put them in a
separate python-notify2-docs package, but then the folder was in
/usr/share/doc/python-notify2-docs, which doesn't seem right. Can I
easily make a -docs package but keep the folder name python-notify2?
- X-Python[3]-Version: I don't know what the minimum Python version
required is. It doesn't use any new language features. Should I leave
these fields out, copy them from dbus-python (the key dependency), or
put the minimum I'd consider fixing things for (2.6/3.1)?


Package name: python-notify2
Version : 0.3-1
Upstream Author : Thomas Kluyver 
URL : http://pypi.python.org/pypi/notify2
License : BSD
Section : python

It builds these binary packages:
  python-notify2 - Desktop notifications API for Python
  python3-notify2 - Desktop notifications API for Python 3

In the DPMT SVN repository:
 http://anonscm.debian.org/viewvc/python-modules/packages/python-notify2/

On Debian mentors:
 http://mentors.debian.net/package/python-notify2

The ITP is #672799 - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672799

Thanks for your time,
Thomas


-- 
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/CAOvn4qhSvvgHiWLVf2toCx8Q_Lh1nbq=-JD=_kr4ew3vkn4...@mail.gmail.com

Re: RFS: python-notify2

[Thomas Kluyver]

On 14 May 2012 23:27, Thomas Kluyver  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, and is there a better way to do it?

I've worked out how to use xvfb-run, which makes running the tests
quite a bit simpler.

I've updated the package in SVN and re-uploaded to mentors. I'm still
keen for someone to review or sponsor it.

Thanks,
Thomas


-- 
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/CAOvn4qjRrdOT96m0HSouGM+=hbx3nv2hoejut4zfvp0ra0r...@mail.gmail.com

Re: RFS: python-notify2

[Thomas Kluyver]

On 19 May 2012 15:20, Piotr Ożarowski  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!

Thomas


--
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/CAOvn4qgooW7ac9DB+CMNCRJBdenUmD=kzhau6jkzal6vibe...@mail.gmail.com

Re: RFS: python-notify2

[Thomas Kluyver]

On 19 May 2012 18:19, Barry Warsaw  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 me, in this case)

Mocking would be valuable for testing the callback infrastructure, but
apart from that, it's just a wrapper around making dbus calls. 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 it on a headless server was more tricky. In
any case, it works now, even if it means 300 lines of code has 50MB of
build-dependencies. ;-)

Thanks,
Thomas


-- 
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/caovn4qhu6_ouwytajgkrifd1esr6bqsmxfbfvehjo9vpzeu...@mail.gmail.com

Re: RFS: python-notify2

[Thomas Kluyver]

On 19 May 2012 19:00, Thomas Kluyver  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 it on a headless server was more tricky. In
> any case, it works now, even if it means 300 lines of code has 50MB of
> build-dependencies. ;-)

Except it didn't work: I've just noticed that I've got a FTBFS bug, as
it couldn't connect to the dbus server. It looks like this is the
critical part:

Setting up dbus (1.5.12-1) ...
All runlevel operations denied by policy
invoke-rc.d: policy-rc.d denied execution of start.

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)?

Thanks,
Thomas


-- 
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/caovn4qjhfhgmeco1zax+vaueeegqx5gtmjs5lq4mnusxq2j...@mail.gmail.com

Re: RFS: python-notify2

[Thomas Kluyver]

On 25 May 2012 15:39, Thomas Kluyver  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 the test suite with an explanatory note in debian/rules.
Could I ask someone to sponsor 0.3-2 (from SVN)? Alternatively, if
there's a good way to get dbus running on the buildd, I'd be happy to
re-enable the tests. I can't reproduce the failure with pbuilder or a
PPA.

Thanks,
Thomas


-- 
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/CAOvn4qgWQ=GC=rssbYtzrR8hTvTDS2yXEfDVCVJr=ltqrvi...@mail.gmail.com

Re: RFS: python-notify2

[Thomas Kluyver]

On 28 May 2012 12:05, Thomas Kluyver  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 to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caovn4qgkufo-prjmfef6sfhj4k_xe2s38vqodepzk4njnhy...@mail.gmail.com

Re: Future of python2.6 in Debian

[Thomas Kluyver]

On 6 June 2012 11:51, Toni Mueller  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 working on 2.7? I thought just about anything written for 2.6
should run on 2.7.

Thomas


--
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/caovn4qhne_waq82k_ut6oncdv+u-bvfu2pukz-wfzbzg6bu...@mail.gmail.com

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

[Thomas Kluyver]

On 7 June 2012 17:09, Michael Fladischer  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 through
to the website, I see it's from SVG to pdf/ps/png.

Best wishes,
Thomas


-- 
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/caovn4qhz4xacjdsiu6czsams91faggd5e69rt8x18bx90ez...@mail.gmail.com

Re: RFR: python-secretstorage

[Thomas Kluyver]

On 22 June 2012 08:47, Dmitry Shachnev  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 a wrapper for the dbus desktop notifications API, which
is tested with dbus and notification-daemon running. It was suggested
that it wasn't necessary to run those tests, but after a bit of
fiddling we got it working. You're welcome to crib from that:

http://anonscm.debian.org/viewvc/python-modules/packages/python-notify2/trunk/debian/

Best wishes,
Thomas


-- 
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/caovn4qjfzcp1cnyzag5he9v36vdbnkuatfszmsqhcsyt4nf...@mail.gmail.com

Re: RFR: python-secretstorage

[Thomas Kluyver]

On 22 June 2012 12:37, Simon McVittie  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 - that line was apparently
to fix the issue:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674351

>> PYTHONS="$(PYTHON2) $(PYTHON3)" xvfb-run -a debian/runtests.sh
>
> You don't need X for D-Bus if you run a dbus-daemon yourself.
> tools/with-session-bus.sh in src:telepathy-glib and other Telepathy
> packages is a relatively simple way to achieve that: run it like this:

Thanks, that's good to know. Good luck getting it in as a general
tool. In my case, I think notification-daemon itself requires an X
server.

Best wishes,
Thomas


-- 
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/caovn4qj3xxpsfeiwayacb4vknkckkqkc2guol69+dmk50yb...@mail.gmail.com

pyxdg 0.23

[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 - or commit the changes
to the team SVN repository and then ask for review?

Thanks,
Thomas


pyxdg_0.23-1.diff
Description: Binary data

Re: pyxdg 0.23

[Thomas Kluyver]

On 31 July 2012 08:02, Jakub Wilk  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 these changes count as big? By the standards of packaging, it's a
fairly substantial set of changes, including adding a new binary
package. But it's not changing much that should affect users, just
packaging a new upstream release.

>> +   rm -rf *.egg-info
>
> This looks like a no-op to me.

Thanks, I'll remove that line. Are there other cases where it is
needed? I got it from http://wiki.debian.org/Python/LibraryStyleGuide

Best wishes,
Thomas


-- 
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/caovn4qigrckmdlcbgwjg6bdxua_byn_yyp4a6umecfh4sfz...@mail.gmail.com

Re: pyxdg 0.23

[Thomas Kluyver]

Thanks Barry,

On 1 August 2012 19:51, Barry Warsaw  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, along with Jakub's suggestion, and
committed to the team SVN repository.

> - I had to update gettext-support.patch (but maybe that's an Ubuntu-ism)

That patch doesn't seem to be in Debian.

> - I also updated d/watch, but I think I used your p.f.o/~takluyver url.  I'm
>   glad you changed it to use the PyPI url instead.

Yep - hopefully if the maintainership changes again, releases will
still be uploaded to PyPI in the same way.

Best wishes,
Thomas


-- 
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/CAOvn4qi6q_nKgN8A2KT=3fzxxav0k8nzobx4kqkdbykytet...@mail.gmail.com

RFS: pyxdg 0.23-1

[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 ; Heinrich
Wendel ; Thomas Kluyver 
URL : http://freedesktop.org/wiki/Software/pyxdg
License : LGPL-2
Section : python

Changelog:
pyxdg (0.23-1) unstable; urgency=low

  * New upstream version
+ Python 3 support (closes: #591017)
+ Test suite
  * Convert packaging to use dh_python2 (closes: #637154)

It builds these binary packages:
  python-xdg - Python 2 library to access freedesktop.org standards
  python3-xdg - Python 3 library to access freedesktop.org standards

In the DPMT SVN repository:
 http://anonscm.debian.org/viewvc/python-modules/packages/pyxdg/

On Debian mentors:
 http://mentors.debian.net/package/pyxdg

Thanks,
Thomas


-- 
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/caovn4qisy+zeasrwb0adaxo1rdxmdnueccsu09x5xlro60g...@mail.gmail.com

Re: Please add me to the team

[Thomas Kluyver]

On 10 August 2012 11:33, Jakub Wilk  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 sure, it's polite to ask.

Best wishes,
Thomas


-- 
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/caovn4qjtt_fvjp3jcrm+4bfx0qg2-vo4bb_3tpzryscxjqj...@mail.gmail.com

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

[Thomas Kluyver]

Hi Nigel,

On 3 September 2012 14:57, Nigel Sedgwick  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. wx and
matplotlib haven't yet released Python 3 compatible versions, and
Wheezy is frozen now, so they've missed that boat. If you need to use
those packages for a substantial application in the near future,
sticking with Python 2 for now is your safest bet. If you use Python
2.6 or 2.7 with modern idioms, it should be relatively easy to port
code later when all the libraries are ready.

As far as I understand Debian, none of those python3- packages will be
added to Squeeze. The idea of a stable release is that the only
updates it gets are bugfixes and security.

Looking further ahead: matplotlib is aiming to release a Python 3
version in October. wxPython has a development version working on
Python 3, but I don't see any indication of how soon a release is
planned. Other GUI toolkits (Qt, GTK) already support Python 3, if
they are an option for you.

Best wishes,
Thomas


-- 
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/caovn4qipxjjqxswn1dwc3rcnzhc15icn8e5dyxwa18yurzo...@mail.gmail.com

Re: Xpra to publicly expose its modules

[Thomas Kluyver]

On 18 September 2012 18:00, Dmitry Smirnov  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


-- 
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/CAOvn4qgoh_wUN_jSG8teDoFXe3ykxFdpjTv6mh2BoyrGau_=m...@mail.gmail.com

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

[Thomas Kluyver]

With apologies in advance for straying off topic ;-)

On 21 September 2012 14:18, Yaroslav Halchenko  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 discussion on scipy-user at the moment about
formalising a scientific Python stack under the name Pylab. I hope
once it's defined, we'll be able to make a Debian metapackage that
depends on all the relevant components. If you want to get involved in
defining it, please do join the discussion on scipy-user.

> 2. tutorial on "Debian packaging of Python modules/software"

That reminds me: I'm doing a talk (~ 1/2 hour) at my local Python user
group on this topic, so I'd be interested to see any tutorials anyone
has already prepared. I'm not sure I'm really qualified to expound on
it, but I hope that I can give people some kind of mental map of
what's involved.

Thanks,
Thomas


-- 
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/caovn4qigcsn3wpw7qrgbnhsyczkftue9o2-ggwvak57syda...@mail.gmail.com

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

[Thomas Kluyver]

On 21 September 2012 19:32, Paul Boddie  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 half-decent package. It might also be informative if Natalia
> Frydrych's PyPI to Debian work were covered somehow, because that would
> potentially make people aware of "packaging portability" and that with only a
> little extra consideration, they could have their work conveniently available
> to an entire community.

Thanks all, good points.

Fred:
> in that case you should have a look to the pythonxy project

Yes, that's one of several distributions we're discussing - others
include EPD, Anaconda, WinPython and QSnake.

Best wishes,
Thomas


-- 
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/caovn4qgdjz3csn3bchnyy8d57cyyblzwkpbjlaqs0gpcgov...@mail.gmail.com

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

[Thomas Kluyver]

On 2 October 2012 09:01, Nicolas Chauvat  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 not installed in the virtualenv ?

I'd be interested to see something like this, or something that would
allow installing Debian packages for a single user. Is something
possible with UnionFS/OverlayFS?

Thomas


-- 
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/CAOvn4qgPKgcgwEA+5a_o27ch4go4-sKLpqG9nFv7KzhO=du...@mail.gmail.com

Sympy 0.7.2

[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 Code and PyPI
have separate py2/py3 tarballs, and they don't include the conversion
script. So I've used the tarball from the github tag as the source. I
also had to patch the conversion script, which assumes it's working
inside a git repository. I've raised an issue upstream about this.

I'm still not sure of the protocol, so I thought I'd bring it up here
first. Let me know if I should commit the changes to the DPMT SVN.

Thanks,
Thomas


sympy-0.7.2-and-py3.patch
Description: Binary data

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

[Thomas Kluyver]

On 26 October 2012 09:19, Floris Bruynooghe  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 line would cause trouble that warrants not doing
> this by default?

Are there any situations where you might want to run a system script
with modified Python environment variables? I can't think of any off
the top of my head. Here's the list of environment variables:

http://docs.python.org/using/cmdline.html#environment-variables

Thomas


-- 
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/CAOvn4qjiW6VicuZnT-CdQnESXkVMc0kO4pVGCV_3vLwx=nd...@mail.gmail.com

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

[Thomas Kluyver]

On 26 October 2012 11:53, Chow Loong Jin  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 think there's a robust distinction on Linux, but there's
loosely a difference between system components and user applications.

Thomas


-- 
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/CAOvn4qjjutDhApA1YVBGWY61z9NoLp=r8ctkhggw-jwdnwf...@mail.gmail.com

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

[Thomas Kluyver]

On 26 October 2012 14:20, Paul Tagliamonte  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 unattended-upgrades script, which you wouldn't
really want to be affected by virtualenvs.

Thomas


-- 
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/caovn4qimsiet2_lwts2p1c37mjabgmi5tsxsy3ptzqgc-vy...@mail.gmail.com

Re: Sympy 0.7.2

[Thomas Kluyver]

On Oct 25, 2012 6:31 PM, "Thomas Kluyver"  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

[Thomas Kluyver]

On 28 October 2012 08:47, Jakub Wilk  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 (diff attached) to update the Python 2
package to 0.7.2. I tried to add a -docs package with the Sphinx docs, but
it complained about Mathjax, so I've left it for now. If that sounds OK,
could someone upload it?

Also attached is the new packaging for the Python 3 version. This now calls
the script isympy3. Is it OK to svn-inject this? And is python3-sympy the
right name to use for the SVN directory?

Thanks,
Thomas


sympy-0.7.2.patch
Description: Binary data


python3-sympy-debianpackaging.tar.gz
Description: GNU Zip compressed data

Re: Sympy 0.7.2

[Thomas Kluyver]

On 29 October 2012 04:42, Dmitry Shachnev  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
missing

Thanks,
Thomas

RFS: pyxdg 0.24-1

[Thomas Kluyver]

Hello,

I'd like to request a sponsor to upload a new version of pyxdg. This is
essentially the same as an earlier RFS for 0.23-1, but with a new upstream
version.

Package name: pyxdg
Version : 0.24-1
Upstream Author : Sergey Kuleshov ; Heinrich
Wendel ; Thomas Kluyver 
URL : http://freedesktop.org/wiki/Software/pyxdg
License : LGPL-2
Section : python

Changelog:
pyxdg (0.24-1) unstable; urgency=low

  * New upstream version
+ Python 3 support (closes: #591017)
+ Test suite
  * Convert packaging to use dh_python2 (closes: #637154)

It builds these binary packages:
  python-xdg - Python 2 library to access freedesktop.org standards
  python3-xdg - Python 3 library to access freedesktop.org standards

In the DPMT SVN repository:
 http://anonscm.debian.org/viewvc/python-modules/packages/pyxdg/

Thanks,
Thomas

Re: RFS: pyxdg 0.24-1

[Thomas Kluyver]

(Resending to the list - sorry)

On 6 November 2012 12:36, Thomas Kluyver  wrote:

> On 6 November 2012 12:03, Dmitrijs Ledkovs  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? If it looks
> OK, I'll commit it.
>
> Thanks,
> Thomas
>

Re: RFS: pyxdg 0.24-1

[Thomas Kluyver]

On 6 November 2012 12:54, Dmitrijs Ledkovs  wrote:

> Looks good. Commit and I will sponsor your package.
>

Done. Thanks, Dmitrijs.

Thomas

Re: RFS: pyxdg 0.24-1

[Thomas Kluyver]

On 6 November 2012 13:18, Dmitrijs Ledkovs  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 these changes are not appropriate for wheezy
> at this time.
> Is that ok with you? Or did you intend to upload into unstable?
>

That's fine by me. I see myself primarily as the upstream here, offering
the package to Debian to use as you will.

In that case, I'll submit it separately to Ubuntu, as it won't be synced
from experimental. Thanks for letting me know.

Best wishes,
Thomas

Re: Advise on packaging a new Python module

[Thomas Kluyver]

On 8 November 2012 14:15, Andreas Tille  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 writing would be needed.  Any more detailed advise?


Some manual code writing is needed, as debhelper doesn't yet know how to
automatically build packages with Python 3.

The best description is this wiki page:
http://wiki.debian.org/Python/LibraryStyleGuide

Thomas

GUI tool for packaging

[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 not everything can be automated, and the tools end up with lots of
options to learn about.

The upshot is that most open source developers rely on a relatively small
number of specialist packagers to do the rather esoteric work of preparing
Debian packages. To get this to scale, I think we need to encourage more
upstreams to provide packaging - whether it's for inclusion in Debian, or
to provide .deb packages themselves, like Google Chrome, MongoDB and
Dropbox do.

In my opinion, the best way to do that is to build a GUI that holds the
user's hand through the process of packaging, showing them the options
available. It should be particularly useful for occasional packagers who
don't want to remember a load of commands and options.

Ultimately, I envisage a kind of packaging IDE. But the bit I picked to
implement first is a wizard to create a watch file. The user can select
popular sites like Github or PyPI, enter a couple of details, and a
(hopefully correct) watchfile is generated.
Screenshot: http://i.imgur.com/YM2LT.png
Code: https://bitbucket.org/takluyver/packagebench/src

I imagine wizards like this could be a large part of this tool, for tasks
like "Add a documentation package" or "Make DEP-8 tests".

So, I'd like to know:
- Do you think this is worth spending time on? Bear in mind it's primarily
aimed at new & occasional packagers, not experts who already know the tools.
- Is there already anything like this?
- Would you be interested in helping to develop it?

Of course, this should be useful for any packages, not just Python-based
ones. But I thought I'd float the idea here first, to get some feedback
before I take it any further.

Thanks,
Thomas

Re: pyxs review

[Thomas Kluyver]

On 9 November 2012 12:44, Maykel Moya  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 it, but I'd consider it good
etiquette, if you're adding something to a much larger work, to follow the
author's lead on licensing.

For instance: say you patch the code to fix a bug you notice while you're
packaging. You don't forward the patch at the time, but the upstream author
later sees it and wants to include it. If debian/ is under the same
license, he's free to use your code and credit you. If debian/ is more
restricted, he has to try to contact you to get an appropriate license.

Thanks,
Thomas

Re: Sympy 0.7.2

[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 Wilk  wrote:

> * Dmitry Shachnev , 2012-10-29, 14:47:
>
>> 2. dh_sphinxdoc should handle URLs starting with a protocol name
>> correctly (so that it won't complain about .../html/file:///usr/share/**
>> javascript/mathjax/MathJax.js?**config=TeX-AMS_HTML-full missing)
>>
>
> This is now fixed in svn.
>
>
>  3. It would be also good if dh_sphinxdoc stripped everything after ?
>> character.
>>
>
> Ditto.
>
> --
> Jakub Wilk
>
>
>
> --
> To UNSUBSCRIBE, email to 
> debian-python-REQUEST@lists.**debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: 
> http://lists.debian.org/**20121108133234.GA1777@jwilk.**net
>
>

Re: Python fdb

[Thomas Kluyver]

(Resending to the list)
Hi Philippe,


On 13 November 2012 12:36, Philippe Makowski  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 packaging. It
probably won't be ready for you to use, but I'd be interested to hear what
bumps you hit as someone new to the process.

Good luck!

Thomas

Re: GUI tool for packaging

[Thomas Kluyver]

On 14 November 2012 11:43, Jakub Wilk  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: GUI tool for packaging

[Thomas Kluyver]

Hi Clint,

On 15 November 2012 03:53, Clint Byrum  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 large project like a GUI.


I have been keeping an eye on pkgme, but I'm not sure it solves the
problem. My concern with automated tools is that they tend to to work for
about 75% of stuff, but there's always a substantial proportion of things
that just do something a little bit odd, and the automatic tool can't
handle them. So I have to understand what the automation is doing, to deal
with the things it can't do for me.

To give more concrete examples, we have stdeb for Python packages, and
debhelper, which can guess much of the standard process of building a
package (such as running 'make' or 'setup.py'). But neither can handle
enough real-world cases that new packagers can use it without thinking
about what's happening.

I tried writing an application with Quickly a couple of months ago, and I
was impressed with how well 'quickly package' (which uses pkgme) worked.
But a lot of things that I'd like to see packaged aren't developed with
Quickly, and I'm not confident that pkgme can do such a good job with them.

Thanks,
Thomas

Re: GUI tool for packaging

[Thomas Kluyver]

On 15 November 2012 15:18, Andrey Rahmatullin  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
> needed.
>

I absolutely agree, but as I see it, I'm not trying to automate the
process. I'm trying to make it easier for the user to manually intervene in
the packaging. The wizards are just one part of that.

Packaging at the moment involves an array of different data files,
specialist syntax, and command line tools. There's a lot of detail which is
hard to learn and remember. For example:
- uscan puts upstream tarballs into ../, but svn-buildpackage expects them
in ../tarballs/
- dh_make is something for the user to run, whereas dh_install is something
to be run automatically by the build system.
- When you make a new patch, you have to 'quilt add' any files you want to
modify before you can modify them. It's easy, and annoying, to forget that.
(I know about 'quilt edit', but for other reasons my $EDITOR is set to an
in-terminal editor, which isn't what I prefer for modifying large code
files)
- To work on patches, you have the debian/ directory in amongst the
upstream codebase. But having the rest of the codebase there clutters up
information from the version control system. So I often end up with two
copies of the packaging, and copying debian/patches/ between them.
- You call pbuilder with a .dsc file, but dput with a .changes file.
- In the .install list, a line with a single entry works quite
differently from a line with two entries

To be clear, I'm not asking for solutions or workarounds to these
individual issues. I'm sure there are good reasons things work the way they
do - but being relatively new to this, the array of not-quite-connected
tools is daunting.

I think the advantage of a GUI is that it presents your options, rather
than requiring you to already know them. If you realise you need to change
some of upstream's code to make the package work... hey, that pane says
'patches', that sounds like the thing. If there are some examples, you can
see the binary package target has an entry called 'examples'.

Specifically, some of the things I have in mind:
- Integration with quilt for patches. If you try to edit a source file from
the GUI, you're prompted to create a patch.
- A joined-up view of the intended binary packages. At present, the details
of a binary package are spread out over part of the control file, and the
foo.install, .docs, .examples, etc. files.
- Editing copyright info without having to get the file syntax just right,
look up license short names, and so on. Just enter a glob and select the
license from a dropdown.
- Wizards for specific things like watch files or DEP-8 tests. The key to
this is that GUI wizards have a much lower barrier of entry than new
command line tools - no flags to remember.
- A build menu where you can select source package, local build, pbuilder
or PPA, and it will take care of any preparation needed for that.

Whew, that's more than I meant to write. Thanks to anyone who's read this
far - I hope I've managed to give a clearer picture of what my idea
involves.

Thanks,
Thomas

Re: Private modules

[Thomas Kluyver]

On 22 December 2012 22:00, Bas Wijnen  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 with it:

http://wiki.debian.org/Python/Packaging#Example_2:_Python_application
http://permalink.gmane.org/gmane.linux.debian.devel.python/6728

Thomas

python-xlrd

[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 version, and adding a python3- package. Does
anyone object to me committing this to the DPMT SVN repository, and seeking
sponsorship for the new version?

[1]
http://lists.alioth.debian.org/pipermail/python-apps-team/2012-April/006028.html

Thanks,
Thomas

Re: python-xlrd

[Thomas Kluyver]

On 6 February 2013 12:52, Sandro Tosi  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 your email)? have you done that in a public
> tracable way (pinging a bug, f.e.)? did you give him enough time to
> reply?
>

I've just done some digging. I see no activity from Thomas B since 2009.
Lintian is complaining about his packages [1], apart from two where people
have managed non-maintainer/team uploads. Tomorrow, it will be two years
since a bug was filed requesting a new version of python-xlrd [2]. I can't
find him on the TU Berlin site, so it's likely that the e-mail address
we're trying for him has expired. No new e-mail address is apparent.

No doubt he should have declared his packages orphaned before he left. But
whether he got hit by a bus, or just lost interest in them, I'm not
interested in blaming him. I have e-mailed the MIA team to start the
2-month process [3] that will probably end with his packages being
orphaned. Of course, it's good to exercise due diligence, but the flip side
is that technical changes which I hope would be uncontroversial have now
taken a back seat to bureaucracy, because one man a few years ago declared
himself 'the maintainer'.

It feels like a big enterprise which should have a pretty good bus factor
has been artificially split into many small projects, each with a terrible
bus factor. There are plenty of people who understand the packaging for
something simple like this, and hundreds [4] of Debian developers that we
trust to upload packages. But changing a package hinges on an individual
maintainer, who could be busy, on holiday, uninterested, or deceased.

I suggest that we encourage packagers to make team maintainership the norm,
and individual maintainership the exception, to avoid this kind of problem.
This is in line with plenty of other open source projects, where people
talk about not becoming a bottleneck or a single point of failure.

[1]
http://lintian.debian.org/maintainer/thoma...@pool.math.tu-berlin.de.html
[2] https://bugs.launchpad.net/debian/+source/python-xlrd/+bug/714632
[3] http://wiki.debian.org/qa.debian.org/MIATeam
[4] http://www.debian.org/devel/people

Best wishes,
Thomas

Re: python-xlrd

[Thomas Kluyver]

On 6 February 2013 19:30, Sandro Tosi  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 situations where the package is so complex that
a check from a knowledgeable person is welcome before an upload but they
are very rare."

This is pretty much what I mean, but I think we should strengthen it a bit
from what I think the current case is. Namely, if someone does an RFS for a
package with themselves set as the Maintainer, the reviewer should
encourage them to put the team there instead. Maybe reviewers are already
doing that, although I don't remember seeing it.

Simon:
> If the request for a new version has been open for 2 years, waiting
another couple of months to confirm that the maintainer doesn't object
isn't really going to make much difference - particularly if that's 2
months of release-freeze time.

It's two months in which someone has to e-mail Thomas B several times, and
in which what I've done will fall out of my memory. Maybe I'll forget about
it by April, and someone will end up redoing the work. Maybe my laptop will
kick the bucket in the meantime, and the changes that I couldn't commit to
the centralised VCS will be lost. (Although in this case, they're in my PPA
[1])

It's two months of release freeze time for Debian, but my understanding is
that submitting to Debian experimental remains the preferred way to get new
versions into Ubuntu. Ubuntu is not currently frozen, but in two months
time it will be, so it will miss these changes for another 6 months.

Finally, it's two months as a minimum. Elena contacted the MIA team at
least seven months ago, but Thomas B's packages have not been orphaned.
That suggests that either they didn't follow up, or that he made contact
but hasn't resumed any maintenance. I haven't seen any way to check on
that, or to know the fate of my message to the MIA team.

Thomas

[1] https://launchpad.net/~takluyver/+archive/python3

Re: How does team maintenace of python module works?

[Thomas Kluyver]

On 14 February 2013 12:12, Thomas Goirand  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 support for allowing
team-maintained modules to live in git.

Please don't be put off by the somewhat hostile atmosphere that seems to be
an unfortunate feature of this list. There seem to be historical tensions
between some of the senior members.


Thomas

Re: How does team maintenace of python module works?

[Thomas Kluyver]

On 14 February 2013 16:41, Sandro Tosi  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 arguing strongly against the switch,
although there were a few caveats, like having a sane migration path:

http://thread.gmane.org/gmane.linux.debian.devel.python/6540/

It looks more like the idea stalled than was rejected. If that is the case,
it shouldn't be a problem to discuss it again.

Thomas

Re: How does team maintenace of python module works?

[Thomas Kluyver]

On 14 February 2013 20:29, Barry Warsaw  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 deprecated helpers still seem to meet considerable
resistance. 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.

Back on the VCS question, I fear that the 'all or nothing' road will circle
back to 'nothing' for a long time. I think that we should allow some
packages to live in git without forcing a complete migration, so individual
maintainers can use the VCS they're more comfortable with. Most open source
programmers have at least a basic familiarity with both, so it shouldn't be
such an obstacle to working on other packages.

We wouldn't be the only team doing this - Debian Games Team, for example,
use both git and svn for packaging:
http://wiki.debian.org/Games/VCS

Thomas

Re: How does team maintenace of python module works?

[Thomas Kluyver]

On 14 February 2013 22:54, Matthias Klose  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?
>

I'm not sure what you're suggesting I do. I consider myself to be a
newcomer in more or less the situation I described. I've got better things
to do than learn the workings of python-support, but switching a package to
dh_python2 is apparently a major change, which only named maintainers can
approve. And if the maintainers aren't interested, the old helper can
remain indefinitely.

Also, between this sort of thing, and the tense atmosphere I sometimes feel
this list has, I'm not especially motivated to contribute here. The
effort/satisfaction ratio isn't as good as many other projects I can spend
time on.


>  > Back on the VCS question, I fear that the 'all or nothing' road will
> circle
> > back to 'nothing' for a long time. I think that we should allow some
> > packages to live in git without forcing a complete migration, so
> individual
> > maintainers can use the VCS they're more comfortable with. Most open
> source
> > programmers have at least a basic familiarity with both, so it shouldn't
> be
> > such an obstacle to working on other packages.
> >
> > We wouldn't be the only team doing this - Debian Games Team, for example,
> > use both git and svn for packaging:
> > http://wiki.debian.org/Games/VCS
>
> Now you did point out one discrepancy, which hinders newcomers, and you do
> want
> to introduce another one?


The distinction I was trying to make is that open source developers often
already know the basics of multiple VCSs, because they've contribute to
different projects. By contrast, the different packaging helpers are
entirely specific to packaging Python modules within Debian, so newcomers
have to learn them for this specific task. So there's less penalty to
having multiple VCSs coexisting.

But I don't feel strongly about this point - it looks like we want to
maintain a single team VCS, and that's fine by me.

Thomas

Re: How does team maintenace of python module works?

[Thomas Kluyver]

On 16 February 2013 09:10, Thomas Goirand  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 agree there are reasonable reasons to want to maintain something in git,
and it's not ideal to exclude those packages from team maintainership just
because of the VCS question. Although, if it came to that, the team would
be happy to offer advice and assistance for Python packages that aren't
maintained by the team. We all want stuff to work smoothly, whether or not
it's "our" stuff.

I suggest we take a poll - not as a binding decision, but to get an idea of
the level of support for different courses of action. You're free to attach
more weight to the votes of highly involved team members.

The following four positions have all been advocated in this thread:

A - Maintain the status quo, in which DPMT packages may only be maintained
in SVN.
B - As A, but encourage the creation of a separate team where Python
modules can be maintained in git.
C - Allow DPMT-maintained packages to live in SVN or git, so new packages
can be committed to git if the packager prefers. Optionally, we could make
provisions to migrate existing packages.
D - Migrate all the DPMT-maintained packages to git.

(I suggest we don't consider other VCSs - while we might have our
favourites, I sampled the list of Debian teams, and found very few using
anything other than svn or git. So tools & workflows for other VCSs are
likely to be less well developed.)

So I would vote CDBA, in order of preference.

Thanks,
Thomas

Re: How does team maintenace of python module works?

[Thomas Kluyver]

On 18 February 2013 20:46, Ludovic Gasc  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 - the only option with more than one first preference
vote is the status quo.

Thomas

Re: How does team maintenace of python module works?

[Thomas Kluyver]

On 18 February 2013 22:23, Ludovic Gasc  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
even the barest hint of consensus, and there's no particular reason to
think that a wider sample would produce a more unified opinion. If you
think it would be useful, though, I shan't stop you doing it.

Thomas

Re: How does team maintenace of python module works?

[Thomas Kluyver]

On 19 February 2013 17:55, Thomas Goirand  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 you've
described into the nearest possible vote would give us first preference
votes:

D: 4 (migration to git)
C: 3 (allow git)
E: 2 (migration to bzr)
F: 2 (migration to hg)
A: 1 (maintain status quo) - I thought there were some more, but I'm too
tired to go back through the thread at present.

Using alternative voting, knock out A (and B, which had no first preference
votes):

D: 4
C: 3
F: 3
E: 2

After that it gets tricky, because we'd knock E out next, but the I'm not
sure where the votes counted for E (Scott & Barry) should be reallocated.
If we plough ahead regardless by dropping them, it ends up with a 4-4 draw
between D (migration to git) and C (allowing git and svn). Perhaps we can
get more votes, or more fallback preferences from people who've only
expressed their first preference.

Thomas

Re: python3 and /usr/share

[Thomas Kluyver]

On 20 February 2013 14:38, Olе Streicher  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 independent data go into /usr/share/, while the Python3
> package contains everything under /usr/lib/python3.
>

The Python code itself goes into /usr/lib/python3 now - as I understand it,
/usr/share/pyshared was a workaround that's not needed for Python 3. If the
package includes actual data files, they should still go into /usr/share.

If it has a lot of data files, it might be worth splitting them into a
-data or -common package that the Python 2 & 3 packages both depend on.
IPython & matplotlib both use this: ipython3-notebook depends on
ipython-notebook-common, and python3-matplotlib depends on
python-matplotlib-data.

Best wishes,
Thomas

Re: How does team maintenace of python module works?

[Thomas Kluyver]

On 20 February 2013 14:53, Thomas Goirand  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, if you prepare a release and find some
last-minute critical bug (say, in the build process), you'll definitely
upload a fixed release tarball, because that's what people are installing
from. But you might have already tagged it, and you might forget to move
the tag to the fixed version.

Of course, in projects where the git tag is the release, it makes no
difference. But lots of projects still do tag a release and upload separate
release tarballs (say, to PyPI).

Thomas

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

[Thomas Kluyver]

On 22 February 2013 06:28, Dmitry Shachnev  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 update that, but you might want to double check the script
that you were using to scan packages, to make sure that we're not missing
other cases.

[1]
http://anonscm.debian.org/viewvc/python-modules/packages/pyxdg/trunk/debian/rules?revision=22479&view=markup
[2]
http://anonscm.debian.org/viewvc/python-modules/packages/pyxdg/trunk/debian/tests/upstream?revision=23091&view=markup

Thomas

Re: About canonical Vcs fields

[Thomas Kluyver]

On 14 March 2013 14:01, Scott Kitterman  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 it, because it
just seems like yet another gotcha to catch out new packagers.

Thomas

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

[Thomas Kluyver]

On 7 May 2013 18:46, Sandro Tosi  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 quoting the tech committee resolution:

"These breakdowns appear to be rooted in an unfortunate feedback loop, of
which all parties involved share some blame.

On multiple occasions, inflammatory comments regarding the employment
and/or motives of individuals involved in python have been made.

...

The committee expresses its disappointment in the communication problems
which have lead to this issue, and strongly suggests that all involved
parties be as awesome to each other as possible."

Please everyone, make an effort to be polite. I don't know the origin of
all the problems in debian-python (and frankly I don't want to), but it's
pretty clear that writing snarky messages isn't going to resolve them. If
you want to make a point, do so politely and people will be more inclined
to listen.

Thanks,
Thomas

Re: Bug#708573: trac-accountmanager: Please remove Python Applications Packaging Team as maintainer

[Thomas Kluyver]

On 17 May 2013 17:52, Daniel Kahn Gillmor  wrote:

> > We've been through this a number of times for both PAPT and DPMT.  We
> want a
> > common repository for each team (not split between different VCSs).
>  There's
> > been discussion about what would be needed to migrate from SVN to
> something
> > else and about what work would need to be done to do that.  So far no
> one has
> > done the work.
>
> Perhaps this should be documented someplace so that when it comes up in
> the future, there is a clear document to refer to.  I haven't heard any
> of these discussions, and i don't know where they took place or who took
> part in them.  sorry for my ignorance!
>

This came up recently on debian-python. It's a very long thread, but the
basic outcome was that, while quite a few people wanted to move away from
svn, there was very little consensus on which VCS to migrate to, whether to
include full source tarballs, and how to do any migration. It was suggested
that if someone was willing to put the time in to drive a migration, that
might be OK, but by then the discussion had pretty much killed all
enthusiasm for it.

My memory is that there was also disagreement over whether the team could
live with packages split across two difference VCSs. Some people argued
that the teams packages should be unified, others that a migration would be
easier if it didn't need to be all-at-once. Some other packaging teams
(e.g. Games) do have packages in two VCSs.

Here's the start of that thread, if you've got time to read through it all:
http://lists.debian.org/debian-python/2013/02/msg00032.html

Best wishes,
Thomas

RFS: python3-sympy

[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 discussion, it's OK to have separate source for this,
because upstream doesn't support building Python 2 and 3 packages from the
same release tarball:
http://lists.debian.org/debian-python/2012/10/msg00041.html

Thanks,
Thomas

Re: dh_python2+dh_python3

[Thomas Kluyver]

On 11 June 2013 20:58, Vincent Bernat  wrote:

>  - dh_auto_build has to be overrided to also call each supported Python
>3 version "python setup.py build".
>  - dh_auto_install has to be overrided for the same reason.
>  - Ditto for dh_auto_clean.
>  - python-.install and python3-.install needs to be defined.
>

This should be somewhat easier using the new pybuild system. Piotr
described it as:

"with pybuild in unstable it should be a lot easier to add python3-foo
packages (just add binary package in debian/control, build depend on
python3-all-dev, use --buildsystem=pybuild in debian/rules and add some
.install files / export PYBUILD_DESTDIR_python{2,3})"
http://lists.debian.org/debian-python/2013/05/msg00017.html

Thomas

Re: django-tables package

[Thomas Kluyver]

On 19 June 2013 05:47, Brian May  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 & Django sphinx
docs, so you can cross reference a Django function and Sphinx will make a
link to the documentation for it.

Thomas

Re: setuptools 0.7

[Thomas Kluyver]

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?

Thanks,
Thomas

Re: RFS: python3-sympy

[Thomas Kluyver]

On 6 June 2013 11:15, Thomas Kluyver  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://svn.debian.org/python-modules/packages/python3-sympy/trunk/
>
> From a previous discussion, it's OK to have separate source for this,
> because upstream doesn't support building Python 2 and 3 packages from the
> same release tarball:
> http://lists.debian.org/debian-python/2012/10/msg00041.html


This now also has an ITP bug, #712924. And I've put it on Debian mentors if
that helps anyone to review it.

Thanks,
Thomas

Re: starting to dive into python package bugs

[Thomas Kluyver]

On 3 July 2013 19:36, Barry Warsaw  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 (from at least 2.6 - I don't have
older versions to check). Changing the exception could still lead to it
getting caught by an except: clause which previously missed it, though.

Thomas

Re: starting to dive into python package bugs

[Thomas Kluyver]

On 16 July 2013 22:25, Stéphane Blondon  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 raised are not TypeError so it's not the
> > appropriate exception but if someone catched TypeError in another
> > software (outside Debian) it will work. It would not work with
> > Exception class. However, I still prefer raising Exception. Does
> > anyone have an opinion about that point?
> >
>
> Finally, I used BaseException. I added a patch to the bug report (#585291):


I would be inclined *not* to use BaseException for this - the intention is
that 'except Exception:' should catch all normal exceptions, and only
KeyboardInterrupt and SystemExit are outside that. I don't know the
specifics of the string exceptions you're updating, but almost anything
that Python code explicitly raises should inherit from Exception.

Thomas