Re: upload sphinx-autoapi
On 2020-10-21 15:37+0530, Utkarsh Gupta wrote: Hi Felix, On Sat, Oct 10, 2020 at 4:04 PM Félix Sipma wrote: I updated the package to the last upstream version, and it includes a few fixes. I'd appreciate if I could be given upload rights, that would help maintaining the package. Given you upload rights. You should have an email about it shortly. Great, thanks. -- Félix signature.asc Description: PGP signature
Re: upload sphinx-autoapi
If someone could have a look... On 2020-10-10 12:27+0200, Félix Sipma wrote: Hi, Could someone upload sphinx-autoapi 1.5.1-1? https://mentors.debian.net/package/sphinx-autoapi/ https://mentors.debian.net/debian/pool/main/s/sphinx-autoapi/sphinx-autoapi_1.5.1-1.dsc I updated the package to the last upstream version, and it includes a few fixes. I'd appreciate if I could be given upload rights, that would help maintaining the package. Regards, -- Félix signature.asc Description: PGP signature
upload sphinx-autoapi
Hi, Could someone upload sphinx-autoapi 1.5.1-1? https://mentors.debian.net/package/sphinx-autoapi/ https://mentors.debian.net/debian/pool/main/s/sphinx-autoapi/sphinx-autoapi_1.5.1-1.dsc I updated the package to the last upstream version, and it includes a few fixes. I'd appreciate if I could be given upload rights, that would help maintaining the package. Regards, -- Félix signature.asc Description: PGP signature
Re: todoman_3.7.0-2_source.changes ACCEPTED into unstable
Sandro also noted it, and it's already fixed. Thanks, -- Félix signature.asc Description: PGP signature
Re: khard_0.16.1-1_source.changes ACCEPTED into unstable
Note that changing the address triggers a lintian warning: W: khard source: mailing-list-obsolete-in-debian-infrastructure Python Applications Packaging Team -- Félix signature.asc Description: PGP signature
Re: khard_0.16.1-1_source.changes ACCEPTED into unstable
Sorry, I thought this had been updated! -- Félix signature.asc Description: PGP signature
Re: [felix+deb...@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1 [ITP]]
On 2020-04-20 21:53+0200, Thomas Goirand wrote: Well, I'm just trying to sponsor what you've uploaded to mentors, and so far, it didn't work (I just tried). Please try downloading the .dsc with dget and try yourself. Cheers, Thomas Goirand (zigo) How did you build the package? I just tried to "dget -x https://mentors.debian.net/debian/pool/main/s/sphinx-autoapi/sphinx-autoapi_1.3.0-1.dsc && sbuild sphinx-autoapi_1.3.0-1.dsc" and, again, that just worked, tests included. Regards, -- Félix signature.asc Description: PGP signature
Re: [felix+deb...@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1 [ITP]]
On 2020-04-20 16:16+0200, Thomas Goirand wrote: On 4/20/20 2:45 PM, Félix Sipma wrote: On 2020-04-20 12:06+0200, Thomas Goirand wrote: I'm not sure, the doc still accounts for half of the package. But let's pretend it's ok. We are talking about 80KB for the whole package. If it's not a blocker for you I prefer keeping it like that. Fine, ok. Now, the package contains a test suite. It'd be nice to run it. If you add, as dependency: python3-mock, python3-pytest, then pybuild runs the tests automatically. It needs to be overridden though, to avoid running integration tests which are failing (or these tests must be fixed). Can you do that? Then I'll happily upload... I added the dependencies, and disabled the integration tests which requires golang and dotnet sphinxcontrib extensions. I don't have the energy to package these myself... Of course! However, when I build the package: The text files are in build/sphinx/text. dh_auto_test -O--buildsystem=pybuild I: pybuild base:217: cd /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build; python3.8 -m unittest discover -v -- Ran 0 tests in 0.000s So, it's running zero tests now. I'm unsure what you did, but that's not correct. When it tried myself, a lot of tests ran with success. I added python3-mock and python3-pytest to actually run the tests, then I just disabled one specific test through `export PYBUILD_TEST_ARGS=-k-test_integration` I use `dgit sbuild` to build the package, and the other tests are actually ran (I just tried again)... ... The text files are in build/sphinx/text. dh_auto_test -O--buildsystem=pybuild I: pybuild base:217: cd /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build; python3.8 -m pytest -k-test_integration = test session starts == platform linux -- Python 3.8.2, pytest-4.6.9, py-1.8.1, pluggy-0.13.0 rootdir: /<> collected 235 items / 14 deselected / 221 selected tests/test_astroid_utils.py [ 19%] [ 52%] [ 77%] tests/test_domains.py .. [ 80%] tests/test_objects.py ...[ 83%] tests/python/test_parser.py .. [ 88%] tests/python/test_pyintegration.py .. [100%] === warnings summary === /usr/lib/python3/dist-packages/jinja2/sandbox.py:19 /usr/lib/python3/dist-packages/jinja2/sandbox.py:19: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.9 it will stop working from collections import Mapping tests/test_domains.py:147 /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/tests/test_domains.py:147: DeprecationWarning: invalid escape sequence \s self.assertEqual(ret, "With surrounding characters s :any:`FOO`\s") tests/test_domains.py:152 /<>/.pybuild/cpython3_3.8_sphinx-autoapi/build/tests/test_domains.py:152: DeprecationWarning: invalid escape sequence \s self.assertEqual(ret, "With surrounding characters s ``FOO``\s") .pybuild/cpython3_3.8_sphinx-autoapi/build/tests/python/test_pyintegration.py::TestSimpleModule::test_manual_directives .pybuild/cpython3_3.8_sphinx-autoapi/build/tests/python/test_pyintegration.py::test_napoleon_integration_loaded .pybuild/cpython3_3.8_sphinx-autoapi/build/tests/python/test_pyintegration.py::test_class_class_content .pybuild/cpython3_3.8_sphinx-autoapi/build/tests/python/test_pyintegration.py::test_both_class_content .pybuild/cpython3_3.8_sphinx-autoapi/build/tests/python/test_pyintegration.py::test_init_class_content .pybuild/cpython3_3.8_sphinx-autoapi/build/tests/python/test_pyintegration.py::test_hiding_inheritance .pybuild/cpython3_3.8_sphinx-autoapi/build/tests/python/test_pyintegration.py::test_inherited_members /usr/lib/python3/dist-packages/sphinx/domains/python.py:400: RemovedInSphinx40Warning: PyClassmember is deprecated. warnings.warn('PyClassmember is deprecated.', -- Docs: https://docs.pytest.org/en/latest/warnings.html 221 passed, 14 deselected, 10 warnings in 3.96 seconds create-stamp debian/debhelper-build-stamp dh_testroot -O--buildsystem=pybuild dh_prep -O--buildsystem=pybuild dh_auto_install -O--buildsystem=pybuild I: pybuild base:217: /usr/bin/
Re: [felix+deb...@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1 [ITP]]
On 2020-04-20 12:06+0200, Thomas Goirand wrote: I'm not sure, the doc still accounts for half of the package. But let's pretend it's ok. We are talking about 80KB for the whole package. If it's not a blocker for you I prefer keeping it like that. Now, the package contains a test suite. It'd be nice to run it. If you add, as dependency: python3-mock, python3-pytest, then pybuild runs the tests automatically. It needs to be overridden though, to avoid running integration tests which are failing (or these tests must be fixed). Can you do that? Then I'll happily upload... I added the dependencies, and disabled the integration tests which requires golang and dotnet sphinxcontrib extensions. I don't have the energy to package these myself... Could you please also give me the upload rights for this package when it will enter sid? Thanks again for your reviews. -- Félix signature.asc Description: PGP signature
Re: [felix+deb...@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1 [ITP]]
On 2020-04-19 23:18+0300, Dmitry Shachnev wrote: Better not symlink anything manually but use dh_sphinxdoc which will do it automatically: - Replace “--with python3” with “--with python3,sphinxdoc” in debian/rules. - Make python-sphinx-autoapi-doc depend on ${sphinxdoc:Depends}. - Drop Suggests: libjs-jquery, libjs-underscore as they will be in Depends. Thanks for pointing me to dh_sphinxdoc! I'll fix my other packages relying on sphinx to make use of it, too. Regards, -- Félix signature.asc Description: PGP signature
Re: [felix+deb...@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1 [ITP]]
On 2020-04-19 21:50+0200, Thomas Goirand wrote: On 4/19/20 5:24 PM, Félix Sipma wrote: I hope I fixed the issues you found Not really... :( Let's try again, then... Now the package is 2.7 MB, out of which the extracted library is only 380 KB. Now, the extracted documentation is 3.5 MB and contains 3 MB of fonts, like fontawesome and lato, which are already part of Debian. If everyone was doing like you, installing a small python app would download gigabytes of packages! :) Please: 1/ Push the docs into a separate package that you could call python-sphinx-autoapi-doc. 2/ Remove the embedded fonts fonts from that -doc package, and create symlinks to the appropriate files in the fonts-font-awesome and fonts-lato package. One little general advice now: use mc (or something similar) to go within the resulting .deb files after you've built them, so you can check its content. If you did that, you would have find the issues I'm describing above. For sure, getting a 2.7MB package for this small library is not good. I do display the list of the files after I build them, but I admit I usually don't look too closely to these, and rely on lintian warnings to see if fonts package are incorrectly embedded, if the resulting doc is too big and should be put to a separate package, etc. Maybe something changed recently on lintian (or in my config, but the warnings were not displayed on https://mentors.debian.net/package/sphinx-autoapi either) because I do not get the embedded fonts warnings I used to have... The resulting package is much smaller, I don't think it justifies another -doc package. Do you agree? Regards, -- Félix signature.asc Description: PGP signature
Re: [felix+deb...@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1 [ITP]]
On 2020-04-19 15:39+, Scott Kitterman wrote: As a member of the FTP Team, I see this situation from time to time. It's usually not a serious problem, but I agree with Zigo on this. Where it becomes problematic is when code in debian/ becomes intermingled with the installed upstream code. One has to look at the license of both upstream and debian/ to determine the effective license of the package. If the licenses are incompatible, then the binary isn't distributable. I have seen this happen. Aligning the license of the packaging with the upstream license makes it all much simpler. ... OK, it makes sense. Thanks for the rationale! If you intend to maintain this package in DPMT or PAPT, we have a standard gbp.conf for the teams that doesn't include this, so it would be inappropriate. In any case, it's the default for a format 3.0(Quilt) source package, so there's no need for it anyway: https://manpages.debian.org/testing/git-buildpackage/gbp-import-orig.1.en.html Scott K OK. I removed the setting. -- Félix signature.asc Description: PGP signature
Re: [felix+deb...@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1 [ITP]]
Hi Thomas, Thanks for the review, and it's nice to see you found a number of problems! I have to admit I did not prepare a new package since a long time, probably forgot a lot of things, and copied others from other packages of mine... On 2020-04-19 14:09+0200, Thomas Goirand wrote: Hi Felix, Thanks for working on this. Here's my comments. I'm sorry that there's a lot to say on what you did... :/ On 4/19/20 11:53 AM, Félix Sipma wrote: dget -x https://mentors.debian.net/debian/pool/main/s/sphinx-autoapi/sphinx-autoapi_1.2.1-1.dsc Looking at your debian/copyright, I'd strongly suggest releasing the Debian packaging under the same license. For me that's a blocker for sponsoring the package (it may be ok for others to sponsor). OK. I prefer using GPL-3+, but nevermind, I would really like to get this package in sid soon. Other sponsors are still to be found, so I turned it to Expat. You wrote in d/control as if the 2nd line of Description: was the continuation of the short description. This is not the case. Please write a proper short description (ie: the first line after "Description:") and a long description (what goes after that first line) as *not* the continuation of the first line. It's very much ok to repeat the short description in the long one. This is also a blocker for me to sponsor the package. Sorry about this, I guess I wanted to write a small description, forgot about it, and just put the long description instead. It should be fixed now. You're packaging the doc "as-is" without using Sphinx to build it. Any reason why, or you just don't know how yet? :) I'd suggest looking at other Python package building a -doc package to fix this. I'd also suggest packaging the doc in a separate -doc package. Woops, I guess I didn't look closely to the build logs... And I did this for a package used for generating doc: I should be punished for that :). Also, please remove: [import-orig] merge-mode = replace from debian/gbp.conf. This is typically something that goes into ~/.gbp.conf rather than on individual packages. I don't agree with you on this one. To me, this kind of setting should be put in the package, to have an uniform way of updating/building/etc. a given package, whoever the uploader could be. Can you explain in more details than in debian/rules why you're overriding override_dh_auto_clean ? What does it try to download, apart from the build dependencies? Can't you set $clean_source = 0; in your ~/.sbuildrc instead? Mmh, I don't remember about this... I probably copied it from another of my packages, without looking at it. It works without, so I removed it. I'll try to find what this other package is to see if I can fix it properly :-). Note that I found and patched another access to the internet during build (see 0001-Use-local-object-inventory-files-for-sphinx.patch). More generally, I disagree with needing special settings in ~/.sbuildrc (or other user configuration, or special command line arguments) before updating a package. I think that is just making life harder for (potential) future uploaders. I hope this helps, Sure, thanks! I have to say that I was starting filling quite demotivated because of not finding a sponsor for this little package... (And I have the same issue for other haskell packages, maybe I should finally complete the procedure to apply for becoming a DD...). I hope I fixed the issues you found and that you will agree with my argument for the debian/gbp.conf setting. The new package is at https://mentors.debian.net/debian/pool/main/s/sphinx-autoapi/sphinx-autoapi_1.3.0-1.dsc Regards, -- Félix signature.asc Description: PGP signature
[felix+deb...@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1 [ITP]]
Hi, Nobody answered on mentors, so I'm trying debian-python... If someone could have a look to this package and push it to the NEW queue, it would allow me to get a new version of khard in sid. Thanks, -- Félix --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "sphinx-autoapi", which is needed for the newest version of khard. * Package name: sphinx-autoapi Version : 1.2.1-1 Upstream Author : Read the Docs, Inc * URL : https://github.com/readthedocs/sphinx-autoapi/ * License : Expat * Vcs : https://salsa.debian.org/python-team/modules/sphinx-autoapi.git Section : python It builds those binary packages: python3-sphinx-autoapi - Sphinx AutoAPI provides "autodoc" style documentation for multiple programming languages without needing to load, run, or import the project being documented. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/sphinx-autoapi Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/sphinx-autoapi/sphinx-autoapi_1.2.1-1.dsc Changes since the last upload: * Initial release. (Closes: #955819). -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Félix signature.asc Description: PGP signature --- End Message --- signature.asc Description: PGP signature
Re: package_data in python package
On 2019-10-28 11:15-0400, Scott Kitterman wrote: > On Monday, October 28, 2019 11:02:40 AM EDT Félix Sipma wrote: >> On 2019-10-28 10:44-0400, Scott Kitterman wrote: >>> It's the way setuptools works. Looking at the current upstream >>> recommendations: >>> >>> https://python-packaging.readthedocs.io/en/latest/non-code-files.html >>> >>> your solution seems correct. >> >> Hi Scott, >> >> Thanks for your message. I'm not sure I get why upstream can't reproduce >> the problem in this case... setuptools, as used in the setup.py seems to >> install the data dir just fine, and without my patch. >> >> That's why I thought that it was maybe a limitation of dh-python... > > It does depend considerably on how you do the install. For example, to > replicate what pip does (to get the data files installed) you have to do: > > python setup.py install --single-version-externally-managed --record=/dev/null > > I don't find I need to do that with pybuild though. I find setuptools > handling > of data files highly mysterious and counter-intuitive, so I doubt I'll have > more specific advice. > > Scott K They just run "python3 setup.py install" (https://github.com/scheibler/khard/issues/231): $ python3 -m venv test-for-231 $ source test-for-231/bin/activate $ python3 setup.py install $ tree test-for-231/lib/python3.7/site-packages/khard-0.15.0-py3.7.egg test-for-231/lib/python3.7/site-packages/khard-0.15.0-py3.7.egg ├── EGG-INFO │ ├── dependency_links.txt │ ├── entry_points.txt │ ├── not-zip-safe │ ├── PKG-INFO │ ├── requires.txt │ ├── SOURCES.txt │ └── top_level.txt └── khard ├── actions.py ├── address_book.py ├── carddav_object.py ├── cli.py ├── config.py ├── data │ ├── config.spec │ └── template.yaml ├── helpers.py ├── __init__.py ├── khard.py ├── __main__.py ├── object_type.py └── version.py 3 directories, 20 files For my part, I "just" build the debian package with "gbp buildpackage", and with "dh $@ --with python3 --buildsystem=pybuild" in debian/rules. The solutions I say are: I can keep the patch in the package (without really understanding the need for it) or try to convince upstream to merge it (but they can't reproduce the problem, so why would they do that?). In both cases, probably others will encounter the same problem in other packages... It would be nice to fix the problem once for all (if possible :)). Regards, -- Félix signature.asc Description: PGP signature
Re: package_data in python package
On 2019-10-28 10:44-0400, Scott Kitterman wrote: > It's the way setuptools works. Looking at the current upstream > recommendations: > > https://python-packaging.readthedocs.io/en/latest/non-code-files.html > > your solution seems correct. Hi Scott, Thanks for your message. I'm not sure I get why upstream can't reproduce the problem in this case... setuptools, as used in the setup.py seems to install the data dir just fine, and without my patch. That's why I thought that it was maybe a limitation of dh-python... -- Félix signature.asc Description: PGP signature
package_data in python package
Hi, I have a problem with package_data files in a package ("khard", which is not currently under the debian-python umbrella but it is on my todo list to transfer it, I just didn't find the time yet) not getting installed. I submitted an error upstream, https://github.com/scheibler/khard/issues/231 but they can't reproduce the problem. I "fixed" the issue by adding a patch to add "khard/data/" to MANIFEST.in (with "recursive-include khard/data/ *"), but I don't get why this directory doesn't get installed by default... Is it because of a limitation of dh-python? Have I forgot an option somewhere? Link to the patch and the source of the package: https://sources.debian.org/src/khard/0.15.0-2/debian/patches/0003-add-khard-data-dir-to-MANIFEST.in.patch/ Thanks for your help! -- Félix signature.asc Description: PGP signature
joining PAPT
Hi, I'm already a member of DPMT, but I'd like to join PAPT to put some of the packages I maintain there (todoman and khard, and I still plan to work on these), and help in at least khal packaging. I still agree to follow the team policy. My login on salsa is felix-guest. Cheers, signature.asc Description: PGP signature
new version of python-icalendar
Hi, I pushed the latest release of python-icalendar (with an upstream fix to #908498 and with various fixes in the packaging) to salsa and uploaded it to ftp-master. I forgot I did not have the permissions to upload this package, so this failed. Could someone upload it for me? I put it on mentors: https://mentors.debian.net/debian/pool/main/p/python-icalendar/python-icalendar_4.0.3-1.dsc Thanks! signature.asc Description: PGP signature
Re: Move to salsa? Team structure preview ready
Hi, Do you plan changing the Vcs-fields for all packages automatically? I also noticed that this package: https://salsa.debian.org/python-team/modules/twodict is not accessible on salsa (and neither is accessible on alioth anymore). Is this expected? Thanks! signature.asc Description: PGP signature
salsa.debian.org
Hi, Is it intended to create an organisation for Python packaging soon? I'm asking because I'd like to start the packaging of a new module (python-twodict). Thanks, -- Félix signature.asc Description: PGP signature
Re: RFS: sphinx-autorun/1.0.4-1 [ITP]
sphinx-autorun is now updated to 1.1.0-1 on mentors. Could someone have a look to this package? I can't finish the packaging of todoman because of this build dependency... Thanks! On 2017-07-25 18:45+0200, Félix Sipma wrote: > Package: sponsorship-requests > Followup-For: Bug #863982 > > I updated the package on mentors to 1.0.4-1. > > -- System Information: > Debian Release: buster/sid > APT prefers unstable > APT policy: (990, 'unstable'), (500, 'stable'), (100, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US:en (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) signature.asc Description: PGP signature
Re: RFS: sphinx-autorun/1.0.4-1 [ITP]
Package: sponsorship-requests Followup-For: Bug #863982 I updated the package on mentors to 1.0.4-1. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) signature.asc Description: PGP signature
RFS: sphinx-autorun/1.0.3-1
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for "sphinx-autorun": sphinx-autorun - Code execution extension for Sphinx Package name: sphinx-autorun Version: 1.0.3-1 Upstream Author: Hugo Osvaldo Barrera Homepage: https://github.com/hobarrera/sphinx-autorun License: BSD-2-clause Section: python Download with dget: dget -x https://mentors.debian.net/debian/pool/main/s/sphinx-autorun/sphinx-autorun_1.0.3-1.dsc Or build it with gbp: gbp clone --pristine-tar https://anonscm.debian.org/git/python-modules/packages/sphinx-autorun.git cd sphinx-autorun gbp buildpackage This is needed to build todoman, another ITP of mine. If the person who sponsors the upload could also give me upload permissions for this package, that would be great! Thanks. signature.asc Description: PGP signature
Re: request to join the DPMT
On 2017-05-25 08:56+0200, Piotr Ożarowski wrote: > [Félix Sipma, 2017-05-18] >> I'd like to package and maintain sphinx-autorun >> https://github.com/hobarrera/sphinx-autorun which is needed to build another >> ITP of mine, todoman. It would be nice if I could do this in the DPMT. > > todoman looks like a package for PAPT, let me know if you want to join > this one too... > >> My alioth login is gueux-guest. >> >> I just subscribed to debian-python@lists.debian.org. I have read >> https://python-modules.alioth.debian.org/policy.html and I accept it. > > welcome on board! :) I'll be happy to be added to the PAPT, too. Note that I'd like to wait before adding todoman there, until the migration to git is complete (I've already started the packaging, and I don't use svn). I'd also like to add khard there. Thanks! signature.asc Description: PGP signature
request to join the DPMT
Hi, I'd like to package and maintain sphinx-autorun https://github.com/hobarrera/sphinx-autorun which is needed to build another ITP of mine, todoman. It would be nice if I could do this in the DPMT. My alioth login is gueux-guest. I just subscribed to debian-python@lists.debian.org. I have read https://python-modules.alioth.debian.org/policy.html and I accept it. Thanks! signature.asc Description: PGP signature