On 10/05/2024 12:39, Mauro Carvalho Chehab wrote:
Em Fri, 10 May 2024 13:39:17 +0300
Dmitry Baryshkov <dmitry.barysh...@linaro.org> escreveu:
On Fri, 10 May 2024 at 13:09, Jani Nikula <jani.nik...@intel.com> wrote:
On Fri, 10 May 2024, Mauro Carvalho Chehab <mche...@kernel.org> wrote:
Em Fri, 10 May 2024 11:08:38 +0300
Jani Nikula <jani.nik...@intel.com> escreveu:
On Thu, 09 May 2024, Dmitry Baryshkov <dmitry.barysh...@linaro.org> wrote:
The drm/msm driver had adopted using Python3 script to generate register
header files instead of shipping pre-generated header files. Document
the minimal Python version supported by the script.
Signed-off-by: Dmitry Baryshkov <dmitry.barysh...@linaro.org>
---
Documentation/process/changes.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/process/changes.rst
b/Documentation/process/changes.rst
index 5685d7bfe4d0..8d225a9f65a2 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -63,6 +63,7 @@ cpio any cpio --version
GNU tar 1.28 tar --version
gtags (optional) 6.6.5 gtags --version
mkimage (optional) 2017.01 mkimage --version
+Python (optional) 3.5.x python3 --version
Python 3.5 reached end-of-life 3½ years ago [1]. What's the point in
using anything older than the oldest supported version of Python,
i.e. 3.8 at this time?
What's the point of breaking compilation with on older distros?
The idea of minimal versions here is to specify the absolute minimum
version that it is required for the build to happen. If 3.5 is
the minimal one, then be it.
AFAICT 3.5 was an arbitrary rather than a deliberate choice. We should
at least be aware *why* we'd be sticking to old versions.
From my side, the 3.5 was chosen basing on the previous feedback from
Jon Hunter:
https://lore.kernel.org/dri-devel/20240412165407.42163-1-jonath...@nvidia.com/
Patch there seems small/simple enough if it is all it takes for 3.5.
Yet, it would be nice to hear from Jon Hunter about the rationale
for 3.5 support (if any).
We just have some legacy builders for legacy Tegra devices that are
still using python 3.5. I will request that these are updated but these
are not machines that I own and so may take some time.
Minimum versions here also means sticking to features available in said
versions, for Python just as well as for GCC or any other tool. That's
not zero cost.
I guess there are two angles here too. The absolute minimum version
currently required, and the, uh, maximum the minimum version can be
safely bumped to. Say, you want to use a feature not available in the
current minimum, how far up can you bump the version to?
Could we define and document the criteria (e.g. based on distros as you
suggest below) so we don't have to repeat the discussion?
Agreed. While we should not bump version randomly, defining a
criteria about when we should update the requirement sounds a great idea.
For me, the criteria is:
- the minimal version shall be at least the minimal one required for the
Kernel to build at the most used LTS distros that are not EOL, e. g.:
Debian, openSUSE/SUSE, CentOS/RHEL and Ubuntu LTS[1].
[1] In practice, Ubuntu LTS usually has a python version newer than
Debian LTS, and CentOS versions are identical to RHEL ones, so
I guess checking for Debian, openSUSE, SUSE and RHEL should be
enough.
Adding Stefan from SUSE because Stefan also reported a similar issue
[0]. Note that subject of this email is incorrect and should be python
3.6 and not 2.6 :-)
Jon
[0] https://lore.kernel.org/all/20240118123752.bl3qss3qbbxgv...@suse.de/
--
nvpublic
