Re: Fw: RFS: python-coverage 3.0.1-1
Ben Finney wrote: The changelog entry for ‘debhelper’ 7.3.5 says: * python_distutils buildsystem: Build for all supported Python versions that are installed. Ensure that correct shebangs are created by using `python' first during build and install. Closes: #520834 Also build with python*-dbg if the package build-depends on them. What does it mean “if the package build-depends on them”? If “them” means “debug packages”, why would any non-debug package depend on a debug package? Checking if -dbg interpreters are installed is not enough to decide if you want to buiid with them as you don't necessarily have a clean chroot. So dh needs to look into the build-deps. debian/python-coverage.dirs: * Useless. I can't find where ‘/usr/bin/’ is excluded from requirement to be created; is it in a part of Policy that I've overlooked? There is no need to use a .dirs file if setup.py creates the directory for you. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
License entry in egg info files
Hi, I believe that the following entries are incorrect: /usr/share/pyshared/arista-0.9.1.egg-info:License: UNKNOWN /usr/share/pyshared/cups-1.0.egg-info:License: UNKNOWN /usr/share/pyshared/Django-1.1.1.egg-info:License: UNKNOWN /usr/share/pyshared/git_build_package-0.0.0.egg-info:License: UNKNOWN /usr/share/pyshared/lxml-2.2.2.egg-info:License: UNKNOWN /usr/share/pyshared/miro-2.5.2.egg-info:License: UNKNOWN /usr/share/pyshared/pcapy-0.10.6.egg-info:License: UNKNOWN /usr/share/pyshared/pycrypto-2.0.1.egg-info:License: UNKNOWN /usr/share/pyshared/pyogg-1.3.egg-info:License: UNKNOWN /usr/share/pyshared/python_mpd-0.2.1.egg-info:License: UNKNOWN /usr/share/pyshared/pyvorbis-1.4.egg-info:License: UNKNOWN /usr/share/pyshared/PyXML-0.8.4.egg-info:License: UNKNOWN /usr/share/pyshared/Sonata-1.6.2.1.egg-info:License: UNKNOWN /usr/share/pyshared/spambayes-1.0.4.egg-info:License: UNKNOWN /usr/share/pyshared/tailor-0.9.35.egg-info:License: UNKNOWN I'm too lazy right now to file bugs, but shouldn't we fix this? -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Fw: RFS: python-coverage 3.0.1-1
Bernd Zeimetz be...@bzed.de writes: Ben Finney wrote: I can't find where ‘/usr/bin/’ is excluded from requirement to be created; is it in a part of Policy that I've overlooked? There is no need to use a .dirs file if setup.py creates the directory for you. Gotcha. Okay, removed. The changelog entry for ‘debhelper’ 7.3.5 says: * python_distutils buildsystem: […] Also build with python*-dbg if the package build-depends on them. What does it mean “if the package build-depends on them”? […] Checking if -dbg interpreters are installed is not enough to decide if you want to buiid with them as you don't necessarily have a clean chroot. So dh needs to look into the build-deps. Ah, I see. So this means it will check the ‘Build-Depends’ field for the packages ‘python2.4-dbg’, ‘python2.5-dbg’, or ‘python-all-dbg’; nothing to do with dependencies on ‘foo-dbg’. Right? -- \ “I call him Governor Bush because that's the only political | `\ office he's ever held legally.” —George Carlin, 2008 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Debhelper 7, Python package, multiple binary packages (was: RFS: python-coverage 3.0.1-1)
Ben Finney ben+deb...@benfinney.id.au writes: Once I learn how to make a ‘foo-dbg’ package, I can do that in the next release […] I've learned some about creating a ‘foo-dbg’ package [0]. However, I'm ending up with a source package that installs none of the Python files into any of the binary packages. Can someone point me to an existing package that: * uses ‘debhelper’ vversion 7 or later (i.e. uses the implied-sequence ‘dh’ command instead of explicit lists of ‘dh_foo’ commands) * uses ‘python-support’ * creates multiple packages, preferably including a ‘foo-dbg’ package I can't find any package that does all of those, but can't really do better than guess and manually check source packages with trial and error. [0] URL:http://wiki.debian.org/PkgSplit is really difficult to follow, probably because it needs some love from a fluent English writer. URL:http://www.debian.org/doc/developers-reference/best-pkging-practices.html#multiple-binary ignores using Debhelper 7 to avoid explicit use of ‘setup.py’ or ‘dh_install’. -- \ “Imagine a world without hypothetical situations.” —anonymous | `\ | _o__) | Ben Finney pgp0rsc3mjm0K.pgp Description: PGP signature
Re: License entry in egg info files
W. Martin Borgert deba...@debian.org writes: Hi, I believe that the following entries are incorrect: /usr/share/pyshared/arista-0.9.1.egg-info:License: UNKNOWN /usr/share/pyshared/cups-1.0.egg-info:License: UNKNOWN […] /usr/share/pyshared/spambayes-1.0.4.egg-info:License: UNKNOWN /usr/share/pyshared/tailor-0.9.35.egg-info:License: UNKNOWN I'm too lazy right now to file bugs, but shouldn't we fix this? Currently, Debian policy is (AFAICT) silent on the topic of ‘foo-1.2.3.egg-info’ files. The ‘License’ field does not IMO have any effect on copyright or licenses; only an explicit grant of license could do that, and I don't think that field value would count. So currently I don't think they are bugs of any severity above ‘minor’. There's currently no effective Python policy (the latest one at URL:http://www.debian.org/doc/packaging-manuals/python-policy/ is way out of date with regard to current recommended practice). However, if there *were* to be such a policy, I would expect it to require that the distutils ‘License’ field at least be consistent with ‘debian/copyright’. So, in principle, I think these *should* be bugs. Presumably all these are created by upstream ‘setup.py’ settings, so it would ultimately be for upstream to fix in each case. -- \ “It's up to the masses to distribute [music] however they want | `\… The laws don't matter at that point. People sharing music in | _o__)their bedrooms is the new radio.” —Neil Young, 2008-05-06 | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: License entry in egg info files
* W. Martin Borgert deba...@debian.org, 2009-10-17, 13:23: Hi, I believe that the following entries are incorrect: /usr/share/pyshared/arista-0.9.1.egg-info:License: UNKNOWN [snip] I'm too lazy right now to file bugs It would be better to file a bug against lintian to have a check for such issues. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: License entry in egg info files
Jakub Wilk uba...@users.sf.net writes: * W. Martin Borgert deba...@debian.org, 2009-10-17, 13:23: /usr/share/pyshared/arista-0.9.1.egg-info:License: UNKNOWN It would be better to file a bug against lintian to have a check for such issues. I disagree. This issue in the ‘setup.py’ settings is upstream's responsibility. Lintian is best reserved for reporting problems that are the Debian package maintainer's responsibility. -- \“All opinions are not equal. Some are a very great deal more | `\robust, sophisticated and well supported in logic and argument | _o__) than others.” —Douglas Adams | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: License entry in egg info files
On Sat, Oct 17, 2009 at 9:50 PM, Ben Finney ben+deb...@benfinney.id.au wrote: I disagree. This issue in the ‘setup.py’ settings is upstream's responsibility. Lintian is best reserved for reporting problems that are the Debian package maintainer's responsibility. Do you object to spelling-error-in-binary, duplicated-key-in-desktop-entry, embedded-zlib, duplicate-font-file or the other lintian tests that check upstream stuff? Also, it is the maintainer's responsibility to point out upstream problems to upstream, if lintian can help automatically detect such problems, I think it is a good idea to do so. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debhelper 7, Python package, multiple binary packages (was: RFS: python-coverage 3.0.1-1)
On Sat, Oct 17, 2009 at 11:40:07PM +1100, Ben Finney wrote: Can someone point me to an existing package that: * uses ‘debhelper’ vversion 7 or later (i.e. uses the implied-sequence ‘dh’ command instead of explicit lists of ‘dh_foo’ commands) * uses ‘python-support’ * creates multiple packages, preferably including a ‘foo-dbg’ package IIRC, backintime does all but the -dbg of these things. -- Jonathan Wiltshire 1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: License entry in egg info files
On 2009-10-17 23:59, Ben Finney wrote: So currently I don't think they are bugs of any severity above ‘minor’. I agree, that this is 'minor' or even 'wishlist'. Presumably all these are created by upstream ‘setup.py’ settings, so it would ultimately be for upstream to fix in each case. The maintainer can patch the setup.py file in the meantime or in case upstream does not care. A lintian check sounds like a good idea to me. It's all about package consistency. Fortunately, I forgot my poor Perl knowledge years ago, so somebody else has to write it. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: python-scrapy -- Python web scraping and crawling framework
Dear Python mentors, I am looking for a sponsor for the python-scrapy package * Package name: python-scrapy Version : 0.7-1 Upstream Author : Scrapy developers [1] [2] * URL : http://scrapy.org/ * License : BSD Section : python It builds these binary packages: python-scrapy - Python web scraping and crawling framework python-scrapy-doc - Python web scraping and crawling framework documentation Description: Scrapy is a fast high-level screen scraping and web crawling framework, used to crawl websites and extract structured data from their pages. It can be used for a wide range of purposes, from data mining to monitoring and automated testing. The package appears to be lintian clean. The upload would fix these bugs: 551038 [3] The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/python-scrapy - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/python-scrapy/python-scrapy_0.7-1.dsc I would be glad if someone reviewed/uploaded this package for me. Kind regards Ignace Mouzannar NB: I have already svn-injected the package onto the team's SVN [4]. [1] http://hg.scrapy.org/scrapy/file/fce8f9e2a4f0/LICENSE [2] http://hg.scrapy.org/scrapy/file/fce8f9e2a4f0/AUTHORS [3] http://bugs.debian.org/551038 [4] http://svn.debian.org/viewsvn/python-modules/packages/python-scrapy/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: License entry in egg info files
Paul Wise p...@debian.org writes: Do you object to spelling-error-in-binary, duplicated-key-in-desktop-entry, embedded-zlib, duplicate-font-file or the other lintian tests that check upstream stuff? I think they lead to widely-used, persistent overrides, and I think such overrides are an indicator that the specific check is inappropriate. That said, I freely acknowledge that in this case I can't predict whether that would be the result. Also, it is the maintainer's responsibility to point out upstream problems to upstream, if lintian can help automatically detect such problems, I think it is a good idea to do so. W. Martin Borgert deba...@debian.org writes: The maintainer can patch the setup.py file in the meantime or in case upstream does not care. I don't have a strong objection in this case, and I can see good arguments for and against a Lintian check. I wouldn't put up a fight either way :-) -- \ “I was in a bar the other night, hopping from barstool to | `\ barstool, trying to get lucky, but there wasn't any gum under | _o__) any of them.” —Emo Philips | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: License entry in egg info files
On 2009-10-18 09:46, Ben Finney wrote: I don't have a strong objection in this case, and I can see good arguments for and against a Lintian check. I wouldn't put up a fight either way :-) Me neither, it's certainly one of the least pressing issues we have with Debian Python :~) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debhelper 7, Python package, multiple binary packages
Jonathan Wiltshire deb...@jwiltshire.org.uk writes: On Sat, Oct 17, 2009 at 11:40:07PM +1100, Ben Finney wrote: * uses ‘debhelper’ vversion 7 or later […] * uses ‘python-support’ * creates multiple packages, preferably including a ‘foo-dbg’ package IIRC, backintime does all but the -dbg of these things. Thanks, ‘backintime’ does indeed meet these criteria. The ‘debian/rules’ file is doing some things that I'm confused about: = override_dh_auto_clean: rm -rf locale common/po/*.mo find $(CURDIR) -name *\.py[co] -delete rm -f common/Makefile gnome/Makefile kde4/Makefile = Is it necessary to remove ‘*.py[co]’ files? Wouldn't it be better to call ‘dh_auto_clean’ to do this? = override_dh_pysupport: dh_pysupport /usr/share/backintime/ = Is this necessary? Why can't ‘dh_pysupport’ do this without being overridden here? -- \ “Two possibilities exist: Either we are alone in the Universe | `\ or we are not. Both are equally terrifying.” —Arthur C. Clarke, | _o__) 1999 | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: License entry in egg info files
On Sun, Oct 18, 2009 at 6:46 AM, Ben Finney ben+deb...@benfinney.id.au wrote: Paul Wise p...@debian.org writes: Do you object to spelling-error-in-binary, duplicated-key-in-desktop-entry, embedded-zlib, duplicate-font-file or the other lintian tests that check upstream stuff? I think they lead to widely-used, persistent overrides, and I think such overrides are an indicator that the specific check is inappropriate. Sounds like you have observed people using overrides inappropriately. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
