Removal of easy_install

[Scott Talbert]

About a month ago, Matthias removed easy_install from setuptools.  I have 
sent him a few mails and bugs asking about it, but I haven't heard 
anything back.  Anyone know why he did it?  I have a package that 
currently FTBFS because of it.  :(


python-setuptools (39.0.1-2) unstable; urgency=medium

  * Make the PKG-INFO output reproducible (Chris Lamb). Closes: #894215.
  * Stop shipping the easy_install scripts.

 -- Matthias Klose   Mon, 02 Apr 2018 11:46:01 +0200

Re: Removal of easy_install

[Scott Talbert]

On Mon, 7 May 2018, Ben Finney wrote:


About a month ago, Matthias removed easy_install from setuptools.  I
have sent him a few mails and bugs asking about it, but I haven't
heard anything back.  Anyone know why he did it?  I have a package
that currently FTBFS because of it.  :(


Why does a source package *build* need to use ‘easy_install’? The source
package should not need any network access to build, all the source
should be in Debian source packages that are fetched before the build
begins.

Which package is the one that's failing to build now?


I guess I should have included that information.  :)

The source package in question is wxpython4.0.  The reason I use 
easy_install is for installing the python2 version of the module as an 
egg.  The reason I do this is because wxpython3.0 occupies the 'namespace' 
for the wx module for python2.  In other words, both wxpython3.0 and 
wxpython4.0 have a 'wx' module for python2.  In order to avoid a conflict, 
I install the wxpython4.0 version as an egg.  The wxpython3.0 and 
wxpython4.0 modules are not drop-in compatible, so an update-alternatives 
solution doesn't make sense.


Scott

Re: Removal of easy_install

[Scott Talbert]

On Tue, 8 May 2018, Ben Finney wrote:


The source package in question is wxpython4.0. The reason I use
easy_install is for installing the python2 version of the module as an
egg.


Okay, so from that I understand that the Debian package is not invoking
‘easy_install’ to fetch files from the network.


From what I remember, it is surprisingly difficult to convince

‘easy_install’ that it should never access the network, even when you
think you're only performing local operations. Probably it's best to
test this in a virtual machine isolated from the network, to be sure it
succeeds.


Correct - using easy_install to install the egg doesn't fetch files from 
the network.  I haven't tried this in a virtual machine, but it definitely 
works fine on the Fedora builders which are pretty well hardened to have 
no network access.



The reason I do this is because wxpython3.0 occupies the 'namespace'
for the wx module for python2. In other words, both wxpython3.0 and
wxpython4.0 have a 'wx' module for python2. In order to avoid a
conflict, I install the wxpython4.0 version as an egg.


How does that avoid the conflict — that is, what is the effect of
installing the egg such that a namespace conflict is avoided?

I ask because it is likely that today's Python has a better way of
achieving the effect you're wanting, so that ‘easy_install’ is not
needed.


Installing the egg means that all the wxpython4.0 files are installed 
under:

/usr/lib/python2.7/dist-packages/wxPython-4.0.1-py2.7-linux-amd64.egg

Thus, any program or user who does an 'import wx' will get the wxpython3.0 
module and if instead the wxpython4.0 module is desired, the user must 
manually insert the above path into sys.path or PYTHONPATH.


Scott

Broken dbgsym packages for Python 3

[Scott Talbert]

Hi,

I've got a package (wxpython4.0) that builds modules for both Python 2.7 
and Python 3.  When I rebuilt the package in early May, I started getting 
the lintian warning debug-file-with-no-debug-symbols for the Python 3 
dbgsym packages only.  Sure enough, looking at those files, there is not 
much there.  The Python 2.7 dbgsym files are fine.  Given that I haven't 
changed anything in how the Python 3 modules are compiled, it seems that 
some outside change in the distribution has caused this.  Has anyone else 
noticed this, or have any idea what might have caused these dbgsym 
packages to stop working?


Scott

Re: Broken dbgsym packages for Python 3

[Scott Talbert]

On Mon, 4 Jun 2018, Matthias Klose wrote:


I've got a package (wxpython4.0) that builds modules for both Python 2.7
and Python 3.  When I rebuilt the package in early May, I started getting
the lintian warning debug-file-with-no-debug-symbols for the Python 3
dbgsym packages only.  Sure enough, looking at those files, there is not
much there.  The Python 2.7 dbgsym files are fine.  Given that I haven't
changed anything in how the Python 3 modules are compiled, it seems that
some outside change in the distribution has caused this.  Has anyone else
noticed this, or have any idea what might have caused these dbgsym
packages to stop working?


The -dbgsym packages don't work for Python anyway because you need to call 
the

debug interpreter, so I don't think it matters much either way.


Usually the python*-*-dbg packages contain two things:

- the unstripped extensions for the dbg interpreter
- the debug symbols for the python*-* packages.

If you don't have both of these, you should investigate why.


Yes, I'm talking about the automatically generated -dbgsym packages that 
contain the /usr/lib/debug/.build-id/... files.  I have looked into it 
further and the problem seems to be happening during the link phase.  I 
checked the individual .o files (for the Python 3 version) and they all 
contain .debug_str and I can see the symbol names with readelf 
--debug-dump=str.  But then after linking, they are gone.  I ran the exact 
same link command on the Python 2 .o files and the resulting .so has the 
debug info.


Rather bizarre.  I don't know what to think.  g++ (or whatever actually 
does the linking?) doesn't like the Python 3 debug info and discards it?


Scott

Re: Broken dbgsym packages for Python 3

[Scott Talbert]

On Tue, 5 Jun 2018, Andrey Rahmatullin wrote:


Yes, I'm talking about the automatically generated -dbgsym packages that
contain the /usr/lib/debug/.build-id/... files.

Have you read Scott's email?


Yes, but wouldn't they still be useful for symbolicating core dumps?

Scott

Request to join DPMT

[Scott Talbert]

Hi,

I would like to join DPMT so that I could maintain the python-pytest-xdist 
package (that I've recently discussed adopting with Daniel Stender). 
Additionally, I'll need to package a new dependency for a new upstream 
release of python-pytest-xdist.


My Alioth login is swt2c-guest.

I've read https://python-modules.alioth.debian.org/policy.html and accept 
it.


Thanks,
Scott

Re: Request to join DPMT

[Scott Talbert]

On Tue, 6 Feb 2018, Scott Talbert wrote:


Hi,

I would like to join DPMT so that I could maintain the python-pytest-xdist 
package (that I've recently discussed adopting with Daniel Stender). 
Additionally, I'll need to package a new dependency for a new upstream 
release of python-pytest-xdist.


My Alioth login is swt2c-guest.

I've read https://python-modules.alioth.debian.org/policy.html and accept it.


Can I redirect this as a request to join the Salsa group?  :)  My Salsa 
username is the same, swt2c-guest.


Thanks,
Scott

Re: Request to join DPMT

[Scott Talbert]

On Fri, 9 Feb 2018, Scott Talbert wrote:


Hi,

I would like to join DPMT so that I could maintain the python-pytest-xdist 
package (that I've recently discussed adopting with Daniel Stender). 
Additionally, I'll need to package a new dependency for a new upstream 
release of python-pytest-xdist.


My Alioth login is swt2c-guest.

I've read https://python-modules.alioth.debian.org/policy.html and accept 
it.


Can I redirect this as a request to join the Salsa group?  :)  My Salsa 
username is the same, swt2c-guest.


Ping?

RFS: pytest-forked

[Scott Talbert]

Hi,

I'm looking for a sponsor to upload pytest-forked.  It's quite a simple 
package.  It's a small bit of functionality that has been stripped out of 
pytest-xdist and is needed for a new upstream release of pytest-xdist.


It's here on salsa and also uploaded to mentors:
https://salsa.debian.org/python-team/modules/pytest-forked
https://mentors.debian.net/package/pytest-forked

Thanks,
Scott

Re: Pass arguments to setup.py with dh_python2

[Scott Talbert]

On Wed, 28 Mar 2018, Andrey Rahmatullin wrote:


I've got a package where I need to pass an argument to setup.py as part of
the build process.  Is there a way to do this with dh_python2, ie, without
using overrides?

dh_python2 doesn't call setup.py, the build system (python_distutils or
pybuild) does, which one are you using?


I'm not specifying one, so I suppose it is python_distutils?

Scott

Pass arguments to setup.py with dh_python2

[Scott Talbert]

Hi,

I've got a package where I need to pass an argument to setup.py as part of 
the build process.  Is there a way to do this with dh_python2, ie, without 
using overrides?


Scott

pybuild and testing pytest plugins

[Scott Talbert]

When packaging a pytest plugin and wanting to run the plugin's unit tests 
during the build process, the plugin usually has to be installed before 
running the tests, otherwise pytest cannot find the plugin.  This seems to 
require workarounds such as this [1].


Is there any way to avoid this with pybuild or is such a workaround really 
necessary?


Thanks,
Scott

[1] 
https://salsa.debian.org/python-team/modules/pytest-xdist/blob/debian/master/debian/rules#L12

Re: py2-rm: a few leaf packages to work on

[Scott Talbert]

On Thu, 15 Aug 2019, Jonathan Carter wrote:


- btfs


That's weird, this program is written in C and contains no python
whatsoever. Any idea how it ended up on the list? Perhaps there are some
other false positives too?


Probably because it Depends: python?

Scott

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

[Scott Talbert]

On Thu, 5 Sep 2019, Andreas Tille wrote:


Control: tags -1 help

Hi,

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?


Very good question.  The only thing I can see is debian/tests/control has 
Depends: python, but I don't see how that should end up in the binary 
package's Depends.


Scott

Re: Removing python2 packages

[Scott Talbert]

On Tue, 23 Jul 2019, Ondrej Novy wrote:


Hi,

