Combined RFS for humanfriendly/2.4-1 [ITP] python-coloredlogs/6.0-1 [ITP] python-verboselogs/1.6-1 [ITP]

2017-04-04 Thread Gaurav Juvekar
Hi,

I've added these three packages to python-modules git repos on alioth. This is 
a combined RFS as these three packages are dependent on each other. Can someone 
please upload them?

Details of each package:

* Package name: python-coloredlogs
  Version : 6.0-1
  Upstream Author : Peter Odding 
* URL : https://coloredlogs.readthedocs.io
* License : Expat
  Section : python
  ITP : #780187
  RFS : #854249
  Binary packages : python-coloredlogs python3-coloredlogs
  Alioth git repo : 
https://anonscm.debian.org/git/python-modules/packages/python-coloredlogs.git
  dget for source : dget -x 
https://mentors.debian.net/debian/pool/main/p/python-coloredlogs/python-coloredlogs_6.0-1.dsc



* Package name: python-verboselogs
  Version : 1.6-1
  Upstream Author : Peter Odding ]
* URL : https://verboselogs.readthedocs.io
* License : Expat
  Section : python
  ITP : #853810
  RFS : #854115
  Binary packages : pypy-verboselog  python-verboselogs python3-verboselogs
  Alioth git repo : 
https://anonscm.debian.org/git/python-modules/packages/python-verboselogs.git
  dget for source : dget -x 
https://mentors.debian.net/debian/pool/main/p/python-verboselogs/python-verboselogs_1.6-1.dsc



* Package name: humanfriendly
  Version : 2.4-1
  Upstream Author : Peter Odding ]
* URL : https://humanfriendly.readthedocs.io
* License : Expat
  Section : python
  ITP : #851824
  RFS : #852233
  Binary packages : humanfriendly python-humanfriendly python3-humanfriendly
  Alioth git repo : 
https://anonscm.debian.org/git/python-modules/packages/humanfriendly.git
  dget for source : dget -x 
https://mentors.debian.net/debian/pool/main/h/humanfriendly/humanfriendly_2.4-1.dsc


-- 
Regards,
Gaurav Juvekar



Re: Packaging ElasticSearch (different version for different server API version)

2017-04-04 Thread Paul Wise
On Wed, Apr 5, 2017 at 3:21 AM, Adam Cécile wrote:

> It's working just fine, and I even think it's a lot saner as I can simply do
> "from elasticsearch5 import ElasticSearch" instead "from elasticsearch2
> import ElasticSearch" to test my code against a new ES5 servers cluster.
> Do you think it's acceptable to "change" upstream behavior like this ?

I think this is a feature that would be best added upstream so that it
can be supported by other distributions too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Packaging ElasticSearch (different version for different server API version)

2017-04-04 Thread Adam Cécile

Hello,


At the moment, python-elasticsearch is only available in version 1.x 
[1], which is pretty useless as it's intended to be used against 
ElasticSearch 1.x servers.


The main problem is that the client is disitributed following multiple 
branches, one for servers running version 1.x, another for version 2.x 
and the last one for 5.x but I really think Debian should provide high 
level Python library for ElasticSearch (next goal is to get the DSL in [3]).


How would you handle that ? For work purpose I created 
python-elasticsearch2 and python3-elasticsearch2 as well as 
python-elasticsearch5 and python3-elasticsearch5.


It's working just fine, and I even think it's a lot saner as I can 
simply do "from elasticsearch5 import ElasticSearch" instead "from 
elasticsearch2 import ElasticSearch" to test my code against a new ES5 
servers cluster.Do you think it's acceptable to "change" upstream 
behavior like this ?


Does it worth an alternative, to provide a default unversionned 
"elasticsearch" module ?



Thanks in advance for your answer,

Best regards, Adam.


[1] https://packages.debian.org/search?keywords=python-elasticsearch

[2] https://elasticsearch-py.readthedocs.io/en/master/#compatibility

[3] https://elasticsearch-dsl.readthedocs.io/



Re: RFS: python-patch 1.16

2017-04-04 Thread Paolo Greppi
Hi Mattia,

It is still in my TODO list to process your detailed feedback to the RFS I sent 
to the mailing list (thanks BTW !).

I think I should manage to do that before May but I'm always happy if anybody 
steps in.

I'll CC the ITP bug as well...

Paolo

