Valgrind-3.10.1 PDF docs don't build (needs recheck)

[christopher]

Hello,

When building the documentation using make download-docs it fails on Making portrait pages on USletter paper (8.5inx11in) with the following error:

Making portrait pages on USletter paper (8.5inx11in) (cd ../docs/valgrind/print/ && \

( pdfxmltex manual.fo && \

pdfxmltex manual.fo && \ pdfxmltex manual.fo ) &> print.log < /dev/null )

Makefile:651: recipe for target 'download-docs' failed make: * [download-docs] Error 127

From reading the README file it shows alternatives to the make download-docs.

For example, make html-docs successfully builds the html documentation but running make print-docs fails with the above error.

This affects both OFFICIAL blfs books.

[christopher]

Replying to cjg:

Hello,

When building the documentation using make download-docs it fails on Making portrait pages on USletter paper (8.5inx11in) with the following error:

Making portrait pages on USletter paper (8.5inx11in) (cd ../docs/valgrind/print/ && \

( pdfxmltex manual.fo && \

pdfxmltex manual.fo && \ pdfxmltex manual.fo ) &> print.log < /dev/null )

Makefile:651: recipe for target 'download-docs' failed make: * [download-docs] Error 127

From reading the README file it shows alternatives to the make download-docs.

For example, make html-docs successfully builds the html documentation but running make print-docs fails with the above error.

Armin will probably lie and say that it works fine for him, but that is not the case so could someone other than Armin please check. It does need to be fixed and I have been unable at this stage to find a solution to it. This affects both OFFICIAL blfs books.

The following is the output of index.log which is in the docs/print directory of the sourcecode:

(/opt/texlive/2014/texmf-dist/tex/context/base/supp-pdf.mkii [Loading MPS to PDF converter (version 2006.09.02).] \scratchcounter=\count140 \scratchdimen=\dimen150 \scratchbox=\box66 \nofMPsegments=\count141 \nofMParguments=\count142 \everyMPshowfont=\toks29 \MPscratchCnt=\count143 \MPscratchDim=\dimen151 \MPnumerator=\count144 \makeMPintoPDFobject=\count145 \everyMPtoPDFconversion=\toks30 ) (/opt/texlive/2014/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty Package: epstopdf-base 2010/02/09 v2.5 Base part for package epstopdf

(/opt/texlive/2014/texmf-dist/tex/latex/oberdiek/grfext.sty Package: grfext 2010/08/19 v1.1 Manage graphics extensions (HO) ) Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4 34.

! Undefined control sequence. <recently read> \AppendGraphicsExtensions

l.451 \fi

? ! Emergency stop. <recently read> \AppendGraphicsExtensions

l.451 \fi

End of file on the terminal! ere is how much of TeX's memory you used:

12419 strings out of 492553 150167 string characters out of 6133183 241967 words of memory out of 5000000 16276 multiletter control sequences out of 15000+600000 8456 words of font info for 23 fonts, out of 8000000 for 9000 1141 hyphenation exceptions out of 8191 51i,0n,34p,22483b,262s stack positions out of 5000i,500n,10000p,200000b,80000s

! ==> Fatal error occurred, no output PDF file produced!

[bdubbs@…]

When I ran make 'download-docs', it did get the error:

(cd ../docs/valgrind/print/ && \
        ( pdfxmltex manual.fo && \
          pdfxmltex manual.fo && \
          pdfxmltex manual.fo ) &> print.log < /dev/null )
Makefile:651: recipe for target 'download-docs' failed

I then tried to run those commands manually:

cd ../docs/valgrind/print/  -- OK
pdfxmltex manual.fo
-bash: pdfxmltex: command not found

Upon investigation, I have pdfxmltex: /opt/texlive.old/2013/bin/x86_64-linux/pdfxmltex, but I don't have it in my current /opt/texlive directory. Do you have that program in your path?

Even if I add the above to my PATH, I still get a failure LaTeX Error: 'File `rotating.sty' not found.' So I think it revolves around the installation of texlive.

[Fernando de Oliveira]

Believe this is an unsolved texlive bug:

​https://bugzilla.redhat.com/show_bug.cgi?id=949087

IMHO, I feel generally superfluous regenerating documents that are already there, worse here, where we have a bug, so, would just remove the instructions.

[bdubbs@…]

OK, let's just comment out these instructions and test when texlive releases a new version, probably next summer. We may want to put his ticket in pending.

[Fernando de Oliveira]

Agree completeley, including the pending part. Due to that problem, would you mind, please, taking this?

[bdubbs@…]

I'll comment it, but leave the ticket owner as book.

[Fernando de Oliveira]

Thank you very much!!!

[ken@…]

Replying to bdubbs@…:

I then tried to run those commands manually:

cd ../docs/valgrind/print/  -- OK
pdfxmltex manual.fo
-bash: pdfxmltex: command not found

Upon investigation, I have pdfxmltex: /opt/texlive.old/2013/bin/x86_64-linux/pdfxmltex, but I don't have it in my current /opt/texlive directory. Do you have that program in your path?

Even if I add the above to my PATH, I still get a failure LaTeX Error: 'File `rotating.sty' not found.' So I think it revolves around the installation of texlive.

On my 7.6 / 2014 system, I do have pdfxmltex my the from-source install. But it still fails. TeX error/warning messages are often misleading. I have the following which might hint at problems but probably do not:

No File: manual.cfg
[...]
WARNING: Elsevier font setup not found
(/opt/texlive/2014/texmf-dist/tex/xmltex/passivetex/dummyels.sty)
WARNING: mmasym package not loaded. some symbols will fail

and then I get

(/opt/texlive/2014/texmf-dist/tex/latex/latexconfig/hyperref.cfg))

