On Sun, Mar 01, 2015 at 12:48:21PM +0100, Federico Gimenez wrote:
> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
> I am looking for a sponsor for my package "pylama"
>
> * Package name : pylama
> Version : 6.2.0-1
> Upstream Author : Kirill Klenov <horneds@gmail.com>
> * URL : https://github.com/klen/pylama
> * License : LGPL-3
> Section : python
>
> It builds those binary packages:
>
> python-pylama - Code audit tool for Python and JavaScript - Python 2.x
> python3-pylama - Code audit tool for Python and JavaScript - Python 3.x
>
> To access further information about this package, please visit the
> following URL:
>
> http://mentors.debian.net/package/pylama
>
>
> Alternatively, one can download the package with dget using this command:
>
> dget -x
> http://mentors.debian.net/debian/pool/main/p/pylama/pylama_6.2.0-1.dsc
Consider maintaining this in the DPMT (I've seen pylama added to the topic
of #debian-python but we add only team packages there).
You shouldn't use ${shlibs:Depends} for packages without ELF binaries.
As the packages contain public modules it's a bad idea to have py2 and py3
versions conflict with each other. If the modules are usable only by the
pylama app, you should package only the py3 version in some private path
and call the package pylama. If they are usable as python modules
(importable) then either the binaries should have different names or (if
it doesn't matter for the user which version is used) probably only the
py3 version should be packaged.
See also https://www.debian.org/doc/packaging-manuals/python-policy/
The license of debian/* shouldn't be stricter that the upstream license
(though this is debatable I think).
The package contains tests which aren't run by your debian/rules. On a
first glance they are supposed to be run using py.test and pybuild can be
asked to use that.
--
WBR, wRAR
Attachment:
signature.asc
Description: Digital signature