linux-kernel - Re: [PATCH] doc: flat-table directive

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]

Message-Id: <C4C837F6-6658-4AE2-95DF-9A4DE02BC548@darmarit.de>
Date:	Fri, 1 Jul 2016 13:12:30 +0200
From:	Markus Heiser <markus.heiser@...marit.de>
To:	Jani Nikula <jani.nikula@...el.com>
Cc:	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, hverkuil@...all.nl,
	daniel.vetter@...ll.ch, airlied@...il.com,
	grant.likely@...retlab.ca, rdunlap@...radead.org, keithp@...thp.com
Subject: Re: [PATCH] doc: flat-table directive


Am 01.07.2016 um 12:44 schrieb Jani Nikula <jani.nikula@...el.com>:

> On Fri, 01 Jul 2016, Mauro Carvalho Chehab <mchehab@....samsung.com> wrote:
>> Not being able to compile just one docbook is a regression and breaks
>> my process. This needs to be fixed.
> 
> Do you have a regression with *DocBook XML* on docs-next now? If yes,
> clearly that must be fixed ASAP.

Now I see the problem ...

It seems that we didn't neglected that the DocBook Makefile 
builds single books, e.g.

  make DOCBOOKS=device-drivers.xml htmldocs

Since the Makefile.sphinx does not care the environment DOCBOOKS,
the XML is build and the reST also, where only the XML content
should be build.

Jani, may could you apply a small fix on the Makefile.sphinx which
takes into account, not to run the sphinx-build if the DOCBOOK 
environment is set .. is it a solution for a start?

-- Markus --

> As to Sphinx, I fear your DocBook workflows are so elaborate that we are
> bound to break some of them when switching over. Personally, I don't
> think that's all bad. It's an opportunity to make things better. But we
> can't make all of that happen overnight for media. This is why we have
> Sphinx and DocBook side by side for now.
> 
> We specifically wanted to make the switch for e.g. GPU documentation
> fast, act as guinea pigs, hit the issues, and make it easier for others
> in the end. We'd also love to get some of those validation things you
> have, for everyone, but using Sphinx instead of a bunch of scripts and
> sed on the input files.
> 
> This is also one of the reasons why I so much want to keep everything
> behind one configuration file, and build everything in the Sphinx
> toolchain. To keep it all more uniform, to not duplicate stuff, and not
> deviate to some silos like we've done in the past. I think when we have
> things working, we can add dedicated config files for the select few
> things that have additional special needs. Media is probably one of
> them. But that said, I think we should be able to keep including that to
> the main documentation build too.
> 
> Also, many thanks for digging into this and reporting issues that you do
> face.
> 
> 
> BR,
> Jani.
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center