Package hyperref Message: Driver (autodetected): hpdftex.

(/opt/texlive/2014/texmf-dist/tex/latex/hyperref/hpdftex.def
(/opt/texlive/2014/texmf-dist/tex/latex/oberdiek/rerunfilecheck.sty)))
No file manual.aux.
(/opt/texlive/2014/texmf-dist/tex/latex/tipa/t3ptm.fd)
(/opt/texlive/2014/texmf-dist/tex/latex/cyrillic/t2acmr.fd)
(/opt/texlive/2014/texmf-dist/tex/latex/base/ts1cmr.fd)
(/opt/texlive/2014/texmf-dist/tex/latex/psnfss/t1ptm.fd)
(/opt/texlive/2014/texmf-dist/tex/context/base/supp-pdf.mkii
[Loading MPS to PDF converter (version 2006.09.02).]
) (/opt/texlive/2014/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty
(/opt/texlive/2014/texmf-dist/tex/latex/oberdiek/grfext.sty)
! Undefined control sequence.
<recently read> \AppendGraphicsExtensions 
                                          
l.451 \fi
         
? 
! Emergency stop.
<recently read> \AppendGraphicsExtensions 
                                          
l.451 \fi
         
!  ==> Fatal error occurred, no output PDF file produced!
Transcript written on manual.log.

and manual.log does not appear to show anything extra about this error.

I've never tried to run this before, nor used valgrind, so I do not know when it last worked.

[ken@…]

I see that this package was added to the book between 7.5 and 7.6.

We released 7.6 with 3.10.0 and texlive-2014, that combination also has the problem.

Our original version was 3.9.0, with its instructions last updated on 16th June. Trac shows me that those instructions matched what we had for 3.10.0. I cannot build 3.9.0 on LFS-7.6, it requires a version of glibc between 2.2 and 2.17 - don't you just love packages which put an upper limit on what they will work with ?

I'm sure that those instructions worked when valgrind 3.9.0 went into the book, but that was with texlive-2013. I'll need to dig out a 7.5 system to try to work out when it broke, in the hope that I can identify where the problem lies. I'd never come across pdfxmltex apart from in this ticket, and 'texdoc pdfxmltex' finds nothing. Ubuntu has a manpage, but it is not detailed enough for *me* to make sense of how to use it. It is part of xmltex, apparently xmlto also uses it to generate its docs.

[ken@…]

Replying to ken@…:

apparently xmlto also uses it to generate its docs.

That seems to be correct, but it still needs dblatex and fop, which makes it a far-from-trivial way of testing if pdfxmltex works at all.

[ken@…]

I now think that pdfxmltex is broken! I eventually found a reference, or rather google did, to the bzip2 xmlproc.sh script (it found it at apple, of all places). If you use that in the form:

$./xmlproc.sh -pdf manual.xml

(preferably after renaming the shipped PDF so that you can compare them if successful) it ought to generate manual.pdf using xsltproc with the supplied xsl files, followed by three runs of pdfxmltex.

When I run that, I get:

Creating manual.pdf ...
Making portrait pages on USletter paper (8.5inx11in)
Cleaning up: output manual.fmt manual.aux manual.fo manual.log *.out
  deleting output
  deleting manual.fmt
  deleting manual.aux
  deleting manual.fo
  deleting manual.log
  deleting *.out
rm: cannot remove ‘*.out’: No such file or directory

and a PDF is NOT created.

[christopher]

Replying to ken@…:

I now think that pdfxmltex is broken! I eventually found a reference, or rather google did, to the bzip2 xmlproc.sh script (it found it at apple, of all places). If you use that in the form:

$./xmlproc.sh -pdf manual.xml

(preferably after renaming the shipped PDF so that you can compare them if successful) it ought to generate manual.pdf using xsltproc with the supplied xsl files, followed by three runs of pdfxmltex.

When I run that, I get:

Creating manual.pdf ...
Making portrait pages on USletter paper (8.5inx11in)
Cleaning up: output manual.fmt manual.aux manual.fo manual.log *.out
  deleting output
  deleting manual.fmt
  deleting manual.aux
  deleting manual.fo
  deleting manual.log
  deleting *.out
rm: cannot remove ‘*.out’: No such file or directory

and a PDF is NOT created.

Hello Ken,

From you saying that you think that pdfxmltex is the problem, I went back into my build directory and into the docs directory and re-read the README file in there and they state the version of pdfxmltex that needs to be used as:

pdfxmltex: pdfeTeX 3.141592-1.21a-2.2 (Web2C 7.5.4)

The newest released version shipped with texlive gives the following output:

This is pdfTeX, Version 3.14159265-2.6-1.40.15 (TeX Live 2014) (preloaded format=pdfxmltex)

This *may* give you a clue if you are going to dig out an older version from your backups.

Regards,

Christopher.

[ken@…]

Replying to cjg:

From you saying that you think that pdfxmltex is the problem, I went back into my build directory and into the docs directory and re-read the README file in there and they state the version of pdfxmltex that needs to be used as:

pdfxmltex: pdfeTeX 3.141592-1.21a-2.2 (Web2C 7.5.4)

The newest released version shipped with texlive gives the following output:

This is pdfTeX, Version 3.14159265-2.6-1.40.15 (TeX Live 2014) (preloaded format=pdfxmltex)

This *may* give you a clue if you are going to dig out an older version from your backups.

Christopher - MANY thanks for that. The README is informative (I had previously found a link where the valgrind developer was asking about moving _from_ PassiveTex because it was apparently broken. Long story short - I've gone back to an LFS-7.4 system because that was the stable LFS version when valgrind came into BLFS. I don't have a 2013 binary (used to, but I discarded it). In theory, the texlive-date-bin tarballs will provide the programs, but the organization is "unusual" in regard to the symlinks. Also, no scripts, so texmf is needed. But I still could not find texmf-var in anything.

So, I've tried building the old versions using LFS-7.4, following the from-source instructions currently in the book, but NOT using system libs except for zlib (mine are newer and will probably break things). I've managed to build back to the 2009 version, 2008 falls over in teckit (my toolchain is too new - c++ scope errors). What I can now say with certainty is that the instructions must have been copied from the documentation, but not tested. I can understand that : why bother to recreate shipped docs ?

In the 2009 version, pdfxmltex reports itself as

pdfTeX 3.1415926-1.40.10-2.2 (Web2C 2009)

So it is still too new. For bzip2, the current release was in 2010, but it was a vulnerability fix - I guess that normal development had already stopped because "it works". There too, the version of pdfxmltex seems to be too new.

With the possible exception of xmlto (#5915) which has its own shed-load of other dependencies, I think that anything using {pdf,}xmltex should be assumed to be broken, and we should just put a comment in valgrind saying that the docs need a REALLY old version of pdfxmltex (and perhaps older versions of libxml etc.).

[bdubbs@…]

Does upstream rebuild the docs for every release? If so can they be asked how they are building them. I do note that the .pdf file for 3.8.1 is a different size than the one for 3.10.1. There is a valgrind-developers mailing list.

[Pierre Labastie]

in ​https://bugzilla.redhat.com/show_bug.cgi?id=949087, there is a workaround, which allows building the valgrind pdf manual. In file /opt/texlive/2014/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty, comment out the following lines around line 450:

%\ifETE@prepend
%  \expandafter\PrependGraphicsExtensions
%\else
%  \expandafter\AppendGraphicsExtensions
%\fi
%{.eps}

But as the reporter says, "I admit to not know what I am doing".

[ken@…]

Replying to pierre.labastie:

in ​https://bugzilla.redhat.com/show_bug.cgi?id=949087, there is a workaround, which allows building the valgrind pdf manual. In file /opt/texlive/2014/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty, comment out the following lines around line 450:

%\ifETE@prepend
%  \expandafter\PrependGraphicsExtensions
%\else
%  \expandafter\AppendGraphicsExtensions
%\fi
%{.eps}

But as the reporter says, "I admit to not know what I am doing".

That sounds highly dangerous, as in "it might break or damage anything else which uses that file". From that bugzilla, I think that the first comment is the key : passivetex upstream is dead.

If that stylesheet is used directly by valgrind, it would be possible (as root) to copy it to a new name and change that version, and then change the invocation in valgrind. More likely, the stylesheet is not invoked directly and a lot more places (the call chain used by valgrind) would need to be changed to get a separate defective (in texlive upstream's terms) version by use with valgrind - and perhaps with xmlto.

I know that people on LTS distros get stuck with old versions of texlive, but a quick google for 'replace passivetex' shows that debian stopped packaging that in 2007. They had a bug for xmlto, suggesting using dblatex ​https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416622 but I've no idea if any of the suggestion in that would help.

But google also found a valgrind thread from 2007: the maintainer keeps a SuSe-10.1 machine purely to build the PDF and html ​http://sourceforge.net/p/valgrind/mailman/message/18726170/. So I don't think there is a lot we can do (short of trying to convert valgrind to use a current system, and offering that to upstream).

[Pierre Labastie]

Replying to ken@…:

Replying to pierre.labastie:

in ​https://bugzilla.redhat.com/show_bug.cgi?id=949087, there is a workaround, which allows building the valgrind pdf manual. In file /opt/texlive/2014/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty, comment out the following lines around line 450:

%\ifETE@prepend
%  \expandafter\PrependGraphicsExtensions
%\else
%  \expandafter\AppendGraphicsExtensions
%\fi
%{.eps}

But as the reporter says, "I admit to not know what I am doing".

That sounds highly dangerous, as in "it might break or damage anything else which uses that file". From that bugzilla, I think that the first comment is the key : passivetex upstream is dead.

Agreed! I just tried a less destructive workaround. In docs/Makefile.in of the valgrind build tree, change the lines:

                ( pdfxmltex manual.fo && \
                  pdfxmltex manual.fo && \
                  pdfxmltex manual.fo ) &> $(LOGFILE) < /dev/null )

to

                ( xmltex manual.fo && \
                  xmltex manual.fo && \
                  xmltex manual.fo && \
                  dvipdfm manual.dvi ) &> $(LOGFILE) < /dev/null )

(needs tab as the first character on the lines). Not easy to make a sed, I guess. Maybe a little patch could be preferred.

[Fernando de Oliveira]

Replying to pierre.labastie:

(needs tab as the first character on the lines). Not easy to make a sed, I guess. Maybe a little patch could be preferred.

Use \t to have tab in sed:

​http://www.linuxfromscratch.org/blfs/view/svn/basicnet/samba.html

sed -e 's/.*set_priority.*/\tgnutls_priority_set_direct(tls->session, "NORMAL:+CTYPE-OPENPGP", NULL);/' \
    -e '/cert_type_priority/d' \
    -i source4/lib/tls/tls.c &&

Following sed also uses \t.

Lines with gnutls_priority_set_direct(tls->session... will start with a tab, IIRC.

One of the things I did in r16049 was exactly replace the spaces by tabs, to conform with the original text, which I had forgotten before.

[ken@…]

Replying to fo:

Following sed also uses \t.

Lines with gnutls_priority_set_direct(tls->session... will start with a tab, IIRC.

One of the things I did in r16049 was exactly replace the spaces by tabs, to conform with the original text, which I had forgotten before.

Not yet tested, but (as a separate sed)

sed -i 's/pdfxmltex/xmltex/g' docs/Makefile.in

does the same thing (I assume we need to change both sets). I must admit, I'd forgotten I ever touched this heap of fetid dingo's kidneys. So presumably add -e for this and the current sed to docs/Makefile.in.

[ken@…]

Replying to ken@…:

Replying to fo:

Following sed also uses \t.

Lines with gnutls_priority_set_direct(tls->session... will start with a tab, IIRC.

One of the things I did in r16049 was exactly replace the spaces by tabs, to conform with the original text, which I had forgotten before.

Not yet tested, but (as a separate sed)

sed -i 's/pdfxmltex/xmltex/g' docs/Makefile.in

does the same thing (I assume we need to change both sets). I must admit, I'd forgotten I ever touched this heap of fetid dingo's kidneys. So presumably add -e for this and the current sed to docs/Makefile.in.

Nope, running

make -C docs/ download-docs

giveslots of what look like error messages in the first part (html?) about redefining something (but it's tex, so maybe not really errors), then in the second part (pdf) it ends

../docs/xml/index.xml:535: element sect2: validity error : ID ms-manual.forkingprograms already defined
../docs/xml/index.xml:14: element sect1: validity error : ID ms-manual.overview already defined
Making portrait pages on USletter paper (8.5inx11in)
(cd ../docs/valgrind/print/ && \
	( xmltex manual.fo && \
	  xmltex manual.fo && \
	  xmltex manual.fo ) &> print.log < /dev/null )
Makefile:651: recipe for target 'download-docs' failed
make: *** [download-docs] Error 1

and in the log files in valgrind/print there are messages about undefined references. If I use dvips on manual.dvi, and then ps2pdf on manual.ps I get a PDF, but it only contains the first part of what is presumably the front page.

[Fernando de Oliveira]

Replying to ken@…:

Not yet tested, but (as a separate sed)

sed -i 's/pdfxmltex/xmltex/g' docs/Makefile.in

does the same thing (I assume we need to change both sets). I must admit, I'd forgotten I ever touched this heap of fetid dingo's kidneys. So presumably add -e for this and the current sed to docs/Makefile.in.

Of course. Sorry, I was just thinking about an eventual necessity of using a tab. In my case, I needed space (was working) or tab, and could not find a simple way to just replace the text leaving the original tab.

About your exact case, I would need to think more.

If you don't find a solution, tomorrow I will try to think about it.

[Fernando de Oliveira]

Correction: s/your exact case/our case in this ticket/

When I try to make fast replies I multiply my mistakes. :-(

[Fernando de Oliveira]

Could create the sed to obtain the Makefile.in described by Pierre. Unfortunately, gives same errors reported by Ken.

BTW, LOL, forgot to say, yesterday, when reading

(Ken wrote:)

I must admit, I'd forgotten I ever touched this heap of fetid dingo's kidneys.

[Pierre Labastie]

Digged a little more into this. The fix above (xmltex instead of pdfxmltex + dvipdfm) works only with the latest version of passivetex: ​http://projects.oucs.ox.ac.uk/passivetex/passivetex.zip That version is ~10 years old, but the version shipped with texlive-20140525 is older!

I had forgotten I had installed this version when trying pdfxmltex...

I do not know whether it is interesting to install it whan building texlive. If you feel so, it can be done as follows: assuming passivetex.zip has been downloaded to the parent directory, and the texmf tarball has already been extracted to /opt/texlive/2014, run as root:

rm -r /opt/texlive/2014/texmf-dist/tex/xmltex/passivetex
unzip -d /opt/texlive/2014/texmf-dist/tex/xmltex ../passivetex.zip

Once you have the new passivetex, the instructions for building valgrind documentation could be:

sed -e 's/pdfxmltex/xmltex/' \
    -e '/index\.fo[^(]*)/s/)/\&\& dvipdfm index.dvi )/' \
    -i docs/Makefile.in
configure [...] && make
make -C docs XSL_MAN_STYLES=/usr/share/xml/docbook/xsl-stylesheets-1.78.1/manpages/docbook.xsl all-docs

Not sure it is worth it. But the change to a more recent passivetex might be interesting.

[bdubbs@…]

I think I'd recommend just adding a note to the texlive section about this and another note to the valgrind page about the requirement in texlive and the procedures to build the pdf.

I really rather doubt that many users will actually want to rebuild this pdf, but it doesn't hurt to document it.

[ken@…]

Replying to bdubbs@…:

I think I'd recommend just adding a note to the texlive section about this and another note to the valgrind page about the requirement in texlive and the procedures to build the pdf.

I really rather doubt that many users will actually want to rebuild this pdf, but it doesn't hurt to document it.

I would prefer to see it on a separate page - it is an example of how to upgrade files within texlive. I would certainly find it educational. Also, valgrind could then link to it directly.

[bdubbs@…]

That's a good idea. Do you want to tackle it? You've been doing all the texlive pages recently.

[ken@…]

Replying to bdubbs@…:

That's a good idea. Do you want to tackle it? You've been doing all the texlive pages recently.

I would prefer to leave it to somebody who understands it. I'm still a novice in TeX-derivatives, and once I've done my outstanding tickets I'll be building one or more systems without any TeX, to get ready for TL-2015.

[bdubbs@…]

We updated to TL at the end of June. Does that fix this issue?

[ken@…]

Pierre is the expert on passivetex. Can the passivetex.zip files be installed to an installed texlive without rebuilding it ? Or perhaps with 'maketexlsr'.

That was my initial impression, but I'm uncertain. If that is possible, I still suggest adding passivetex to the typesetting chapter, dependent on the binary or the source versions of texlive. And making valgrind link to it.

But I do not have any cycles for this.

[bdubbs@…]

This ticket has been here way too long. The package ships with ./docs/index.pdf

I think we should either say that regenerating the docs requires a custom TeX package or just ignore trying to regen the docs.

Then close this ticket. I'll do it if we cna get agreement.

[Douglas R. Reno]

I agree that it has been here for too long. There really is no need to regenerate the documentation in this case if it is already provided, as Bruce said. I vote for saying that regenerating the docs required a Custom TeX package.

[Fernando de Oliveira]

Replying to bdubbs@…:

This ticket has been here way too long.

Agreed.

[Pierre Labastie]

Replying to ken@…:

Pierre is the expert on passivetex.

Very honoured, but not sure it is true...

Can the passivetex.zip files be installed to an installed texlive without rebuilding it ? Or perhaps with 'maketexlsr'.

A more recent version of passivetex (has it been included in TeXLive 2015?) may be installed, but if the only use is to build valgrind doc, which is already shipped within valgrind tarball, I doubt it is worth it.

I suggest closing the ticket as wontfix.

[Fernando de Oliveira]

I agree with wontfix.

I am taking the liberty of doing it, after everybody seems to agree.

[bdubbs@…]

Milestone renamed

[Bruce Dubbs]

Milestone renamed