Re: RFS: colorzero/2.0-1 [ITP] -- Construct, convert, and manipulate colors in a Pythonic manner.
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?
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.
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).
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.
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.
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&arch=amd64&ver=2%3A4.11.5%2Bdfsg-1%2Bb1&stamp=1583775414&raw=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
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
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
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.
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.
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.
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.
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.
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, python-kiwisolver,
pylint3 reverse dependencies.
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
> 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
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.
(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.
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
> 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.
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.
(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.
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
> 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.
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
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
Re: Python 2, Python 3, Stretch & Buster
On 16/04/15 14:50, Paul Tagliamonte wrote: Aloha, Developers! Many of our projects in Debian are written in Python -- yay, Python! However, a large chunk are implemented in Python 2 -- Booo, Python 2! Background == Python 2 is scheduled to be EOL'd upstream officially and for good in 2020. Afaict the current documentation I can find ( https://hg.python.org/peps/rev/76d43e52d978 ) python 2.7 will be supported for "at least" 10 years after the initial python2.7 release which would mean july 2020. Do you have more recent information that changes the "at least" to "exactly"? We're in 2015 now (wow, that went quickly), and keeping our release cadence up (3 years a pop) puts Stretch up in 2018, and Buster in 2021. I just ran the sums (took the differences in days using openoffice calc, then divided by 365.25) woody->sarge 2.88 years sarge->etch 1.84 years etch->lenny 1.86 years lenny->squeeze 1.98 years squeeze->wheezy 2.23 years wheezy-> jessie 1.97 years (assuming it releases as announced) I assume there is no intention of a repeat of the woody->sarge cycle ;) If we are optimistic and assume that the jessie->stretch and stretch->buster cycles will be the same length as the sarge->etch cycle that puts the stretch release in febuary 2017 and the buster release in december 2018. If we are pessimistic and assume that the jessie->stretch and stretch->buster cycles will be the same length as the squeeze->wheezy cycle that puts the stretch release in july 2017 and the buster release in october 2019. -- 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/553063cb.4090...@p10link.net
Re: python-enchant is not importable in python 2.6 on armhf. Any idea which package is at fault?
Loïc Minier wrote:
We faced this in the Ubuntu armhf port as well; the bug is described in
details there:
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/898172
Essentially ctypes' "find_library" is very wrong and should not be used
(it tries to emulate ld.so's search behavior but does so with many
scary shortcuts...). find_library breaks on armhf because its ldconfig
output parsing isn't ready for the ",hard-float" suffix on libraries in
the cache.
Not only is find_library poorly implemented, but it also encourages
upstreams to try loading *any* SONAME from a library (in fact the first
one which comes in the ldconfig output), and with *whatever*
architecture ABI. So if you have the 32-bits libenchant12, 32-bits
libenchant13, 64-bits libenchant12 and 64-bits libenchant13, and you
find_library("enchant"), any of these libraries might be loaded
depending on the ldconfig output ordering...
I've opened an upstream bug (see the Launchpad meta-bug) and AFAIK the
python2.x patches will be uploaded to Debian with next uploads.
According to the launchpad "meta-bug" the python2.7 fix was already
uploaded to
unstable. This would fit with my test succeeding with python2.7 and
failing with
python2.6
Python2.6 (ubuntu) in the launchpad meta-bug is marked as "won't fix"
because python2.6 is "to be removed" are there any plans to fix
python2.6 in
debian or do they plan to remove it like ubuntu do?
It would be best if we would patch python programs and modules to stop
using find_library.
Should a bug be opened against python-enchant? and if so what should the
package use instead of find_library?
--
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/4ef887ff.60...@p10link.net
Re: python-enchant is not importable in python 2.6 on armhf. Any idea which package is at fault?
Hector Oron wrote:
Hello again,
2011/12/25 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 "", line 1, in
File "/usr/lib/python2.6/dist-packages/enchant/__init__.py", line 90, in
from enchant import _enchant as _e
File "/usr/lib/python2.6/dist-packages/enchant/_enchant.py", line 133, in
raise ImportError("enchant C library not found")
ImportError: enchant C library not found
root@debian:/#
Right, I was unable to reproduce on harris.debian.org, porterbox using
debian-ports.org packages, but I was able to reproduce on buildd,
running from official archive:
(sid-armhf-sbuild)root@hoiby:~# python2.6 -c "import enchant"
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.6/dist-packages/enchant/__init__.py", line
90, in
from enchant import _enchant as _e
File "/usr/lib/python2.6/dist-packages/enchant/_enchant.py", line
133, in
raise ImportError("enchant C library not found")
ImportError: enchant C library not found
python2.6 package was uploaded in binary form, without any
coordination with porters doing armhf bootstrapping, by its maintainer
Matthias Klose.
So would the reasonable thing to do be to binnmu it and see if the
problem goes away?
Cheers,
--
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/4ef723ec.8020...@p10link.net
python-enchant is not importable in python 2.6 on armhf. Any idea which package is at fault?
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 "", line 1, in
File "/usr/lib/python2.6/dist-packages/enchant/__init__.py", line 90,
in
from enchant import _enchant as _e
File "/usr/lib/python2.6/dist-packages/enchant/_enchant.py", line 133,
in
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
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
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
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
>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]
