Re: Sympy 0.7.2
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 jw...@debian.org wrote: * Dmitry Shachnev mity...@gmail.com, 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.orgdebian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/**20121108133234.GA1777@jwilk.**nethttp://lists.debian.org/20121108133234.ga1...@jwilk.net
Re: Second round of advise on packaging python-csb
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
Second round of advise on packaging python-csb
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: Bug 664759: python-tox request for review/sponsorship
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 ba...@python.org, 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 class 'urllib2.URLError': urlopen error [Errno -2] Name or 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
Re: egg-info's SOURCES.txt files in .deb packages
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
Is virtualenv --setuptools still useful?
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
