Bug 2377254

Summary:	fail2ban: Stop using deprecated %py3_build/%py3_install macros
Product:	[Fedora] Fedora	Reporter:	Miro Hrončok <mhroncok>
Component:	fail2ban	Assignee:	Richard Shaw <hobbes1069>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	anon.amish, hobbes1069, orion
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2025-08-21 02:15:49 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2376118

Description Miro Hrončok 2025-07-08 14:04:41 UTC

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.

Comment 1 Richard Shaw 2025-07-13 19:51:47 UTC

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.

Comment 2 Miro Hrončok 2025-07-14 07:52:31 UTC

/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?

Comment 3 Richard Shaw 2025-07-14 11:38:39 UTC

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.

Comment 4 Richard Shaw 2025-08-07 12:02:24 UTC

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.

Comment 5 Richard Shaw 2025-08-07 12:04:01 UTC

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

Comment 6 Richard Shaw 2025-08-07 12:08:06 UTC

grep -ir wheel fail2ban-1.1.0/ produces no results, is this the problem?

Comment 7 Orion Poplawski 2025-08-09 02:56:10 UTC

Richard - as miro stated, a WIP PR would be very helpful.  I've also asked for additional help in the Fedora python ML.

Comment 8 Richard Shaw 2025-08-09 12:04:53 UTC

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.

Comment 9 Miro Hrončok 2025-08-11 17:28:17 UTC

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.

Comment 10 Richard Shaw 2025-08-18 12:07:37 UTC

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.

Comment 11 Richard Shaw 2025-08-21 02:15:49 UTC

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.