Re: Build and run-time triplets

2022-07-24 Thread Andrey Rahmatullin
On Sun, Jul 24, 2022 at 08:30:42PM +0100, Julian Gilbey wrote:
> On Sun, Jul 24, 2022 at 11:41:56PM +0500, Andrey Rahmatullin wrote:
> > [...]
> > > 
> > > I got all of the triplets working, but was then stymied when I tried
> > > to specify Multi-Arch: same in the control file.  I got a lintian
> > > warning: multi-arch-same-package-calls-pycompile
> > > It seems that since the pybuild system (via dh_python3) adds a
> > > py3compile command to the postinst of the package, then I can't safely
> > > use Multi-Arch: same.
> > > 
> > > I don't know if this is the case for all python3 Arch: any packages
> > > with compiled extensions;
> > I think the tag desciption has a good step-by-step explanation why does
> > the tag exists.
> > But your package is not a "package with compiled extensions", is it?
> 
> Yes, it's got compiled extensions (Cython) in addition to this
> non-Python .so library file.
> 
> > > are they all effectively Multi-Arch: no?  Is this worth thinking about
> > > in the longer term?
> > What do you propose?
> 
> I think the fix to bug #812228 might have done the job nicely ;-)
If it actually ships extensions, the "it should usually get a dependency
on the Python interpreter for the same architecture" part should still
apply as far as I understand it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Build and run-time triplets

2022-07-24 Thread Andrey Rahmatullin
On Sun, Jul 24, 2022 at 06:36:57PM +0100, Julian Gilbey wrote:
> I got all of the triplets working, but was then stymied when I tried
> to specify Multi-Arch: same in the control file.  I got a lintian
> warning: multi-arch-same-package-calls-pycompile
> It seems that since the pybuild system (via dh_python3) adds a
> py3compile command to the postinst of the package, then I can't safely
> use Multi-Arch: same.
Actually, #812228, mentioned in the tag description, was fixed in 2021 so
it's possible that this is no longer a problem.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Build and run-time triplets

2022-07-24 Thread Andrey Rahmatullin
On Sun, Jul 24, 2022 at 06:36:57PM +0100, Julian Gilbey wrote:
> > > > > I'd like to ask for some help.  I'm working on packaging pydevd, which
> > > > > builds a private .so library.  Ordinary extensions built using cython
> > > > > or similar end up being called "foo.cpython-310-x86_64-linux-gnu.so",
> > > > > but this library, which is not dependent on the Python version, should
> > > > > presumably be called "bar.x86_64-linux-gnu.so".
> > > > If it's just a private library and not a Python module it should be 
> > > > called
> > > > bar.so.
> > > > 
> > > > > Question 1: How do I determine (within Python) the triplet to use when
> > > > > building the library?
> > > > You don't.
> > > > 
> > > > > Question 2: How do I determine (within Python) the triplet to use when
> > > > > loading the library at runtime?
> > > > You don't, but also how are you actually loading it?
> > > 
> > > Well, the upstream wanted to compile two versions of the library, one
> > > for 64 bit architectures and one for 32 bit architectures.  I don't
> > > really want to build two different arch libraries in a single build,
> > > because that seems very contrary to the way the Debian architectures
> > > work, and would also limit it to the amd64/i386 architectures for no
> > > obviously good reason.  I had imagined that if there is some sort of
> > > multiarch setup, one might have the amd64 and i386 packages installed
> > > simultaneously, hence the need for different names.
> > The normal way for this is putting it into
> > /usr/lib//pkgname/foo.so, and according to the code below you'll
> > need the full path at the run time so you indeed need the triplet at both
> > build and run time. You can get the triplet in d/rules, not sure how
> > should you pass it to the build system as that depends on the build system
> > used. For the run time, https://wiki.debian.org/Python/MultiArch suggests
> > sys.implementation._multiarch (note that you cannot use it during the
> > build as that would break cross-compilation etc.), not sure if there are
> > better ways. 
> 
> I got all of the triplets working, but was then stymied when I tried
> to specify Multi-Arch: same in the control file.  I got a lintian
> warning: multi-arch-same-package-calls-pycompile
> It seems that since the pybuild system (via dh_python3) adds a
> py3compile command to the postinst of the package, then I can't safely
> use Multi-Arch: same.
> 
> I don't know if this is the case for all python3 Arch: any packages
> with compiled extensions;
I think the tag desciption has a good step-by-step explanation why does
the tag exists.
But your package is not a "package with compiled extensions", is it?