út 23. 7. 2019 v 11:40 odesílatel Scott Talbert  napsal:
  When removing leaf python2 packages for bullseye, is there
  anything


__modules__ package :)
 
  special that needs to be done, other than removing the building
  of the
  python2 subpackage?

  For example, obsoleting of the old package or anything along
  those lines?


* check reverse-depends and "reverse-depends -b"
* remove from d/control
* remove from d/tests
* remove from d/rules
* check/remove d/python-* files
* test
* upload


After doing the above, does anything have to be done to remove the python2 
binary package from the archive?  Is it removed automatically by some sort 
of garbage collection or do I have to file a bug to have it removed?


Scott

Re: Removing python2 packages

[Scott Talbert]

On Tue, 30 Jul 2019, Thomas Goirand wrote:


Hi,

út 23. 7. 2019 v 11:40 odesílatel Scott Talbert  napsal:
  When removing leaf python2 packages for bullseye, is there
  anything


__modules__ package :)
 
  special that needs to be done, other than removing the building
  of the
  python2 subpackage?

  For example, obsoleting of the old package or anything along
  those lines?


* check reverse-depends and "reverse-depends -b"
* remove from d/control
* remove from d/tests
* remove from d/rules
* check/remove d/python-* files
* test
* upload


After doing the above, does anything have to be done to remove the
python2 binary package from the archive?


No. You must *not* add breaks or conflicts.


Is it removed automatically by
some sort of garbage collection or do I have to file a bug to have it
removed?


Do you mean, will python-foo be automatically removed from Sid/Testing,
after your upload? Normally yes, if nothing depends on it. And that's
probably harder to find out than one may think... :)


Yes, that's what I mean.  The reason I ask is because I've done such an 
upload (with python-xyz removed), but this package hasn't disappeared from 
the python2-rm transition tracker.  The specific package involved is 
concordance (python-libconcord was removed).


Scott

Request for sponsor: pytest-bdd

[Scott Talbert]

Hi,

I did a major update for pytest-bdd (new upstream release, dropped py2 
packages, other lintian fixes, etc.).  Does someone mind uploading it?


https://salsa.debian.org/python-team/modules/pytest-bdd

Thanks,
Scott

Re: Request for sponsor: pytest-bdd

[Scott Talbert]

On Mon, 5 Aug 2019, Mattia Rizzolo wrote:


I did a major update for pytest-bdd (new upstream release, dropped py2
packages, other lintian fixes, etc.).  Does someone mind uploading it?

https://salsa.debian.org/python-team/modules/pytest-bdd


Uploaded!

Just, please do not push debian/ tags unless you are completely sure
that's what is going to be uploaded.
In this case I would have liked to run wrap-and-sort, and add a R³
header, but hold back just for that.


Thanks - I will not tag in the future.  For packages that I have DM upload 
rights to, I usually don't even push to salsa until after my upload is 
accepted.  :)


Are you sure that it uploaded successfully?  I haven't seen any messages 
about upload being accepted and I don't see anything on the tracker.


Thanks,
Scott

pytest 4 and autopkgtest dependency loops

[Scott Talbert]

Hi,

Ondřej, I saw you uploaded pytest 4.  This has caused autopkgtest failures 
in a few of the packages I maintain, which I've been working on fixing.  I 
think those should be fine once they migrate to testing, as it should 
clear the autopkgtest failure from pytest 4.


However, there's one package that seems like it is going to cause a 
problem.  I uploaded pytest-xdist 1.29.0-1, which *requires* pytest 4, so 
pytest-xdist won't migrate to testing until pytest 4 does.  On the other 
hand, pytest 4 won't migrate to testing until all its autopkgtest failures 
(which include pytest-xdist) clear (right?).  So it seems we have a loop 
here.  How do we resolve it?


Scott

Re: pytest 4 and autopkgtest dependency loops

[Scott Talbert]

On Fri, 9 Aug 2019, Graham Inggs wrote:


However, there's one package that seems like it is going to cause a
problem.  I uploaded pytest-xdist 1.29.0-1, which *requires* pytest 4, so
pytest-xdist won't migrate to testing until pytest 4 does.  On the other
hand, pytest 4 won't migrate to testing until all its autopkgtest failures
(which include pytest-xdist) clear (right?).  So it seems we have a loop
here.  How do we resolve it?


I believe the solutions is for python-pytest and python3-pytest to add
Breaks: python-pytest-xdist (<< 1.29.0-1~)
and
Breaks: python3-pytest-xdist (<< 1.29.0-1~)
respectively.


Thanks.  As an aside, what does the tilde at the end of the version number 
mean?  I have seen that in control files before, but I've been unable to 
find anything in the documentation about it.


Scott

dh_python2 removing empty directories

[Scott Talbert]

I'm running dh_python2 in a package on a non-standard directory path so it 
will handle byte compilation, etc.  However, it seems to be removing empty 
directories from the directory tree.  Is there any way to avoid this 
behavior?


Thanks,
Scott

Re: dh_python2 removing empty directories

[Scott Talbert]

On Fri, 19 Jul 2019, Andrey Rahmatullin wrote:


I'm running dh_python2 in a package on a non-standard directory path so it
will handle byte compilation, etc.  However, it seems to be removing empty
directories from the directory tree.  Is there any way to avoid this
behavior?

From Python package dirs or outside them?


Well, outside of the standard python package dirs, but inside the 
non-standard path that I'm passing to dh_python2.


Scott

Re: dh_python2 removing empty directories

[Scott Talbert]

On Fri, 19 Jul 2019, Andrey Rahmatullin wrote:


I'm running dh_python2 in a package on a non-standard directory path so it
will handle byte compilation, etc.  However, it seems to be removing empty
directories from the directory tree.  Is there any way to avoid this
behavior?

From Python package dirs or outside them?


Well, outside of the standard python package dirs, but inside the
non-standard path that I'm passing to dh_python2.

If it's a place where modules are stored, why do you need empty dirs
there?


It's a bit disorganized, unfortunately.  There is also data stored there.

Scott

Removing python2 packages

[Scott Talbert]

When removing leaf python2 packages for bullseye, is there anything 
special that needs to be done, other than removing the building of the 
python2 subpackage?


For example, obsoleting of the old package or anything along those lines?

Scott

Re: Removing python2 packages

[Scott Talbert]

On Tue, 23 Jul 2019, Ondrej Novy wrote:


út 23. 7. 2019 v 11:40 odesílatel Scott Talbert  napsal:
  When removing leaf python2 packages for bullseye, is there
  anything


__modules__ package :)
 
  special that needs to be done, other than removing the building
  of the
  python2 subpackage?

  For example, obsoleting of the old package or anything along
  those lines?


* check reverse-depends and "reverse-depends -b"
* remove from d/control
* remove from d/tests
* remove from d/rules
* check/remove d/python-* files
* test
* upload


Thanks.  The reason I asked about 'obsoleting' is because I wondered about 
what will happen on the upgrade case.  Say, I remove python-foo from 
bullseye.  When a user running buster with python-foo installed upgrades 
to bullseye, what will happen?  Will apt try to remove python-foo?


Scott

Re: Removing python2 packages

[Scott Talbert]

On Wed, 24 Jul 2019, Neil Williams wrote:


napsal: When removing leaf python2 packages for bullseye, is there
  anything


__modules__ package :)
 
  special that needs to be done, other than removing the
building of the
  python2 subpackage?

  For example, obsoleting of the old package or anything along
  those lines?


* check reverse-depends and "reverse-depends -b"
* remove from d/control
* remove from d/tests
* remove from d/rules
* check/remove d/python-* files
* test
* upload


Thanks.  The reason I asked about 'obsoleting' is because I wondered
about what will happen on the upgrade case.  Say, I remove python-foo
from bullseye.  When a user running buster with python-foo installed
upgrades to bullseye, what will happen?  Will apt try to remove
python-foo?


Not unless something actually Breaks: or Conflicts: or the user runs
autoremove.

If a leaf package bar changes from Depends: python-foo to python3-foo,
then python-foo will remain installed. There are lots of packages in
Stretch that are not in Buster. Upgrading leaves them in place unless
there is something which actively Conflicts: or Breaks: them. That's
why autoremove is so useful after dist-upgrade.


Assuming python 2 is removed from bullseye, upon an upgrade from buster to 
bullseye, I guess we are assuming python 2 would remain installed on 
upgraded systems?


Scott

Re: Removing python2 packages

[Scott Talbert]

On Wed, 24 Jul 2019, Neil Williams wrote:


út 23. 7. 2019 v 11:40 odesílatel Scott Talbert 
napsal: When removing leaf python2 packages for bullseye, is there
  anything


__modules__ package :)
 
  special that needs to be done, other than removing the
building of the
  python2 subpackage?

  For example, obsoleting of the old package or anything along
  those lines?


* check reverse-depends and "reverse-depends -b"
* remove from d/control
* remove from d/tests
* remove from d/rules
* check/remove d/python-* files
* test
* upload


Thanks.  The reason I asked about 'obsoleting' is because I wondered
about what will happen on the upgrade case.  Say, I remove python-foo
from bullseye.  When a user running buster with python-foo installed
upgrades to bullseye, what will happen?  Will apt try to remove
python-foo?


Not unless something actually Breaks: or Conflicts: or the user runs
autoremove.

If a leaf package bar changes from Depends: python-foo to python3-foo,
then python-foo will remain installed. There are lots of packages in
Stretch that are not in Buster. Upgrading leaves them in place unless
there is something which actively Conflicts: or Breaks: them. That's
why autoremove is so useful after dist-upgrade.


What about reverse dependencies that are "Suggests" vice "Depends?"  Do 
all Suggests dependencies needs to be removed first as well?


NOTE: reverse-depends (aside from '-b' being broken in unstable right 
now), does not seem to show Suggests dependencies by default.

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

