Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1668678 > unrolled thread

[PATCH 0/5] Make PDF builds work again

Started byJonathan Corbet <corbet@lwn.net>
First post2017-06-19 01:50 +0200
Last post2017-06-19 16:50 +0200
Articles 11 — 2 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/5] Make PDF builds work again Jonathan Corbet <corbet@lwn.net> - 2017-06-19 01:50 +0200
    [PATCH 1/5] Docs: Include the Latex "ifthen" package Jonathan Corbet <corbet@lwn.net> - 2017-06-19 01:50 +0200
    [PATCH 4/5] Docs: Use kernel-figure in vidioc-g-selection.rst Jonathan Corbet <corbet@lwn.net> - 2017-06-19 01:50 +0200
    [PATCH 2/5] Docs: Remove redundant geometry package inclusion Jonathan Corbet <corbet@lwn.net> - 2017-06-19 01:50 +0200
      Re: [PATCH 2/5] Docs: Remove redundant geometry package inclusion Mauro Carvalho Chehab <mchehab@s-opensource.com> - 2017-06-19 12:40 +0200
        Re: [PATCH 2/5] Docs: Remove redundant geometry package inclusion Mauro Carvalho Chehab <mchehab@s-opensource.com> - 2017-06-19 12:50 +0200
    [PATCH 5/5] DRM: Fix an incorrectly formatted table Jonathan Corbet <corbet@lwn.net> - 2017-06-19 01:50 +0200
    Re: [PATCH 0/5] Make PDF builds work again Jonathan Corbet <corbet@lwn.net> - 2017-06-19 01:50 +0200
    [PATCH 3/5] Docs: fix table problems in ras.rst Jonathan Corbet <corbet@lwn.net> - 2017-06-19 01:50 +0200
    Re: [PATCH 0/5] Make PDF builds work again Mauro Carvalho Chehab <mchehab@s-opensource.com> - 2017-06-19 03:20 +0200
      Re: [PATCH 0/5] Make PDF builds work again Mauro Carvalho Chehab <mchehab@s-opensource.com> - 2017-06-19 16:50 +0200

#1668678 — [PATCH 0/5] Make PDF builds work again

FromJonathan Corbet <corbet@lwn.net>
Date2017-06-19 01:50 +0200
Subject[PATCH 0/5] Make PDF builds work again
Message-ID<tTS78-3fw-1@gated-at.bofh.it>
I've just spent rather more time than I would like figuring out why the PDF
builds fail and what was needed to fix it.  The result is the following
patch series.  It's a combination of little mistakes and fragility in the
whole PDF build tool chain.

Mauro, Daniel: Do you want the last two?  Or otherwise give me acks?  I'd
like to send the set Linusward forthwith so that 4.12 can come out with
a working PDF build.

In general, I'm dismayed by the fragility of the whole thing.  I'm also a
little concerned that nobody except Jim complained about the problem.
Perhaps nobody really cares about PDF output anymore?  In the absence of a
concerted effort on somebody's part, I predict that PDF building will be
broken much of the time.  I have to wonder if it's worth it...

Jonathan Corbet (5):
  Docs: Include the Latex "ifthen" package
  Docs: Remove redundant geometry package inclusion
  Docs: fix table problems in ras.rst
  Docs: Use kernel-figure in vidioc-g-selection.rst
  DRM: Fix an incorrectly formatted table

 Documentation/admin-guide/ras.rst                  | 10 ++--
 Documentation/conf.py                              |  3 +-
 .../media/uapi/v4l/vidioc-g-selection.rst          |  4 +-
 include/drm/bridge/dw_hdmi.h                       | 70 +++++++++++-----------
 4 files changed, 43 insertions(+), 44 deletions(-)

-- 
2.13.1

[toc] | [next] | [standalone]

#1668679 — [PATCH 1/5] Docs: Include the Latex "ifthen" package

FromJonathan Corbet <corbet@lwn.net>
Date2017-06-19 01:50 +0200
Subject[PATCH 1/5] Docs: Include the Latex "ifthen" package
Message-ID<tTS78-3fw-5@gated-at.bofh.it>
In reply to#1668678
Otherwise we get PDF build failures when LaTeX refused to acknowledge the
existence of \ifthenelse

