diff mbox series

[v2] python3-roman-numerals-py: upgrade 3.1.0 -> 4.1.0

Message ID 20260108014101.1974-1-liuyd.fnst@fujitsu.com
State Changes Requested
Headers show
Series [v2] python3-roman-numerals-py: upgrade 3.1.0 -> 4.1.0 | expand

Commit Message

Yiding Liu (Fujitsu) Jan. 8, 2026, 1:41 a.m. UTC 
1.Changelog:
  Restore LICENCE.rst in the roman-numerals-py meta-package
  Add some debug assertions for unsafe blocks

2.Add bbclass python_setuptools_build_meta to solve following error:
  pyproject_hooks._impl.BackendUnavailable: Cannot import 'setuptools.build_meta'
  ERROR Backend 'setuptools.build_meta' is not available.

Signed-off-by: Liu Yiding <liuyd.fnst@fujitsu.com>
---
 ...umerals-py_3.1.0.bb => python3-roman-numerals-py_4.1.0.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-devtools/python/{python3-roman-numerals-py_3.1.0.bb => python3-roman-numerals-py_4.1.0.bb} (68%)

Comments

Paul Barker Jan. 8, 2026, 9:46 a.m. UTC | #1 
On Thu, 2026-01-08 at 09:41 +0800, Yiding Liu (Fujitsu) via
lists.openembedded.org wrote:
> 1.Changelog:
>   Restore LICENCE.rst in the roman-numerals-py meta-package
>   Add some debug assertions for unsafe blocks
> 
> 2.Add bbclass python_setuptools_build_meta to solve following error:
>   pyproject_hooks._impl.BackendUnavailable: Cannot import 'setuptools.build_meta'
>   ERROR Backend 'setuptools.build_meta' is not available.

Thanks for adding the extra info.

However, this doesn't explain why we now need the setuptools.build_meta
backend, we should say what upstream change caused this. This caused me
to look at the upstream v4.0.0 release notes and I found:

  - Rename Python package to roman-numerals on PyPI.
  - Publish roman-numerals-py as a meta-package that depends on
    roman-numerals and installs no modules.

So I'm not sure we can take the new version as-is, the roman-numerals-py
package is now empty.

It looks like this recipe is here to support python3-sphinx, have you
tested that still works after this update?

As a side note, when we upgrade a recipe across multiple upstream
versions we should include the changelog entries in our commit message
for each version we skip across, especially if there's a major version
bump in there as it's often because of some backwards incompatibility.

Best regards,
Alexander Kanavin Jan. 8, 2026, 9:49 a.m. UTC | #2 
On Thu, 8 Jan 2026 at 10:46, Paul Barker via lists.openembedded.org
<paul=pbarker.dev@lists.openembedded.org> wrote:
> As a side note, when we upgrade a recipe across multiple upstream
> versions we should include the changelog entries in our commit message
> for each version we skip across, especially if there's a major version
> bump in there as it's often because of some backwards incompatibility.

I'd clarify this a bit: either there's a complete changelog for each
in-between version, or no changelog at all. It can be tedious to
produce them, especially if there's a lot of recipes updates in a
patchset, and it's not a strict requirement.

Alex
Paul Barker Jan. 8, 2026, 9:52 a.m. UTC | #3 
On Thu, 2026-01-08 at 10:49 +0100, Alexander Kanavin via
lists.openembedded.org wrote:
> On Thu, 8 Jan 2026 at 10:46, Paul Barker via lists.openembedded.org
> <paul=pbarker.dev@lists.openembedded.org> wrote:
> > As a side note, when we upgrade a recipe across multiple upstream
> > versions we should include the changelog entries in our commit message
> > for each version we skip across, especially if there's a major version
> > bump in there as it's often because of some backwards incompatibility.
> 
> I'd clarify this a bit: either there's a complete changelog for each
> in-between version, or no changelog at all. It can be tedious to
> produce them, especially if there's a lot of recipes updates in a
> patchset, and it's not a strict requirement.