[Scott Talbert]

On Fri, 8 Nov 2019, Andreas Tille wrote:


Hi,

I started an attempt to port graphlan to Python3 in Git[1] but its
autopkgtest throws errors:



Running test script ./IBD_biogeography/run.sh .
Traceback (most recent call last):
 File "/usr/bin/graphlan_annotate", line 26, in 
   from src.graphlan_lib import CircTree as CTree
 File "/usr/share/graphlan/src/graphlan_lib.py", line 99, in 
   legal_options = 
set(zip(*clade_attr+ext_attr+int_attr+structural_attr+global_graphical_attr+branch_attr+leg_attr)[0])
 | set(['class'])
TypeError: 'zip' object is not subscriptable
Traceback (most recent call last):
 File "/usr/bin/graphlan", line 29, in 
   from src.graphlan_lib import CircTree as CTree
 File "/usr/share/graphlan/src/graphlan_lib.py", line 99, in 
   legal_options = 
set(zip(*clade_attr+ext_attr+int_attr+structural_attr+global_graphical_attr+branch_attr+leg_attr)[0])
 | set(['class'])
TypeError: 'zip' object is not subscriptable


Try converting the zip(x) to list(zip(x)).

See: 
https://stackoverflow.com/questions/27431390/typeerror-zip-object-is-not-subscriptable/27431433


Scott

Re: RFS: python-traits

[Scott Talbert]

On Wed, 4 Dec 2019, Dmitry Shachnev wrote:


Hi,

Can someone please do an upload of python-traits?  I did an update to the
latest upstream release, plus various minor fixes.  I didn't remove Python 2
support yet as there are still a few rdeps.

https://salsa.debian.org/python-team/modules/python-traits


- The changelog entry from 4.6.0-1 upload is missing.
- You added ${sphinxdoc:Depends}, but none of the packages contains any .html
 files, so that substitution variable is undefined. Please either build and
 ship the documentation, or remove that variable and python3-sphinx from
 Build-Depends.

Please fix that and I will sponsor this.


Done.


Also are you interested in python-traitsui package? It would be nice to get
it ported to Python 3 or removed.


Yes, I was planning to work on that package next.

Scott

Re: pytest help needed

[Scott Talbert]

On Wed, 4 Dec 2019, Andreas Tille wrote:


Hi,

I try to prepare the latest git commit from upstream of python-pbcore[1].
Unfortunately the build time test fails with:

...
 dh_auto_test
I: pybuild base:217: python3.8 setup.py test
running pytest
running egg_info
writing pbcore.egg-info/PKG-INFO
writing dependency_links to pbcore.egg-info/dependency_links.txt
writing entry points to pbcore.egg-info/entry_points.txt
writing requirements to pbcore.egg-info/requires.txt
writing top-level names to pbcore.egg-info/top_level.txt
reading manifest file 'pbcore.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
/usr/lib/python3.8/distutils/dist.py:274: UserWarning: Unknown distribution 
option: 'test_requires'
 warnings.warn(msg)
warning: no files found matching '*.txt'
writing manifest file 'pbcore.egg-info/SOURCES.txt'
running build_ext
ERROR: usage: setup.py [options] [file_or_dir] [file_or_dir] [...]
setup.py: error: unrecognized arguments: -n --dist=loadscope --cov=./pbcore 
--cov-report=xml:coverage.xml
 inifile: /build/python-pbcore-1.7.1+git20191121.7947eb7+dfsg/pytest.ini
 rootdir: /build/python-pbcore-1.7.1+git20191121.7947eb7+dfsg

E: pybuild pybuild:341: test: plugin custom failed with: exit code=4: python3.8 
setup.py test
dh_auto_test: pybuild --test --test-pytest -i python{version} -p "3.8 3.7" 
returned exit code 13
...

Those arguments are mentioned in pytest.ini which reads:


[pytest]
markers =
   pbtestdata: requires the 'PacBioTestData' package to be installed
   internal_data: requires access to internal data on 
'/pbi/dept/secondary/siv/testdata'
   constools: requires 'pbindex', 'samtools' and 'pbmerge' in PATH

addopts =
   -v -n auto --dist=loadscope --durations=20 --junitxml=nosetests.xml 
--cov=./pbcore --cov-report=xml:coverage.xml


Any hints what options I should use instead?


I think you also need pytest plugins xdist and cov (Debian packages 
python3-pytest-xdist and python3-pytest-cov).


Scott

Joining PAPT

[Scott Talbert]

Hi,

I'm already a member of DPMT, I would like to join PAPT as well so I can 
also contribute to those packages.  I have read the policy and accept it.


Salsa ID: swt2c-guest

Thanks,
Scott

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

[Scott Talbert]

On Thu, 12 Dec 2019, Andreas Tille wrote:


Control: tags -1 help

Hi,

it seems pdb2pqr is orphaned upstream.  However, it seems to be worth
keeping inside Debian thus I tried my luck to port it to Python3 in
Git[1].  Unfortunately the build runs into

 scons: Building targets ...
 CopySubAction("pdb2pqr.py", "pdb2pqr.py.in")
 scons: *** [pdb2pqr.py] TypeError : a bytes-like object is required, not 
'str'
 Traceback (most recent call last):
   File "/usr/lib/scons/SCons/Action.py", line 1209, in execute
 result = self.execfunction(target=target, source=rsources, env=env)
   File "/usr/lib/scons/SCons/Action.py", line 1371, in __call__
 return self.parent.actfunc(*args, **kw)
   File "./site_scons/site_init.py", line 123, in CopySubAction
 contents = contents.replace(k, v)
 TypeError: a bytes-like object is required, not 'str'
 scons: building terminated because of errors.

I wonder whether it might just be a scons issue.  Please note that I'm
using scons 3.1.1-4 from experimental that is supposed to run with
Python3.

Any hint would be welcome.

Kind regards

  Andreas.


[1] https://salsa.debian.org/med-team/pdb2pqr


I don't see any Python3 changes in that repository.  Did you push your 
changes?


Anyway, the problem is likely in CopySubAction in site_scons/site_init.py.

On line 111, the file 'sourcefile' is opened as binary.  Then, when then 
next line, 'contents = r.read()' is executed, contents ends up as a bytes 
object.  Thus on line 123, when 'contents = contents.replace(k, v)' is 
executed, contents is a bytes object, whereas k and v are strings.  You 
can't mix strings and bytes objects like that in Python 3.


You could perhaps try opening the file as a text file instead (remove the 
'b') from the open function call.


Scott

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

[Scott Talbert]

On Thu, 12 Dec 2019, Andreas Tille wrote:


That hint was helpful anyway and I get further now.  I think now the
problem is to convince scons to install in $(CURDIR)/debian/tmp which
seems to try rather /usr/share/pdb2pqr directly:


Looks like the debian/rules file is specifying /usr/share/pdb2pqr as PREFIX:

https://salsa.debian.org/med-team/pdb2pqr/blob/master/debian/rules#L33


Arrghh, good if somebody else is proof-reading.  However, setting this
does not help:



mkdir -p /build/pdb2pqr-2.1.1+dfsg/debian/tmp/usr/share/pdb2pqr
scons \
   URL="http://localhost/pdb2pqr/; \
   PREFIX="/build/pdb2pqr-2.1.1+dfsg/debian/tmp/usr/share/pdb2pqr"
scons: Reading SConscript files ...
not using opal
scons: done reading SConscript files.
scons: Building targets ...
CopySubAction("pdb2pqr.py", "pdb2pqr.py.in")
scons: *** [pdb2pqr.py] Can't write target file pdb2pqr.py
scons: building terminated because of errors.


I think you need to change the other open() call in that function to write 
in text mode also.


Scott

Re: kmer: Python2 removal in sid/bullseye

[Scott Talbert]

On Thu, 19 Dec 2019, Andreas Tille wrote:


Traceback (most recent call last):
 File "/usr/bin/../lib/atac/bin/AtacDriver.py", line 18, in 
   import MyFile
 File "/usr/lib/atac/lib/MyFile.py", line 6, in 
   class myfile(file):
NameError: name 'file' is not defined
PYTHONPATH=/usr/bin/../lib/atac/lib
Chainer failed.


The 'file' class doesn't exist anymore in Python 3.  You'll have to 
rewrite myfile to not use it.


Scott

RFS: python-traits

[Scott Talbert]

Hi,

Can someone please do an upload of python-traits?  I did an update to the 
latest upstream release, plus various minor fixes.  I didn't remove Python 
2 support yet as there are still a few rdeps.


https://salsa.debian.org/python-team/modules/python-traits

Thanks,
Scott

Request to (re)-join DPMT and PAPT

[Scott Talbert]

Hi,

I am currently a member as swt2c-guest, but I recently became a DD, so can 
I please be re-added to DPMT and PAPT under swt2c.


I still accept all policies.  :)

Thanks,
Scott

Re: Python3-kivy & fife Installation SyntaxWarning (Was: Request for backport of python3-kivy)

[Scott Talbert]

On Thu, 9 Jan 2020, Cindy Sue Causey wrote:


Oh, boy, oh, boy, an excuse for my first post!! *waving!*


Hi Cindy and welcome!


About an hour ago, I was installing more Python and other types of
developer-learning packages on a Bullseye debootstrap in chroot. A
couple of dependency packages that came along with threw
SyntaxWarnings I'd never encountered as a regular user. Python3-kivy
and python3-fife are the two packages involved.

The warnings are relatively similar and mainly resemble:

SyntaxWarning: "is not" with a literal. Did you mean "!="?
if module is not "FIFE":

AND..

SyntaxWarning: "is" with a literal. Did you mean "=="?
 if module is "FIFE":

