[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250731195536.6075afe2@foz.lan>
Date: Thu, 31 Jul 2025 19:55:36 +0200
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: Akira Yokosawa <akiyks@...il.com>
Cc: Jonathan Corbet <corbet@....net>, Linux Doc Mailing List
<linux-doc@...r.kernel.org>, linux-kernel@...r.kernel.org, Sai Vishnu M
<saivishnu725@...il.com>
Subject: Re: [PATCH 00/15] Translate sphinx-pre-install to Python
Em Thu, 31 Jul 2025 13:51:07 +0200
Mauro Carvalho Chehab <mchehab+huawei@...nel.org> escreveu:
> Em Tue, 8 Jul 2025 23:56:01 +0900
> Akira Yokosawa <akiyks@...il.com> escreveu:
>
> > > My question would be: are the results somehow worse than those provided
> > > by the existing, Perl script?
> >
> > Not at all. Mauro made some improvements WRT opensuse/leap over the perl
> > one, but there remain a lot of rooms for improvements here and there.
> >
> > I've been ignoring sphinx-pre-install all these years, but the impressive
> > test results presented in this cover-letter made me test it.
>
> I'm now working to fix PDF generation, assuming that all packages from
> sphinx-pre-install are installed.
>
> I'm placing the patches on my scratch tree at:
> https://github.com/mchehab/linux/tree/my-docs-next
>
> It contains several branches merged there in sequence:
> - elder_python_v1: makes kernel-doc run with elder kernels (2 patches);
> - netlink_v10: patches adding an yaml parser for netlink (14 patches);
> - sphinx-pre-install-v4: current version of this series (39 patches);
> - pdfdocs: specific fixes for PDF doc generation (11 patches);
> - sphinx-build-wrapper: a new script with a large cleanup at docs Makefile
> (7 patches)
>
> On my testbanch, this is the current summary, where:
> - PASSED: means both HTML and PDF were generated:
>
> PASSED - AlmaLinux release 9.6 (Sage Margay) (7 tests)
> PASSED - Amazon Linux release 2023 (Amazon Linux) (7 tests)
> PASSED - Arch Linux (7 tests)
> PASSED - CentOS Stream release 9 (7 tests)
> PASSED - Fedora release 42 (Adams) (7 tests)
> PASSED - Kali GNU/Linux 2025.2 (7 tests)
> PASSED - Mageia 9 (7 tests)
> PASSED - openSUSE Leap 15.6 (7 tests)
> PASSED - openSUSE Tumbleweed (7 tests)
> PASSED - Oracle Linux Server release 9.6 (7 tests)
> PASSED - Rocky Linux release 9.6 (Blue Onyx) (7 tests)
> PASSED - Ubuntu 24.04.2 LTS (7 tests)
> PASSED - Ubuntu 25.04 (7 tests)
Forgot to mention, but for Debian-based distros, my setup does this at
the distro setup phase:
if [ -f /etc/ImageMagick-6/policy.xml ]; then
# Remove any existing restrictive policies for PDF/PS/EPS/XPS
sed -i '/<policy.*domain="coder".*pattern=".*\(PDF\|PS\|EPS\|XPS\).*"/d' /etc/ImageMagick-6/policy.xml
# Allow PDF patterns at the end </policymap>
sed -i '/<\/policymap>/i \ \ <policy domain="coder" rights="read|write" pattern="{PS,PS2,PS3,EPS,PDF,XPS}" />'etc/ImageMagick-6/policy.xml
fi
if [ -f /etc/ImageMagick-7/policy.xml ]; then
# Remove any existing restrictive policies for PDF/PS/EPS/XPS
sed -i '/<policy.*domain="coder".*pattern=".*\(PDF\|PS\|EPS\|XPS\).*"/d' /etc/ImageMagick-7/policy.xml
# Allow PDF patterns at the end </policymap>
sed -i '/<\/policymap>/i \ \ <policy domain="coder" rights="read|write" pattern="{PS,PS2,PS3,EPS,PDF,XPS}" />' /etc/ImageMagick-7/policy.xml
fi
to fix a debian-specific packaging issue that makes ImageMagick
to fail when it is used with PS/PDF files.
Regards,Mauro
Powered by blists - more mailing lists