Hey, I would like to join the DPMT and PAPT team (yes, both! :D). I am a DM and maintain packages under the Ruby, Golang, JS, and the Perl team. My QA profile could be found here. Within the Python team, I would like to help maintain the existing packages, and also package a few new modules for a couple of upstream projects. My Salsa login is: utkarsh2102-guest I have read the policy and agree to it. : https://nm.debian.org/person/utkarsh2102 : https://qa.debian.org/developer.php?login=guptautkarsh2...@gmail.com : https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst Best, Utkarsh signature.asc Description: OpenPGP digital signature
Hi, I am one of the maintainers of the Charliecloud package . The most recent version of Charliecloud (0.10) has added new python dependencies (lark  and its dependencies). Some of them are not yet available in Debian. My salsa login is wiene-guest. I read the DPMT policy  and I accept it. Peter  https://tracker.debian.org/pkg/charliecloud  https://github.com/lark-parser/lark  https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
On 2019-07-27 22:04, Drew Parsons wrote: I've uploaded python-scipy 1.2.2 to unstable. Previously the build system ran through distutils, but dh now gives an error on that, and says pybuild should be used instead. So I reorganised debian/rules to use dh --buildsystem=pybuild. I also reorganised rules to stop the second invocation of dh in the build-arch rule. The build completes successfully. But it is taking 3 times longer than it did before. It is also using around 75% more disk space than before. ... Is an increase in build resources like this known to happen when pybuild is used instead of distutils? This seems to be why scipy 1.2.2-1 used more build resources: scipy modules are built in 2 steps: 1) setup.py config_fc --noarch build (with override_dh_auto_configure) 2) setup.py install ... --force --no-compile (with override_dh_auto_install) Previously (building with distutils), both steps built via a build/src.linux-x86_64-* builddir, so the --no-compile flag meant object files were not compiled twice. Now with pybuild, the config_fc step is still built in build/src.linux-x86_64-*, but the install step is handled via build/src.linux-amd64-*. So object files are compiled twice, first for x86_64, and then for amd64. Likewise arm64 first "configures" builds in an aarch64 builddir, and then "installs" via arm64. Looks like some discrepancy between setup.py config_fc and pybuild's setup.py install in handling DEB_*_ARCH_CPU and DEB_*_GNU_CPU. DEB_*_CPU is not used explicitly by scipy's debian/rules. Is setup.py config_fc even needed? Is it a hangover from distutils and not needed in a pybuild build? It's not well documented and not listed by "python3 setup.py --help-commands", though is mentioned in INSTALL.rst.txt (with a brief reference in scipy/special/setup.py and scipy/integrate/setup.py). But debian/rules doesn't use it with --fcompiler to specific the fortran compiler. Drew
Hi, Python folks. I think help is needed regarding #932584 python-pydoctor: Epydoc will be removed It seems to be languishing rather. What I don't understand is why pydoctor depends on epydoc given that, in the words of the Description: [Pydoctor] was written primarily to replace epydoc ... I had a quick look through the source but I don't know enough about pydoctor to make immediate sense of the results of my grep. Maybe some person who knows more about pydoctor can help ? (I'm CCing this to the gbp maintainers because this came to my attention due to an autoremoval bug where a package of mine has a dependency chain via gbp.) Thanks, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Hi, so 27. 7. 2019 v 15:41 odesílatel Otto Kekäläinen napsal: > I would like to join the Python packaging team. > welcome :) -- Best regards Ondřej Nový