python3-kivy's second lines read e.g.:

 if type(data) is 'dict':
 elif type(data) is 'list':
 walk_tree = 'walk' if focus_dir is 'focus_next' else 'walk_reverse'


Yes, I've seen a few of these SyntaxWarning's start to pop up as well. 
They have started popping up because Python 3.8 (or maybe 3.7) has started 
to report them, whereas they were ignored before.


If you feel so inclined, you could report them as bugs in python3-kivy and 
python3-fife package.  If you feel even further inclined, you could submit 
a patch to fix them.  :)


Scott

Re: Request to join PAPT

[Scott Talbert]

On Mon, 11 May 2020, Doug Torrance wrote:


On Thursday, April 23, 2020 10:32:42 PM EDT Doug Torrance wrote:

I am interested in joining the Python Applications Packaging Team.  I'm
experienced in packaging for Debian and am an active member of the Window
Maker and Science teams.  However, I don't have much experience with Python
packaging yet and am looking for some guidance and extra sets of eyes on
any packages that I might maintain under the PAPT umbrella.

Currently, I maintain one package which I think would be a good fit for the
team, git-big-picture [1].  It's currently out of testing with RC bug
#936615.  However, I've packaged a new upstream version which fixes it, and
I think it's almost ready for review and sponsorship.


Also quite late, but welcome to the team.  Note I did add you with your
current username.


No worries -- thank you!

I've pushed the package I was mentioning to its new home:
https://salsa.debian.org/python-team/applications/git-big-picture

Would anyone be able to review/sponsor?


Looks good, uploaded.

Scott

Re: DD Ping - New upstream release for python-rq

[Scott Talbert]

On Sat, 16 May 2020, Marcos Fouces wrote:


Hello

I packaged a new release for python-rq [1]. Please, consider review and
upload.

[1] https://salsa.debian.org/python-team/modules/python-rq


I added a gbp.conf and uploaded.

Thanks,
Scott

Re: Help fixing #959558 (case: FTBFS: AttributeError: 'tuple' object has no attribute 'lstrip' with sphinx 2.4)

[Scott Talbert]

On Tue, 26 May 2020, Thomas Goirand wrote:


Hi there!

Does any of you knows how to fix this bug?
https://bugs.debian.org/959558

Almost all of OpenStack can removed from Bullseye if not fixed in time,
so I tried to fix, but couldn't.


It looks like it's a bug in sphinx.  I tried sphinx 3.0.4 and it seems to 
work fine.  2.4.4 still has the problem, however.


Dmitry, do you plan to update to sphinx 3.0.x soon?

Scott

Re: pyarrow: Could NOT find Python3 (missing: Python3_LIBRARIES Python3_INCLUDE_DIRS)

[Scott Talbert]

On Wed, 22 Jul 2020, Andreas Tille wrote:


Hi,

I intend to package pyarrow[1] as a precondition for some Debian
Med package.  Unfortunately I get:

...
-- Build output directory: 
/build/python-pyarrow-0.17.1/build/temp.linux-x86_64-3.8/release
CMake Error at 
/usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
 Could NOT find Python3 (missing: Python3_LIBRARIES Python3_INCLUDE_DIRS
 Development NumPy) (found version "3.8.5")
Call Stack (most recent call first):
 /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 
(_FPHSA_FAILURE_MESSAGE)
 /usr/share/cmake-3.16/Modules/FindPython/Support.cmake:2214 
(find_package_handle_standard_args)
 /usr/share/cmake-3.16/Modules/FindPython3.cmake:300 (include)
 cmake_modules/FindPython3Alt.cmake:46 (find_package)
 CMakeLists.txt:196 (find_package)


-- Configuring incomplete, errors occurred!
See also 
"/build/python-pyarrow-0.17.1/build/temp.linux-x86_64-3.8/CMakeFiles/CMakeOutput.log".
error: command 'cmake' failed with exit status 1


Any idea why these variables are not sensibly set automatically and what
I can do to provide these?


Try adding python3-all-dev to Build-Depends.

Scott

Re: Maintaining all of the testing-cabal packages under the OpenStack team

[Scott Talbert]

On Mon, 29 Jun 2020, Scott Kitterman wrote:


More over, mock debhelper was upgraded to 13, for no apparent

reason

(yet another "cosmetic fix" that isn't helping?). I'd like to

remind

everyone that, increasing debhelper compat version to a number

that

isn't in stable, without a specific reason (like the need of a

specific

feature that wasn't there before) is just annoying for anyone
maintaining backports. That's truth even for when debhelper

itself is

backported to oldstable (it's always nicer to be able to build a
backport without requiring another backport at build time).

nope, this is not true. Using the newest debhelper compat level is
recommended, see man page. There is no reason to __not__ upgrade
debhelper compat level. I will always upgrade debhelper in my

packages

to the newest debhelper as soon as possible. Please newer downgrade
debhelper in my packages again without asking.


I don't agree this is best practice when backports are to be expected.


I'm substantially less enthusiastic about bumping compat levels than 
Ondrej, but since debhelper 13 is available in buster-backports, 
backporting is unrelated to whether it's a good idea or not.


Can you elaborate on other reasons not the upgrade the compat levels?

Scott

Re: Issues with packaging intake

[Scott Talbert]

On Thu, 18 Jun 2020, Shayan Doust wrote:


I have been having some issues with packaging intake[1] for the Debian
Med packaging team, specifically during pytest. There are a lot of tests
failing, so I contacted upstream for a solution.

According to upstream, the "entrypoints in the setup script are not
being registered when using python3 setup.py build", so I decided to do
some experimentation. It seems like the entry_points do actually get
registered and installed, so I experimentally overrode dh_auto_test and
only triggered dh_auto_test after dh_install (which is also overridden).
Unfortunately, this has not made any difference and a good hundred unit
tests fail.

I am new to Python packaging, especially one that features entry points.
If anyone could please kindly look into the package (and possibly even
building it), this would be much appreciated.

Kind regards,
Shayan Doust

[1]: https://salsa.debian.org/med-team/intake


Yes, this is unfortunately a common packaging problem due to the test 
target running before the install target which causes problems for a lot 
of Python packages that do additional work during the install step.


Anyway, you can fix most of the failures by creating a
debian/pybuild.testfiles file that contains:
intake.egg-info

This causes the egg-info to be copied into the directory used for testing. 
This solves the errors related to plugins but not the ones related to 
console scripts, since the console script shims don't get created until 
'install' runs.  :(


For the console scripts, I don't have any good ideas other than overriding 
dh_auto_test and dh_auto_install (so that you run dh_auto_test *after* 
dh_auto_install).  But you will probably have to set PATH and PYTHONPATH 
to include the install directories so that the console scripts and Python 
modules can be found.


Maybe someone else will have a better idea.

Scott

Moving utility scripts from one package to another

[Scott Talbert]

Hi,

I have a couple of (mostly library) Python packages, src:wxpython3.0, 
which was Python 2 only and has been recently RM'd and src:wxpython4.0 
which is Python 3 only.  wxpython3.0 had a subpackage, python-wxtools, 
which contained a few utility scripts.  wxpython4.0 can also provide those 
utility scripts, so I just wanted to confirm what I need to do to make 
that happen safely when adding a python3-wxtools package to replace 
python-wxtools.


1) python3-wxtools should Replace:, Provide:, and Conflict: 
python-wxtools, correct?


2) Should python3-wxtools even be named with the python3- prefix if it is 
not providing a Python library?  I'm thinking not.


Thanks,
Scott

Re: RFS: git-big-picture

[Scott Talbert]

On Thu, 14 Jan 2021, Torrance, Douglas wrote:



Hello!

There was just a new upstream release of git-big-picture, which I've
packaged:
https://salsa.debian.org/python-team/packages/git-big-picture

Would anyone be able to review/sponsor?


Uploaded, thanks!

Scott

Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs

[Scott Talbert]

On Fri, 25 Jun 2021, Jeremy Stanley wrote:


I feel like there is probably consensus against the use of PyPi-provided
upstream source tarballs in preference for what will usually be a GitHub
release tarball, so I made an MR to this effect (moderate recommendation
rather than a "must" directive):

  https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/16

Comments, corrections, requests for additional information, and
objections welcome :-)  I'm also curious if there isn't consensus by
this point and if it requires further discussion


I work on a vast ecosystem of Python-based projects which consider
the sdist tarballs they upload to PyPI to be their official release
tarballs, because they encode information otherwise only available
in revision control metadata (version information, change history,
copyright holders). The proposal is somewhat akin to saying that a
tarball created via `make dist` is unsuitable for packaging.

"GitHub tarballs" (aside from striking me as a blatant endorsement
of a wholly non-free software platform) lack this metadata, being
only a copy of the file contents from source control while missing
other relevant context Git would normally provide.


I tend to agree about PyPI being the official releases for a lot of 
projects.  "GitHub tarballs" also tend to include other undesirable stuff 
for distribution like upstream CI/CD configuration files, etc.


Scott

Re: Python3 -dbg packages

[Scott Talbert]

On Fri, 3 Sep 2021, Matthias Klose wrote:


