Problems with %py_provides macro

I've just received [1] this bug report about wrong generated Provides for py3dist() and py3.9dist() for package python-pytest-filter-subpackage. It seems that the %py_provides macro doesn't generate the correct Provides. I think I have another case with python-graphql-server [2]. Do you think

Re: Problems with %py_provides macro

> > Consider using https://src.fedoraproject.org/rpms/pyproject-rpm-macros and > generating the buildrequires from pyproject.toml (setuptools_scm is listed > there). Thanks, I tried pyproject-rpm-macros, but it seems that using %generate_buildrequires + %pyproject_buildrequires and then

Migrating python-graphql-server to new guidelines

Hello folks, I'm trying to migrate graphql-server spec file to the newer Python guidelines, but I'm hitting some walls. - Building the package locally went fine, while on Koji [¹] I get: error: line 39: Unknown tag: %pyproject_extras_subpkg -n python3-graphql-server flask webob aiohttp - The

Re: Migrating python-graphql-server to new guidelines

> On Sun, 22 Aug 2021 at 06:06, Mattia Verga wrote: > > The extras macro expands to %package, %description, and %files; you > have put it in between a %package and %description, which will surely > confuse rpm somewhat. > Oh, I've missed that. Thanks. > > You

Need help with build failure

python-calcephpy builds were FTB since between the F39 mass rebuild (which completed fine) and the Cython 3.x change (which started to fail). While I was waiting for upstream to fix the package for compatibility with Cython 3.x I tried to rebuild it forcing cython < 3.0, but I got an odd build

Re: Need help with build failure

Well, I've solved the problem just by adding 'export CPPFLAGS="$CXXFLAGS" at the start of the %build section... I don't think the automatic exports in Fedora build system have changed, did them? Mattia ___ python-devel mailing list --

Headers file in python package

I'm reviewing the un-retirement ticket of python-nss [1] and rpmlint is complaining about header files under the python module directory. The specfile is using the %pyproject_save_files macro to get the file list. I'm unsure if this is a false positive or I must ask the submitter to filter out

getattr default value evaluation

This code: ``` from unittest import TestCase _testcase = TestCase('setUp') getattr(_testcase, 'assertRaisesRegex', _testcase.assertRaisesRegexp) ``` was working in Python 3.11, but doesn't work anymore in 3.12: AttributeError: 'TestCase' object has no attribute 'assertRaisesRegexp'. Did you mean:

python macros inconsistency between Fedora and EPEL9

In the test section of libindi package I use this to run tests: %ctest --test-dir %_vpath_builddir/test This translates in Fedora as: + /usr/bin/ctest --test-dir redhat-linux-build --output-on-failure --force-new-ctest-process -j6 --test-dir redhat-linux-build/test Internal ctest changing into

Re: python macros inconsistency between Fedora and EPEL9

> On 03. 06. 23 13:29, Mattia Verga wrote: > > It's not in epel because it is in RHEL. > > > I have no idea. What makes you suspect this problem is related to *Python* > macros at all? %ctest is defined in /usr/lib/rpm/macros.d/macros.cmake which > is >

Broken %pyproject_buildrequires parser

While trying to update python-rpds-py I came across this commit: https://github.com/crate-py/rpds/commit/27d6caf11aac8170e2e9fd56042f05ab27cdb580 The 'file:.#egg=rpds-py' breaks %pyproject_buildrequires parser... what's the best way to fix/patch it? --

Re: Broken %pyproject_buildrequires parser

> I think I would just do something like this in %prep: > > sed -r -i 's/^file:/# &/' tests/requirements.in > Thanks, that did it. Is this something broken in upstream code, or is it our parser that needs to be adjusted? I couldn't find the relevant pip documentation about 'file:.#egg='