Bug 868011 - /usr/bin/texi2dvi: pdfetex exited with bad status, quitting.
/usr/bin/texi2dvi: pdfetex exited with bad status, quitting.
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: texinfo (Show other bugs)
18
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Vitezslav Crhonek
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-18 17:13 EDT by Bruno Postle
Modified: 2013-01-30 01:36 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-30 01:36:34 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Debian BTS 666532 None None None 2012-10-18 17:13:42 EDT

  None (edit)
Description Bruno Postle 2012-10-18 17:13:42 EDT
Description of problem:

I'm updating the enblend package to build the pdf documentation, this is fine in f16/f17/f18 but not with rawhide. It seems the exact same bug in texlive has been encountered and fixed in debian, see:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666532
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666375

Version-Release number of selected component (if applicable):

1:2012-3.20120926_r27815.fc19

How reproducible:

Always

Steps to Reproduce:
1. wget http://repos.fedorapeople.org/repos/bpostle/panorama/fedora-18/SRPMS/enblend-4.1-0.1.20121011hg.fc18.src.rpm
2. mock --rebuild -r fedora-rawhide-x86_64 enblend-4.1-0.1.20121011hg.fc18.src.rpm
3. wait a very long time, crash happens at end of build...

Actual results:

/usr/bin/texi2dvi: pdfetex exited with bad status, quitting.

Expected results:

Nice rawhide enblend rpms

Additional info:
Comment 1 Bruno Postle 2012-11-11 15:30:43 EST
This problem now affects f18 (in addition to f19/rawhide), presumably this is something to do with 2012-3.20121019_r28030.fc18 landing in f18.
Comment 2 Jindrich Novy 2012-11-12 01:19:28 EST
The build failure you see is caused by epsf.tex missing from the install-root. One can simply add this BR to fix it:

BuildRequires: tex(epsf.tex)

But I'm not sure whether this is not actually a requirement of texinfo-tex where it is missing.

Vitezslav, doesn't this requirement need to be added directly to texinfo-tex?

Thanks!
Comment 3 Jindrich Novy 2012-11-13 00:58:32 EST
After source investigation it is apparent that texinfo-tex sources realy requires epsf.tex so I added the build requirement and release update.
Comment 4 Fedora Update System 2012-11-13 01:05:21 EST
texinfo-4.13a-18.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/texinfo-4.13a-18.fc18
Comment 5 Alex Lancaster 2012-11-17 20:36:33 EST
I see something similar with my f18 builds: bug #877691  but adding the BuildRequires: tex(epsf.tex) trick doesn't seem to fix it.
Comment 6 Fedora Update System 2012-11-20 14:50:08 EST
emacs-common-ess-12.09-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/emacs-common-ess-12.09-2.fc18
Comment 7 Fedora Update System 2012-11-20 14:51:25 EST
emacs-common-ess-12.09-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/emacs-common-ess-12.09-2.fc17
Comment 8 Fedora Update System 2012-12-06 02:19:52 EST
texinfo-4.13a-18.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 9 Andrea Musuruane 2013-01-02 08:22:55 EST
This issue is still present in current rawhide and F18. I reproduced it following the instructions in comment #0.

Moreover, I get a similar issue when trying to rebuild xroar (in RPM Fusion).

How reproducible:
Always

Steps to Reproduce:
1. wget http://www.lesloueizeh.com/musuruan/xroar-0.29.1-1.fc17.src.rpm
2. mock --rebuild -r fedora-rawhide-x86_64 xroar-0.29.1-1.fc17.src.rpm
(the same applies for F18 but *NOT* for F17)
3. crash happens at end of build..

Actual results:
TEXI2PDF doc/xroar.pdf
make: *** [doc/xroar.pdf] Error 1
errore: Stato d'uscita errato da /var/tmp/rpm-tmp.IiOCxI (%build)
Errori di compilazione RPM:
    Stato d'uscita errato da /var/tmp/rpm-tmp.IiOCxI (%build)
Child return code was: 1

Expected results:
Nice rawhide & F18 xroar RPMs

Maybe it is related to this bug:
https://bugs.archlinux.org/task/16129
Comment 10 Pavel Raiskup 2013-01-10 09:20:21 EST
I don't know whether this is related or not .. but I have some problems during
building rawhide's automake.  Internal testusite fails on texi2dvi ..

Shouldn't be texlive-dvips dependant on texlive-latex-fonts?  Because it would
solve this problem..:

  $ texi2dvi test.texi
  $ echo $?
  1
  $ cat test.texi
  \input texinfo
  @node Top
  Hello walls.
  @bye

I could possibly create new bugzilla for this when needed.

Pavel
Comment 11 Dmitri A. Sergatskov 2013-01-26 02:43:07 EST
I do have texlive-latex-fonts yet this does not work for me:

