Created attachment 500982 [details] build log Latest sane-backends has problems building its documentation: Error in ghostcript command command was: gs -q -dNOPAUSE -sAutoRotatePages=None -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -sDEVICE=pdfwrite -dPDFSETTINGS=/prepress -sOutputFile=figs/area.pdf - -c quit Without MAKEOPTS=-j1 I happened to see three more of these, for figs/image-data.pdf, figs/hierarchy.pdf and figs/flow.pdf. I have app-text/ghostscript-gpl-9.21 and media-gfx/transfig-3.2.5e installed.
Created attachment 501128 [details] emerge --info Contrary to what I expected, USE=-doc didn't solve this.
The working workaround for me was eselect infinality set ultimate-free This yields # fc-match helvetica LiberationSans-Regular.ttf: "Liberation Sans" "Regular" Before I had eselect infinality set infinality and "helvetica" was actually Arial. This somehow breaks ghostscript.
See discussion at https://tex.stackexchange.com/questions/151607/epstopdf-ghostscript-cant-find-fonts
*** Bug 636374 has been marked as a duplicate of this bug. ***
Don't seem to have infinality here. Not sure what a clean fix would be for me. # fc-match helvetica texgyreheros-regular.otf: "TeX Gyre Heros" "Regular" # eselect infinality !!! Error: Can't load module infinality exiting # qfile -v -b texgyreheros-regular.otf dev-texlive/texlive-fontsrecommended-2017 (/usr/share/texmf-dist/fonts/opentype/public/tex-gyre/texgyreheros-regular.otf) media-sound/lilypond-2.19.64 (/usr/share/lilypond/2.19.64/fonts/otf/texgyreheros-regular.otf) media-fonts/tex-gyre-2.005 (/usr/share/fonts/tex-gyre/texgyreheros-regular.otf) From /etc/fonts/conf.d/30-metric-aliases.conf <!-- Map generics to specifics --> <!-- PostScript --> <alias binding="same"> <family>Helvetica</family> <accept> <family>TeX Gyre Heros</family> </accept> </alias>
Try to reconfigure fontconfig to substitute another font instead of Helvetica.
I don't know what changed in my config, but during today's world update, the sane-backends-1.0.27 package suddenly emerged successfully, without me taking any manual action. I see no difference to comment 5.
closing as obsolete (this looks to me as a ghostscript bug anyway, for the case it reappears)