Python 3.8 upstream now has a common ABI for normal and debug extension builds,
so it is technically possible to load a debug extension in the normal
interpreter, or to load a normal extension in the debug interpreter.  In Debian,
debug extensions are shipped with a different name, and only loaded by the
corresponding interpreter.  We could change / simply the current setup, but I
first wanted to know how many people are still using the debug builds.  The
reason for the separate debug builds allowed debugging of stuff in modules
further down the Python stack, without having to rebuild the whole stack. There
are several solutions how to simplify the packaging, I'm not sure how much the
dbg extensions are still used ... There are several scenarios:

 - Keep the current setup (-dbg packages need to be available to
   run them).

 - Allow the debug interpreter to load normal debug extensions (but
   load a debug extension if it's available by default).  That would
   allow building debug extensions without having debug extensions
   built for all it's dependencies, maybe requiring changes in the
   dependencies of a package.

 - Stop building debug extensions, and telling developers to
   build extensions in debug mode, if they need them.  That would
   probably be inline with everything else shipped in Debian.

 - Stop building debug extensions, and also stop building the Python
   debug interpreter.  You would need to rebuild the interpreter
   itself to have meaningful debug sessions.  I'm not preferring
   this solution.

I'm currently tending to implement the second scenario, but if people think that
having the -dbg packages available is still useful, then also opt for the third
option.


Let's address this before we start adding Python 3.10 as a supported Python3
version. Starting with the third option.  I'll file bug reports for the
following packages:


Just to confirm on this: if we currently have a python module that builds 
a -dbg package, we can now drop this in favor of the automatically 
generated -dbgsym package for debugging?


Scott

Re: xlsxwriter: How to change homepage url

[Scott Talbert]

On Wed, 15 Sep 2021, c.bu...@posteo.jp wrote:


It seems that this package should probably be fully moved and adopted
into the Debian Python Team - it seems to have been partially done.


I would say the salsa project is outdated because the version number
in setup.py does not fit to upstream.

https://salsa.debian.org/python-team/packages/xlsxwriter/-/blob/master/setup.py#L31

I asked about the Debian package on the Checkbox-Mailinglist
https://lists.ubuntu.com/archives/checkbox-devel/2021-September/000489.html


Well, I think what Andrius meant was to check whether the salsa project 
matches what is currently uploaded to Debian.


The salsa project does however seem to be mismatched with what's currently 
uploaded in Debian unstable.


Salsa has 0.9.3-0.1 + some unreleased changes whereas unstable had 
uploads of 0.9.6-0.1, 1.1.2-0.1, and 1.1.2-0.2 after 0.9.3-0.1, so that 
would need to be sorted out.


Scott

Re: xlsxwriter: How to change homepage url

[Scott Talbert]

On Wed, 15 Sep 2021, Andrius Merkys wrote:


https://tracker.debian.org/media/packages/x/xlsxwriter/control-1.1.2-0.2

The package does not seem to have a current version control repository.

That would be a good start. There doesn't seem to be a project in
salsa.debian.org and it would make things a lot easier when asking for
help with packaging changes, to have a URL in Salsa.


There seems to be a project for xlsxwriter:

https://salsa.debian.org/python-team/packages/xlsxwriter

However, I am not sure whether this one corresponds to the package on
tracker.debian.org, it also would be great to make sure whether it does.


To answer your original question, yes, a new upload is required to update 
the 'Homepage' URL which is defined in debian/control.


It seems that this package should probably be fully moved and adopted into 
the Debian Python Team - it seems to have been partially done.


Scott

Re: xlsxwriter: How to change homepage url

[Scott Talbert]

On Thu, 16 Sep 2021, Nicholas D Steeves wrote:


Am 15.09.2021 21:36 schrieb Emmanuel Arias:

Looking in the salsa repo [0], it is very old. And that shouldn't
happen. I
can updated to the last unstable version tonight/tomorrow.


Just to improve my knowledge about Debian processes: What does it mean
to update the salsa repo to the current upstream? Is it the same as
create a new package? Or is it just one step into creating a new
package?



I didn't look at the packages in question, but as a matter of team
policy, the Debian Python Team uses git-buildpackage repositories, with
pristine-tar, and a repo's layout is as follows:

1. Pristine-tar branch (upstream tarball is imported here)
2. Upstream branch (upstream tarball is unpacked here)
3. Debian packaging branch (name varies)
  * https://dep-team.pages.debian.net/deps/dep14/ is the standardisation
  effort the DPT has adopted.
  * another key phrase is a "patches unapplied" packaging branch.

`gbp import-orig --pristine-tar --uscan` downloads the latest tarball
and puts it in #1, then unpacks it to #2, then creates an
upstream/new_version tag on this upstream branch, then merges that tag
to #3.  One then needs update the version of the current changelog entry
(if UNRELEASED), or create a new one with `dch
-v$new_upstream_version-1`.  Finally, one may need to use `gbp pq` to
import, rebase, and export an existing quilt patch series onto the new
upstream release.

 
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#git-procedures
 https://wiki.debian.org/Python/FAQ
 https://wiki.debian.org/Python/GitPackaging

Other teams/individuals have different policies and practises.


I'm working on updating this package.

Scott

Re: xlsxwriter: How to change homepage url

[Scott Talbert]

On Fri, 17 Sep 2021, Scott Talbert wrote:


Looking in the salsa repo [0], it is very old. And that shouldn't
happen. I
can updated to the last unstable version tonight/tomorrow.


Just to improve my knowledge about Debian processes: What does it mean
to update the salsa repo to the current upstream? Is it the same as
create a new package? Or is it just one step into creating a new
package?



I didn't look at the packages in question, but as a matter of team
policy, the Debian Python Team uses git-buildpackage repositories, with
pristine-tar, and a repo's layout is as follows:

1. Pristine-tar branch (upstream tarball is imported here)
2. Upstream branch (upstream tarball is unpacked here)
3. Debian packaging branch (name varies)
  * https://dep-team.pages.debian.net/deps/dep14/ is the standardisation
  effort the DPT has adopted.
  * another key phrase is a "patches unapplied" packaging branch.

`gbp import-orig --pristine-tar --uscan` downloads the latest tarball
and puts it in #1, then unpacks it to #2, then creates an
upstream/new_version tag on this upstream branch, then merges that tag
to #3.  One then needs update the version of the current changelog entry
(if UNRELEASED), or create a new one with `dch
-v$new_upstream_version-1`.  Finally, one may need to use `gbp pq` to
import, rebase, and export an existing quilt patch series onto the new
upstream release.

 
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#git-procedures
 https://wiki.debian.org/Python/FAQ
 https://wiki.debian.org/Python/GitPackaging

Other teams/individuals have different policies and practises.


I'm working on updating this package.


Package has been updated to version 3.0.1 and brought up to current 
standards.  :)


Scott

Re: RFS: python-untokenize: Untokenize transforms tokens into source code

[Scott Talbert]

On Thu, 7 Oct 2021, Adam Cecile wrote:


Hello

Still looking for sponsoring !

Thanks

On September 28, 2021 10:47:27 PM GMT+02:00, "Adam Cécile"
 wrote:

Hello,
Could someone please upload this little package ? It's a indirect 
(docformatter dep) dependency of xsdata, an awesome XML/dataclasses 
library I'd like to get into the archive.

ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976441
Salsa: https://salsa.debian.org/python-team/packages/python-untokenize
Thanks in advance,
Adam.


Uploaded.

Thanks,
Scott

Re: RFS: python-fastjsonschema: validation of JSON documents by JSON schema drafts 04/06/07

[Scott Talbert]

On Thu, 7 Oct 2021, Adam Cecile wrote:


Hello

Still looking for sponsoring !

Thanks

On September 28, 2021 10:20:25 PM GMT+02:00, "Adam Cécile"
 wrote:

Hello,
Is there someone willing to upload this package ? It was waiting for 
json-schema-test-suite to be uploaded as a separated package, that I did 
a while ago and I just verified the package is in good shape and updated 
to latest upstream patch release.

ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948968
Salsa: https://salsa.debian.org/python-team/packages/python-fastjsonschema
Thanks in advance,
Best regards, Adam.


I tweaked the copyright file to remove the paragraph for the 
json-schema-test-suite files and uploaded.


Scott

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

[Scott Talbert]

On Mon, 29 Nov 2021, Andrey Rahmatullin wrote:


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


That is a really strange error.  importlib-metadata requires 
typing-extenstions>=3.6.4, but it's supposed to be only for python < 3.8. 
Almost seems like a pip bug when comparing version strings?  Perhaps its 
confused with the two-digits in python 3.10?


Scott

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

[Scott Talbert]

On Mon, 29 Nov 2021, Scott Talbert 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


That is a really strange error.  importlib-metadata requires 
typing-extenstions>=3.6.4, but it's supposed to be only for python < 3.8. 
Almost seems like a pip bug when comparing version strings?  Perhaps its 
confused with the two-digits in python 3.10?


Yep, I confirmed this is a bug in pip (and apparently a downstream one) 
and filed a separate bug: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000826


Scott

Re: Request to join the team

[Scott Talbert]

On Tue, 9 Nov 2021, Athos Ribeiro wrote:


Hi,

I am Athos Ribeiro and I would like to join the Python team. At this
moment, I would like to start by helping to add Python 3.10 support to
some packages that may be FTBFS for Python 3.10 (which may help with the
upcoming transition).

I already started with the following packages

https://salsa.debian.org/python-team/packages/unittest2/-/merge_requests/1
https://salsa.debian.org/python-team/packages/python-pyscss/-/merge_requests/2
https://salsa.debian.org/python-team/packages/python-werkzeug/-/merge_requests/2

Some of them may unblock a few other packages which may be FTBFS with
Python 3.10. I will also use this opportunity to ask for sponsorship on
the packages listed above :)


Hi Athos and welcome!

I can't add you to the group, but I uploaded the packages above.  Thanks 
for your work.


Scott

Re: Request to join the team

[Scott Talbert]

On Thu, 11 Nov 2021, Athos Ribeiro wrote:


Hi,

I am Athos Ribeiro and I would like to join the Python team. At this
moment, I would like to start by helping to add Python 3.10 support to
some packages that may be FTBFS for Python 3.10 (which may help with the
upcoming transition).

I already started with the following packages

https://salsa.debian.org/python-team/packages/unittest2/-/merge_requests/1
https://salsa.debian.org/python-team/packages/python-pyscss/-/merge_requests/2
https://salsa.debian.org/python-team/packages/python-werkzeug/-/merge_requests/2