(In $HOME/scratch/)
$ cat test.texi 
\input texinfo
  @node Top
  Hello walls.
  @bye

$ texi2dvi --build=local -V  test.texi 
/usr/bin/texi2dvi: Processing test.texi ...
/usr/bin/texi2dvi: BIBINPUTS='.:/home/ZZZ/scratch:/home/ZZZ/scratch/.::'
/usr/bin/texi2dvi: BSTINPUTS='.:/home/ZZZ/scratch:/home/ZZZ/scratch/.::'
/usr/bin/texi2dvi: DVIPSHEADERS='.:/home/ZZZ/scratch:/home/ZZZ/scratch/.::'
/usr/bin/texi2dvi: INDEXSTYLE='.:/home/ZZZ/scratch:/home/ZZZ/scratch/.::'
/usr/bin/texi2dvi: MFINPUTS='.:/home/ZZZ/scratch:/home/ZZZ/scratch/.::'
/usr/bin/texi2dvi: MPINPUTS='.:/home/ZZZ/scratch:/home/ZZZ/scratch/.::'
/usr/bin/texi2dvi: TEXINPUTS='.:/home/ZZZ/scratch:/home/ZZZ/scratch/.::'
/usr/bin/texi2dvi: TFMFONTS='.:/home/ZZZ/scratch:/home/ZZZ/scratch/.::'
/usr/bin/texi2dvi: Removing /home/ZZZ/scratch/test.t2d

(It appears it also ignores "--build-local" and does --tidy anyway).

Dmitri.
Comment 12 Vitezslav Crhonek 2013-01-29 06:48:49 EST
(In reply to comment #11)
> I do have texlive-latex-fonts yet this does not work for me:
> 
> (In $HOME/scratch/)
> $ cat test.texi 
> \input texinfo
>   @node Top
>   Hello walls.
>   @bye
> 
> $ texi2dvi --build=local -V  test.texi 
> /usr/bin/texi2dvi: Processing test.texi ...
> /usr/bin/texi2dvi: BIBINPUTS='.:/home/ZZZ/scratch:/home/ZZZ/scratch/.::'
> /usr/bin/texi2dvi: BSTINPUTS='.:/home/ZZZ/scratch:/home/ZZZ/scratch/.::'
> /usr/bin/texi2dvi: DVIPSHEADERS='.:/home/ZZZ/scratch:/home/ZZZ/scratch/.::'
> /usr/bin/texi2dvi: INDEXSTYLE='.:/home/ZZZ/scratch:/home/ZZZ/scratch/.::'
> /usr/bin/texi2dvi: MFINPUTS='.:/home/ZZZ/scratch:/home/ZZZ/scratch/.::'
> /usr/bin/texi2dvi: MPINPUTS='.:/home/ZZZ/scratch:/home/ZZZ/scratch/.::'
> /usr/bin/texi2dvi: TEXINPUTS='.:/home/ZZZ/scratch:/home/ZZZ/scratch/.::'
> /usr/bin/texi2dvi: TFMFONTS='.:/home/ZZZ/scratch:/home/ZZZ/scratch/.::'
> /usr/bin/texi2dvi: Removing /home/ZZZ/scratch/test.t2d
> 
> (It appears it also ignores "--build-local" and does --tidy anyway).
> 
> Dmitri.

Worked fine for me, or am I missing something?

This bug should be fixed by updating to texlive version from bz#879661.
Comment 13 Andrea Musuruane 2013-01-29 13:51:07 EST
(In reply to comment #12)
> Worked fine for me, or am I missing something?
> 
> This bug should be fixed by updating to texlive version from bz#879661.

I could successfully build xroar for rawhide with texinfo-4.13a-19 and its dependencies.
Comment 14 Pavel Raiskup 2013-01-29 15:09:36 EST
> Worked fine for me, or am I missing something?
>
> This bug should be fixed by updating to texlive version from bz#879661.

Thanks, this fixes issue for me (if relevant):

  | $ git show 2e16460
  | commit 2e164609f06b2b3b6e740bd4fcc03c9c2daf420d
  |
  |     dvips require latex-fonts (#879661)
Comment 15 Dmitri A. Sergatskov 2013-01-29 22:25:55 EST
I removed .texlive2012 (left over from Fedora 17 + texlive2012 days) and
re-created it by re-running texconfig. That fixed the problem for me.
Comment 16 Jindrich Novy 2013-01-30 01:36:34 EST
Dmitri, thanks. It could actually happen that some formats are created in ~/.texlive2012 which may conflict with the main ones. The installation of texlive couldn't actually handle this as this directory is in an user's home directory.

Note You need to log in before you can comment on or make changes to this bug.