Re: Bug 664759: python-tox request for review/sponsorship

2012-11-12 Thread Jakub Wilk

* Barry Warsaw , 2012-11-12, 13:32:

The LICENSE file reads:
| The execnet package is released under the provisions of the Gnu Public
| License (GPL), version 2 or later.
Shouldn't it be s/execnet/tox/ and s/Gnu/GNU General/?


I've reported these upstream:

https://bitbucket.org/hpk42/tox/issue/58/typos-in-license-file


The license name is still wrong...

--
Jakub Wilk


--
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/20121113012509.gb3...@jwilk.net



Is virtualenv --setuptools still useful?

2012-11-12 Thread Barry Warsaw
I am upgrading Ubuntu 13.04's python-virtualenv package to 1.8.2.  This could
provide a basis for upgrading the Debian version in Wheezy+1.

I'd like to modify the add_distribute.patch.  What this currently does is set
virtualenv to use distribute by default.  This is fine, and I want to keep
this change.  In fact, this only affects Python 2 venvs since distribute is
the only choice for Python 3 anyway.

What I'm very tempted to drop is the addition of the --setuptools option for
Python 2 (and the $VIRTUALENV_{USE_,}SETUPTOOLS envar).  As mentioned, this
would be ignored for Python 3, but also really, who uses setuptools anymore?
:)

I don't think this would affect any Debian/Ubuntu packages, since we've long
used distribute as an alias for setuptools, so all of our packages already use
distribute.  I suppose it could break 3rd party developers, but if they're
developing on Debian, using the packaged version of virtualenv, *and* still
want to use setuptools, they're going to have to do something special anyway
(set an envar, pass in a cli switch).  Is it really that much of a hardship to
just require them to install or use upstream virtualenv from source in those
cases?  Can't we put a stake in the heart of setuptools already?

So my proposal is to adjust the patch so that it uses distribute only for both
Python 2 and 3 on Debian.

Comments?
-Barry


signature.asc
Description: PGP signature


Re: egg-info's SOURCES.txt files in .deb packages

2012-11-12 Thread Barry Warsaw
On Nov 12, 2012, at 08:29 PM, Piotr Ożarowski wrote:

>[Barry Warsaw, 2012-11-12]
>> >p: python-tox: SOURCES.txt-in-binary-package
>> 
>> Fixed, but we really need better rationale for this in the wiki. ;)
>
>If keeping this file in .deb package doesn't have any advantages,
>it can simply be removed in dh_python{2,3}. It's not even used by
>egg-ralated tools, no?

Conversely, if it does no harm, why worry about it?

OTOH, removing it in dh_python* is equivalent to "not worrying about it". :)

-Barry


signature.asc
Description: PGP signature


egg-info's SOURCES.txt files in .deb packages

2012-11-12 Thread Piotr Ożarowski
[Barry Warsaw, 2012-11-12]
> >p: python-tox: SOURCES.txt-in-binary-package
> 
> Fixed, but we really need better rationale for this in the wiki. ;)

If keeping this file in .deb package doesn't have any advantages,
it can simply be removed in dh_python{2,3}. It's not even used by
egg-ralated tools, no?
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645


signature.asc
Description: Digital signature


Re: Bug 664759: python-tox request for review/sponsorship

2012-11-12 Thread Barry Warsaw
On Nov 10, 2012, at 10:55 PM, Jakub Wilk wrote:

>(I don't intend to sponsor this, sorry.)

No problem, thanks for the review.

>* Barry Warsaw , 2012-11-09, 20:27:
>>http://anonscm.debian.org/viewvc/python-apps/packages/tox/trunk/
>
>I see some warnings in the build log:
>
>| loading intersphinx inventory from http://docs.python.org/objects.inv...
>| WARNING: intersphinx inventory 'http://docs.python.org/objects.inv' not 
>fetchable due to : service not known>

Interesting.  I didn't see the warning because I don't get it in my sbuild
environment, but I do see the "loading..." message.  I understand why this
would be a no-no for the build process, and this has come up before:

http://lists.debian.org/debian-python/2011/07/msg00016.html

I adapted the referenced patch and added the B-D.  It's now using the local
copy of objects.inv.

>| /build/tox-W107m9/tox-1.4.2/doc/index.txt:90: WARNING: toctree contains
>| reference to nonexisting document u'config-v1'

Upstream bug, reported here:

https://bitbucket.org/hpk42/tox/issue/57/doc-indextxt-refers-to-non-existent

quilt patch added.

>Furthermore, the package FTBFS if built twice in a row:
>
>| dpkg-source: error: unwanted binary file: 
>debian/manpage/_build/doctrees/environment.pickle
>| dpkg-source: error: unwanted binary file: 
>debian/manpage/_build/doctrees/tox-man.doctree
>| dpkg-source: error: detected 2 unwanted binary files (add them in 
>debian/source/include-binaries to allow their inclusion).
>| dpkg-buildpackage: error: dpkg-source -b tox-1.4.2 gave error exit status 29

I *think* I've fixed this now.

>lintian emits:
>
>I: tox source: binary-control-field-duplicates-source field "priority" in 
>package python-tox
>P: python-tox: no-homepage-field
>I: python-tox: possible-documentation-but-no-doc-base-registration

These should be fixed now.

>lintian4python emits:
>
>x: tox source: missing-vcs-field vcs-svn 
>svn://svn.debian.org/python-apps/packages/tox/trunk/
>x: tox source: missing-vcs-field vcs-browser
>http://svn.debian.org/viewsvn/python-apps/packages/tox/trunk/

Fixed.

>p: python-tox: SOURCES.txt-in-binary-package

Fixed, but we really need better rationale for this in the wiki. ;)