You're right, it can be tedious. We need to be careful in cases like
this where an upgrade from v3.1 to v4.1 skips over a v4.0 major version
with significant things in the release notes.

Best regards,
Mathieu Dubois-Briand Jan. 8, 2026, 11:35 a.m. UTC | #4 
On Thu Jan 8, 2026 at 2:41 AM CET, Yiding Liu (Fujitsu) via lists.openembedded.org wrote:
> 1.Changelog:
>   Restore LICENCE.rst in the roman-numerals-py meta-package
>   Add some debug assertions for unsafe blocks
>
> 2.Add bbclass python_setuptools_build_meta to solve following error:
>   pyproject_hooks._impl.BackendUnavailable: Cannot import 'setuptools.build_meta'
>   ERROR Backend 'setuptools.build_meta' is not available.
>
> Signed-off-by: Liu Yiding <liuyd.fnst@fujitsu.com>
> ---

Hi Liu,

Thanks for your patch.

Building btrf seems to be broken by this update:

ERROR: btrfs-tools-6.17.1-r0 do_compile: Execution of '/srv/pokybuild/yocto-worker/qemux86-world-alt/build/build/tmp/work/x86-64-v3-poky-linux/btrfs-tools/6.17.1/temp/run.do_compile.1347185' failed with exit code 1
...
| Extension error!
|
| Versions
| ========
|
| * Platform:         linux; (Linux-6.14.5-100.fc40.x86_64-x86_64-with-glibc2.42)
| * Python version:   3.13.11 (CPython)
| * Sphinx version:   9.1.0
| * Docutils version: 0.22.4
| * Jinja2 version:   3.1.6
| * Pygments version: 2.19.2
|
| Last Messages
| =============
|
| None.
|
| Loaded Extensions
| =================
|
| None.
|
| Traceback
| =========
|
|       File "/srv/pokybuild/yocto-worker/qemux86-world-alt/build/build/tmp/work/x86-64-v3-poky-linux/btrfs-tools/6.17.1/recipe-sysroot-native/usr/lib/python3.13/site-packages/sphinx/registry.py", line 553, in load_extension
|         raise ExtensionError(
|             __('Could not import extension %s') % extname, err
|         ) from err
|     sphinx.errors.ExtensionError: Could not import extension sphinx.builders.latex (exception: No module named 'roman_numerals')

https://autobuilder.yoctoproject.org/valkyrie/#/builders/17/builds/2834

Can you have a look at this issue?

Thanks,
Mathieu
Yiding Liu (Fujitsu) Jan. 9, 2026, 9:35 a.m. UTC | #5 
Hi Mathieu
    I tryed to bitbake btrfs-tools to reproduce this error, But I can't reproduce it.

    Could share you local.conf with me?

Thanks
Liu
________________________________
发件人: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
发送时间: 2026年1月8日 19:35
收件人: Liu, Yiding/刘 乙丁 <liuyd.fnst@fujitsu.com>; openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org>
主题: Re: [OE-core][PATCH v2] python3-roman-numerals-py: upgrade 3.1.0 -> 4.1.0

On Thu Jan 8, 2026 at 2:41 AM CET, Yiding Liu (Fujitsu) via lists.openembedded.org wrote:
> 1.Changelog:
>   Restore LICENCE.rst in the roman-numerals-py meta-package
>   Add some debug assertions for unsafe blocks
>
> 2.Add bbclass python_setuptools_build_meta to solve following error:
>   pyproject_hooks._impl.BackendUnavailable: Cannot import 'setuptools.build_meta'
>   ERROR Backend 'setuptools.build_meta' is not available.
>
> Signed-off-by: Liu Yiding <liuyd.fnst@fujitsu.com>
> ---

Hi Liu,

Thanks for your patch.

Building btrf seems to be broken by this update:

