Sphinx make duplicates image files

[wildintellect]

Sphinx appears to be duplicating each image for each translation. So we end up with 8 copies of every screenshot, for ~400MB too much.

Look in /var/www/_images/ on a recent 6.0 beta iso.

[wildintellect]

related to ticket:950

[hamish]

see ​http://osdir.com/ml/sphinx-dev/2012-02/msg00006.html

Jake wrote:

It seems to be a problem with sphinx not being willing to overwrite an
image file, even when the new file is identical to the one being
overwritten. Currently, we have a hack in place which, on each build,
selectively removes the files that are causing the problem. This is
not an ideal solution: any help with this would be appreciated! Thank
you
Jake Vanderplas
scikit-learn dev team

Hamish

(argh, trac keeps logging me out)

[hamish]

here's a better thread view:

​http://groups.google.com/group/sphinx-dev/browse_thread/thread/289358d8f506649b

and the relevant ticket. it was supposed to be fixed in sphinx 1.0.8, but we are using 1.3.3. ?!

​https://bitbucket.org/birkenfeld/sphinx/issue/704

(perhaps the python patch there is worth trying)

Hamish

[hamish]

The nightly build on Adhoc does not have this bug (it's using 1.0.8+dfsg-2~bpo60+1 from Deb/Squeeze), but I do notice this line at the end of ​http://adhoc.osgeo.osuosl.org/livedvd/logs/nightly_build.err

WARNING: html_static_path entry './svn/doc/_static' does not exist

maybe relevant?

Hamish

[hamish]

work-around now implemented in install_main_docs.sh, /var/www/_images/ is down to 46mb and ~/gisvm/doc/_build/ is make cleaned away..

it's ugly though, duplicate files are replaced with symlinks to the originals. better to fix it in sphinx's python code. alternatively I added some commented out code to 'sed -i' the filenames in the .html docs dirs to match the base image name, if anyone wants to try to get that working (still a little more to do before it works).

Hamish

[hamish]

Replying to hamish:

The nightly build on Adhoc

(I've now made it the hourly build by the way)

Hamish

[kalxas]

In latest build8234 the _images folder is 45MB. No doc duplicates.

I will keep this around until it is confirmed in beta4

[hamish]

the bug should be kept open until it is fixed, the current work-around just alleviates the symptoms, it doesn't actually address the real problem. it's no longer a critical problem though. It also confirms that either the hardlinking by fslint is failing for the iso build, or that the remastersys max size calc is failing to account for hardlinks not taking up any (significant) extra space. If it is the latter, perhaps we can hack it to not trigger the max size check and just confirm it is not too big by hand.

thanks, Hamish

[kalxas]

this does not affect current beta5. I am leaving it open as requested but moving it to next version

[hamish]

Replying to kalxas:

this does not affect current beta5.

actually it very much does, but since we've mitigated the problem with an ugly hack it's no longer a blocker.

Hamish

[kalxas]

no problem with 6.5 release...

[kalxas]

As long as we stay on LTS, I don't see sphinx getting an update. The bug is resolved upstream.

[hamish]

7.0 is keeping with 12.04, hoping it is fixed in some future version. reopen if that doesn't happen after we upgrade sphinx.

[hamish]

nope, still busted in ubu 14.04 & sphinx 1.2.2.

Hamish

[kalxas]

There was a reply from Sphinx developers on GitHub:

_From Takayuki Shimizukawa on 2014-06-11 11:17:31+00:00_

Hamish, @kalxas, I can't reproduce the behavior this issue mentioned.

If you mean that sphinx should share the image directory for each build output, I think it's a new proposal.

Please make another ticket. Or, your contribution is always welcome 


---
Reply to this email directly or view it on GitHub:
https://github.com/sphinx-doc/testing/issues/704#issuecomment-68318498

[kalxas]

Unfortunately the repository was deleted from GitHub and all tickets were lost...

[kalxas]

my mistake: ​https://github.com/sphinx-doc/sphinx/issues/704

[johanvdw]

The correct issue for sphinx is: ​https://github.com/sphinx-doc/sphinx/issues/1112 I believe.

[kalxas]

This is now addressed in the debian build:

​https://github.com/OSGeo/OSGeoLive-doc/blob/master/debian/fix_sphinx.sh

​https://github.com/OSGeo/OSGeoLive-doc/blob/master/debian/rules#L12

[kalxas]

Ticket retargeted after milestone closed

[kalxas]

Ticket retargeted after milestone closed

[kalxas]

Fixed as part of our debian packaging. Upstream reports that this is a new feature and does not know when/if will be implemented.