[AUH] python3-setuptools-scm: upgrading to 10.3.4 FAILED

Hello,

this email is a notification from the Auto Upgrade Helper
that the automatic attempt to upgrade the recipe(s) *python3-setuptools-scm* to *10.3.4* has Failed(do_compile).

Detailed error information:

do_compile failed



Next steps:
    - apply the patch: git am 0001-python3-setuptools-scm-upgrade-10.2.3-10.3.4.patch
    - check the changes to upstream patches and summarize them in the commit message,
    - compile an image that contains the package
    - perform some basic sanity tests
    - amend the patch and sign it off: git commit -s --reset-author --amend
    - send it to the appropriate mailing list

Alternatively, if you believe the recipe should not be upgraded at this time,
you can fill RECIPE_NO_UPDATE_REASON in respective recipe file so that
automatic upgrades would no longer be attempted.

Please review the attached files for further information and build/update failures.
Any problem please file a bug at https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Automated%20Update%20Handler

Regards,
The Upgrade Helper

-- >8 --
From 1a17031af146f7cb8d7ad376e628bad0d4de2338 Mon Sep 17 00:00:00 2001
From: Upgrade Helper <auh@yoctoproject.org>
Date: Thu, 24 Sep 2026 05:15:56 +0000
Subject: [PATCH] python3-setuptools-scm: upgrade 10.2.3 -> 10.3.4

## 10.3.4 (2026-09-23)
### Fixed

- Ship the tracked files of projects whose `pyproject.toml` sits in a
  subdirectory
  of the checkout. `root` defaults to the project directory, so version
  inference
  correctly finds no SCM there and answers from `SETUPTOOLS_SCM_PRETEND_VERSION`
  or `fallback_version` -- but that says nothing about which files git tracks,
  and
  the sdist and wheel came out with none of them. This was the 10.3.0 regression
  fixed in 10.3.3, surviving in the subdirectory layout.

  File discovery now follows the checkout the project sits in, independently of
  the `root` that scopes versioning, and records `scm_file_list.json` in the
  egg-info as a root-level project already did. ([#1543]( ))
- Require `vcs-versioning>=2.5.0`. The subdirectory file-discovery fix (#1543)
  imports
  `discover_file_workdir`, which no earlier release has, while the declared
  floor still
  named 2.4.0 -- an install against a published vcs-versioning raised
  `ImportError`
  during the build. ([#1546]( ))

## 10.3.3 (2026-09-16)
### Fixed

- Keep file discovery working when the version is pretended.
  `SETUPTOOLS_SCM_PRETEND_VERSION` and its scoped `_FOR_<DIST>` form made
  version inference return before discovering a workdir, and the `egg_info`
  mixin read the absent workdir as "searched, found no checkout" -- the signal
  it acts on by suppressing the `setuptools.file_finders` chain. Every
  SCM-tracked file that setuptools' own package discovery does not find was
  then dropped from the sdist and the wheel, silently, since the build
  succeeded and the version was correct.

  A pretended version still skips discovery, because most builds only want a
  version and probing for a checkout nobody asks about costs subprocesses for
  nothing. What no longer happens is passing that off as an answer: "nobody
  looked yet" is now distinct from "looked and found nothing", and the workdir
  is discovered on demand the first time a consumer needs a file list.

  `scm_file_list.json` is now written to the egg-info for pretended builds as
  well. It describes which files the checkout tracks, which a pretended
  version says nothing about. `scm_version.json` stays absent there, because
  a pretended version must not be recorded as what the SCM said. ([#1540]( ))

## 10.3.2 (2026-09-14)
### Fixed

- Stop the command mixins from reordering a project's own ``build_py``,
  ``egg_info``
  or ``bdist_wheel`` MRO. ``ScmVersionFileMixin`` and friends inherited from the
  corresponding setuptools command, so wrapping a project class built on a
  disjoint
  hierarchy -- ``distutils.command.build_py``, or the standalone ``wheel``
  package's
  ``bdist_wheel`` -- placed setuptools' command *ahead* of the project's class.
  ``setuptools.build_py.run()`` does not delegate any further, so the project's
  ``run()`` was silently skipped, surfacing as
  ``error: package directory '...' does not exist``. The mixins now carry no
  runtime
  base class and linearise to ``(wrapped, mixin, *project_command.__mro__)``.
  ([#1531]( ))
- Leave a project's ``cmdclass`` alone when setuptools-scm is installed but not
  actually inferring a version. ``build_py``, ``egg_info`` and ``bdist_wheel``
  are
  now registered only once version inference has stored data on the distribution
  --
  the precondition for any of the mixins doing something. Previously every
  project
  with a ``pyproject.toml`` had its commands wrapped, including projects with no
  ``[tool.setuptools_scm]`` section at all.

  Note for projects that *used* to configure setuptools-scm and no longer do: a
  ``scm_version.json`` left behind in a stale ``*.egg-info`` directory is no
  longer
  stripped from built wheels, because the ``bdist_wheel`` mixin that strips it
  is no
  longer registered either. Remove the stale ``*.egg-info`` directory. ([#1533](
  ))

## 10.3.1 (2026-09-14)
### Fixed

- Require ``vcs-versioning>=2.4.0``. setuptools-scm 10.3.0 declared ``>=2.3.2``
  but
  imports ``vcs_versioning._file_finders.scm_search_known_failed``, which vcs-
  versioning
  only gained in 2.4.0, so installing it alongside an older vcs-versioning
  failed with
  ``ImportError``. CI now installs setuptools-scm against the oldest vcs-
  versioning its
  metadata permits, so the lower bound can no longer go stale unnoticed.
  ([#1528]( ))

## 10.3.0 (2026-09-12)
### Deprecated

- Emit a ``DeprecationWarning`` when the ``setuptools.file_finders`` entry point
  is invoked for a project that does not configure setuptools-scm. The entry
  point will be removed in a future major release. ([#1407]( ))

### Fixed

- Run the `setuptools.file_finders` hook inside a setuptools-scm override
  context. It previously resolved settings under the `VCS_VERSIONING` prefix
  only, so documented variables such as `SETUPTOOLS_SCM_SUBPROCESS_TIMEOUT` and
  `SETUPTOOLS_SCM_HG_COMMAND` were ignored when finding files.

  When version inference has already run and found no SCM checkout, the
  `egg_info` mixin

[Changelog truncated as it exceeds 5000 characters;
the full changelog can be found in an attachment to the AUH email]
---
 ...etuptools-scm_10.2.3.bb => python3-setuptools-scm_10.3.4.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-devtools/python/{python3-setuptools-scm_10.2.3.bb => python3-setuptools-scm_10.3.4.bb} (89%)