> are they all effectively Multi-Arch: no?  Is this worth thinking about
> in the longer term?
What do you propose?

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Build and run-time triplets

2022-06-09 Thread Andrey Rahmatullin
On Thu, Jun 09, 2022 at 10:43:01AM +0100, Julian Gilbey wrote:
> > > The normal way for this is putting it into
> > > /usr/lib//pkgname/foo.so, and according to the code below you'll
> > > need the full path at the run time so you indeed need the triplet at both
> > > build and run time.
> > 
> > You can do something like
> > 
> >  handle = dlopen("/usr/${LIB}/pkgname/foo.so", flags);
> > [...]
> > 
> > Then you'd install the private library into what Autotools would refer to
> > as ${libdir}/pkgname/foo.so (adjust as necessary for other build systems)
> > and it will usually end up in the correct place. This assumes that
> > ${libdir} is configured to something like
> > ${exec_prefix}/lib/x86_64-linux-gnu or ${exec_prefix}/lib64 as appropriate
> > for the distribution, but that's normally true anyway, and in particular
> > should be true in debhelper.
> 
> Thanks Simon!
> 
> The build system here is the standard Python setup.py, except for this
> library.  That is built by the following script:
> 
> ---
> g++ -m64 -shared -o attach_linux_amd64.so -fPIC -nostartfiles attach.cpp
> mv attach_linux_amd64.so ../attach_linux_amd64.so
> echo Compiled amd64
> ---
> 
> There's not even an attempt at working out ${libdir} or so on.
Sure, it's not necessary to know the installation path at the compile and
link time. It's only needed at the install time.


-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Build and run-time triplets

2022-06-09 Thread Andrey Rahmatullin
On Thu, Jun 09, 2022 at 09:56:42AM +0100, Julian Gilbey wrote:
> > [...]
> > > Well, the upstream wanted to compile two versions of the library, one
> > > for 64 bit architectures and one for 32 bit architectures.  I don't
> > > really want to build two different arch libraries in a single build,
> > > because that seems very contrary to the way the Debian architectures
> > > work, and would also limit it to the amd64/i386 architectures for no
> > > obviously good reason.  I had imagined that if there is some sort of
> > > multiarch setup, one might have the amd64 and i386 packages installed
> > > simultaneously, hence the need for different names.
> > The normal way for this is putting it into
> > /usr/lib//pkgname/foo.so, and according to the code below you'll
> > need the full path at the run time so you indeed need the triplet at both
> > build and run time. You can get the triplet in d/rules, not sure how
> > should you pass it to the build system as that depends on the build system
> > used. For the run time, https://wiki.debian.org/Python/MultiArch suggests
> > sys.implementation._multiarch (note that you cannot use it during the
> > build as that would break cross-compilation etc.), not sure if there are
> > better ways. 
> 
> Thanks for your help!
> 
> OK (and yes, it does require the full path at runtime).  What triplet
> do I use in d/rules?  dpkg-architecture offers 6 different ones:
> DEB_{BUILD,HOST,TARGET}_{GNU_TYPE,MULTIARCH}?  I'm guessing
> DEB_TARGET_MULTIARCH, but I'm really not certain, so it would be great
> to confirm that.
It's always DEB_HOST_MULTIARCH. *_TARGET_* are for Canadian cross. See
TERMS in dpkg-architecture(1).

> About the location, though: why do compiled Python libraries live in
> /usr/lib/python3/dist-packages/ and not
> /usr/lib//? 
That's where the import machinery expects them. They also have special
names.

> And is there a good reason not to do the same with this
> Python-package-specific library?
Yes, it's not Python-related.

> It's not for general use, so I can't see why I shouldn't put it in the
> python3 directory with the other compiled Python module libraries.
It's not a module.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Build and run-time triplets

