Request to join the Python team

2019-07-28 Thread Utkarsh Gupta

I would like to join the DPMT and PAPT team (yes, both! :D).

I am a DM[1] and maintain packages under the Ruby, Golang, JS, and the Perl 
My QA profile could be found here[2].

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[3] and agree to it.



Description: OpenPGP digital signature

Joining the DPMT

2019-07-28 Thread Peter Wienemann

I am one of the maintainers of the Charliecloud package [0]. The most
recent version of Charliecloud (0.10) has added new python dependencies
(lark [1] and its dependencies). Some of them are not yet available in

My salsa login is wiene-guest.

I read the DPMT policy [2] and I accept it.



Re: increased build time and disk usage for scipy with pybuild

2019-07-28 Thread Drew Parsons

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


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) config_fc --noarch build (with override_dh_auto_configure)
2) install ... --force --no-compile (with 

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 config_fc and pybuild's install in handling DEB_*_ARCH_CPU and DEB_*_GNU_CPU.

DEB_*_CPU is not used explicitly by scipy's debian/rules.

Is 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 --help-commands", though is mentioned in 
INSTALL.rst.txt (with a brief reference in scipy/special/ and 
scipy/integrate/ But debian/rules doesn't use it with 
--fcompiler to specific the fortran compiler.


Please help fix pydoctor

2019-07-28 Thread Ian Jackson
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

  [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.)


Ian JacksonThese opinions are my own.

If I emailed you from an address or, that is
a private address which bypasses my fierce spamfilter.

Re: Request to join Python team

2019-07-28 Thread Ondrej Novy

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ý