Re: New Python project

2020-12-12 Thread Andrey Rahmatullin
On Sat, Dec 12, 2020 at 01:56:46PM +0100, Nyírő Balázs wrote:
> Can you help me to give the steps
> that how can a new project be placed in Debian repos?
https://mentors.debian.net/intro-maintainers/ has the outline. But please
note the "Please do not treat Debian as a platform to advertise your own
software, unless there is some real request for it." part.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Error in build time tests (Was: numpy breaks nipy autopkgtest: No module named 'numpy.testing.decorators')

2020-12-08 Thread Andrey Rahmatullin
On Tue, Dec 08, 2020 at 09:44:51PM +0100, Andreas Tille wrote:
> > https://github.com/nipy/nipy/issues/461
> 
> As far as I can see that's included into 0.4.3~rc1.
If by "it" you mean requiring sympy older than the Debian one then yes.
But the package evidently doesn't enforce this requirement.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: How to run unit tests?

2020-12-08 Thread Andrey Rahmatullin
On Tue, Dec 08, 2020 at 09:33:03PM +0100, Peter Wienemann wrote:
> Dear Python experts,
> 
> in trying to update the python-lark package [0] to the most recent upstream
> version, an interesting issue regarding unit tests showed up [1]. Depending
> on how one runs unit tests they either fail or not. Tried options are:
> 
> 1. PYTHONWARNINGS=d pythonX -m unittest discover -v tests
> 2. pythonX setup.py test
> 3. pythonX -m tests
Option 3 runs
https://github.com/lark-parser/lark/blob/master/tests/__main__.py which
mostly just runs unittest.main().
Option 2 seems to run the same file according to setup.py.
I'm not familiar with unittests enough know the difference between options
1 and 3.
You didn't explain what actual problems do you have, but
https://github.com/lark-parser/lark/issues/792 suggests that some way you
used was skipping some of the tests?

> Upstream uses option 3 in its CI testing [2] and did not see any issues with
> lark release 0.11.1. dh_auto_test seems to use option 2 by default (for the
> pybuild build system). For autopkgtest I have chosen to use option 1. The
> latter two options both fail for version 0.11.1. 
Which is good?

> After applying a patch provided by upstream [3], also option 2 works but 
> option 1 still fails.
Which is good or bad? I'm not sure.

> Upstream suggested to change the way the (autopkgtest) tests are run [4].
So are you asking only about autopkgtests, not build-time tests?

> Is there something like a general recommendation on what is the best way
> to run Python unit tests?
No (except "whatever the upstream CI runs").

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Error in build time tests (Was: numpy breaks nipy autopkgtest: No module named 'numpy.testing.decorators')

2020-12-08 Thread Andrey Rahmatullin
On Tue, Dec 08, 2020 at 07:02:22PM +0100, Andreas Tille wrote:
> TypeError: unsupported operand type(s) for *: 'GreaterThan' and 'Add'
Consider starting to use Google to find at least some info related to
questions you ask.

https://github.com/nipy/nipy/issues/461

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Python3.9 issue: '"yield from" can't be applied to "Condition"' (Was: Bug#976779: mypy FTBFS with only python 3.9)

2020-12-08 Thread Andrey Rahmatullin
On Tue, Dec 08, 2020 at 01:27:57PM +0100, Andreas Tille wrote:
> test-data/samples/crawl.py:750: error: "yield from" can't be applied to 
> "Condition"
> test-data/samples/crawl.py:772: error: "yield from" can't be applied to 
> "Semaphore"
> test-data/samples/crawl.py:778: error: "yield from" can't be applied to 
> "Condition"
https://github.com/python/mypy/pull/9375

Also https://github.com/python/mypy/issues/9761

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: python3-(py)crypto(dome)?

2020-12-05 Thread Andrey Rahmatullin
On Sat, Dec 05, 2020 at 06:29:32PM +0100, Martin wrote:
> The fix in wokkel should not lead to a problem after the next upload of
> python3-pycryptodome.
I disagree. Currently wokkel clearly has a problem and it's most lilely a
typo. If python3-pycryptodome will be renamed to python3-cryptodome, that
will be a separate matter, and it will most likely be done via a
transition package so wokkel won't need a revert.


-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: python3-(py)crypto(dome)?

2020-12-05 Thread Andrey Rahmatullin
On Sat, Dec 05, 2020 at 02:43:44PM +0100, Martin wrote:
> Dears,
> 
> I'm a little confused about what the correct name for the
> binary package python3-pycryptodome should or will be.
Depends on the module name it provides.
So python3-cryptodome, it seems.

> Because https://bugs.debian.org/891619 talks about renaming it
> and/or providing python3-crypto.
If it doesn't provide a "crypto" module it shouldn't be named
python3-crypto.
I don't know what did the reporter mean in their first message.

> Package wokkel has changed the dependency from python3-crypto to
> python3-cryptodome, leading to #975748 and #975770.
The changelog entry says "Switch to python3-pycryptodome" but the control
field says "python3-cryptodome". This is a bug in python3-wokkel,
unrelated to the initial question here.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: How to watch pypi.org

2020-10-31 Thread Andrey Rahmatullin
On Sat, Oct 31, 2020 at 12:03:50PM +0100, Thomas Goirand wrote:
> Pypi is often thought as a Python module source repository. It is *NOT*.
> It is a repository for binaries to be consumed by pip.
Oooh, that's a very interesting thought I never considered.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: How to watch pypi.org

2020-10-30 Thread Andrey Rahmatullin
On Fri, Oct 30, 2020 at 03:18:58PM +0100, Fioddor Superconcentrado wrote:
> As I said I'm very new to this and all (python) packages I'm using lately
> use the usual python tools (pipy, setup.py, etc) and my first approach has
> been to stick as close as possible to the upstream procedures. But I might
> very likely be taking a wrong decision. What are the reasons to go for git
> instead of pypi? I see that it is 'more upstream' but it seems that
> everyone else is pointing to pypi as a distro-agnostic solution.
One reason is tarballs may be missing some files, including tests.

> El lun., 5 oct. 2020 a las 4:24, Paul Wise () escribió:
> 
> > On Sun, Oct 4, 2020 at 3:29 PM Fioddor Superconcentrado wrote:
> >
> > > I've packaged a project provided via https://pipi.org and I wanted to
> > create a debian/watch file but pipi.org publishes the tarball behind a
> > strange url like
> >
> > I would suggest using the upstream git repo instead of the PyPi tarballs.
> >

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Bug#971111: gubbins: FTBFS: pkg_resources.extern.packaging.requirements.InvalidRequirement: Parse error at "'/build/g'": Expected W:(abcd...)

2020-10-30 Thread Andrey Rahmatullin
python/gubbins/common.py::parse_and_run() constructs an absolute path for
the executable and then passes it to pkg_resources.get_distribution(). I
have no idea what does this code want to achieve, as get_distribution()
takes requirement specifications, not file paths.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: help with FTBFS bug due to python3.8/3.9 confusion

2020-10-26 Thread Andrey Rahmatullin
On Mon, Oct 26, 2020 at 08:54:37AM +0100, Stephen Sinclair wrote:
> The recommendations are to change the build-dep on "python-dev" to
> "python-all-dev", and I can confirm that this does allow the package
> to build.  (Is this the right thing to do?)
Building a module for all supported Python versions is a right thing to
do.

> However, autopkgtest tests still fail.  The commenter in that bug
> report claims, "the lack of 3.8 modules in the package also explains
> your problem."  However, I do not understand that claim -- wouldn't it
> be counter-productive to specify which minor version of Python the
> package depends on?  I would need to update this manually when the
> default switches to Python 3.9.
If you are packaging a public module you need to provide it for all
supported Python versions.
Not sure which tests fail and how, I don't think this is described
anywhere?

