linux-kernel - Re: [PATCH 00/15] Translate sphinx-pre-install to Python

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: <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