Re: RFS: colorzero/2.0-1 [ITP] -- Construct, convert, and manipulate colors in a Pythonic manner.

[Peter Green]

Just done some reviewing/tweaking. I've pushed the following changes to the git 
repo, please
tell me if you have any objections.

I added a gpb.conf to make git-buildpackage actually use pristine tar and hence 
result in an orig
tarball that was consistent with what is already in Ubuntu.

I found the clean target was not cleaning up the "egg-info" so I added a 
command to do that.

I added a closes: entry for the ITP bug.

---

That leaves one issue that I think still needs to be sorted before I sponsor 
the package.

The file "copyrights" has no license header and the git history says it was 
copied but not where
from. Poking around I discovered a script of the same name in gpiozero, 
containing what appears
to be the same code and committed by you with a commit message of "create copyright 
header", so
I presume this script is entirely your work, assuming it is I would suggest 
adding a copyright
header upstream and then picking the commit up as a Debian patch until there is 
another upstream
release.

Finally would you consider adding me as a co-maintainer.

Is it time to remove python-numpy from testing?

[peter green]

python-numpy* is no longer buildable in testing due to the removal of the 
"cython" binary package.
The maintainer has requested removal of python-numpy from unstable but the 
ftpmasters have not yet
actioned it, presumably because there are still reverse-dependencies in 
unstable. A rc bug is
present but will not cause autoremoval because python-numpy is on the "key 
packages" list.

All of the reverse dependencies of python-numpy have already been removed from 
testing. So IMO
it makes sense to remove python-numpy from testing at this point, do other 
people agree?

* Note: since buster the python-numpy source package only builds python 2 
related binary packages,
the python3 numpy binary packages are now built from the numpy source package.

joining the DPMT.

[peter green]

I would like to join the DPMT, there are a couple of reasons for this.

Firstly I have been making an effort to try and get broken build-dependencies 
in testing fixed, and this often ends up involving python module packages. It 
would be easier to fix such packages as a member of the team than working 
through patches and NMUs as I have done so far.

Secondly I maintain a couple of python modules, which it may make sense to 
bring into team maintainership, though I would have to figure out how to 
restructure the git repositories to fit the dpmt policy.

I have read and accept the DPMT policy at 
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst

my salsa username is plugwash

Re: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).

[peter green]

On 21/04/2020 22:20, Thomas Goirand wrote:

So, if I'm following correctly, what you seem to propose, is to remove
Python 2 from unittest2. If that's the case, then I agree with such a
plan. I just didn't dare to do it yet.

Yes, whichever approach is taken to dealing with funcsigs, unittest2 will need 
to drop it's python2 packages.

Though in fact, I already worked on that, but stopped, also because
unittest2 FTBFS when I try building it on my laptop. So I've pushed it
in its normal Git repo [1] under a py2-removal branch. If anyone has
some time available to look at it, that'd be nice (I currently don't...).

It appears that this was fixed in a NMU, but the NMU changes were never 
imported into the packaging repository, once I imported the NMU changes the 
package built fine here.

Re: samba: FTBFS glibc/stropts/python issue.

[peter green]

If my understanding is correct I see two possible ways forward.

1. Rebuild python3.8 against the new glibc.
2. Remove the stropts include from samba, it doesn't seem to actually be used 
for anything (at least I can't find any other references to HAVE_STROPTS_H in 
the code).

I am currently testing a build in raspbian bullseye with the second approach. I 
will report back later on whether it results in a succesful build.


This build was successful and I uploaded it to raspbian, a debdiff should 
appear soon at https://debdiffs.raspbian.org/main/s/samba . No intent to NMU in 
Debian.

re: samba: FTBFS glibc/stropts/python issue.

[peter green]

The samba FTBFS is blocking the python 3.8 transition in raspbian bullseye, so 
I decided to take a look.


