Re: reducing matplotlib2 build-depends.
On Tue, Nov 12, 2019 at 9:24 AM peter green wrote: > 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). well, i dont think it's a good reason to just stop testing complex software tho. some of those dependencies are required so that mpl can build extensions (in particular for the GUI backends) so if you remove them, the mpl build system is smart enough to disable those extensions, resulting in a graphic library without any GUI bindings to work with. that doesnt sound ideal. I'm gonna go thru some of the dependencies and will see if i can remove some, in particular now that i've remored the -doc package from the git repo, but i'm not gonna get rid the whole unittest suite. thanks for your work on this, and to nudge me into looking deeper at mpl2 deps Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Adding Python 3.8 as a supported Python3 version
On 07.11.19 15:08, Matthias Klose wrote: > This weekend, I am planning to upload python3-defaults, adding python3.8 as a > supported Python3 version. This may introduce some churn in unstable until > the > basic binNMUs are available as well. > > Details for the addition can be found at [1], known issues and patches are > filed > [2]. There was no test rebuild in Debian itself, but the addition was made in > the current Ubuntu development series. Things look good, and from my point of > view don't block any unrelated transition work. python3-defaults will get a > RC > issue to stay in unstable until the packages build-depending on > python3-all-dev > are built, and after doing a test rebuild with the two supported Python3 > versions. Earlier test rebuilds don't make sense. > > There are a few packages, where the upstream versions used in Ubuntu diverge > from the ones currently in unstable (not naming those already updated in > unstable by the DPMT): > > - hypothesis #942693, not sure if this is really needed, > the testsuite stack might be fixed by the new pluggy > version as well. > > - python-xarray #944044. 1.4 is already broken with Python 3.7. For > Ubuntu I fell back to 1.2.1. 1.2.3 might work as well, still seeing > one or two test failures. > > - Using numpy from experimental, and only building the Python2 numpy > packages from the python-numpy source. > > - Using python-scipy from experimental, building the Python3 packages, > and renaming the python-scipy package to python2-scipy, only building > the Python2 packages. > > - matplotlib and pandas don't have Python2 packages in Ubuntu > anymore, so I can't tell much what is needed here. Pandas needs > a new upstream for 3.8. > > Packages building on top of numpy/scipy/pandas, like the PyAstro stack, > continue > to work with these updates, despite some new test failures. So this upload didn't happen, but thanks to Rebecca we now have an almost Python2 free pandas in unstable. And apologies to the science team for the 1-day delayed NMUs for patsy and scikit-learn. Now planning the python3-defaults upload for Thursday or Friday. Matthias
Re: reducing matplotlib2 build-depends.
By itself, removing those dependencies reduces the big tangle [0] from 148 packages to 141, the freed ones being: ipywidgets pyqt5 pep8 autopep8 xcffib xlwt cairocffi. (Note that "not in a tangle" means "no *circular* dependencies", *not* "leaf / can be removed immediately".) There may also be more packages that have more than one link into the tangle but could have all of those links cut. This was calculated from the Blocks of py2removal bugs, so only considers packages that still have an open py2removal bug, not already-removed packages e.g. pandas. [0] Largest strongly connected component: can't remove any subset (except all or none) without breaking at least some of the remaining ones. Previously discussed in https://lists.debian.org/debian-python/2019/10/threads.html#00092 The full 148 are: alabaster apipkg automat autopep8 backports.functools-lru-cache beautifulsoup4 cairocffi chardet colorspacious configobj contextlib2 cython dbus-python dot2tex entrypoints enum34 execnet fdb freezegun html5lib incremental ipykernel ipython ipython-genutils ipywidgets jupyter-client jupyter-core keyrings.alt lxml mako matplotlib matplotlib2 mayavi2 mercurial more-itertools mpmath nose numexpr numpydoc pep8 pexpect pickleshare pillow pycairo pyflakes pyglet pygments pygobject pygobject-2 pygtk pyhamcrest pymacs pyopenssl pyqt5 pyrex pytables pytest pytest-expect pytest-forked pytest-runner pytest-xdist python-apptools python-apt python-atomicwrites python-attrs python-babel python-cffi python-chaco python-changelog python-characteristic python-click python-cryptography python-cycler python-dateutil python-debian python-docutils python-enable python-envisage python-flake8 python-flaky python-funcsigs python-future python-genty python-gevent python-greenlet python-hypothesis python-importlib-metadata python-iso8601 python-keyring python-linecache2 python-mccabe python-mock python-mode python-numpy python-packaging python-pathlib2 python-pbr python-pip python-pluggy python-psutil python-py python-pyface python-pysqlite2 python-qt4 python-scipy python-secretstorage python-service-identity python-setupdocs python-traceback2 python-traits python-traitsui python-typing python-tz python-urllib3 python-virtualenv python-webencodings python-whoosh python-zipp pyxdg pyyaml pyzmq requests rope ropemacs ropemode setuptools-scm sip4 six soupsieve sphinx sphinx-gallery sphinx-paramlinks sphinx-rtd-theme sphinxcontrib-websupport sqlalchemy sympy tap.py testresources texlive-base texlive-extra traitlets twisted unittest2 wcwidth wheel xapian-bindings xcffib xlwt
Re: reducing matplotlib2 build-depends.
Hi all, On Tue, Nov 12, 2019 at 02:13:51PM +, peter green wrote: > 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. > > [...] > > What do others with more experience think? Should these build-dependencies > be removed? +1 for this idea! matplotlib2 is currently one of only 4 blockers for python-qt4 removal (and one of two blockers for removing its Python 2 part). I wonder if we can also remove python-matplotlib2-doc and related sphinx build-dependencies. For developers working on software using matplotlib, the documentation for its latest version (python-matplotlib-doc) should be enough. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: getmail: Python2 removal in sid/bullseye
On Wed, Nov 13, 2019 at 12:37:27AM +0900, Osamu Aoki wrote: > Upstream is active and prides to keep python 2.5 compatibility code in > it ... (Not just 2.7). I (Osamu Aoki ) and dkg even > made some effort to support both 2 and 3 but the idea was rejected by > upstream in 2018. (Then we both lost motivation since upstream will not > include such code in near future) > https://marc.info/?l=getmail&m=151542515929707&w=2 > > The upstream is somehow convinced that python2 will be there for some > time (Year ~2020 and later). > https://marc.info/?l=getmail&m=151542154628352&w=2 uh. meh. I haven't looked at the code, but if you made the effort, how improbable would it be for you to just keep the patches for py3 support yourself in the packaging for the time being? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
getmail: Python2 removal in sid/bullseye
Hi, It seems I need to discuss here before adding followings. | Package: src:getmail | Version: 5.13-1 | Severity: normal | Tags: sid bullseye | User: debian-python@lists.debian.org | Usertags: py2keep Upstream is active and prides to keep python 2.5 compatibility code in it ... (Not just 2.7). I (Osamu Aoki ) and dkg even made some effort to support both 2 and 3 but the idea was rejected by upstream in 2018. (Then we both lost motivation since upstream will not include such code in near future) https://marc.info/?l=getmail&m=151542515929707&w=2 The upstream is somehow convinced that python2 will be there for some time (Year ~2020 and later). https://marc.info/?l=getmail&m=151542154628352&w=2 | > Python2 will be EOL after 2020. | [...] | > But, if getmail stays as python2 code, many distros have no choice but | > to drop getmail sometime after 2020. | | Uh, no, they won't. Python 2 may stop *development*, but it doesn't magically | stop working in 2020. I fully expect distros will keep shipping Python 2 for | years after that, and undoubtedly there will still be lots of Python 2 code | in the world running in 2030 and later. The related binary packages are available in 2 binary names (depending on release) getmail4 (version=4,5) popcon installed ~2000 getmail (version=3,5) popcon installed ~1000 https://qa.debian.org/popcon-graph.php?packages=getmail%20getmail4&show_installed=on&want_legend=on&want_ticks=on&date_fmt=%25Y-%25m&beenhere=1 I think this qualifies for "py2keep". The next upload of new upstream 5.14 should update dependency etc to python2 instead of bare python. If Debian and Fedora demonstrate its python3 removal, I am sure the upstream may change his thought. If you have some progress indicator, that can be used to convince getmail upstream. I or dkg need a solid fact to restart conversation with the upstream. Regards, Osamu
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,
Re: Policy About Maintainer and Uploaders Fields (was: PAPT: join request)
On 11/12/19 2:38 AM, Sandro Tosi wrote: > please also realize not everyone shares the > same ideas as yours and you should try sometimes to respect those > people decisions too. With all due respect, the point that I'm trying to make is that this policy is only there because what I believe is a minority (which you are part of) supports it, and which everyone else doesn't like. I do respect your view, and I'm sorry if voicing my opinion is (again) going against what's been established for years, just like it did when we moved from SVN to Git. Though that's how things evolve, hopefully for the better. Also, it's ok if we don't agree... :) Cheers, Thomas Goirand (zigo)
