Broken symlinks in /etc/alternatives
I noticed this on my system: $ ls /etc/alternatives/* | xargs -n1 file | grep -w broken | grep python /etc/alternatives/bandit: broken symbolic link to /usr/bin/python3-bandit /etc/alternatives/bandit-baseline: broken symbolic link to /usr/bin/python3-bandit-baseline /etc/alternatives/bandit-config-generator: broken symbolic link to /usr/bin/python3-bandit-config-generator /etc/alternatives/doc8: broken symbolic link to /usr/bin/python3-doc8 /etc/alternatives/pbr: broken symbolic link to /usr/bin/python3-pbr /etc/alternatives/restructuredtext-lint: broken symbolic link to /usr/bin/python3-restructuredtext-lint /etc/alternatives/rst-lint: broken symbolic link to /usr/bin/python3-rst-lint /etc/alternatives/wsdump: broken symbolic link to /usr/bin/python3-wsdump I guess this is fallout from Python 2 removal? Please fix your packages. -- Jakub Wilk
Re: Proposed MBF: packages still using nose
anorack Fixed upstream in 0.2.8. mwic Fixed upstream in 0.7.9. python-djvulibre Fixed upstream in 0.8.7. This one should probably be removed, though: there are no rev-deps, it's orphaned in Debian, and it's likely to be orphaned upstream soon too. -- Jakub Wilk
Re: can we disable the bounce kicker? Re: confirm
* Sandro Tosi <mo...@debian.org>, 2016-09-11, 10:42: Now, you've got to ask to the admin of that mailing list, which appears to be jwilk. I find that particularly interesting, given that afaik he left the team some time ago. Yeah, that's bizarre. I don't know whether anybody else knows the administration password other than him. When I reset the password back in 2013, I sent it to all the DPMT admins.[0] Hey jwilk, would you be able to disable the suspend membership upon bounces on the python teams mailing lists? No, I'm too lazy. maybe you also want to hand over the administration of the mls to someone else, given you moved on from dpmt/papt :) Very gladly! Now we only need this "someone else". Last time[1] I asked the DPMT admins to take over the list admin duties, there were no replies. [0] <20130411191230.ga...@jwilk.net> [1] <20150410194600.ga...@jwilk.net> -- Jakub Wilk
Re: Terminal Pager at unit tests
* Josue Ortega josueort...@debian.org.gt, 2014-09-08, 21:21: When the tests are running the docstrings are displayed in a terminal pager making impossible run all tests without human interaction to close the pager. I've found this really annoying if someone wants to build the package even the build process might fail if it's running on an automated enviroment. I could't find an elegant way to disable the terminal pager. Programs launching pagers must honour the PAGER environment variable (see Policy §11.4). So adding this to debian/rules should do the trick: export PAGER = cat -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140909105957.ga3...@jwilk.net
Re: Bug#758013: s3ql autopkg test regression
* Matthias Klose d...@debian.org, 2014-08-19, 10:33: Control: severity -1 important The maintainer decides on the bug severity. Please don't abuse the BTS. That's a bug in the test (race condition) rather than in the program. It's fixed upstream. Nikolaus, I find this kind of attitude rather disturbing. If you don't care about the autopkg tests, and if you are not ready to fix these but rather wait for the fixes from upstream (and maybe new bugs), then I think it's better to drop the autopkg tests. Why is it better? If you want the maintainer to give priority to a bug, you need to give a better justification than “I said so”. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140819090239.ga7...@jwilk.net
Re: Python3 search path order when building Debian package
It's most likely unrelated to your problem, but... * Thomas Goirand z...@debian.org, 2014-08-12, 02:51: set -e set -x for i in 2.7 $(PYTHON3S) ; do \ set -e has no effect on statements that use . So you probably want s//;/g here. TEMP_REZ=`mktemp -t` \ PYTHONPATH=$(CURDIR) PYTHON=python$$i testr-python$$PYMAJOR run --subunit | tee $$TEMP_REZ | subunit2pyunit ; \ And here too. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140811192311.ga8...@jwilk.net
Re: python-pandocfilters_1.2.1-1_amd64.changes is NEW
Hi Sebastian, debian-python@l.d.o, is a discussion list. We don't want all the bug traffic or messages from dak here. Please set your Maintainer field to: Debian Python Modules Team python-modules-t...@lists.alioth.debian.org -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140723225612.gb1...@jwilk.net
Re: /usr/bin/django-admin in python-django
* Brian May br...@microcomaustralia.com.au, 2014-07-20, 11:47: Or, another words, ideally we want all these to work: python2 /usr/bin/django-admin - python2 python3 /usr/bin/django-admin - python3 /usr/bin/django-admin - autodetect. One possibility is to write a shell script that is also valid Python code. PoC: #!/bin/sh sh= if command -v python3 /dev/null; then exec python3 $0 $@ else exec python $0 $@ fi ' ''' import sys print(I'm Python %d.%d! % sys.version_info[:2]) Another possibility is to create the django-admin symlink in maintainer scripts, with the target depending on which of python*-django packages are installer. This is how src:sphinx manages its /usr/bin/sphinx-* symlinks. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140720090004.ga2...@jwilk.net
Re: Embedded six.py in many packages: can someone add a lintian check?
* Barry Warsaw ba...@debian.org, 2014-05-29, 10:53: Unfortunately, it's not just six that gets vendorized. I'd be in favor of a lintian check if it could be generalized to warn against all vendorizing. A warning specifically about six is helpful but limited. How would you implement the generalization then? Yeah, that's the trick; I'm not sure. The best I could come up with was an a priori list of known common vendorizations. So something like this: https://bitbucket.org/jwilk/lintian4python/src/default/vendors/debian/python/data/python2-embedded-code-copies ? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140529161246.ga4...@jwilk.net
Re: Embedded six.py in many packages: can someone add a lintian check?
* Daniele Tricoli er...@mornie.org, 2014-05-28, 15:36: txclib - urllib3 - six Jakub, which version of urllib3 are you referring to? The one that is embedded in transifex-client. I removed the embedded copy on 1.3-2 so it should be ok... Great, thanks. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140528134751.ga7...@jwilk.net
Re: Help with python-biom-format needed
* Piotr Ożarowski pi...@debian.org, 2014-05-21, 11:14: svn://anonscm.debian.org/debian-med/trunk/packages/python-biom-format/trunk/ Unfortunately the new version has a problem when it comes to build the documentation. Either does not find the biom Python module or since I adapted the packaging to dh_python using --buildsystem=pybuild in debian/rules I get Makefile:50: recipe for target 'singlehtml' failed I cannot reproduce it. It FTBFS due to ImportError: No module named biom while trying to build docs, though. s/not// :-P The error is: sphinx-build -b singlehtml -d _build/doctrees -W . _build/singlehtml Making output directory... Running Sphinx v1.2.2 Exception occurred: File conf.py, line 17, in module import biom ImportError: No module named biom The full traceback has been saved in /tmp/sphinx-err-bzenOM.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. A bug report can be filed in the tracker at https://bitbucket.org/birkenfeld/sphinx/issues/. Thanks! Makefile:50: recipe for target 'singlehtml' failed So, is there a sane way to make pybuild run an arbitrary command with default version of python, and with PYTHONPATH set to the build directory? One insane way is to abuse the --test option: pyrun = DEB_BUILD_OPTIONS= pybuild -s custom -p $(shell pyversions -dv) --test --test-args [...] $(pyrun) 'make --directory=doc singlehtml' # eww! -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140521110223.ga6...@jwilk.net
Re: Help with python-biom-format needed
* Andreas Tille andr...@an3as.eu, 2014-05-21, 15:09:
So, is there a sane way to make pybuild run an arbitrary command with
default version of python, and with PYTHONPATH set to the build
directory?
One insane way is to abuse the --test option:
pyrun = DEB_BUILD_OPTIONS= pybuild -s custom -p $(shell pyversions -dv) --test
--test-args
[...]
$(pyrun) 'make --directory=doc singlehtml' # eww!
Well, if there is no other suggestion for a not so insane solution I
might try this.
With the attached patch I got the package almost building. Almost,
becasue the tests fail:
I: pybuild base:170: cd /home/jwilk/python-biom-format/.pybuild/pythonX.Y_2.7/build; python2.7 -m nose --with-doctest
/home/jwilk/python-biom-format/.pybuild/pythonX.Y_2.7/build/biom/util.py:27: UserWarning: h5py is not available
warn(h5py is not available)
EEE..
==
ERROR: Failure: NameError (global name '_type_handlers' is not defined)
--
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/nose/loader.py, line 414, in
loadTestsFromName
addr.filename, addr.module)
File /usr/lib/python2.7/dist-packages/nose/importer.py, line 47, in
importFromPath
return self.importFromDir(dir_path, fqname)
File /usr/lib/python2.7/dist-packages/nose/importer.py, line 94, in
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
File
/home/jwilk/python-biom-format/.pybuild/pythonX.Y_2.7/build/biom/interfaces/html/config/convert.py,
line 57, in module
Help='Process metadata associated with observations when '
File /usr/lib/python2.7/dist-packages/pyqi/core/interfaces/html/__init__.py,
line 67, in __init__
super(HTMLInputOption, self).__init__(Type=Type, **kwargs)
File /usr/lib/python2.7/dist-packages/pyqi/core/interface.py, line 239, in
__init__
self._validate_option()
File /usr/lib/python2.7/dist-packages/pyqi/core/interfaces/html/__init__.py,
line 123, in _validate_option
elif type(self.Choices) not in (_type_handlers.TupleType, types.ListType):
NameError: global name '_type_handlers' is not defined
==
ERROR: Failure: ImportError (cannot import name html_list_of_strings)
--
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/nose/loader.py, line 414, in
loadTestsFromName
addr.filename, addr.module)
File /usr/lib/python2.7/dist-packages/nose/importer.py, line 47, in
importFromPath
return self.importFromDir(dir_path, fqname)
File /usr/lib/python2.7/dist-packages/nose/importer.py, line 94, in
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
File
/home/jwilk/python-biom-format/.pybuild/pythonX.Y_2.7/build/biom/interfaces/html/config/show_install_info.py,
line 25, in module
from pyqi.core.interfaces.html.output_handler import html_list_of_strings
ImportError: cannot import name html_list_of_strings
==
ERROR: Failure: ImportError (cannot import name write_or_print_list_of_strings)
--
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/nose/loader.py, line 414, in
loadTestsFromName
addr.filename, addr.module)
File /usr/lib/python2.7/dist-packages/nose/importer.py, line 47, in
importFromPath
return self.importFromDir(dir_path, fqname)
File /usr/lib/python2.7/dist-packages/nose/importer.py, line 94, in
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
File
/home/jwilk/python-biom-format/.pybuild/pythonX.Y_2.7/build/biom/interfaces/optparse/config/summarize_table.py,
line 23, in module
from pyqi.core.interfaces.optparse.output_handler import (
ImportError: cannot import name write_or_print_list_of_strings
--
Ran 25 tests in 0.482s
FAILED (errors=3)
E: pybuild pybuild:256: test: plugin distutils failed with: exit code=1: cd /home/jwilk/python-biom-format/.pybuild/pythonX.Y_2.7/build; python2.7 -m nose --with-doctest
dh_auto_test: pybuild --test -i python{version} -p 2.7 --dir . returned exit code 13
debian/rules:20: recipe for target 'build' failed
make: *** [build] Error 13
dpkg-buildpackage: error: debian/rules build gave error exit status 2
--
Jakub Wilk
Index: debian/control
===
--- debian/control (revision 16978)
+++ debian/control (working copy)
@@ -8,6 +8,7 @@
dh-linktree,
python-dev,
python-numpy,
+ python-scipy,
help2man,
python-dateutil,
python-cogent,
Index: debian/rules
Re: Help with python-biom-format needed
* Andreas Tille andr...@an3as.eu, 2014-05-21, 15:05: I'm now also excluding *.so and *.pyx. Hmm, *.pyx? Aren't they source code from some *.c files? Uh, yes, they are - re-added. Thanks for correcting me. This opens the question about the policy of *.c files: Should these regenerated at build time (and thus these might be removed as well) or not? I strongly recommend rebuilding everything from source. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140521133823.gb9...@jwilk.net
Re: wheel support for Debian?
* Matthias Klose d...@debian.org, 2014-05-19, 12:44: we don't unpack jar files either. Fortunately, we don't have to mimic all the Java misfeatures. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140519111953.gc8...@jwilk.net
Re: restarting services after security upgrades in pure-Python modules?
* Paul Wise p...@debian.org, 2014-05-16, 14:17: Anyone know if it is possible to detect processes that are using old versions of pure-Python modules after security upgrades to them? needrestart(1) attempts to do that, but I doubt it works well: https://sources.debian.net/src/needrestart/0.9-1/perl/lib/NeedRestart/Interp/Python.pm -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140516203454.ga5...@jwilk.net
Re: Preventing network access during nose doctest ?
* Barry Warsaw ba...@debian.org, 2014-05-12, 09:41: Note that some test suites do legitimate http/https access during their tests. By legitimate I mean, they set up their own localhost special-port service and vend files out of them. AFAICS urllib honours the no_proxy environment variable. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140512135255.ga...@jwilk.net
Re: Bug#747494: python3-biopython: Does not use C implementations of cpairwise2 functions
* Andreas Tille andr...@an3as.eu, 2014-05-09, 13:15: thanks for your bug report. I think this should work out of the box but I personally not comfortable with cpython to know how this could be fixed. I keep the Debian Python list in CC - perhaps they might have some helpful advise. The relvant code in Bio/pairwaise2.py is: # Try and load C implementations of functions. If I can't, # then just ignore and use the pure python implementations. try: from cpairwise2 import rint, _make_score_matrix_fast except ImportError: pass But in Python 3 imports as always absolute, unless explicitly requested, so the import fails, and this code snippet is no-op. Changing the import line to: from .cpairwise2 import rint, _make_score_matrix_fast should do the trick. Before: $ python3 -c 'from Bio.pairwise2 import rint; print(rint.__module__)' Bio.pairwise2 After: $ python3 -c 'from Bio.pairwise2 import rint; print(rint.__module__)' Bio.cpairwise2 It seems this module is not affected by the test suite since this runs fine. Yeah, as the code comment says, if the import fails, everything(?) still works, just slower. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140509113237.ga7...@jwilk.net
Re: sponsorship request
* Thomas Goirand z...@debian.org, 2014-05-07, 14:29:
Same remark also for the binary Depends: of python-django-piston. But
this time, if dh_python2 (see below) automatically adds the
dependencies by replacing ${python:Depends}, then probably you can
completely remove the manual dependencies (this will have to be checked
after a build, for example using mc to see the content of the .deb,
and going into the DEBIAN folder).
I find debc(1) very convenient for checking whether the built binary
packages make sense.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140507065832.ga2...@jwilk.net
Re: Getting rid of python-support?
* Dimitri John Ledkov x...@debian.org, 2014-04-30, 16:43:
python-central is gone (\o/) and python-support usage is slowly
decreasing in the archive:
http://lintian.debian.org/tags/dh_pysupport-is-obsolete.html
Do you think it would be the right time to prepare a mass bug filing
asking to convert to dh_python{2,3}?
Given it's like less than 200 packages left, let's do it now. This is
smaller than e.g. a boost transition.
This tag doesn't catch indirect use of python-support, via dh or cdbs.
The actual number of affect packages is much higher.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140430172723.ga4...@jwilk.net
Re: BioPython: Some Python modules not found in tests at package build time
* Andreas Tille andr...@an3as.eu, 2014-04-28, 13:11: [Debian Python Modules Team python-modules-t...@lists.alioth.debian.org in CC since it maintains python-reportlab] ITYM s/maintains/is in Uploaders of/. It makes a big difference here... Does this mean that not any member of the team could upload a fixed package? I don't know that. What I know is that there were no commits to the package's repository by the maintainers since 2006. And changes by other team members made to the repository weren't integrated in package either. Well, this was rather me forgetting a python-imaging dependency - I (wrongly) assumed that python-pil would be sufficient. Note that python-imaging is only a compatibility package. It would be better to port biopython to the new PIL API. Well, I have no idea what porting really means. python-imaging's description more or less says what you have to change: “PIL used to provide a PIL.pth file which allowed you to `import Image` but this is deprecated. Use `from PIL import Image` now, or install this compatibility package to temporarily get the old behavior back.” If there might be a simple patch that would be OK. Otherwise I can only hope for upstream. That attached (untested) patch should do the trick. -- Jakub Wilk diff --git a/Tests/test_GenomeDiagram.py b/Tests/test_GenomeDiagram.py --- a/Tests/test_GenomeDiagram.py +++ b/Tests/test_GenomeDiagram.py @@ -27,7 +27,7 @@ Install reportlab if you want to use Bio.Graphics.) try: -import Image +from PIL import Image from reportlab.graphics import renderPM except ImportError: #This is an optional part of ReportLab, so may not be installed. diff --git a/Tests/test_GraphicsBitmaps.py b/Tests/test_GraphicsBitmaps.py --- a/Tests/test_GraphicsBitmaps.py +++ b/Tests/test_GraphicsBitmaps.py @@ -35,7 +35,7 @@ bitmaps with Bio.Graphics.) try: # Skip the test if PIL is not installed -import Image as i +from PIL import Image as i del i except: raise MissingPythonDependencyError(
Re: BioPython: Some Python modules not found in tests at package build time
* Andreas Tille andr...@an3as.eu, 2014-04-25, 16:08: [Debian Python Modules Team python-modules-t...@lists.alioth.debian.org in CC since it maintains python-reportlab] ITYM s/maintains/is in Uploaders of/. It makes a big difference here... test_GraphicsBitmaps ... Warn: Can't find .pfb for face 'Times-Roman' skipping. Check the fonts needed by ReportLab if you want bitmaps from Bio.Graphics Can't setFont(Times-Roman) missing the T1 files? Originally type 'exceptions.TypeError': makeT1Font() argument 2 must be string, not None Well, this was rather me forgetting a python-imaging dependency - I (wrongly) assumed that python-pil would be sufficient. Note that python-imaging is only a compatibility package. It would be better to port biopython to the new PIL API. So any idea how to get .pfb for face 'Times-Roman' found by reportlab […] Unfortunately the result remained the same. I somehow came to the conclusion that the problem is caused by a broken reportlab package I came to the same conclusion. I've attached what seems to be a minimal test-case: $ python test.py Warn: Can't find .pfb for face 'Times-Roman' Traceback (most recent call last): File test.py, line 6, in module renderPM.drawToFile(d, 'test.png', 'PNG') File /usr/lib/python2.7/dist-packages/reportlab/graphics/renderPM.py, line 655, in drawToFile c = drawToPMCanvas(d, dpi=dpi, bg=bg, configPIL=configPIL, showBoundary=showBoundary) File /usr/lib/python2.7/dist-packages/reportlab/graphics/renderPM.py, line 641, in drawToPMCanvas draw(d, c, 0, 0, showBoundary=showBoundary) File /usr/lib/python2.7/dist-packages/reportlab/graphics/renderPM.py, line 50, in draw R.draw(renderScaledDrawing(drawing), canvas, x, y, showBoundary=showBoundary) File /usr/lib/python2.7/dist-packages/reportlab/graphics/renderbase.py, line 198, in draw self.initState(x,y) #this is the push() File /usr/lib/python2.7/dist-packages/reportlab/graphics/renderPM.py, line 99, in initState self.applyState() File /usr/lib/python2.7/dist-packages/reportlab/graphics/renderPM.py, line 93, in applyState self._canvas.setFont(s['fontName'], s['fontSize']) File /usr/lib/python2.7/dist-packages/reportlab/graphics/renderPM.py, line 374, in setFont _setFont(self._gs,fontName,fontSize) File /usr/lib/python2.7/dist-packages/reportlab/graphics/renderPM.py, line 227, in _setFont raise RenderPMError(Can't setFont(%s) missing the T1 files?\nOriginally %s: %s % (fontName,s1,s2)) reportlab.graphics.renderPM.RenderPMError: Can't setFont(Times-Roman) missing the T1 files? Originally type 'exceptions.TypeError': makeT1Font() argument 2 must be string, not None If I understand correctly, reportlab is trying to use non-free Adobe PostScript fonts, which (unsurprisingly) doesn't work on Debian systems. It should use the substitutes from the gsfonts package instead. -- Jakub Wilk from reportlab.graphics.shapes import Drawing from reportlab.graphics import renderPM d = Drawing(100, 100) renderPM.drawToFile(d, 'test.png', 'PNG')
Re: BioPython: Some Python modules not found in tests at package build time
* Jakub Wilk jw...@debian.org, 2014-04-26, 21:12: reportlab.graphics.renderPM.RenderPMError: Can't setFont(Times-Roman) missing the T1 files? Originally type 'exceptions.TypeError': makeT1Font() argument 2 must be string, not None Filed as #745985. Please let me know if the patch I made fixes all the reportlab problems for you. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140426215312.ga4...@jwilk.net
Re: RFS: python-ebooklib
(I don't intend to sponsor this package. Sorry!)
* Daniel James dan...@64studio.com, 2014-04-24, 17:34:
I am a non-DD looking for sponsorship of (or any helpful hints about)
my first upload to Debian:
http://mentors.debian.net/package/python-ebooklib
Direct link to .dsc for the lazy:
http://mentors.debian.net/debian/pool/main/p/python-ebooklib/python-ebooklib_0.15-1.dsc
Don't hardcode Python versions in Depends. Use ${python:Depends} and
${python3:Depends} substitution variables instead.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140424173428.ga4...@jwilk.net
Re: [PATCH] Support :any architecture qualifiers for multiarch
* Steve Langasek vor...@debian.org, 2013-09-18, 14:33: On Wed, Sep 18, 2013 at 06:24:13PM +0200, Jakub Wilk wrote: Following the “if it didn't happen on a mailing list, it didn't happen”, I repeat here what I said on IRC: 12:26 kwilk So I rebuilt src:python-aalib, and I ended up these Depends: python3:any (= 3.3.2-2~), libaa1. 12:27 kwilk This is wrong; the package only works if the interpreter architecture is the same as libaa1 architecture. 12:27 kwilk Please revert this :any mess. 12:30 kwilk In general, just because a script or a module is pure-Python doesn't mean it doesn't care about interpreter's architecture. 12:30 kwilk And there's no way to determine automatically whether it cares or not. Nonsense. Yeah, right. # dpkg --print-architecture i386 # dpkg --print-foreign-architectures amd64 # apt install liblas [...] # python -c 'import liblas; print liblas' module 'liblas' from '/usr/lib/python2.7/dist-packages/liblas/__init__.pyc' # apt install python:amd64 [...] # python -c 'import liblas; print liblas' Traceback (most recent call last): File string, line 1, in module File /usr/lib/python2.7/dist-packages/liblas/__init__.py, line 2, in module from core import get_version File /usr/lib/python2.7/dist-packages/liblas/core.py, line 157, in module las = ctypes.CDLL(lib_name) File /usr/lib/python2.7/ctypes/__init__.py, line 365, in __init__ self._handle = _dlopen(self._name, mode) OSError: liblas_c.so.2: wrong ELF class: ELFCLASS32 As a strawman, if there's a consensus that it's important to preserve the capability to install jessie module packages on top of wheezy's python, we could generate dependencies such as: python:any (= 2.7.5-5) | python (= 2.6.6-3) which I think would DTRT in all cases except where you try to cross-install on top of the wheezy python, which is a negligible use case. The idea that cross-installabilty of python could justify less smooth wheezy-jessie upgrades is not even remotely funny. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140421004135.ga8...@jwilk.net
Re: Python CGI sandboxing advice (packaging of Online Python Tutor)
* Jakub Wilk jw...@debian.org, 2014-02-13, 00:27:
The CGI's code is supposed to be safeguarding against abuse,
The protection is not very good. (I'll disclose the details later.)
The exploit I had in mind was:
import re
from re import sys
imp = re.sys.modules['imp']
posix = imp.load_dynamic('', 'posix')
which gives you access to the goodies of the posix module. There's a
resource limit that prevents you from opening any file, but you can do
chmod(), chown(), remove(), rename(), kill(), …
Apparently this is now fixed:
https://github.com/pgbovine/OnlinePythonTutor/commit/eab7cb1c717a
I wouldn't be surprised if there were other clever ways to bypass OPT's
security restrictions, and upstream doesn't seem to confident about this
code either.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140409121133.ga2...@jwilk.net
Re: Bug#743583: python3-gi fails to install on arm64 (struct.error from py3compile)
* Emilio Pozuelo Monfort po...@debian.org, 2014-04-04, 00:49: Setting up python3-gi (3.10.2-2) ... Traceback (most recent call last): File /usr/bin/py3compile, line 290, in module main() File /usr/bin/py3compile, line 270, in main options.force, options.optimize, e_patterns) File /usr/bin/py3compile, line 172, in compile interpreter.magic_number(version), mtime) struct.error: 'l' format requires -2147483648 = number = 2147483647 Probably something to do with bogus timestamps in the deb: drwxr-xr-x root/root 0 2063-05-01 14:32 ./ Of couse, it would be better if dh_python3 was Y2038-compliant. :) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140403232159.ga4...@jwilk.net
Re: Growing file lists after python2.7 rebuild
* Moritz Muehlenhoff j...@debian.org, 2014-03-11, 18:30: I prepared a security update for python2.7 in stable-security fixing CVE-2013-4238 and CVE-2014-1912. But rebuilding the package caused changes in the file list which are not obvious to me: In python2.7-minimal: +/usr/lib/python2.7/lib-dynload/_hashlib.so +/usr/lib/python2.7/lib-dynload/_ssl.so In python2.7: +/usr/lib/python2.7/lib-dynload/_hashlib.so +/usr/lib/python2.7/lib-dynload/_ssl.so Unexpected migrations of these modules between python2.7 and python2.7-minimal have been observed in the past: #702005. Turns out that sweeping the problem under the carpet, instead of fixing it properly, wasn't the best strategy… Does anyone have an idea what's going wrong? debian/rules has some commented entries for lib-dynload/_bsddb.so, so this seems to be a generic problem? No idea yet, but I will look into it. This happened both for my local build and on the buildd. Source package and build log are on http://people.debian.org/~jmm/ “You don't have permission to access /~jmm/python2.7_2.7.3-6+deb7u1_i386-20140305-1206.gz on this server.” -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140311182655.gb8...@jwilk.net
Re: Growing file lists after python2.7 rebuild
[This is a copy of what I sent to #702005 (after unarchiving it), which didn't show up on bugs.d.o yet.] According to python2.7-minimal's README.Debian, the _ssl and _hashlib are supposed to be included in the -minimal package. python2.7-minimal_2.7.3-6_amd64.deb indeed includes them both, but on every other architecture they are shipped in python2.7. Worse, if you rebuild wheezy's src:python2.7 in a clean environment, the modules move to python2.7, likely leading to upgrade problem similar to that reported a while ago: * Vincent Lefevre vinc...@vinc17.net, 2013-03-01, 17:00: Unpacking replacement python2.7 ... dpkg: error processing /var/cache/apt/archives/python2.7_2.7.3-7_amd64.deb (--unpack): trying to overwrite '/usr/lib/python2.7/lib-dynload/_hashlib.so', which is also in package python2.7-minimal 2.7.3-6 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) I believe the bug lies in the following part of debian/rules: DH_COMPAT=2 dh_movefiles -p$(p_min) --sourcedir=$(d) \ usr/bin/python$(VER) \ usr/share/man/man1/python$(VER).1 \ $(foreach i,$(MIN_MODS),$(scriptdir)/$(i).py) \ $(foreach i,$(MIN_PACKAGES),$(scriptdir)/$(i)) \ $(foreach i,$(MIN_ENCODINGS),$(scriptdir)/$(i)) \ $(scriptdir)/config/Makefile \ usr/include/$(PVER)/pyconfig.h \ $(scriptdir)/site.py \ $(shell cd $(d); for i in $(MIN_EXTS); do \ test -e $(scriptdir)/lib-dynload/$$i.so \ echo $(scriptdir)/lib-dynload/$$i.so; \ done; true) The culprit appears to be that make expands $(shell ... ) too early, when no *.so files exist yet. Replacing $(shell ... ) with $$( ... ), and then adding appropriate Breaks+Replaces should fix this bug. (I haven't tested the proposed fix in practice yet.) It still don't understand why this bug didn't trigger for the amd64 package. Perhaps the build log could shed some light on it. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140311234718.ga6...@jwilk.net
Re: Bug#739840: python-netaddr: python3 shebang
* Vincent Bernat ber...@debian.org, 2014-02-23, 08:57: /usr/bin/netaddr has #! /usr/bin/python shebang, as expected. But when I rebuilt the package from source, the binary ended up with #! /usr/bin/python3 shebang. This is not the first time I get this when I have both a Python 2.x and a Python 3 packages. The last time, I fixed this by inverting the sections in debian/control. Eww! Is there a better solution? Looking at my build log, debian/rules called python setup.py install \ --root=/build/python-netaddr-c_G4Pi/python-netaddr-0.7.10/debian/tmp/ \ --install-purelib=/usr/lib/python2.7/site-packages/ \ --prefix=/usr --no-compile -O0 and later python3 setup.py install \ --root=/build/python-netaddr-c_G4Pi/python-netaddr-0.7.10/debian/tmp/ \ --install-purelib=/usr/lib/python3.3/site-packages/ \ --prefix=/usr --no-compile -O0 I doubt that cdbs guarantees any particular order of these two calls. Even if it did, it's still insufficient to get deterministic shebang: distutils won't overwrite files if they have identical[0] timestamps. How to fix this? There are many possibilities: 1) Make sure that both “setup.py install” calls are made in the correct order, and that the last uses the --force[1] option. 2) Don't install both to the same directory, but rather install each one to its own debian/$pkgname/. If you take advantage of the fact that Python 2 and Python 3 versions of the script vary only with shebang (no 2to3 involved), you have even more options: 3) Pass --executable[2] to “setup.py build”. 4) Fix shebang using dh_python2's --shebang. 5) Fix shebang using sed. I can't offer help with implementing any of the above options, because I don't know cdbs. Sorry! [0] Resolution for the timestamp check is 1 second. :( http://bugs.python.org/issue18027 [1] --force (-f) force installation (overwrite any existing files) [2] --executable (-e) specify final destination interpreter path (build.py) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140226185412.ga7...@jwilk.net
Re: preparing for Python 3.4
* Matthias Klose d...@debian.org, 2014-02-21, 00:22: The most common thing is a generated dependency on python3.x, because a package contains a file/binary with a python3.x shebang. In most cases this should be replaced with a python3 shebang, which can be done with dh_python3 --shebang=/usr/bin/python3. But why not automate this? dh_python3 looks at the b-d's, and if it doesn't find a b-d on python3-all-dev or libpython-all-dev, then it should be safely replaced. It's none of the dh_python3 business to know what I have in Build-Depends, especially since it can't possibly know why I have it there. Even for packages with a b-d on python-all-dev, in most cases a python3 shebang should be the correct default. Same thing for python2.7, maybe not that important, because nobody cares and we have only one version available. So change dh_python? Isn't pile of hacks implemented in dh_python* high enough already? Or at least add some lintian warning for a dependency on a specific python version? Sounds better. FWIW, lintian4python has this: $ lintian4py-info -t versioned-python-shebang I: versioned-python-shebang N: N: This script starts with a shebang referring to versioned interpreter N: name. This is often a mistake. N: N: Severity: normal, Certainty: wild-guess N: N: Check: python/scripts, Type: binary N: -- 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/20140221220551.ga8...@jwilk.net
Re: Python CGI sandboxing advice (packaging of Online Python Tutor)
* Olivier Berger olivier.ber...@telecom-sudparis.eu, 2014-02-10, 10:51: The CGI's code is supposed to be safeguarding against abuse, The protection is not very good. (I'll disclose the details later.) but I think some sandboxing would be better at the CGI invocation for additional security. Agreed. -- 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/20140212232736.ga21...@jwilk.net
Re: Bug#736721: Incorrect dependencies
What attic/crypto.py currently does is:
libcrypto = cdll.LoadLibrary(find_library('crypto'))
But there is no guarantee that find_library('crypto') returns a library
that is ABI-compatible with the Python code. For the Debian package, a
quickdirty fix is to replace the find_library() call with
'libcrypto.so.1.0.0', then hardcode libssl1.0.0 in Depends. But that of
course means that the package would need a sourceful upload by the next
OpenSSL transition.
* Dmitry Shachnev mity...@gmail.com, 2014-02-07, 11:37:
a simplier solution will be to use existing modules like python-xattr
and python-crypto, or writing a Python extension where you can use C
code.
Instead of full-blow extension module, you could build a thin C wrapper
over the interesting libcrypto functions, and then dlopen the wrapper
instead of the shared library.
But then I notice that attic already contains some extensions modules
written in Cython, so surely rewritting crypto.py and xattr.py in Cython
shouldn't be a big deal? :-)
--
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/20140207111203.ga7...@jwilk.net
Re: Indeed, python-concurrent.futures is the same
* Vincent Bernat ber...@debian.org, 2014-01-31, 08:20: Sandro has orphaned python-concurrent.futures: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736714 Since it is team maintained, I don't think it really makes sense. Given that he was the only uploader, this makes perfect sense. Should we just close the bug report and remove Sandro from the Uploaders field? No. Policy §5.6.3 reads “if the ‘Maintainer’ control field names a group of people and a shared email address, the ‘Uploaders’ field must be present and must contain at least one human with their personal email address.” -- 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/20140131085508.ga3...@jwilk.net
Re: Multiple copies of timeoutsocket.py in Debian packages
* Olivier Berger olivier.ber...@telecom-sudparis.eu, 2014-01-29, 10:25: Yeah, timeoutsocket.py looks like something that should have died a decade ago. In Python ≥ 2.3 you can set default timeout or a per-socket timeout without help of this library. planet-venus, python-feedvalidator and rawdog already use the proper Python interfaces, and only fall back to timeoutsocket when they are not available: http://sources.debian.net/src/python-feedvalidator/0~svn1022-2/feedvalidator/__init__.py#L8 http://sources.debian.net/src/planet-venus/0~git9de2109-1/planet/spider.py#L378 http://sources.debian.net/src/rawdog/2.13.dfsg.1-1/rawdoglib/feedparser.py#L103 I'm wondering, in similar cases, if there is anything that should be done for these packages, like patching the code to remove the embedded copy and get rid of the import check, since our Python versions in Debian are recent enough ? This would eliminate uncertainty... I would remove the embedded copy from Debian binary packages, and then poke upstream to drop the obsolete code… or maybe things should just be kept in the current state... Maybe that's not worth the worry in general. … but others' laziness may vary. :-P plucker and spikeproxy would have to be ported to the “new” API. I guess that would be worth a bug report, then ? I'm glad you volunteered to file them. ;-) Beware that spikeproxy's copy is slightly modified; see the attached diff. -- Jakub Wilk --- plucker-1.8/parser/python/PyPlucker/helper/timeoutsocket.py 2002-10-10 23:57:45.0 +0200 +++ spkproxy-1.4.8/timeoutsocket.py 2003-04-08 17:22:38.0 +0200 @@ -286,6 +286,8 @@ if self._blocking: r,w,e = select.select([],[sock],[], self._timeout) if not w: +#no raising for me! +return 0 raise Timeout(Send timed out) return sock.send(data, flags) # end send @@ -295,6 +297,8 @@ if self._blocking: r,w,e = select.select([sock], [], [], self._timeout) if not r: +#I don't want to raise anything +return raise Timeout(Recv timed out) return sock.recv(bufsize, flags) # end recv
Re: Multiple copies of timeoutsocket.py in Debian packages
* Olivier Berger olivier.ber...@telecom-sudparis.eu, 2014-01-28, 16:39: A quick search on http://codesearch.debian.net reports many hits for the timeoutsocket.py library. I think it would be better to have a distinct package, then (hence a RFP: #736935). However I don't have a clue whether this is really used by these packages, if multiple versions co-exist, etc. I haven't played with sockets in Python yet. I'm tempted to think that it may even no longer be needed at all, judging from http://bugs.python.org/issue555085 if the feature was added to Python's standard library. Yeah, timeoutsocket.py looks like something that should have died a decade ago. In Python ≥ 2.3 you can set default timeout or a per-socket timeout without help of this library. planet-venus, python-feedvalidator and rawdog already use the proper Python interfaces, and only fall back to timeoutsocket when they are not available: http://sources.debian.net/src/python-feedvalidator/0~svn1022-2/feedvalidator/__init__.py#L8 http://sources.debian.net/src/planet-venus/0~git9de2109-1/planet/spider.py#L378 http://sources.debian.net/src/rawdog/2.13.dfsg.1-1/rawdoglib/feedparser.py#L103 plucker and spikeproxy would have to be ported to the “new” API. -- 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/20140128175053.ga5...@jwilk.net
Re: Set shebang line to default (instead of latest) Python 3 interpreter
* Ben Finney ben+deb...@benfinney.id.au, 2014-01-26, 17:06: How can I convince ‘dh_python3’ to set the shebang to the *default* Python 3 interpreter? dh_python3 --shebang=/usr/bin/python3 (if I recall correctly) -- 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/20140126091920.ga5...@jwilk.net
Re: Set shebang line to default (instead of latest) Python 3 interpreter
* Ben Finney ben+deb...@benfinney.id.au, 2014-01-26, 22:08: How can I convince ‘dh_python3’ to set the shebang to the *default* Python 3 interpreter? dh_python3 --shebang=/usr/bin/python3 (if I recall correctly) Thanks. So the manpage doesn't say, should I add that option for the “build” action? The “install” action? Some other action? Reading the source for ‘dh-python’ isn't very enlightening on this. You normally call dh_python3 in binary* targets. (Not sure if that's what you're asking, though...) The important part is that I need to override the shebang rewrite for only *some* programs, and leave it with the default behaviour for others. Oops, I missed that bit in your original mail. There's --exclude option that looked promising to me, but it doesn't seem to have any effect of shebang rewriting. :/ In this case, I think the best you can do is to edit the shebang with sed. Adding this after dh_auto_install should do the trick: sed -i -e '1 s,^#!.*,#!/usr/bin/python3,' $(package_install_bin_dir)/python3-coverage -- 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/20140127002026.ga8...@jwilk.net
Re: Indeed, python-concurrent.futures is the same
* Thomas Goirand z...@debian.org, 2014-01-26, 03:50: - No file shipped into /usr/lib/python2.x/dist-packages (well, 2.7 for Sid, and 2.x if you consider an eventual backport). Now, I'm saying: sorry what? like on your 1st mail. This breaks the package for everybody (and not only my case). It has always worked for me. Now what? -- 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/20140125202944.ga18...@jwilk.net
Re: Indeed, python-concurrent.futures is the same
* Thomas Goirand z...@debian.org, 2014-01-26, 04:53: - No file shipped into /usr/lib/python2.x/dist-packages (well, 2.7 for Sid, and 2.x if you consider an eventual backport). Now, I'm saying: sorry what? like on your 1st mail. This breaks the package for everybody (and not only my case). It has always worked for me. Now what? Now, try this: zigo@host # sudo dpkg -i python-concurrent.futures_2.1.6-1_all.deb (Reading database ... 108371 files and directories currently installed.) Preparing to unpack python-concurrent.futures_2.1.6-1_all.deb ... Unpacking python-concurrent.futures (2.1.6-1) over (2.1.6-1) ... Setting up python-concurrent.futures (2.1.6-1) ... Processing triggers for python-support (1.0.15) ... zigo@host # python Python 2.7.6 (default, Jan 11 2014, 14:34:26) [GCC 4.8.2] on linux2 Type help, copyright, credits or license for more information. import futures Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named futures The futures module is deprecated upstream, and provided upstream only for backwards compatibility: $ PYTHONWARNINGS=d python -c 'import futures' /usr/lib/python2.7/dist-packages/futures/__init__.py:24: DeprecationWarning: The futures package has been deprecated. Use the concurrent.futures package instead. DeprecationWarning) Surely you must have become aware of this fact when you removed the 10_dont_install_futures patch. Not shipping a deprecated and generically-named module, when there were no reverse-dependencies relying on its existence, sounds like a reasonable decision. I'm however confused how import concurrent works, even if there's nothing in /usr/lib/python2.7/dist-packages in this package. How come? That's how python-support works. -- 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/20140125214722.ga21...@jwilk.net
Re: usr/bin/ scripts for console_scripts which lead to binaries-have-file-conflict when python 2 + 3
* Olivier Berger olivier.ber...@telecom-sudparis.eu, 2013-12-16, 13:24: - add a python-rdflib-tools package that contains shell scripts of the form : #!/bin/sh exec /usr/bin/python -m rdflib.tools.csv2rdf $* I can't see how that's better than a script with #!/usr/bin/python shebang... - make this package depend on python-rdflib | python3-rdflib /usr/bin/python can't use the modules shipped by python3-rdflib. -- 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/20131216124159.ga5...@jwilk.net
Re: [Debian-med-packaging] Review and sponsoring request: pymia (Python module)
* Gert Wollny gw.foss...@gmail.com, 2013-12-10, 18:22:
Vcs-Browser: http://anonscm.debian.org/?p=debian-med/pymia.git;a=summary
Vcs-Git: git://anonscm.debian.org/debian-med/pymia.git
I had a 5-seconds look at the source package:
Typo in the package description: apropriate - appropriate
python3-mia(-dbg) should use ${python3:Depends} (NOT ${python:Depends}).
Build-dependency on pkg-config appears to be missing.
--
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/20131211134515.ga7...@jwilk.net
Disappearing egg-info
egg-info for distribute and pil has disappeared recently. But there are existing packages referencing these projects names in their requires.txt: glue-sprite_0.3-1_all/usr/share/pyshared/glue-0.3.egg-info/requires.txt:PIL==1.1.7 keysync_0.2-2_all/usr/share/pyshared/keysync-0.2.egg-info/requires.txt:PIL python-enable_4.1.0-1_i386/usr/share/pyshared/enable-4.1.0.egg-info/requires.txt:PIL rst2pdf_0.93-1_all/usr/share/pyshared/rst2pdf-0.93.dev.egg-info/requires.txt:PIL trac-odtexport_0.6.0+svn10787-2_all/usr/share/pyshared/OdtExportPlugin-0.6.egg-info/requires.txt:PIL trac-wikiprint_1.9.2-1.1_all/usr/share/pyshared/TracWikiPrintPlugin-1.9.2.egg-info/requires.txt:PIL python-argcomplete_0.5.4-1_all/usr/share/pyshared/argcomplete-0.5.4.egg-info/requires.txt:distribute python3-hamcrest_1.6-3_all/usr/lib/python3/dist-packages/PyHamcrest-1.6.egg-info/requires.txt:distribute pbundler_0.0.4_all/usr/share/pyshared/pbundler-0.0.4.egg-info/requires.txt:distribute python3-stdnum_0.8.1-1_all/usr/lib/python3/dist-packages/python_stdnum-0.8.1.egg-info/requires.txt:distribute python-hamcrest_1.6-3_all/usr/share/pyshared/PyHamcrest-1.6.egg-info/requires.txt:distribute python-stdnum_0.8.1-1_all/usr/share/pyshared/python_stdnum-0.8.1.egg-info/requires.txt:distribute See also bug #731825. -- 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/20131210092304.ga...@jwilk.net
Re: Review and sponsoring request: pymia (Python module)
* Andreas Tille andr...@an3as.eu, 2013-12-10, 13:17:
On Tue, Dec 10, 2013 at 12:41:38PM +0100, Gert Wollny wrote:
[...]
I have one reservation about multi-arch support: Is a python *.so
module considered a shared library in the sense that I should add
Pre-Depends: ${misc:Pre-Depends}?
No, it's not.
(In fact, now that wheezy is released, you don't need to pre-depend on
multi-arch support even when you ship an actual shared library.)
--
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/20131210124453.ga7...@jwilk.net
Re: Recommending get-orig-source for packages ?
* Andreas Tille andr...@an3as.eu, 2013-12-04, 08:43: uscan to grow features for removing files from upstream tarballs, in a declarative way preferably. That's in devscripts git and will be included in the next devscripts version. (see [1]) So now you'll have to audit both d/watch and d/copyright before you can run uscan. *sigh* -- 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/20131204081249.ga9...@jwilk.net
Re: Recommending get-orig-source for packages ?
* Andreas Tille andr...@an3as.eu, 2013-12-04, 10:41: uscan to grow features for removing files from upstream tarballs, in a declarative way preferably. That's in devscripts git and will be included in the next devscripts version. (see [1]) So now you'll have to audit both d/watch and d/copyright before you can run uscan. *sigh* AFAICS they way get_main_source_dir() is currently implemented lets malicious upstream to plant files in their tarball that would cause arbitrary code execution... Well, there was a lenthy discussion, uscan bug, Wiki page trying to summarise everything. The people who contributed did not brought up your (and Paul's concern) and I guess Charles Plessy would have been in favour of using d/upstream. I do not think it is my fault if you did not raised you voice when it was time ... https://lists.debian.org/debian-policy/20130116133513.ga4...@jwilk.net By the way: currently you also have to audit another file in addition to d/watch if you need to exclude some files. Unless you knew in advance that there's nothing to exclude, which was most often the case, and you could guess it just by looking at version. -- 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/20131204103001.ga6...@jwilk.net
Re: Recommending get-orig-source for packages ?
* Charles Plessy ple...@debian.org, 2013-12-04, 19:58: Well, there was a lenthy discussion, uscan bug, Wiki page trying to summarise everything. The people who contributed did not brought up your (and Paul's concern) and I guess Charles Plessy would have been in favour of using d/upstream. I do not think it is my fault if you did not raised you voice when it was time ... https://lists.debian.org/debian-policy/20130116133513.ga4...@jwilk.net (actually https://lists.debian.org/20130116133513.ga4...@jwilk.net) D'oh. Hi Jakub, Debian has what its developers implement. I am sure that if somebody steps up and does the actual work of implementing a better solution and migrating the existing information, Andreas will complain. s/complain/comply/ perhaps? -- 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/20131204111348.ga9...@jwilk.net
Re: Recommending get-orig-source for packages ?
* Olivier Berger olivier.ber...@telecom-sudparis.eu, 2013-12-03, 17:06: Piotr Ożarowski pi...@debian.org writes: if there's working debian/watch file, there's no need to add get-orig-source (and to be honest, I prefer debian/rules without get-orig-source if debian/watch is available) +1 What's your rationale, Piotr ? I'd understand if there was something in debhelper/dh-python that would automatically handle debian/watch, but that's not the case, AFAICT... so, what harm is there to make things explicit It harms everyone who reviews the package. It's impossible to write g-o-s target that is both policy-compliant and easy to understand. I don't want to waste time glaring at extra 10 lines of code only to realize it's a fancy wrapper over uscan. -- 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/20131203164231.ga...@jwilk.net
Re: Some thoughts about py{support,central} - dh_python2 conversion
* Dmitry Shachnev mity...@gmail.com, 2013-11-13, 23:15: sphinxcontrib: pymodules: [python-sphinxcontrib.issuetracker, python-sphinxcontrib.spelling] site-pkgs: [python-sphinxcontrib.actdiag, python-sphinxcontrib-pecanwsme, python-sphinxcontrib.seqdiag, python-sphinxcontrib-programoutput, python-sphinxcontrib.blockdiag, python-sphinxcontrib.nwdiag, python-sphinxcontrib-httpdomain, python-sphinxcontrib.phpdomain] Work-around implemented in python-sphinx. I am currently experimenting¹ with porting sphinx to dh_python2. Do I get it correctly that the workaround should be kept so that dh_pysupport-using packages can integrate using dh_python2-based Sphinx? That's right. -- 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/20131114070317.ga3...@jwilk.net
Re: Some thoughts about py{support,central} - dh_python2 conversion
* Jakub Wilk jw...@debian.org, 2012-05-03, 21:41: 2) Do not skip the Before you begin[0] step. This is very important: if two packages share a namespace, either both or none of them must use python-support. Also, it's not enough just to convert them all to dh_python2: you must make sure (using Breaks or Depends relationships) that you cannot co-install an older python-support-based versions together with dh_python2-based ones. An alternative might be using this trick: http://docs.python.org/library/pkgutil.html#pkgutil.extend_path (Though a convenient place to insert the code might not exist in some cases.) This is what I did in my two packages: http://anonscm.debian.org/viewvc/python-modules/packages/gamera/trunk/debian/patches/namespace-package.diff?revision=21262view=markup http://anonscm.debian.org/viewvc/python-modules/packages/sphinx/trunk/debian/patches/sphinxcontrib_namespace.diff?revision=20343view=markup I set up a page to track this kinds of issues in unstable[2] and testing[3]. Please note that I analyse only package contents, not relationships. The tracker is updated daily. (Any volunteers to file bugs?) (Ping?) The pages moved to: [2] http://people.debian.org/~jwilk/python/namespace/conflicts-unstable.txt [3] http://people.debian.org/~jwilk/python/namespace/conflicts-testing.txt Here's how it looks today: enthought: pymodules: [python-apptools] site-pkgs: [python-enthoughtbase] This is a false-positive, and a weird one. python-apptools ships only one file in the enthought namespace: /usr/share/pyshared/enthought/rst/sphinx_default/jquery.js But there are no symlinks in /usr/lib/python2.X/ to that file, so don't know how's that supposed to work. repoze: pymodules: [python-repoze.who, python-repoze.what-plugins, python-repoze.who-plugins, python-repoze.what, python-repoze.sphinx.autointerface] site-pkgs: [python-repoze.lru, python-repoze.tm2] True positive. If you install one package from the pymodules set and one from the site-pkgs set, the former package doesn't work. python-repoze.who-plugins is in the worst situation, as it transitively depends on python-repoze.lru. twisted: pymodules: [cpushare] site-pkgs: [python-axiom, python-twisted-news, python-twisted-lore, python-twisted-bin, calendarserver, ibid, python-twisted-runner-dbg, python-twisted-names, python-twisted-bin-dbg, python-twisted-words, python-cyclone, graphite-carbon, epoptes, python-twisted-core, python-twisted-web2, python-twisted-web, python-nevow, python-twisted-mail, python-twisted-runner, python-wokkel, python-twisted-conch] cpushare ships (among other things) a twisted plugin that doesn't work. Not a regression; twisted has never used python-support. mysql: pymodules: [python-mysql.connector] site-pkgs: [mysql-utilities] Work-around implemented in mysql-utilities. google: pymodules: [python-protobuf] site-pkgs: [python-google-apputils] True positive. If you install both python-protobuf and python-google-apputils, the former doesn't work. pywcs: pymodules: [python-pywcs] site-pkgs: [python-astropy-legacy] Not co-installable. sphinxcontrib: pymodules: [python-sphinxcontrib.issuetracker, python-sphinxcontrib.spelling] site-pkgs: [python-sphinxcontrib.actdiag, python-sphinxcontrib-pecanwsme, python-sphinxcontrib.seqdiag, python-sphinxcontrib-programoutput, python-sphinxcontrib.blockdiag, python-sphinxcontrib.nwdiag, python-sphinxcontrib-httpdomain, python-sphinxcontrib.phpdomain] Work-around implemented in python-sphinx. cherrypy: pymodules: [python-cherrypy] site-pkgs: [python-cherrypy3] Not co-installable. DD-list of the affected packages is attached. -- Jakub Wilk Bernhard Reiter ock...@raz.or.at python-repoze.sphinx.autointerface (U) Debian Cloud Team cloud-packa...@lists.alioth.debian.org google-apputils-python Debian Python Modules Team python-modules-t...@lists.alioth.debian.org python-apptools python-repoze.lru python-repoze.sphinx.autointerface python-repoze.tm2 python-repoze.what-plugins python-repoze.who-plugins Debian QA Group packa...@qa.debian.org python-repoze.what python-repoze.who Debian Scientific Computing Team pkg-scicomp-de...@lists.alioth.debian.org cpushare Iustin Pop ius...@debian.org protobuf Jan Dittberner ja...@debian.org python-repoze.tm2 (U) Piotr Ożarowski pi...@debian.org python-repoze.what-plugins (U) python-repoze.who-plugins (U) Robert S. Edmonds edmo...@debian.org protobuf (U) Sam Hocevar sam+...@zoy.org cpushare (U) Stefano Zacchiroli z...@debian.org python-repoze.what-plugins (U) python-repoze.who-plugins (U) TANIGUCHI Takaki tak...@debian.org python-repoze.lru (U) Varun Hiremath va...@debian.org python-apptools (U) Vincent Bernat ber...@debian.org google-apputils-python (U)
Re: uninstalling issue of a local Debian package
* Florian Rothmaier froth...@ari.uni-heidelberg.de, 2013-10-27, 18:52: sudo apt-get remove python-gavodachs deletes /usr/share/pyshared/gavo/ and /usr/lib/python2.6/dist-packages/gavo/ . Under /usr/lib/python2.7/dist-packages/gavo/ all symlinks are removed but the byte-compiled modules (.pyc) are still present. [...] You'll find the code in a git repository at http://anonscm.debian.org/gitweb/?p=debian-science/packages/gavodachs.git . My guess is that the culprit is order of commands in prerm: *.pyc are removed first, then the daemon is stopped, which causes recreation of *.pyc. Could you edit debian/prerm, moving the #DEBHELPER# token from line 4 to the end of the file, and see if it helps? As a side note, if the module name is gavo, then the policy-compliant binary package name is python-gavo. -- 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/20131028095755.ga5...@jwilk.net
Re: Using update-alternatives for /usr/bin provided binaries
Apparently two (mostly orthogonal) problems have been squeezed into a single
bug report:
1) Is the name /usr/bin/coverage appropriate?
IMVHO, no, this name is too generic.
2) Can the alternatives mechanism be used to switch between the two
implementations of the coverage command line tool?
* Dmitry Shachnev mity...@gmail.com, 2013-10-15, 10:04:
Though, #726255 still needs a resolution, and I would like to have the view
of other Python module maintainers. Is using update-alternatives the way to
go? Was my commit correct? Is there any other (better) way to do things here?
I agree with Thomas here. Update-alternatives is a good and standard way to do
such things. For example, we use it in sphinx and python-docutils to provide
tools like sphinx-build or rst2html.
True for docutils; however, sphinx doesn't use alternatives, and it doesn't do
so for good reasons.
The alternatives mechanisms is only suitable if both commands are compatible,
i.e. their behavior doesn't vary with Python version. This is the case for
rst2html and friends, but no so much for sphinx-build. The problem is that
sphinx-build can import 3rd-party Python code, which is not necessarily
compatible with both Python 2 and 3.
As I understand it, python{2,3}-coverage are NOT compatible, and therefore they
should NOT use alternatives.
--
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/20131015110353.gb2...@jwilk.net
Re: Using ‘export http_proxy = http://127.0.9.1:9/’ to fail noisily on dependency problems
* Thomas Goirand z...@debian.org, 2013-10-15, 01:47: Unless something changed recently, Debian buildds don't block Internet access. :( I've read multiple times that they do. Could you show a build log where something is downloaded? The only thing I found[0] is a bit old, but here you go: https://buildd.debian.org/status/fetch.php?pkg=python-ethtoolarch=i386ver=0.7-1stamp=1340805337 http://bugs.debian.org/683174 [0] Unfortunately Google doesn't seem to index Debian build logs. :( Perhaps someone wants to implement buildlogsearch.debian.net? -- 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/20131015112525.ga...@jwilk.net
Re: Using update-alternatives for /usr/bin provided binaries
* Dmitry Shachnev mity...@gmail.com, 2013-10-15, 15:14:
As I understand it, python{2,3}-coverage are NOT compatible, and therefore
they should NOT use alternatives.
Can you please explain why they are incompatible for people who never used
them (like me)?
$ echo 'print foo' foo.py
$ python-coverage -x foo.py
foo
With Python 3 implementation, you'll get SyntaxError.
--
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/20131015113503.ga1...@jwilk.net
Re: Using ‘export http_proxy = http://127.0.9.1:9/’ to fail noisily on dependency problems
* Barry Warsaw ba...@debian.org, 2013-10-11, 11:03: The point of this recommendation is so that missing Build-Depends are exposed when you are testing your package builds locally. ACK If you omit them, your package will still properly FTBFS, but only on the buildds. Unless something changed recently, Debian buildds don't block Internet access. :( -- 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/20131014112335.ga3...@jwilk.net
Re: about python-oauth2: CVE-2013-4347
[Disclaimer: I don't know anything about OAuth, or python-oauth2.]
* Paul Wise p...@debian.org, 2013-10-09, 07:41:
On Wed, Oct 9, 2013 at 5:46 AM, Philippe Makowski wrote:
do you think that for fixing that, using
return ''.join(random.choice('abcdefghijklmnopqrstuvwxyz123456789') for i in
xrange(length))
...
would be an acceptable fix ?
No, from the announcement of this issue on oss-sec:
... the Python 'random' documentation clearly states the results are
repeatable ...
http://www.openwall.com/lists/oss-security/2013/09/12/5
Yeah, the oss-sec mail is about using a RNG that is not suitable for
cryptographic purposes. This can be easily fixed by using random.SystemRandom
(which uses /dev/urandom) instead of the random module directly (which has a
Mersenne Twister under the hood).
Confusingly, the mail also points to upstream bug report[0], which is about an
(almost) orthogonal problem. Philippe's fix would make birthday attacks harder.
Note however that make_nonce() and generate_nonce() docstrings say generate
pseudorandom number, so they would have to be updated accordingly.
[0] https://github.com/simplegeo/python-oauth2/issues/9
--
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/20131009064018.ga3...@jwilk.net
Re: How to help with sphinx 1.2?
* Dmitry Shachnev mity...@gmail.com, 2013-09-21, 16:24: Will you sponsor the new package (the package is mature enough for unstable, but let's upload it to experimental until the mentioned fixes are uploaded)? I won't have time to review or sponsor anything in the next few months. Sorry. -- 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/20130923172311.ga5...@jwilk.net
Re: Best practices for data files in /usr/share
On Sat, Sep 21, 2013 at 11:36:05PM +0600, Andrey Rahmatullin wrote: So, what are the best practices for moving data files out of the module directories? This is how we do it in Sphinx: 1) There's only one statement that uses __file__ (thanks, upstream!): http://sources.debian.net/src/sphinx/1.1.3%2Bdfsg-4/sphinx/__init__.py#L21 2) We run tests against source that has this line kept intact. Then we patch the line using sed: http://sources.debian.net/src/sphinx/1.1.3%2Bdfsg-4/debian/rules#L66 -- 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/20130921191149.ga20...@snusmumriken.jwilk.net
Re: [PATCH] Support :any architecture qualifiers for multiarch
* Piotr Ożarowski pi...@debian.org, 2013-09-19, 15:33: any proposals on how to detect packages that import ctypes It's not necessarily only ctypes. (other than parsing sources, please ;) Don't detect anything. Add an option (say, --multiarch-me-harder), so that maintainers can opt-in for :any dependencies. -- 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/20130919150538.ga2...@jwilk.net
Re: [PATCH] Support :any architecture qualifiers for multiarch
Following the “if it didn't happen on a mailing list, it didn't happen”, I repeat here what I said on IRC: 12:26 kwilk So I rebuilt src:python-aalib, and I ended up these Depends: python3:any (= 3.3.2-2~), libaa1. 12:27 kwilk This is wrong; the package only works if the interpreter architecture is the same as libaa1 architecture. 12:27 kwilk Please revert this :any mess. 12:30 kwilk In general, just because a script or a module is pure-Python doesn't mean it doesn't care about interpreter's architecture. 12:30 kwilk And there's no way to determine automatically whether it cares or not. -- 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/20130918162413.ga3...@jwilk.net
Re: [PATCH] Support :any architecture qualifiers for multiarch
* Colin Watson cjwat...@ubuntu.com, 2013-09-16, 15:02: (CCing debian-python in case anyone is wondering what those spurious entries for Python packages in update_excuses.html are about.) I wish I had learned about such changes from this mailing list, not from bug reports against lintian, or from excuses files. Also, did I miss the moment when multi-arch stopped being opt-in and become obligatory? dh-python recently started using this syntax [2], and as a result we're seeing lots of this kind of thing in excuses: i18nspector/i386 unsatisfiable Depends: python3:any (= 3.2.3-3~) Fun, apt thinks that wheezy's python3 satisfies the dependency, but dpkg disagrees: $ sudo apt-get install -q -t wheezy i18nspector/unstable Reading package lists... Building dependency tree... Reading state information... The following extra packages will be installed: python3 python3-minimal python3-polib Suggested packages: python3-doc python3-tk python-polib-doc The following NEW packages will be installed: i18nspector python3 python3-minimal python3-polib 0 upgraded, 4 newly installed, 0 to remove and 126 not upgraded. Need to get 0 B/136 kB of archives. After this operation, 672 kB of additional disk space will be used. Do you want to continue [Y/n]? y Selecting previously unselected package python3-minimal. (Reading database ... 103055 files and directories currently installed.) Unpacking python3-minimal (from .../python3-minimal_3.2.3-6_all.deb) ... Selecting previously unselected package python3. Unpacking python3 (from .../python3_3.2.3-6_all.deb) ... Selecting previously unselected package python3-polib. Unpacking python3-polib (from .../python3-polib_1.0.0-2_all.deb) ... Selecting previously unselected package i18nspector. Unpacking i18nspector (from .../i18nspector_0.13-1_all.deb) ... Processing triggers for man-db ... Setting up python3-minimal (3.2.3-6) ... Setting up python3 (3.2.3-6) ... running python rtupdate hooks for python3.2... running python post-rtupdate hooks for python3.2... Setting up python3-polib (1.0.0-2) ... dpkg: dependency problems prevent configuration of i18nspector: i18nspector depends on python3:any (= 3.2.3-3~). dpkg: error processing i18nspector (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: i18nspector E: Sub-process /usr/bin/dpkg returned an error code (1) -- 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/20130917153638.ga3...@jwilk.net
Re: How to help with sphinx 1.2?
* Dmitry Shachnev mity...@gmail.com, 2013-09-14, 13:56: So that is the showstopper? I thought I've seen other Debian packages based on development releases, so I thought maybe b1 would have a chance of making it out of experimental... Yes, I don't like the idea of having beta releases in unstable. I don't like it either. Anyway, here's a list of bugs you might want to fix before uploading Sphinx 1.2 (beta or not) to unstable: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-modules-t...@lists.alioth.debian.org;tag=sphinx1.2 https://bitbucket.org/birkenfeld/sphinx/issue/1185 -- 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/20130916115151.ga6...@jwilk.net
Re: Request to join PMPT
* Andrea Colangelo war...@ubuntu.com, 2013-08-15, 12:45: I have an ITA on python-roman, and I wish to keep maintaining it under the PMPT, so I would like to be accepted as a team member. My account on alioth is warp10-guest. Welcome to the team! I had a look at your existing packages: keymon == python is needed in the clean target, so it should be in Build-Depends, not in Build-Depends-Indep. Are the Python modules shipped by key-mon supposed to be used by other software? If not, please consider moving them to a private directory. get_config_dir() should fallback to ~/.config if XDG_CONFIG_HOME is set but empty. manually_run_dialog() should probably use get_config_dir() instead of hardcoding ~/.config/. woof lintian4python emits: e: woof: string-exception usr/bin/woof:67 e: woof: pyflakes-undefined-name usr/bin/woof:304: RuntimeException w: woof: usr-bin-env-python-shebang usr/bin/woof -- 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/20130912163455.ga4...@jwilk.net
Re: Installing platform-independent resources outside the Python package (was: Specifying ‘--install-data’ for each binary package)
* Ben Finney ben+deb...@benfinney.id.au, 2013-09-09, 13:36:
* Use ‘packagename.links’ to make a symlink for each package to
‘usr/share/packagename/foofile’ at
‘usr/lib/python${PYTHON_VERSION}/dist-packages/${DISTRIBUTION_NAME}/foofile’.
How can you do that without hardcoding Python version?
--
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/20130909112420.ga4...@jwilk.net
Re: Request to join DPMT
* Michael Schutte mi...@debian.org, 2013-07-29, 10:31: I have agreed with Jakub to take over python-docutils and I'm currently preparing the first revision of the 0.11 release. I'd therefore like to be added to the Modules Team. My username on Alioth is michi. Welcome to the team! :-) -- 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/20130802105355.ga4...@jwilk.net
Re: dh-python in unstable
* Julien Cristau julien.cris...@logilab.fr, 2013-08-02, 15:56: So it will rename stuff or not based on the Build-Depends field? That seems... wrong. Worse, it doesn't even try to parse Build-Depends. The relevant logic appears to be: if [ -f /usr/share/dh-python/dh_python2 ] \ grep -q dh-python ./debian/control 2/dev/null then exec /usr/share/dh-python/dh_python2 $@ else exec /usr/share/python/dh_python2 $@ fi -- 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/20130802142400.ga3...@jwilk.net
Re: django-ajax-selects
* Brian May br...@microcomaustralia.com.au, 2013-07-30, 16:15: The package name is incorrect. Per the python policy, the binary name should be python-ajax-select. That's the module name. Really? I thought it was based on the package name. So I guess this means I got my other package, already uploaded to Debian, wrong: python-django-filter instead of python-django-filters :-(. .oO( http://lists.debian.org/20130608225655.ga5...@jwilk.net ) -- 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/20130801122556.ga6...@jwilk.net
Re: django-ajax-selects
* Brian May br...@microcomaustralia.com.au, 2013-07-28, 16:13: Could I please get somebody to check the new version of my package before I upload to Debian? svn+ssh:// svn.debian.org/svn/python-modules/packages/django-ajax-selects/trunk http://anonscm.debian.org/viewvc/python-modules/packages/django-ajax-selects/trunk/ The changelog reads: * Replace debian/pycompat with X-Python-Version. This suggest that d/pycompat and XPV that the same (or similar) purpose. But this is not the case. I would rewrite it as: * Drop debian/pycompat. * Add X-Python-Version. lintian4python emits: w: django-ajax-selects source: missing-vcs-field vcs-svn svn://anonscm.debian.org/python-modules/packages/django-ajax-selects/trunk/ w: django-ajax-selects source: missing-vcs-field vcs-browser http://anonscm.debian.org/viewvc/python-modules/packages/django-ajax-selects/trunk/ x: python-django-ajax-selects: incorrect-package-name python-ajax-select -- 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/20130728174224.gc6...@jwilk.net
Re: Request to join Project Python Modules Packaging Team
* Nicolas Delvaux cont...@nicolas-delvaux.org, 2013-06-28, 12:13: I'm willing to maintain the new scandir package[1] in Debian, with the DPMT team if you think this is relevant. You can see in my QA page[2] that I already maintain a package in Debian and Ubuntu since some time now, so I'm familiar with the process. I use a lot of Python packages for my pet projects but also at work. Because of this, I may propose more packages in the future and also help to backport some. In the long run, my personal goal is to become a DD :-) Welcome to the team! :) -- 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/20130628161826.ga5...@jwilk.net
Re: Requesting non -guest account on Alioth
* Barry Warsaw ba...@debian.org, 2013-06-28, 11:46: Could the project admins for DPMT and PAPT please add my non-guest account? Done for DPMT. -- 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/20130628190832.ga1...@jwilk.net
Re: Introducing myself
* Etienne Millon etienne.mil...@gmail.com, 2013-06-23, 14:57: What is the preferred method: update the TODO page[2], post a RFS on the list, I prefer e-mails, but I don't sponsor much, and other sponsors/reviewers preferences may vary. or just set the suite to unstable in SVN? I don't think that would help finding a sponsor. -- 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/20130623172153.ga6...@jwilk.net
Re: Request to Join Project Python Modules Packaging Team from Mike Neish (neishm-guest)
* Sandro Tosi mo...@debian.org, 2013-06-21, 08:37: Sandro, are you okay with me adding Mike to the team, so the he can commit the patch? sorry for the late reply; sure go ahead, Welcome to the team, Mike! :) does Mike need a sponsor for the upload? I believe he does. -- 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/20130621095903.ga5...@jwilk.net
Re: Request to Join Project Python Modules Packaging Team from Mike Neish (neishm-guest)
* Mike Neish nei...@atmosp.physics.utoronto.ca, 2013-06-21, 14:33: I have the patch ready to commit, but I don't have permission to write directly into the repository (I think it's because I'm not in the 'scm_python-modules' group on the server). You are in this group as far as I can tell: $ ssh svn.debian.org getent group scm_python-modules | tr , '\n' | grep neishm neishm-guest Please make sure you're using the correct host (svn.debian.org, NOT alioth.debian.org; the latter has only read-only copies of the repositories). Maybe this is where I need to find a sponsor for the patch? :) No, you need a sponsor only to upload the package to the archive. I haven't touched debian/changelog, though. There's already an unreleased version (2.2.6.7-2) by Jakub, so I wasn't sure whether to (A) Append my change to that entry, (B) Create a new (also unreleased) entry under 2.2.6.7-3, or (C) Let the maintainers edit and sign off on the changelog. (A') Use dch(1), which should do the right thing. :) -- 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/20130621202843.ga4...@jwilk.net
Re: Request to Join Project Python Modules Packaging Team from Mike Neish (neishm-guest)
* Mike Neish nei...@atmosp.physics.utoronto.ca, 2013-06-21, 16:50: I had followed the instructions for developers on the Python Modules alioth page (https://alioth.debian.org/scm/?group_id=30714), which pointed me to the alioth.debian.org server. Looks like misconfiguration on Alioth side. I'll poke Alioth admins to get it fixed. I used dch -a to append my change into the existing changelog. Hopefully that's doing the right thing. Yup, the changelog looks good to me. -- 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/20130621222503.ga2...@jwilk.net
Re: Recommend package not yet in Debian
* B. Clausius ba...@gmx.de, 2013-06-18, 20:09: 1. Just Recommends: python3-pyicu and rely the package is coming sometime I've been doing this for my packages (with s/pyicu/$somethingelse/ of course). 2. Recommends: python3-pyicu and target experimental This should work, too. 3. This way: http://raphaelhertzog.com/2010/09/27/different-dependencies-between-debian-and-ubuntu-but-common-source-package/ I don't see how is that better that 1 or 2. It hides the problem rather than fixing it. 4. ??? Ping the maintainer? #671361 -- 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/20130618183149.ga6...@jwilk.net
Re: Recommend package not yet in Debian
* Jakub Wilk jw...@debian.org, 2013-06-18, 20:31: 1. Just Recommends: python3-pyicu and rely the package is coming sometime I've been doing this for my packages (with s/pyicu/$somethingelse/ of course). Though that works only if you can predict the package name. And I believe the Ubuntu's choice of package name is wrong: http://bugs.debian.org/671361#21 -- 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/20130618184500.ga7...@jwilk.net
Re: how could I help?
* Stéphane Blondon stephane.blon...@gmail.com, 2013-06-15, 12:40: I want to change my way of contributing to Debian. I wonder if I could help the debian-python. Some ideas: * Adopt a package: http://wnpp-by-tags.alioth.debian.org/tags/implemented-in/python.html (But note that maintaining packages you don't use is usually a bad idea!) * Provide patches for these bugs: http://udd.debian.org/cgi-bin/python_bugs.cgi (Not necessarily all of them at once. ;P) -- 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/20130618220630.ga4...@jwilk.net
Re: Introducing myself
* Etienne Millon etienne.mil...@gmail.com, 2013-06-14, 15:37: I recently offered to help Carlos Galisteo with feedparser (a dependency of rss2email which I maintain), and he proposed me to take care of the package within the DPMT (see #664199 and #711916). I had a look at the NMU you proposed: Did you mean Convert to dh instead of Convert to dh_python2? The package in unstable already uses dh_python2... But anyway, changing the packaging style in NMUs is discouraged (DevRef §5.11.1). Now that you're going to become a (co-)maintainer, you can of course make any changes you want, so I'm mentioning it here only as word of advice for the future. :) Right now I've sent a request to join the team on alioth (login: emillon-guest) Welcome to the team! -- 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/20130614170034.gb1...@jwilk.net
Re: Request to Join Project Python Modules Packaging Team from Mike Neish (neishm-guest)
* Mike Neish nei...@atmosp.physics.utoronto.ca, 2013-06-10, 18:15: I would like to join the Python Modules Packaging Team in order to apply a patch for the pydap package (bug 709376). I reproduced the bug, and the patch looks uncontroversial too me. (Although admittedly I didn't check if it actually fixes the problem.) I would normally insist that the patch is forwarded (and, ideally, accepted) upstream first, but AFAICS upstream has changed the build system in the mean time, with the side effect that dap ends up in namespace_packages.txt as it should. (So effectively the bug is fixed upstream in Pydap 3.1.) Sandro, are you okay with me adding Mike to the team, so the he can commit the patch? -- 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/20130614175207.ga7...@jwilk.net
Re: Taking over SQLObject package?
* Stefano Rivera stefa...@debian.org, 2013-06-09, 20:01: Hi Neil (2013.06.05_11:17:13_+0200) Since I'm responsible for the last NMU, and have a decent relationship with upstream, would anyone object to me taking over the debian package? The team policy [0] allows it, and I wouldn't object to you adding yourself to Uploaders. [...] I suggest starting to work on it in SVN immediately, I've added Neil Muller to the team. Welcome! -- 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/20130614180552.ga8...@jwilk.net
Re: RFS: python-keyring 1.4-1
(I don't intend to sponsor this package.) * Dmitry Shachnev mity...@gmail.com, 2013-06-08, 15:06: * Run upstream testsuite during build; Typo in the variable name: $(PYTHON) - $(PYTHON2). Also, python2.X -m unittest discover works only for X=7. -- 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/20130609170301.ga1...@jwilk.net
Re: Obsolete Conflits/Replaces: python2.3-MODULE, python2.4-MODULE
* Jakub Wilk jw...@debian.org, 2013-06-05, 00:55: Would anyone mind if I made a mass-commit to drop them from the packages (co-)maintained by DPMT? Done! (With the exception of python-reportlab, which hasn't seen VCS updates since 2008, despite numerous uploads.) -- 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/20130608162947.ga6...@jwilk.net
Re: Joining Python Modules Packaging Team
* Brian May br...@microcomaustralia.com.au, 2013-06-07, 12:00: I currently am the maintainer of the following packages: django-tables django-filters django-ajax-selects Plus a number of other packages that are not yet available in Debian. My Alioth login is bam. Welcome to the team! (Yes, I have been told that those package names should be prefixed with python- to be policy compliant Yup, policy-complaint binary package names should be: python-django-tables2 python-django-filters python-ajax-select Source package names can of course stay as they are. - just one of the things that needs fixing) Speaking of which, django-ajax-selects debian/rules does this: cp -r ajax_select/static debian/django-ajax-selects/usr/share/pyshared/ajax_select /usr/share/pyshared is an implementation detail of Python helpers; you should not rely on its existence. (In fact, now that we support only one Python version, I hope we get rid of it soon.) -- 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/20130608225655.ga5...@jwilk.net
Re: RFS: bunch, kitchen, grapefruit, fabulous, stomper, txws, txzmq, moksha.common, moksha.hub
* Simon Chopin chopin.si...@gmail.com, 2013-06-06, 14:19:
fabulous/fonts/cmr10.ttf license doesn't look free to me.
I've removed all the fonts from the tarball since their license wasn't
specified anyway — I had to go look in other packages to find them. I
guess the FTP masters disagree with you on the license though, as one
can find this font at least in fonts-lyx.
I wouldn't assume that just because something is in main, it's
necessarily blessed by ftp-masters. Two reasons:
1) mistakes happen;
2) not every upload goes through NEW.
I don't see a point of making fabulous-xtermspeedup a separate
package. It's tiny, and doesn't bring any extra dependencies.
Yes, but it's arch:any whereas the rest is arch:all.
That would be a valid reason to keep them separated _if_ the arch:all
package were big. But it's tiny, too.
The package FTBFS when I build only arch-dependent packages:
|dh_sphinxdoc -a
| dh_sphinxdoc: Sphinx documentation not found
| make: *** [binary-arch] Error 2
Shouldn't dh_sphinxdoc -a be a NOP?
In general case, no: it's possible that the documentation is included in
an arch:any package.
In this case: maybe. Here's an excerpt from #debian-mentors from a few
days ago on this subject:
helmut jwilk: while working on doxygen, a question on --with
sphinxdoc appeared. maybe you have an answer: as far as I can see the
sequence causes dh_sphinxdoc to be executed on all builds, but it fails
when it does not find any sphinx documentation. does this work when the
docs reside in arch:all packages and building arch-only?
[...]
jwilk helmut: It doesn't.
[...]
jwilk The alternative is to do nothing if you don't find docs. (I'm
not saying I like this idea.)
jwilk Oh, and at some point I was considering doing this:
http://paste.debian.net/6076
jwilk But since nobody bothered to file a bug about the current
behavior so far, I'm assuming that people are mostly content with it. :P
(The paste has expired since then, so I attached the patch I had in
mind.)
If I were the maintainer, I would remove (with a Debian-specific
patch) this junk from setup.py:
| from ez_setup import use_setuptools
| use_setuptools(version='0.6c11')
I always thought this was only a convoluted way to check for the
version and never bothered to actually look at ez_setup. Now I
understand why you'd remove it, and will do the same from now on.
You could drop the The information above should ... part from the
patch header. :)
lintian4python emits (among others):
x: python-fabulous: except-without-exception-type
usr/share/pyshared/fabulous/logs.py:86
x: python-fabulous: except-without-exception-type
usr/share/pyshared/fabulous/utils.py:95
x: python-fabulous: except-without-exception-type
usr/share/pyshared/fabulous/xterm256.py:104
Patched and reported upstream.
Now it emits:
e: python-fabulous: except-shadows-builtin
usr/share/pyshared/fabulous/xterm256.py:104: AssertionError
--
Jakub Wilk
Index: debian/control
===
--- debian/control (revision 18535)
+++ debian/control (working copy)
@@ -20,6 +20,7 @@
${sphinxdoc:Depends}, libjs-sphinxdoc (= ${source:Version})
Recommends: python (= 2.6) | python-simplejson, python-imaging
Suggests: jsmath
+Breaks: debhelper ( 7.3.16~)
Description: tool for producing documentation for Python projects
Sphinx is a tool for producing documentation for Python projects, using
reStructuredText as markup language.
Index: debian/changelog
===
--- debian/changelog (revision 18552)
+++ debian/changelog (working copy)
@@ -2,8 +2,11 @@
* Export PYTHONWARNINGS=d in debian/rules to enable all warnings in Python
code.
+ * dh_sphinxdoc: when run via the dh addon and acting on a strict subset of
+all binary packages, don't fail if no documentation was found.
++ This feature requires debhelper 7.3.16, add Breaks for older versions.
- -- Jakub Wilk jw...@debian.org Thu, 15 Sep 2011 18:48:37 +0200
+ -- Jakub Wilk jw...@debian.org Sat, 17 Sep 2011 14:07:34 +0200
sphinx (1.0.7+dfsg-2) unstable; urgency=low
Index: debian/dh-sphinxdoc/dh_sphinxdoc
===
--- debian/dh-sphinxdoc/dh_sphinxdoc (revision 18535)
+++ debian/dh-sphinxdoc/dh_sphinxdoc (working copy)
@@ -306,8 +306,11 @@
return 1;
}
-init();
+init(options = { dh = \$dh{FLAG_DH} });
+my $all_packages = @{$dh{DOPACKAGES}} == getpackages();
+my $mercy_mode = $dh{FLAG_DH} $all_packages;
+
load_packaged_js();
my @paths = @ARGV;
@@ -340,7 +343,7 @@
}, $pkgpath);
}
}
-if ($done == 0)
+if ($done == 0 and not $mercy_mode)
{
my $message = 'Sphinx documentation not found';
$message .= at $path if defined $path;
Index: debian/dh-sphinxdoc/sphinxdoc.pm
===
--- debian/dh
Re: python3.3 status
* Scott Kitterman deb...@kitterman.com, 2013-06-06, 12:46: mpi4py, pyepr, pystemmer, python-llfuse, python-scipy, and python-astropy all needed a fixed cython, which is now available. pyepr builds successfully, but puts dbg extensions into wrong package: #708011 python-scipy FTBFS with new Cython: #707315 python-astropy needs fixed Numpy mpi4py, pystemmer, python-llfuse are OK -- 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/20130606170405.gb6...@jwilk.net
Re: python3.3 status
* Scott Kitterman deb...@kitterman.com, 2013-06-06, 12:46: Did anyone file bugs for jwilk's FTBFS TODO packages? I've file them all, with one exception: I couldn't reproduce nuitka's FTBFS in a different build environment. -- 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/20130606204443.ga8...@jwilk.net
Obsolete Conflits/Replaces: python2.3-MODULE, python2.4-MODULE
Quite a few packages carry Conflicts or Replaces with python2.4-MODULE or python2.3-MODULE or sometimes even pythonX.Y-MODULE for X.Y 2.3. Not only such packages are long gone, but it's very unlikely that the file conflict that was the reason to add these Conflict/Replaces actually still occur. Please consider dropping these obsolete relations from your packages. Would anyone mind if I made a mass-commit to drop them from the packages (co-)maintained by DPMT? -- Jakub Wilk A Mennucc1 mennu...@debian.org pygame (U) Alain Leufroy alain.leuf...@logilab.fr xmldiff (U) Alexander Wirt formo...@debian.org eyed3 rrdtool (U) Alexandre Fayolle afayo...@debian.org xmldiff Alexandre Fayolle alexandre.fayo...@logilab.fr xmldiff (U) Alexey Nezhdanov snak...@users.sourceforge.net python-xmpp Ana Beatriz Guerrero Lopez a...@debian.org empy Andreas Rottmann ro...@debian.org python-crypto (U) Andreas Tille ti...@debian.org python-biopython (U) Barry Warsaw ba...@python.org python-mode Bernd Zeimetz b...@debian.org fpconst (U) python-soappy (U) pyxmpp (U) rrdtool (U) zsi (U) Brian Sutherland ji...@web.de python-tcpwrap Calendarserver Maintainers calendarserver-maintain...@lists.alioth.debian.org pykerberos Charles Plessy ple...@debian.org python-biopython (U) Chow Loong Jin hyper...@debian.org libgpod (U) Christoph Haas h...@debian.org python-iplib Cosimo Alfarano ka...@debian.org jabber.py python-xmpp (U) David Gil d...@telefonica.net python-adodb Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org gamin (U) pyorbit (U) Debian Hamradio Maintainers debian-h...@lists.debian.org hamlib Debian Med Packaging Team debian-med-packag...@lists.alioth.debian.org python-biopython Debian Python Modules Team python-modules-t...@lists.alioth.debian.org cherrypy3 (U) elementtidy forgethtml forgetsql fpconst ldaptor nevow (U) pycxx python-adns python-biggles (U) python-cherrypy (U) python-crypto (U) python-dhm python-goopy python-htmltmpl (U) python-mysqldb python-pychart (U) python-reportlab (U) python-soappy python-xlib pyvtk (U) pyxmpp quixote quixote1 templayer zsi Debian QA Group packa...@qa.debian.org pygresql pythoncard slides tix twisted-web2 Debian RRDtool Team rrdt...@ml.snow-crash.org rrdtool Debian Science Team debian-science-maintain...@lists.alioth.debian.org opencv Deepak Tripathi apenguinli...@gmail.com python-biggles Dima Barsky d...@debian.org python-pam Dirk Eddelbuettel e...@debian.org rpy Ed Boraas e...@debian.org pygame Emile Anclin emile.anc...@logilab.fr xmldiff (U) Emilio Pozuelo Monfort po...@debian.org gamin (U) ExpPsy Maintainers pkg-exppsy-maintain...@lists.alioth.debian.org pyode Fabian Fagerholm fa...@debian.org albatross Frederic Peters fpet...@debian.org lasso Free Ekanayaka fr...@debian.org twisted (U) twisted-conch (U) twisted-lore (U) twisted-mail (U) twisted-names (U) twisted-news (U) twisted-runner (U) twisted-web (U) twisted-words (U) Ghe Rivero g...@debian.org libuser gtkpod Maintainers pkg-gtkpod-de...@lists.alioth.debian.org libgpod Guido Günther a...@sigxcpu.org pykerberos (U) Gustavo Noronha Silva k...@debian.org cherrypy3 python-cherrypy Henry Velez henry.deb...@gmail.com pysvn Ian Ward i...@excess.org templayer (U) Igor Stroh jen...@debian.org python-reportlab (U) Jaime Robles ja...@debian.org hamlib (U) Jamie Wilkinson j...@debian.org pymad Jan Dittberner ja...@debian.org ldaptor (U) python-adns (U) Javier Fernandez-Sanguino Pen~a j...@computer.org python-adodb (U) Jesus Climent jesus.clim...@hispalinux.es clearsilver Joel Rosdahl j...@debian.org egenix-mx-base python-apsw python-pysqlite1.1 python-pysqlite2 python-sqlite Jonas Meurer m...@debian.org python-mysqldb (U) Jonas Smedegaard d...@jones.dk pygdchart2 Josselin Mouette j...@debian.org pyorbit (U) Julian Taylor jtaylor.deb...@googlemail.com pycxx (U) Kamal Mostafa ka...@whence.com hamlib (U) Kenneth J. Pronovici prono...@debian.org epydoc Kevin Coyner kcoy...@debian.org htmlgen Kumar Appaiah aku...@debian.org python-goopy (U) Lars Kruse de...@sumpfralle.de clearsilver (U) Loic Dachary (OuoU) l...@debian.org poker-engine pypoker-eval Loic Minier l...@dooz.org dbus-python (U) gamin (U) gst0.10-python (U) pyorbit (U) rpm (U) Luca Falavigna dktrkr...@debian.org pyorbit (U) Maintainers of GStreamer packages pkg-gstreamer-maintain...@lists.alioth.debian.org gst0.10-python Martin Pitt mp...@debian.org gamin (U) Matej Vela v...@debian.org python-ldap Matthias Klose d...@debian.org distribute gadfly lxml python-reportlab python-stdlib-extensions twisted twisted-conch twisted-lore
Re: Use the just installed package in the postinst script
* Cornelius Kölbel cornelius.koel...@lsexperts.de, 2013-05-27, 17:30: Although I am calling a update-python-modules in the postinst, the package is not available, yet. Do you have any tricks for this scenario? If you're using python-support, you want to read its README, section Namespace packages. -- 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/20130527192518.ga4...@jwilk.net
Re: Joining DPMT / PAPT
* Geoffrey Thomas geo...@ldpreload.com, 2013-05-26, 11:40: P: python-github: no-upstream-changelog P: python3-github: no-upstream-changelog There isn't one. What about doc/changes.rst? :) That said, I thought the eventual goal was to move tests to autopkgtest instead of the build process? Are we sufficiently far away from that reality that today I should still be putting this in the build process? I don't think there was a plan to abandon build-time testing. And anyway, we have currently no QA infrastructure for running DEP-8 tests. The code uses assert to validate types of method arguments. That's not what assert is for. [...] (These should be converted into TypeErrors, right?) Right. -- 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/20130526190004.ga8...@jwilk.net
Re: Joining DPMT / PAPT
* Geoffrey Thomas geo...@ldpreload.com, 2013-05-24, 17:41: I'd like to join the Debian Python teams. I have two packages I'd like to package for Debian at the moment -- python-github (ITP #709682) and tratihubis (ITP not filed yet). I'm a DM and have slowly been having more time for Debian-ish stuff, so I expect that there will probably be more packages that I'd like to see in Debian as time passes. I've just submitted a request to join the Alioth DPMT group. Welcome to DPMT! I already asked on IRC, but if folks here have comments on my draft packaging for pygithub (with a python- and python3- split based on ScottK's python-ipaddr packaging), I'd definitely appreciate them: https://ldpreload.com/p/pygithub_1.14.2-1.dsc I don't intend to sponsor this package, but here's my review: Upstream provides documentation. It might be a good idea to build and ship it. Lintian says: I: pygithub source: debian-watch-file-is-missing P: python-github: no-upstream-changelog P: python-github: no-homepage-field P: python3-github: no-upstream-changelog P: python3-github: no-homepage-field I would drop the Provides fields: http://lists.debian.org/debian-python/2011/03/msg00139.html Re override_dh_auto_install: -O0 is no-op when used together with --no-compile. But then, I wouldn't use --no-compile, as is thwarts possibility of spotting byte-compilation errors early. Do tests require Internet connectivity? If no, then it would be good to run them at build time. Typos in upstream code: explicitely - explicitly instanciate - instantiate The code uses assert to validate types of method arguments. That's not what assert is for. Does pygithub validate SSL certificates? -- 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/20130525115652.ga1...@jwilk.net
Re: Joining DPMT / PAPT
* Jakub Wilk jw...@debian.org, 2013-05-25, 13:56: https://ldpreload.com/p/pygithub_1.14.2-1.dsc I don't intend to sponsor this package, but here's my review: One more thing I forgot: Don't ignore errors from rm -rf build. -f takes care of ENOENT and you failures certainly should not go unnoticed. -- 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/20130525120936.ga2...@jwilk.net
Re: Request to Join Project Python Modules Packaging Team from Vincent Cheng (vincentc-guest)
* Vincent Cheng vincentc1...@gmail.com, 2013-05-24, 03:22: I see you overrode image-file-in-usr-lib, but This is where distutils installs everything is a poor excuse. :) Is there any easy workaround for this? Not really. While distutils has an option to install data files to a different directory (--install-data) it doesn't store that location anywhere, so the code has no way of knowing where the data could be. In practice it means that you have to either patch the code that loads the data, or add symlinks pointing from old to new locations. -- 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/20130525214944.gb7...@jwilk.net
Re: pyflakes and Python 3 scripts (was Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz)
* Barry Warsaw ba...@python.org, 2013-05-24, 16:12: Replace the driver (Python) scripts with a shell script Eww! :( Can you elaborate on what you don't like about that? I'd like to at least accurately understand your objections. I want Python scripts to remain Python scripts, so that I can: - run then with non-default Python interpreter easily; - write a wrapper script that execfile()s the original script. -- 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/20130525221351.ga5...@jwilk.net
Re: On robustness of maintainer scripts
* Jakub Wilk jw...@debian.org, 2013-05-10, 00:41: prerm = [...] Real-world failure: #706758 Also #708831. -- 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/20130521120144.ga4...@jwilk.net
Re: On robustness of maintainer scripts
* Matthias Klose d...@debian.org, 2013-05-21, 17:55: The dependency of python2.7-minimal on libpython2.7-minimal looks safe to me, At least in theory, it's not safe. If python2.7-minimal is unpacked, but libpython2.7-minimal is not (yet) unpacked, then all pyclean can do is: Could not find platform independent libraries prefix Consider setting $PYTHONHOME to prefix[:exec_prefix] ImportError: No module named site dpkg: error while cleaning up: subprocess installed post-installation script returned error exit status 1 -- 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/20130521173556.ga5...@jwilk.net
Re: On robustness of maintainer scripts
* Matthias Klose d...@debian.org, 2013-05-21, 17:55: namespace packages aren't an issue anymore in python3, and for python2 it would be better to ship these files into separate binary packages. these aren't that many, and it would be much better for the robustness. nothing to do anymore about these in maintainer scripts. We have about ~60 packages which ship files in /usr/share/python/ns/, which is quite a bit. That said, most of them don't need __init__.py at all, because the namespace would be created at runtime via *-nspkg.pth files. The only namespaces for which appropriate *-nspkg.pth don't exist are: * flaskext (python-flaksext.wtf): flaskext/__init__.py is already shipped by python-flask, so not a problem. * r2 (python-radare2): no other users of the namespace AFAICS, so it could ship __init__.py directly in .deb. * dummy (python-van.pydeb) * zope.app (python-van.pydeb) - these two look like a bug in dh_python2. -- 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/20130521180705.ga8...@jwilk.net
Re: Request to Join Project Python Modules Packaging Team from Vincent Cheng (vincentc-guest)
* Vincent Cheng vincentc1...@gmail.com, 2013-05-18, 01:50:
I'm currently a DM (DDPO profile here [1]), and I'd like to join the
DPMT and PAPT to move some of my self-maintained packages (pygame is
one of them) into team maintainership. Most of my other packages are
also team-maintained (I'd estimate half of my packages to be in the
Debian Games team, in fact).
Welcome to the team!
Here's my review of pygame_1.9.2~pre~r3189-2:
You have python3.2-dev (= 3.2.3-7) in Build-Depends. Could you put
python3.2-dev ( 3.2.3-7) in Build-Conflicts instead? That should
have the same effect, while making it easier to remove python3.2 from
the archive in the future.
What is libjs-sphinxdoc in Depends for? The changelog says Add depends
on libjs-sphinxdoc and replace embedded js libraries with symlinks in
debian/rules, but I don't see anything relevant in debian/rules. But
anyway, should probably put ${sphinxdoc:Depends} in Depends and use
dh_shpinxdoc instead of replacing this stuff manually.
I advocate against using ${python:Provides}:
http://lists.debian.org/20110324164804.ga5...@jwilk.net
It's time to drop Replaces/Conflict with python2.{3,4}-pygame.
“for” loops in debian/rules lack “set -e”; see Policy §4.6.
Please honour DEB_BUILD_OPTIONS=nocheck.
Please run tests with all supported Python versions, not only the
default one.
Is there a reason test failures are ignored?
You might want to try run the tests under xvfb. Hopefully that should
allow running more of them than currently.
You never call setup.py build with python3.X, so building Python 3.X
modules takes place only when you call setup.py install, that is in
binary* targets, with (pseudo)root privileges. This is something your
should avoid.
/usr/share/pyshared/pygame/docs: AFAICS this is the very same
documentation as in /usr/share/doc/python-pygames/. Are two copies
really needed?
/usr/share/pyshared/examples: examples normally belong to
/usr/share/doc/$package/examples/.
Documentation and examples are quite big, and they are included in both
binary packages. Maybe it would make sense to move them to a separate
documentation package?
/usr/share/pyshared/tests: do tests make sense in the binary package? I
wouldn't install them.
/usr/share/pyshared/pygame/LGPL: Lintian should have emitted
extra-license-file.
I see you overrode image-file-in-usr-lib, but This is where distutils
installs everything is a poor excuse. :)
test/test_utils/unittest.py is an embedded copy of stdlib module. Please
make sure it's not used at build time, and that it's not installed into
binary packages.
Please regenerate src/pypm.c from src/pypm.pyx at build time.
docs/reST/ref/code_examples/joystick_calls.py uses print as method
name. You can't do that in Python 2.X (unless you import print_function
from __future__).
--
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/20130519140959.ga8...@jwilk.net
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz
* Barry Warsaw ba...@python.org, 2012-09-28, 10:40: we need to get tools like pyflakes ported to Python 3. pyflakes = 0.6 supports Python 3. There's no Debian package built for Python 3 yet, but that's something that can be kluged up: 1) Install pyflakes_0.6.1-1~exp1 from experimental. 2) Put the attached script somewhere in your $PATH. 3) ... 4) PROFIT!^W^WGrumble that it doesn't work out of the box, and that you need to resort to hacks like this instead. -- Jakub Wilk #!/usr/bin/python3 import sys # Close your eyes here. sys.path += ['/usr/share/pyshared'] from pyflakes.scripts.pyflakes import main del sys.path[-1] # You can open your eyes now. main(sys.argv[1:])
Re: Joining DPMT
* Thomas Preud'homme robo...@debian.org, 2013-05-14, 18:32: About the maintainership of these packages, does your answer mean we can update the maintainer and uploader fields (namely setting Matteo and myself as uploaders and DPMT as maintainer)? Yes. Please see: http://python-modules.alioth.debian.org/python-modules-policy.html#maintainership -- 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/20130514223602.ga3...@jwilk.net
Re: dh9: dh_python2 with dh_sphinxdoc: missing /usr/bin and /usr/lib in deb
* Mathias Behrle mathi...@m9s.biz, 2013-05-13, 20:13: I want to create a separate package tryton-modules-doc from the sphinx documentation contained in tryton-server. The packages are building without error, but in the final deb of the server package (tryton-server) the files for /usr/bin and /usr/lib are missing. Inspecting debian/tryton-server after the build shows still the directory tmp containing those missing files, apparently not being moved to debian/tryton-server/usr. The build log doesn't show anything unusual. Quoting the dh_auto_install(1) manpage: Unless --destdir option is specified, the files are installed into debian/package/ if there is only one binary package. In the multiple binary package case, the files are instead installed into debian/tmp/, and should be moved from there to the appropriate package build directory using dh_install(1). You probably want to instruct dh_install which files belong to which packages, presumably by creating appropriate *.install files. -- 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/20130513182639.ga6...@jwilk.net
Re: On robustness of maintainer scripts
* Jakub Wilk jw...@debian.org, 2013-05-10, 00:41: postinst [...] Test-case (in a squeeze chroot, with wheezy added to sources.lists): # dpkg --unpack cpuset_1.5.6-2_all.deb # apt-get install -t squeeze python2.6 # apt-get install -t wheezy python gcc-4.4 # dpkg --force-depends -r libssl0.9.8 # dpkg -i python-pkg-resources_0.6.24-1_all.deb Blargh, I suck at copyingpasting: g/cpuset/d prerm = [...] Test case (in wheezy chroot): # apt-get install -q python-pkg-resources # dpkg --force-depends -r libssl0.9.8 # dpkg -r python-ipaddr s/wheezy/squeeze/ s/ipaddr/pkgresources/ A different test case (in squeeze chroot): # apt-get install python-pkg-resources # dpkg --unpack --auto-deconfigure python-minimal_2.7.3-4_all.deb # dpkg -r python-pkg-resources -- 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/20130513223139.ga8...@jwilk.net