Some of them may unblock a few other packages which may be FTBFS with
Python 3.10. I will also use this opportunity to ask for sponsorship on
the packages listed above :)


Hi Athos and welcome!


Hi Scott,

I can't add you to the group, but I uploaded the packages above.  Thanks 
for your work.


Thank you for the uploads!

I am adding a few more MRs I filed in salsa here in case Scott or
someone else is feeling like sponsoring some of them.

https://salsa.debian.org/python-team/packages/python-leather/-/merge_requests/2
https://salsa.debian.org/python-team/packages/python-agate/-/merge_requests/2
https://salsa.debian.org/python-team/packages/python-pyscss/-/merge_requests/3

https://salsa.debian.org/openstack-team/python/testresources/-/merge_requests/3

While this last one is under the OpenStack team, it is a build dep for
other packages under the Python team, so I also threw it in the list
just in case.


For the first two, I ended up uploading new upstream releases since those 
patches were already incorporated upstream.


I'm not a member of the OpenStack team so I can't help with that last one.

Thanks,
Scott

Re: Removal of python-flask-script and flask-assets from unstable/bookworm

[Scott Talbert]

On Wed, 24 Nov 2021, Thomas Goirand wrote:


Hi,

flask-assets build-depends on python3-flask-script. python-flask-script
depends on Flask, but isn't compatible with Flask 2.x which is now in
unstable. python-flask-script has no commit or release since 2017.

So both packages are kind of doomed...

Neither python-flask-script or flask-assets have reverse dependencies.

I am therefore hereby proposing the removal of python-flask-script and
flask-assets from unstable/testing, which by the way will allow Flask to
migrate to Bookworm.

Your thoughts?


If it's desirable to keep flask-assets, another option might be to just RM 
python-flask-script.  It looks like flask-assets should(?) still work 
without it.  Also, python-flask-script currently FTBFS.


Scott

Re: Bug#999415: transition: pandas 1.1 -> 1.3 - to unstable now or not?

[Scott Talbert]

On Sun, 28 Nov 2021, Rebecca N. Palmer wrote:

After build-testing about half of the reverse dependencies, failures that 
look new-pandas-related are cfgrib #1000726, joypy #1000727, python-skbio 
#1000752, and maybe hyperspy (not filed yet).


python-skbio and hyperspy already FTBFS for unrelated reasons (but fail more 
tests with new pandas), and joypy looks trivially fixable.


Given this and expecting to find a similar number in the other half, against 
pandas 1.3 working on python3.10 while 1.1 doesn't (#1000422), would you 
prefer to have pandas 1.3 in unstable now, or not?


My vote would be: go for it, but then again, I don't maintain any of 
pandas BDs.


Thanks,
Scott

Re: Upload updated python-easygui

[Scott Talbert]

On Wed, 3 Nov 2021, Andreas Noteng wrote:

Hi, i recently pushed an update to python-easygui fixing an FTBFS-bug 
recently filed.


I though I had DM upload priveleges to the package, but apparently I don't. 
Would anyone please upload for me, or grant me upload privileges for the 
package? From before I have DM upload priveleges to packages transgui and 
pyspread, and I had on package pype before it died upstream an was removed 
from Debian.


Uploaded, thanks!

Scott

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

[Scott Talbert]

On Mon, 29 Nov 2021, Andreas Tille wrote:


Control: tags -1 help

Hi,

currently I'm running into


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


Any help would be really welcome


Can you post the full build log somewhere?

Scott

Re: [Help] Re: python-envisage: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" returned exit code 13

[Scott Talbert]

On Thu, 10 Feb 2022, Andreas Tille wrote:


Control: tags -1 help

Hi,

I've updated python-envisage in Salsa[1] to the latest upstream version
and bumped its failing predepends to their according latest upstream and
fixed all bugs in those.  For envisage I'm stumbling upon a Python3.10
related bug I'd like to ask for help:

...
==
ERROR: test_exclude_multiple 
(envisage.tests.test_egg_plugin_manager.EggPluginManagerTestCase)
exclude multiple
--
Traceback (most recent call last):
 File 
"/build/python-envisage-6.0.1/.pybuild/cpython3_3.10_envisage/build/envisage/tests/test_egg_plugin_manager.py",
 line 115, in test_exclude_multiple
   self._add_eggs_on_path([self.egg_dir])
 File 
"/build/python-envisage-6.0.1/.pybuild/cpython3_3.10_envisage/build/envisage/tests/test_egg_based.py",
 line 59, in _add_eggs_on_path
   raise SystemError("Cannot find eggs %s" % errors)
SystemError: Cannot find eggs {}


I spent some time looking into this.  The problem is that upstream 
includes binary eggs (which are Python version specific) as part of its 
test suite.  The problem here is that there are no eggs included for 
Python 3.10.  Upstream is aware of this[1] but unfortunately, that patch 
can't be applied because it is a binary patch.  They have also later[2] 
removed the binary eggs completely, but that patch can't be applied either 
because it involves files that are not in the PyPI distribution.  The best 
solution might be do what Fedora did[3], but for that we'd probably have 
to switch to using a GitHub tarball instead of the PyPI tarball because 
the PyPI tarball is missing files.


Scott

[1] 
https://github.com/enthought/envisage/commit/d29e6f438d16fc6ac6ede5381ba12d9849187b14
[2] 
https://github.com/enthought/envisage/commit/6e5c7ba004e8700bd009c3d2b9444d543709a4d7
[3] 
https://src.fedoraproject.org/rpms/python-envisage/c/a20fa2cf6fe0eaf7604394a8b93bf8d3b48bc599?branch=rawhide

Re: New version of mayavi2 fails to build

[Scott Talbert]

On Thu, 17 Feb 2022, Andreas Tille wrote:


Hi,

as you can see in Salsa-CI build log[1] the new version of mayavi2 fails
with something like:

...
File "/builds/python-team/packages/mayavi2/debian/output/source_dir/mayavi/mlab.py", 
line 16 in 
 File "", line 228 in _call_with_frames_removed
 File "", line 850 in exec_module
 File "", line 680 in _load_unlocked
 File "", line 986 in _find_and_load_unlocked
 File "", line 1007 in _find_and_load
 File "", line 228 in _call_with_frames_removed
 File "", line 1058 in _handle_fromlist
 File "/builds/python-team/packages/mayavi2/debian/output/source_dir/setup.py", 
line 138 in mlab_reference
 File "/builds/python-team/packages/mayavi2/debian/output/source_dir/setup.py", 
line 176 in run
 ...
Aborted (core dumped)
E: pybuild pybuild:367: build: plugin distutils failed with: exit code=134: 
/usr/bin/python3 setup.py build

Any idea what might be wrong here?


Looking at the full log, it appears as if something in the build process 
is trying to open an X display and fails.  Perhaps try running 
dh_auto_build with Xvfb?


Scott

Re: pygame: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" --system=custom --test-args "/usr/bin/xvfb-run {interpreter} -m pygame.tests.__main__ --exclude opengl" returned

[Scott Talbert]

On Wed, 23 Mar 2022, Hugh McMaster wrote:


On Wed, 23 Mar 2022 at 02:37, Andreas Tille wrote:
  Hi,

  Am Wed, Mar 23, 2022 at 12:19:40AM +1100 schrieb Hugh McMaster:
  > On Mon, 28 Feb 2022 at 16:40, Hugh McMaster wrote:
  >
  > > I did some testing and found that pygame 2.1.0 is the first
  recent
  > > version not affected by the FreeType test issue.
  > >
  > > I'll keep digging, but I'd strongly suggest migrating to the
  most
  > > recent upstream version as soon as possible, as I had no
  problems
  > > building it.
  >
  >
  > Any progress on packaging the latest version of pygame?
  >
  > The current package will be removed from testing next week.

  If you ask me lets push pygame 2.1.0 and remove anything that
  does not
  work with this version from testing (it would be removed from
  there
  anyway).  I know its not good style but stagnation in the status
  quo
  is also no good solution.


Agreed. pygame 1.9.6 is now almost 3 years old.


Since there were no objections, and pygame is already slated to be kicked 
out of testing, plus given that pygame 2 is advertised as largely backward 
compatible, I went and did a cursory check on most of pygame's rdeps and 
found they seemed to work fine with pygame 2.  I just went ahead and 
uploaded the new pygame.  Let me know if anyone notices any problems.


Scott

Re: Uncleaned egg-info directory giving lots of bugs about failing to build after successful build

[Scott Talbert]

On Fri, 18 Aug 2023, Andreas Tille wrote:


Am Fri, Aug 18, 2023 at 01:42:53PM +0100 schrieb Julian Gilbey:

I'm sure I'm not the only one who received a whole bunch of bugs
entitled "Fails to build source after successful build" last weekend.
There was one theme common to most of them: the presence of a
*.egg-info directory which was not cleaned by debian/rules clean.

I know the bug report said that this policy is currently under
discussion, but I did get thinking about it.  I imagine that this
particular directory should be the responsibility of dh-python to
clean up, but it may not be sensible to always delete *.egg-info
directories, as they may be present in the orig.tar.gz file.  One
could handle it by manually adding this directory to debian/clean in
each package, but perhaps this should be the default behaviour of
dh-python?

Any thoughts?


I agree that having this a no-brainer and getting all this *.egg-info
caused bugs solved by a simple dh-python update without changing
packaging code would be extremely convenient.  I could imagine creating
a backup of the affected *.egg-info files if existent and copy these
back in clean target could solve this.


It is being worked on:
https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/46

Regards,
Scott

Re: python-catalogue: AttributeError: type object 'EntryPoint' has no attribute '_from_text'

[Scott Talbert]

On Thu, 17 Mar 2022, Andreas Tille wrote:


Hi,

