Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 374645 - media-gfx/asymptote-2.13[doc] fails to emerge: Could not open file diagonal.eps
Summary: media-gfx/asymptote-2.13[doc] fails to emerge: Could not open file diagonal.eps
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Andrey Grozin
URL:
Whiteboard:
Keywords:
Depends on: 374147
Blocks:
  Show dependency tree
 
Reported: 2011-07-10 06:27 UTC by Martin von Gagern
Modified: 2011-08-22 05:01 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build log (media-gfx:asymptote-2.13:20110710-003636.log,60.25 KB, text/plain)
2011-07-10 06:27 UTC, Martin von Gagern
Details
My emerge --info output (emerge-info.txt,7.95 KB, text/plain)
2011-07-20 12:51 UTC, Honza Macháček
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin von Gagern 2011-07-10 06:27:54 UTC
Created attachment 279565 [details]
build log

I guess this might be closely related to bug #374147.

texi2dvi --pdf asymptote.texi
This is pdfTeX, Version 3.1415926-1.40.11 (TeX Live 2010)
 restricted \write18 enabled.
entering extended mode
(./asymptote.texi (/usr/share/texmf-dist/tex/texinfo/texinfo.tex
Loading texinfo [version 2010-09-06.17]: pdf, fonts, markup, glyphs,
page headings, tables, conditionals, indexing, sectioning, toc, environments,
defuns, macros, cross references, insertions,
(/usr/share/texmf-dist/tex/generic/epsf/epsf.tex
This is `epsf.tex' v2.7.3 <23 July 2005>
) localization, formatting, and turning on texinfo input format.)
(./version.texi)
(logo.eps
)
[1] [2] [-1] Chapter 1 Cross reference values unknown; you must run TeX again.
[1] Chapter 2 [2] [3]
Overfull \hbox (6.50589pt too wide) in paragraph at lines 447--450
@textrm pro-ces-sor @texttt Ghostscript[]@textrm , avail-able from @texttt http
://sourceforge.net/projects/ghostscript/[]@textrm . 
[4] [5] [6] [7] Chapter 3 [8] (./diagonal.asy)
(diagonal.eps
./asymptote.texi:799: Could not open file diagonal.eps, ignoring it.
@epsfgetbb ...Could not open file #1, ignoring it}
                                                  @else {@chardef @other = 1...

@next #1->@epsfgetbb {#1}
                         @epsfsetgraph {#1}
@imagexxx ...ysize =#3@relax @fi @epsfbox {#1.eps}
                                                  @fi @ifimagevmode @medskip...

@image ...true @fi @else @imagexxx #1,,,,,@finish 
                                                  @fi 
<argument> @hfil @ignorespaces @image {diagonal}
                                                @unskip @hfil 
@next #1->@line {@kern @leftskip #1
                                   @kern @rightskip }
l.799 @center @image{diagonal}
                              
? x
Output written on asymptote.dvi (11 pages, 24972 bytes).
Transcript written on asymptote.log.
/usr/bin/texi2dvi: pdfetex exited with bad status, quitting.
make: *** [asymptote.pdf] Error 1
emake failed
 * ERROR: media-gfx/asymptote-2.13 failed (compile phase):
 *   emake asymptote.pdf failed

As latex was run in interactive mode, the build got stuck there until I entered the x and pressed return.
Comment 1 Honza Macháček 2011-07-11 15:11:25 UTC
I have not found the cause of the problem but I have managed to circumvent it manually.

All the images that should be generated as eps files are generated as pdf. So, when my building of asymptote crashed, I converted all the pdf files in the doc subdirectory to eps using ptftops with the -eps switch.

Then asymptote.dvi was created but not asymptote.pdf. Obviously using dvipdf corrected that deficiency.

Afterwards I was able to issue ebuild compile and ebuild merge successfully.
Comment 2 Andrey Grozin gentoo-dev 2011-07-14 14:27:40 UTC
I cannot reproduce this problem.

texi2dvi --pdf asymptote.texi

uses .pdf files (rightly so), not .eps files:

....
[4] [5] [6] [7] Chapter 3 [8] (./diagonal.asy) <./diagonal.pdf> [9] <./diagonal
.pdf> (./bigdiagonal.asy) <./bigdiagonal.pdf> (./square.asy) <./square.pdf>
[10] (./labelsquare.asy) <./labelsquare.pdf> (./quartercircle.asy) <./quarterci
rcle.pdf> [11] (./superpath.asy) <./superpath.pdf> (./cube.asy [12]) <./cube.pdf> Chapter 4 [13] [14]
Overfull \hbox (26.27502pt too wide) in paragraph at lines 1181--1181
[][] 
[15] [16]
Overfull \hbox (69.88573pt too wide) in paragraph at lines 1313--1314
 [][][]@texttt http://partners.adobe.com/public/developer/en/ps/sdk/TN5600.Smoo
thShading.pdf[][][]@textrm .  
[17] [18] [19] <./CDlabel.pdf> (./CDlabel.asy [20]) Chapter 5 [21] <./bezier.pd
f> <./bezier2.pdf> [22] (./dots.asy) <./dots.pdf> (./colons.asy) <./colons.pdf>
Chapter 6 [23] [24] [25] [26] [27] [28]
Overfull \hbox (32.68237pt too wide) in paragraph at lines 2132--2132
 [][] 
[29] [30] (./join.asy) <./join.pdf> [31] [32] [33]
....

and so on. /usr/bin/texi2dvi comes from sys-apps/texinfo-4.13-r1. And from the fact that I never had this problem, I conclude that older versions of texinfo worked the same way (i.e., used .pdf figures if --pdf was given).
Comment 3 Martin von Gagern 2011-07-14 20:26:28 UTC
(In reply to comment #0)
> I guess this might be closely related to bug #374147.

Very closely indeed: texi2dvi calls pdfetex behind the scenes, and for some reason that doesn't operate in pdf mode by default on my system. A workaround analogous to bug #374147 comment #1 is possible:

cat <<EOF> /usr/local/bin/pdfetex
#!/bin/sh
# Work around https://bugs.gentoo.org/374645
exec /usr/bin/pdfetex -output-format=pdf "$@"
EOF
chmod a+x /usr/local/bin/pdfetex

With this in place, asymptote emerges as it should.

The question remains: why doesn't pdfetex default to pdf mode on my system. No clue how to get a lead on that. Suggestions appreciated.
Comment 4 Honza Macháček 2011-07-20 12:50:45 UTC
(In reply to comment #3)

> The question remains: why doesn't pdfetex default to pdf mode on my system. No
> clue how to get a lead on that. Suggestions appreciated.

That is the question.

If I put \showthe\pdfoutput into a simple (or just any) TeX file and run pdftex on it I get 0. Doing that in /usr/share/texmf-dist/tex/plain/config/pdfetex.ini just before \dump breaks making the format (texconfig-sys init pdftex), but reports 1. Removing \showthe\pdfoutput and calling `texconfig-sys init pdftex` produced a new /var/lib/texmf/web2c/pdftex/pdftex.fmt but did not help the pdftex behaviour. I cannot find if the value is dumped incorrectly or if it gets changed somehow when pdftex is invoked.

I have tried installing TeXlive outside portage, and that has helped. Nevertheless I am unable to find the critical difference.
Comment 5 Honza Macháček 2011-07-20 12:51:59 UTC
Created attachment 280451 [details]
My emerge --info output
Comment 6 Martin von Gagern 2011-07-29 12:47:04 UTC
I suggest keeping this report here for the asymptote build error, and invstigate the underlying pdfoutput problem in bug #374147. Honza, do you want to cc to that one as well, as you are the only other person that I know has encountered this issue.
Comment 7 Martin von Gagern 2011-07-29 16:37:33 UTC
Proposed fix for the underlying texlive bug in bug #374147 comment #4. I expect texlive maintainers to commit fixed revbumps soon.

Not sure how to properly avoid the problem in the asymptote ebuild, though. All versions of texlive-core currently in portage are likely affected by this bug.

So the obvious solution would be blocking each and every one of them, or rather depending on revisions after those currently in portage. As bug #4315 isn't in PMS yet, this can only be done using a long list:

DEPEND="${RDEPEND}
  doc? (
    || ( 
      ( >app-text/texlive-core-2011 )
      ( <app-text/texlive-core-2011 >app-text/texlive-core-2010-r3 )
      ( <app-text/texlive-core-2010 >app-text/texlive-core-2009-r2 )
      ( <app-text/texlive-core-2009 >app-text/texlive-core-2008-r7 )
    )
  )"

Assuming that texlive-core 2008-r8, 2009-r3, 2010-r4 and 2011-r1, when and if they are committed, will include the fix, then the above should ensure that there is a version of texlive-core around that does work all right.

Of course, this is a lot more complicated and stricter than the virtual/latex-base dependency currently in place. So as a second-best solution, you could explicitely hard-block all broken versions currently in portage:

DEPEND="${RDEPEND}
  doc? (
    !!app-text/texlive-core-2008-r7
    !!app-text/texlive-core-2008-r8
    !!app-text/texlive-core-2009-r1
    !!app-text/texlive-core-2009-r2
    !!app-text/texlive-core-2010-r3
    !!app-text/texlive-core-2011
  )"

This approach won't take care of people who have outdated versions of texlive-core installed, but that's their problem, and I believe portage will tell them so. But perhaps the texlive maintainers will remove the broken versions from the portage tree soon, so that by the same argument no action at all is required from the asymptote ebuild.

Of course, you could also simply ignore the fact that broken texlive-core has a chance of breaking the asymptote build. It appears to be rare enough. If it does, people are likely to find this bug (in particular if you keep it open), and then they know that they'll have to update their texlive-core package.

One thing worth considering might be whether we want to patch the asymptote build to not use interactive tex mode. Having the ebuild fail with an error message is acceptable, but having it hang might cause trouble on several occasions. Parallel builds (e.g. emerge -j4) as well as automated unattended upgrades (cron job or similar) come to my mind. There might be also build servers (like the Gentoo tinderbox machines) busy building binary packages, without user intervention either.

If you'd change to say scrollmode, then you could even analyze the log in case of an error, and emit a suitable error message in case this bug here occurs.
Comment 8 Andrey Grozin gentoo-dev 2011-08-22 05:01:18 UTC
I suppose this can be closed, because bug #374147 has been fixed.