Fixes: 41cff161fe99d1c6a773becc2250a1dc3ac035ff
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
 Documentation/conf.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/conf.py b/Documentation/conf.py
index bacf9d337c89..93827bc1620f 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -273,6 +273,7 @@ latex_elements = {
     'preamble': '''
 	% Adjust margins
 	\\usepackage[margin=0.5in, top=1in, bottom=1in]{geometry}
+        \\usepackage{ifthen}
 
         % Allow generate some pages in landscape
         \\usepackage{lscape}
-- 
2.13.1

[toc] | [prev] | [next] | [standalone]

#1668680 — [PATCH 4/5] Docs: Use kernel-figure in vidioc-g-selection.rst

FromJonathan Corbet <corbet@lwn.net>
Date2017-06-19 01:50 +0200
Subject[PATCH 4/5] Docs: Use kernel-figure in vidioc-g-selection.rst
Message-ID<tTS78-3fw-7@gated-at.bofh.it>
In reply to#1668678
...otherwise the PDF build fails when it can't find constraints.pdf.

CC: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
 Documentation/media/uapi/v4l/vidioc-g-selection.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/media/uapi/v4l/vidioc-g-selection.rst b/Documentation/media/uapi/v4l/vidioc-g-selection.rst
index deb1f6fb473b..b80d85cb8891 100644
--- a/Documentation/media/uapi/v4l/vidioc-g-selection.rst
+++ b/Documentation/media/uapi/v4l/vidioc-g-selection.rst
@@ -129,8 +129,8 @@ Selection targets and flags are documented in
 
 .. _sel-const-adjust:
 
-.. figure::  constraints.*
-    :alt:    constraints.pdf / constraints.svg
+.. kernel-figure::  constraints.svg
+    :alt:    constraints.svg
     :align:  center
 
     Size adjustments with constraint flags.
-- 
2.13.1

[toc] | [prev] | [next] | [standalone]

#1668681 — [PATCH 2/5] Docs: Remove redundant geometry package inclusion

FromJonathan Corbet <corbet@lwn.net>
Date2017-06-19 01:50 +0200
Subject[PATCH 2/5] Docs: Remove redundant geometry package inclusion
Message-ID<tTS78-3fw-11@gated-at.bofh.it>
In reply to#1668678
Commit 85c21e5c3ee7 (docs-rst: better adjust margins and font size) added a
\usepackage{geometry} that conflicts with another inclusion deep within the
dependencies somewhere, causing the the PDF build to fail with a
"conflicting parameters" error.  Just remove it for now until we can figure
out a better way.

Fixes: 85c21e5c3ee74fb75d690c57f7066bae7e2dca55
Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
 Documentation/conf.py | 2 --
 1 file changed, 2 deletions(-)

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 93827bc1620f..3d4e89330044 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -271,8 +271,6 @@ latex_elements = {
 
 # Additional stuff for the LaTeX preamble.
     'preamble': '''
-	% Adjust margins
-	\\usepackage[margin=0.5in, top=1in, bottom=1in]{geometry}
         \\usepackage{ifthen}
 
         % Allow generate some pages in landscape
-- 
2.13.1

[toc] | [prev] | [next] | [standalone]

#1668990 — Re: [PATCH 2/5] Docs: Remove redundant geometry package inclusion

FromMauro Carvalho Chehab <mchehab@s-opensource.com>
Date2017-06-19 12:40 +0200
SubjectRe: [PATCH 2/5] Docs: Remove redundant geometry package inclusion
Message-ID<tU2ga-1qR-17@gated-at.bofh.it>
In reply to#1668681
Em Sun, 18 Jun 2017 17:46:27 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:

> Commit 85c21e5c3ee7 (docs-rst: better adjust margins and font size) added a
> \usepackage{geometry} that conflicts with another inclusion deep within the
> dependencies somewhere, causing the the PDF build to fail with a
> "conflicting parameters" error.  Just remove it for now until we can figure
> out a better way.
> 
> Fixes: 85c21e5c3ee74fb75d690c57f7066bae7e2dca55
> Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
> ---
>  Documentation/conf.py | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/Documentation/conf.py b/Documentation/conf.py
> index 93827bc1620f..3d4e89330044 100644
> --- a/Documentation/conf.py
> +++ b/Documentation/conf.py
> @@ -271,8 +271,6 @@ latex_elements = {
>  
>  # Additional stuff for the LaTeX preamble.
>      'preamble': '''
> -	% Adjust margins
> -	\\usepackage[margin=0.5in, top=1in, bottom=1in]{geometry}
>          \\usepackage{ifthen}

This patch has a bad side effect: with it, the tables with this tag:
	.. tabularcolumns::

become too big, violating the right margin. If Sphinx 1.5.x or
1.6.x replaced geometry package with something else, then I
guess we'll need to add some hack at conf.py for it to adjust
it based on the Sphinx version.

Btw, in order to build latex output here with Sphinx 1.6.x,
I had to install this package:

	texlive-fncychap.noarch

Perhaps the change is somehow related to it.

Btw, the current documentation at:
	http://www.sphinx-doc.org/en/stable/latex.html

added a new option for version 1.5.3 and upper, to setup the
geometry, using 'sphinxsetup'. As described there:

	'sphinxsetup': 'hmargin={2in,1.5in}, vmargin={1.5in,2in}, marginpar=1in',

I'll play with it and see if I can use it on such versions.

Thanks,
Mauro

[toc] | [prev] | [next] | [standalone]

#1668993 — Re: [PATCH 2/5] Docs: Remove redundant geometry package inclusion

FromMauro Carvalho Chehab <mchehab@s-opensource.com>
Date2017-06-19 12:50 +0200
SubjectRe: [PATCH 2/5] Docs: Remove redundant geometry package inclusion
Message-ID<tU2pQ-1ul-7@gated-at.bofh.it>
In reply to#1668990
Em Mon, 19 Jun 2017 07:30:38 -0300
Mauro Carvalho Chehab <mchehab@s-opensource.com> escreveu:

> Em Sun, 18 Jun 2017 17:46:27 -0600
> Jonathan Corbet <corbet@lwn.net> escreveu:
> 
> > Commit 85c21e5c3ee7 (docs-rst: better adjust margins and font size) added a
> > \usepackage{geometry} that conflicts with another inclusion deep within the
> > dependencies somewhere, causing the the PDF build to fail with a
> > "conflicting parameters" error.  Just remove it for now until we can figure
> > out a better way.
> > 
> > Fixes: 85c21e5c3ee74fb75d690c57f7066bae7e2dca55
> > Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> > Signed-off-by: Jonathan Corbet <corbet@lwn.net>
> > ---
> >  Documentation/conf.py | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/Documentation/conf.py b/Documentation/conf.py
> > index 93827bc1620f..3d4e89330044 100644
> > --- a/Documentation/conf.py
> > +++ b/Documentation/conf.py
> > @@ -271,8 +271,6 @@ latex_elements = {
> >  
> >  # Additional stuff for the LaTeX preamble.
> >      'preamble': '''
> > -	% Adjust margins
> > -	\\usepackage[margin=0.5in, top=1in, bottom=1in]{geometry}
> >          \\usepackage{ifthen}  
> 
> This patch has a bad side effect: with it, the tables with this tag:
> 	.. tabularcolumns::
> 
> become too big, violating the right margin. If Sphinx 1.5.x or
> 1.6.x replaced geometry package with something else, then I
> guess we'll need to add some hack at conf.py for it to adjust
> it based on the Sphinx version.
> 
> Btw, in order to build latex output here with Sphinx 1.6.x,
> I had to install this package:
> 
> 	texlive-fncychap.noarch
> 
> Perhaps the change is somehow related to it.
> 
> Btw, the current documentation at:
> 	http://www.sphinx-doc.org/en/stable/latex.html
> 
> added a new option for version 1.5.3 and upper, to setup the
> geometry, using 'sphinxsetup'. As described there:
> 
> 	'sphinxsetup': 'hmargin={2in,1.5in}, vmargin={1.5in,2in}, marginpar=1in',
> 
> I'll play with it and see if I can use it on such versions.

I guess the right fix would be do to something similar to what's in
the patch below.

There's a catch, though: as sphinxsetup hmargin/vmargin was added
only on Sphinx version 1.5.3, the enclosed patch won't adjust the
margins for versions 1.5.0 to 1.5.2. While I didn't test, I bet it
will just ignore the keys, showing some warning.


[PATCH] Docs: Fix breakage with Sphinx 1.5 and upper
    
Commit 85c21e5c3ee7 (docs-rst: better adjust margins and font size) added a
\usepackage{geometry} that conflicts with another inclusion deep within the
dependencies with newer versions of Sphinx, causing the the PDF build to fail
with a "conflicting parameters" error.
    
Detect the Sphinx version, using sphinxsetup for Sphinx versions 1.5 and
upper.
    
Fixes: 85c21e5c3ee74fb75d690c57f7066bae7e2dca55
Sighed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 9eff2c8f7f67..900b9cfea430 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -271,8 +271,6 @@ latex_elements = {
 
 # Additional stuff for the LaTeX preamble.
     'preamble': '''
-	% Adjust margins
-	\\usepackage[margin=0.5in, top=1in, bottom=1in]{geometry}
         \\usepackage{ifthen}
 
         % Allow generate some pages in landscape
@@ -343,6 +341,12 @@ latex_elements = {
 if major == 1 and minor > 3:
     latex_elements['preamble']  += '\\renewcommand*{\\DUrole}[2]{ #2 }\n'
 
+if major == 1 and minor < 5:
+    latex_elements['preamble']  += '\\usepackage[margin=0.5in, top=1in, bottom=1in]{geometry}'
+else:
+    latex_elements['sphinxsetup'] = 'hmargin=0.5in, vmargin=0.5in'
+
+
 # Grouping the document tree into LaTeX files. List of tuples
 # (source start file, target name, title,
 #  author, documentclass [howto, manual, or own class]).

[toc] | [prev] | [next] | [standalone]

#1668682 — [PATCH 5/5] DRM: Fix an incorrectly formatted table

FromJonathan Corbet <corbet@lwn.net>
Date2017-06-19 01:50 +0200
Subject[PATCH 5/5] DRM: Fix an incorrectly formatted table
Message-ID<tTS78-3fw-13@gated-at.bofh.it>
In reply to#1668678
The "supported input formats" table in dw_hdmi.h was incorrectly formatted,
using "+" signs where "|" needs to be.  That, in turn, causes the PDF build
to fail.

Fixes: def23aa7e9821a3dfe3fb7b139dd0229a89fdeb0
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
 include/drm/bridge/dw_hdmi.h | 70 ++++++++++++++++++++++----------------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index ed599bea3f6c..c00671fef53c 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -22,56 +22,56 @@ struct dw_hdmi;
  * 48bit bus.
  *
  * +----------------------+----------------------------------+------------------------------+
- * + Format Name          + Format Code                      + Encodings                    +
+ * | Format Name          | Format Code                      | Encodings                    |
  * +----------------------+----------------------------------+------------------------------+
- * + RGB 4:4:4 8bit       + ``MEDIA_BUS_FMT_RGB888_1X24``    + ``V4L2_YCBCR_ENC_DEFAULT``   +
+ * | RGB 4:4:4 8bit       | ``MEDIA_BUS_FMT_RGB888_1X24``    | ``V4L2_YCBCR_ENC_DEFAULT``   |
  * +----------------------+----------------------------------+------------------------------+
- * + RGB 4:4:4 10bits     + ``MEDIA_BUS_FMT_RGB101010_1X30`` + ``V4L2_YCBCR_ENC_DEFAULT``   +
+ * | RGB 4:4:4 10bits     | ``MEDIA_BUS_FMT_RGB101010_1X30`` | ``V4L2_YCBCR_ENC_DEFAULT``   |
  * +----------------------+----------------------------------+------------------------------+
- * + RGB 4:4:4 12bits     + ``MEDIA_BUS_FMT_RGB121212_1X36`` + ``V4L2_YCBCR_ENC_DEFAULT``   +
+ * | RGB 4:4:4 12bits     | ``MEDIA_BUS_FMT_RGB121212_1X36`` | ``V4L2_YCBCR_ENC_DEFAULT``   |
  * +----------------------+----------------------------------+------------------------------+
- * + RGB 4:4:4 16bits     + ``MEDIA_BUS_FMT_RGB161616_1X48`` + ``V4L2_YCBCR_ENC_DEFAULT``   +
+ * | RGB 4:4:4 16bits     | ``MEDIA_BUS_FMT_RGB161616_1X48`` | ``V4L2_YCBCR_ENC_DEFAULT``   |
  * +----------------------+----------------------------------+------------------------------+
- * + YCbCr 4:4:4 8bit     + ``MEDIA_BUS_FMT_YUV8_1X24``      + ``V4L2_YCBCR_ENC_601``       +
- * +                      +                                  + or ``V4L2_YCBCR_ENC_709``    +
- * +                      +                                  + or ``V4L2_YCBCR_ENC_XV601``  +
- * +                      +                                  + or ``V4L2_YCBCR_ENC_XV709``  +
+ * | YCbCr 4:4:4 8bit     | ``MEDIA_BUS_FMT_YUV8_1X24``      | ``V4L2_YCBCR_ENC_601``       |
+ * |                      |                                  | or ``V4L2_YCBCR_ENC_709``    |
+ * |                      |                                  | or ``V4L2_YCBCR_ENC_XV601``  |
+ * |                      |                                  | or ``V4L2_YCBCR_ENC_XV709``  |
  * +----------------------+----------------------------------+------------------------------+
- * + YCbCr 4:4:4 10bits   + ``MEDIA_BUS_FMT_YUV10_1X30``     + ``V4L2_YCBCR_ENC_601``       +
- * +                      +                                  + or ``V4L2_YCBCR_ENC_709``    +
- * +                      +                                  + or ``V4L2_YCBCR_ENC_XV601``  +
- * +                      +                                  + or ``V4L2_YCBCR_ENC_XV709``  +
+ * | YCbCr 4:4:4 10bits   | ``MEDIA_BUS_FMT_YUV10_1X30``     | ``V4L2_YCBCR_ENC_601``       |
+ * |                      |                                  | or ``V4L2_YCBCR_ENC_709``    |
+ * |                      |                                  | or ``V4L2_YCBCR_ENC_XV601``  |
+ * |                      |                                  | or ``V4L2_YCBCR_ENC_XV709``  |
  * +----------------------+----------------------------------+------------------------------+
- * + YCbCr 4:4:4 12bits   + ``MEDIA_BUS_FMT_YUV12_1X36``     + ``V4L2_YCBCR_ENC_601``       +
- * +                      +                                  + or ``V4L2_YCBCR_ENC_709``    +
- * +                      +                                  + or ``V4L2_YCBCR_ENC_XV601``  +
- * +                      +                                  + or ``V4L2_YCBCR_ENC_XV709``  +
+ * | YCbCr 4:4:4 12bits   | ``MEDIA_BUS_FMT_YUV12_1X36``     | ``V4L2_YCBCR_ENC_601``       |
+ * |                      |                                  | or ``V4L2_YCBCR_ENC_709``    |
+ * |                      |                                  | or ``V4L2_YCBCR_ENC_XV601``  |
+ * |                      |                                  | or ``V4L2_YCBCR_ENC_XV709``  |
  * +----------------------+----------------------------------+------------------------------+
- * + YCbCr 4:4:4 16bits   + ``MEDIA_BUS_FMT_YUV16_1X48``     + ``V4L2_YCBCR_ENC_601``       +
- * +                      +                                  + or ``V4L2_YCBCR_ENC_709``    +
- * +                      +                                  + or ``V4L2_YCBCR_ENC_XV601``  +
- * +                      +                                  + or ``V4L2_YCBCR_ENC_XV709``  +
+ * | YCbCr 4:4:4 16bits   | ``MEDIA_BUS_FMT_YUV16_1X48``     | ``V4L2_YCBCR_ENC_601``       |
+ * |                      |                                  | or ``V4L2_YCBCR_ENC_709``    |
+ * |                      |                                  | or ``V4L2_YCBCR_ENC_XV601``  |
+ * |                      |                                  | or ``V4L2_YCBCR_ENC_XV709``  |
  * +----------------------+----------------------------------+------------------------------+
- * + YCbCr 4:2:2 8bit     + ``MEDIA_BUS_FMT_UYVY8_1X16``     + ``V4L2_YCBCR_ENC_601``       +
- * +                      +                                  + or ``V4L2_YCBCR_ENC_709``    +
+ * | YCbCr 4:2:2 8bit     | ``MEDIA_BUS_FMT_UYVY8_1X16``     | ``V4L2_YCBCR_ENC_601``       |
+ * |                      |                                  | or ``V4L2_YCBCR_ENC_709``    |
  * +----------------------+----------------------------------+------------------------------+
- * + YCbCr 4:2:2 10bits   + ``MEDIA_BUS_FMT_UYVY10_1X20``    + ``V4L2_YCBCR_ENC_601``       +
- * +                      +                                  + or ``V4L2_YCBCR_ENC_709``    +
+ * | YCbCr 4:2:2 10bits   | ``MEDIA_BUS_FMT_UYVY10_1X20``    | ``V4L2_YCBCR_ENC_601``       |
+ * |                      |                                  | or ``V4L2_YCBCR_ENC_709``    |
  * +----------------------+----------------------------------+------------------------------+
- * + YCbCr 4:2:2 12bits   + ``MEDIA_BUS_FMT_UYVY12_1X24``    + ``V4L2_YCBCR_ENC_601``       +
- * +                      +                                  + or ``V4L2_YCBCR_ENC_709``    +
+ * | YCbCr 4:2:2 12bits   | ``MEDIA_BUS_FMT_UYVY12_1X24``    | ``V4L2_YCBCR_ENC_601``       |
+ * |                      |                                  | or ``V4L2_YCBCR_ENC_709``    |
  * +----------------------+----------------------------------+------------------------------+
- * + YCbCr 4:2:0 8bit     + ``MEDIA_BUS_FMT_UYYVYY8_0_5X24`` + ``V4L2_YCBCR_ENC_601``       +
- * +                      +                                  + or ``V4L2_YCBCR_ENC_709``    +
+ * | YCbCr 4:2:0 8bit     | ``MEDIA_BUS_FMT_UYYVYY8_0_5X24`` | ``V4L2_YCBCR_ENC_601``       |
+ * |                      |                                  | or ``V4L2_YCBCR_ENC_709``    |
  * +----------------------+----------------------------------+------------------------------+
- * + YCbCr 4:2:0 10bits   + ``MEDIA_BUS_FMT_UYYVYY10_0_5X30``+ ``V4L2_YCBCR_ENC_601``       +
- * +                      +                                  + or ``V4L2_YCBCR_ENC_709``    +
+ * | YCbCr 4:2:0 10bits   | ``MEDIA_BUS_FMT_UYYVYY10_0_5X30``| ``V4L2_YCBCR_ENC_601``       |
+ * |                      |                                  | or ``V4L2_YCBCR_ENC_709``    |
  * +----------------------+----------------------------------+------------------------------+
- * + YCbCr 4:2:0 12bits   + ``MEDIA_BUS_FMT_UYYVYY12_0_5X36``+ ``V4L2_YCBCR_ENC_601``       +
- * +                      +                                  + or ``V4L2_YCBCR_ENC_709``    +
+ * | YCbCr 4:2:0 12bits   | ``MEDIA_BUS_FMT_UYYVYY12_0_5X36``| ``V4L2_YCBCR_ENC_601``       |
+ * |                      |                                  | or ``V4L2_YCBCR_ENC_709``    |
  * +----------------------+----------------------------------+------------------------------+
- * + YCbCr 4:2:0 16bits   + ``MEDIA_BUS_FMT_UYYVYY16_0_5X48``+ ``V4L2_YCBCR_ENC_601``       +
- * +                      +                                  + or ``V4L2_YCBCR_ENC_709``    +
+ * | YCbCr 4:2:0 16bits   | ``MEDIA_BUS_FMT_UYYVYY16_0_5X48``| ``V4L2_YCBCR_ENC_601``       |
+ * |                      |                                  | or ``V4L2_YCBCR_ENC_709``    |
  * +----------------------+----------------------------------+------------------------------+
  */
 
-- 
2.13.1

[toc] | [prev] | [next] | [standalone]

#1668683

FromJonathan Corbet <corbet@lwn.net>
Date2017-06-19 01:50 +0200
Message-ID<tTS78-3fw-15@gated-at.bofh.it>
In reply to#1668678
On Sun, 18 Jun 2017 17:46:25 -0600
Jonathan Corbet <corbet@lwn.net> wrote:

> In general, I'm dismayed by the fragility of the whole thing.  I'm also a
> little concerned that nobody except Jim complained about the problem.

Jim, I just realized I neglected Reported-by tags for you on these
patches; I'll fix that before they go upstream.

jon

[toc] | [prev] | [next] | [standalone]

#1668684 — [PATCH 3/5] Docs: fix table problems in ras.rst

FromJonathan Corbet <corbet@lwn.net>
Date2017-06-19 01:50 +0200
Subject[PATCH 3/5] Docs: fix table problems in ras.rst
Message-ID<tTS78-3fw-9@gated-at.bofh.it>
In reply to#1668678
Two table problems caused the PDF build to fail:

 - Evidently multirow cells are not appreciated in table headers,
   so remove such from the "CS Rows" table.

 - The logging message structure table was incorrectly formatted,
   with two "+" instead of "|".  The HTML build is forgiving of such
   things, but PDF is not.

Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
 Documentation/admin-guide/ras.rst | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/admin-guide/ras.rst b/Documentation/admin-guide/ras.rst
index 8c7bbf2c88d2..197896718f81 100644
--- a/Documentation/admin-guide/ras.rst
+++ b/Documentation/admin-guide/ras.rst
@@ -344,9 +344,9 @@ for more than 2 channels, like Fully Buffered DIMMs (FB-DIMMs) memory
 controllers. The following example will assume 2 channels:
 
 	+------------+-----------------------+
-	| Chip       |       Channels        |
-	| Select     +-----------+-----------+
-	| rows       |  ``ch0``  |  ``ch1``  |
+	| CS Rows    |       Channels        |
+	+------------+-----------+-----------+
+	|            |  ``ch0``  |  ``ch1``  |
 	+============+===========+===========+
 	| ``csrow0`` |  DIMM_A0  |  DIMM_B0  |
 	+------------+           |           |
@@ -698,7 +698,7 @@ information indicating that errors have been detected::
 The structure of the message is:
 
 	+---------------------------------------+-------------+
-	| Content                               + Example     |
+	| Content                               | Example     |
 	+=======================================+=============+
 	| The memory controller                 | MC0         |
 	+---------------------------------------+-------------+
@@ -713,7 +713,7 @@ The structure of the message is:
 	+---------------------------------------+-------------+
 	| The error syndrome                    | 0xb741      |
 	+---------------------------------------+-------------+
-	| Memory row                            | row 0       +
+	| Memory row                            | row 0       |
 	+---------------------------------------+-------------+
 	| Memory channel                        | channel 1   |
 	+---------------------------------------+-------------+
-- 
2.13.1

[toc] | [prev] | [next] | [standalone]

#1668696

FromMauro Carvalho Chehab <mchehab@s-opensource.com>
Date2017-06-19 03:20 +0200
Message-ID<tTTwd-4hF-3@gated-at.bofh.it>
In reply to#1668678
Hi Jon,

Em Sun, 18 Jun 2017 17:46:25 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:

> I've just spent rather more time than I would like figuring out why the PDF
> builds fail and what was needed to fix it.  The result is the following
> patch series.  It's a combination of little mistakes and fragility in the
> whole PDF build tool chain.

Yeah, the PDF toolchain is very fragile. Yet, I'm pretty sure I was able
to build PDF in the past without noticing the problems fixed by patches
1 and 2. Maybe the bugs has to do with some specific incompatibility with
toolchain versions.

What Sphinx version are you using?

It is too late now, but tomorrow I'll test with a few Spinx versions
and see if PDF builds equally well with them.

> 
> Mauro, Daniel: Do you want the last two?  Or otherwise give me acks?  I'd
> like to send the set Linusward forthwith so that 4.12 can come out with
> a working PDF build.

For the media and EDAC changes (patches 3 and 4), once I test it,
feel free to add my ack and send via your tree:

Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

> 
> In general, I'm dismayed by the fragility of the whole thing.  I'm also a
> little concerned that nobody except Jim complained about the problem.

Actually, despite any "errors", usually it produces the PDF files.
I have a robot building just the media documentation, daily basis,
from media development tree, at:
	https://linuxtv.org/downloads/v4l-dvb-apis-new/media.pdf

The robot is using Sphinx 1.4.8 version.
	
> Perhaps nobody really cares about PDF output anymore?  In the absence of a
> concerted effort on somebody's part, I predict that PDF building will be
> broken much of the time.  I have to wonder if it's worth it...
> 
> Jonathan Corbet (5):
>   Docs: Include the Latex "ifthen" package
>   Docs: Remove redundant geometry package inclusion
>   Docs: fix table problems in ras.rst
>   Docs: Use kernel-figure in vidioc-g-selection.rst
>   DRM: Fix an incorrectly formatted table
> 
>  Documentation/admin-guide/ras.rst                  | 10 ++--
>  Documentation/conf.py                              |  3 +-
>  .../media/uapi/v4l/vidioc-g-selection.rst          |  4 +-
>  include/drm/bridge/dw_hdmi.h                       | 70 +++++++++++-----------
>  4 files changed, 43 insertions(+), 44 deletions(-)
> 



Thanks,
Mauro

[toc] | [prev] | [next] | [standalone]

#1669137

FromMauro Carvalho Chehab <mchehab@s-opensource.com>
Date2017-06-19 16:50 +0200
Message-ID<tU6a7-3UW-13@gated-at.bofh.it>
In reply to#1668696
Em Sun, 18 Jun 2017 22:18:29 -0300
Mauro Carvalho Chehab <mchehab@s-opensource.com> escreveu:

> Hi Jon,
> 
> Em Sun, 18 Jun 2017 17:46:25 -0600
> Jonathan Corbet <corbet@lwn.net> escreveu:
> 
> > I've just spent rather more time than I would like figuring out why the PDF
> > builds fail and what was needed to fix it.  The result is the following
> > patch series.  It's a combination of little mistakes and fragility in the
> > whole PDF build tool chain.  
> 
> Yeah, the PDF toolchain is very fragile. Yet, I'm pretty sure I was able
> to build PDF in the past without noticing the problems fixed by patches
> 1 and 2. Maybe the bugs has to do with some specific incompatibility with
> toolchain versions.
> 
> What Sphinx version are you using?
> 
> It is too late now, but tomorrow I'll test with a few Spinx versions
> and see if PDF builds equally well with them.
> 
> > 
> > Mauro, Daniel: Do you want the last two?  Or otherwise give me acks?  I'd
> > like to send the set Linusward forthwith so that 4.12 can come out with
> > a working PDF build.  
> 
> For the media and EDAC changes (patches 3 and 4), once I test it,
> feel free to add my ack and send via your tree:
> 
> Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> 
> > 
> > In general, I'm dismayed by the fragility of the whole thing.  I'm also a
> > little concerned that nobody except Jim complained about the problem.  
> 
> Actually, despite any "errors", usually it produces the PDF files.
> I have a robot building just the media documentation, daily basis,
> from media development tree, at:
> 	https://linuxtv.org/downloads/v4l-dvb-apis-new/media.pdf
> 
> The robot is using Sphinx 1.4.8 version.

I tested building here with Sphinx 1.4.9, 1.5.6 and 1.6.2.

With those patches applied (using my version of the patch adjusting
the margins), the result is that it seems to be building fine with
versions 1.4.9 and 1.5.6.

However, with 1.6.2, I'm getting build errors:

Output written on driver-api.pdf (847 pages).
Transcript written on driver-api.log.
Documentation/Makefile:83: recipe for target 'pdfdocs' failed
make[1]: *** [pdfdocs] Error 2
Makefile:1470: recipe for target 'pdfdocs' failed
make: *** [pdfdocs] Error 2

Despite what's written there, I was unable to find a problem on
driver-api build so far. Yet, the media.pdf book is written with
just a few pages. It turns that the build breaks on the tables
that need scaling to fit at the paper's page.

The first one to break is this piece of .rst file, located at
media/uapi/v4l/extended-controls.rst:


	enum v4l2_vp8_golden_frame_sel -
	    Selects the golden frame for encoding. Possible values are:

	.. raw:: latex

	    \begin{adjustbox}{width=\columnwidth}

It seems that adjustbox doesn't work anymore. It fails with:


	! Missing \endgroup inserted.
	<inserted text> 
	                \endgroup 
	l.4104 \begin{savenotes}\sphinxattablestart

I suspect that we'll need to redefine sphinxattablestart for Sphinx
versions 1.6.x.

I'm starting to think that the only way we'll get some sanity on
documentation build is if we enforce that builds will happen with
only sanctioned Sphinx versions.

Markus,

Are there some way for us to have an extension that would provide
something that would modify the LaTeX output to 


Anyway, I'm seeking for some hack at conf.py that would fix it.

Thanks,
Mauro

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web