2022-06-09 Thread Andrey Rahmatullin
On Thu, Jun 09, 2022 at 08:42:28AM +0100, Julian Gilbey wrote:
> > > I'd like to ask for some help.  I'm working on packaging pydevd, which
> > > builds a private .so library.  Ordinary extensions built using cython
> > > or similar end up being called "foo.cpython-310-x86_64-linux-gnu.so",
> > > but this library, which is not dependent on the Python version, should
> > > presumably be called "bar.x86_64-linux-gnu.so".
> > If it's just a private library and not a Python module it should be called
> > bar.so.
> > 
> > > Question 1: How do I determine (within Python) the triplet to use when
> > > building the library?
> > You don't.
> > 
> > > Question 2: How do I determine (within Python) the triplet to use when
> > > loading the library at runtime?
> > You don't, but also how are you actually loading it?
> 
> Well, the upstream wanted to compile two versions of the library, one
> for 64 bit architectures and one for 32 bit architectures.  I don't
> really want to build two different arch libraries in a single build,
> because that seems very contrary to the way the Debian architectures
> work, and would also limit it to the amd64/i386 architectures for no
> obviously good reason.  I had imagined that if there is some sort of
> multiarch setup, one might have the amd64 and i386 packages installed
> simultaneously, hence the need for different names.
The normal way for this is putting it into
/usr/lib//pkgname/foo.so, and according to the code below you'll
need the full path at the run time so you indeed need the triplet at both
build and run time. You can get the triplet in d/rules, not sure how
should you pass it to the build system as that depends on the build system
used. For the run time, https://wiki.debian.org/Python/MultiArch suggests
sys.implementation._multiarch (note that you cannot use it during the
build as that would break cross-compilation etc.), not sure if there are
better ways. 

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Build and run-time triplets

2022-06-09 Thread Andrey Rahmatullin
On Wed, Jun 08, 2022 at 10:43:57PM +0100, Julian Gilbey wrote:
> I'd like to ask for some help.  I'm working on packaging pydevd, which
> builds a private .so library.  Ordinary extensions built using cython
> or similar end up being called "foo.cpython-310-x86_64-linux-gnu.so",
> but this library, which is not dependent on the Python version, should
> presumably be called "bar.x86_64-linux-gnu.so".
If it's just a private library and not a Python module it should be called
bar.so.

> Question 1: How do I determine (within Python) the triplet to use when
> building the library?
You don't.

> Question 2: How do I determine (within Python) the triplet to use when
> loading the library at runtime?
You don't, but also how are you actually loading it?

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: a review of your bumblebee-status package

2022-06-07 Thread Andrey Rahmatullin
On Mon, Jun 06, 2022 at 10:42:53PM -0400, Ben Westover wrote:
> > Does the package *work* at all in 3.10? We might not want to silence
> > real errors here...
> 
> Upstream says 3.4-3.9 is supported, but I don't know if that's because 3.10
> doesn't work or because they haven't bothered to add it. Searching their bug
> tracker, I wasn't able to find any 3.10-related issues yet.
> I also haven't tried to use the program with Python 3.10, because I don't
> use it myself at all (packaging this for a friend).
This is a really bad idea IMO.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Ask for reviewing

2022-05-28 Thread Andrey Rahmatullin
On Sat, May 28, 2022 at 06:39:56PM +0430, Danial Behzadi wrote:
> Hey folks,
> 
> I recently uploaded my python app to deb-expo. As this is my first
> packaging experience in Debian, I would love to get some feedback on my
> packaging to make it better.
> 
> Here is my package: https://mentors.debian.net/package/tractor/
You shouldn't make this a native package or keep an upstream changelog in
debian/changelog.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: How to create a new package in git ?

2022-05-23 Thread Andrey Rahmatullin
On Mon, May 23, 2022 at 10:02:09AM +0200, Jean Baptiste Favre wrote:
> Hello,
> Looking to help to package Frescobaldi 3.2 release, which includes Python
> 3.10 compatibility fixes, I figured out 3.2 release introduces a new
> dependency against qpageview [1] which is currently not packaged in Debian.
> I looked around for documentation to remember how to bootstrap a new Python
> package, and only found the Python-team policy [2].
> Unfortunatly, it doesn't explain how to properly setup a new package, and I
> can't remember how it previously did :(
https://wiki.debian.org/Python/GitPackaging may be helpful here.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: ITP: tractor -- Setup an onion routing proxy

