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

Attachment: signature.asc
Description: PGP signature

Reply via email to