[shiptux]

Problem

pyproject.toml declares license = "Apache-2.0" and license-files = ["LICENSE"], the PEP 639 form that needs setuptools>=77. The Debian package build uses the distribution's python3-setuptools (68.1.2 on Ubuntu 24.04), which rejects it:

ValueError: invalid pyproject.toml config: `project.license`.
configuration error: `project.license` must be valid exactly by one definition (2 matches found)

The rpm build for openEuler 24.03 (python3-setuptools 65, pip fallback path) fails the same way at Preparing metadata (pyproject.toml); Fedora 43 passes because its setuptools is new enough. So python3-flagsparse deb and the openEuler rpm cannot be built from v0.3.0 (the FlagOS 2.2 release tag) or from main; the v0.3.0-rc2.post1 package built because that tag still had the table form.

Change

license = { text = "Apache-2.0" }, with the license-files key dropped: setuptools includes LICENSE by default, and old versions reject that key as well.

Verified

setuptools	result
68.1.2 (Ubuntu 24.04 python3-setuptools)	wheel builds; LICENSE is in dist-info
84.0.0 (current)	wheel builds, with the deprecation warning (removal not before 2027-02-18)

Test

tests/ci/test_packaging_metadata.py::test_license_metadata_is_apache_2 asserted the string form; it now expects the table form, with the reason next to it. The rest of that file is unchanged (test_package_version_matches_metadata needs the package installed and is not affected).

Also built through the central release path (flagos-ai/build-infra) at this PR head: noarch-deb run 38678034771 (build plus ubuntu22.04/24.04 install verification), passed.

This PR was written in part with the assistance of generative AI.

[shiptux]

Note on when this reaches the package repositories:

• v0.3.0 cannot build the deb or the openEuler rpm, so those repositories keep the 0.3.0~rc2.post1 / 0.3.0-0.rc2.post1 packages; only the fedora43 rpm is at 0.3.0. As it stands (merge to main only), fixed packages ship with FlagOS 2.3 (rc0 2026-11-30, GA 2026-12-30).
• If it is also backported to the 0.3.0-rc2 branch and a v0.3.1 tag is cut (community release process, section 9), 0.3.1 packages can be published for 2.2 right away.