[PATCH 1/2] tools/make_pip.sh: Use debian packages instead of pip

[PATCH 1/2] tools/make_pip.sh: Use debian packages instead of pip

[Simon Glass]

Recent distros complain about using 'pip install'. Adjust the script to
use 'apt get' instead where possible/required (e.g. with Ubuntu 24.04).

Signed-off-by: Simon Glass <sjg@chromium.org>
---

 scripts/make_pip.sh | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/scripts/make_pip.sh b/scripts/make_pip.sh
index d2639ffd6e4..90756279770 100755
--- a/scripts/make_pip.sh
+++ b/scripts/make_pip.sh
@@ -107,8 +107,10 @@ mkdir ${dir}/tests
 cd ${dir}
 
 # Make sure the tools are up to date
-python3 -m pip install --upgrade build
-python3 -m pip install --upgrade twine
+if ! sudo apt install python3-build twine; then
+	python3 -m pip install --upgrade build
+	python3 -m pip install --upgrade twine
+fi
 
 # Build the PyPi package
 python3 -m build
-- 
2.43.0

base-commit: 0312b271dd6dff8ca6d60c53ab028af526c45dde
branch: patb

[PATCH 2/2] tools: Update the license specifiers

[Simon Glass]

Recent versions of Python complain about the license being in the
classifiers part. Use a 'license' property instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

 tools/binman/pyproject.toml       | 2 +-
 tools/buildman/pyproject.toml     | 2 +-
 tools/dtoc/pyproject.toml         | 2 +-
 tools/patman/pyproject.toml       | 2 +-
 tools/u_boot_pylib/pyproject.toml | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/binman/pyproject.toml b/tools/binman/pyproject.toml
index ba34437fc53..f17bc051ea1 100644
--- a/tools/binman/pyproject.toml
+++ b/tools/binman/pyproject.toml
@@ -10,11 +10,11 @@ authors = [
 ]
 dependencies = ["pylibfdt", "u_boot_pylib >= 0.0.6", "dtoc >= 0.0.6"]
 description = "Binman firmware-packaging tool"
+license = "GPL-2.0-or-later"
 readme = "README.rst"
 requires-python = ">=3.7"
 classifiers = [
     "Programming Language :: Python :: 3",
-    "License :: OSI Approved :: GNU General Public License v2 or later (GPLv2+)",
     "Operating System :: OS Independent",
 ]
 
diff --git a/tools/buildman/pyproject.toml b/tools/buildman/pyproject.toml
index 68bfa45c3f4..3d0842e470a 100644
--- a/tools/buildman/pyproject.toml
+++ b/tools/buildman/pyproject.toml
@@ -14,11 +14,11 @@ dependencies = [
     "patch-manager >= 0.0.6"
 ]
 description = "Buildman build tool for U-Boot"
+license = "GPL-2.0-or-later"
 readme = "README.rst"
 requires-python = ">=3.7"
 classifiers = [
     "Programming Language :: Python :: 3",
-    "License :: OSI Approved :: GNU General Public License v2 or later (GPLv2+)",
     "Operating System :: OS Independent",
 ]
 
diff --git a/tools/dtoc/pyproject.toml b/tools/dtoc/pyproject.toml
index 9f59788e616..3d75e5269c7 100644
--- a/tools/dtoc/pyproject.toml
+++ b/tools/dtoc/pyproject.toml
@@ -10,11 +10,11 @@ authors = [
 ]
 dependencies = ["pylibfdt", "u_boot_pylib >= 0.0.6"]
 description = "Devicetree-to-C generator"
+license = "GPL-2.0-or-later"
 readme = "README.rst"
 requires-python = ">=3.7"
 classifiers = [
     "Programming Language :: Python :: 3",
-    "License :: OSI Approved :: GNU General Public License v2 or later (GPLv2+)",
     "Operating System :: OS Independent",
 ]
 
diff --git a/tools/patman/pyproject.toml b/tools/patman/pyproject.toml
index 06e169cdf48..be7bf1998a6 100644
--- a/tools/patman/pyproject.toml
+++ b/tools/patman/pyproject.toml
@@ -10,11 +10,11 @@ authors = [
 ]
 dependencies = ["u_boot_pylib >= 0.0.6", "aiohttp >= 3.9.1" ]
 description = "Patman patch manager"
+license = "GPL-2.0-or-later"
 readme = "README.rst"
 requires-python = ">=3.7"
 classifiers = [
     "Programming Language :: Python :: 3",
-    "License :: OSI Approved :: GNU General Public License v2 or later (GPLv2+)",
     "Operating System :: OS Independent",
 ]
 