2022-04-30 Thread Andrey Rahmatullin
On Sat, Apr 30, 2022 at 01:38:02PM +0430, دانیال بهزادی wrote:
> Hey,
> 
> I recently sent an [ITP request](1) of [my python package](2) to wnnp and
> they told me to send it here.
> 
> I'm not familiar to the workflow here yet. What should I do to include this
> app (and my other packages) in Debian?
If you want to maintain these packages in Debian yourself you should
follow https://mentors.debian.net/intro-maintainers/

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Help for python-subby needed

2022-01-28 Thread Andrey Rahmatullin
On Fri, Jan 28, 2022 at 09:48:00PM +0100, Andreas Tille wrote:
> Hi,
> 
> I need python-subby as a new dependency for some Debian Med package.
> Unfortunately it does not build easily[1]:
> 
>dh_auto_build -O--buildsystem=pybuild
> E: pybuild pybuild:367: build: plugin flit failed with: Neither [project] nor 
> [tool.flit.metadata] found in pyproject.toml
> E: pybuild pybuild:367: build: plugin flit failed with: Neither [project] nor 
> [tool.flit.metadata] found in pyproject.toml
> dh_auto_build: error: pybuild --build -i python{version} -p "3.10 3.9" 
> returned exit code 13
It indeed uses poetry, not flit, but you have export PYBUILD_SYSTEM=flit.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: [help] pymol: Deprecation warning during startup

2021-12-14 Thread Andrey Rahmatullin
On Tue, Dec 14, 2021 at 09:17:31PM +0100, Andreas Tille wrote:
> I think I've fixed the issue[1] and it works nicely at command line.  
> Unfortunately
> Salsa-CI[2] shows a new issue
> 
>AttributeError: module 'importlib' has no attribute 'util'
You should explicitly import modules that you are using, such as
`importlib.util`.

> which I do not understand at all since at command line there is the attribute 
> 'util'.
As you can see in sys.modules, some modules are imported by default in
some circumstabces. You shouldn't depend on that.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Installing data files with pybuild

2021-12-01 Thread Andrey Rahmatullin
On Wed, Dec 01, 2021 at 04:57:44PM +, Julian Gilbey wrote:
> Hello!
> 
> pybuild is magic.  It knows where the build directory is, despite it
> seemingly calling setup.py with no command line arguments specifying
> it!
> 
> But anyway, my actual question is this.  How do I ensure that the data
> files are also copied into the package?
Why do you need this? Does setup.py not install them?

> Only the .py files are currently included in the build; what is the
> best way to include all of the data files after the build step and
> before the test step, and then to ensure they are included in the
> final package?
Apart from fixing setup.py? execute_after_dh_auto_install I guess.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: [Help] diskcache: FTBFS now even earlier due to Python3.10

2021-11-29 Thread Andrey Rahmatullin
On Mon, Nov 29, 2021 at 05:58:47PM +0100, Andreas Tille wrote:
> ERROR:   py310: could not install deps [django>=2.2.*, pytest, pytest-cov, 
> pytest-django, pytest-xdist]; v = 
> InvocationError("/build/diskcache-5.2.1/.tox/py310/bin/python -m pip install 
> 'django>=2.2.*' pytest pytest-cov pytest-django pytest-xdist", 1)
> E: pybuild pybuild:354: test: plugin distutils failed with: exit code=1: cd 
> /build/diskcache-5.2.1/.pybuild/cpython3_3.10_diskcache/build; tox -c 
> /build/diskcache-5.2.1/tox.ini --sitepa
The actual error:

ERROR: Could not find a version that satisfies the requirement 
typing-extensions>=3.6.4 (from importlib-metadata)
ERROR: No matching distribution found for typing-extensions>=3.6.4

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#1000547: RM: ROM; NPOASR; FTBFS; doesn't work

2021-11-24 Thread Andrey Rahmatullin
Package: ftp.debian.org
X-Debbugs-Cc: debian-python@lists.debian.org, rodrilopez@gmail.com
Severity: normal

This package wasn't updated for the Python 3.9 transition and removed from
testing on 2020-11-27. Its FTBFS actually suggests it doesn't work with modern
celery, this was fixed upstream by
https://github.com/clokep/celery-batches/pull/21

$ dak rm -Rn celery-batches
Will remove the following packages from unstable:

celery-batches |  0.2-2 | source
python3-celery-batches |  0.2-2 | amd64, arm64, armel, armhf, i386, 
mips64el, mipsel, ppc64el, s390x

Maintainer: Debian Python Modules Team 


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#1000545: RM: doublex -- ROM; FTBFS; dead upstream

2021-11-24 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-python@lists.debian.org, david.vi...@gmail.com

This package wasn't updated for the Python 3.9 transition and removed from
testing on 2020-11-27. The test failures aren't fixed upstream, and
https://bitbucket.org/DavidVilla/python-doublex/issues/3/#comment-60228312
suggests the upstream is not active.

$ dak rm -Rn doublex
Will remove the following packages from unstable:

   doublex |1.9.2-1 | source
python3-doublex |1.9.2-1 | all

Maintainer: David Villa Alises 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#1000543: RM: python-enable -- ROM; FTBFS; not installable

2021-11-24 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-python@lists.debian.org, va...@debian.org

This package wasn't updated for the Python 3.9 transition. It was removed
from testing even earlier than that, on 2019-10-19. It's not installable
as it requires Python 3.7 or 3.8.
The FTBFS bug is fixed upstream at
https://github.com/enthought/enable/issues/360 (according to the bug
metadata).

