Re: [PATCH 1/2] scripts: add TOML config to container tool

[Nicolas Schier <n.schier@fritz.com>]

[-- Attachment #1: Type: text/plain, Size: 2542 bytes --]

On Sat, Aug 29, 2026 at 10:56:47AM +0200, Guillaume Tucker wrote:
> Hi Miguel,
> 
> On 28/08/2026 7:35 pm, Miguel Ojeda wrote:
> > On Fri, Aug 28, 2026 at 7:25 PM Guillaume Tucker <gtucker@gtucker.io> wrote:
> > > 
> > > It states Python 3.9 which was already older than the 3.10 minimum
> > > set when the container tool was merged.  Also my understanding is
> > > that it's not a hard requirement for all the kernel tools, only for
> > > building and producing a functioning kernel.  If I misunderstood this
> > 
> > I didn't check at the moment, but at least back when the "(optional)"
> > tag was removed, it was only required for certain configurations from
> > what I understand (I am not sure why the tag was removed).
> > 
> > In any case, it is nice if we could just say that it is required -- it
> > is quite useful to have around, especially due to its standard
> > library.
> 
> OK so I'll leave this part as-is for now unless someone makes a
> strong case for downgrading to v3.9, thanks for confirming.
> 
> > And regarding the minimum version, it would be nice to eventually have
> > a single minimum for all Python scripts, no? Debian oldstable is
> > already at 3.11, so I think we could perhaps bump the minimum already.
> > And Debian stable is 3.13, which from your list would be enough for
> > everything on your list, right? So we could perhaps set that as the
> > actual minimum for everything in the future.
> 
> I was wondering about this too, especially since v3.10 is soon going
> to reach end-of-life which means no more security patches.  In
> principle newer, version should be backwards compatible so if we just
> bumped the minimum to v3.13 older scripts that were written for v3.9
> should still work - but it'd be nice to have a way to test that.
> 
> Well that's beyond this series anyway, maybe something for KernelCI?

If I filtered the repology data correctly, bumping the minimum Python 
version to v3.11 would be problematic for these (major) distributions:

  * Alpine Linux 3.17
  * CentOS 8
  * Debian 11
  * Devuan 4.0
  * OpenMandriva Cooker
  * OpenMandriva Rolling
  * Slackware 15.0
  * Ubuntu 20.04

With the end of security support for Python 3.10, I think that is 
acceptable for a minimum version bump.

Bumping the minimum version of a tool used in scattered places in the 
tree to a version that is just 3-4 years old should not be done too 
careless, but I think for Python, I'd second bumping to v3.11.

Kind regards,
Nicolas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]