Re: conflicting packages python-pysocks and python-socksipy
On January 4, 2016 2:18:22 PM EST, "W. Martin Borgert" wrote: >Hi, > >TLDR: Both are the same, providing the "socks" module. We should >remove one of them. Maybe renaming the other to python-socks. > >Longer story: Recently, I upgraded the outdated python-socksipy >package. This involved following a new upstream. Later I was >informed, that the new upstream was already packaged under the >name python-pysocks. > >Questions: > > - shall we remove one of the package? > (proposal: yes) Yes. Please file the RM bug. > - which of the two packages should be removed from Debian? > (proposal: remove pysocks, just because socksipy is older) Reasonable. Also both maintained by DPMT, so we can just pick. > - shall the other package provide dummy transitional packages? > (proposal: yes) Actually, based on Python Policy both have wrong binary names. The binaries should be python/python3-socks since they provide the socks module. No need to rename the source. I think transitional packages are only needed if there are rdepends that need updating and the can't be done now. > - shall we rename the binary package to python-socks? > (proposal: yes) Definitely. See above. >Any ideas or opinions? Scott K
conflicting packages python-pysocks and python-socksipy
Hi, TLDR: Both are the same, providing the "socks" module. We should remove one of them. Maybe renaming the other to python-socks. Longer story: Recently, I upgraded the outdated python-socksipy package. This involved following a new upstream. Later I was informed, that the new upstream was already packaged under the name python-pysocks. Questions: - shall we remove one of the package? (proposal: yes) - which of the two packages should be removed from Debian? (proposal: remove pysocks, just because socksipy is older) - shall the other package provide dummy transitional packages? (proposal: yes) - shall we rename the binary package to python-socks? (proposal: yes) Any ideas or opinions? TIA & Cheers
Bug#809857: ITP: django-python3-ldap -- Django LDAP user authentication backend
Package: wnpp Severity: wishlist Owner: Michael Fladischer -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: django-python3-ldap Version : 0.9.8 Upstream Author : Dave Hall * URL : https://github.com/etianen/django-python3-ldap * License : BSD-3-clause Programming Lang: Python Description : Django LDAP user authentication backend django-python3-ldap provides a Django LDAP user authentication backend for Python. It uses the pure Python ldap3 library for all LDAP related operations. This makes it easier to deploy instead of solutions that depend on the OpenLDAP library. . It provides the following features: * Authenticate users with an LDAP server. * Sync LDAP users with a local Django database. * Supports custom Django user models. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJWir5fAAoJEGlMre9Rx7W2RZoP/0Hsu71JJnDCDCAzLfjfSFgs xQiojeCit/uDVJSP7i6ItaJhhaZFyqdD7M58/s47kOeGodYsJepoDh5P9xoi2+pe iC+ovEMCLUMSfTWViqqilZuAIfveVbdzBwy+QOD1tnYtL5/mEfvyHxtinIrRpIA4 BTrtQtPgJqy7Ow0BHdyTyU5Epz46Cmxa1lLLmPpr1DiQwd/QIQ6yxbgCdt51Itfq tjcPyeAw37I4QDGKefCfLkjv0ibTtYfKVFeKvTCqJZKtjsJ0j39FuOLoi4W8abZe GoUTXcH1X7d1bDKb8ZAbRZXNR9BukGLLU54JtJdkgvQPck0EcVfqxsyM28FjSdvS f+gcrnbCFYqNCu2D8rcnk5pdPZ9gHoWkWsa6IwfPPCnxqRUrhIebOA7Vq4rhRpAF bFAt3Wk2KMPK20roJNBgv2mi+q9FrSmd5INWLpGdPMq2dNI4774/YpK3nPWSRvHS mY6ocaIaCkzjG0woUR3UQKbPO+9oA5B3DDat6jBhi5zfK4aFcXgLyrygNmGWlZyV rA7/ZV99sdiwZteij49J7cvGgNwYPglgRVCal/afwGLSrayWOCZP3qzKsQAHtNwV Sri+SlmN12WNnZSUl3I0kmFvqy3ppISxulclguqHz5w9SbmStXRN7mPxcYBXAaxC dgKRVG+TjP9kczjfpXJc =/v0T -END PGP SIGNATURE-
Re: Switching Default Python3 To Python3.5
On Dec 31, 2015, at 04:44 AM, Scott Kitterman wrote: >Does anyone object if I go ahead and ask the release team for a transition >slot? +1 and thanks! -Barry
Re: Joining python-modules
On 01/01/16 15:44, Yuri D'Elia wrote: > I've read the policy from > https://python-modules.alioth.debian.org/policy.html and I accept it (in > fact, I love the idea behind collaborative maintenance, collab-maint, > and I subscribed to LowThresholdNmu as well). > > There are three python packages that I'd like to contribute, all three > from pypi: > > - https://pypi.python.org/pypi/python-bond (I'm the author) Anyone?
Re: RFS: twistar (Was: Request to join)
On Jan 04, 2016, at 04:41 AM, Giovanni Pellerano wrote: >i was reading https://lists.debian.org/debian-python/2015/10/msg00267.html >while working on GlobaLeaks (https://github.com/globaleaks/GlobaLeaks) >and evaluate it's adoption as replacement for python-storm that >appears not to be an abandoned software :( I don't know anything about twistar, but I do think Storm is effectively abandoned. I'm not sure twistar is in better shape, given that the last PyPI release is 2013, although there are a few commits to upstream's GitHub in 2015. I think SQLAlchemy or SQLObject are generally considered best-in-breed of the Python ORMs. (FWIW, GNU Mailman 3 core is Python 3 and was ported to SA last year.) >I would support the packaging of twistar for debian; is there stil >lthe possibility if packaged readly to have it in the upcoming debian >stretch/ubuntu xenial? I can't say whether it's worth it or not, but yes, there is probably time to package it up and get it through NEW for stretch and xenial, if you can find a sponsor (I'm not volunteering ;). Cheers, -Barry
