Hey Dmitry, please note that the relatively old version of sphinx we have in Debian now makes it not possible to upgrade scikit-learn (https://github.com/scikit-learn/scikit-learn/issues/16087#issuecomment-573092993), which we require to upgrade as the scikit-learn version we have in unstable now FTBFS due to other modules/libraries being upgraded, compatibility which is fixed in the new version and... you got the idea :)
I understand it may be more work, but i suspect that splitting sphinx 1.8 and 2.* is probably the best way forward to allow continuous compatibility with already-existing packages and the upgrade of those modules that require a newer version. please let me know what you think On Tue, 24 Dec 2019 22:18:37 -0500 Sandro Tosi <mo...@debian.org> wrote: > On Sun, Dec 22, 2019 at 4:22 PM Dmitry Shachnev <mity...@debian.org> wrote: > > > > Hi Sandro! > > > > On Sun, Dec 22, 2019 at 02:47:10PM -0500, Sandro Tosi wrote: > > > > The current version packaged in Debian is very outdated, > > > > even in unstable. Please consider packaging the current > > > > upstream release. > > > > > > I'm echoing this request: the just released numpy/1.18.0 requires > > > sphinx >= 2.2.0, so we cannot upgrade numpy without an updated sphinx. > > > please consider package it at the earliest. > > > > Unfortunately sphinx ≥ 2.0 dropped support for Python 2. > > > > So I should either wait until all blocking bugs of #938528 are resolved, or > > introduce a new source package like sphinx-python2 for the old version. > > i think there a quite too many packages blocking 938528 (counts is > 100), so yeah maybe a src:sphinx2 (to track 1.8.5) and src:sphinx (to > track 2+) seems like the best solution to keep old packages around and > not prevent progress for the modules more forward-looking. > > > However the latter solution will mean that we can no longer have shared > > sphinx-common and libjs-sphinxdoc packages, and we will need to have two > > versions of dh_sphinxdoc too (or one version that will generate different > > dependencies for old and new sphinx). This is something I wanted to avoid, > > because it is extra work for supporting a Python 2 version that will be > > dead in a few days. > > hm, that's a good point indeed; i'm not sure we can drop python-sphinx > and make all of those packages RC > > > Recently your script bumped many Python 2 removal bugs to RC, with the > > intention to accelerate porting those packages to Python 3 (or getting them > > removed). Maybe better to wait a couple of months and then just upload new > > Sphinx and break its Python 2 reverse build-dependencies? > > only 49 of those 100 blocked packages are currently RC, so it will > take quite more time i suspect; also some of those packages are sphinx > extensions, that will have to go at the same time as sphinx maybe? > > > Can you patch old Sphinx support into numpy for the time being? > > tbh, i'd rather not :) maybe you can consider uploading 2.2+ to > experimental, just to see if there's any breakage with the new version > (even for packages already using python3-sphinx), and i can upload > numpy in experimental > > Cheers, > -- > Sandro "morph" Tosi > My website: http://sandrotosi.me/ > Me at Debian: http://wiki.debian.org/SandroTosi > Twitter: https://twitter.com/sandrotosi > >