>e: python-tox: missing-dependency-for-import pkg_resources (usr/bin/tox) =>
>python-pkg-resources

Fixed.

>(+ some boring pyflakes-* tags)

Yeah, the one remaining one is a false positive.

>I think section should be "python" not "misc"; priority should be optional.
>
>Current standards version is 3.9.4.
>
>Shouldn't you add yourself to d/copyright?

All fixed.

>The LICENSE file reads:
>| The execnet package is released under the provisions of the Gnu Public
>| License (GPL), version 2 or later.
>
>Shouldn't it be s/execnet/tox/ and s/Gnu/GNU General/?

I've reported these upstream:

https://bitbucket.org/hpk42/tox/issue/58/typos-in-license-file

>Licenses of toxbootstrap.py and tox/_verlib.py are not documented in the
>copyright file.

Fixed.

>>P.S. I know the manpage sucks;
>
>Agreed, it does.
>
>Also, I think that adding full-blown makefile just to build a single manpage
>is overkill. You could call sphinx-build manually in debian/rules

Fair enough, fixed.

>>I'm trying to find some examples of Sphinx-generated manpages, after >which 
>>I'll improve that.
>
>Take a look at... sphinx-* manpages. Dogfooding FTW! :)

Okay!  Now the manpage sucks less. :)

Thanks for the review, and any re-review you might do.  So, anybody want to
sponsor it?

-Barry


-- 
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/20121112133239.72cbd...@limelight.wooz.org



Second round of advise on packaging python-csb

2012-11-12 Thread Tomás Di Domenico
Greetings, all.

After the very helpful replies I received to my first message about
packaging the CSB library, I'm now kindly requesting a second round of
comments on the state of the package.

With the goal of having a clean repo to start with, but also willingly
repeating some steps to better understand and learn them, I have
recreated the git repository for the package. A consequence of this is
that you will not be able to use the logs to see the changes since my
first message, so here's a list of the things I did:

* Rebuilt the package with an upstream release tarball
* Added 'X-Python-Version: >= 2.6' to debian/control
* Versioned the build-dependency on python-all (
>= 2.6.6-3~)
* Bumped the standard to 3.9.4
* Bumped debhelper to 8.1.0
* Changed debian/* license to MIT, matching upstream's
* Added dependency on ${python:Depends}
* Removed the empty docs file

Speaking of docs, the upstream tarball contains HTML-formatted
documentation for the module's API. How would this be handled? Should it
be made available as a separate package?

Once again, thank you all in advance.

Tomás


-- 
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/50a108e7.4050...@tdido.com.ar



Re: Second round of advise on packaging python-csb

2012-11-12 Thread Tomás Di Domenico
I clumsily forgot to post a reference to the package repository [1] in
my previous message. My apologies.

Tomás

[1] http://anonscm.debian.org/gitweb/?p=debian-med/python-csb.git;a=summary

On 12/11/12 15:34, Tomás Di Domenico wrote:
> Greetings, all.
> 
> After the very helpful replies I received to my first message about
> packaging the CSB library, I'm now kindly requesting a second round of
> comments on the state of the package.
> 
> With the goal of having a clean repo to start with, but also willingly
> repeating some steps to better understand and learn them, I have
> recreated the git repository for the package. A consequence of this is
> that you will not be able to use the logs to see the changes since my
> first message, so here's a list of the things I did:
> 
> * Rebuilt the package with an upstream release tarball
> * Added 'X-Python-Version: >= 2.6' to debian/control
> * Versioned the build-dependency on python-all (
>> = 2.6.6-3~)
> * Bumped the standard to 3.9.4
> * Bumped debhelper to 8.1.0
> * Changed debian/* license to MIT, matching upstream's
> * Added dependency on ${python:Depends}
> * Removed the empty docs file
> 
> Speaking of docs, the upstream tarball contains HTML-formatted
> documentation for the module's API. How would this be handled? Should it
> be made available as a separate package?
> 
> Once again, thank you all in advance.
> 
> Tomás


-- 
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/50a109ac.2000...@tdido.com.ar



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