Well, I tested on CentOS-9 Stream, and it Works For Me, so I will release it. Please report bugs.

Needed this for cjdns-tools and nodejs-marked

cjdroute now creates a unix socket in /tmp to talk to the core. It looks like an attacker could get lucky and grab the private key without being root:

srwxr-xr-x. 1 root root 0 Jul 1 19:43 /tmp/cjdroute.sock

Boot target is graphical. It works normally (module occasional crashes, on which systemd restarts it). It may be a feature of user services that they are started even when you aren't logged in.

$ lk psi-notify
term=xt,unicode=1
 RUSER        PID STIME TTY        TIME CMD
 root           1 May10 ?          0:07/usr/lib/systemd/systemd --switched-root --system --deserialize 29
 stuart      1242 May10 ?          0:05├/usr/lib/systemd/systemd --user
#stuart      2939 May10 ?          0:05│├/usr/bin/psi-notify
 guest       1243 May10 ?          0:05├/usr/lib/systemd/systemd --user
#guest       1276 May10 ?          0:05│└/usr/bin/psi-notify

Generating a backtrace for submitting the crash report fails both for retrace server and locally.

On rebooting, psi-notify is started for every user account, whether logged in or not. Maybe having some running with no gui is why I started getting core-dumps after booting. Each user psi-notify crashes after initial load, then is restarted by systemd.

Upgrading from my prelease version, the user service was not restarted. Maybe this is correct - I don't see how systemd could reasonably restart an arbitrary bunch of user services. There is no practical problem, because the utility is so tiny.

On my desktop with 5400rpm rotating media, it complains about I/O pressure a lot. So it works as advertised.

nsca-client works in production.

Upgrading or reinstalling cjdns on f32 beta crashes the system! (x86_64) Networking is dead, and CAPSLOCK does not toggle indicator light. Looking at journalctl, the crash occurs about 4 secs after cjdns has been successfully restarted, right when man-db-cache-update has been started.

After a power cycle, nothing seems damaged and cjdns functions normally. Restarting cjdns works normally.

CVE-2020-8794 for this important security patch

Seems to still work in peer2peer mode (raw IPv6 addresses instead of domains). I didn't run the exploit, as I only send to trusted peers. But if I get to it, I'll add another comment.

I think I should have kept the python2 package for f30.

Before submitting package, I did install on several el7 production machines and one f31 test VM. But I can't vote.

This update has been unpushed.

I could drop python3 support altogether, or maybe I can make the cjdns-graph subpackage use python2.

This release does not include python2 tools. RHEL8 supports python2 until 2024 (and reduced support thereafter). So I have been isolating the API modules which I can include in a future release (if anyone cares). The command line tools will be python3.

It just occurred to me, I should have at least copied the markdown man pages to the doc directory, even if they can't be turned into man pages. I'll do that on the next release if ronn or an alternative is still not available.

Successfully used to build cjdns for EPEL8.

Works on pine64 (aarch64).