Combined RFS for humanfriendly/2.4-1 [ITP] python-coloredlogs/6.0-1 [ITP] python-verboselogs/1.6-1 [ITP]
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)
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)
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
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
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
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