> Although the CMake build is quite complicated and therefore I can
> expect such problems, but I am nonetheless confused why it would
> select the wrong Python version, as I do specify the Python executable
> via the command,
> 
> > -DPYTHON_EXECUTABLE=$(shell which python3)"
> 
> Is there a better way to find the path to the default python interpreter?
When building a public module you don't need to care about the default
version.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: python3- preffix

2020-10-04 Thread Andrey Rahmatullin
On Sun, Oct 04, 2020 at 05:39:16PM +0200, Fioddor Superconcentrado wrote:
> Debian's packaging documentation requires the packages containing python3
> apps to be renamed with a python3 suffix. 
*apps* shouldn't have a prefix, only modules should.

> Now I can put that prefix to the source too or not.
No. The current best practices for source package names for Python module
packages are either just foo or python-foo and this wasn't changed when
dropping py2.

> if I don't I get a conflict warning.
What do you mean?


-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: How to watch pypi.org

2020-10-04 Thread Andrey Rahmatullin
On Sun, Oct 04, 2020 at 05:28:57PM +0200, Fioddor Superconcentrado wrote:
> I've packaged a project provided via https://pipi.org and I wanted to
> create a debian/watch file but pipi.org publishes the tarball behind a
> strange url like
> 
> https://files.pythonhosted.org/packages/d6/72/9848a2d631dad70d7ea582540f0619e1a7ecf31b3a117de9d9f2b6b28029/django-settings-export-1.2.1.tar.gz
> 
> I guess pypi.org is a common source of python code so perhaps there's
> already a solution for this.
The solution (that transparently uses pypi.debian.net) is described in
uscan(1).

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Merging the PAPT and the DMPT

2020-08-28 Thread Andrey Rahmatullin
Can you please also describe the current plans for changing/not changing
the Git paths after the merge?

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: mismatched-python-substvar ${python3:Depends}

2020-07-08 Thread Andrey Rahmatullin
On Wed, Jul 08, 2020 at 03:35:19AM -0300, Pablo Mestre wrote:
> Hi
> 
> Im start packaging python-jsonrpc-server[1], but im dealing with an
> lintian warning thats I dont understand
> 
> W: python-jsonrpc-server source: mismatched-python-substvar
> python-jsonrpc-server ${python3:Depends}
> N:
> N:    The specified package declares a dependency on ${python:Depends}
> whilst
> N:    appearing to be a Python 3.x package or a dependency on
> N:    ${python3:Depends} when it appears to be a package for Python 2.x.
Py3 packages should be named python3-foo.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: packaging DiscoDOS - a cli tool for vinyl DJs

2020-05-18 Thread Andrey Rahmatullin
On Mon, May 18, 2020 at 11:24:23AM +0200, jojo wrote:
> One question: Often I read the workflow is to first create a source
> package and then the binary package from it. Is that true for python
> tools as well? 
Yes.

> I mean there is no "source/binary" in this sense.
It doesn't matter whether there are sources and binaries. There is still a
source package and a binary package created from it.

> And this does not seem to be a source package but a regular
> package I would install as user using apt:
> https://salsa.debian.org/python-team/applications/rename-flac.git
No, you cannot install a git repo with apt.
Binary packages are .deb files.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: pauvre is missing sklearn despite the package is installed

2020-04-27 Thread Andrey Rahmatullin
On Mon, Apr 27, 2020 at 01:17:50PM +0200, Andreas Tille wrote:
> pkg_resources.DistributionNotFound: The 'sklearn' distribution was not found 
> and is required by pauvre
It's actually called scikit-learn, not sklearn, see e.g.
/usr/lib/python3/dist-packages/scikit_learn-0.22.2.post1.egg-info and
https://pypi.org/project/sklearn/

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: pybuild and setup.py in unusual place

2020-04-17 Thread Andrey Rahmatullin
On Fri, Apr 17, 2020 at 08:10:34AM +, PICCA Frederic-Emmanuel wrote:
> subsidiary question is it possible to run a command before  all the 
> dh_auto_xxx without overrideing eveythings ?
See "Injecting commands before or after a step" in dh(1).

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: pybuild and setup.py in unusual place

2020-04-17 Thread Andrey Rahmatullin
On Fri, Apr 17, 2020 at 07:31:55AM +, PICCA Frederic-Emmanuel wrote:
> Hello, I have a packahe where the setup.py is not located at the root of the 
> directory.
> 
> So I need to do 
> 
> override_dh_auto_XXX:
> dh_auto_XXX -- -d 
> 
> Is there a export somthing whcih allows to says where is the setup.py to deal 
> with ?
Just pass that -D to dh(1)? (assuming you meant -D and not -d).

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: where should we put private libraries

2020-04-12 Thread Andrey Rahmatullin
On Sun, Apr 12, 2020 at 03:18:39PM +0200, picca wrote:
> I thought about adding rpath to these libraries in order to move then
> under a private  location /usr/lib/. 
This looks like the correct way to solve this.

> The issue is that the current build system do not provide rpath for
> these libraries so I can not add one via chrpath.
Well, ideally you need to fix the build system so that it sets the correct
rpath directly.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: packaging manual for a beginner

2020-04-08 Thread Andrey Rahmatullin
On Tue, Apr 07, 2020 at 08:13:02PM +0200, Alex Mestiashvili wrote:
> Hi Debian Python folks,
> 
> Is there a good entry point for a newbie who wants to package a python
> module? I am looking for a tool similar to dh-make-perl. In the past
> I've been using stdeb as far as I remember, but it is somehow painful
> compared to other dh-make-x helpers.
> A link with step-by-step instructions would be also helpful. Sorry but I
> am unable to find Debian documentation suitable for a newcomer.
There is https://wiki.debian.org/Python/LibraryStyleGuide but it doesn't
cover the very first steps.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: [RFC] python-cobra, python3-sbml5

2020-04-04 Thread Andrey Rahmatullin
On Sat, Apr 04, 2020 at 06:53:55PM +0530, Nilesh Patra wrote:
> >From the logs, in the last message[2] it looks like an import-error for
> '_libsbml' file which corresponds to libsbml (with python3-sbml5 as a
> provide) package. When I dug into looking at libsbml, I noticed that the
> relevant file (libsbml.py) which throws error
> is generated with swig-3.0 by the upstream [3]
> 
> While the same file in the apt archive (observed after $apt source
> python3-sbml5) seems to be generated with swig-4.0, and that's the current
> swig version in Debian now.
Sorry, I couldn't understand which two files are you comparing. One is
from the python3-sbml5 binary package and is generated with swig 4, where
is the second one, generated by swig 3?

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Python help needed for test suite in multiqc