error: Unable to determine origin of type `struct cli_credentials'

I don't think this is the error that is causing the build failure. The same error can be seen 
in succesful build logs. e.g. 
https://buildd.debian.org/status/fetch.php?pkg=samba=amd64=2%3A4.11.5%2Bdfsg-1%2Bb1=1583775414=0

Instead I think the real error is further down the log

../../lib/replace/system/network.h:91:10: fatal error: stropts.h: No such file 
or directory

Some googling lead me to https://bugs.gentoo.org/699668 and 
https://bugzilla.samba.org/show_bug.cgi?id=14100 which suggests that the bug 
triggers if samba is built against a newer glibc while python was built against 
an older glibc. Specifically it seems python headers leak certain system 
feature defines including HAVE_STROPTS_H which cause network.h to think 
stropts.h is available when it isn't.

If my understanding is correct I see two possible ways forward.

1. Rebuild python3.8 against the new glibc.
2. Remove the stropts include from samba, it doesn't seem to actually be used 
for anything (at least I can't find any other references to HAVE_STROPTS_H in 
the code).

I am currently testing a build in raspbian bullseye with the second approach. I 
will report back later on whether it results in a succesful build.

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

[peter green]

Relevant packages and bugs:
  943107 git-buildpackage: Python2 removal in sid/bullseye

This bug is not marked as rc.

Nevertheless I believe that this bug report is in-fact a false positive. From 
what I can tell git-buildpackage, even in buster, does not (build-)depend on 
python 2 or any python 2 modules.

It does build-depend on python-pydoctor, but according to a recently entry in the 
pydoctor changelog that package "is a Python application and not used as a 
module"

It would make sense to change the build-dependency to pydoctor in the next 
upload, but it's probablly not worth making an upload just for that change.

  937132 nevow: Python2 removal in sid/bullseye

Depended on by pydoctor in testing, but not in unstable. Should stop being a 
problem for git-buildpackage when pydoctor migrates.

  938622 tahoe-lafs: Python2 removal in sid/bullseye

Listed as a "blocker" of the above bug but not currently in testing. Personally I 
advocate ignoring "blockers" that are not in testing, but I'm not sure if consensus has 
been reached on that.


Bugs which you may notice which are now not so relevant any more
because they have been fixed in sid (but not yet migrated):
  950216 [git-buildpackage] missing xsltproc autopkg test dependency
Fixed in sid; migration blocked by FTBFS due to pydoctor
breakage (#949232).  When pydoctor has migrated, reattempting
build (eg by re-upload) should fix this.

Builds happen in unstable, so there is no need to wait for pydoctor to migrate 
to testing before retrying the build. I just requested a retry and the package 
built succesfully. I'd expect it to migrate as soon as dak and britney process 
the binary.

  949232/948831 [pydoctor] needs to depend on cachecontrol
  952546 [pydoctor] d/copyright & DFSG issues
  937421 [pydoctor] Python2 removal in sid/bullseye

Should hopefully be fixed in a few days when pydoctor migrates to testing, i'm 
not seeing any obvious blockers for that right now.

Re: looking at the remaining "bad" packages in the "add python 3.8" transition

[peter green]

There's another kind of issue

Yeah, sadly the transition tracker only looks at unstable, so packages that are 
fixed in unstable but haven't migrated to testing for some reason won't show up.

; here is an example :

- sagemath builds only for Python 3.7, so some of this subpackages
don't load under Python 3.8 :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949023

- which means that for brial, autopkgtest fails :
https://ci.debian.net/data/autopkgtest/testing/amd64/b/brial/3988637/log.gz


Looking at brial, it seems python3-brial should technically have a dependency 
on sagemath, but this dependency is omitted for bootstrapping reasons 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896218 .


I haven't found the time to investigate things further in sagemath ; I
was wondering if I wouldn't disable the Python 3.8 test in brial... not
ideal...

I would think the autopkgtest should probably check somehow what versions of 
python3 sagemath supports and test against those, rather than having a 
hardcoded whitelist/blacklist.


Afaict until sagemath makes it back into testing ( currently blocked by 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944055 ), having a brial 
package in testing is pretty pointless.

looking at the remaining "bad" packages in the "add python 3.8" transition

[peter green]

I just took a look at the "add python3.8 transition tracker", and split the remaining 
"bad" packages into categories.

Key package, rc bug with patch.
* gpgme1.0 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944774

Not key package, but not marked for autoremoval from testing
* macs version in unstable FTBFS on most architectures, version in testing 
seems to build fine
  with 3.8 according to reproducible builds, but afaict binnmus are not 
currently possible in testing

Builds only against default python3 version
* libcap-ng https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943627
* fontforge https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948016
* pcp can't find a bug report for this one.
* getfem++ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948016
* uhd https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943636
* stimfit https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948020

Marked for autoremoval from testing
* subvertpy https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942678
* beancount https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943608
* python-thinc https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947111

Not in testing (and not mentioned already)
* libyang build timesouts on mipsel/mips64el , probablly heavy swap use
* python-tesserocr https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943501
* pyfai https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945411
* veusz https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945467

Re: Dealing with zope.interface unsatisfiable build-dependency.

[peter green]

On 07/12/2019 15:09, Håvard Flaget Aasen wrote:

If you still wish to disable tests for python 2, you might be looking for this

export PYBUILD_DISABLE_python2=test

That line in debian/rules should work.

You have some more options here: https://wiki.debian.org/Python/Pybuild
and perhaps the manpages. 

Thanks, I found I also had to add export PYBUILD_DISABLE_python2-dbg=test to 
disable the tests for the python2 debug interpreter. Looking at the log 
confirms it's running the tests for python 3.x and not python 2.x as desired.

New debdiff is attached.
diff -Nru zope.interface-4.6.0/debian/changelog 
zope.interface-4.6.0/debian/changelog
--- zope.interface-4.6.0/debian/changelog   2019-09-05 11:09:40.0 
+
+++ zope.interface-4.6.0/debian/changelog   2019-12-07 07:00:43.0 
+
@@ -1,3 +1,13 @@
+zope.interface (4.6.0-2) unstable; urgency=medium
+
+  * QA upload.
+  * Drop build-dependency on nonexistent python-zope.event. Downgrades: 
#938909.
+  * Disable testsuite for python 2, it needs python-zope.event.
+(keep testsuite enabled for python 3)
+  * Fix clean target.
+
+ -- Peter Michael Green   Sat, 07 Dec 2019 07:00:43 +
+
 zope.interface (4.6.0-1) unstable; urgency=medium
 
   * QA upload.
diff -Nru zope.interface-4.6.0/debian/control 
zope.interface-4.6.0/debian/control
--- zope.interface-4.6.0/debian/control 2019-09-05 11:09:40.0 +
+++ zope.interface-4.6.0/debian/control 2019-12-07 07:00:43.0 +
@@ -12,7 +12,6 @@
python-all-dbg:any,
python-all-dev:any,
python-setuptools,
-   python-zope.event,
python3-all-dbg:any,
python3-all-dev:any,
python3-setuptools,
diff -Nru zope.interface-4.6.0/debian/rules zope.interface-4.6.0/debian/rules
--- zope.interface-4.6.0/debian/rules   2016-07-05 21:43:11.0 +
+++ zope.interface-4.6.0/debian/rules   2019-12-07 07:00:43.0 +
@@ -3,6 +3,8 @@
 export PYBUILD_NAME=zope.interface
 #export PYBUILD_VERBOSE=1
 #export DH_VERBOSE=1
+export PYBUILD_DISABLE_python2=test
+export PYBUILD_DISABLE_python2-dbg=test
 
 %:
dh $@ --with python2,python3 --buildsystem=pybuild
@@ -97,3 +99,9 @@
 override_dh_strip:
dh_strip -p$(package) --dbg-package=$(package)-dbg
dh_strip -p$(package3) --dbg-package=$(package3)-dbg
+
+override_dh_auto_clean:
+   dh_auto_clean
+   rm -f .eggs/README.txt
+   rm -f src/zope.interface.egg-info/requires.txt
+   rm -f src/zope/interface/_zope_interface_coptimizations.*.so

Re: Dealing with zope.interface unsatisfiable build-dependency.

[peter green]

On 07/12/2019 07:47, peter green wrote:

It would be preferable to only disable the testsuite for python2, but I have no 
idea how to do that, so my current debdiff disables the testsuite completely, I 
also ran into an issue with the package's clean target not cleaning up properly.

Just realized I added moreutils to the build-depends, planning to use it in the 
clean target fix, but in the end I decided to just delete the file in question. 
So that build-dep should be dropped before upload.

Dealing with zope.interface unsatisfiable build-dependency.

[peter green]

zope.interface is currently rc buggy because of an unsatisfiable 
build-depenency on python-zope.event, the package is also orphaned.

The package is a key package, so the issue won't be dealt with by autoremovals, 
furthermore the python-zope.interface package has quite a stack of reverse 
dependencies, so dropping it doesn't seem like a good option at this point.

Testing reveals that the build-dependency in question is only needed by the 
test suite, so I believe the least-bad option is to drop the build-dependency 
and not run the testsuite.

It would be preferable to only disable the testsuite for python2, but I have no 
idea how to do that, so my current debdiff disables the testsuite completely, I 
also ran into an issue with the package's clean target not cleaning up properly.

If anyone can suggest how to modify the package so it runs the testsuite for 
python3 but not python2 that would be appreciated. I plan to go ahead with an 
upload next week.

diff -Nru zope.interface-4.6.0/debian/changelog 
zope.interface-4.6.0/debian/changelog
--- zope.interface-4.6.0/debian/changelog   2019-09-05 11:09:40.0 
+
+++ zope.interface-4.6.0/debian/changelog   2019-12-07 07:00:43.0 
+
@@ -1,3 +1,13 @@
+zope.interface (4.6.0-2) unstable; urgency=medium
+
+  * QA upload.
+  * Drop build-dependency on nonexistent python-zope.event. Downgrades: 
#938909.
+  * Disable testsuite, it needs python-zope.event.
+  * Fix clean target.
+  * Add build-depends on moreutils, needed by fixed clean target.
+
+ -- Peter Michael Green   Sat, 07 Dec 2019 07:00:43 +
+
 zope.interface (4.6.0-1) unstable; urgency=medium
 
   * QA upload.
diff -Nru zope.interface-4.6.0/debian/control 
zope.interface-4.6.0/debian/control
--- zope.interface-4.6.0/debian/control 2019-09-05 11:09:40.0 +
+++ zope.interface-4.6.0/debian/control 2019-12-07 07:00:43.0 +
@@ -12,11 +12,11 @@
python-all-dbg:any,
python-all-dev:any,
python-setuptools,
-   python-zope.event,
python3-all-dbg:any,
python3-all-dev:any,
python3-setuptools,
-   python3-zope.event
+   python3-zope.event,
+   moreutils
 Standards-Version: 4.4.0
 Testsuite: autopkgtest
 Homepage: http://pypi.python.org/pypi/zope.interface
diff -Nru zope.interface-4.6.0/debian/rules zope.interface-4.6.0/debian/rules
--- zope.interface-4.6.0/debian/rules   2016-07-05 21:43:11.0 +
+++ zope.interface-4.6.0/debian/rules   2019-12-07 07:00:43.0 +
@@ -97,3 +97,10 @@
 override_dh_strip:
dh_strip -p$(package) --dbg-package=$(package)-dbg
dh_strip -p$(package3) --dbg-package=$(package3)-dbg
+
+override_dh_auto_test:
+   echo testsuite disabled
+
+override_dh_auto_clean:
+   rm -f .eggs/README.txt
+   rm -f src/zope.interface.egg-info/requires.txt

Bug#945775: python-sponge: should this package be removed.

[peter green]

Package: python-sponge
Severity: serious
x-debbugs-cc: debian-python@lists.debian.org

While looking at some python2 removal issues, I came across python sponge. I 
noticed the following about the package.

* Python 2 only.
* Only one maintainer upload (and one NMU) ever.
* Not in stable or testing
* RC buggy for nearly two years with no maintainer response.
* Upstream seems inactive (no commits since 2010, no releases since the one 
that was packaged for Debian in 2009)
* No rdeps.

To me this adds up to a package that is not in a fit state to remain in Debian, 
if noone disagrees I will likely convert this bug to a removal request in the 
not too distant future.

reducing matplotlib2 build-depends.

[peter green]

matplotlib2 seems to be an important node in the python2 removal/reduction 
problem (and the qt4 removal problem). I have noticed there are a substantial 
number of python module packages that it build-depends on but does not depend 
on.

python-backports.functools-lru-cache
python-cairocffi
python-colorspacious
python-cycler
python-functools32
python-gi
python-ipywidgets
python-kiwisolver
python-mock
python-nose
python-numpy
python-numpy-dbg
python-numpydoc
python-pandas
python-pil
python-pkg-resources
python-pyqt5
python-pytest
python-qt4
python-scipy
python-setuptools
python-six
python-sphinx
python-sphinx-gallery
python-subprocess32
python-tk
python-tk-dbg
python-tornado
python-wxgtk3.0
python-xlwt

There is also the slightly-strange case of kiwisolver where there is no binary 
dependency on python-kiwisolver but there is one on python-kiwisolver-dbg.

Some of these dependencies are starting to cause problems. For example

ipywidgets needs to drop it's python2 packages because jupyter-notebook has 
already done so, but it can't because of the build-dependency from matplotlib2

the qt developers want to get rid of qt4, but can't because of the 
build-dependency from matplotlib2.

the pandas maintainers have packaged a new python3 only version, which leaves 
matplotlib2 build-depending on a cruft package.

I am guessing that many of these are to get testsuite coverage for optional 
features and are not strictly needed for the build, while testing stuff is nice 
I don't think it's vital for software that is on it's way out. I tried removing 
all of the aforementioned packages except python-setuptools and 
python-kiwisolver from the build-depends (and I uninstalled all python 2 
packages from the chroot where I was doing my test builds before I installed 
the remaining build-depends).

I had to add the following packages back in to get a succesful build.

python-numpy
python-numpy-dbg
python-sphinx (needed for documentation build)
python-backports.functools-lru-cache (needed for documentation build)
python-cycler (needed for documentation build)
python-numpydoc (needed for documentation build)
python-sphinx-gallery (needed for documentation build)
python-colorspacious (needed for documentation build)
python-mock (needed for documentation build)

I also had to add a build-dependency on python-ipkernel which is needed by the 
documentation build and was previously pulled in indirectly.

That left the following list of changes to build-dependencies.

-   python-cairocffi [!ia64],
-   python-functools32,
-   python-gi,
-   python-ipywidgets,
+   python-ipykernel,
-   python-nose,
-   python-pandas [!hppa !m68k !powerpcspe !sparc64 !sh4 !x32],
-   python-pil,
-   python-pkg-resources,
-   python-pytest,
-   python-qt4,
-   python-pyqt5 [!hurd-i386],
-   python-scipy,
-   python-six (>= 1.4),
-   python-subprocess32,
-   python-tk (>= 2.5.2-1.1),
-   python-tk-dbg (>= 2.5.2-1.1),
-   python-tornado,
-   python-wxgtk3.0,
-   python-xlwt,

Unfortunately the matplotlib2 build is not reproducible, so while I was able to 
determine there were no significant changes to file lists (there were some id 
changes to id's in the documenation) I was not able to reasonably check for 
changes to file content.

What do others with more experience think? Should these build-dependencies be 
removed?

While working on this I also ran into an issue with the clean target not 
cleaning up properly which I fixed as it was getting in the way of my testing.

debdiff is attached.

diff -Nru matplotlib2-2.2.4/debian/changelog matplotlib2-2.2.4/debian/changelog
--- matplotlib2-2.2.4/debian/changelog  2019-09-17 03:44:50.0 +
+++ matplotlib2-2.2.4/debian/changelog  2019-11-12 10:59:29.0 +
@@ -1,3 +1,13 @@
+matplotlib2 (2.2.4-2.1) UNRELEASED; urgency=medium
+
+  * experimental local build
+  * reduce build-dependencies to (mostly) match binary ones.
+  * add build-depends on python-ipykernel, the documentation build
+needs it (previously it was pulled in indirectly)
+  * fix clean target.
+
+ -- Peter Michael Green   Tue, 12 Nov 2019 10:59:29 +
+
 matplotlib2 (2.2.4-2) unstable; urgency=medium
 
   * debian/control
diff -Nru matplotlib2-2.2.4/debian/control matplotlib2-2.2.4/debian/control
--- matplotlib2-2.2.4/debian/control2019-09-17 03:44:50.0 +
+++ matplotlib2-2.2.4/debian/control2019-11-12 10:59:29.0 +
@@ -19,36 +19,18 @@
python-cycler (>= 0.10.0),
python-dateutil,
python-colorspacious,
-   python-cairocffi [!ia64],
-   python-functools32,
-   python-gi,
-   python-ipywidgets,
+   python-ipykernel,

pylint3 reverse dependencies.

[peter green]

pylint3 is now a cruft package, however it still has a fair few reverse 
dependencies, from
https://ftp-master.debian.org/users/dktrkranz/NBS

* source package pylint version 2.2.2-4 no longer builds
   binary package(s): pylint3
   on all
   - suggested command:
 dak rm -m "[auto-cruft] NBS (no longer built by pylint)" -s unstable -a 
all -p -R -b pylint3
   - broken Depends:
 prospector: prospector
 pylint-celery: python3-pylint-celery
 pylint-common: python3-pylint-common
 pylint-django: python3-pylint-django
 pylint-plugin-utils: python3-pylint-plugin-utils
 pytest-pylint: python3-pytest-pylint
 salt-pylint: python3-saltpylint
 thonny: thonny
   - broken Build-Depends:
 backblaze-b2: pylint3 (>= 1.4.5)
 custodia: pylint3
 devscripts: pylint3
 duplicity: pylint3
 gnome-keysign: pylint3
 ionit: pylint3
 knack: pylint3
 pathspider: pylint3
 prospector: pylint3 (>= 1.5.6)
 pylint-celery: pylint3
 pylint-common: pylint3
 pylint-django: pylint3 (>= 2.0)
 pylint-flask: pylint3
 pytest-pylint: pylint3
 python-stetl: pylint3
 python-trio: pylint3
 python-ttystatus: pylint3
 ranger: pylint3
 salt-pylint: pylint3
 thonny: pylint3
 uranium: pylint3
 vmdb2: pylint3


Are there plans to deal with this centrally or should bugs be filed against all 
the reverse dependencies.

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

[peter green]

> tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave)))

Thanks to this hint

This hint was *wrong*, it will introduce garbage into the string and the 
"rotor" code is clearly designed to work with byte strings, not unicode strings.

Change it to

"tmp=rt.encrypt( b'Cycle'+pickle.dumps(objSave) )"

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

[peter green]

but this leads later to

Traceback (most recent call last):
   File "cycle.py", line 83, in OnCloseWindow
 Save_Cycle(cycle.name, cycle.passwd, cycle.file)
   File "/home/andreas/debian-maintain/salsa/med-team/cycle/save_load.py", line 
46, in Save_Cycle
 tmp=rt.encrypt( 'Cycle'+pickle.dumps(objSave) )
TypeError: can only concatenate str (not "bytes") to str

String handling changed significantly between python2 and python3. Python 2 is "byte strings by 
default", type "str" was used for byte strings and type "unicode" was used for 
unicode strings. Implicit conversions between the two were allowed.

Python 3 is "unicode by default", type "bytes" is used for byte strings and type 
"str" is used for unicode strings. There is no implict conversion between unicode strings and byte 
strings.

"pickle.dumps" returned a bytes object, and you tried to concatenate it to a 
str object. You need to change 'Cycle' to b'Cycle'.

Also python 3 bytes objects behave a bit differently from python 2 str objects. 
To accommodate this I believe you need the following changes in p_rotor.py

"|for c in map(ord, buf):|" -> "|for c in buf:|"
"|return ''.join(map(chr, outbuf))|" -> "|return bytes(outbuf)|"
"|for c in map(ord, key):|" -> "for c in key:"

Re: Investigating the reverse dependencies of python-monotonic.

[peter green]

(note for people reading on bug 934333, the start of this thread can be found 
at https://lists.debian.org/debian-python/2019/08/msg00070.html )

On 13/08/2019 11:54, Andrey Rahmatullin wrote:

This is worrying, a package with revdeps shouldn't have been dropped.


AIUI a "go cleanly" approach was agreed at the Python BoF, but by that time an 
aggressive removal process was already well underway for django and openstack related 
packages.


By the way, you checked only deps, not build-deps, as at least
python-coloredlogs and python-datalad has reverse build-deps.


I took a look at the build-rdeps, also this time I used unstable whereas my 
previous analysis had been looking at buster (yeah, this made little sense, I 
was probablly meaning to use bullseye but mixed the words up in my head, not 
that I think it made any difference). Again i'm not investigating openstack 
related stuff. This seems to add a few more packages to our set

python-jira (via python-tenacity)
cyvcf2 (via python-coloredlogs, sid version has dropped the python2 stuff, but 
it's blocked from having old versions cleaned up and migrating to testing by 
build failures on mips*)
heudiconv (via python-datalad, sid only, never been in testing or a stable 
release, WTF was someone doing uploading a new python2 only package in 2019?!)
python-googlecloudapis (via python-oauth2client, sid only)
python-google-auth(via python-oauth2client, sid only)
rekall(via python-oauth2client)
python-oslo.cache (via python-etcd3gw, openstack related)
elastalert (via python-jira, also depends on python-croniter)


I've also noted https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934333

ccing this mail there.


As for duplicity, the latest upstream version (not packaged) support
Python 3.

There is a bug report for it, 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929949

In a response to bug 934333 Ondrej Novy wrote:

just my two cents: correct solution is to add Python 3.x support to
python-m2crypto and migrate oz to Python 3.

I agree that is the correct long term soloution, however as mentioned in this 
mail and in https://lists.debian.org/debian-python/2019/08/msg00070.html it's 
not just oz that is involved here.

Reintroduction Python2 support to python-monotonic is not good idea, we are
going to drop Python 2 completly from Debian.

I understand that dropping python 2 is the goal, but my understanding of 
https://lists.debian.org/debian-python/2019/07/msg00069.html and 
https://lists.debian.org/debian-python/2019/07/msg00080.html is the plan was to 
do it cleanly, starting with leaf stuff and working down the dependency stack.

IMO python-monotonic should be reinstated until it's reverse dependencies are 
sorted out.

Investigating the reverse dependencies of python-monotonic.

[peter green]

Hi

I've been looking at various python 2 cruft packages (packages no longer built 
by the corresponding source packages) and why they can't be cleaned up, I have 
been looking in a derivative but many of my results are also relevant to debian 
proper. Where relevant I have been filing bugs against the reverse-dependencies 
of these cruft packages, so they can be fixed or ultimately removed.

Most such packages have been part of upstream projects that have dropped python 
2 support, notablly django and openstack. In such cases it is pretty clear that 
the only reasonable way forward is for the reverse dependencies to be either 
removed or migrated to python 3.

One package that stood out from the rest was python-monotonic. python-monotonic 
is maintained by the Debian openstack team, but it doesn't seem to be in any 
way openstack specific, nor does upstream seem to have dropped python2 support. 
It seemed to have a fair few reverse dependencies.

python-humanfriendly (has rdeps)
oz (rc bug filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933509 )
python-fasteners (has rdeps)
python-futurist (has rdeps, cruft)
python-octaviaclient (assumed to be openstack related)
python-oslo.log (assumed to be openstack related)
python-oslo.messaging (assumed to be openstack related)
python-oslo.service (assumed to be openstack related)
python-oslo.utils (assumed to be openstack related)
python-tenacity (has rdeps, cruft)

There are also indirect reverse dependencies, (i'm not investigating reverse 
dependencies of packages that are clearly openstack specific here)

python-coloredlogs (via python-humanfriendly, no reverse dependencies)
python-datalad (via python-fasteners, no reverse dependencies)
duplicity (via python-fasteners)
python-oauth2client (via python-fasteners)
python-oslo.concurrency (via python-fastners, openstack related)
python-taskflow (via python-fasteners, cruft)
python-tooz (via python-fasteners, openstack related, cruft)
python-googleapi (via python-oauth2client)
python-pypowervm (via python-taskflow, openstack related, cruft)
python-googleapi-samples (via python-googleapi)
python-etcd3gw (no rdeps)
python-gnocchiclient (openstack related, cruft)

If we ignore openstack stuff, python modules and an examples package the two 
main packages left seem to be oz and duplicity, oz seems to have very low 
popcon, but duplicity seems to have a popcon of around 3000 and growing.

So the main question seems to be can duplicity be reasonably migrated to python 
3 and if not is it worth reinstating the python-monotonic binary package to 
save duplicity?

Re: Python 3.7 or 3.6 in Buster

[Peter Green]

> No one in Debian (or Ubuntu) reported it.

That is hardly surprising, most Debian/Ubuntu users will be using the default 
python3 version.

IMO (I am just a random dd) if Debian is going to switch the default python 
version for buster it should be done ASAP to maximize the amount of testing 
with the new python version before release.

Future of pygame in Debian.

[peter green]

pygame in Debian testing is currently python2 only, I am sure I am not alone in 
thinking this is not a good state of affairs given that pygame is frequently 
used for introducing people to programming.

pygame in sid has python3 support but is held back from migrating to testing by 
three rc bugs. None of which have had any response from the maintainer.

One of those is a FTBFS with python 3.7 which is apparently fixed upstream. So 
presumably the best thing to do about this one would be to update the package 
to the new upstream. I may have a go at this myself but I'm not an expert in 
python packaging so I don't know how well I will do.

The other two are testsuite failures on architectures where frankly I doubt 
pygame has many users*. I may also take a look at these after the new upstream 
version is dealt with but I don't think it's worth putting huge amounts of 
effort into pygame on architectures where I doubt it has any users and I 
equally don't think it should be allowed to block the availability of 
python3-pygame in testing on architectures people do actually care about, so if 
the root cause cannot be found quickly I would propose either disabling the 
tests on these architectures or requesting the ftpmasters remove the binaries.

Anyone have any comments or suggestions?

*Both are very expensive architectures driven by IBM.

python-gevent, python-greenlet, debug packages, hurd, and testing.

[peter green]

(sorry if this is long winded, but I feel the need to explain the situation 
so-far, the important bit of this mail is the last few paragraphs)

python-gevent cannot currently be built in testing because it has a build-dependency on 
python-greenlet (>= 0.4.13) but testing only has 0.4.12-2. This is technically a RC bug 
(violates "Packages must be buildable within the same release." but AIUI in such 
cases it is generally considered more productive to investigate why there is a delta between 
testing and unstable than file a bug against the victim of the delta.

After digging into the britney update output it seems that the new 
python-gevent is not migrating to testing because the python-greenlet no longer 
builds -dbg packages but the old -dbg packages are still in unstable.


trying: python-greenlet
skipped: python-greenlet (3538, 0, 13)
 got: 29+0: a-4:i-24:a-0:a-0:a-0:m-0:m-0:m-0:p-0:s-1
 * amd64: python-greenlet-dbg, python3-greenlet-dbg

The old debug packages are still in unstable because python-gevent failed to 
build on hurd (and for some reason hurd is still on ftp-master).


* source package python-greenlet version 0.4.13-2 no longer builds
   binary package(s): python-greenlet-dbg python3-greenlet-dbg
   on 
amd64,arm64,armel,armhf,hurd-i386,i386,kfreebsd-amd64,kfreebsd-i386,mips,mips64el,mipsel,ppc64el,s390x
   - suggested command:
 dak rm -m "[auto-cruft] NBS (no longer built by python-greenlet)" -s 
unstable -a 
amd64,arm64,armel,armhf,hurd-i386,i386,kfreebsd-amd64,kfreebsd-i386,mips,mips64el,mipsel,ppc64el,s390x
 -p -R -b python-greenlet-dbg python3-greenlet-dbg
   - broken Depends:
 python-gevent: python-gevent-dbg [hurd-i386]
python3-gevent-dbg [hurd-i386]

Following the general principle that issues affecting release architectures in testing 
(python-gevent being unbuildable in testing) are more important than issues that only 
affect non-release architectures in unstable (some uninstallable -dbg packages on hurd) I 
filed a removal request asking for the old -dbg packages to be removed so that 
python-greenlet could migrate to testing. I cc'd the removal request to the 
"python-green...@packages.debian.org" maintainer alias in case the maintainer 
had any concerns.

A couple of hours after I filed the removal request Laszlo uploaded a new 
version of python-gevent which fixed the hurd FTBFS. I have no idea if these 
two events were related.

Anyway Scott Kitterman (a ftp assistant) replied to my removal request with the 
following.


It appears these are not being removed automatically because they are
depended on by out of date binaries on hurd. Can you clean them up
manually?

This is certainly possible, but is deleting the -dbg packages really the best 
solution?
For python debug packages to work, they need to run with the debug version of 
the python
interpreter, which -dbgsym packages make no provision for.

Generally, for python packages, it's desirable to keep the traditional -dbg 
packages.


I am far from a python expert, I am just a random dd pushing on an issue that I 
noticed as
a result of running a downstream distribution.

So I am passing Scott's comment on to the package maintainer and to Debian's 
python
experts so that hopefully a descision can be taken to either tell the 
ftpmasters to
go ahead with the removal of the old dbg packages or to reintroduce the -dbg 
packages
to the  python-gevent and python-greenlet source packages.

More generally I find it surprising that given that python apparently has 
special
requirements regarding dbg packages this does not seem to be addressed in the 
python
policy.

python logo.

[Peter Green]

I am looking into cleaning up some software so it can be uploaded to Debian. 
Inside the documentation folder is a copy of the python logo. I found the 
python.org page for the logo more confusing than helpful.

1. Is the python logo under a license acceptable for including in a Debian 
package? or does it need to be stripped out?
2. If it is acceptable for inclusion how should it be documented in 
debian/copyright?

Re: Next python-mote pre-condition - issue with pybuild: python-backports.tempfile conflicting python-backports.weakref

[peter green]

> However, in Debian case, I do not know how this can be handled as 2 packages 
cannot hold the same file (even if __init__ is only an empty file), and at least 
one must be present (if you install only one).

I'm not a python expert but I expect the least-horrible way to do this would be 
to ship a package that only contained the __init__. Then have all the 
python-backports.* packages depend on it.

Bug#805435: libapache2-mod-wsgi-py3, broken depends when rebuilt.

[peter green]

Package: libapache2-mod-wsgi-py3
Version: 4.3.0-1
Severity: serious
Tags: stretch sid
x-debbugs-cc: debian-python@lists.debian.org

I run a derivative called raspbian and I noticed our auto-binnmuer was 
repeatedly binnmuing mod-wsgi. Further investigation reveealed that 
every time it was rebuilt it was getting dependencies like.


python3 (>= 3.5), python3 (<<  3.5)


Which is obviously unsatisfiable.

I was able to reproduce this with a manual test build in a Debian sid 
environment.


Further investigation showed that the code in debian/rules assumed that 
supported python3 versions would be listed from lowest to highest but 
the current version of py3versions -vs always lists the default version 
last. My memory tells me this was a recent behaviour change and that 
would seem to fit with the fact that in Debian this package was 
successfully binnmu'd to add python 3.5 support.


As a quick fix I added some commands to debian/rules to sort the list 
before extracting the first and last entries and uploaded to Raspbian. A 
debdiff is attached, no intent to NMU in Debian.


 ccing debian-python for their opinion on

1: whether they were aware that this behaviour change could break packages
2: whether there is a better way to get the highest and lowest currently 
supported python3 version.


diff -Nru mod-wsgi-4.3.0/debian/changelog mod-wsgi-4.3.0/debian/changelog
--- mod-wsgi-4.3.0/debian/changelog 2014-10-05 10:28:06.0 +
+++ mod-wsgi-4.3.0/debian/changelog 2015-11-18 05:22:24.0 +
@@ -1,3 +1,9 @@
+mod-wsgi (4.3.0-1+rpi1) stretch-staging; urgency=medium
+
+  * Sort python 3 versions to prevent generation of impossible dependencies.
+
+ -- Peter Michael Green   Wed, 18 Nov 2015 04:39:47 
+
+
 mod-wsgi (4.3.0-1) unstable; urgency=medium
 
   [ Felix Geyer ]
diff -Nru mod-wsgi-4.3.0/debian/rules mod-wsgi-4.3.0/debian/rules
--- mod-wsgi-4.3.0/debian/rules 2014-10-05 10:19:11.0 +
+++ mod-wsgi-4.3.0/debian/rules 2015-11-18 05:25:03.0 +
@@ -7,7 +7,7 @@
 PYDEFAULT=$(shell pyversions -dv)
 PYMIN=$(shell echo $(PYVERS) | awk '{print $$1}')
 PYMAX=$(shell echo $(PYVERS) | LANG=C awk '{print $$NF+0.1}')
-PY3VERS=$(shell py3versions -vs)
+PY3VERS=$(shell py3versions -vs | tr ' ' '\n' | sort -n | tr '\n' ' ' | paste 
-s -d ' ')
 PY3DEFAULT=$(shell py3versions -dv)
 PY3MIN=$(shell echo $(PY3VERS) | awk '{print $$1}')
 PY3MAX=$(shell echo $(PY3VERS) | LANG=C awk '{print $$NF+0.1}')

pygame and python 3

[peter green]

One python package used heavilly in the raspberry pi community is 
pygame. Unfortunately the package hasn't had an upstream stable release 
since 2009 and the upstream stable release doesn't support python3.


Currently sid has the latest upstream stable release and no 
python3-pygame package. Experimental does have a python3-pygame package 
but I have not tested it (i'm not really a python guy myself).


Thoughts? has anyone tried the pythong3-pygame package in experimental? 
should it be pushed to unstable (after jessie release)? are there better 
alternatives to pygame?



--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55306616.6000...@p10link.net

python-enchant is not importable in python 2.6 on armhf. Any idea which package is at fault?

[peter green]

While investigating the build failure of scim-python on armhf I 
discovered that importing enchant with python 2.6 fails on armhf


root@debian:/# python2.6 -c import enchant
Traceback (most recent call last):
 File string, line 1, in module
 File /usr/lib/python2.6/dist-packages/enchant/__init__.py, line 90, 
in module

   from enchant import _enchant as _e
 File /usr/lib/python2.6/dist-packages/enchant/_enchant.py, line 133, 
in module

   raise ImportError(enchant C library not found)
ImportError: enchant C library not found
root@debian:/#

Importing with python 2.7 completes without errors on armhf. Importing 
with either 2.6 or 2.7 completes without errors on amd64, i386 and armel.


Any thoughts on what is going on and which package should receive a bug 
report about this



--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ef6893c.9010...@p10link.net

Bug#562904: adonthell ftbfs on armel

[peter green]

package: adonthell
version: 0.3.5-4
severity: serious
x-debbugs-cc: debian-python@lists.debian.org

During the run up to the lenny release python 2.5 was made the default 
and this made adonthell FTBFS on arm(el) with Fatal Python error: 
exceptions bootstrapping error. 
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486654 ). While doing 
flyby bugsquashing I took a look at this bug but failed to make any 
headway. I asked on debian-python but the only response I received was a 
suggestion to ask upstream. Since I was just doing flyby bugsquashing, 
had failed to produce a reduced testcase (since I really had no idea 
what was triggering the bug) and I don't know python I didn't make any 
contact with upstream (for either python or adonthell).


Since a release was looming and noone had made no progress on finding a 
root cause (afaict none of the maintainers even responsed to the 
bugreport) I proposed a patch that special cased arm(el) and explicityly 
chose python2.4 on theese architectures. after some minor revisions this 
patch was uploaded by Philipp Kern as a NMU.


Due to the planned removal of python2.4 Moritz Muehlenhoff reverted this 
special casing recently and the package now FTBFS again on armel but the 
soloution used last time is no longer possible. So as Moritz indicated 
in his changelog entry either the issue with newer python versions needs 
to be found and fixed (something I'm not capable of doing) or the armel 
adonthell package needs to be dropped.




--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bug#486654: adonthell: FTBFS on arm and armel

[peter green]

tags 486654 +patch
thanks

Rebuilding with gcc-4.2 fails in the same way, so I guess it is due to
Python changes.
  
The package builds succesfully on arm (I don't have armel availible to 
test but I presume the issue is the same on both) with python2.4. I have 
attatched a patch to make it use python 2.4 on arm and armel.




diff -ur adonthell-0.3.4.cvs.20080529/debian/control adonthell-0.3.4.cvs.20080529.new/debian/control
--- adonthell-0.3.4.cvs.20080529/debian/control	2008-07-28 18:31:56.0 +
+++ adonthell-0.3.4.cvs.20080529.new/debian/control	2008-07-28 08:42:39.0 +
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Games Team [EMAIL PROTECTED]
 Uploaders: Barry deFreese [EMAIL PROTECTED]
-Build-Depends: debhelper (= 5.0.37.2), autotools-dev, libsdl1.2-dev, libvorbis-dev, zlib1g-dev, swig1.3 (= 1.3.14), libfreetype6-dev, libaa1-dev, python-dev (= 2.3.5-11), python-support (= 0.4.0), libsdl-ttf2.0-dev, libsdl-mixer1.2-dev, libsdl1.2-dev, quilt
+Build-Depends: debhelper (= 5.0.37.2), autotools-dev, libsdl1.2-dev, libvorbis-dev, zlib1g-dev, swig1.3 (= 1.3.14), libfreetype6-dev, libaa1-dev, python-dev (= 2.3.5-11), python-support (= 0.4.0), libsdl-ttf2.0-dev, libsdl-mixer1.2-dev, libsdl1.2-dev, quilt, python2.4-dev [arm armel]
 Standards-Version: 3.7.3
 Homepage: http://adonthell.linuxgames.com/
 Vcs-Svn: ssh://svn.debian.org/svn/pkg-games/packages/trunk/adonthell/
diff -ur adonthell-0.3.4.cvs.20080529/debian/rules adonthell-0.3.4.cvs.20080529.new/debian/rules
--- adonthell-0.3.4.cvs.20080529/debian/rules	2008-07-28 18:31:56.0 +
+++ adonthell-0.3.4.cvs.20080529.new/debian/rules	2008-07-28 17:44:17.0 +
@@ -8,7 +8,23 @@
 CFGDEBUG = 
 INSTALL = /usr/bin/install -c
 INSTALL_PROGRAM = ${INSTALL} -p -o root -g root  -m 755
-PYVERSION=$(shell pyversions -d)
+
+PYVERSIONNN:=$(shell pyversions -d -v)
+
+
+#for some reason when adonthell embeds python2.5 on arm(el) it fails to init
+#so use python2.4 there for now
+DEB_BUILD_ARCH_CPU ?=$(shell dpkg-architecture -qDEB_BUILD_ARCH_CPU)
+
+ifeq ($(DEB_BUILD_ARCH_CPU),armel)
+	PYVERSIONNN :=2.4
+endif
+
+ifeq ($(DEB_BUILD_ARCH_CPU),arm)
+	PYVERSIONNN :=2.4
+endif
+
+PYVERSION :=python$(PYVERSIONNN)
 
 ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
 	CXXFLAGS += -g
@@ -98,7 +114,7 @@
 	dh_installmenu
 	dh_installman debian/adonthell.6
 	dh_installchangelogs ChangeLog
-	dh_pysupport -V $(shell pyversions -d -v) adonthell /usr/share/games/adonthell/modules/
+	dh_pysupport -V $(PYVERSIONNN) adonthell /usr/share/games/adonthell/modules/
 	dh_link
 	dh_strip
 	dh_compress

Re: Bug#486654: adonthell: FTBFS on arm and armel

[peter green]

Anyway, given that 0.3.4.cvs.20050813-3 compiled but
0.3.4.cvs.20050813-4 didn't, I guess this is somehow related to
gcc-4.3.
  
It looks like the default python version also changed between the two 
builds from 2.4 to 2.5 so that would be a suspect too.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

re: adonthell: FTBFS on arm and armel

[peter green]

make[4]: Entering directory 
`/build/buildd/adonthell-0.3.4.cvs.20080529/src/modules'

../../src/adonthell-0.3 -c
*** warning: prefs::read_adonthellrc: creating config file failed
Fatal Python error: exceptions bootstrapping error.

Something is going wrong with the intitalisation of the embedded python 
interpreter. What I can't figure out is what and why. Moving the call to 
initilise python to the beggining of main didn't make it work yet python 
inits fine when I try it in a seperate test app. Unfortunately the error 
message (which afaict is printed by the python lisb) is pretty much useless.


Any python gurus got any suggestions on how best to troubleshoot this issue?


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]