Dear package maintainer, this bugzilla is automated becasue the number of impacted packages it too high to go trough manually. It appears that your package uses the deprecated %py3_build and/or %py3_install macro. See https://fedoraproject.org/wiki/Changes/DeprecateSetuppyMacros for why the macros are deprecated. %py3_install expands to python setup.py install. This has been a deprecated command for 5 years and will likely stop working in Fedora 45. Please migrate to %pyproject_buildrequires + %pyproject_wheel + %pyproject_install macros instead. See https://fedoraproject.org/wiki/Changes/DeprecateSetuppyMacros#Migrating_to_%pyproject_macros for migration guide. See https://github.com/hroncok/pyprojectize/ for a tool that can help you automate the migration. Thank you. Let me know if you need help.
Might need some help with this one... The install seems to be going into a subdirectory of BUILD instead of %buildroot%, is this the default behavior? Going into the mock buildroot I found: /builddir/build/BUILD/fail2ban-1.1.0-build/BUILDROOT Which is causing manual modifications in %install to fail.
/builddir/build/BUILD/fail2ban-1.1.0-build/BUILDROOT is normal since RPM 4.20 What failures do you get? Could you share your specfile? What if you opened a [WIP] (Work In Progress) Pull Request so I can check out both?
In %install there is some manual manipulation/removal of conf files for non-linux systems using %buildroot% which started failing after conversion. I'll take another look.
Been chasing CMake 4.0 and FTBFS bugs but trying to get back to this. So the project still builds "fine" before pyprojectize, but afterwards I get the following error: + rm '/builddir/build/BUILD/fail2ban-1.1.0-build/BUILDROOT/etc/fail2ban/action.d/*ipfw.conf' rm: cannot remove '/builddir/build/BUILD/fail2ban-1.1.0-build/BUILDROOT/etc/fail2ban/action.d/*ipfw.conf': No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.YUFI5b (%install) The relevant part of the spec file is here: # Remove non-Linux actions rm %{buildroot}%{_sysconfdir}/%{name}/action.d/*ipfw.conf rm %{buildroot}%{_sysconfdir}/%{name}/action.d/{ipfilter,pf,ufw}.conf rm %{buildroot}%{_sysconfdir}/%{name}/action.d/osx-*.conf It looks like the files are no longer installed after pyprojectize, in fact /etc/fail2ban doesn't exist in the build at all. Need to investigate more.
Ok, that's the problem, nothing is being installed: + /usr/bin/python3 -m pip install --root /builddir/build/BUILD/fail2ban-1.1.0-build/BUILDROOT --prefix /usr --no-deps --disable-pip-version-check --progress-bar off --verbose --ignore-installed --no-warn-script-location --no-index --no-cache-dir --find-links /builddir/build/BUILD/fail2ban-1.1.0-build/fail2ban-1.1.0/pyproject-wheeldir fail2ban==1.1.0 Using pip 25.1.1 from /usr/lib/python3.14/site-packages/pip (python 3.14) Looking in links: /builddir/build/BUILD/fail2ban-1.1.0-build/fail2ban-1.1.0/pyproject-wheeldir Processing ./pyproject-wheeldir/fail2ban-1.1.0-py3-none-any.whl Installing collected packages: fail2ban Successfully installed fail2ban-1.1.0
grep -ir wheel fail2ban-1.1.0/ produces no results, is this the problem?
Richard - as miro stated, a WIP PR would be very helpful. I've also asked for additional help in the Fedora python ML.
I both love and hate git... It's annoying to have to fork a whole repo just to share things... Rant over... It's basically stock Rawhide + pyprojectize at this point. The project seems to %build but %install completes successfully while doing nothing.
So... wheel-based installations cannot install files outside of prefix. /etc is not in /usr, so this does not work. There is no way to represent such files in wheel. The same applies to /var/run/fail2ban. Then there is /usr/share/doc/fail2ban in https://github.com/fail2ban/fail2ban/blob/bf4903538d619bfde2264b2c10dcf57a4e4c8df1/setup.py#L183 -- that can be replaced with a relative path within prefix, i.e. share/doc/fail2ban Unfortunately, wheels are not designed to handle arbitrary file locations. Such files need to be located in prefix and then mv'ed in %install by an upstream-provided script/tool or downstream package maintainer.
Trying to get back to this now that most of the other Python/CMake 4.0/FTBFS has been handled. So basically we're moving to a system/method that can't actually work for some subset of packages on Fedora. It looks like %build is working as far as I can tell so I may be better off manually installing after that.
Not thrilled about the workarounds but it's done and built in rawhide. Did some rpmdiff's from current rawhide as this is a pretty sensitive package and think it's OK at this point.