Is it time to remove python-numpy from testing?

2020-07-09 Thread 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

joining the DPMT.

2020-04-30 Thread 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

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

2020-04-25 Thread 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

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

2020-03-30 Thread 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

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

2020-03-30 Thread 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.

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

2020-02-27 Thread 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

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

2020-01-18 Thread 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

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

2020-01-17 Thread 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

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

2019-12-07 Thread 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

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

2019-12-07 Thread 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

Dealing with zope.interface unsatisfiable build-dependency.

2019-12-06 Thread 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

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

2019-11-28 Thread 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

reducing matplotlib2 build-depends.

2019-11-12 Thread 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

pylint3 reverse dependencies.

2019-10-01 Thread 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

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

2019-09-15 Thread 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(

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

2019-09-12 Thread 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(

Re: Investigating the reverse dependencies of python-monotonic.

2019-08-13 Thread 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

Investigating the reverse dependencies of python-monotonic.

2019-08-13 Thread 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

Re: Python 3.7 or 3.6 in Buster

2018-11-11 Thread 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

Future of pygame in Debian.

2018-10-12 Thread 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

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

2018-07-22 Thread 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

python logo.

2018-03-05 Thread 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?

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

2018-01-25 Thread 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

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

2015-11-17 Thread 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

pygame and python 3

2015-04-16 Thread 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.

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

2011-12-24 Thread 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

Bug#562904: adonthell ftbfs on armel

2009-12-28 Thread 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.

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

2008-07-28 Thread 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

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

2008-07-27 Thread 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

re: adonthell: FTBFS on arm and armel

2008-06-17 Thread 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