ERROR: btrfs-tools-6.17.1-r0 do_compile: Execution of '/srv/pokybuild/yocto-worker/qemux86-world-alt/build/build/tmp/work/x86-64-v3-poky-linux/btrfs-tools/6.17.1/temp/run.do_compile.1347185' failed with exit code 1
...
| Extension error!
|
| Versions
| ========
|
| * Platform:         linux; (Linux-6.14.5-100.fc40.x86_64-x86_64-with-glibc2.42)
| * Python version:   3.13.11 (CPython)
| * Sphinx version:   9.1.0
| * Docutils version: 0.22.4
| * Jinja2 version:   3.1.6
| * Pygments version: 2.19.2
|
| Last Messages
| =============
|
| None.
|
| Loaded Extensions
| =================
|
| None.
|
| Traceback
| =========
|
|       File "/srv/pokybuild/yocto-worker/qemux86-world-alt/build/build/tmp/work/x86-64-v3-poky-linux/btrfs-tools/6.17.1/recipe-sysroot-native/usr/lib/python3.13/site-packages/sphinx/registry.py", line 553, in load_extension
|         raise ExtensionError(
|             __('Could not import extension %s') % extname, err
|         ) from err
|     sphinx.errors.ExtensionError: Could not import extension sphinx.builders.latex (exception: No module named 'roman_numerals')

https://autobuilder.yoctoproject.org/valkyrie/#/builders/17/builds/2834

Can you have a look at this issue?

Thanks,
Mathieu

--
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Alexander Kanavin Jan. 9, 2026, 10:02 a.m. UTC | #6 
On Fri, 9 Jan 2026 at 10:35, Yiding Liu (Fujitsu) via
lists.openembedded.org <liuyd.fnst=fujitsu.com@lists.openembedded.org>
wrote:
>     I tryed to bitbake btrfs-tools to reproduce this error, But I can't reproduce it.
>
>     Could share you local.conf with me?

Note that the error happened in a 'qemux86-world-alt' build. You can
find the config for it here:
https://git.yoctoproject.org/yocto-autobuilder-helper/tree/config.json#n841

I'm fairly sure that the error (which is sphinx-related) is triggered
by this part:

DISTRO_FEATURES:append = ' api-documentation'

Alex
diff mbox series

Patch

diff --git a/meta/recipes-devtools/python/python3-roman-numerals-py_3.1.0.bb b/meta/recipes-devtools/python/python3-roman-numerals-py_4.1.0.bb
similarity index 68%
rename from meta/recipes-devtools/python/python3-roman-numerals-py_3.1.0.bb
rename to meta/recipes-devtools/python/python3-roman-numerals-py_4.1.0.bb
index 9a76df0de2..8689a6315f 100644
--- a/meta/recipes-devtools/python/python3-roman-numerals-py_3.1.0.bb
+++ b/meta/recipes-devtools/python/python3-roman-numerals-py_4.1.0.bb
@@ -3,10 +3,10 @@  HOMEPAGE = "https://github.com/AA-Turner/roman-numerals/"
 LICENSE = "0BSD & CC0-1.0"
 LIC_FILES_CHKSUM = "file://LICENCE.rst;md5=bfcc8b16e42929aafeb9d414360bc2fd"
 
-SRC_URI[sha256sum] = "be4bf804f083a4ce001b5eb7e3c0862479d10f94c936f6c4e5f250aa5ff5bd2d"
+SRC_URI[sha256sum] = "f5d7b2b4ca52dd855ef7ab8eb3590f428c0b1ea480736ce32b01fef2a5f8daf9"
 PYPI_PACKAGE = "roman_numerals_py"
 UPSTREAM_CHECK_PYPI_PACKAGE = "roman_numerals_py"
 
-inherit pypi python_flit_core
+inherit pypi python_flit_core python_setuptools_build_meta
 
 BBCLASSEXTEND = "native nativesdk"