linux-kernel - Re: [PATCH RFC 0/4] Fix PDF build errors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 2 Nov 2016 10:47:34 -0600
From:   Mauro Carvalho Chehab <mchehab@...radead.org>
To:     Markus Heiser <markus.heiser@...marit.de>
Cc:     Jani Nikula <jani.nikula@...ux.intel.com>,
        Jonathan Corbet <corbet@....net>,
        Mauro Carvalho Chehab <mchehab@....samsung.com>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        Jim Davis <jim.epost@...il.com>,
        linux-kernel List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC 0/4] Fix PDF build errors

Em Wed, 2 Nov 2016 17:08:08 +0100
Markus Heiser <markus.heiser@...marit.de> escreveu:

> Am 02.11.2016 um 12:14 schrieb Jani Nikula <jani.nikula@...ux.intel.com>:
> 
> > On Wed, 02 Nov 2016, Mauro Carvalho Chehab <mchehab@....samsung.com> wrote:  
> >> This series address a series of errors during PDF generation from
> >> media documentation.
> >> 
> >> Please notice that patch 2 carries on a PDF conversion from a PNG
> >> image, because Sphinx is not smart enough to do the convertion.
> >> 
> >> This is a temporary solution (That's why I'm marking this series
> >> as RFC).  
> > 
> > This seems to work on top of docs-next.
> > 
> > ...but it'll break again if we include the missing admin-guide in the
> > build. :(
> > Sadly, this breaks the pdf build with:
> > 
> > ! TeX capacity exceeded, sorry [main memory size=5000000].
> > \FV@...ce ...ionary {\copy \sphinxvisiblespacebox
> > }{\sphinxafterbreak } {\ke...
> > l.3711 ...\PYG{n}{be} \PYG{n}{used} \PYG{n+nb}{to}
> > or 2  
> 
> 
> This is the verbatim block of the kernel parameters with more
> than 4300 lines in.
> 
> IMO, Verbatim exceeded, because in sphinx.sty is a redefinition
> of the LaTeX Verbatim command which might be sloppy / see 
> sphinx.sty::
> 
>  \renewcommand{\Verbatim}[1][1]{%
>    ....

Argh! I really hate those ugly hacks that Sphinx do for LaTeX output...

Btw, I remember I had to touch on a TeXLive style in order to workaround
the memory size when testing LaTeX output for some book, but it ended by
causing some other issues.
 
> 
> The renew-Verbatim has been removed later:
> 
>  https://github.com/sphinx-doc/sphinx/commit/f9880bfcc8b19a7d197badeb6ab412abfca19891
> 
> I my POC I use such a modified sphinx.sty
> 
>  https://github.com/return42/sphkerneldoc/blob/master/_tex/sphinx.sty
> 
> with it, the PDF is build:
> 
> https://h2626237.stratoserver.net/kernel/books/admin-guide/pdf/linux-user.pdf
> 
> Using modified sphinx.sty has the drawback, that it is not
> up- or downward compatible to the installed Sphinx version.
> 
> So in short, I think it is the best to come back to the reasons
> and just split kernel parameters in several blocks and using the 
> 'none' option to prevent rendering as C .. E.g:
> 
> .. code-block:: none

I'm staring to think that we should just redefine the default for ::
to be "none", and use the "C" handling **only** when explicitly
requested.

I remember that Jon did such suggestion sometime ago.

If we change it to "none", it will still spend lots of memory for
verbatim?


Cheers,
Mauro