I intend to package python-catalogue[1] but there is a test suite
issue (see salsa-ci for complete log[2]):

platform linux -- Python 3.10.3, pytest-6.2.5, py-1.10.0, pluggy-1.0.0
rootdir: /builds/python-team/packages/python-catalogue/debian/output/source_dir
collected 8 items
catalogue/tests/test_catalogue.py ..F.   [100%]
=== FAILURES ===
__ test_entry_points ___
   def test_entry_points():
   # Create a new EntryPoint object by pretending we have a setup.cfg and
   # use one of catalogue's util functions as the advertised function
   ep_string = "[options.entry_points]test_foo\nbar = 
catalogue:check_exists"

  ep = catalogue.importlib_metadata.EntryPoint._from_text(ep_string)

E   AttributeError: type object 'EntryPoint' has no attribute '_from_text'
catalogue/tests/test_catalogue.py:108: AttributeError
=== short test summary info 
FAILED catalogue/tests/test_catalogue.py::test_entry_points - AttributeError:...
= 1 failed, 7 passed in 0.06s ==

Any hint would be welcome


See: https://github.com/explosion/catalogue/issues/27

TLDR: skip that test on Python 3.10 for now.

Scott

Re: pybuild pyproject.toml problem

[Scott Talbert]

On Thu, 11 Aug 2022, Ole Streicher wrote:


Hi,

I have a package

https://salsa.debian.org/debian-astro-team/asdf-standard

that changed its build process to pyproject.toml. As hinted by pybuild,
I added pybuild-plugin-pyproject to the build dependencies; however it
still does not build properly. The build fails with the following
output:

---8<---
* Building wheel...
Successfully built UNKNOWN-1.0.3-py3-none-any.whl
I: pybuild plugin_pyproject:118: Unpacking wheel built for python3.10 with 
"installer" module
E: pybuild pybuild:369: build: plugin pyproject failed with: UNKNOWN wheel 
found: UNKNOWN-1.0.3-py3-none-any.whl. Does pyproject.toml specify a 
build-backend?
dh_auto_build: error: pybuild --build -i python{version} -p 3.10 returned exit 
code 13
make: *** [debian/rules:5: binary] Error 25
---8<---

which I do not understand. The build backend specified in pyproject.toml is

build-backend = "setuptools.build_meta"

What goes wrong here?

Full build log:

https://salsa.debian.org/debian-astro-team/asdf-standard/-/jobs/3095942


I *think* the issue might be that our setuptools is too old to understand 
how to get project metadata from pyproject.toml (PEP 621).  This seems to 
indicate that it was added in setuptools 61.0.0:


https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html

As a workaround, you might try to patch the metadata back into setup.cfg?

Scott

Re: pybuild pyproject.toml problem

[Scott Talbert]

On Fri, 12 Aug 2022, Ole Streicher wrote:


Scott Talbert  writes:

On Thu, 11 Aug 2022, Ole Streicher wrote:

---8<---
* Building wheel...
Successfully built UNKNOWN-1.0.3-py3-none-any.whl
I: pybuild plugin_pyproject:118: Unpacking wheel built for
python3.10 with "installer" module
E: pybuild pybuild:369: build: plugin pyproject failed with: UNKNOWN
wheel found: UNKNOWN-1.0.3-py3-none-any.whl. Does pyproject.toml
specify a build-backend?
dh_auto_build: error: pybuild --build -i python{version} -p 3.10
returned exit code 13
make: *** [debian/rules:5: binary] Error 25
---8<---


I *think* the issue might be that our setuptools is too old to
understand how to get project metadata from pyproject.toml (PEP 621).
This seems to indicate that it was added in setuptools 61.0.0:

https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html

As a workaround, you might try to patch the metadata back into setup.cfg?


Since setuptools 63 is already in experimental, I will probably just
wait until it makes its way to unstable (and file a bug for it).


Does building with setuptools from experimental resolve the issue?

Scott

Re: python-envisage: FTBFS: AssertionError: 0 != 3

[Scott Talbert]

On Tue, 10 Jan 2023, Andreas Tille wrote:


Hi,

I've updated Git to latest upstream version which does not show the
reported error any more.  However, there are two other issues I seem to
need help for.  I've worked around the initial issue[1]

 FileNotFoundError: [Errno 2] No such file or directory: 'python'

with a patch[2] but this finally leads to a different error[3]

 subprocess.CalledProcessError: Command '['python3', 'setup.py', 'bdist_egg', 
'--dist-dir', '/tmp/tmp14hpgj33']' returned non-zero exit status 1.

Any help would be welcome

Andreas.

[1] https://salsa.debian.org/python-team/packages/python-envisage/-/jobs/3774020
[2] 
https://salsa.debian.org/python-team/packages/python-envisage/-/blob/master/debian/patches/python3.patch
[3] https://salsa.debian.org/python-team/packages/python-envisage/-/jobs/3774219


I'm looking into this.  It appears that something is going horribly wrong 
with the test egg generation (which is now being done upstream 
automatically).


Scott

Re: python-envisage: FTBFS: AssertionError: 0 != 3

[Scott Talbert]

On Tue, 10 Jan 2023, Scott Talbert wrote:


On Tue, 10 Jan 2023, Andreas Tille wrote:


Hi,

I've updated Git to latest upstream version which does not show the
reported error any more.  However, there are two other issues I seem to
need help for.  I've worked around the initial issue[1]

 FileNotFoundError: [Errno 2] No such file or directory: 'python'

with a patch[2] but this finally leads to a different error[3]

 subprocess.CalledProcessError: Command '['python3', 'setup.py', 
'bdist_egg', '--dist-dir', '/tmp/tmp14hpgj33']' returned non-zero exit 
status 1.


Any help would be welcome

Andreas.

[1] 
https://salsa.debian.org/python-team/packages/python-envisage/-/jobs/3774020
[2] 
https://salsa.debian.org/python-team/packages/python-envisage/-/blob/master/debian/patches/python3.patch
[3] 
https://salsa.debian.org/python-team/packages/python-envisage/-/jobs/3774219


I'm looking into this.  It appears that something is going horribly wrong 
with the test egg generation (which is now being done upstream 
automatically).


Pushed a fix to salsa for that issue.  It seems that some of the Debian 
build environment variables were interfering with the test egg generation 
process.


Scott

Re: python-avro: FTBFS: AssertionError: 'reader type: null not compatible with writer type: int' not found in {'reader type: SchemaType.NULL not compatible with writer type: SchemaType.INT'}

[Scott Talbert]

On Thu, 29 Dec 2022, Scott Kitterman wrote:


On Thursday, December 29, 2022 4:13:20 PM EST Andreas Tille wrote:

Control: tags -1 help

Hi,

I wonder whether someone might suggest a fix for


==
FAIL: test_schema_compatibility_type_mismatch
(avro.test.test_compatibility.TestCompatibility.test_schema_compatibility_t
ype_mismatch)
--
Traceback (most recent call last):
  File