2020-03-25 Thread Andrey Rahmatullin
On Wed, Mar 25, 2020 at 08:31:10PM +0100, Andreas Tille wrote:
> Hi Python folks,
> 
> the Debian Med team intends to package multiqc[1].  When running the build
> time tests I get:
> 
> 
> ...
>debian/rules override_dh_auto_test
> make[1]: Verzeichnis „/build/multiqc-1.8+dfsg“ wird betreten
> cp -a multiqc*.egg-info 
> /build/multiqc-1.8+dfsg/.pybuild/cpython3_3.8_multiqc/build
> PYTHONPATH=/build/multiqc-1.8+dfsg/.pybuild/cpython3_3.8_multiqc/build 
> dh_auto_test
> I: pybuild base:217: cd 
> /build/multiqc-1.8+dfsg/.pybuild/cpython3_3.7_multiqc/build; python3.7 -m 
> unittest discover -v 
> multiqc (unittest.loader._FailedTest) ... ERROR
> 
> ==
> ERROR: multiqc (unittest.loader._FailedTest)
> --
> ImportError: Failed to import test module: multiqc
> Traceback (most recent call last):
>   File "/usr/lib/python3.7/unittest/loader.py", line 470, in _find_test_path
> package = self._get_module_from_name(name)
>   File "/usr/lib/python3.7/unittest/loader.py", line 377, in 
> _get_module_from_name
> __import__(name)
>   File 
> "/build/multiqc-1.8+dfsg/.pybuild/cpython3_3.7_multiqc/build/multiqc/__init__.py",
>  line 16, in 
> from .multiqc import run
>   File 
> "/build/multiqc-1.8+dfsg/.pybuild/cpython3_3.7_multiqc/build/multiqc/multiqc.py",
>  line 38, in 
> from .utils import report, plugin_hooks, megaqc, util_functions, 
> lint_helpers, config, log
>   File 
> "/build/multiqc-1.8+dfsg/.pybuild/cpython3_3.7_multiqc/build/multiqc/utils/log.py",
>  line 7, in 
> import coloredlogs
>   File "/usr/lib/python3/dist-packages/coloredlogs/__init__.py", line 192, in 
> 
> from humanfriendly.terminal import ANSI_COLOR_CODES, ansi_wrap, 
> terminal_supports_colors
> ModuleNotFoundError: No module named 'humanfriendly.terminal'
http://bugs.debian.org/954640

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: About itsdangerous

2020-02-27 Thread Andrey Rahmatullin
On Thu, Feb 27, 2020 at 05:02:32PM +0100, Julien Puydt wrote:
> > https://alioth-archive.debian.org/git/collab-maint/python-itsdangerous.git.tar.xz
> > 
> 
> I must be going through a very bad day, but trying to follow 
> https://wiki.debian.org/Salsa/AliothMigration#By_hand doesn't work ;
> the two git checkout commands (both pristine-tar and upstream) give:
> error: pathspec 'pristine-tar' did not match any file(s) known to git
> 
> Are we sure the original git repository had the correct structure
> anyway?
It indeed doesn't use pristine-tar. Its upstream branch is named master
(as you can check in debian/gbp.conf) and looks like a clone of the
upstream repo master branch. OTOH the last release there repacks the
tarball and so uses the master-dfsg branch instead.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: About itsdangerous

2020-02-27 Thread Andrey Rahmatullin
On Thu, Feb 27, 2020 at 12:57:49PM +0100, Julien Puydt wrote:
> Le jeudi 27 février 2020 à 15:49 +0500, Andrey Rahmatullin a écrit :
> > On Thu, Feb 27, 2020 at 11:33:00AM +0100, Julien Puydt wrote:
> > > Hi,
> > > 
> > > I saw python3-itsdangerous was far behind upstream, and decided to
> > > if
> > > it was easy to update : but it's not on salsa.
> > > 
> > > Should I import the last known package version (recent upload to
> > > remove
> > > the Python 2 package) to a new salsa repository and start from
> > > here?
> > I think you should import the alioth backup and import the last
> > upload on
> > top of it.
> 
> Hmmm... I searched for "itsdangerous":
> - on salsa ( 
> https://salsa.debian.org/search?utf8=%E2%9C%93=itsdangerous_id=_id=_ref=_source=navbar
> ) : nothing
> - on https://alioth-archive.debian.org/git/ : nothing
https://alioth-archive.debian.org/git/collab-maint/python-itsdangerous.git.tar.xz

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: About itsdangerous

2020-02-27 Thread Andrey Rahmatullin
On Thu, Feb 27, 2020 at 11:33:00AM +0100, Julien Puydt wrote:
> Hi,
> 
> I saw python3-itsdangerous was far behind upstream, and decided to if
> it was easy to update : but it's not on salsa.
> 
> Should I import the last known package version (recent upload to remove
> the Python 2 package) to a new salsa repository and start from here?
I think you should import the alioth backup and import the last upload on
top of it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: git-buildpackage to be autoremoved due to python2 transition

2020-02-26 Thread Andrey Rahmatullin
On Wed, Feb 26, 2020 at 12:14:08PM +, Ian Jackson wrote:
> I looked again and I was looking at an old version.  Sorry for the
> noise.  I still think we have problems with these
>   937132 nevow: Python2 removal in sid/bullseye
>   938622 tahoe-lafs: Python2 removal in sid/bullseye
> which I think are brought in by pydoctor...
As you can see with reverse-depends or dak, there is no packages depending
on these two (after pydoctor was ported, I guess).

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: git-buildpackage to be autoremoved due to python2 transition

