From: Kees Cook <keescook@chromium.org>
To: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>,
Jani Nikula <jani.nikula@linux.intel.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] docs: Programmatically render MAINTAINERS into ReST
Date: Tue, 1 Oct 2019 09:16:41 -0700 [thread overview]
Message-ID: <201910010913.2BAAC8A@keescook> (raw)
In-Reply-To: <20191001120930.5d388839@coco.lan>
On Tue, Oct 01, 2019 at 12:09:30PM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 1 Oct 2019 08:31:47 -0600
> Jonathan Corbet <corbet@lwn.net> escreveu:
>
> > On Tue, 24 Sep 2019 16:02:06 -0700
> > Kees Cook <keescook@chromium.org> wrote:
> >
> > > Commit log from Patch 2 repeated here for cover letter:
> > >
> > > In order to have the MAINTAINERS file visible in the rendered ReST
> > > output, this makes some small changes to the existing MAINTAINERS file
> > > to allow for better machine processing, and adds a new Sphinx directive
> > > "maintainers-include" to perform the rendering.
> >
> > I finally got around to trying this out. After the usual warnings, the
> > build comes to a screeching halt with this:
> >
> > Sphinx parallel build error:
> > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 8: ordinal not in range(128)
> >
> > For extra fun, the build process simply hangs, requiring a ^C to blow it
> > away. You've managed to get new behavior out of Sphinx that I've not seen
> > before, congratulations :)
> >
> > This almost certainly has to do with the fact that I'm (intentionally)
> > running the Python2 Sphinx build here. Something's not doing unicode that
> > should be.
Given this would be for v5.5, and python2 is EOL in 2 months[1], I don't
think it's unreasonable to deprecate it. Especially considering there
are already explicit "python3" shebangs in existing code in the sphinx/
directory.
[1] https://pythonclock.org/
> > I would suggest that we might just want to repair this before merging this
> > feature. Either that, or we bite the bullet and deprecate the use of
> > Python 2 entirely - something that's probably not too far into our future
> > regardless. Anybody have thoughts on that matter?
>
> I'm almost sure we got this already. If I'm not mistaken, the solution
> is to add the encoding line after shebang. Looking at
> Documentation/sphinx/maintainers_include.py (patch 2/2), the script
> starts with:
>
> #!/usr/bin/env python
> # SPDX-License-Identifier: GPL-2.0
> # -*- coding: utf-8; mode: python -*-
> # pylint: disable=R0903, C0330, R0914, R0912, E0401
>
> But, as I pointed before, the SPDX header at the wrong place is causing the
> crash, as the encoding line should be the second line, not the third one,
> e. g.:
>
> #!/usr/bin/env python
> # -*- coding: utf-8; mode: python -*-
> # SPDX-License-Identifier: GPL-2.0
> # pylint: disable=R0903, C0330, R0914, R0912, E0401
>
> I also suspect that this would happen even with python3, depending on
> how LC_ALL, LANG, ... are set on the distro you use.
Oh that's a delightful bug. :P I haven't been able to reproduce this
failure (maybe all my LANG junk is accidentally correct)?
Jon, if this fixes it for you, should I respin the patches?
--
Kees Cook
next prev parent reply other threads:[~2019-10-01 16:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-24 23:02 [PATCH 0/2] docs: Programmatically render MAINTAINERS into ReST Kees Cook
2019-09-24 23:02 ` [PATCH 1/2] doc-rst: Reduce CSS padding around Field Kees Cook
2019-09-24 23:02 ` [PATCH 2/2] doc-rst: Programmatically render MAINTAINERS into ReST Kees Cook
2019-10-01 14:31 ` [PATCH 0/2] docs: " Jonathan Corbet
2019-10-01 15:09 ` Mauro Carvalho Chehab
2019-10-01 16:16 ` Kees Cook [this message]
2019-10-01 17:05 ` Jonathan Corbet
2019-10-01 17:35 ` Jonathan Corbet
2019-10-01 18:26 ` Kees Cook
2019-10-01 16:27 ` Kees Cook
2019-10-01 17:36 ` Jonathan Corbet
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=201910010913.2BAAC8A@keescook \
--to=keescook@chromium.org \
--cc=corbet@lwn.net \
--cc=jani.nikula@linux.intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab+samsung@kernel.org \
/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.