Workflows Archive mirror
 help / color / mirror / Atom feed
From: Jon Hunter <jonathanh@nvidia.com>
To: Mauro Carvalho Chehab <mchehab@kernel.org>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Stefan Dirsch <sndirsch@suse.de>
Cc: Jani Nikula <jani.nikula@intel.com>,
	Jonathan Corbet <corbet@lwn.net>, Rob Clark <robdclark@gmail.com>,
	Abhinav Kumar <quic_abhinavk@quicinc.com>,
	Sean Paul <sean@poorly.run>,
	Marijn Suijten <marijn.suijten@somainline.org>,
	workflows@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Masahiro Yamada <masahiroy@kernel.org>,
	linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
	freedreno@lists.freedesktop.org
Subject: Re: [PATCH] docs: document python version used for compilation
Date: Fri, 10 May 2024 12:47:00 +0100	[thread overview]
Message-ID: <7e23363b-747e-444e-9007-c806a6c5596e@nvidia.com> (raw)
In-Reply-To: <20240510123911.34f050b5@sal.lan>


On 10/05/2024 12:39, Mauro Carvalho Chehab wrote:
> Em Fri, 10 May 2024 13:39:17 +0300
> Dmitry Baryshkov <dmitry.baryshkov@linaro.org> escreveu:
> 
>> On Fri, 10 May 2024 at 13:09, Jani Nikula <jani.nikula@intel.com> wrote:
>>>
>>> On Fri, 10 May 2024, Mauro Carvalho Chehab <mchehab@kernel.org> wrote:
>>>> Em Fri, 10 May 2024 11:08:38 +0300
>>>> Jani Nikula <jani.nikula@intel.com> escreveu:
>>>>   
>>>>> On Thu, 09 May 2024, Dmitry Baryshkov <dmitry.baryshkov@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.baryshkov@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-jonathanh@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.bl3qss3qbbxgvpdk@suse.de/
-- 
nvpublic

  reply	other threads:[~2024-05-10 11:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-09 13:31 [PATCH] docs: document python version used for compilation Dmitry Baryshkov
2024-05-09 16:48 ` Jonathan Corbet
2024-05-09 18:59   ` Abhinav Kumar
2024-05-10  8:08 ` Jani Nikula
2024-05-10  9:20   ` Mauro Carvalho Chehab
2024-05-10 10:09     ` Jani Nikula
2024-05-10 10:39       ` Dmitry Baryshkov
2024-05-10 11:21         ` Mauro Carvalho Chehab
2024-05-10 11:39         ` Mauro Carvalho Chehab
2024-05-10 11:47           ` Jon Hunter [this message]
2024-05-10 20:04       ` Rob Clark

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=7e23363b-747e-444e-9007-c806a6c5596e@nvidia.com \
    --to=jonathanh@nvidia.com \
    --cc=corbet@lwn.net \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marijn.suijten@somainline.org \
    --cc=masahiroy@kernel.org \
    --cc=mchehab@kernel.org \
    --cc=quic_abhinavk@quicinc.com \
    --cc=robdclark@gmail.com \
    --cc=sean@poorly.run \
    --cc=sndirsch@suse.de \
    --cc=workflows@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).