From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Markus Heiser <markus.heiser@darmarit.de>
Subject: Re: [PATCH RFC 0/2] docs: Deal with some Sphinx deprecation warnings
Date: Wed, 22 May 2019 07:19:09 -0300 [thread overview]
Message-ID: <20190522071909.050bb227@coco.lan> (raw)
In-Reply-To: <87d0kb7xf6.fsf@intel.com>
Em Wed, 22 May 2019 10:36:45 +0300
Jani Nikula <jani.nikula@linux.intel.com> escreveu:
> On Tue, 21 May 2019, Jonathan Corbet <corbet@lwn.net> wrote:
> > The Sphinx folks are deprecating some interfaces in the upcoming 2.0
> > release; one immediate result of that is a bunch of warnings that show up
> > when building with 1.8. These two patches make those warnings go away,
> > but at a cost:
> >
> > - It introduces a couple of Sphinx version checks, which are always
> > ugly, but the alternative would be to stop supporting versions
> > before 1.7. For now, I think we can carry that cruft.
>
> Frankly, I'd just require Sphinx 1.7+, available even in Debian stable
> through stretch-backports.
We can raise the bar and force a 1.7 or even 1.8 (Fedora 30 comes
with version 1.8.4), but I would prefer to keep support older versions,
at least while we don't depend on some new features introduced after
the version we're using, and while our extensions won't require a major
rework due to a new version.
>
> > - The second patch causes the build to fail horribly on newer
> > Sphinx installations. The change to switch_source_input() seems
> > to make the parser much more finicky, increasing warnings and
> > eventually failing the build altogether. In particular, it will
> > scream about problems in .rst files that are not included in the
> > TOC tree at all. The complaints appear to be legitimate, but it's
> > a bunch of stuff to clean up.
There is a flag to cleanup the warning about a file not included at
a TOC tree (:orphan:), but it will still try to parse it. There's also
a conf.py way of doing it. For example, you can exclude an entire dir:
exclude_patterns = ['includes/*.rst']
But using exclude_patterns will likely be too messy.
> I can understand Sphinx complaining that a file is not included in a TOC
> tree, but I don't understand why it goes on to parse them anyway.
Yeah, this is, IMHO, a very bad behavior.
>
> BR,
> Jani.
>
>
> >
> > I've tested these with 1.4 and 1.8, but not various versions in between.
> >
> > Jonathan Corbet (2):
> > doc: Cope with Sphinx logging deprecations
> > doc: Cope with the deprecation of AutoReporter
> >
> > Documentation/sphinx/kerneldoc.py | 48 ++++++++++++++++++++++++-------
> > Documentation/sphinx/kernellog.py | 28 ++++++++++++++++++
> > Documentation/sphinx/kfigure.py | 38 +++++++++++++-----------
> > 3 files changed, 87 insertions(+), 27 deletions(-)
> > create mode 100644 Documentation/sphinx/kernellog.py
>
Thanks,
Mauro
next prev parent reply other threads:[~2019-05-22 10:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-21 21:17 [PATCH RFC 0/2] docs: Deal with some Sphinx deprecation warnings Jonathan Corbet
2019-05-21 21:17 ` [PATCH 1/2] doc: Cope with Sphinx logging deprecations Jonathan Corbet
2019-05-21 21:17 ` [PATCH 2/2] doc: Cope with the deprecation of AutoReporter Jonathan Corbet
2019-05-22 7:38 ` Jani Nikula
2019-05-22 7:36 ` [PATCH RFC 0/2] docs: Deal with some Sphinx deprecation warnings Jani Nikula
2019-05-22 10:19 ` Mauro Carvalho Chehab [this message]
2019-05-22 13:25 ` Markus Heiser
2019-05-22 15:45 ` Jonathan Corbet
2019-05-22 16:04 ` Mauro Carvalho Chehab
2019-05-22 16:40 ` Mauro Carvalho Chehab
2019-05-22 9:43 ` Oleksandr Natalenko
2019-05-22 9:49 ` Oleksandr Natalenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190522071909.050bb227@coco.lan \
--to=mchehab@kernel.org \
--cc=corbet@lwn.net \
--cc=jani.nikula@linux.intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=markus.heiser@darmarit.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.