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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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