Hi Chris, On Thu, Jul 07, 2016 at 09:53:53AM +0200, Chris Lamb wrote: > Hi, > > According to Debian Policy 4.9, packages may not attempt network > access during the build. However, the intersphinx mapping extension > causes attempted network access in almost all of Sphinx' reverse > build- dependencies. > > (Note that the network access does not cause a FTBFS if internet is > disabled, but it may cause a package to contain different contents > and is thus non-reproducible.) > > I've filed this against Sphinx, but I think a fix will require at > least two changes: > > - A patch to Sphinx to disable network access based on some > flag/environment variable. > > - dh-python (etc.) updated to set this specific flag. > > Filed as "serious" given that I could /technically/ file RC bugs > against all of Sphinx's reverse dependencies but this seems less > anti-social…
I agree that it is quite an unfortunate situation. I don't want to disable
intersphinx support by default because Sphinx can be used not only for
building other Debian packages: it will break other developers' workflow.
You say that we can read some flag set by dh-python. However, dh-python
(aka pybuild) already sets http{,s}_proxy environment variables which
disable network access for Sphinx. So packages using dh-python are already
safe.
The packages using intersphinx should be probably patched anyway to use
the distro provided inventory files, and I think it is the best solution we
have. Some examples:
http://sources.debian.net/src/psycopg2/2.6.1-1/debian/patches/local_inventory/
http://sources.debian.net/src/celery/3.1.23-4/debian/patches/intersphinx.patch/
So I am going to close this bug unless you can suggest anything better.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
_______________________________________________ Python-modules-team mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