2020-02-26 Thread Andrey Rahmatullin
On Wed, Feb 26, 2020 at 11:28:03AM +, Ian Jackson wrote:
> FYI.  The widespread impact of this not so apparent because
> git-buildpackage is typically used ad-hoc by maintainers, rather than
> via (Build)-Depends.
> 
> Relevant packages and bugs:
>  943107 git-buildpackage: Python2 removal in sid/bullseye
>  937132 nevow: Python2 removal in sid/bullseye
>  938622 tahoe-lafs: Python2 removal in sid/bullseye
> 
> Bugs which you may notice which are now not so relevant any more
> because they have been fixed in sid (but not yet migrated):
>  950216 [git-buildpackage] missing xsltproc autopkg test dependency
>   Fixed in sid; migration blocked by FTBFS due to pydoctor
>   breakage (#949232).  When pydoctor has migrated, reattempting
>   build (eg by re-upload) should fix this.
>  949232/948831 [pydoctor] needs to depend on cachecontrol
>  952546 [pydoctor] d/copyright & DFSG issues
>  937421 [pydoctor] Python2 removal in sid/bullseye
Yes, and as far as I can see after pydoctor migrates the only problem with
gbp will be python-rpm in debian/tests/control, which is probably
unneeded.

> the py2 rot seems wider including in gbp itself.
Where exactly?

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: application and private module extension

2020-02-03 Thread Andrey Rahmatullin
On Mon, Feb 03, 2020 at 02:32:22PM +, PICCA Frederic-Emmanuel wrote:
> Hello,
> 
> I am packaging a python application . So I dediced to put the  module under 
> the private directory
> 
> /usr/share/
> 
> but this software contain a cython extension.
> 
> So at the end I have a lintian Error due to  binary  file under /usr/share.
> 
> What is the best soltuion when we need to package a softare with this kind of 
>  extension.
/usr/lib of course.
See also 
https://www.debian.org/doc/packaging-manuals/python-policy/programs.html#current_version_progs

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: python3-distutils is not a separate package in stretch - uninstallable package in stretch-backports

2020-01-22 Thread Andrey Rahmatullin
On Wed, Jan 22, 2020 at 06:59:18PM +0100, Julien Puydt wrote:
> Le mercredi 22 janvier 2020 à 21:04 +0500, Andrey Rahmatullin a écrit :
> > On Wed, Jan 22, 2020 at 04:53:22PM +0100, Julien Puydt wrote:
> > > Hi,
> > > 
> > > I'm trying to solve this bug on python3-setuptools-scm :
> > > 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928156
> > > 
> > > where the problem is :
> > > - python3-setuptools-scm depends on python3-distutils
> > > - python3-distutils is not a separate package in stretch-backports.
> > > 
> > > I think the solution of the problem doesn't rest on my shoulders :
> > > the
> > > package which does the job of python3-distutils in stretch-
> > > backports
> > > should "Provides: python3-distutils".
> > I think that the backport should depend on packages it needs instead
> > of
> > non-existing ones.
> 
> So you agree the problem isn't mine, but disagree on the solution?
The problem isn't yours but the person who made the backport. This isn't
what you meant though. If you are asking whether it's the problem in the
backport or in the packages in stretch, the problem is in the backport.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: python3-distutils is not a separate package in stretch - uninstallable package in stretch-backports

2020-01-22 Thread Andrey Rahmatullin
On Wed, Jan 22, 2020 at 04:53:22PM +0100, Julien Puydt wrote:
> Hi,
> 
> I'm trying to solve this bug on python3-setuptools-scm :
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928156
> 
> where the problem is :
> - python3-setuptools-scm depends on python3-distutils
> - python3-distutils is not a separate package in stretch-backports.
> 
> I think the solution of the problem doesn't rest on my shoulders : the
> package which does the job of python3-distutils in stretch-backports
> should "Provides: python3-distutils".
I think that the backport should depend on packages it needs instead of
non-existing ones.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Help needed (Was: Bug#943083: libncl: Python2 removal in sid/bullseye)

2019-12-16 Thread Andrey Rahmatullin
On Mon, Dec 16, 2019 at 11:07:07AM +0100, Andreas Tille wrote:
> I'm afraid 2to3 skipped this very file.  I retried manually:
> 
> $ 2to3 -w roundTripNCLTest.py 
> RefactoringTool: Skipping optional fixer: buffer
> RefactoringTool: Skipping optional fixer: idioms
> RefactoringTool: Skipping optional fixer: set_literal
> RefactoringTool: Skipping optional fixer: ws_comma
> RefactoringTool: Can't parse roundTripNCLTest.py: ParseError: bad input: 
> type=22, value='=', context=('', (41, 93))
> RefactoringTool: No files need to be modified.
> RefactoringTool: There was 1 error:
> RefactoringTool: Can't parse roundTripNCLTest.py: ParseError: bad input: 
> type=22, value='=', context=('', (41, 93))
It worked for me, but didn't change that line.

ii  2to3   3.7.5-3  all  2to3 binary using python3

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Help needed (Was: Bug#943083: libncl: Python2 removal in sid/bullseye)

2019-12-16 Thread Andrey Rahmatullin
On Mon, Dec 16, 2019 at 09:17:50AM +0100, Andreas Tille wrote:
> inputParentPath = lineIter.next().strip()
> AttributeError: '_io.StringIO' object has no attribute 'next'
This should be changed to next(lineIter).strip(), 2to3 for some reason
missed it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye)

2019-12-13 Thread Andrey Rahmatullin
On Fri, Dec 13, 2019 at 10:10:03PM +0100, Andreas Tille wrote:
> i$ pdb2pqr
> Traceback (most recent call last):
>   File "/usr/bin/pdb2pqr", line 52, in 
> from main import mainCommand
>   File "/usr/share/pdb2pqr/main.py", line 77, in 
> import extensions
>   File "/usr/share/pdb2pqr/extensions/__init__.py", line 56, in 
> extDict[extName] = __import__(extName,globals(),locals(),[], -1)
> ValueError: level must be >= 0

"""
level specifies whether to use absolute or relative imports. The default
is -1 which indicates both absolute and relative imports will be
attempted. 0 means only perform absolute imports.  Positive values for
level indicate the number of parent directories to search relative to the
directory of the module calling __import__().
"""
https://docs.python.org/2.7/library/functions.html#__import__

-1 was removed in 3.3 as implicit relative import are not supported in
3.x. As this code seems to use relative imports you need to change -1 to
1.

> So I tried:
> 
> --- a/extensions/__init__.py
> +++ b/extensions/__init__.py
> @@ -53,7 +53,7 @@ _extList = [name for _, name, _ in 
> pkgutil.iter_modules(__path__)]
>  extDict = {}
>  
>  for extName in _extList:
> -extDict[extName] = __import__(extName,globals(),locals(),[], -1)
> +extDict[extName] = __import__(extName,globals(),locals(),[], 0)^M

Mindlessly changing the code is almost always a bad idea...

>   File "/usr/share/pdb2pqr/extensions/__init__.py", line 57, in 
> extDict[extName] = __import__(extName,globals(),locals(),[], 0)
> ModuleNotFoundError: No module named 'chi'
This is expected as it now tries to do "import chi". With 1 it should try
"from . import chi". This fails later, as the source also has implicit
relative imports that needs to be fixed, for example "from aconf import"
in src/utilities.py.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Bug#937262: Help with scons needed (Was: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye))

2019-12-13 Thread Andrey Rahmatullin
On Fri, Dec 13, 2019 at 03:49:22PM +0100, Andreas Tille wrote:
> > g++ -o pdb2pka/substruct/Algorithms.cpython-37m-x86_64-linux-gnu.so 
> > -Wl,-z,relro -Wl,-z,now -shared pdb2pka/substruct/Algorithms.os -L/usr/lib 
> > -lpython3.7m -lpython3.7
> > /usr/bin/ld: cannot find -lpython3.7
> > collect2: error: ld returned 1 exit status
> > ...
> > 
> > AAArgh, now we just need to get rid of the unwanted stuff.  Any scons
> > expert around?
> 
> I think at least this is solved now:
> 
>
> https://salsa.debian.org/med-team/pdb2pqr/commit/1f4ee901456641140ef18ca8e91e4701e1175410

Nice catch, "env.Append(LIBS=[python_lib])" where "python_lib = 'python' +
gcv('VERSION')" is definitely the cause.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Bug#937262: Help with scons needed (Was: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye))

2019-12-13 Thread Andrey Rahmatullin
On Fri, Dec 13, 2019 at 01:40:34PM +0100, Andreas Tille wrote:
> > > g++ -o pdb2pka/substruct/Algorithms.cpython-37m-x86_64-linux-gnu.so 
> > > -Wl,-z,relro -Wl,-z,now -shared pdb2pka/substruct/Algorithms.os 
> > > -L/usr/lib -lpython3.7
> > > /usr/bin/ld: cannot find -lpython3.7
> > Actually, it's a different problem, sorry.
> > There is no -lpython3.7, only -lpython3.7m. If the build system used
> > pkgconfig it would know that. I guess the library name is hardcoded
> > instead? I see that it got -I/usr/include/python3.7m from somewhere, so
> > it's not completely broken.
> 
> Thanks for that additional hint.  I can confirm that I checked whether
> pkgconfig can be used before I was asking here.  But we seem to agree
> that this is not the case.  I admit I have no real clue how to convince
> scons to link to the correct library name. :-(
I have no idea either. It seems that it just uses the scons compilation
code by creating an env.LoadableModule.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Bug#937262: Help with scons needed (Was: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye))

2019-12-13 Thread Andrey Rahmatullin
On Fri, Dec 13, 2019 at 09:49:47AM +0100, Andreas Tille wrote:
> g++ -o pdb2pka/substruct/Algorithms.cpython-37m-x86_64-linux-gnu.so 
> -Wl,-z,relro -Wl,-z,now -shared pdb2pka/substruct/Algorithms.os -L/usr/lib 
> -lpython3.7
> /usr/bin/ld: cannot find -lpython3.7
Actually, it's a different problem, sorry.
There is no -lpython3.7, only -lpython3.7m. If the build system used
pkgconfig it would know that. I guess the library name is hardcoded
instead? I see that it got -I/usr/include/python3.7m from somewhere, so
it's not completely broken.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Bug#937262: Help with scons needed (Was: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye))

2019-12-13 Thread Andrey Rahmatullin
On Fri, Dec 13, 2019 at 09:49:47AM +0100, Andreas Tille wrote:
> So how can I enable proper linking to -lpython3.7 which is obviously not
> in the library search path (but package libpython3.7 is definitely
> installed in the pbuilder chroot).
To link to a library you need to install its -dev package (this is not just
for libpython*).

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: [Help] consensuscore: Python2 removal in sid/bullseye

2019-12-07 Thread Andrey Rahmatullin
On Sat, Dec 07, 2019 at 09:23:16PM +0100, Andreas Tille wrote:
> I tried to port consensuscore to Python3 in Git[1].  Unfortunately 2to3
> was not completely successfully since I get:
This isn't 2to3's fault.

>dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:217: /usr/bin/python3.8 setup.py build.
> WARNING: '' not a valid package name; please use only .-separated package 
> names in setup.py
> running build
> Traceback (most recent call last):
>   File "tools/find_boost", line 56, in 
> boost = find_boost()
>   File "tools/find_boost", line 44, in find_boost
> best_boost = max(boosts_found, key=lambda t: t[1])[0]
> TypeError: '>' not supported between instances of 'NoneType' and 'tuple'
Such meaningless comparisons are indeed not supported in Python3. You need
to filter out the items where version is None.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: pytest help needed

2019-12-04 Thread Andrey Rahmatullin
Why are you running tests via PYBUILD_SYSTEM=custom
PYBUILD_TEST_ARGS="{interpreter} setup.py test"? Is the pytest one not
working?

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#945792: RM: fpconst -- RoM; obsolete; no Python 3 support and no reverse deps

2019-11-28 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

The only release was in 2005. https://www.python.org/dev/peps/pep-0754/
was abouyt including it into stdlib and it failed.

The only revdep, jack-mixer, was recently removed from the archive.

Popcon 17k, much higher than jack-mixer had, but it was 110k in 2014 so I
suspect it's just an old dep of some long gone or updated package.


Reverse deps checked with dak rm -Rnb python-fpconst

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#945264: RM: python-backports.os -- RoM; no Python 3 support and no reverse deps; low popcon

2019-11-21 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

Not needed with Py3 and not used by any package in Debian anymore.

Popcon 82.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Bug#937657: Issue with numpy under Python 3.8

2019-11-17 Thread Andrey Rahmatullin
On Sun, Nov 17, 2019 at 04:29:56PM +0100, Andreas Tille wrote:
> > If you look on the numpy tracker page [1], you'll see there is a note:
> > 
> > "This package is part of the ongoing testing transition known as
> > python3.8. Please avoid uploads unrelated to this transition, they
> > would likely delay it and require supplementary work from the release
> > managers."
> 
> I wonder in how far this is relevant to simply *build* a package.
It's very relevant to running its tests.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#943496: RM: python-adns -- RoM; ancient; dead upstream; no Python 3 support and no reverse deps

2019-10-25 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

https://pypi.org/project/adns-python/ no new releases since 2007.

Popcon 544, because of transmission-remote-cli which was recently removed
from the archive.

Reverse deps checked with dak rm -Rnb python-adns

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: 2Removal: handling circular dependencies

2019-10-24 Thread Andrey Rahmatullin
On Thu, Oct 24, 2019 at 08:49:41AM +0100, Simon McVittie wrote:
> in general we
> also consider broken Recommends to be a serious bug if anyone notices
> them (due to Policy §2.2.1 "must not require or recommend a package
> outside of main for compilation or execution").
Note that the release policy up to buster explicitly said ""Recommends:"
lines do not count as requirements.", this is not true for
https://release.debian.org/bullseye/rc_policy.txt though.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#942327: RM: sclapp -- RoQA; orphaned; dead upstream; no Python 3 support and no reverse deps

2019-10-14 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

http://www.alittletooquiet.net/software/sclapp/ is dead.
The current upstream code was uploaded to Debian in 2008.

Reverse deps checked with dak rm -Rnb python-sclapp

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

2019-10-14 Thread Andrey Rahmatullin
On Mon, Oct 14, 2019 at 09:54:18AM -0400, Sandro Tosi wrote:
> i think it's a bit premature to raise severity to RC (we should also
> check with the release team): these bugs have been opened since just 2
> months and a half, and the development cycle for bullseye started not
> longer before. there's still a lot of time. (and removing a py2
> package from a leaf pkg takes 5 minutes, usually, so if everyone in
> this thread had done that instead of writing an email, we'd be down 5
> bugs already :D )
> 
> I think it's also extremely premature (and just a bad idea in general)
> to consider breakage of reverse dependencies but just dropping py2
> packages. the Release Team is extremely unhappy with this approach for
> dealing with the py2removal bugs, so let's not even consider that
> option.

I agree with this.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#941067: RM: python-webflash -- RoQA; orphaned; dead upstream; no Python 3 support and no reverse deps

2019-09-24 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

Last release in 2009. http://python-rum.org/wiki/WebFlash is dead.

Reverse deps checked with dak rm -Rn python-webflash

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#941066: RM: python-toscawidgets -- RoQA; orphaned; no Python 3 support and no reverse deps

2019-09-24 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

Last release in 2011. Popcon 20.

Reverse deps checked with dak rm -Rn python-toscawidgets

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#941064: RM: myghty -- RoQA; orphaned; obsolete; no Python 3 support

2019-09-24 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

Long dead. "Myghty is a legacy library. New projects should use Mako
templates". Last release in 2010.

Reverse deps checked with dak rm -Rn myghty pylons webhelpers

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#941063: RM: python-weberror -- RoM; no Python 3 support

2019-09-24 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

Part of the Pylons stack. Last release in 2016, but no Python 3 support
anyway. "This software is not actively maintained. Simple bugfixes and
other patches will be accepted, and released."

Reverse deps checked with dak rm -Rn pylons webhelpers python-weberror

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#941061: RM: pylons -- RoM; obsolete; no Python 3 support

2019-09-24 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

Pylons is dead and Python2-only. The only revdep is python-webhelpers.

Reverse deps checked with dak rm -Rn pylons webhelpers

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#941062: RM: webhelpers -- RoM; obsolete; no Python 3 support

2019-09-24 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

Part of the Pylons stack, last release in 2011.

Reverse deps checked with dak rm -Rn pylons webhelpers

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: 2Removal: handling circular dependencies / dropping tests before the binary?

2019-09-21 Thread Andrey Rahmatullin
On Sat, Sep 21, 2019 at 10:18:16AM +0100, Rebecca N. Palmer wrote:
> Some Python 2 packages have circular (build-)dependencies, making it
> impossible to remove them one at a time without breaking anything.
Unless I'm missing something, this shouldn't be a problem, just go away
and remove them all and upload them in roughly the same time?

> --- Cut the cycle by removing one of the dependencies.
> 
> This may mean skipping (some of) the tests, as Python build dependencies are
> often actually test dependencies.  There might be cases where it isn't
> reasonably possible at all.
Unless some of those don't have Python 3 packages in the archive yet, why
removing py2 from one package would break building another, if that
another has py2 parts removed too?
Note that having an unbuildable package in sid for several days, until
it's updated to a no-py2 version, is perfectly acceptable.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Packages depending on python-testtools are now RC: is bzr still a thing?

2019-09-16 Thread Andrey Rahmatullin
Note that dak doesn't check autopkgtest deps. I'm using
grep-dctrl -FTestsuite-triggers $pkg -sPackage 
/var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources
for that.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Python3 issue with Tkinter (Was: Bug#938447: scoary: Python2 removal in sid/bullseye)

2019-09-13 Thread Andrey Rahmatullin
On Fri, Sep 13, 2019 at 10:04:12PM +0200, Andreas Tille wrote:
> try:
> ttk
> Tkinter
> except NameError:
> sys.exit("Need the following installed: Tkinter, tkFileDialog, ttk")
> 
> 
> I have no idea what the call to tkk is supposed to do 
Checking that the name exists.

> and why it ends up in a NameError.
The name doesn't exist, most likely because one of the ImportErrors
didn't happen. And it didn't happen because you ran 2to3 on code that
already supports both 2 and 3, thus turning the py2 parts into the py3
ones...

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#940184: RM: python-enthoughtbase -- RoM; dead upstream; ancient; no Python 3 support and no reverse deps

2019-09-13 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

https://pypi.org/project/EnthoughtBase/ is dead and I cannot find the new
source. The current upstream source was uploaded to Debian in 2011.

Popcon is 203, not sure why. It has only a reverse build-dep in stable and
oldstable, not reverse deps there.

Reverse deps checked with dak rm -Rnb python-enthoughtbase

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: skimage (build-)depends on python-cloudpickle which has already been dropped

2019-09-13 Thread Andrey Rahmatullin
On Fri, Sep 13, 2019 at 05:16:30PM +0800, Drew Parsons wrote:
> Python maintainers, remember, check your reverse dependencies before
> dropping your python2 packages.
> Check each of
> 
>   build-rdeps python-yourmodule
>   apt-rdepends -r python-yourmodule
> 
> and confirm the package has rdeps=0 on Sandro's list at
> http://sandrotosi.me/debian/py2removal/index.html
And grep-dctrl -FTestsuite-triggers $pkg -sPackage 
/var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources 

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: 2to3 adds '.' in front dir of "from dir import ..." statements (Was: [MoM] lefse migration to python 3])

2019-09-12 Thread Andrey Rahmatullin
On Thu, Sep 12, 2019 at 08:30:20AM +0200, Thomas Goirand wrote:
> I wont comment on the relative import ambiguity problem, as Ghislain
> replied correctly. However, I do want to comment on 2to3.
> 
> I generally recommend against using it, in the favor of other tools. For
> example, you can use sixer, which I maintain in Debian, and often used
> (and abused) to do Python 3 conversions. There's also 2to6, which I
> don't know much about, but I've read it works about the same way as
> sixer (which was specifically written for OpenStack).
> 
> The advantage is that you'll get a source code that will work on both
> Python 2 and 3. It's generally a way more easy to submit upstream, which
> may not want to loose Python 2 compatibility.
I can add to this that it's non-trivial to convert from six to normal Py3
code, unless there are some tools that I didn't find. And it's really time
to do that, not to convert TO six.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

2019-09-12 Thread Andrey Rahmatullin
On Thu, Sep 12, 2019 at 09:17:08AM +0200, Andreas Tille wrote:
> > > $ cycle
> > > Traceback (most recent call last):
> > >   File "/usr/bin/cycle", line 12, in 
> > > from dialogs import *
> > >   File "/usr/share/cycle/dialogs.py", line 8, in 
> > > from cal_year import cycle, Val
> > >   File "/usr/share/cycle/cal_year.py", line 9, in 
> > > from dialogs import Note_Dlg
> > > ImportError: cannot import name 'Note_Dlg' from 'dialogs' 
> > > (/usr/share/cycle/dialogs.py)
> > There are circular imports in the code so you most likely broke that by
> > reordering imports in various files.
> 
> s/you most likely broke/2to3 most likely broke/
2to3 doesn't do that. You mentioned autopep8, it could do that.

> > "from cal_year import *; from dialogs import *" works, the reverse
> > doesn't, so the /usr/bin/cycle code is definitely problematic, not sure
> > about other changes.
> 
> I can not confirm that
> 
>from cal_year import *
> 
> works at all.  It works in the unpatched Python2 version.
I was just saying that (in the unpatched Python2 version) "from cal_year
import *; from dialogs import *" works, the reverse doesn't, and the
patched version contains the reverse.

>git clone https://salsa.debian.org/med-team/cycle
>cd cycle
>echo "from cal_year import *" | python
>quilt push -a
>echo "from cal_year import *" | python3
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/home/andreas/debian-maintain/salsa/med-team/cycle/cal_year.py", line 
> 9, in 
> from dialogs import Note_Dlg
>   File "/home/andreas/debian-maintain/salsa/med-team/cycle/dialogs.py", line 
> 12, in 
> from cal_year import cycle, Val
> ImportError: cannot import name 'cycle' from 'cal_year' 
> (/home/andreas/debian-maintain/salsa/med-team/cycle/cal_year.py)
> 
> 
> So may be I misinterpreted your hint but even reverting the reordering
> of 2to3 in my latest commit does not help.
I also said that other changes may be problematic too. I didn't check
them.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

2019-09-11 Thread Andrey Rahmatullin
On Wed, Sep 11, 2019 at 04:12:34PM +0200, Andreas Tille wrote:
> Control: tags -1 help
> 
> On Wed, Sep 11, 2019 at 09:33:54AM -0300, Antonio Terceiro wrote:
> > E: Sub-process /usr/bin/dpkg returned an error code (1)
> > ~[100]$ cycle
> >   File "/usr/bin/cycle", line 29
> > if lang_find:
> > ^
> > TabError: inconsistent use of tabs and spaces in indentation
> 
> Argh.  That's fixed via autopep8 in Git[1] now.  However, when calling
> cycle I get
> 
> $ cycle
> Traceback (most recent call last):
>   File "/usr/bin/cycle", line 12, in 
> from dialogs import *
>   File "/usr/share/cycle/dialogs.py", line 8, in 
> from cal_year import cycle, Val
>   File "/usr/share/cycle/cal_year.py", line 9, in 
> from dialogs import Note_Dlg
> ImportError: cannot import name 'Note_Dlg' from 'dialogs' 
> (/usr/share/cycle/dialogs.py)
There are circular imports in the code so you most likely broke that by
reordering imports in various files.
"from cal_year import *; from dialogs import *" works, the reverse
doesn't, so the /usr/bin/cycle code is definitely problematic, not sure
about other changes.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: [Help] Bug#938668: tifffile: Python2 removal in sid/bullseye

2019-09-05 Thread Andrey Rahmatullin
On Thu, Sep 05, 2019 at 07:42:15PM +0200, Andreas Tille wrote:
> for some reason I do not understand are the dependencies of the
> binary package
> 
> Depends: python3-numpy (>= 1:1.16.0~rc1), python3-numpy-abi9, python3:any, 
> python:any
> 
> 
> How can I get rid of the python:any dependency?
You ship a Python 2 script, /usr/bin/tifffile. It also doesn't work, for
obvious reasons. Fix its shebang. It would also be a good idea to test it
before the last upload, but as nobody noticed that the package doesn't
work since it was broken in December and got into buster, maybe it should
just be RMed? I've just filed an RC bug for it.

Also, my understanding is that public modules should be packaged
separately as python3-foo packages and private modules should be put into
private paths, but this package ships a public module and the changelog
entry says "The package does not really provide a Python module for
inclusion into other projects." See
https://www.debian.org/doc/packaging-manuals/python-policy/programs.html#current_version_progs

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#939352: RM: django-threaded-multihost -- RoM; dead upstream; RC-buggy; no Python 3 support and no reverse deps

2019-09-03 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

Doesn't work with current Django. No new upstream versions in Debian
since the first upload in 2010. The homepage is dead.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#939351: RM: django-app-plugins -- RoM; RC-buggy; ancient; no Python 3 support and no reverse deps

2019-09-03 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

The version in Debian is released in 2009, no upstream releases since
then.
The package doesn't work, according to its RC bugs.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#939350: RM: python-django-rosetta -- RoM; RC-buggy; no Python 3 support and no reverse deps; low popcon

2019-09-03 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

Doesn't support modern Django and FTBFS because of that (#933146).

Popcon 20.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#939349: RM: django-prometheus -- RoM; RC-buggy; low popcon

2019-09-03 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

The package FTBFS (#918418).
Ships a Python 2 subpackage which can't be dropped because of that FTBFS.

Popcon 11.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#939348: RM: djangocms-admin-style -- RoM; RC-buggy; low popcon

2019-09-03 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

Doesn't support modern Django and FTBFS because of that (#865293).
Ships a Python 2 subpackage which can't be dropped because of that FTBFS.

Popcon 15 and less.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#939327: RM: python-gnutls -- RoM; no Python 3 support and no reverse deps

2019-09-03 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

The upstream code doesn't support Python 3 and there is no ongoing effort
or even an upstream issue about this.

Popcon 491. This is probably caused by sagemath, which depends on it in
oldstable but not in stable and has similar popcon values.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#939319: RM: python-contract -- RoQA; orphaned; ancient; no Python 3 support and no reverse deps

2019-09-03 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

No upstream releases since 2007.

Popcon 46.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#939320: RM: python-plwm -- RoQA; orphaned; ancient; no Python 3 support and no reverse deps

2019-09-03 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

No upstream releases since 2009.

Popcon 41.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Webpage to track py2removal bugs & packages

2019-09-02 Thread Andrey Rahmatullin
On Mon, Sep 02, 2019 at 04:43:40PM +0800, Drew Parsons wrote:
> Looks great, is plenty enough accurate for the task. It tells us it's more
> important to process live-task-standard than python-gnatpython-doc.
Not necessarily.

live-task-standard just depends on python, without any other python2 deps.
python-gnatpython-doc Recommends: python-gnatpython (which has a reverse
build dep and there is no python3-gnatpython to switch the Recommends).
I'd say both packages are not worth it. If the table displayed the number
of deps+build-deps that are themselves related to Python 2 it would be
more useful but I don't know if that's possible to implement.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#939098: RM: mocker -- RoM; no Python 3 support and no reverse deps; low popcon

2019-09-01 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

No upstream releases since 2010.

Popcon is 19.

Reverse deps checked with dak rm -Rnb python-mocker

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: updating mechanize - help concerning tests with pybuild

2019-08-31 Thread Andrey Rahmatullin
On Sat, Aug 31, 2019 at 07:10:43PM +0200, Raphael Hertzog wrote:
> Looking at the status of the packages in the team, it's quite clear that
> the team is MIA as a whole:
> https://qa.debian.org/developer.php?email=pkg-zope-develop...@lists.alioth.debian.org
> 
> The only recent upload is from TANIGUCHI Takaki 
> on zope.deprecation 4.4.0-1. It's also the only package
> 
> Thus I would suggest to go ahead and take over the package in the DPMT
> team.
And many of those packages can be RMed. I checked packages from `grep-dctrl
-FMaintainer pkg-zope`.

These non-zope.* packages have revdeps:

python-chameleon
python-mechanize (while python-clientform can be dropped)
python-transaction
python-zc.buildout
python-zconfig
python-zdaemon
python-zodb

So these non-zope.* packages can be RMed:

bobo
sourcecodegen
van.pydeb

It's harder to check all revdeps of the zope.* packages as they depend on
each other and some, but not all, have py3 subpackages, but these py2
subpackages can be dropped (I didn't check if they are the only
subpackages):

python-zope.authentication
python-zope.cachedescriptors
python-zope.component-persistentregistry
python-zope.component-test
python-zope.copy
python-zope.dottedname
python-zope.sendmail
python-zope.sqlalchemy
python-zope.testbrowser
python-zope.traversing

And these source packages can be RMed (overlaps with the list above,
checked with dak):

zope.authentication
zope.browser
zope.cachedescriptors
zope.contenttype
zope.copy
zope.dottedname
zope.i18n
zope.publisher
zope.sendmail
zope.sqlalchemy
zope.testbrowser
zope.traversing

This includes several Py3 subpackages.

Hope this helps.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Webpage to track py2removal bugs & packages

2019-08-31 Thread Andrey Rahmatullin
On Sat, Aug 31, 2019 at 11:50:33AM -0400, Scott Kitterman wrote:
> > > I definitely think it will be helpful.  Thanks for putting it together. 
> > > It's the best thing I've seen yet for answering the question of what can
> > > we try to kill off now.
> > > 
> > > Please keep it updated.
> > 
> > Please note though that all python modules with QA or DPMT in Maintainer
> > and without revdeps are already fixed.
> 
> I'm not sure how you checked that.
reverse-depends and reverse-depends -b

> I just now fixed pycxx which did have an
> rdepend, but only one from the same source package.  
Indeed, though it has reverse build-deps anyway.

> Depending on your methodology, there may be others.
Yes, but I suspect not many of them.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Webpage to track py2removal bugs & packages

2019-08-31 Thread Andrey Rahmatullin
On Sat, Aug 31, 2019 at 10:20:32AM -0400, Scott Kitterman wrote:
> I definitely think it will be helpful.  Thanks for putting it together.  It's 
> the best thing I've seen yet for answering the question of what can we try to 
> kill off now.
> 
> Please keep it updated.
Please note though that all python modules with QA or DPMT in Maintainer
and without revdeps are already fixed.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: updating mechanize - help concerning tests with pybuild

2019-08-31 Thread Andrey Rahmatullin
On Sat, Aug 31, 2019 at 11:33:54AM +0900, Norbert Preining wrote:
> here are two questions: one concerning adopting/updating mechanize and
> how to deal with rdepends, one concerning how to fix tests with special
> requirements in pybuild.
> 
> For calibre and porting to python3, I need mechanize for python3.
I'm sorry that I can't help with your questions, but what can you tell us
about Python 3 calibre? Last time I heard of it was famous "I am perfectly
capable of maintaining python 2 myself.  Far less work than migrating the
entire calibre codebase." from https://bugs.launchpad.net/calibre/+bug/1714107
I didn't read the recent comments on that bug but I found
https://github.com/kovidgoyal/calibre/blob/master/README.python3

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#935841: RM: python-googlecloudapis -- RoM; RC-buggy; uninstallable

2019-08-26 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

Depends and build-depends on python3-protorpc-standalone which is not
installable on Python 3.7, and on python-oauth2client which is dropped
from Debian.

Reverse deps checked with dak rm -Rn python-googlecloudapis

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#935840: RM: python-protorpc-standalone -- RoQA; orphaned; RC-buggy; incompatible with Python 3.7

2019-08-26 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

From the O bug (#906195): "If it is still RC buggy at the time of the
freeze, I'll ask for its removal from Debian."

The only reverse dep is python-googlecloudapis which has other problems
and isn't installable because of python3-protorpc-standalone. RM for it
will be filed shortly.

Reverse deps checked with dak rm -Rn python-protorpc-standalone 
python-googlecloudapis

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#935838: RM: python-visual -- RoQA; orphaned; RC-buggy; broken

2019-08-26 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal
Control: block -1 by 935073
Control: block -1 by 911171

According to #884616 (RC bug on python-visual) and #911171 (RC bug on
epigrass) it's broken and should not be used. Its only reverse dep is
epigrass which was requested to be removed (#935073), though that
discussion hints it may be ported to Py3 before being removed, which
should drop this dep anyway.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#935837: RM: pygdchart2 -- RoQA; orphaned; ancient; dead upstream; no Python 3 support and no reverse deps

2019-08-26 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

http://www.nullcube.com/software/pygdchart2.html (from the O bug) is dead.
No new releases in Debian since initial packaging in 2005.
The only reverse dep is rebuildd for which an RM bug was just filed.

Reverse deps checked with dak rm -Rn rebuildd pygdchart2

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#935836: RM: rebuildd -- RoQA; orphaned; low popcon; dead upstream; Python 2-only

2019-08-26 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

Native package by a retired DD. Homepage gives 404. Last release in 2012.
Popcon 8.
Depends on several py2 packages.

Reverse deps checked with dak rm -Rnb rebuildd

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#935835: RM: htmlgen -- RoQA; orphaned; RC-buggy; ancient; no Python 3 support and no reverse deps

2019-08-26 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

Source in Debian was first packaged in 1999.
Depends on cruft python-imaging.

Reverse deps checked with dak rm -Rnb python-htmlgen

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Git, gbp blues

2019-08-26 Thread Andrey Rahmatullin
On Mon, Aug 26, 2019 at 08:20:13AM +0200, Guðjón Guðjónsson wrote:
> > The correct procedure is running “gbp pq import” *before* importing a new
> > tarball. Then after importing you do “gbp pq rebase”.
> In fact I did do that.
Then you would get an error message when trying to do that second time.

> > > But fixing the patches with quilt before importing them the second
> > > time seems to fix all my problems.
> > If it does not break the patches metadata then it also works.
> But what other way is possible?
gbp pq rebase.
Seriously.

> The patch queue must apply cleanly in gbp pq import 
And it will, of course.

> in general you can assume it doesn't with new upstream and
> old patch queue.
This is not something you can or should do.

> I still don't understand how to edit the patches the correct way
> after a new upstream release.
gbp pq rebase, as the wiki page tells you.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Git, gbp blues

2019-08-25 Thread Andrey Rahmatullin
On Sun, Aug 25, 2019 at 10:01:02PM +0200, Guðjón Guðjónsson wrote:
> > > Isn't this an error. Shouldn't it be git checkout?
> > > $ gbp checkout debian/master
> > Yes.
> You mean it should be git checkout?
Yes.

> > If you ran gbp pq import after importing the new tarball and it didn't say
> > "Patch queue branch 'patch-queue/master'. already exists. Try 'rebase' or
> > 'switch' instead." this means you didn't follow the procedure you copied
> > above, which includes running gbp pq import before gbp import-orig.
> 
> I did follow the procedure but I don't know what to do if a patch
> doesn't apply cleanly.
You seem to be misunderstanding what I wrote.

> I did try
> gbp pq import
> gbp:info: Trying to apply patches at 
> 'c72f39a3a32b5e5c1eb7f9aaf7176e942e85d804'
> gbp:warning: Patch 0004-remove-logo-privacy-issue.diff.patch failed to
> apply, retrying with whitespace fixup
This cannot happen when you run gbp pq import before running gbp
import-orig, as the wiki page tells you to do.
And this cannot happen when you run it after gbp import-orig, if you also
ran it before running gbp import-orig, as the wiki page tells you to do.
So this can only happen if you didn't follow the procedure.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Git, gbp blues

2019-08-25 Thread Andrey Rahmatullin
On Sun, Aug 25, 2019 at 09:40:16PM +0200, Guðjón Guðjónsson wrote:
> Isn't this an error. Shouldn't it be git checkout?
> $ gbp checkout debian/master
Yes.

> But I still find working with patch queues difficult especially with
> new upstream where the old patches don't apply correctly.
> I tried to do
> $ gbp pq import
> but it fails because one of the patches doesn't apply.
> So I fixed the patches in the old way using
> quilt push -f
> quilt edit
> quilt refresh
> And after having fixed all the patches I could do
> $gbp pq import
> $gbp pq export
> and the diff seems ok.
> Is this the correct procedure?
The correct procedure is documented on that page.

"""
Rebase the patches:

$ gbp pq rebase
$ gbp pq export
"""

If you ran gbp pq import after importing the new tarball and it didn't say
"Patch queue branch 'patch-queue/master'. already exists. Try 'rebase' or
'switch' instead." this means you didn't follow the procedure you copied
above, which includes running gbp pq import before gbp import-orig.


-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#935685: RM: python-opster -- RoM; no Python 3 support and no reverse deps; low popcon

2019-08-25 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

https://github.com/piranha/opster/ supports Python 3.

Popcon is 14.

Reverse deps checked with dak rm -Rnb python-opster

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#935689: RM: python-unipath -- RoM; ancient; no Python 3 support and no reverse deps; low popcon

2019-08-25 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

No upstream releases since 2008.

Popcon is 17.

Reverse deps checked with dak rm -Rnb python-unipath

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#935687: RM: python-txosc -- RoM; ancient; no Python 3 support and no reverse deps; low popcon

2019-08-25 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

There is no upstream development at https://bitbucket.org/arjan/txosc since 
2011.

Popcon is 6.

Reverse deps checked with dak rm -Rnb python-txosc

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#935688: RM: unittest-xml-reporting -- RoM; no Python 3 support and no reverse deps; low popcon

2019-08-25 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

Latest upstream code supports Python 3. There is a Python 3 request bug,
#737790, 5.5 years old.

Popcon is 34.

Reverse deps checked with dak rm -Rnb python-xmlrunner

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#935446: RM: flower -- RoQA; orphaned; RC-buggy; low popcon; no Python 3 support and no reverse deps

2019-08-22 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

The package is Python 2 only and depends on celery which is Python 3 only.
It also depends on libjs-twitter-bootstrap which will be removed too
(#908424). The upstream code supports Python 3.

Reverse deps checked with dak rm -Rnb python-flower

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#935331: RM: libavg -- RoQA; orphaned; no Python 3 support and no reverse deps

2019-08-21 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

I couldn't find if the upstream source supports Python 3.

Reverse deps checked with dak rm -Rnb python-libavg

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#935131: RM: xpyb -- RoQA; orphaned; RC-buggy; no Python 3 support and no reverse deps

2019-08-19 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

No upstream releases since the last packaged one in 2012.

python3-xcffib description says "This package is intended to be a (mostly)
drop-in replacement for xpyb. xpyb has an inactive upstream, several
memory leaks, is python2 only and doesn't have pypy support."

Reverse deps checked with dak rm -Rnb python-xpyb

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#935130: RM: pyvtk -- RoQA; orphaned; ancient; no Python 3 support and no reverse deps

2019-08-19 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

The latest upstream code at https://github.com/pearu/pyvtk seems to
support Python 3, but the Debian package contains code from 2007.

Reverse deps checked with dak rm -Rnb python-pyvtk

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#935129: RM: python-uniconvertor -- RoQA; orphaned; RC-buggy; no Python 3 support and no reverse deps

2019-08-19 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

Looks like it doesn't work at all in the current state.

Reverse deps checked with dak rm -Rn python-uniconvertor

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#935125: RM: pyexcelerator -- RoQA; orphaned; ancient; no Python 3 support and no reverse deps

2019-08-19 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

Last release in 2009.

Reverse deps checked with dak rm -Rnb python-excelerator

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#935124: RM: pyao -- RoQA; orphaned; ancient; dead upstream; no Python 3 support and no reverse deps

2019-08-19 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

There is some Py3 fork at https://github.com/tynn/PyAO

Reverse deps checked with dak rm -Rn pyao

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#935122: RM: optcomplete -- RoQA; orphaned; no Python 3 support and no reverse deps

2019-08-19 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

Upstream Python 3 bugreport: 
https://bitbucket.org/blais/optcomplete/issues/2/python3-compatibility

Reverse deps checked with dak rm -Rnb python-optcomplete

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#935120: RM: jabber.py -- RoQA; orphaned; ancient; no Python 3 support and no reverse deps

2019-08-19 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

Last release in 2003.

Reverse deps checked with dak rm -Rnb python-jabber

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#934832: RM: pygpiv -- RoQA; orphaned; no Python 3 support and no reverse deps

2019-08-15 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

No upstream releases since 2009.

Reverse deps checked with dak rm -Rnb python-gpiv

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Python 2 and PyPy module removal from Debian

2019-08-15 Thread Andrey Rahmatullin
On Wed, Jul 24, 2019 at 01:35:35AM +0200, Piotr Ożarowski wrote:
> 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.
Do you or anyone else have ideas when we should these next steps?

-- 
WBR, wRAR


signature.asc
Description: PGP signature


  1   2   >