Il 04/04/2017 19:31, Mattia Rizzolo ha scritto:
> Hey Paolo, any news of this package?
> (explicitly CCing you to be extra sure it'll reach you)
>
> (And this is why I prefer RFS bugs, btw, saving me from digging in my
> mail archive to find this one…)
> 
> On Thu, Dec 29, 2016 at 06:17:40PM +0100, Mattia Rizzolo wrote:
>> On Tue, Nov 29, 2016 at 08:20:23AM +0100, Paolo Greppi wrote:
>>> Hi,
>>
>> Hi!
>>
>> FYI, I found your RFS only thanks to the /topic in #debian-python.
>> Unless you're very lucky most RFSes sent to random mailing lists have a
>> tendency to get lost/ignored; that's why I suggest you always file a RFS
>> bug and X-Debbugs-CC the relevant team, unless you know that team is
>> going to react (like pkg-js recently).
>>
>>> I packaged python-patch as per this ITP:
>>> https://bugs.debian.org/845482, this is the repo:
>>> https://anonscm.debian.org/cgit/python-modules/packages/python-patch.git
>>>
>>> Please someone more experienced than me review it and if it's OK sponsor
>>> its upload.
>>
>> I fixed the file name in the pristine-tar branch (otherwise `origtargz`
>> ignored it..).
>>
>>> Please note that since the pypi tarball has no tests, whereas the github
>>> tarball has no setup, I choose the latter and added the setup.py with a
>>> git-dpm/quilt patch. I hope this is correct.
>>
>> Yep, that's fine.  Please ask upstream to syncronize both, and have
>> github ship the setup.py, and the tarball the release.
>>
>>
>> more changes I ask you:
>> * d/changelog:
>>   + please kill the second changelog line; first uploads should only
>> come with a "first upload" line
>>   + finalize it (dch -r)
>> * d/control:
>>   + please wrap-and-sort that list of build-deps
>>   + why are you commenting out the Testsuite field?
>>   + Vcs-* are pointing to a repo that's not DPMT's, that's wrong
>> (furthermore that URL first requires auth, and it gave me a 404, so
>> I think it's a private repo)
>> * d/compat:
>>   + please bump to 10 (d/control already have the >= 10, so I guess you
>> just forgot to push this one too)
>> * d/rules:
>>   + please repspect DEB_BUILD_OPTIONS=nocheck
>>   + please use the method provided by pybuild to properly run the tests
>> against all supported python versions, against what you just
>> "built"; I think that one runs only one python version (2.7)
>> against the original sources.
>>   + you're overriding dh_auto_install when you only want to append
>> --install-script to the command invoked.  Please use
>> PYBUILD_INSTALL_ARGS=--install-scripts=... instead.
>> * d/copyright:
>>   + why are you licensing debian/ under a different license?
>>   + personally I find a lot more readable to have all the file paragraph
>> at the top, and all stand alone licenses at the bottom
>>   + other/pack.py is under another license
>> * I: python-patch: new-package-should-not-package-python2-module python-patch
>>   + right, I was about to forget about this...
>> * I: python-patch source: binary-control-field-duplicates-source field 
>> "section" in package python-patch
>>
>> -- 
>> regards,
>> Mattia Rizzolo
>>
>> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
>> more about me:  https://mapreri.org : :'  :
>> Launchpad user: https://launchpad.net/~mapreri  `. `'`
>> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
> 
> 
> 



Re: RFS: python-patch 1.16

2017-04-04 Thread Mattia Rizzolo
Hey Paolo, any news of this package?
(explicitly CCing you to be extra sure it'll reach you)


(And this is why I prefer RFS bugs, btw, saving me from digging in my
mail archive to find this one…)


On Thu, Dec 29, 2016 at 06:17:40PM +0100, Mattia Rizzolo wrote:
> On Tue, Nov 29, 2016 at 08:20:23AM +0100, Paolo Greppi wrote:
> > Hi,
> 
> Hi!
> 
> FYI, I found your RFS only thanks to the /topic in #debian-python.
> Unless you're very lucky most RFSes sent to random mailing lists have a
> tendency to get lost/ignored; that's why I suggest you always file a RFS
> bug and X-Debbugs-CC the relevant team, unless you know that team is
> going to react (like pkg-js recently).
> 
> > I packaged python-patch as per this ITP:
> > https://bugs.debian.org/845482, this is the repo:
> > https://anonscm.debian.org/cgit/python-modules/packages/python-patch.git
> > 
> > Please someone more experienced than me review it and if it's OK sponsor
> > its upload.
> 
> I fixed the file name in the pristine-tar branch (otherwise `origtargz`
> ignored it..).
> 
> > Please note that since the pypi tarball has no tests, whereas the github
> > tarball has no setup, I choose the latter and added the setup.py with a
> > git-dpm/quilt patch. I hope this is correct.
> 
> Yep, that's fine.  Please ask upstream to syncronize both, and have
> github ship the setup.py, and the tarball the release.
> 
> 
> more changes I ask you:
> * d/changelog:
>   + please kill the second changelog line; first uploads should only
> come with a "first upload" line
>   + finalize it (dch -r)
> * d/control:
>   + please wrap-and-sort that list of build-deps
>   + why are you commenting out the Testsuite field?
>   + Vcs-* are pointing to a repo that's not DPMT's, that's wrong
> (furthermore that URL first requires auth, and it gave me a 404, so
> I think it's a private repo)
> * d/compat:
>   + please bump to 10 (d/control already have the >= 10, so I guess you
> just forgot to push this one too)
> * d/rules:
>   + please repspect DEB_BUILD_OPTIONS=nocheck
>   + please use the method provided by pybuild to properly run the tests
> against all supported python versions, against what you just
> "built"; I think that one runs only one python version (2.7)
> against the original sources.
>   + you're overriding dh_auto_install when you only want to append
> --install-script to the command invoked.  Please use
> PYBUILD_INSTALL_ARGS=--install-scripts=... instead.
> * d/copyright:
>   + why are you licensing debian/ under a different license?
>   + personally I find a lot more readable to have all the file paragraph
> at the top, and all stand alone licenses at the bottom
>   + other/pack.py is under another license
> * I: python-patch: new-package-should-not-package-python2-module python-patch
>   + right, I was about to forget about this...
> * I: python-patch source: binary-control-field-duplicates-source field 
> "section" in package python-patch
> 
> -- 
> regards,
> Mattia Rizzolo
> 
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-



-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Join the team

2017-04-04 Thread Adrian Vondendriesch
Hi,

I would like to join the Python-modules team. Within the pkg-postgresql
team we are currently working on pgAdmin4 which has a lot of python
dependencies that are not yet in debian. I'm currently working on these
packages.

My alioth login is discostu-guest.

I've read the python modules policy
(https://python-modules.alioth.debian.org/policy.html) and accept it.

Regards,
 - Adrian



signature.asc
Description: OpenPGP digital signature