"/build/python-avro-1.11.1+dfsg/.pybuild/cpython3_3.11_avro/build/avro/test
/test_compatibility.py", line 1039, in
test_schema_compatibility_type_mismatch self.assertIn(message,
result.messages)
AssertionError: 'reader type: null not compatible with writer type: int' not
found in {'reader type: SchemaType.NULL not compatible with writer type:
SchemaType.INT'}

--
Ran 421 tests in 8.358s

FAILED (failures=1, skipped=3)


Otherwise I will probably exclude Python3.11 from the build to fix this bug.


That's not an actual solution.  If you close the bug on this basis it will
hide the issue and make it appear we are more ready to move to Python 3.11 as
the default (and probably only) Python version for Bookworm.

I didn't look at the actual code.  Typically when something comes up Null is
means that something was not found.  I would look at the code where SchemaType
is determined to see how it might come up with no SchemaType.


It looks like this has already been fixed upstream (although with a 
non-obvious commit message):


https://github.com/apache/avro/commit/432f073c3cfb8ac7edb2793b797ab855c5a978dd

I just uploaded a fix.

Scott T.

python-greenlet update to 2.0.1

[Scott Talbert]

Hi Jelmer,

It looks like you started working on updating python-greenlet to 2.0.1 
(needed because python-gevent was updated and the two versions are now 
incompatible).  Any reason that you stopped or just lack of time?


Thanks,
Scott

Re: pyfakefs: Outdate version was migrated today

[Scott Talbert]

On Fri, 9 Dec 2022, c.bu...@posteo.jp wrote:


Hello folks,
my question is not critic but just learning purpose. Because in the Debian 
universe I always assume that there is a good reason behind each activity, no 
matter if I understand it or not.


Here is one I don't understand.
Today (9th December '22) pyfakefs 4.6.3 was migrated [1] into testing. But 
the latest stable release at upstream is 5.0.0 release two months ago [2].


So why does a Debian package maintainer invest time and resources into 
packaging an out dated version of a package?


The version that migrated to testing on 9 December was just a bug fix, see 
[3].  Version 4.6.3 was initially packaged on 12 September [4].


Scott

[3] 
https://tracker.debian.org/news/1393666/accepted-python-pyfakefs-463-3-source-into-unstable/
[4] 
https://tracker.debian.org/news/1361844/accepted-python-pyfakefs-463-1-source-into-unstable/

Re: python-tesserocr: flaky autopkgtest

[Scott Talbert]

On Sun, 18 Dec 2022, Malik Mlitat wrote:



Hello DPT,

I have updated the package python-tesserocr [1] to skip the flaky test to
fix the issue below.

 I need a maintainer please to upload the new release version 2.5.2-2  to
the Debian archive.


[1] https://salsa.debian.org/python-team/packages/python-tesserocr


Uploaded.  But the ftp-master server is down, so it's unclear when 
that will be fixed (and hopefully the uploads that are occurring now will 
be processed?).


Regards,
Scott

Re: Docu about Salsa workflow

[Scott Talbert]

On Wed, 21 Dec 2022, c.bu...@posteo.jp wrote:


Hello,

sorry for asking. I'm looking or the right document explaining the workflows 
on Salsa.

Am I on the right way here: https://wiki.debian.org/Teams/PythonTeam ?

Most projects on Salsa do have three branch names. I need an explanation of 
them and how they interact.


The team policy talks about the three branches and the Git procedures for 
managing them (using git-buildpackage):


https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#git-procedures

Scott

Re: Updating python-build/getting rid of pep517

[Scott Talbert]

On Wed, 2 Aug 2023, Scott Kitterman wrote:


On Tuesday, August 1, 2023 7:36:38 PM EDT Scott Talbert wrote:

On Tue, 1 Aug 2023, Scott Kitterman wrote:

On Tue, 1 Aug 2023, Scott Kitterman wrote:

The pep517 package has been renamed pyproject-hooks upstream:

https://github.com/pypa/pyproject-hooks

It looks like we need this to update python-build to the latest version
(which we should definitely do sooner rather than later).

Is anyone up  for packaging this?

Once it's in the archive we ought to make sure all current users of
pep517
are switched so we can remove it this cycle.


I'll go ahead and start packaging it.


Excellent.  PEP517 has a few users that will need to be ported/updated:

Initial packaging done, on its way into NEW.


And it's in Unstable now, so it would be good if people could start updating
the relevant team packages.  I filed #1042869 for the one package not in DPT.

* python-build (update to new version, needs pyproject-hooks)


I took care of python-build already as a team upload.

Scott T.

Re: Updating python-build/getting rid of pep517

[Scott Talbert]

On Tue, 1 Aug 2023, Scott Kitterman wrote:


The pep517 package has been renamed pyproject-hooks upstream:

https://github.com/pypa/pyproject-hooks

It looks like we need this to update python-build to the latest version (which
we should definitely do sooner rather than later).

Is anyone up  for packaging this?

Once it's in the archive we ought to make sure all current users of pep517 are
switched so we can remove it this cycle.


I'll go ahead and start packaging it.

Regards,
Scott Talbert

Re: Updating python-build/getting rid of pep517

[Scott Talbert]

On Tue, 1 Aug 2023, Scott Kitterman wrote:


On Tue, 1 Aug 2023, Scott Kitterman wrote:

The pep517 package has been renamed pyproject-hooks upstream:

https://github.com/pypa/pyproject-hooks

It looks like we need this to update python-build to the latest version
(which we should definitely do sooner rather than later).

Is anyone up  for packaging this?

Once it's in the archive we ought to make sure all current users of pep517
are switched so we can remove it this cycle.


I'll go ahead and start packaging it.


Excellent.  PEP517 has a few users that will need to be ported/updated:


Initial packaging done, on its way into NEW.

Scott T.

Re: Recommended way of installing system-wide python application and libraries

[Scott Talbert]

On Tue, 5 Dec 2023, Ivan Perez wrote:


Hi everyone!

I'm currently trying to bring a tool we have at NASA Ames up to speed:
https://github.com/NASA-SW-VnV/ikos

IKOS is a static analyzer for C. I'm really hoping that IKOS can be included
in Debian in the near future.

IKOS is implemented as a  C++ library, and a number of python
tools/wrappers. The tools call mains in modules defined in a python library
`ikos`.

As of right now, our CMakeFiles attempt to install everything (by default)
under /opt/ikos/.

I'm having lots of issues getting the python portions installed system-wide.
I initially upgraded distutils to setuptools, but a recent update is now
asking that I use a venv. More details and a link to a dockerfile can be
found here: https://github.com/NASA-SW-VnV/ikos/discussions/241.

While I can hack a solution that "works" (either by making a venv under the
target dir or by means of break-system-packages), I'd prefer to use
recommended practices, and also conform to the way that things are done in
Debian/Ubuntu.

What would be the recommended way of installing IKOS system-wide in Debian?


Hello again Ivan (different neighborhood :)),

The "modern" way of building Python libraries/applications seems to be to 
use a pyproject.toml.  The pyproject.toml specifies a backend build system 
that knows how to build the library/application and produce a wheel.


As far as how to do this within an existing cmake project, unfortunately, 
there doesn't seem to be a clear/easy way.  The only cmake example I can 
think off of the top of my head is cvc5.  It still uses setup.py though, 
so not a great future-looking example (and I had to patch it to build the 
Python bindings in Debian): 
https://github.com/cvc5/cvc5/blob/main/src/api/python/CMakeLists.txt


If you're open to other options for building python libraries, meson might 
be something to look into.  I haven't used it extensively, though.  It 
does seem to have better support for building Python though.


Regards,
Scott

Re: python-miio: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Scott Talbert]

On Sat, 27 Jan 2024, Andreas Tille wrote:


Control: tags -1 help

Hi,

I upgraded python-miio in Git.  Unfortunately there are some test suite 
errors[1]
Any help would be welcome
Andreas.


Fixed.

Re: python-plaster: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Scott Talbert]

On Sun, 28 Jan 2024, Andreas Tille wrote:


Hi,

I upgraded python-plaster to latest upstream - but this did not changed
the test suite error.


I suspect the issue is because dh-python is clobbering the *.egg-info 
directories in the tests directory during the 'clean' target.


While this is helpful in a lot of cases, it would be nice if there was a 
way to opt out of this behavior.


Scott

Re: Suggesting change in DPT policy

[Scott Talbert]

On Tue, 27 Feb 2024, Thomas Goirand wrote:


On 2/27/24 09:05, Andreas Tille wrote:

Hi,

I became more deeply involved into DPT since 2022 as a consequence of
the suggestion for transfering several Debian Med/Science packages to
DPMT[1][2].  I happily followed this suggestion and moved >30 packages
from the Blends teams to DPT.  I was happy with this move since it makes
sense.

Recently we received lots of testing removal warnings in those Blends
teams due to RC bugs caused by Cython 3.0 and Python3.12 migrations.  So
I did what I usually do in those teams:  I dedicated quite some time in
team wide bug hunting.  That way I squashed about 50 bugs on packages
where I was not in Uploaders.  When doing so I usually run
routine-update on the package which basically streamlines packaging to
latest standards including calling Janitor tools which are so far
accepted inside DPT.

I probably should have reviewed the DPT policy on Maintainership[3] more
carefully. In other teams, it's common for the Maintainer to be set to
the team, so I assumed it was just an oversight when I made this
change[4] when touching the package to fix RC bug #1058177.  However, I
I was pointed immediately about the fact that I was mistaken according
to the current DPT policy.  I apologize for this.  However, the wording
of the comment on my commit was discouraging, especially considering I
was a volunteer who had fixed a critical bug.  Because of this, I
decided to focus my efforts on fixing other critical bugs for the
moment.  If the comment had started with a 'Thanks for fixing the
critical bug, but...' I likely would have corrected my mistake quickly.
The lack of respect from my teammate simply made me prioritize my time
on other issues that are more visible to our users.  I wonder whether I
should propose another change to the policy about maintaining a kind and
polite language inside the team - but that's a different thing.

While I applied the patch for another RC bug (#1063443) after >2 weeks
which triggered a RC bug in reportbug I remembered the "keep the
maintainer" policy.  But I kept on doing Janitor like changes since
finally the package is maintained in a team where Janitor is accepted.
When doing so I failed the phrase "please contact the Maintainer for the
green light."  I apoligize for this again.  The response was another
volunteer-demotivating private mail (thus no quote) which also was
lacking the "Thanks for fixing"-phrase and degrading my changes as
"frivolous".

So far what happened (seen from my possibly biased perspective).

Why do I like to change the policy?

The current wording provides some means to stop volunteer team members
helping out moving forward to speed up migrations and fix Debian wide
dependencies.  It hides team maintained packages from a common BTS
view.  When pointing my browser to
 https://bugs.debian.org/team+pyt...@tracker.debian.org
I currently see 1339 open bugs (calculated by [UDD1]).  This hides
another 309 [UDD2] bugs (>18% of team bugs) from our sight.  To work
around this flaw I used an UDD query to find relevant Python3.12 bugs.

When I think twice about the wording
Team in Uploaders is a weak statement of collaboration.[3]
I personally consider it a statement of *no* collaboration (which fits
the wording of the responses I've got).

How can a team member for instance find another RC bug #1009424?  Just
from reading the bug report it is pretty easy to fix but does not
feature any response in BTS.  I came across this while looking into
Cython 3.0 bugs.  The same source package (basemap) that had the open
Cython bug (#1056789, tagged patch since 2023-12-09) is featuring RC bug
(#1009424) that stayed unattended for 22 months?  We all know volunteers
have limited time and I do not want to blame anybody in the team to not
care promptly about RC bugs.  But what else is the sense of a packaging
team than stepping in situations for long standing RC bugs and RC bugs
tagged patch?

This kind of situation wouldn't occur in teams where collaboration is
strong and communication is effective. My motivation to address these
long-ignored critical bugs diminishes when the maintainer opts for
"weak" cooperation and lacks respectful communication with potential
helpers.  I see no difference to simply do a NMU.

I've checked the current situation who is actually using the DPT team as
Uploaders[UDD3].  66 of the 73 maintainers have less than 5 packages
some of these "Maintainers" are other teams and lots of the persons
listed as Maintainer are known to be MIA.  This means the packages are
de-facto not maintained which is most probably an unwanted effect of the
current policy.  I know other maintainers from other teams to be fine
with stronger team understanding.

Since I consider the current situation as demotivating for newcomers
as well as long standing contributors I would like to suggest to drop
this "weak statement of collaboration" option from policy.  I've attached
an according patch to the