Bug 2097535

Created attachment 1890458 [details]
Build log

The macros execute what is given to them in upstream code. Here, they call the setup.py script through the setuptools.build_meta build backend specified in pyproject.toml.

My guess is that https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects is not correctly handled in the %pyproject_buildrequires section.



Anyway, I fail to reproduce because of:


No matching package to install: 'python3dist(xkbcommon) >= 0.2'

Actually:

No matching package to install: 'python3dist(pywayland) >= 0.1.1'
No matching package to install: 'python3dist(xkbcommon) >= 0.2'

My bad, sorry about that. 
The dependencies are available in this Copr project
https://copr.fedorainfracloud.org/coprs/frostyx/qtile/

Will try. In the meantime, several notes about the spec file, some of them might be relevant to the problem.


Requires:  wlroots -> this line does nothing because it is not in the python3-pywlroots %package section.


python3 -m build --wheel --no-isolation -> this should not be needed at all because %pyproject_wheel does that instead.


python3 wlroots/ffi_build.py -> if this is *required* and not just convenient, the upstream build is not PEP 517 compatible and thus cannot work wth the pyproject macros.


%pyproject_save_files '*' +auto -> this is forbidden in official Fedora packages.

https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects is not correctly handled in %pyproject_buildrequires -- this will bite any package that builds extension modules in %pyproject_buildrequires -- e.g. any package using %pyproject_buildrequires -w.

This works around the problem:

%undefine _package_note_flags

And this is a specfile that works:




Name:           python-pywlroots
Version:        0.15.17
Release:        1%{?dist}
Summary:        Python binding to the wlroots library using cffi

License:        MIT
URL:            https://github.com/flacjacket/pywlroots
Source:         %{pypi_source pywlroots}

BuildRequires:  python3-devel
BuildRequires:  gcc
BuildRequires:  wlroots-devel >= 0.15

# https://bugzilla.redhat.com/show_bug.cgi?id=2097535
%undefine _package_note_flags

%global _description %{expand:
A Python binding to the wlroots library using cffi. The library uses pywayland
to provide the Wayland bindings and python-xkbcommon to provide wlroots
keyboard functionality.}


%description %_description

%package -n     python3-pywlroots
Summary:        %{summary}
Requires:       wlroots

%description -n python3-pywlroots %_description


%prep
%autosetup -p1 -n pywlroots-%{version}


%generate_buildrequires
%pyproject_buildrequires


%build
%pyproject_wheel


%install
%pyproject_install
%pyproject_save_files '*' +auto


%check
%pyproject_check_import -t


%files -n python3-pywlroots -f %{pyproject_files}

Zbyszek,

the %pyproject_buildrequires macro is to be executed in the %generate_buildrequires section. It contains:
	
    # The _auto_set_build_flags feature does not do this in %%generate_buildrequires section,
    # but we want to get an environment consistent with %%build:
    %{?_auto_set_build_flags:%set_build_flags}

We need all the flags set as they are in %build, in order to generate extension modules that are ready to be installed if needed.

However, package information on ELF objects makes this blow up when extension modules are actually built, with:

/usr/bin/ld: cannot open linker script file /builddir/build/BUILD/pywlroots-0.15.17/.package_note-python-pywlroots-0.15.17-1.fc37.x86_64.ld: No such file or directory


Do we also need to stick something like this in?

    %{?_package_note_flags:%_generate_package_note_file}

Is that idempotent?

Ok, this works:

%generate_buildrequires
%{?_package_note_flags:%_generate_package_note_file}
%pyproject_buildrequires


And this also works:

%generate_buildrequires
%{?_package_note_flags:%_generate_package_note_file}
%{?_package_note_flags:%_generate_package_note_file}
%{?_package_note_flags:%_generate_package_note_file}
%{?_package_note_flags:%_generate_package_note_file}
%{?_package_note_flags:%_generate_package_note_file}
%pyproject_buildrequires


So I think it is safe to add it.

https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/292

FEDORA-2022-d857c5b521 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-d857c5b521

FEDORA-2022-d857c5b521 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2022-49880f29f9 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-49880f29f9

FEDORA-2022-de6aa089a7 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-de6aa089a7

FEDORA-2022-49880f29f9 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-49880f29f9`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-49880f29f9

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-de6aa089a7 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-de6aa089a7`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-de6aa089a7

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-de6aa089a7 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2022-49880f29f9 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.