<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/Documentation/conf.py, branch v4.11</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Documentation/sphinx: fix primary_domain configuration</title>
<updated>2017-03-03T23:12:30+00:00</updated>
<author>
<name>John Keeping</name>
<email>john@metanate.com</email>
</author>
<published>2017-03-03T12:24:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=fd5d666932d51b2552ecc0280047d6b35d9b6cd1'/>
<id>fd5d666932d51b2552ecc0280047d6b35d9b6cd1</id>
<content type='text'>
With Sphinx 1.5.3 I get the warning:

	WARNING: primary_domain 'C' not found, ignored.

It seems that domain names in Sphinx are case-sensitive and for the C
domain the name must be lower case.

Signed-off-by: John Keeping &lt;john@metanate.com&gt;
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With Sphinx 1.5.3 I get the warning:

	WARNING: primary_domain 'C' not found, ignored.

It seems that domain names in Sphinx are case-sensitive and for the C
domain the name must be lower case.

Signed-off-by: John Keeping &lt;john@metanate.com&gt;
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>docs: Remove the copyright year from conf.py</title>
<updated>2017-02-06T18:52:19+00:00</updated>
<author>
<name>Jonathan Corbet</name>
<email>corbet@lwn.net</email>
</author>
<published>2017-02-06T18:52:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=dc36143fba936d8f1a673e2b554bc5b6cb0dd9ce'/>
<id>dc36143fba936d8f1a673e2b554bc5b6cb0dd9ce</id>
<content type='text'>
It had gone stale, of course, as it would every year, a single date doesn't
really cover things, and the date isn't really needed anyway.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It had gone stale, of course, as it would every year, a single date doesn't
really cover things, and the date isn't really needed anyway.
</pre>
</div>
</content>
</entry>
<entry>
<title>docs-rst: doc-guide: split the kernel-documentation.rst contents</title>
<updated>2016-11-19T17:22:04+00:00</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab@s-opensource.com</email>
</author>
<published>2016-11-17T10:32:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1dc4bbf0b268246f6202c761016735933b6f0b99'/>
<id>1dc4bbf0b268246f6202c761016735933b6f0b99</id>
<content type='text'>
Having the kernel-documentation at the topmost level doesn't
allow generating a separate PDF file for it. Also, makes harder
to add extra contents. So, place it on a sub-dir.

Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Having the kernel-documentation at the topmost level doesn't
allow generating a separate PDF file for it. Also, makes harder
to add extra contents. So, place it on a sub-dir.

Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>docs: Add more manuals to the PDF build</title>
<updated>2016-11-16T23:07:02+00:00</updated>
<author>
<name>Jonathan Corbet</name>
<email>corbet@lwn.net</email>
</author>
<published>2016-11-16T23:07:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=22917b992d3713157e759f23a5a090687d004331'/>
<id>22917b992d3713157e759f23a5a090687d004331</id>
<content type='text'>
There were a few manuals that weren't being built in PDF format, but
there's no reason not to...

Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There were a few manuals that weren't being built in PDF format, but
there's no reason not to...

Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>docs-rst: fix LaTeX \DURole renewcommand with Sphinx 1.3+</title>
<updated>2016-11-16T22:20:12+00:00</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab@osg.samsung.com</email>
</author>
<published>2016-11-14T16:32:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e2a91f4f42018994d7424d405900d17eba6555d0'/>
<id>e2a91f4f42018994d7424d405900d17eba6555d0</id>
<content type='text'>
PDF build on Kernel 4.9-rc? returns an error with Sphinx 1.3.x
and Sphinx 1.4.x, when trying to solve some cross-references.

The solution is to redefine the \DURole macro.

However, this is redefined too late. Move such redefinition to
LaTeX preamble and bind it to just the Sphinx versions where the
error is known to be present.

Tested by building the documentation on interactive mode:
	make PDFLATEX=xelatex -C Documentation/output/./latex

Fixes: e61a39baf74d ("[media] index.rst: Fix LaTeX error in interactive mode on Sphinx 1.4.x")
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
PDF build on Kernel 4.9-rc? returns an error with Sphinx 1.3.x
and Sphinx 1.4.x, when trying to solve some cross-references.

The solution is to redefine the \DURole macro.

However, this is redefined too late. Move such redefinition to
LaTeX preamble and bind it to just the Sphinx versions where the
error is known to be present.

Tested by building the documentation on interactive mode:
	make PDFLATEX=xelatex -C Documentation/output/./latex

Fixes: e61a39baf74d ("[media] index.rst: Fix LaTeX error in interactive mode on Sphinx 1.4.x")
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Documentation/sphinx: set literal block highlight language to none</title>
<updated>2016-11-03T10:38:47+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2016-11-03T08:26:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b459106ea4b7f317faa24b47e9a6b20c2f254d2d'/>
<id>b459106ea4b7f317faa24b47e9a6b20c2f254d2d</id>
<content type='text'>
Set the default highlight language to "none", i.e. do not try to guess
the language and do automatic syntax highlighting on literal blocks.

Eyeballing around the generated documentation, we don't seem to actually
have a lot of literal blocks that would benefit from syntax
highlighting. The C code blocks we do have are typically very short, and
most of the literal blocks are things that shouldn't be highlighted (or,
do not have a pygments lexer). This seems to be true for literal blocks
both in the rst source files and in source code comments.

