Re: [RFS] django-oauth-toolkit
> Are you sure that debian/tests/pkg-python/import-name has the correct value? I guess yes. > What does `cat debian/tests/pkg-python/import-name` show? [debian/master][~/packages/oauth-toolkit/django-oauth-toolkit]$ cat debian/tests/pkg-python/import-name oauth2_provider Seems correct. I'm not really sure what is causing this. > Anyways, thanks for your help, I made some minor tweaks and uploaded it a few hours ago. Thanks a lot for sponsoring the upload, :) Could you as well review my changes for pytds[1] that are done here[2]? That would be great. I'm planning to fix more packages in coming days, :) [1]: https://lists.debian.org/debian-python/2020/03/msg00023.html [2]: https://salsa.debian.org/gi-boi-guest/pytds Thanks and regards, Nilesh
Re: [RFS] django-oauth-toolkit
Am 15.03.2020 um 10:54 schrieb Nilesh Patra: autopkgtest [15:10:19]: test autodep8-python3: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import django_oauth_toolkit; print(django_oauth_toolkit)" ; done Are you sure that debian/tests/pkg-python/import-name has the correct value? What does `cat debian/tests/pkg-python/import-name` show? Anyways, thanks for your help, I made some minor tweaks and uploaded it a few hours ago. Cheers, Michael
Re: Re: [RFS] django-oauth-toolkit
> just a quick glance at the commits: you do not need to replace autopkgtest-pkg-python with home-grown code, just tell it what to import: > echo oauth2_provider > debian/tests/pkg-python/import-name Thanks, I didn't know about that. However, when I added that in, autopkgtest seems to fail with: Removing autopkgtest-satdep (0) ... autopkgtest [15:10:19]: test autodep8-python3: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import django_oauth_toolkit; print(django_oauth_toolkit)" ; done autopkgtest [15:10:19]: test autodep8-python3: [--- Testing with python3.7: Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'django_oauth_toolkit' autopkgtest [15:10:19]: test autodep8-python3: ---] autopkgtest [15:10:20]: test autodep8-python3: - - - - - - - - - - results - - - - - - - - - - autodep8-python3 FAIL non-zero exit status 1 autopkgtest [15:10:20]: summary autodep8-python3 FAIL non-zero exit status 1 The command I used: sudo autopkgtest -B ../*.deb -- schroot unstable-amd64-sbuild Am I missing something here? Need your guidance here. Thanks and regards, Nilesh
Re: cannot allocate memory in static TLS block
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
Re: [RFS] django-oauth-toolkit
Hi Nilesh, Am 15.03.2020 um 07:46 schrieb Nilesh Patra: > Needs review and sponsorship. just a quick glance at the commits: you do not need to replace autopkgtest-pkg-python with home-grown code, just tell it what to import: echo oauth2_provider > debian/tests/pkg-python/import-name Cheers, Michael
[RFS] django-oauth-toolkit
Hi, Currently django-oauth-toolkit FTBFS with python3.8. I have fixed it, and build + autopkgtest pass. My changes have been pushed here [1]. Needs review and sponsorship. [1]: https://salsa.debian.org/gi-boi-guest/django-oauth-toolkit Thanks and regards Nilesh