$ dak rm -Rn python-enable
Will remove the following packages from unstable:

python-enable |4.8.1-1 | source
python3-enable |4.8.1-1 | amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x

Maintainer: Debian Python Modules Team 


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Bug#1000542: RM: celery-haystack -- ROM; FTBFS; doesn't work; dead upstream

2021-11-24 Thread Andrey Rahmatullin
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-python@lists.debian.org, fl...@debian.org

This package wasn't updated for the Python 3.9 transition and removed from
testing on 2020-12-11. Its FTBFS actually suggests it doesn't work with modern
celery, the upstream bug is https://github.com/django-haystack/celery-
haystack/issues/64. There are some PRs and a fork
(https://pypi.org/project/celery-haystack-ng/) linked there.



Re: [help] New error in test cases of bmtk

2021-11-22 Thread Andrey Rahmatullin
On Mon, Nov 22, 2021 at 01:27:23PM +0100, Andreas Tille wrote:
> Hi,
> 
> I think I've found a patch[1] to solve the original issue which just
> seems to be a floating point precision issue.  However, meanwhile there
> is another less simple issue:
> 
>  ERRORS 
> 
> _ ERROR collecting 
> .pybuild/cpython3_3.10/build/bmtk/tests/builder/test_connection_map.py _
> ImportError while importing test module 
> '/build/bmtk-0.0.9+ds/.pybuild/cpython3_3.10/build/bmtk/tests/builder/test_connection_map.py'.
> Hint: make sure your test modules/packages have valid Python names.
> Traceback:
> /usr/lib/python3/dist-packages/pandas/__init__.py:30: in 
> from pandas._libs import hashtable as _hashtable, lib as _lib, tslib as 
> _tslib
> /usr/lib/python3/dist-packages/pandas/_libs/__init__.py:13: in 
> from pandas._libs.interval import Interval
> E   ModuleNotFoundError: No module named 'pandas._libs.interval'
You need to wait until it's built for 3.10.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Request for review for Poetry(Was: Re: Asking for help Poetry)

2021-11-19 Thread Andrey Rahmatullin
On Fri, Nov 19, 2021 at 03:54:48PM +0100, Taihsiang Ho (tai271828) wrote:
> [5] Some of the error messages from latest package source:
> 
> short test summary info 
> 
> FAILED tests/inspection/test_info.py::test_info_setup_complex_pep517_error
> - ...
> 1 failed, 587 passed, 5 skipped, 23 deselected, 15 warnings in 22.23s
> -
> 
> 588 passed, 5 skipped, 23 deselected, 14 warnings in 24.06s ==
> ==
> dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p
> "3.10 3.9" returned exit code 13
> make: *** [debian/rules:44: binary] Error 25
> 
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit
> status 2
Yes, one test fails with 3.10 which isn't unexpected because the package
wasn't tested with it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: platform.machine() on salsa i386 build?

2021-10-30 Thread Andrey Rahmatullin
On Sat, Oct 30, 2021 at 02:20:40PM +0200, Ole Streicher wrote:
> I have a package (pyraf) where I need to switch off some tests for i386
> (but not for other 32-bit platforms). I do this by
> 
> import platform
> is_i386 = platform.machine() in ('i386', 'i486', 'i586', 'i686')
Yup, this is incorrect. This is the same as `uname -m` and so returns the
kernel architecture.
If you want to do this purely at the upstream side without checking
DEB_HOST_ARCH, AFAIK there is no 100% reliable way to do this.
Please read
https://docs.python.org/3/library/platform.html#platform.architecture for
further ideas and caveats.


-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: dh_python or pybuild

2021-10-11 Thread Andrey Rahmatullin
On Mon, Oct 11, 2021 at 12:23:31PM +, c.bu...@posteo.jp wrote:
> I am not sure if I misunderstand something or if the documentation is
> inconsistent.
> 
> The PythonPolicy
> https://www.debian.org/doc/packaging-manuals/python-policy/
> tells me that dh_python should be the preferred tool for packaging
> (https://www.debian.org/doc/packaging-manuals/python-policy/#versions)
You indeed should use dh_python3, this is normally done by passing "--with
python3" to dh(1).

> But the LibraryStyleGuide
> https://wiki.debian.org/Python/LibraryStyleGuide
> tells me it is pybuild
> (https://wiki.debian.org/Python/LibraryStyleGuide#Overview).
pybuild is a build system, it's used to make actual setup.py calls. You
indeed should use it, this is normally done by passing
"--buildsystem=pybuild" to dh(1).
That page even says "What's important to note here is that both of the
dh_python2 and dh_python3 helpers are being invoked, and also that the
build system that dh will use is pybuild." when showing the correct dh(1)
line.

> And the DPT policy
> https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst
> tells me something about git-buildpackage and gbp.
gbp is not Python-specific and, strictly speaking, is not a part of Debian
packaging, but a tool to store Debian source paclages in git.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Fwd: keyman-config is marked for autoremoval from testing

2021-09-28 Thread Andrey Rahmatullin
On Tue, Sep 28, 2021 at 05:06:01PM +0200, Eberhard Beilharz wrote:
> It (build-)depends on packages with these RC bugs:
> 994354: python-gevent: Removal of the python3-*-dbg packages in sid/bookworm
> https://bugs.debian.org/994354
Please read these lines again.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: python-django-js-asset_1.2.2-3_source.changes REJECTED

2021-09-20 Thread Andrey Rahmatullin
On Mon, Sep 20, 2021 at 11:14:44AM -0400, Sandro Tosi wrote:
> > That's because gbp does not use pristine-tar by default, and
> > debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to
> > fix that.
> I dont think this is the right approach: the default options to work
> on DPT packages should be in gbp default config file (or in another,
> global, config file), and not live in each and every package
> debian/gbp.conf file;
What's the mechanism to put these options there for everyone who works on
a DPT package? Or do you mean just working with whatever is shipped with
gbp?

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: python-django-js-asset_1.2.2-3_source.changes REJECTED

2021-09-20 Thread Andrey Rahmatullin
On Sun, Sep 19, 2021 at 10:56:33PM +0200, Carsten Schoenert wrote:
> Hi Antonio,
> 
> thanks for your quick feedback!
> 
> Am 19.09.21 um 21:24 schrieb Antonio Terceiro:
> 
> > Looking from my side, the tarball from the archive (apt source
> > python-django-js-asset) and the one generated by pristine-tar are
> > identical:
> > 
> > 4b6a2c8625b8e96bbc4ff1588a27238d7d418b03  
> > /tmp/python-django-js-asset_1.2.2.orig.tar.gz
> > 4b6a2c8625b8e96bbc4ff1588a27238d7d418b03  
> > /tmp/archive/python-django-js-asset_1.2.2.orig.tar.gz
> > 
> >  From reading the REJECT email, I think it implies that the .dsc/.changes
> > you uploaded refer to an orig tarball with 6360 bytes. Do you still have
> > the exact artifacts that you uploaded?
> 
> No, not completely.
> But I played around a bit with gbp and pristine-tar too and I was able to
> recreate a tarball which has the same size and the same hashes as the
> *.tar.gz in the archive and the one you've posted by using pristine-tar
> manually.
> 
> If I clean out all completely and build the package from scratch by gbp I
> get again a wrong size and of course also different hashes.
As pristine-tar is not enabled in debian/gbp.conf you need to enable it
explicitly with --git-pristine-tar each time you run a command that uses
it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: How to contribute

2021-05-24 Thread Andrey Rahmatullin
On Sat, May 22, 2021 at 10:39:06PM +0200, Fabrice Bauzac-Stehly wrote:
> I have followed the procedure to be able to contribute within the Debian
> Python team some time ago, and I now have permissions related to the
> Debian Python team.
Then you can contribute directly, at least to the packages where the team
is Maintainer.

> I'd like to know what would be the best course of action and avoid
> seeming bold or rude.  Let's take my merge request below as example:
> 
> https://salsa.debian.org/python-team/packages/beaker/-/merge_requests/1
> 
> It's been there for 3 months without comment.  
We are frozen, but Salsa MRs are also not always reacted upon immediately
(or ever).

> Should I expect that
> there are people watching new merge requests, through e.g. some e-mail
> sent to them whenever a new merge request is created? 
No, because it's opt-in, even though
https://lists.debian.org/debian-devel-announce/2020/04/msg9.html asks
people to opt in or disable MRs.

> Or should I advertise this merge request first on this mailing-list, so
> that it gets some attention?
Normal practice is "advertising" it on a bug report.

> Or should I assume that I am trusted to be a careful person, merging
> myself changes that I believe are "safe", but starting a thread for
> changes I have doubts about?
Well, you don't need to join the team to just send patches and MRs.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Build an initial Debian source package with py2dsp from a GitHub project

2021-05-05 Thread Andrey Rahmatullin
On Thu, May 06, 2021 at 01:16:40AM +0530, Utkarsh Gupta wrote:
> Hello,
> 
> On Thu, May 6, 2021 at 12:33 AM Sandro Tosi  wrote:
> > that's correct, the package still needs to be on PyPI, as that's the
> > place where py2dsp obtains most of the package metadata
> 
> Can we change that or have a flag or something added so that it pulls
> from g/h directly?
But Github doesn't provide the metadata. You would need to get a tarball
and run sdist or something like that.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Build an initial Debian source package with py2dsp from a GitHub project

2021-05-05 Thread Andrey Rahmatullin
On Thu, May 06, 2021 at 12:08:06AM +0530, Utkarsh Gupta wrote:
> However, I am running into an issue (or I guess I am just not doing it
> correctly).
> Whilst trying to package from the g/h source
> (https://github.com/keylime/keylime), it fails like this:
> http://paste.debian.net/1195339/
> 
> Am I missing something?
As far as I can see, the change is only about getting the tarball, it
still needs metadata from PyPI.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Fwd: My deep mistake with the python-absl package

2021-04-19 Thread Andrey Rahmatullin
On Mon, Apr 19, 2021 at 11:12:01AM +0200, Arturo Borrero Gonzalez wrote:
> There may be 2 other options:
> * I could ask ftp-masters to drop my upload, not sure if that's something
> they can do. [spoiler: on IRC #debian-ftp they pointed me to talk to you]
It's already in sid: https://buildd.debian.org/status/package.php?p=python-absl
so it cannot be "dropped".

> * We could upload a new version of python-absl and just replace/overwrite my
> upload. I noticed your original repo [0] contains a pretty up-to-date
> version that could work.
I'm not the package maintainer but I'd suggest either rolling back to the
contents of 0.11.0-1 (pro: we are frozen; con: unlikely that the second
upload breaks anything as the package is not in testing and doesn't have
revdeps) or just uploading 0.12.0-2 based on 0.11.0-1, integrating
improvements from 0.12.0-1 if needed.
There is also a question of the salsa repo history, not sure if it should
contain 0.12.0-1 or not (pro: having all versions in the repo, no
confusion over the missing version; con: confusion over two uploads each
rewriting the previous one).

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Requesting upload of proxmoxer 1.1.1-1 to unstable

2021-04-16 Thread Andrey Rahmatullin
On Fri, Apr 16, 2021 at 03:46:45PM +0200, Lorenz Schori wrote:
> Hi,
> 
> I updated proxmoxer to upstream 1.1.1 (latest stable release). I've
> pushed debian/master, upstream and pristine-tar branches now to salsa.
> 
> I did a smoke test (debian/rules clean, debian/rules build,
> debian/rules binary) and the result looks like a respectable debian
> package.
> 
> The only thing left is "dch -r", release tagging and build, I guess.
> @Elena would you mind taking a look if everything is okay and then
> upload to unstable?
We are frozen so nothing except targeted serious fixes should be uploaded
to unstable.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: How to install older python version on Debian

2021-03-26 Thread Andrey Rahmatullin
On Fri, Mar 26, 2021 at 10:01:54AM +, PICCA Frederic-Emmanuel wrote:
> > Hello,
> 
> > I’d suggest you build it from source (python.org/ftp... with the needed 
> > version) as an additional python version, and then create your venv using 
> > the 3.6.
> 
> > You can dm me if you might need more details.
> 
> It would be great to have a python-builder package whcih generates a 
> pythonX.Y package from the upstream sources.
This would give a false suggestion that such a package works with packaged
modules.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: How to install older python version on Debian

2021-03-26 Thread Andrey Rahmatullin
On Fri, Mar 26, 2021 at 09:55:03AM +0800, Robbi Nespu wrote:
> Dear Debian Python,
> 
> I would like to install older python (version 3.6) on my venv environment
> 
> $ inxi -S
> System:Host: debian Kernel: 5.10.0-4-amd64 x86_64 bits: 64 Desktop: KDE
> Plasma 5.20.5
>Distro: Debian GNU/Linux bullseye/sid
> 
> (venv)$ python --version
> Python 3.9.2
> 
> on fedora I can easily do something like this[1],
This only works as long as the version you need is in the repo. It's
expected that a 2019 distro with 3.7 as the default may also include 3.6,
which is somewhat different from what you expect here.

> If my guest are right. Could you suggest me a solution how to have multiple
> python version so I can load inside venv?
Build it manually and install it somewhere in your user directory or use
pyenv.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Need a Python 3.8 virtual environment

2021-03-03 Thread Andrey Rahmatullin
On Wed, Mar 03, 2021 at 05:39:04PM +, Stefano Rivera wrote:
> You need python3.8-venv. 
Which doesn't exist, at least in the current repos.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Need a Python 3.8 virtual environment

2021-03-03 Thread Andrey Rahmatullin
On Wed, Mar 03, 2021 at 08:32:01AM -0500, Yaroslav Halchenko wrote:
> > I'm trying to use a (non-Debian) python system built on python 3.8.  
> > Debian's 
> > default is currently 3.9 so I am advised to use a virtual environment.   
> > Being 
> > a newbie, I searched around and found a writeup covering several different 
> > virtualization tools [1].   Note I am using Debian 'sid'.
> 
> I know that it is not a "proper" Debian answer
Sure, the only proper Debian answer would be "actually you don't need this
version".

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Need a Python 3.8 virtual environment

2021-03-02 Thread Andrey Rahmatullin
It looks like the only sane way to use non-default Python versions is to
build them locally using pyenv. 

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Python package situation

2021-02-16 Thread Andrey Rahmatullin
On Wed, Feb 17, 2021 at 11:51:52AM +1100, Brian May wrote:
> I believe there are a number of Python packages in Debian unstable that
> are out of date in respect to latest upstream.
> 
> e.g.
> 
> https://qa.debian.org/developer.php?login=bam%40debian.org=yes
> 
> Somebody needs to do the work to update them. But maybe the fact that
> nobody is doing so, might mean that nobody is using them?
And/or nobody who uses them is able to update them in Debian or at least
report a bug, and/or it's easier to install them directly than update them
in Debian and install from there.
Also note that many Python module packages in Debian have very low popcon.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Python package situation

2021-02-16 Thread Andrey Rahmatullin
On Tue, Feb 16, 2021 at 09:48:05PM +0100, Martin wrote:
> > I *wish* I could
> > just install everything via the Debian Packaging System, but the reality for
> > most relevant Python packages is very different: packages are either
> > outdated or do not exist in Debian
> 
> Are you talking about many packages? Or only some, that are
> difficult to package? Can you give an example?
Are you asking about testing or stable? Because for stable the "packages
are either outdated or do not exist" situation is somewhat expected and
testing is not that interesting case, though even in testing we may have a
lot of outdated packages.

> At my job, we were always able to stay with Debian packages, or
> I just packaged the missing pieces, but maybe our use case is
> not that advanced.
Surely you use only a subset of modules while other people may need a
different subset, and ability to make and upload new or updated packages,
unavailable for most Debian Python users, is definitely helpful.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


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


  1   2   3   >