Re: Status of sqlalchemy
sqlalchemy 2.X currently FTBFS due to a segmentation fault (3.11 and
3.12) somewhere in pysqlite:
[…]
test/orm/inheritance/test_assorted_poly.py::MultiOfTypeContainsEagerTest_joined::test_big_query[not_use_criteria-contains_eager]
PASSED
[ 1%]
test/orm/inheritance/test_assorted_poly.py::MultiOfTypeContainsEagerTest_joined::test_big_query[not_use_criteria-joinedload]
Program received signal SIGSEGV, Segmentation fault.
__strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76
(gdb) bt
#0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76
#1 0x75e7d84b in sqlite3DbStrDup () from
/lib/x86_64-linux-gnu/libsqlite3.so.0
#2 0x75eb3dde in ?? () from /lib/x86_64-linux-gnu/libsqlite3.so.0
#3 0x75edef9c in sqlite3WalkSelect () from
/lib/x86_64-linux-gnu/libsqlite3.so.0
#4 0x75eb2bb5 in ?? () from /lib/x86_64-linux-gnu/libsqlite3.so.0
#5 0x75edef9c in sqlite3WalkSelect () from
/lib/x86_64-linux-gnu/libsqlite3.so.0
#6 0x75eb42fd in sqlite3SelectPrep () from
/lib/x86_64-linux-gnu/libsqlite3.so.0
#7 0x75eb4558 in sqlite3Select () from
/lib/x86_64-linux-gnu/libsqlite3.so.0
#8 0x75e8c24e in sqlite3Parser () from
/lib/x86_64-linux-gnu/libsqlite3.so.0
#9 0x75ebb345 in sqlite3RunParser () from
/lib/x86_64-linux-gnu/libsqlite3.so.0
#10 0x75e93d39 in ?? () from /lib/x86_64-linux-gnu/libsqlite3.so.0
#11 0x75e94aa1 in ?? () from /lib/x86_64-linux-gnu/libsqlite3.so.0
#12 0x75e94eea in sqlite3_prepare_v2 () from
/lib/x86_64-linux-gnu/libsqlite3.so.0
#13 0x767ea3bb in pysqlite_statement_create
(connection=connection@entry=0x7fffef167880, sql=) at
../Modules/_sqlite/statement.c:59
#14 0x767ea111 in pysqlite_connection_call (self=0x7fffef167880,
args=('SELECT unithead.id, employee.id AS id_1, employee.name,
employee.type, manager_1.id AS id_2, employee_1.id AS id_3, employee_1.name AS
name_1, employee_1.type AS type_1 \nFROM employee JOIN unithead ON employee.id
= unithead.id LEFT OUTER JOIN (employee_m2m AS employee_m2m_1 JOIN (employee AS
employee_1 JOIN manager AS manager_1 ON employee_1.id = manager_1.id) ON
employee_1.id = employee_m2m_1."right" AND employee_1.type = ?) ON employee.id
= employee_m2m_1."left"',), kwargs=0x0)
at ../Modules/_sqlite/connection.c:1786
#15 0x00582bb2 in _PyObject_Call (tstate=0xbb04a8 <_PyRuntime+459656>,
callable=,
args=('SELECT unithead.id, employee.id AS id_1, employee.name,
employee.type, manager_1.id AS id_2, employee_1.id AS id_3, employee_1.name AS
name_1, employee_1.type AS type_1 \nFROM employee JOIN unithead ON employee.id
= unithead.id LEFT OUTER JOIN (employee_m2m AS employee_m2m_1 JOIN (employee AS
employee_1 JOIN manager AS manager_1 ON employee_1.id = manager_1.id) ON
employee_1.id = employee_m2m_1."right" AND employee_1.type = ?) ON employee.id
= employee_m2m_1."left"',), kwargs=)
at ../Objects/call.c:367
#16 0x00698320 in bounded_lru_cache_wrapper (self=0x7fffeea89170,
args=('SELECT unithead.id, employee.id AS id_1, employee.name,
employee.type, manager_1.id AS id_2, employee_1.id AS id_3, employee_1.name AS
name_1, employee_1.type AS type_1 \nFROM employee JOIN unithead ON employee.id
= unithead.id LEFT OUTER JOIN (employee_m2m AS employee_m2m_1 JOIN (employee AS
employee_1 JOIN manager AS manager_1 ON employee_1.id = manager_1.id) ON
employee_1.id = employee_m2m_1."right" AND employee_1.type = ?) ON employee.id
= employee_m2m_1."left"',), kwds=0x0)
at ../Modules/_functoolsmodule.c:1020
#17 0x0052ccc3 in _PyObject_MakeTpCall (tstate=0xbb04a8
<_PyRuntime+459656>,
callable=, __module__='sqlite3', __doc__='SQLite database connection
object.', __wrapped__=) at remote
0x7fffeea89170>,
args=, nargs=1, keywords=0x0) at ../Objects/call.c:240
#18 0x767e8e90 in get_statement_from_cache (
operation='SELECT unithead.id, employee.id AS id_1, employee.name,
employee.type, manager_1.id AS id_2, employee_1.id AS id_3, employee_1.name AS
name_1, employee_1.type AS type_1 \nFROM employee JOIN unithead ON employee.id
= unithead.id LEFT OUTER JOIN (employee_m2m AS employee_m2m_1 JOIN (employee AS
employee_1 JOIN manager AS manager_1 ON employee_1.id = manager_1.id) ON
employee_1.id = employee_m2m_1."right" AND employee_1.type = ?) ON employee.id
= employee_m2m_1."left"', self=0x7fffec6989c0)
at ../Modules/_sqlite/cursor.c:510
#19 _pysqlite_query_execute (self=, multiple=0,
operation='SELECT unithead.id, employee.id AS id_1, employee.name,
employee.type, manager_1.id AS id_2, employee_1.id AS id_3, employee_1.name AS
name_1, employee_1.type AS type_1 \nFROM employee JOIN unithead ON employee.id
= unithead.id LEFT OUTER JOIN (employee_m2m AS employee_m2m_1 JOIN (employee AS
employee_1 JOIN manager AS manager_1 ON employee_1.id = manage
Re: Request to join PAPT and DPMT
[Zygmunt Krynicki, 2022-07-05] > I'd like to join PAPT and DPMT to co-maintain west and several other Python > packages related to or needed by the Zephyr project. I'm an old-timer, in a > way, but I have not been very active in packaging before. I'm looking to > improve my skills and actively maintain the small subset of packages I'm > using. My username on salsa is zyga-guest. welcome :)
Re: The python command in Debian
FTR: I didn't change my mind. /usr/bin/python is still used outside Debian packages, in /usr/local/bin scripts and applications and I strongly disagree to touch it. -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Python3 modules not built for all supported Python versions
> I don't know if I'm missing an argument to dh_python3 so that it knows the > python version, or even if there's a better workaround. But perhaps pybuild better workaround is to force cmake to install into versioned dist-packages (that's what I do in distutils) as I didn't find a reliable way to read Python version/architecture/tag/etc. from .so file > should be doing this automatically between the dh_auto_install calls so that > this kind of workarounds aren't necessary. it's actually a nice idea - pybuild can check if /usr/lib/python3.X/dist-packages/ is empty and there are .so files in /usr/lib/python3/dist-packages/ and move them temporarily to /usr/lib/python3.X/dist-packages/ (it knows which interpreter is used at this point) and let dh_python3 rename them later > Piotr, is this a bug in pybuild, or am I doing something wrong? well, cmake is not really easy to work with, they provide -DPYTHON_LIBRARY:FILEPATH… but they don't use it or use completely different name… it basically is different for each library I checked (and in different official documentation versions I read, sic!)
Re: Joining DPMT
[Julian Gilbey, 2019-11-17] > I currently maintain send2trash, and it was suggested to me by Sandro > Tosi that I join the DPMT to team-maintain it. That sounds like an > excellent idea to me! > > My salsa login is jdg > > I have read and accept the DPMT policy. welcome and sorry for the delay -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Join DPMT
[Håvard Flaget Aasen, 2019-11-17] > I wish to join the team. I don't bring any packages with me, but i intend to > contribute to existing ones. > > I have read and accept the DPMT policy: > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst > > My salsa account is haava-guest welcome in the team :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Join DPMT
[Thomas Andrejak, 2019-11-24] > Peter Wienemann > proposed me to became a member of DPMT and I think this is a good idea ! > > My salsa login is totol-guest > > I have read > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst > and > I accept it. Welcome :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: PAPT: join request
[intrigeri, 2019-11-08] > the PAPT umbrella; I'll co-maintain and sponsor; therefore, I need to > join the PAPT. > > My Salsa handle is: intrigeri > > I've read > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst > and I accept it. welcome and sorry for the delay :( > - In https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin, >the "Policy About Maintainer and Uploaders Fields" section >mentions an "unwritten policy". Said policy seems to have been >written since: > > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst feel free to edit the wiki (as a new member) :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
pypi.debian.net moved to Infomaniak
Hi, Just to let you know: pypi.debian.net is now hosted on Infomaniak's servers. Thanks to Thomas Goirand and other Infomaniak guys for setting that up! (they sponsored lifetime free VPS! :) I would also like to thank GPLHost for providing previous home for the redirector for more than 4 years. Thanks! signature.asc Description: PGP signature
Re: pylint3 reverse dependencies.
> Yes this is a known issue and we are currently waiting for an upload > of dh-python to avoid automatic replacement of pylint by pylint3 when > on python3 before pushing those changes further. http://ftp.debian.org/debian/dists/unstable/main/Contents-amd64.gz still contains pylint3 so I'm waiting with an dh-python upload for now -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: python equivalent of cabal-debian
[PICCA Frederic-Emmanuel, 2019-09-28] > Hello, I would like to know if there is an equivalent of > cabal-debian[1] , which helps a lot maintaining haskell packages. > > I allow to do the initial packaging and also the upgrade of the > packaging, by updating the Build-dependencies, etc... sounds like `py2dsp .` (or `py2dsp foo` if you want it to download sources from PyPI as well). Upgrading not really supported, though (unless `rm debian/control; py2dsp .` counts) Available in pypi2deb package -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Python 2 and PyPy module removal from Debian
Hi, During DebConf19 we¹ have tried to figure out how to manage Python 2 and PyPy module removal from Debian and below is our proposal. After discussing it on this mailing list we plan to send an email to debian-devel@l.d.o with a mass bug report and later an announcement about Python 2.X / PyPy module removal with some hints about what to expect to debian-devel-announce@l.d.o. There's a release tracker set up for Python 2 removal: https://release.debian.org/transitions/html/python2-rm.html but we plan to report a bug for each package that uses Python 2 or PyPy. All these bugs will get "py2removal" usertag and later one or more additional usertags - to make progress tracking a bit easier (release tracker is not optimised for our case). Severity will be set to a RC one at some point so that packages will be autoremoved from testing. Additional tags we will use are: • py2leaf - leaf package ready to be removed, i.e. without (build-)dependencies (including Recommends) in Debian main, • py3available - Python 3 support is available upstream, package needs an update in Debian, • py3noport - there's no upstream support for Python 3, needs a port done by us or package will be removed, • py2keep - package that should not be removed for now (popcon >1000 by default). Please don't add this usertag without discussing it on the mailing list first, • py2rm - packages that we will remove from Debian due to low popcon, etc. - all packages with popcon <100 will get this one by default Each bug will mention wiki help page (which we invite you to improve): https://wiki.debian.org/Python/2Removal documentation = Please keep the python-foo-doc package. Do not rename it to python3-foo-doc. If python-foo was providing documentation: move it to python3-foo or create python-foo-doc (not python3-foo-doc!) binary package. If your package uses python-sphinx to build docs: replace it with python3-sphinx. missing dh-python build dependency == There are ≈62² packages that use old dh_python2 helper (the one provided by python package). This helper will be removed in few months. Please add dh-python to Build-Depends (if your package cannot be upgraded to Python 3 or removed from Debian). Bug reports will be reported soon for these packages. There are ≈11² packages that use dh_python3 but do not depend on dh-python. python3 package will stop depending on dh-python soon, so please add missing dependency. Boost = In the next Boost transition Python 2 and Python 3 will get separate -dev packages. Please make sure you build-depend on the right one (and remove Python 2.X support if possible). DPMT / PAPT === No need to wait for a bug report. If you have a leaf package, remove it now. If you're not a DD, do it in the git repo and ping Piotr. [¹] Dimitri, Matthias, Piotr, Stefano, Thomas [²] https://lintian.debian.org/tags/missing-build-dependency-for-dh_-command.html signature.asc Description: PGP signature
Re: Join DPMT
[William Grzybowski, 2019-06-26] > That said I would like to contribute to DPMT, in special the python > modules I am going to be using which many are asyncio related and some > custom cython modules, including py-libzfs which now works with ZFS On > Linux (soon to be official OpenZFS upstream). welcome :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Joining the DPMT team!
[Louis-Philippe Véronneau, 2019-07-02] > I would like to join the DPMT team. welcome :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Joining PAPT
[Daniel Manila, 2019-06-18] > I would like to join PAPT because I am maintaining the weresync package you're in. Sorry for taking it so long -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Request to join DPMT & PAPT
[Ana Rodríguez López, 2019-03-17] > I would like to upload Weblate (#796777). For that I have been working in > some modules (social-auth-app-django, translation-finder, celery-batches) > which are now being maintained by the DPMT. To continue with the remaining > work I would like to join both the DPMT and PAPT teams. > > My salsa login: ana-pez-guest > > I have read and accept > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst. welcome! :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Please enable me pushing to python-team/applications
I added you to the team Andreas, sorry for the delay. -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Build test failure for python-easydev
> pkg_resources.DistributionNotFound: The 'easydev' distribution was not found > and is required by the application there are many ways to fix it (by creating egg-info data during build, not only during install stage), but if upstream is updating __version__ in each version, then definitely the best option is to patch out lines 23-31 from easydev/__init__.py file (i.e. not use pkg_resources) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: pybuild and testing pytest plugins
> Conceptually I think it's more relevant to override dh_auto_test. To make > sure pytest will register the plugin one may tweak the $PYTHONPATH. That's > the approach I followed in pytest-flask, see [1]. > [1] > https://salsa.debian.org/python-team/modules/pytest-flask/blob/debian/master/debian/rules while tests are run in build target (not my choice, I'd check installed files) I strongly advise to *not* use source files (i.e. "PYTHONPATH=$(CURDIR)") in dh_auto_test, especially if you build an extension. pybuild changes directory for a reason. If you need some files from source directory during tests, please list them in debian/pybuild.testfiles file and pybuild will copy them to build directory (and remove after tests). See pybuild manpage for more info. -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: dh_python2 namespace issue?
> so we tried in a clean chroot, a simple > > import backports.functools_lru_cache > > which end-up with > > ~# python -c "import backports.functools_lru_cache; print > backports.functools_lru_cache" > Traceback (most recent call last): > File "", line 1, in > ImportError: No module named backports.functools_lru_cache > > If we add an __init__.py file under > > (unstable-amd64-sbuild)root@diffabs6:/usr/lib/python2.7/dist-packages/backports# > touch __init__.py I cannot reproduce it: | (unstable-amd64-sbuild)root@piotro:/home/piotr# apt install python-backports.functools-lru-cache | Reading package lists... Done | Building dependency tree | Reading state information... Done | The following additional packages will be installed: | libexpat1 libpython-stdlib libpython2-stdlib libpython2.7-minimal libpython2.7-stdlib libssl1.1 mime-support python python-minimal python2 python2-minimal python2.7 python2.7-minimal | Suggested packages: | python-doc python-tk python2-doc python2.7-doc binfmt-support | The following NEW packages will be installed: | libexpat1 libpython-stdlib libpython2-stdlib libpython2.7-minimal libpython2.7-stdlib libssl1.1 mime-support python python-backports.functools-lru-cache python-minimal python2 python2-minimal python2.7 python2.7-minimal | 0 upgraded, 14 newly installed, 0 to remove and 0 not upgraded. [...] | (unstable-amd64-sbuild)root@piotro:/home/piotr# python -c "import backports.functools_lru_cache; print backports.functools_lru_cache" | anyway, command that should create this __init__.py is: `pycompile -p python-backports.functools-lru-cache` and python-backports.functools-lru-cache's postinst invokes it correctly. -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Please add my DD account to DPMT
> Please add my DD account to DPMT group on salsa: vvidic done :)
Re: Please add my DD account to DPMT
[Daniele Tricoli, 2018-12-29] > I'm already a member of DPMT (in the salsa group with my > eriol-guest account), but now I have a DD account (eriol) and I would > like to start using it. congrats! :)
Re: packaging django-rest-framework-filters
[Scott Kitterman, 2018-11-29]
> dh-python already doesn't use upstream version requirements when
> automatically
> extracting dependencies, so you have to check those yourself regardless of
> how
> you do it. This design decision was based on generally poor experiences with
> the accuracy of upstream version descriptions (using exact version
> requirements is very common in the upstream Python community and that
> generally isn't supportable in Debian).
actually dh_python{2,3} extracts it, but only if package maintainer of
given module claims it is sane (via PEP386 tag in pydist file)
f.e. I consider Mako's versioning sane, so I added PEP386 tag to pydist
file in src:mako and now all packages that have "Mako>=1.0.3" in setup.py's
install_requires AKA requires.txt (do not confuse with requirements.txt)
will get the dependency.
Another way to get versioned dependency is to add version restriction in
Build-Depends (but that has to be updated each time upstream changes it,
it needs to be done for build tests anyway). This is only a bit better
than hardcoding it in Depends, though.
Note that it doesn't cover the "I tested it with latest Mako so lets
require latest one in install_requires" case, so I'm not promoting
PEP386 that much (IMO package maintainers have to translate minimum
required versions into proper Build-Depends dependencies by hand for
now)
--
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: packaging django-rest-framework-filters
[Wookey, 2018-11-22] > No advice on best way to start a python packaging template? # apt install pypi2deb $ py2dsp djangorestframework-filters source package will be available in ./result/ (change it with --root) you can add '--profile dpmt' if you want to maintain it inside DPMT -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
-dbg vs -dbgsym compressed files when using Python3
> Since I polished python-lzma I uploaded the package anyway with new
> Vcs fiels and other polishing stuff.
please don't remove -dbg packages, -dbgsym packages are useless for us, AFAICT
(python{,3}-foo-dbg packages contain modules for Python debug
interpreter, something that -dbgsym packages do not provide)
--
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: dh_python3-ply lintian warning
[Ole Streicher, 2018-10-20] > W: python3-astropy: python-module-in-wrong-location > usr/lib/python3.7/dist-packages/astropy/ > usr/lib/python3/dist-packages/astropy/ > W: python3-astropy: python-module-in-wrong-location > usr/lib/python3.7/dist-packages/astropy/coordinates/ > usr/lib/python3/dist-packages/astropy/coordinates/ > W: python3-astropy: python-module-in-wrong-location > usr/lib/python3.7/dist-packages/astropy/coordinates/angle_lextab.py > usr/lib/python3/dist-packages/astropy/coordinates/angle_lextab.py > > How can I fix that? try adding --verbose to dh_python3 (it will probably mention some diffs - if they're cosmetic, remove files from versioned dir) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: TypeError: ord() expected a character, but string of length 3 found (Was: Updated python-uncertainties)
[PICCA Frederic-Emmanuel, 2018-10-12] > to my opinion, the code is modify in place with 2to3. > So the code on the source after the configuration is already converted to > python3. > And during the build process, with python2 the code is copied as it in the > .pybuild place for python2 > with python3 we see that the RefactoringTool, does nothing, it means the code > is already converted to python3. try adding python3-setuptools to Build-Depends -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: dh_python3 --no-ext-rename does not work (Was: Bug#910284: r-cran-fastcluster does not build Python modules for all supported Python versions)
Control: tags -1 -help Control: tags -1 patch > I tried to fix the issue reported below by using > dh_python3 --no-ext-rename > (see [1]) but this has no effect and the resulting package just > contains well, --no-ext-rename should not be used for public modules (I cannot imagine a single case where it's needed in dist-packages so I'll probably disable it for public modules). The fix: ;) You're missing python3-all-dev¹ build dependency so pybuild builds only for the available interpreter, not for all supported ones. [¹] and python-all-dev to be precise, python-dev covers all 2.X interpreters, though -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Problem with pybuild and pytest (repost)
[Ole Streicher, 2018-09-28] > For one of my packages (sunpy), I want to complete the switch to pybuild > by removing the custom (and quite unperfect) dh_override_auto_test rule. > > Currently, I have the following lines in d/rules: > > override_dh_auto_test: > python -m pytest sunpy -k "not figure and not online" > python3 -m pytest sunpy -k "not figure and not online" > > This gives successfull tests with the following output in the log: > > > --8<--- >debian/rules override_dh_auto_test > make[1]: Entering directory '/<>' > pyversions: missing X(S)-Python-Version in control file, fall back to > debian/pyversions > pyversions: missing debian/pyversions file, fall back to supported versions > pyversions: missing X(S)-Python-Version in control file, fall back to > debian/pyversions > pyversions: missing debian/pyversions file, fall back to supported versions > python -m pytest sunpy -k "not figure and not online" > = test session starts > == > platform linux2 -- Python 2.7.15, pytest-3.6.4, py-1.5.4, pluggy-0.6.0 > rootdir: /<>, inifile: setup.cfg > plugins: mock-1.7.1, hypothesis-3.44.1 > collected 1448 items / 34 deselected > [...] > --8<--- > > > >From the pybuild wiki page, I learned to do instead the override: > > export PYBUILD_TEST_ARGS=-k "not figure and not online" > > However, then the tests are not found anymore and the test step fails: 1) remove HOME line from debian/rules, pybuild sets one 2) you have ".." in PYBUILD_TEST_ARGS (in the git repo) - remove it 3) for python2.7 (and 2.7 only, 3.X works fine), cmdclassd somehow disables distutils' settings from .pydistutils.cfg (probably overwrites too much or doesn't invoke parent's methods). It works for 3.X because "from sunpy.tests.setup_command import SunPyTest" fails on 3.X and thus SunPyTest is not used at all. Disabling SunPyTest fixes it for me -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Byte-compilation for pypy3
> > err again (sorry, to many things at once), I meant option 4 (I can
> > change dh-python to generate additional checks for pypy{compile,clean})
>
> That'd be pypy3{compile,clean}
this is now available in dh-python 3.20180927. Only postinst files are
checking for pypy3compile, though. py3clean in prerm will remove .pyc
generated by PyPy3 as well (so no need to call pypy3clean in there)
> OK, so, now to figure out the "magic" part (byte-compiling already
> installed modules when pypy3 is installed / removed.
>
> Should I run the runtime.d directory? Currently everything in that will
> only do things with cpython bytecode.
>
> Apps that aren't in dist-packages probably don't need pypy3 bytecode,
> unless they want to be run with pypy.
>
> Anything that tries to determine the version (e.g
> /usr/share/python3/runtime.d/public_modules.rtinstall and
> /usr/share/python3/runtime.d/public_modules.rtremove) looks like they
> would break if I told them the version was pypy3.
>
> So, I'm somewhat tempted to ignore runtime.d entirely, and just
> byte-compile /usr/lib/python3/dist-packages. That seems pretty hacky,
> though :/
I think we should create a separate runtime.d for pypy3 and a separate one
for bcep files as well while we're at it.
FTR: bcep files are used to describe files that py3compile should avoid.
F.e. files meant for Python >= 3.6 ('async' keyword, etc.) should not be
byte-compiled using python3.5 (see dh_python3's manpage for details or
python3-jinja2 and pylint3 binary packages for examples).
Since we will share dist-package directory, we'll need to describe
exceptions for pypy3compile. One way is to extend version range syntax
in current /usr/share/python3/bcep/ files but I'd rather have separate
/usr/share/pypy/bcep/ used by pypy3compile.
signature.asc
Description: PGP signature
Re: Updated PEP 394 (python and python2 commands)
[Matthias Klose, 2018-09-25] > > how about generating dependencies on python2.7 and moving > > pycompile/pyclean there as well (this also solves pre-dependency issue) > > > >> - Not having a python package in bullseye (buster+1), but a > >>python2 package doesn't point to any "default" anymore. Many > >>users are installing just python, because it's the unversioned > >>package. So make it clear that this is another version, and > >>with having the choice of python2 and python3, most users will > >>install python3. > > > > same here > > > > additional question: why do you need for all that python2-doc, > > python2-minimal, python2-dev, libpython2-dev, libpython2-stdlib, > > python2-dbg and libpython2-dbg binary packages? > > yes, moving the symlinks to the 2.7 packages would be an option as well. But > I > don't see any difference why one or the other should be the preferred option. If we start generating dependencies on python2 packages that are not available in Stretch, we'll have to rebuild these packages (with hardcoded dependencies) for backports. We'll also force unofficial package maintainers to do some changes (for no clear reason or benefit)
Re: Byte-compilation for pypy3
> err, you meant for python3-foo packages, so I guess option 3 is the best
> one.
err again (sorry, to many things at once), I meant option 4 (I can
change dh-python to generate additional checks for pypy{compile,clean})
--
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Byte-compilation for pypy3
[Piotr Ożarowski, 2018-08-27]
> > rtupdate and postinst / prerm hooks for python3 packages currently call
> > py3{compile,clean} which only operates on cpython3.
> >
> > 5. Something else?
>
> modify these files and ship (renamed ones) in pypy3 package:
> /usr/share/python3/runtime.d/public_modules.rtinstall
> /usr/share/python3/runtime.d/public_modules.rtremove
err, you meant for python3-foo packages, so I guess option 3 is the best
one.
--
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Byte-compilation for pypy3
> rtupdate and postinst / prerm hooks for python3 packages currently call
> py3{compile,clean} which only operates on cpython3.
>
> 5. Something else?
modify these files and ship (renamed ones) in pypy3 package:
/usr/share/python3/runtime.d/public_modules.rtinstall
/usr/share/python3/runtime.d/public_modules.rtremove
--
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Salsa repository and first upload of tinyarray
> I've also kept the full upstream history in the upstream branch, > assuming this to be more robust and powerful. For example, this allows > to directly cherry-pick commits into the patch queue. you can add remote repository and cherry-pick upstream commits as you like > Since both these practices are discouraged by the policy, I'm ready to > give them up, please do > but before I spend time working on it, I would like to ask > whether tinyarray could be exempt from any one of both rules. According > with the policy, I would provide a debian/README.source file with the > above rationale and instructions. having one workflow makes it a lot easier to work on team packages, please don't add exceptions if they're not really needed -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Is there a tool to debianize for the first time a package from pypi
[PICCA Frederic-Emmanuel, 2018-08-04] > once debianize, is there a command which allow to update the control > file for a new upsteam version in order to take into account the new > python dependencies ? > > It would simplify a lot the maintenance of python packages. > > py2dsp update remove control file and invoke py2dsp - it will regenerate it That said, you probably want dch (debchange) rather than new control file -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Is there a tool to debianize for the first time a package from pypi
[Sandro Tosi, 2018-08-03] > https://packages.debian.org/unstable/pypi2deb I uploaded new version today, `py2dsp --profile dpmt` now generates salsa/gbp git repo instead of alioth/dpm -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: How to properly use dh_python3 as lintian suggests to move files from usr/lib/python3.7 to usr/lib/python3
[Andreas Tille, 2018-08-04] > for the new version of python-pyvcf[1] I get > > W: python3-pyvcf: python-module-in-wrong-location > usr/lib/python3.7/dist-packages/vcf/ usr/lib/python3/dist-packages/vcf/ > W: python3-pyvcf: python-module-in-wrong-location > usr/lib/python3.7/dist-packages/vcf/parser.py > usr/lib/python3/dist-packages/vcf/parser.py my guess is 3.7's parser.py differs from the 3.6's one, invoke dh_python3 with --verbose option - it will print the diff if any > I'm curious what to do to fix this. investigate if files can be merged (date stamp? hardcoded Python version?) or leave it as it is. If there's no other file or there are other files but there's no __init__.py file - interpreter will find it -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: how to deal with py-file-not-bytecompiled
[PICCA Frederic-Emmanuel, 2018-08-02] > Hello, I am preparing the new silx package and I got these error messages > from adequate > > This package produce the silx python module but install also a bunch of files > for qtdesigner > in the rules file with this command. > > # install the qtdesigner files only for the python3 package > dh_install -p python3-silx qtdesigner_plugins/*.py > /usr/lib/qt4/plugins/designer/python > > > So I would like to know what is the proper way to deal with this. override_dh_python3: dh_python3 # if you have files installed in standard directories or in other binary packages dh_python3 -p python3-silx /usr/lib/qt4/plugins/designer/python/ see "private dirs" in dh_python3's manpage -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Request to join
Hi Felix, [Felix Lechner, 2018-07-16] > I would like to join the PAPT team, please. Any pointers would be > appreciated. Thank you! let us know your salsa.d.o username if you accept our policy https://salsa.debian.org/python-team/tools/python-apps/blob/master/policy.rst -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: kivy package in trouble?
[Dean Serenevy, 2018-07-18] > Hello, I am a user of the python3-kivy package and just noticed that > kivy is no longer listed in buster [1]. > > Is help needed? (I am not a DD, but I am willing to test and submit > packaging patches if it would help.) tracker¹ points to bug #873501² (FTBFS with cython 0.26) [¹] https://tracker.debian.org/pkg/kivy [²] https://bugs.debian.org/873501 -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: How to convince ‘dh_python3’ to handle ‘/usr/lib/python3.7/dist-packages/foo.egg-info/’ correctly?
[Ben Finney, 2018-07-15] > Which particular of those files are right or wrong, according to the > Debian Python Policy §2.5? > > * usr/lib/python3.7/dist-packages/coverage-4.5.1.egg-info/ > * usr/lib/python3/dist-packages/coverage-4.5.1.egg-info/ > * usr/lib/python3.7/dist-packages/coverage-4.5.1.egg-info/entry_points.txt > * usr/lib/python3/dist-packages/coverage-4.5.1.egg-info/entry_points.txt > > How should I change the package's ‘debian/rules’ to conform to Debian > Python Policy §2.5? my guess is: these two entry_points.txt files are not the same and thus dh_python3 refused to move the second one to the shared directory. -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Binary package contains no Python dependencies, how to convince ‘dh_python3’ to detect them?
[Ben Finney, 2018-07-15] > The Debian package ‘gandi-cli’ is building with none of the Python > library dependencies detected, so the “Depends” field contains none of > the required Python library packages. Why isn't ‘dh_python3’ reading the > dependencies from ‘requires.txt’? gandi-cli name suggests it's not providing public module and thus no "public" requires.txt. If you want dh_python3 to read dependencies from a random file - make sure dh_python3 knows which one it should use: override_dh_python3: dh_python3 --requires path/to/file_with_deps.txt -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Request to join the Python Modules team
[Martin Kelly, 2018-07-15] > I would like to join the Salsa Python Modules team in order to continue > maintaining my package python-gmpy2. I previously had Alioth access and have > finally had time to migrate to Salsa. > > My Salsa login is aomighty-guest. done -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Access to the PAPT repositories
[Elena ``of Valhalla'', 2018-06-30] > I was already a (not very active) member of PAPT, where I maintain > pdfposter, and I would like to have access to it on salsa, where my > username is valhalla. done :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: No clue yet for building snakemake since there are two dirs in .pybuild
[Piotr Ożarowski, 2018-06-27] > [Stuart Prescott, 2018-06-26] > > > # ls -l /build/snakemake-5.1.5/.pybuild > > > total 8 > > > drwxr-xr-x 3 pbuilder pbuilder 4096 Jun 26 09:20 cpython3_3.6 > > > drwxr-xr-x 3 pbuilder pbuilder 4096 Jun 26 09:20 cpython3_3.6_snakemake > > > > > > and the latter contains all the installed files while the former is > > > empty. How can I prevent this? > > > > Deleting PYBUILD_NAME from your debian/rules is sufficient to fix that. > > When > > set, that sets HOME to the above directory and the build system for some > > reason starts using that. > > > > And no, I can't explain why that is... > > "cpython3_3.6" is used if --name / PYBUILD_NAME is not defined. Name is > added to it to support building multiple modules/extensions at the same > time. If snakemake doesn't invoke pybuild twice (with and without > --name) then existence of cpython3_3.6 (without "_snakemake") is a bug > somewhere in pybuild FTR: not a bug in pybuild, in line 11 you have: export PATH:=$(shell pybuild --print build_dir --interpreter python3)/bin:$(PATH) and export/pybuild doesn't know about PYBUILD_NAME yet (it's how Makefile works), you need to add "--name $(PYBUILD_NAME)", like this: export PATH:=$(shell pybuild --print build_dir --interpreter python3 --name $(PYBUILD_NAME))/bin:$(PATH) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: No clue yet for building snakemake since there are two dirs in .pybuild
[Stuart Prescott, 2018-06-26] > > # ls -l /build/snakemake-5.1.5/.pybuild > > total 8 > > drwxr-xr-x 3 pbuilder pbuilder 4096 Jun 26 09:20 cpython3_3.6 > > drwxr-xr-x 3 pbuilder pbuilder 4096 Jun 26 09:20 cpython3_3.6_snakemake > > > > and the latter contains all the installed files while the former is > > empty. How can I prevent this? > > Deleting PYBUILD_NAME from your debian/rules is sufficient to fix that. When > set, that sets HOME to the above directory and the build system for some > reason starts using that. > > And no, I can't explain why that is... "cpython3_3.6" is used if --name / PYBUILD_NAME is not defined. Name is added to it to support building multiple modules/extensions at the same time. If snakemake doesn't invoke pybuild twice (with and without --name) then existence of cpython3_3.6 (without "_snakemake") is a bug somewhere in pybuild -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Request to join the team
[Alexander Gerasiov, 2018-06-20] > I'd like to join the team as I need to debianize some python modules > for internal project and would like to upload them into archive too. > > I think it would be best to maintain them under DPMT. > > And of course I've read and accept team policy for package maintenance. welcome in the team :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Request to join the team
[Dima Kogan, 2018-06-18] > Yes. I accept the policy. Sorry, I wasn't subscribed to the list, and > never saw this reply. welcome :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Updated PEP 394 (python and python2 commands)
[Matthias Klose, 2018-06-08] > from my point of view this doesn't address: > > - being able to de-install the python command for buster, if >people don't use it. Most dependencies are auto-generated, so >these could be replaced by dependencies on python2. I would >assume that the majority of users won't have to install the >python package anymore, unless they are doing python2 >development. how about generating dependencies on python2.7 and moving pycompile/pyclean there as well (this also solves pre-dependency issue) > - Not having a python package in bullseye (buster+1), but a >python2 package doesn't point to any "default" anymore. Many >users are installing just python, because it's the unversioned >package. So make it clear that this is another version, and >with having the choice of python2 and python3, most users will >install python3. same here additional question: why do you need for all that python2-doc, python2-minimal, python2-dev, libpython2-dev, libpython2-stdlib, python2-dbg and libpython2-dbg binary packages? -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Joining DPMT
[Willem van den Akker, 2018-05-31] > I am maintaining python-ldap and want to make it a team-package. > My login name: wvdakker-guest > I have read and accept the Debian Python Modules Team - Policy on > salso (there is in invalid link to alioth in the document). > > A 3.10 package is available on mentors (https://mentors.debian.net/pack > age/python-ldap). I will submit a sponsor request on IRC. welcome :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Requesting to join PAPT
> > I'm the maintainer[1] of the quodlibet[2] package. I'd like to join the > > team. Thanks to W. Martin Borgert (debacle), the repo is there already. > > I still need permissions to push, though). > > what is your salsa username please? It's cargill-guest. Now in the team, welcome :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Request access on DPMT salsa group
[Víctor Cuadrado Juan, 2018-05-17] > > I maintain some packages in DPMT, such as: > > https://salsa.debian.org/python-team/modules/python3-proselint > > https://salsa.debian.org/python-team/modules/python-neovim > > and I wanted to push changes to them. > > > > Could somebody add me to the following salsa group? > > https://salsa.debian.org/python-team/modules > > > > Many thanks in advance, > I forgot to say that my salsa id is viccuad-guest done :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Updated PEP 394 (python and python2 commands)
> A bit disappointed about this style of communication, Matthias same here (you want us to do something without explaining reasons) EOT for me. -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Updated PEP 394 (python and python2 commands)
> who said, that we should rename packages? The only packages being dropped are
> the python defaults packages.
> >
> > I refuse to do that work!
>
> There is no work in renaming the packages. It's about the dependency
> generation
> and the shebang.
the work in dh-python is not trivial. The work needed in thousands of
packages (all Python related packages build depend on python{,-dev} or
python-all{,-dev} is not as well. Rebuilding all binary packages means
even more work (${python:Depends} is not always the only dependency)…
and that's only a work in Debian. There are lots of packages outside
Debian that will need to be updated… for what purpose exactly?
To make it easier to propose later python2-foo binary package rename,
like Fedora did?
> > The only message it sends is that we don't think /usr/bin/python or
> > python package is Python 2.7 anymore and that's definitely not the
> > message I want to send.
>
> No, that's not what the PEP says.
not yet. We all know that it will happen sooner or later, though.
How about creating DEP-394 with a strong message that we have default
Python 2.X and default Python 3.X interpreters and once 2.X will be
gone. Python 3 will NOT become default Python 2.X?
--
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Updated PEP 394 (python and python2 commands)
[Matthias Klose, 2018-05-17] > PEP 394 [1] saw an update in April 2018 [2], the diffs at [3]. > > The most important change from my point of view is > > -* It is suggested that even distribution-specific packages follow the > - ``python2``/``python3`` convention, even in code that is not intended to > +* It is strongly encouraged that distribution-specific packages use > ``python2`` > + or ``python3`` rather than ``python``, even in code that is not intended to >operate on other distributions. FTR: the day this PEP asks us to point /usr/bin/python to python3 is the day I start ignoring it, to say the least. > I don't think there is enough time to replace all python shebangs to python2 > in > time for the buster release, however there is no harm in starting this process > now. too late, this process has already started (since dh_python2 v3.20180313) ;-P > But I'd like to get this done for buster+1, in the case we still need to > ship a Python2/2.7, so that buster+1 doesn't ship with a python command, but > maybe with a python2 command. we already ship /usr/bin/python2. Removing /usr/bin/python makes sense as well (administrators can symlink it to whatever they want once it's gone from Debian), but... > The first step is to create a set of python2* packages in python-defaults, > with > contain all the python2* symlinks, and having the python* packages depend on > those python2 packages. This change itself is a no-op and shouldn't affect > anything. > > As a second step change the dh_python2 (in python-defaults), and dh-python to > generate dependencies on python2 instead of python, and replacing the shebang > from python to python2. > > This should cover the majority of packages to replace dependencies on python > with dependencies on python2. There are packages which don't check for > python2, > so these probably need adjustments. But again, the goal for buster+1 is to > ship > as few Python2 dependent packages as possible, if any. this is useless. What will we gain by renaming packages? I refuse to do that work! The only message it sends is that we don't think /usr/bin/python or python package is Python 2.7 anymore and that's definitely not the message I want to send. > The third step for buster+1 would be to drop the set of python* packages from > python-defaults. if we manage to remove Python 2.7 from Buster+1, all python-* packages¹ will be gone, including python-defaults so why additional work? [¹] without -doc packages -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: PLY problem
[Ole Streicher, 2018-05-16] > # This module includes files automatically generated from ply (these end in > # _lextab.py and _parsetab.py). To generate these files, remove them from this > # folder, then build astropy and run the tests in-place: > # > # python setup.py build_ext --inplace if it's about adding build_ext's option to build command, you can do it like this: export PYBUILD_BUILD_ARGS=build_ext --inplace see uvloop's debian/rules file¹ for an example [¹] https://sources.debian.org/src/uvloop/0.9.1+ds1-1/debian/rules/?hl=4#L4 -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: foo FTBFS with dh-python >= 3.20180313
[Andreas Tille, 2018-04-30] > On Mon, Apr 30, 2018 at 03:57:51PM +0200, Piotr Ożarowski wrote: > > [Andreas Tille, 2018-04-30] > > > > PYTHONPATH=$(shell pybuild --print build_dir --interpreter python3) ... > > > I tried the same trick for snakemake in Git[1] but failed. > > > > > > Am I missing something? > > > > you changed PYTHONPATH, but PATH still hardcodes old path, I'd start > > with that. > > Hmmm, inside pbuilder chroot the files are installed to > > /build/snakemake-4.8.0/.pybuild/cpython3_3.6_snakemake/build/bin/snakemake > > while > > # pybuild --print build_dir --interpreter python3 > /build/snakemake-4.8.0/.pybuild/cpython3_3.6/build you invoked it outside debian/rules, without --name or PYBUILD_NAME set, right? > I have no idea why since some dh-python version things are different > than before but wouldn't it be the best idea to let pybuild set PATH and > PYTHONPATH instead of setting it manually by some manual command? I meant to fix also debian/rules line 11 (you fixed line 21 only) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: foo FTBFS with dh-python >= 3.20180313
[Andreas Tille, 2018-04-30] > > PYTHONPATH=$(shell pybuild --print build_dir --interpreter python3) ... > > This worked nicely for python-skbio. > > > I fixed few packages already, here's a list of other affected ones: > > ... > > snakemake Debian Med Packaging Team > > I tried the same trick for snakemake in Git[1] but failed. > > Am I missing something? you changed PYTHONPATH, but PATH still hardcodes old path, I'd start with that. -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: foo FTBFS with dh-python >= 3.20180313
[Andreas Tille, 2018-04-26] > some packages I maintain received this kind of bug in the case of > python-skbio it is > >ModuleNotFoundError: No module named 'skbio' > > So the module that was just build is not found. I guess this is due to > some misuse of pybuild - but what did I wrong? Python-skbio is available > on Salsa[1] (updated to new upstream but with no change for the current > problem). > > Any hint how to fix this? that's because I had to change pybuild's internal paths (to make it work with multiple modules/packages at the same time). I added --print option for those who really need it (f.e. while building sphinx docs) - please use it instead of hardcoding pybuild's internal paths. You can use it like this: PYTHONPATH=$(shell pybuild --print build_dir --interpreter python3) ... I fixed few packages already, here's a list of other affected ones: cypari2 Debian Science Team keras Debian Science Maintainers khmer Debian Med Packaging Team macsDebian Med Packaging Team numba Debian Science Maintainers numexpr Debian Science Maintainers paleomixDebian Med Packaging Team petsc4pyDebian Science Maintainers pyosmiumDebian GIS Project pysal Debian GIS Project python-gevent Laszlo Boszormenyi python-skbioDebian Med Packaging Team rowsPaulo Roberto Alves de Oliveira saltDebian Salt Team slepc4pyDebian Science Maintainers snakemake Debian Med Packaging Team statsmodels Debian Science Maintainers -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Please add me (back?) to the team
[Julien Puydt, 2018-04-11] > I'm already part of the teams, but as jpuydt-guest, and I would > now need to be part of the same teams as jpuydt, as I just completed the > process to become a DD. congratulations :) > If I remember well, I'm part of: right (https://alioth.debian.org/users/jpuydt-guest/) > - Debian Python Module Team done -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Several questions regarding package tifffile
[Ghislain Vaillant, 2018-04-09] > > I realised that upstream of tifffile[1] switched to Python3. When > > inspecting the package I somehow think that its main purpose is rather a > > user application than a Python module and thus I would rather rename the > > binary from python-tifffile to tifffile than python3-tifffile. What do > > you think? please also move the module to private dir by passing this option to setup.py: --install-lib=/usr/lib/tifffile or if you decide to use pybuild: export PYBUILD_INSTALL_ARGS=--install-lib=/usr/lib/tifffile if you don't want to mess with PYTHONPATH, install script there as well (--install-scripts=/usr/lib/tifffile) and symlink /usr/bin/foo to /usr/lib/tifffile/yourscript -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Request joining DPMT
[florian grignon, 2018-03-28] > I would like to join DPMT. > > I'm maintaining one python package that I would like to team maintain > (python3-anosql). For this goal, I'd like also to join the DPMT salsa group > to move the git repository to the DPMT salsa group. > > My alioth and salsa login are: flog-guest > > I have read the DPMT Policy > https://python-modules.alioth.debian.org/policy.html) and I accept it. welcome :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Strange encoding problem in setup.py of biopython 1.71
[Peter Cock, 2018-04-06] > Piotr, I think your fix would be worth including in Biopython. > > Do you want to submit this as a pull request, or give me > permission to do so by email? go ahead > We'd need you to agree to both the Biopython License Agreement > and the 3-clause BSD licence, and say if you'd like to be > acknowledged by name or not. OK (and no need to mention my name) signature.asc Description: PGP signature
new DPMT / PAPT admin
Hi, We don't have a procedure to select a new admin (or terms / rotations unfortunately) so if you want to blame current admins for this, Ondřej Nový will share the blame now :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: PGP signature
Re: Please add me on Salsa
[Nikolaus Rath, 2018-04-05] > Huh? I have been member of the team for a few years already, I'm just > not registered on Salsa yet (as far as I know Alioth memberships don't > transfer automatically). ah, sorry, I didn't check alioth. You're now also a member on salsa. BTW, there's no need to send an email to the mailing list, if someone was a member on alioth, just send me private email or a message on IRC. -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Requesting team membership for DPMT on Salsa
[Andreas Tille, 2018-04-05] > On Thu, Apr 05, 2018 at 04:40:44PM +0200, Piotr Ożarowski wrote: > > [Andreas Tille, 2018-03-28] > > > I failed to find a button to ask for membership in the Salsa web > > > > let me know if you find it (bonus points for also letting me know how to > > disable it) > > May be it is just disabled? FTR (if it wasn't clear) I want it disabled! I want all join requests to go to this list so that other team members can raise their concerns. -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Please add me on Salsa
Hi Nikolaus, [Nikolaus Rath, 2018-04-03] > Could someone please add me to the DPMT and DPAP teams on Salsa? My > Alioth and Salsa username is nikratio-guest. what do you think about our policy and on which packages do you want to work with us? -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Requesting team membership for DPMT on Salsa
[Andreas Tille, 2018-03-28] > I failed to find a button to ask for membership in the Salsa web let me know if you find it (bonus points for also letting me know how to disable it) > interface for DPMT. Please add me since I contributed to some python-* > packages in the past and would like to keep on contributing. :-) > > It would be nice if the permissions would enable me creating new > projects. done :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: [DPMT] Interested to joining the team
[T K Sourabh, 2018-03-28] > I am interested in contributing to python modules for Debian. Happy to help. > > Why you want to join the team: > I want to help in contributing to packaging python module. > > Your Alioth login: > sourabhtk37-guest > > I have read https://python-modules.alioth.debian.org/policy.html and accept > it. welcome :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Strange encoding problem in setup.py of biopython 1.71
[Andreas Tille, 2018-04-05]
> Traceback (most recent call last):
> File "setup.py", line 435, in
> readme_rst = handle.read()
> File "/usr/lib/python3.6/encodings/ascii.py", line 26, in decode
> return codecs.ascii_decode(input, self.errors)[0]
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 7116:
> ordinal not in range(128)
> E: pybuild pybuild:336: clean: plugin distutils failed with: exit code=1:
> python3.6 setup.py clean
> dh_auto_clean: pybuild --clean -i python{version} -p 3.6 returned exit code 13
> ...
in setup.py, if you decide to keep supporting Python 2, change lines 434-435
into:
with open("README.rst", 'rb') as handle:
readme_rst = handle.read().decode('UTF-8')
or if you finally let it go, change only line 434:
with open("README.rst", encoding='UTF-8') as handle:
--
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: packages that use dh_python{2,3} but don't depend on dh-python
[Matthias Klose, 2018-03-27] > yes. please see below for a description of such packages. Or you might share > the > approach how you did construct those lists you posted. I used codesearch.d.n¹, then downloaded JSON representation of that search² and removed all packages that Build-Depend on dh-python from this³ list in Python. [¹] https://codesearch.debian.net/search?q=dh_python3|--with[%3D+].*python3+path%3Adebian%2Frules [²] curl -s https://codesearch.debian.net/results/216977478aa5db9e/packages.json | jq -r '.Packages[]' [³] grep-dctrl -n -w -F Build-Depends,Build-Depends-Indep -s Package dh-python /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: packages that use dh_python{2,3} but don't depend on dh-python
[Matthias Klose, 2018-03-27] > On 26.03.2018 19:32, Piotr Ożarowski wrote: > > Hi, > > > > Here's a list of packages that will FTBFS soon if dh-python will not be > > added to Build-Depends (it's time to drop dh-python from python3's > > Depends and old version of dh_python2 from python package). > > > > http://people.debian.org/~piotr/dh_python3_without_dh-python.list > > http://people.debian.org/~piotr/dh_python3_without_dh-python.ddlist > > http://people.debian.org/~piotr/dh_python2_without_dh-python.list > > http://people.debian.org/~piotr/dh_python2_without_dh-python.ddlist > > > > The plan is to report bugs first and follow up with changes in -defaults > > packages in April or May. > > These lists have way to many false positives. So please, don't file bug > reports > before checking these manually. can you name some so that I can try to figure out what went wrong? > You have to exclude all these source packages using python/python3 as a b-d > only > and which don't build any binary packages without any python/python3 > dependency > in the packages, e.g. gcc-defaults. gcc-defaults is not a false positive, it calls `dh_python2 -plibgcj-common` but doesn't depend on dh-python -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: PAPT and DPMT membership request for moschlar-guest
> > [Moritz Schlarb, 2018-02-15] > > > please also add my user "moschlar-guest" to the respective Groups on > > > Salsa. done :) > Original email: https://lists.debian.org/debian-python/2017/01/msg00030.html > > So it's about the "nagstamon" package. thanks Raphaël -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Joining the team
[Georg Faerber, 2018-03-15] > I would like to join the team. > > I'm intending to package mwic [1], Misspelled Words In Context, which is > a spell-checker that groups possible misspellings and shows them in > their contexts. This is useful for checking technical documents that > often contain words that are not included in standard dictionaries. The > upstream author is Jakub Wilk. > > I maintain some packages [2], and became a DM recently [3]. > > I'm "georg-guest" on salsa.d.o. welcome :) > I've read the team policy and accept it. -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Request to join the PAPT
[Pierre-Elliott Bécue, 2018-03-18] > After hanging around a lot in DPMT, I'm currently packaging an app that > henceforth would definitely find its place into PAPT namespace on salsa. > > I'll commit myself to follow the PAPT policy. :) > > My salsa login is peb-guest you're in, welcome :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Extra debian.blends Python package
[Ole Streicher, 2018-03-24]
> I am currently rewriting part of the blends-dev package which is used
> for maintaining Debian Pure Blends into Python. This however comes out
> some abstractions of Blends (namely the tasks infrastructure) that may
> be re-usable on other places, f.e. in the blends.d.o web service. So it
> is probably a good idea to create a separate Python package from it.
>
> Since this package deals with tasks sources, it sounds natural to put
> this as a sub-package of the "debian" package. I would however not like
> to integrate the sources to python-debian. First, it is very new and
> likely to change API quickly in the next time. But also, the blends
> subpackage is quite special; there is no need to have it installed in
> such a broad manner as python-debian.
>
> And finally, I do not care about Python 2 compatibility here.
>
> What I could do easily is to create a python3-debian-blends binary
python3-debian-blends suggests some kind of addon ("-", not ".") to
"debian" module.
Will this package provide a public module? If so python-modulename is
your name, if not - why can't you re-use "blends" namespace? (blends-python3?)
> package (maintained in the "blends" source package) for this subpackage,
> just installs a "blends.py" into ../dist-packages/debian/
ah, so python3-debian.blends is the name. I'd talk with python3-debian
maintainers about including it in the python3-debian, though
--
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Team addition request
[Yago González, 2018-03-19] > Recently I started maintaining the "python-tabulate" package, and would > like to join the team to be able to update the Git repository in Salsa, > as well as being able to help with other Python packages in the future. > > I acknowledge reading the team's policy. Here are my usernames: > > Salsa: yago-guest welcome in DPMT :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Request to join the team
[Dima Kogan, 2018-03-17] > Hi. I'd like to join the DPMT team to package and upload some modules. > > Salsa username: dkogan do you accept our policy? -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Request to join DPMT
[Aggelos Avgerinos, 2018-03-16] > It's been a long time, so I'm re-pinging you again: done, sorry for the delay > On 14/02/2018 10:39, Aggelos Avgerinos wrote: > > Hello again, > > > > Thanks for accepting in to the DPMT on alioth. > > > > Can you please do the same for salsa? (avgerinos-guest) > > > > Thanks in advance, > > > > ~A > > > > On 30/01/2018 16:01, Aggelos Avgerinos wrote: > > > Hello there, > > > > > > I would like to join the DPMT to maintain py-radix within the team, also > > > planning to adopt more packages in the future. > > > I'm currently sponsored by Apollon OIkonomopoilos (apoikos) > > > > > > My alioth login is avgerinos-guest > > > > > > I have read the team's policy > > > (https://python-modules.alioth.debian.org/policy.html) and I accept it. -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Join the DPMT
[Craig Small, 2018-03-14] > Hello, > As I'm looking at maintaining two python modules (pytest-vcr and > mastodon) I'm asking to join the DPMT. My salsa login is csmall, I have > read and accept the python module policy. I'm a Debian developer so > probably don't need an ACL change. I added you to the team... > One thing about the policy, as I'm directly importing the upstreams git > repository, I inherit their tags. This means upsteam tags are "1.2.3" > not "upstream/1.2.3" I don't know if there is a way to do tag mangling; > it's certainly past my git knowledge. but please follow the team guidelines and don't import complete upstream history / tags unless you have a really good reason. -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Joining the Debian Python Modules team
[Lev Lamberov, 2018-03-12] > I'd like to join DPMT, Debian Python Modules Team. The motivation is > that I'd like to package and maintain several Python modules within the > team. Namely, sexpdata [1] and epc [2], which are dependencies for > emacs-jedi [3]. jedi maintainer (including vim-python-jedi :P) here... > My Alioth/Salsa login is, well, dogsleg. done :) > I've read DPMT policy and accept it. -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: DPMT; salsa access
[Adrian Vondendriesch, 2018-03-08] > please add me to the DPMT group on salsa.debian.org. I'm already a > member of the DPMT. My username is discostu-guest. done :) > Unfortunately the web interface doesn't show any "Request Access" > button. that's great news! (I hated that button on alioth!) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Please add me to the python-team/modules group on salsa
[Julien Muchembled, 2018-03-08] > My username on salsa on jmuchemb-guest. I'm already member of DPMT. > > I saw this answer on this ML but I don't see this link: > > Le 02/14/18 à 21:46, Jonathan Carter (highvoltage) a écrit : > > I think you have to click on 'request access' on > > https://salsa.debian.org/python-team/modules done, welcome again ;) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Joining the DPMT
[Ana C. Custura, 2018-03-06] > I am writing about joining the DPMT. I have a handful of prospective > python packages which I would like to maintain within the team, and > some existing ones to transition. > I have read and accepted the policy at > https://python-modules.alioth.debian.org/policy.html and my name on > salsa is ana-guest. welcome! :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: membership request
[Christophe Siraut, 2018-03-01] > I have prepared an update for python-jsontest (#840033), I'd like to > push it on salsa and hereby request membership to DPMT group, my > username is tobald. Can you check my svn access for python-apps as well? > > I have read and agree to the terms of the team policy. done, welcome (and sorry for the delay) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Buildbot maintenance by PAPT
[Robin Jarry, 2018-02-27] > after some discussions on https://bugs.debian.org/883529, Martin Borgert > suggested that buildbot becomes maintained by the Python Applications > Packaging Team. > > That sounds like a good thing to have more than one person able to work > on this package. > > I am currently working on buildbot (both upstream dev and Debian > packaging), I have read the Debian Python Policy and I'm not sure how to > proceed for joining the PAPT. great, just let me know if you accept our policy and I'll hit the button (BTW, dh-python should be ready for builbot now, let me know if you need more changes) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Request to join DPMT
[Andre Bianchi, 2018-02-28] > Hello! I'd like to join DPMT to help maintaining packages related to > Weblate. I'm currently working on python3-openid and > python-social-auth-core, and plan to tackle all others that are > deps to Weblate. > > My logins in alioth and salsa are: drebs-guest > > I have read https://python-modules.alioth.debian.org/policy.html and > i agree to it. welcome on board! (and sorry for the delay) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Request to join DPMT (for putting sphinx-intl package)
[Hideki Yamane, 2018-02-24] > I'd like to put sphinx-intl package(*) under DPMT umbrella, so could > you add me your group on salsa, please? done, welcome :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Please add me on Salsa
[Dominik George, 2018-02-22] > please add me to the team(s) on Salsa. I am an existing DPMT member. > > Username: natureshadow-guest I added the one without "-guest" on salsa. Congrats :)_ -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: add to the DPMT team
[Michal Arbet, 2018-02-15] > Could you please add me to DPMT team ? > > Why do I want to join a team ? > Now I am part of Openstack-team and there was discussed that many python > packages will be moved to DPMT team , so I want to continue with > contributing to Openstack via DPMT team. > > What is my alioth login ? > keuko-gues > > I've already read https://python-modules.alioth.debian.org/policy.html . > Accept and uderstand. I added you to one on salsa.d.o, welcome -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: PAPT and DPMT membership request for moschlar-guest
Hi, [Moritz Schlarb, 2018-02-15] > please also add my user "moschlar-guest" to the respective Groups on Salsa. looks like my thread is broken, I cannot find referenced emails. Do you accept our policy? Which packages do you want to work on? -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Access to DPMT and PAPT on salsa
[Joseph Herlant, 2018-02-15] > I'm one of the maintainers of pylint-django, pylint-plugin-utils and asciidoc. > I'd like to be added to the DPMT team for the 2 first repos and I'd > like to move asciidoc to PAPT (it is EOL but it will take a few months > for me to take care of its EOL properly). > > My account on salsa is aerostitch-guest welcome! -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Contributing to DPMT with python-anosql
> My alioth account is: arkadefr-guest please create an account on salsa.d.o and point me to it if you're still interested (and sorry for the delay) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Request to join Python Application Packaging Team
[ChangZhuo Chen (陳昌倬), 2018-02-13] > I would like to request to join Python Application Packaging Team for > some packages I maintain (e.g. cppman, ctop, pydocstyle, ...) > > My salsa account is czchen. you're in. Sorry for the delay -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
packages that use dh_python{2,3} but don't depend on dh-python
Hi, Here's a list of packages that will FTBFS soon if dh-python will not be added to Build-Depends (it's time to drop dh-python from python3's Depends and old version of dh_python2 from python package). http://people.debian.org/~piotr/dh_python3_without_dh-python.list http://people.debian.org/~piotr/dh_python3_without_dh-python.ddlist http://people.debian.org/~piotr/dh_python2_without_dh-python.list http://people.debian.org/~piotr/dh_python2_without_dh-python.ddlist The plan is to report bugs first and follow up with changes in -defaults packages in April or May. -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: pybuild: how to get the build directory name
[Ole Streicher, 2018-03-20]
> test-python%:
> HOME=/tmp/ PYTHONPATH=$(CURDIR)/.pybuild/pythonX.Y_$*/build python$*
> debian/tests/pyraf-test.py
>
> override_dh_auto_test: $(PYTHON2:%=test-python%) $(PYTHON3:%=test-python%)
>
> This however does not work anymore, since the subdir under .pybuild is
> now changed to cpython2_2.7_pyraf resp. cpython3_3.6_pyraf.
`pybuild --print build_dir --interpreter python3` or:
`pybuild --print '{build_dir}' --pyver 2.7`
`pybuild --print '{build_dir}' --pyver 3.6`
> To be backward compatible, I would however not like to just follow this
> change. How can I get the correct build dir here?
or even better (without using pybuild's internal paths):
override_dh_auto_test:
dh_auto_test -- --system=custom --test-args '{interpreter}
{dir}/debian/tests/pyraf-test.py'
--
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: PAPT repo at salsa.d.o open for new packages now?
[W. Martin Borgert, 2018-02-14] > if I have a Python program, that currently is not yet maintained > by PAPT, but want to move it to the team: May I use > salsa.d.o/python-team/applications/ now? Any objections? yes. Please wait until the workflow is selected -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Request to join DPMT
[Scott Talbert, 2018-02-13] > > > I would like to join DPMT so that I could maintain the > > > python-pytest-xdist package (that I've recently discussed adopting > > > with Daniel Stender). Additionally, I'll need to package a new > > > dependency for a new upstream release of python-pytest-xdist. > > > > > > My Alioth login is swt2c-guest. > > > > > > I've read https://python-modules.alioth.debian.org/policy.html and > > > accept it. > > > > Can I redirect this as a request to join the Salsa group? :) My Salsa > > username is the same, swt2c-guest. you're in. Welcome :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Help needed for Python3 package python3-bd2k which does not install due to syntax error
> python-bd2k[1] which builds fine it doesn't if you remove the override to not run Python 3.X tests -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
