Bump minimum python version to 3.10

[r-c-n]

No description provided.

[JenySadadia]

LGTM.

[pawiecz]

LGTM too

I had a slight concern about having 3.9 in the execution environment for prod/staging/ChromeOS update scripts but it looks like it should be fine for now:

• (prod) 16 calls to kci tools: 15 to kci docker, one to kci_test
• (stage) 16 calls to kci docker
• (chromeos) 7 calls to kci docker

[pawiecz]

Turns out I did not verify it thoroughly enough: those kci docker commands make attempts to install KernelCI Python package using Py 3.9.2, e.g.

1. ./kci docker $args k8s kernelci
2. uses k8s recipe which is based off debian.jinja2
3. which still uses bullseye as a base image

It's far from perfect solution but could we keep 3.10 requirement in the GitHub workflows and relax pyproject.toml requirements to also allow 3.9?

[r-c-n]

Well most of those deployment details completely fly over my head, to be honest. So I trust your decision. The only reason I did this PR is to unblock this one, whose Gitlab CI tests are failing until this one is merged, supposedly. So as long as I can get that to work, anything you decide is fine by me.

[JenySadadia]

Turns out I did not verify it thoroughly enough: those kci docker commands make attempts to install KernelCI Python package using Py 3.9.2, e.g.

1. ./kci docker $args k8s kernelci
2. uses k8s recipe which is based off debian.jinja2
3. which still uses bullseye as a base image

It's far from perfect solution but could we keep 3.10 requirement in the GitHub workflows and relax pyproject.toml requirements to also allow 3.9?

@pawiecz Thank you for your findings.
This means we can't do much about this but use 3.9 until the bullseye gets upgraded with a newer python version.
Is that true?
I am wondering what if we install a different python version in debian.jinja2 template? Or that would break the debian:bullseye image?

[nuclearcat]

I will add skip-staging label as at moment it is breaking staging

[pawiecz]

@JenySadadia For a long term solution I believe a way to go would be updating debian.jinja2 base image to current stable (bookworm). This, however, would involve at least:

1. List all images built with kci docker based on debian.jinja2
2. List key acceptance criteria for those ^ to make sure that images rebuilt on a new base kept all required functionalities
3. Run tests ^ on rebuilt images

But we can do that after M1 - for now let's go with relaxed package requirements and strict GH workflow.

[pawiecz]

LGTM, I'm taking staging-skip label off; I'd merge it but I lack permissions to do so

[JenySadadia]

I'll merge it. Thanks.