Nice one nuking the image BTW, did that land a little close to home?

(see above post)

maybe you are getting paid for your efforts.

I have posted the information required to solve the OPs problem, because nobody else was doing that. As a result, this thread is now [SOLVED].
What did you contribute here?

It looks like there you have a task to volunteer for.

You mean giving the forum autoresponder gramophone a whack, because it's stuck again?

There is no "licencing problem". Some APIs were deprecated or moved to external packages, that is all.

But apparently not reading, because g4sra already explained that.

As usual, a bunch of whinging and finger pointing about "them", "forced" changes, "clusterfuck" upstreams, and a bit of misdirection regarding "awful licence changes"...
While the real problem is right in our back yard, and has nothing to do with any of the favourite punching-bags. Nothing ever changes around here, does it?

But which package has the licensing problem? And if its python itself, say so.

If so, does this mean python has a problematic license like rust or java?

Asking...

@OP, make sure all your jails are using the 'polling', 'pyinotify' (if you have that installed) or 'auto' backends.

I had my backends set to "auto", and I even tried "polling".  I have not tried "pyinotify" yet, but if it works, I will report back here.

EDIT:  I installed

and it worked! 

In my jail.local file I have the backend set at:

Maybe the package does not need to be rebuilt, yet, but when this issue comes up again with someone else, pass the word about a missing dependency in devuan "python3-pyinotify"

Someone needs to port fail2ban to the newer python version

Upstream fail2ban already has compatibility with python 3.13 (inc. bundling the async modules removed with python 3.12), said upstream version (1.1.0) is in trixie, and there appear to be no relevant reports on the Debian BTS...

If you're going to claim "well known and all over the internet", perhaps provide some examples?

Given that the only hits I can get for that exact error are 1: this thread, and 2: an artix user from 5 years ago, and there's no noise about this at all over on FDN, I'm far more inclined to think this has to do with python-systemd and Devuan packaging / shipped configs than anything else.

Ed. Yup, sure enough, again:

$ diff fail2ban_1.0.2-2_all/data/etc/fail2ban/paths-debian.conf fail2ban_1.1.0-8_all/data/etc/fail2ban/paths-debian.conf 
30a31,41
> 
> # In Debian, these services will log to the journal via syslog, so use the
> # journal by default.
> syslog_backend = systemd
> sshd_backend = systemd
> dropbear_backend = systemd
> proftpd_backend = systemd
> pureftpd_backend = systemd
> wuftpd_backend = systemd
> postfix_backend = systemd
> dovecot_backend = systemd

$ diff fail2ban_1.0.2-2_all/data/etc/fail2ban/jail.d/defaults-debian.conf fail2ban_1.1.0-8_all/data/etc/fail2ban/jail.d/defaults-debian.conf
0a1,4
> [DEFAULT]
> banaction = nftables
> banaction_allports = nftables[type=allports]
> 
1a6,7
> backend = systemd
> journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd

That's not going to work, now is it? Nice job Devuan packaging team merging stuff from debian without testing it bot, great catch. Definitely fixing all the systemd things for this premiere systemd-free distro.

@OP, make sure all your jails are using the 'polling', 'pyinotify' (if you have that installed) or 'auto' backends. This might not be your problem, but I suspect it is based on where that error appears to be coming from...
Either way though: Blindingly obvious excalibur packaging fail. If it doesn't cause problems here, it will later.

What is coming down the line....
https://docs.python.org/3/deprecations/index.html

Someone needs to port fail2ban to the newer python version forced on it by trixie.

Indeed ...

And then, there's also this bit:

Right on the dot.  8^)

Best,

A.