Bug 2225799

Summary: fail2ban: FTBFS in Fedora rawhide/f39
Product: [Fedora] Fedora Reporter: Fedora Release Engineering <releng>
Component: fail2banAssignee: Richard Shaw <hobbes1069>
Status: ASSIGNED --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 39CC: anon.amish, hobbes1069, orion, tmz, vonsch
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 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: 2168842, 2231791    
Attachments:
Description Flags
build.log
none
root.log
none
state.log none

Description Fedora Release Engineering 2023-07-25 17:37:25 UTC
fail2ban failed to build from source in Fedora rawhide/f39

https://koji.fedoraproject.org/koji/taskinfo?taskID=103572923


For details on the mass rebuild see:

https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
Please fix fail2ban at your earliest convenience and set the bug's status to
ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks,
fail2ban will be orphaned. Before branching of Fedora 40,
fail2ban will be retired, if it still fails to build.

For more details on the FTBFS policy, please visit:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

Comment 1 Fedora Release Engineering 2023-07-25 17:37:32 UTC
Created attachment 1977870 [details]
build.log

file build.log too big, will only attach last 32768 bytes

Comment 2 Fedora Release Engineering 2023-07-25 17:37:39 UTC
Created attachment 1977871 [details]
root.log

file root.log too big, will only attach last 32768 bytes

Comment 3 Fedora Release Engineering 2023-07-25 17:37:42 UTC
Created attachment 1977872 [details]
state.log

Comment 4 Todd Zullinger 2023-07-30 14:44:38 UTC
I haven't tried either of these ideas, so they may both be fatally flawed or just more effort than they're worth...

Could we either a) bundle the python asyncore and asynchat modules from python 3.11 or b) build against python3.11?

Just until upstream fail2ban is able to convert to asyncio (which seems like it could be a good part of the f39 lifecycle).

Bundling the libraries is a smaller change, but more likely to require some effort in making the bundled libraries work with python3.12, while building against python3.11 is a bigger hammer but probably less packaging effort.

Comment 5 Todd Zullinger 2023-07-30 17:16:05 UTC
I gave the bundling a try.  The current status is at https://src.fedoraproject.org/fork/tmz/rpms/fail2ban/commits/python3.12, with ff7b736 (tests: remove test_smtp, smtpd was removed in python-3.12, 2023-07-30) as the tip of the branch.

The last scratch build I ran is https://koji.fedoraproject.org/koji/taskinfo?taskID=104143285

There is a failing test which I'm not sure is related to the asyncore/asynchat or smtpd removals in python 3.12, but I am out of time to keep poking it for now:

FAIL: testRepairDb (fail2ban.tests.databasetestcase.DatabaseTest.testRepairDb)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/fail2ban-1.0.2/fail2ban/tests/databasetestcase.py", line 138, in testRepairDb
    self.assertLogged("Repair seems to be successful",
  File "/builddir/build/BUILD/fail2ban-1.0.2/fail2ban/tests/utils.py", line 816, in assertLogged
    self.fail("%r was not found in the log%s: ===\n%s===" % (s_,
AssertionError: 'Repair seems to be successful' was not found in the log: ===
===== [test-repair], next phase - file-size: 14000 =====
Connected to fail2ban persistent database '/tmp/fail2ban_kju3379o.db'
Error opening fail2ban persistent database '/tmp/fail2ban_kju3379o.db': database disk image is malformed
Trying to repair database /tmp/fail2ban_kju3379o.db
  Database backup created: /tmp/fail2ban_kju3379o.db.20230730-162449
f3483d08 -- exec: ('f2b_db=$0; f2b_dbbk=$1; sqlite3 "$f2b_dbbk" ".dump" | sqlite3 "$f2b_db" ', '/tmp/fail2ban_kju3379o.db', '/tmp/fail2ban_kju3379o.db.20230730-162449')
f3483d08 -- returned successfully 0
  Repair seems to be failed, restored 0 byte(s).
  Error repairing of fail2ban database '/tmp/fail2ban_kju3379o.db': Recreate ...
Connected to fail2ban persistent database '/tmp/fail2ban_kju3379o.db'
New database created. Version '4'
  Create missing tables/indices ...
  -> ok
  Check integrity ...
  -> ok
===
----------------------------------------------------------------------
Ran 496 tests in 18.534s
FAILED (failures=1, skipped=12)

Comment 6 Fedora Release Engineering 2023-08-16 07:56:04 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.