Not highlighting code is never wrong, but guessing the language wrong
almost invariably leads to silly or confusing highlighting.

At the time of writing, admin-guide/oops-tracing.rst and
admin-guide/ramoops.rst contain good examples of 1) a small C code
snippet not highlighted, 2) a hex dump highligted as who knows what, 3)
device tree block highlighted as C or maybe Python, 4) a terminal
interaction highlighted as code in some language, and finally, 5) some C
code snippets correctly identified as C. I think we're better off
disabling language guessing, and going by explicitly identified
languages for longer code blocks.

It is still possible to enable highlighting on an rst source file basis
using the highlight directive:

.. higlight:: language

and on a literal block basis using the code-block directive:

.. code-block:: language

See http://www.sphinx-doc.org/en/latest/markup/code.html for details.

Cc: Jonathan Corbet &lt;corbet@lwn.net&gt;
Cc: Mauro Carvalho Chehab &lt;mchehab@osg.samsung.com&gt;
Cc: Markus Heiser &lt;markus.heiser@darmarit.de&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Set the default highlight language to "none", i.e. do not try to guess
the language and do automatic syntax highlighting on literal blocks.

Eyeballing around the generated documentation, we don't seem to actually
have a lot of literal blocks that would benefit from syntax
highlighting. The C code blocks we do have are typically very short, and
most of the literal blocks are things that shouldn't be highlighted (or,
do not have a pygments lexer). This seems to be true for literal blocks
both in the rst source files and in source code comments.

Not highlighting code is never wrong, but guessing the language wrong
almost invariably leads to silly or confusing highlighting.

At the time of writing, admin-guide/oops-tracing.rst and
admin-guide/ramoops.rst contain good examples of 1) a small C code
snippet not highlighted, 2) a hex dump highligted as who knows what, 3)
device tree block highlighted as C or maybe Python, 4) a terminal
interaction highlighted as code in some language, and finally, 5) some C
code snippets correctly identified as C. I think we're better off
disabling language guessing, and going by explicitly identified
languages for longer code blocks.

It is still possible to enable highlighting on an rst source file basis
using the highlight directive:

.. higlight:: language

and on a literal block basis using the code-block directive:

.. code-block:: language

See http://www.sphinx-doc.org/en/latest/markup/code.html for details.

Cc: Jonathan Corbet &lt;corbet@lwn.net&gt;
Cc: Mauro Carvalho Chehab &lt;mchehab@osg.samsung.com&gt;
Cc: Markus Heiser &lt;markus.heiser@darmarit.de&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Documentation/sphinx: include admin-guide in the latex/pdf build</title>
<updated>2016-11-03T10:38:25+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2016-11-02T11:05:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8d26d90ba3e1cfb75c4af2882045ca2c8120fbab'/>
<id>8d26d90ba3e1cfb75c4af2882045ca2c8120fbab</id>
<content type='text'>
Fix the warning:

WARNING: "latex_documents" config value references unknown document
user/index

Reviewed-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix the warning:

WARNING: "latex_documents" config value references unknown document
user/index

Reviewed-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>docs-rst: create an user's manual book</title>
<updated>2016-10-24T10:12:35+00:00</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab@s-opensource.com</email>
</author>
<published>2016-09-21T12:51:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9d85025b0418163fae079c9ba8f8445212de8568'/>
<id>9d85025b0418163fae079c9ba8f8445212de8568</id>
<content type='text'>
Place README, REPORTING-BUGS, SecurityBugs and kernel-parameters
on an user's manual book.

As we'll be numbering the user's manual, remove the manual
numbering from SecurityBugs.

Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Place README, REPORTING-BUGS, SecurityBugs and kernel-parameters
on an user's manual book.

As we'll be numbering the user's manual, remove the manual
numbering from SecurityBugs.

Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>docs: rename development-process/ to process/</title>
<updated>2016-10-24T10:12:35+00:00</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab@s-opensource.com</email>
</author>
<published>2016-10-18T11:05:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=0e4f07a65f53e7b3afab71925e56fe6aaa07d696'/>
<id>0e4f07a65f53e7b3afab71925e56fe6aaa07d696</id>
<content type='text'>
As we'll type this a lot, after adding CodingStyle &amp; friends,
let's rename the directory name to a shorter one.

Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As we'll type this a lot, after adding CodingStyle &amp; friends,
let's rename the directory name to a shorter one.

Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@s-opensource.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Documentation/sphinx: rename kernel-doc.py to kerneldoc.py</title>
<updated>2016-10-19T22:02:00+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2016-10-19T10:44:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=58af04dff742b6b49fae3de585bdea8c77b62ddc'/>
<id>58af04dff742b6b49fae3de585bdea8c77b62ddc</id>
<content type='text'>
Python module names should not have hyphens per [PEP 8]. Drop the hyphen
from kernel-doc.py. The extension directive remains unchanged.

[PEP 8] https://www.python.org/dev/peps/pep-0008/#package-and-module-names

Reported-by: Markus Heiser &lt;markus.heiser@darmarit.de&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Python module names should not have hyphens per [PEP 8]. Drop the hyphen
from kernel-doc.py. The extension directive remains unchanged.

[PEP 8] https://www.python.org/dev/peps/pep-0008/#package-and-module-names

Reported-by: Markus Heiser &lt;markus.heiser@darmarit.de&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</pre>
</div>
</content>
</entry>
</feed>