diff --git a/tools/u_boot_pylib/pyproject.toml b/tools/u_boot_pylib/pyproject.toml
index ce2355084ac..c0257caba84 100644
--- a/tools/u_boot_pylib/pyproject.toml
+++ b/tools/u_boot_pylib/pyproject.toml
@@ -9,11 +9,11 @@ authors = [
   { name="Simon Glass", email="sjg@chromium.org" },
 ]
 description = "U-Boot python library"
+license = "GPL-2.0-or-later"
 readme = "README.rst"
 requires-python = ">=3.7"
 classifiers = [
     "Programming Language :: Python :: 3",
-    "License :: OSI Approved :: GNU General Public License v2 or later (GPLv2+)",
     "Operating System :: OS Independent",
 ]
 
-- 
2.43.0

base-commit: 0312b271dd6dff8ca6d60c53ab028af526c45dde
branch: patb

Re: [PATCH 2/2] tools: Update the license specifiers

[Quentin Schulz]

Hi Simon,

On 4/29/25 3:15 PM, Simon Glass wrote:
> Recent versions of Python complain about the license being in the

I believe this isn't related to Python but rather setuptools.

setuptools 77.0.3 and later support PEP-639 which recommends to ditch 
the License :: classifier for a license property.

The issue is that this license property also changed in PEP-639, with 
something that isn't compatible with pre-PEP-639.

Therefore we need to bump the minimum requirement for the setuptools 
dependency in the various pyproject.toml to 77.0.3 or later.

I'm also wondering if we don't need to add a license-files property 
(also PEP-639) to comply with the GPL-2.0-or-later which requires to 
provide a copy of the license.

Cheers,
Quentin

Re: [PATCH 2/2] tools: Update the license specifiers

[Tom Rini]

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

On Tue, Apr 29, 2025 at 03:28:35PM +0200, Quentin Schulz wrote:
> Hi Simon,
> 
> On 4/29/25 3:15 PM, Simon Glass wrote:
> > Recent versions of Python complain about the license being in the
> 
> I believe this isn't related to Python but rather setuptools.
> 
> setuptools 77.0.3 and later support PEP-639 which recommends to ditch the
> License :: classifier for a license property.
> 
> The issue is that this license property also changed in PEP-639, with
> something that isn't compatible with pre-PEP-639.
> 
> Therefore we need to bump the minimum requirement for the setuptools
> dependency in the various pyproject.toml to 77.0.3 or later.
> 
> I'm also wondering if we don't need to add a license-files property (also
> PEP-639) to comply with the GPL-2.0-or-later which requires to provide a
> copy of the license.

Thanks for digging in to this more. Is there not some way to both meet
the PEP and utilize SPDX?

-- 
Tom

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

Re: [PATCH 2/2] tools: Update the license specifiers

[Quentin Schulz]

Hi Tom,

On 4/29/25 3:52 PM, Tom Rini wrote:
> On Tue, Apr 29, 2025 at 03:28:35PM +0200, Quentin Schulz wrote:
>> Hi Simon,
>>
>> On 4/29/25 3:15 PM, Simon Glass wrote:
>>> Recent versions of Python complain about the license being in the
>>
>> I believe this isn't related to Python but rather setuptools.
>>
>> setuptools 77.0.3 and later support PEP-639 which recommends to ditch the
>> License :: classifier for a license property.
>>
>> The issue is that this license property also changed in PEP-639, with
>> something that isn't compatible with pre-PEP-639.
>>
>> Therefore we need to bump the minimum requirement for the setuptools
>> dependency in the various pyproject.toml to 77.0.3 or later.
>>
>> I'm also wondering if we don't need to add a license-files property (also
>> PEP-639) to comply with the GPL-2.0-or-later which requires to provide a
>> copy of the license.
> 
> Thanks for digging in to this more. Is there not some way to both meet
> the PEP and utilize SPDX?
> 

AFAICT, the license field is for the SPDX identifier.

Not all licenses require you to provide the license to comply with it I 
guess? But my reading of GPL-2.0-or-later makes me believe that we need 
to. You would then have the license file(s) included when license-files 
contains a file that is found at the root of the python project? I 
believe that the default value for license-files is ['LICEN[CS]E*', 
'COPYING*', 'NOTICE*', 'AUTHORS*'] so it could be automatically included 
(and thus the license-files not be explicit) if the license file(s) is 
named like that.

