Bug#1031300: ITP: sphinx-argparse-cli -- Sphinx extension to render CLI arguments defined by the argparse module
Package: wnpp Severity: wishlist Owner: Faidon Liambotis X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: sphinx-argparse-cli Version : 1.11.0 Upstream Author : Bernát Gábor * URL : https://github.com/tox-dev/sphinx-argparse-cli/ * License : Expat Programming Lang: Python Description : Sphinx extension to render CLI arguments defined by the argparse module sphinx-argparse-cli is an extension for Sphinx to render documentation for command-line interface (CLI) arguments defined by the argparse module. . Unlike the sphinx-argparse module, this module is more capable with regards to CLI interfaces that utilize sub-commands. A notable example is the "tox" project, from which this module originates. The package is trivial, but if anyone is interested in helping maintain it, or with tox's maintenance, you're more than welcome!
Bug#1031298: ITP: pyproject-api -- API to interact with Python pyproject.toml-based projects
Package: wnpp Severity: wishlist Owner: Faidon Liambotis X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: pyproject-api Version : 1.5.0 Upstream Author : Bernát Gábor * URL : https://github.com/tox-dev/pyproject-api * License : Expat Programming Lang: Python Description : API to interact with Python pyproject.toml-based projects pyproject-api aims to abstract away interaction with pyproject.toml style projects in a flexible way. pyproject-api is a new dependency of tox, in the 4.x series, currently slated for experimental. I intend to maintain this package as part of the DPT. The package is trivial, but if anyone is interested in helping maintain it, or with tox's maintenance, you're more than welcome!
Re: cannot allocate memory in static TLS block
Hi Andreas, Thanks for reaching out. It sounds like this is already reported as #951704 (Cc'ed now). I'll need to give this a closer look, but I hope I can have an update within the next couple of weeks. Does this work? Thanks! Faidon On Sun, Mar 15, 2020 at 10:33:20AM +0100, Andreas Tille wrote: > Hi Faidon, > > could you imagine to build jemalloc with --disable-initial-exec-tls > as Sergio suggests below to fix the issue in drmaa (and possibly other > packages)? > > Should I open a separate bug report against jemalloc to request this? > > Kind regards > > Andreas. > > On Sat, Mar 14, 2020 at 05:18:49PM -0400, Sergio Durigan Junior wrote: > > > $ python3 > > > Python 3.7.6 (default, Jan 19 2020, 22:34:52) > > > [GCC 9.2.1 20200117] on linux > > > Type "help", "copyright", "credits" or "license" for more information. > > import drmaa > > > Traceback (most recent call last): > > > File "", line 1, in > > > File > > > "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/__init__.py", > > > line 65, in > > > from .session import JobInfo, JobTemplate, Session > > > File > > > "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/session.py", > > > line 39, in > > > from drmaa.helpers import (adapt_rusage, Attribute, > > > attribute_names_iterator, > > > File > > > "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/helpers.py", > > > line 36, in > > > from drmaa.wrappers import (drmaa_attr_names_t, drmaa_attr_values_t, > > > File > > > "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/wrappers.py", > > > line 58, in > > > _lib = CDLL(libpath, mode=RTLD_GLOBAL) > > > File "/usr/lib/python3.7/ctypes/__init__.py", line 364, in __init__ > > > self._handle = _dlopen(self._name, mode) > > > OSError: /usr/lib/x86_64-linux-gnu/libjemalloc.so.2: cannot allocate > > > memory in static TLS block > > > > This is an issue with jemalloc's handling of the TLS model when being > > dlopened.. See: > > > > https://github.com/jemalloc/jemalloc/issues/1237 > > > > The recommended way to build a libjemalloc that is suitable for being > > dlopened is to use '--disable-initial-exec-tls' when building it. Take > > a look at the INSTALL.md file, and look for this option: > > > > https://github.com/jemalloc/jemalloc/blob/dev/INSTALL.md > > > > There is a way to workaround this bug by doing an LD_PRELOAD of > > libjemalloc when invoking python, but this will only mask the problem > > and we can't expect users to do/know this. > > > > The way I see it, you can try to convince jemalloc's maintainer to > > enable that flag. > > > > BTW, the reason 'find_library' can't find drmaa's library is because the > > .so is being installed in a non-standard directory. I don't know why > > the package was made like this, though. > > > > Thanks, > > > > -- > > Sergio > > GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 > > Please send encrypted e-mail if possible > > http://sergiodj.net/ > > > > -- > http://fam-tille.de >
Request to join the Python team
Hi, I'd like to be added to the Python team Salsa group (either PAPT, DPMT, or both -- see below). My salsa login is "paravoid". I've prepared multiple updates to the "tox" package, including a (much) newer upstream, and I'd like to be able to push those changes and make an upload to Debian. In terms of experience, I maintain a Python package already (python-maxminddb, under collab-maint) and have sponsored other packages in the past that were maintained by DPMT. I'm actually a bit confused on where "tox" belongs -- Maintainer field seems to be set to PAPT, but in salsa it's under python-modules. It could be argued that it belongs in either, as it's a Python application used to develop and test other Python modules and applications... I actually don't really mind, but I would need access to both groups to be able to move it in Salsa. On that note... what is the Maintainer field supposed to be post-Alioth? For DPMT, I see some packages in the archive with Debian Python Modules Team but nothing similar for PAPT. PAPT's page on wiki seems outdated, as is policy.rst on that front. Finally, I've read python-modules policy.rst, and acknowledge that. That said, that policy dictates the use of git-dpm, but Ondřej Nový has already migrated tox to gbp, and I'd rather keep that change. Regards, Faidon
Re: RFS: transifex-client
Janos Guljas wrote: Hi Faidon, Thank you for a review. It is fixed. Uploaded. Regards, Faidon -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d3c8f5f.4060...@debian.org
Re: RFS: transifex-client
Janos Guljas wrote: I would be glad if you reviewed and uploaded this package for me. debian/tx.1: .TP \fB\-\-traceback\fR print full traceback on exceptions .TP \fB\-\-disable\-colors\fR print full traceback on exceptions The second description is probably a mistake. Also, if you haven't already, please contact upstream to push the manpage to the upstream tarballs. Are you sure that the homepage should be indifex.com instead of transifex.org (or .net)? Besides those two, seems OK. Regards, Faidon -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d3c1f33.3000...@debian.org
