On 01/02/2024 16:07, Justin Forbes wrote:
On Thu, Feb 1, 2024 at 8:58 AM Justin Forbes jforbes@fedoraproject.org wrote:
On Thu, Feb 1, 2024 at 8:41 AM Justin Forbes jforbes@fedoraproject.org wrote:
On Thu, Feb 1, 2024 at 8:25 AM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Thu, Feb 01, 2024 at 06:43:46AM -0600, Justin Forbes wrote:
On Tue, Jan 30, 2024 at 10:21 AM Jonathan Corbet corbet@lwn.net wrote:
Justin Forbes jforbes@fedoraproject.org writes: > On Mon, Jan 29, 2024 at 09:01:07AM -0800, Greg Kroah-Hartman wrote: >> 6.6-stable review patch. If anyone has any objections, please let me know. >> >> ------------------ >> >> From: Vegard Nossum vegard.nossum@oracle.com >> >> [ Upstream commit c48a7c44a1d02516309015b6134c9bb982e17008 ] >> >> The kernel-feat directive passes its argument straight to the shell. >> This is unfortunate and unnecessary.
[...]
> This patch seems to be missing something. In 6.6.15-rc1 I get a doc > build failure with: > > /builddir/build/BUILD/kernel-6.6.14-332-g1ff49073b88b/linux-6.6.15-0.rc1.1ff49073b88b.200.fc39.noarch/Documentation/sphinx/kerneldoc.py:133: SyntaxWarning: invalid escape sequence '.' > line_regex = re.compile("^.. LINENO ([0-9]+)$")
Ah ... you're missing 86a0adc029d3 (Documentation/sphinx: fix Python string escapes). That is not a problem with this patch, though; I would expect you to get the same error (with Python 3.12) without.
Well, it appears that 6.6.15 shipped anyway, with this patch included, but not with 86a0adc029d3. If anyone else builds docs, this thread should at least show them the fix. Perhaps we can get the missing patch into 6.6.16?
Sure, but again, that should be independent of this change, right?
I am not sure I would say independent. This particular change causes docs to fail the build as I mentioned during rc1. There were no issues building 6.6.14 or previous releases, and no problem building 6.7.3.
I can confirm that adding this patch to 6.6.15 makes docs build again.
I lied, it just fails slightly differently. Some of the noise is gone, but we still have: Sphinx parallel build error: UnboundLocalError: cannot access local variable 'fname' where it is not associated with a value make[2]: *** [Documentation/Makefile:102: htmldocs] Error 2 make[1]: *** [/builddir/build/BUILD/kernel-6.6.15/linux-6.6.15-200.fc39.noarch/Makefile:1715: htmldocs] Error 2
The old version of the script unconditionally assigned a value to the local variable 'fname' (not a value that makes sense to me, since it's literally assigning the whole command, not just a filename, but that's a separate issue), and I removed that so it's only conditionally assigned. This is almost certainly a bug in my patch.
I'm guessing maybe a different patch between 6.6 and current mainline is causing 'fname' to always get assigned for the newer versions and thus make the run succeed, in spite of the bug.
Something like the patch below (completely untested) should restore the previous behaviour, but I'm not convinced it's correct.
Vegard
diff --git a/Documentation/sphinx/kernel_feat.py b/Documentation/sphinx/kernel_feat.py index b9df61eb4501..15713be8b657 100644 --- a/Documentation/sphinx/kernel_feat.py +++ b/Documentation/sphinx/kernel_feat.py @@ -93,6 +93,8 @@ class KernelFeat(Directive): if len(self.arguments) > 1: args.extend(['--arch', self.arguments[1]])
+ fname = ' '.join(args) + lines = subprocess.check_output(args, cwd=os.path.dirname(doc.current_source)).decode('utf-8')
line_regex = re.compile(r"^.. FILE (\S+)$")