Opened 12 years ago

Closed 8 years ago

#952 closed defect (fixed)

Sphinx make duplicates image files

Reported by: wildintellect Owned by: live-demo@…
Priority: normal Milestone: OSGeoLive10.0
Component: OSGeoLive Keywords: sphinx, docs


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.

Change history (26)

comment:1 by wildintellect, 12 years ago

related to ticket:950

comment:2 by hamish, 12 years ago

Keywords: 6.0 added
Priority: normalblocker

comment:3 by hamish, 12 years ago


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
Jake Vanderplas
scikit-learn dev team


(argh, trac keeps logging me out)

comment:4 by hamish, 12 years ago

here's a better thread view:

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

(perhaps the python patch there is worth trying)


comment:5 by hamish, 12 years ago

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

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

maybe relevant?


comment:6 by hamish, 12 years ago

work-around now implemented in, /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).


in reply to:  5 comment:7 by hamish, 12 years ago

Replying to hamish:

The nightly build on Adhoc

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


comment:8 by kalxas, 12 years ago

Priority: blockernormal

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

I will keep this around until it is confirmed in beta4

comment:9 by hamish, 12 years ago

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

comment:10 by kalxas, 12 years ago

Milestone: OSGeoLive6.0RC1OSGeoLive6.5

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

in reply to:  10 comment:11 by hamish, 12 years ago

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.


comment:12 by camerons, 12 years ago

Keywords: 6.5 added; 6.0 removed

comment:13 by kalxas, 11 years ago

Keywords: 7.0 added; 6.5 removed
Milestone: OSGeoLive6.5OSGeoLive7.0

no problem with 6.5 release...

comment:14 by kalxas, 11 years ago

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

comment:15 by hamish, 11 years ago

Milestone: OSGeoLive7.0OSGeoLive7.5
Resolution: wontfix
Status: newclosed

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.

comment:16 by hamish, 10 years ago

Keywords: docs added; 7.0 removed
Milestone: OSGeoLive7.9OSGeoLive8.0
Resolution: wontfix
Status: closedreopened

nope, still busted in ubu 14.04 & sphinx 1.2.2.


comment:17 by hamish, 10 years ago

Milestone: OSGeoLive8.0OSGeoLive8.5

comment:18 by kalxas, 9 years ago

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:

comment:19 by kalxas, 9 years ago

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

comment:21 by kalxas, 9 years ago

Milestone: OSGeoLive8.5OSGeoLive9.0

comment:22 by johanvdw, 9 years ago

The correct issue for sphinx is: I believe.

comment:24 by kalxas, 9 years ago

Milestone: OSGeoLive9.0OSGeoLive9.5

Ticket retargeted after milestone closed

comment:25 by kalxas, 8 years ago

Milestone: OSGeoLive9.5OSGeoLive10.0

Ticket retargeted after milestone closed

comment:26 by kalxas, 8 years ago

Resolution: fixed
Status: reopenedclosed

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

Note: See TracTickets for help on using tickets.