Re: The python command in Debian

2020-07-14 Thread Piotr Ożarowski
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

2020-03-30 Thread Piotr Ożarowski
> 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

2019-11-26 Thread Piotr Ożarowski
[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

2019-11-26 Thread Piotr Ożarowski
[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

2019-11-26 Thread Piotr Ożarowski
[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

2019-11-26 Thread Piotr Ożarowski
[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

2019-11-01 Thread Piotr Ożarowski
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.

2019-10-04 Thread Piotr Ożarowski
> 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

2019-09-30 Thread Piotr Ożarowski
[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

2019-07-23 Thread Piotr Ożarowski
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

2019-07-07 Thread Piotr Ożarowski
[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!

2019-07-07 Thread Piotr Ożarowski
[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

2019-07-07 Thread Piotr Ożarowski
[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

2019-03-28 Thread Piotr Ożarowski
[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

2019-03-28 Thread Piotr Ożarowski
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

2019-01-16 Thread Piotr Ożarowski
> 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

2019-01-14 Thread Piotr Ożarowski
> 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?

2019-01-09 Thread Piotr Ożarowski
> 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

2018-12-30 Thread Piotr Ożarowski
> Please add my DD account to DPMT group on salsa: vvidic
done :)



Re: Please add my DD account to DPMT

2018-12-29 Thread Piotr Ożarowski
[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

2018-11-29 Thread Piotr Ożarowski
[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

2018-11-22 Thread Piotr Ożarowski
[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

2018-10-23 Thread Piotr Ożarowski
> 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

2018-10-20 Thread Piotr Ożarowski
[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)

2018-10-12 Thread Piotr Ożarowski
[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)

2018-10-04 Thread Piotr Ożarowski
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)

2018-09-28 Thread Piotr Ożarowski
[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

2018-09-27 Thread Piotr Ożarowski
> > 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)

2018-09-25 Thread Piotr Ożarowski
[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

2018-08-27 Thread Piotr Ożarowski
> 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

2018-08-27 Thread Piotr Ożarowski
[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

2018-08-27 Thread Piotr Ożarowski
> 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

2018-08-22 Thread Piotr Ożarowski
> 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

2018-08-04 Thread Piotr Ożarowski
[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

2018-08-04 Thread Piotr Ożarowski
[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

2018-08-04 Thread Piotr Ożarowski
[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

2018-08-02 Thread Piotr Ożarowski
[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

2018-07-30 Thread Piotr Ożarowski
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?

2018-07-18 Thread Piotr Ożarowski
[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?

2018-07-16 Thread Piotr Ożarowski
[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?

2018-07-16 Thread Piotr Ożarowski
[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

2018-07-14 Thread Piotr Ożarowski
[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

2018-06-30 Thread Piotr Ożarowski
[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

2018-06-27 Thread Piotr Ożarowski
[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

2018-06-27 Thread Piotr Ożarowski
[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

2018-06-25 Thread Piotr Ożarowski
[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

2018-06-18 Thread Piotr Ożarowski
[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)

2018-06-10 Thread Piotr Ożarowski
[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

2018-06-04 Thread Piotr Ożarowski
[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

2018-05-28 Thread Piotr Ożarowski
> > 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

2018-05-18 Thread Piotr Ożarowski
[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)

2018-05-18 Thread Piotr Ożarowski
> 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)

2018-05-18 Thread Piotr Ożarowski
> 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)

2018-05-18 Thread Piotr Ożarowski
[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

2018-05-17 Thread Piotr Ożarowski
[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

2018-04-30 Thread Piotr Ożarowski
[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

2018-04-30 Thread Piotr Ożarowski
[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

2018-04-26 Thread Piotr Ożarowski
[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

2018-04-12 Thread Piotr Ożarowski
[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

2018-04-09 Thread Piotr Ożarowski
[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

2018-04-08 Thread Piotr Ożarowski
[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

2018-04-06 Thread Piotr Ożarowski
[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

2018-04-05 Thread Piotr Ożarowski
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

2018-04-05 Thread Piotr Ożarowski
[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

2018-04-05 Thread Piotr Ożarowski
[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

2018-04-05 Thread Piotr Ożarowski
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

2018-04-05 Thread Piotr Ożarowski
[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

2018-04-05 Thread Piotr Ożarowski
[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

2018-04-05 Thread Piotr Ożarowski
[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

2018-03-27 Thread Piotr Ożarowski
[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

2018-03-27 Thread Piotr Ożarowski
[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

2018-03-26 Thread Piotr Ożarowski
> > [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

2018-03-26 Thread Piotr Ożarowski
[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

2018-03-26 Thread Piotr Ożarowski
[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

2018-03-26 Thread Piotr Ożarowski
[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

2018-03-26 Thread Piotr Ożarowski
[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

2018-03-26 Thread Piotr Ożarowski
[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

2018-03-26 Thread Piotr Ożarowski
[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

2018-03-26 Thread Piotr Ożarowski
[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

2018-03-26 Thread Piotr Ożarowski
[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

2018-03-26 Thread Piotr Ożarowski
[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: Joining the DPMT

2018-03-26 Thread Piotr Ożarowski
[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

2018-03-26 Thread Piotr Ożarowski
[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: Request to join DPMT

2018-03-26 Thread Piotr Ożarowski
[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)

2018-03-26 Thread Piotr Ożarowski
[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

2018-03-26 Thread Piotr Ożarowski
[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

2018-03-26 Thread Piotr Ożarowski
[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

2018-03-26 Thread Piotr Ożarowski
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

2018-03-26 Thread Piotr Ożarowski
[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

2018-03-26 Thread Piotr Ożarowski
> 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

2018-03-26 Thread Piotr Ożarowski
[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

2018-03-26 Thread Piotr Ożarowski
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

2018-03-20 Thread Piotr Ożarowski
[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?

2018-02-14 Thread Piotr Ożarowski
[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

2018-02-13 Thread Piotr Ożarowski
[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

2018-02-12 Thread Piotr Ożarowski
> 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



Re: Move to salsa? Merge modules and apps team?

2018-02-12 Thread Piotr Ożarowski
Hi Andreas,

[Andreas Tille, 2018-02-12]
> On Wed, Feb 07, 2018 at 10:29:37AM +0100, Piotr Ożarowski wrote:
> > > And how about merging the modules and apps teams into one?
> > If not separated at team level, I definitely want to have them somehow
> > separated at repository level so that it's clear which package is which
> > type or to easily checkout libraries only.
> 
> If you ask me at least cython should go to Python Modules team.  Its
> not really just a random Python application and strongly connected
> to several Python modules.

Cython is a library. I don't care what the description says, if there
are other libraries or applications that import it (and thus it has to
go into dist-packages/) - it's a library from my POV (as we HAVE TO
treat it as a library in the toolchain, transitions, ...)

> I see other applications in python-apps that are for no reason there.
> We have no team C-apps or Perl-apps or ... LanguageX-apps.  These are

"others do it differently" never was and hopefully never will be a valid
argument for me. "Others achieve this and that thanks to doing it this
way" might.

> just random applications and could go to collab-maint (where the
> Git maintained packages of Python-apps team reside anyway).

please point me to them so that I can NMU them removing team from
debian/control
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645



Re: Move to salsa? Team structure preview ready

2018-02-08 Thread Piotr Ożarowski
Hi,

Thanks for pushing it forward

[Ondrej Novy, 2018-02-08]
> I created team "python-team" in salsa with 3 subgroups:
> interpreter
> modules
> packages

could you describe these groups? What goes into modules and what into
packages?
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645



Re: Move to salsa? Merge modules and apps team?

2018-02-07 Thread Piotr Ożarowski
[Ole Streicher, 2018-02-07]
> Piotr Ożarowski <pi...@debian.org> writes:
> > [W. Martin Borgert, 2018-02-07]
> >> And how about merging the modules and apps teams into one?
> >
> > I don't understand this, though. Why you want to merge them?
> > Sure, packaging Python applications is very similar to packaging
> > libraries but the difference is very significant - unfortunately many
> > application maintainers don't know or care about it and pollute global
> > Python namespace with private libraries.
> 
> So, why would you like to keep them separate?

Could you start with why do you want to merge them first?
If there are no advantages, why change?

> > If not separated at team level, I definitely want to have them somehow
> > separated at repository level so that it's clear which package is which
> > type or to easily checkout libraries only.
> 
> At least in the field where I package (astronomy), this does not work:
> many of our packages are libraries *and* apps. Often they come as a big
> (public) library with a small startup wrapper, and it is a matter of
> taste (and of how deep an astronomer digs into Python) whether it is
> used from the shell or from a Jupyter notebook.

well, if your application provides public library, it's a library to me
to be honest. It has to be taken care of in each transition and so on
so an additional tiny script in /usr/bin doesn't matter (I even install
such scripts in python*-foo binary packages)

> The rules for both are (should be) the same, right? So, what is the
> difference? 

the difference is you install an application in private dir and care
about default Python change only (less work for us, less disk space,
less buildd time, etc.) and less problems with conflicting names (why
would you bother searching for an unique name for a private lib?).
If you want to write a script that checks something in all of team
packages, it's easier if you can assume all of them are libraries.
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645



Re: Move to salsa? Merge modules and apps team?

2018-02-07 Thread Piotr Ożarowski
[W. Martin Borgert, 2018-02-07]
> how about moving the Python team(s) to salsa?

that's the natural place to move from alioth for both teams.
PAPT's repos will also have to be converted from svn to git.
All we need is a volunteer who will prepare it and supervise the
process.

> And how about merging the modules and apps teams into one?

I don't understand this, though. Why you want to merge them?
Sure, packaging Python applications is very similar to packaging
libraries but the difference is very significant - unfortunately many
application maintainers don't know or care about it and pollute global
Python namespace with private libraries.

If not separated at team level, I definitely want to have them somehow
separated at repository level so that it's clear which package is which
type or to easily checkout libraries only.

The only advantage I can see is less hassle with join requests, but
I don't think it's a big problem (you have to join once).

I also have a feeling the more packages (team members?) we have, the
less people care about packages without their name in
Maintainer/Uploaders fields (even those who did team-wide changes in the
past are not so active now, including myself) and the team name should
be changed to collab-maint-2 or collab-maint-py. 

> Moving git packages (modules team) is very easy using
> import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git

looks like it takes only one repo at a time
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645



  1   2   3   4   5   6   7   8   9   10   >