It isn't necessarily a big deal (IANAL) to not have the license shipped 
if we don't plan on pushing those to pypi or share sdist/wheels through 
another mean (e.g. GitLab/GitHub releases generated with `python3 -m 
build`)?

I am not sure exactly what you meant by "both meet the PEP and utilize 
SPDX" as I believe they aren't related here? I mean, license property is 
the way to define the SPDX identifier in PEP-639, but the missing 
license-files doesn't have anything to do with SPDX I believe? Just that 
it wouldn't be complying (I believe, still haven't become a lawyer in 
the last few paragraphs) with the license itself if the license file 
isn't shipped.

What I meant is that in order to use the license property, we need to 
bump the setuptools version dependency in pyproject.toml so we're sure 
we're building with a recent enough setuptools.

Let me know if something isn't clear, I just happened to have had a 
glance at the PEP this morning for another project, so I am as confident 
as someone who spent 5min reading a spec :)

Cheers,
Quentin

Re: [PATCH 2/2] tools: Update the license specifiers

[Tom Rini]

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

On Tue, Apr 29, 2025 at 04:04:32PM +0200, Quentin Schulz wrote:
> Hi Tom,
> 
> On 4/29/25 3:52 PM, Tom Rini wrote:
> > On Tue, Apr 29, 2025 at 03:28:35PM +0200, Quentin Schulz wrote:
> > > Hi Simon,
> > > 
> > > On 4/29/25 3:15 PM, Simon Glass wrote:
> > > > Recent versions of Python complain about the license being in the
> > > 
> > > I believe this isn't related to Python but rather setuptools.
> > > 
> > > setuptools 77.0.3 and later support PEP-639 which recommends to ditch the
> > > License :: classifier for a license property.
> > > 
> > > The issue is that this license property also changed in PEP-639, with
> > > something that isn't compatible with pre-PEP-639.
> > > 
> > > Therefore we need to bump the minimum requirement for the setuptools
> > > dependency in the various pyproject.toml to 77.0.3 or later.
> > > 
> > > I'm also wondering if we don't need to add a license-files property (also
> > > PEP-639) to comply with the GPL-2.0-or-later which requires to provide a
> > > copy of the license.
> > 
> > Thanks for digging in to this more. Is there not some way to both meet
> > the PEP and utilize SPDX?
> > 
> 
> AFAICT, the license field is for the SPDX identifier.
> 
> Not all licenses require you to provide the license to comply with it I
> guess? But my reading of GPL-2.0-or-later makes me believe that we need to.
> You would then have the license file(s) included when license-files contains
> a file that is found at the root of the python project? I believe that the
> default value for license-files is ['LICEN[CS]E*', 'COPYING*', 'NOTICE*',
> 'AUTHORS*'] so it could be automatically included (and thus the
> license-files not be explicit) if the license file(s) is named like that.
> 
> It isn't necessarily a big deal (IANAL) to not have the license shipped if
> we don't plan on pushing those to pypi or share sdist/wheels through another
> mean (e.g. GitLab/GitHub releases generated with `python3 -m build`)?
> 
> I am not sure exactly what you meant by "both meet the PEP and utilize SPDX"
> as I believe they aren't related here? I mean, license property is the way
> to define the SPDX identifier in PEP-639, but the missing license-files
> doesn't have anything to do with SPDX I believe? Just that it wouldn't be
> complying (I believe, still haven't become a lawyer in the last few
> paragraphs) with the license itself if the license file isn't shipped.
> 
> What I meant is that in order to use the license property, we need to bump
> the setuptools version dependency in pyproject.toml so we're sure we're
> building with a recent enough setuptools.
> 
> Let me know if something isn't clear, I just happened to have had a glance
> at the PEP this morning for another project, so I am as confident as someone
> who spent 5min reading a spec :)

Thanks for explaining more. I misunderstood for a moment. Yes, we still
have "Licenses/gpl-2.0.txt" in-tree as the license text itself so we can
point at that I hope.

-- 
Tom

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

Re: [PATCH 1/2] tools/make_pip.sh: Use debian packages instead of pip

[Quentin Schulz]

Hi Simon,

On 4/29/25 3:15 PM, Simon Glass wrote:
> Recent distros complain about using 'pip install'. Adjust the script to
> use 'apt get' instead where possible/required (e.g. with Ubuntu 24.04).
> 

I believe this should already be handled by 9d3f1ebaf875 
("tools/make_pip: Use venv when invoking pip")?

Cheers,
Quentin