Request to join the Python team

2019-07-28 Thread Utkarsh Gupta
Hey,

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 
team.
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.

[1]: https://nm.debian.org/person/utkarsh2102
[2]: https://qa.debian.org/developer.php?login=guptautkarsh2...@gmail.com
[3]: 
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst


Best,
Utkarsh




signature.asc
Description: OpenPGP digital signature


Joining the DPMT

2019-07-28 Thread Peter Wienemann
Hi,

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
Debian.

My salsa login is wiene-guest.

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

Peter

[0] https://tracker.debian.org/pkg/charliecloud
[1] https://github.com/lark-parser/lark
[2]
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst



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
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



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



Re: Request to join Python team

2019-07-28 Thread Ondrej Novy
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ý