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:
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.
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!
After source investigation it is apparent that texinfo-tex sources realy requires epsf.tex so I added the build requirement and release update.
texinfo-4.13a-18.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/texinfo-4.13a-18.fc18
I see something similar with my f18 builds: bug #877691 but adding the BuildRequires: tex(epsf.tex) trick doesn't seem to fix it.
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
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
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.
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
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
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.
(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.
(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.
> 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)
I removed .texlive2012 (left over from Fedora 17 + texlive2012 days) and re-created it by re-running texconfig. That fixed the problem for me.
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.