Yeah, figuring it out was kinda fun while it lasted. Now that OpenRC has user-services, I expect that's the way I'll go next time I feel like messing with it.

IMO, for all its other flaws, systemd user-units aren't inherently a bad idea. The trick is, as usual, implementing something comparable without falling into the same scope-creep tarpit.
Devuan is going to need a generic solution sooner or later, if they're willing to embrace OpenRC as a first-class (or even default) init system, it can just be leeched off Gentoo and the solution already in testing.
If they want to cling to sysvinit as the default, we need something else... Which will likely have to be a Devuan project or a colab with Slackware, since pretty much everyone else has moved on from pure sysv.

At the very least, shipping an interim launcher in shell (aka. nicking gentoo-pipewire-launcher) and packaging some simple xdg-autostart files that work with common DEs would go a long way to alleviating the "I installed the default KDE desktop and stuff doesn't work" pain. It's not exactly a lot of work either.

Yeah, and for what it's worth I'm not usually quite as confrontational as I have been lately... This pattern from the admin(s) has been going on a long while, and today I just had a gutsfull of it.
Sorry that it was your intro to this board and all that.

Ahh, personal attacks. The last refuge of the incompetent. Bye go, I'm done arguing with you.

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

Ahh yes, the old "everything new is bad, we're all doomed, my generation knew better, damn kids get off my lawn, why don't we all just die" line. All very helpful and productive I'm sure.

More productively (but probably not diplomatically), if this thread is anything to go by.
If I count correctly, four five, if I'm being generous users have piped up with technical support for this technical question, and through their efforts the problem is now solved. You are not one of them, nor have you offered any relevant information or technical assistance. Same goes for zapper.

Resampling is necessary in many run-of-the-mill scenarios. If all you want is to play one stream, that can be done with no resampling. If you want the kind of automagic mixing of multiple inputs and outputs with hotplugged devices over bluetooth and dog knows what else that people tend to expect from a modern system... Some resampling will be happening somewhere.

This is one advantage of pipewire over pulseaudio or ALSA DMIX, it tries quite hard to match your stream to a samplerate your hardware supports, and to never downsample anything if it can be avoided.
Whether or not pipewire's spa resampler is suitable for the cases where it is needed... That's up to your (presumably bat-like) ears to decide.

In general though, unless your resampling algo is really bad (or you're using a SoundBlaster 16), your speakers and listening environment will be doing more to screw up reproduction than anything on the source end.

That'll work, but it probably won't play nice with a multi-user/multi-seat system.

Killing processes is a dirty hack to kill lingering pipewire processes after a user logs out - which will tie up the sound devices so that they will have no audio if they log in again. Dirty, because it doesn't solve the root problem of making sure pipewire terminates when the launching user logs out (of possibly multiple sessions etc.).

That's one of the things we need real user-services for, this kind of shell-hackery is all well-and-good for a single-user box, but unix/linux is and always has been multi-user. Getting that to work properly means tying the pipewire daemons to the login seat lifecycle somehow, or hacking pipewire to run as a system-wide service (which it absolutely wasn't designed for).

I already am "elsewhere". I have exactly one headless box still running Devuan, and if the next upgrade is as much of a disaster as I expect it will be, that one will move to Gentoo as well.

As for being pissed... I'm being told to "go code" by a self-important bureaucrat who can't code, and directed to dead channels to engage with absent devs in non-existent onboarding processes.
And they wonder why anyone who might contribute gives up and goes elsewhere. That airfare to amsterdam go is so proud of? That could have paid someone to start sorting out this mess.

Case in point, let's recap 24 hours of the devuan-dev channel:

Let's see... No development, one guy giving up because there's nobody around, and golinux dropping some bureaucratic chaff nobody cares about.
And this is right on a major release window. Trixie just dropped, where is everyone?

Why bother? Even the most stalwart rats must be making for the mooring lines by now, with all possible haste. Might as well join them, no?

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.

So, IOW "There is no formal procedure to become a Devuan contributor."

Why do I even bother. Guess I'll go see if #devuan-dev is still a whole bunch of resounding silence.

Good to know I'm not the only one who has noticed.

The answer(s) to the original question and comments on the situation in general have been covered ad-nauseam in another thread, what else is there to do?

I've been pissed with this whole situation for some time, because nothing at all appears to be happening, and the standard tag-line around here when it comes to systemd-dependent packages is "just don't use them"... While the distro steadily looses functionality and the users steadily loose options.
Systemd is not going to go away, and burying our heads in the sand isn't going to fix anything.
User-units are a thing, and we need a solution. Define what that solution should look like and someone might just provide it.

EDX-0 dreamed up a whole user-init system, is Devuan interested? Is this the solution we should be contributing to? Who knows, there's nothing but silence from leadership.

Need more devs? Sure, every project needs more devs. You don't get more devs by bitching about it, you get them by training up more devs.
That means setting out what needs doing, how to go about doing it, and how to get it into the distro, then providing hands-on guidance and mentoring to make sure it doesn't break anything.

And yet, here you are shouting at others for not doing those things.

Yes yes, I'm sure you're very important. We were talking about "sanitizing" packages, were we not? What do airfares have to do with that?

gentoo-pipewire-launcher is intended to be started per-user as part of session startup (e.g. xdg-autostart or xinitrc), not by openrc.
As I said above, pipewire is intended to be started by systemd user units for each user login, not system-wide by init as root. Current openrc releases do have (experimental) user-unit support which could handle this... But this is Devuan we're talking about here so good luck finding current anything in the repos.

To quote the Gentoo wiki page (which you should also read completely):

Using the gentoo script is one option, others are discussed in the thread I linked earlier. How you actually launch any of those depends on your graphical session, for KDE on wayland, xdg-autostart is probably easiest.

FWIW, this was my suggestion, and is what I'm using right now on Gentoo (It works well enough I haven't gotten around to moving it over to openrc user-units). Make of it what you will, it does require backporting a not-ancient daemon version from unstable.

Indeed. While it is likely a dead horse, I'll flog it some more here: Devuan, as a supposed leader in systemd-free distros... Does precious little leading.
Where real work is needed to get things working without systemd, solutions are lifted from Gentoo (eudev, elogind, opentmpfiles etc.). Everything else is just banning packages rather than fixing them, or shipping broken setups like we see here with wayland and pipewire.
I have asked repeatedly what Devuan's direction and preferred solution for user-units is, and all I get is a bunch of "nothing, wait for Debian to fix it" wilful inaction.

That's not how pipewire is meant to be started.

That's not even remotely how pipewire is meant to be started.

Failure to read the documentation or search the forum.

They do, but they're starting only one part of it, manually, and with sudo for maximum borkage (sudo is always the answer ). It can't find it's runtime directory, because that env is not set for root (even if sudo propagated those vars, which it doesn't).
Even if it could, sound still won't work without wireplumber (and pipewire-pulse if you want the KDE mixer and stuff).

Well it's an out-of-tree DKMS module, so yeah, obviously, if you don't need it just remove the package.
I assumed that since you had it installed, you wanted it.

... Will have exactly the same problem. That's what I said above: Kernel packages and DKMS packages need to be in sync, so if you run a newer kernel you need to backport newer versions of any additional drivers as well.

This is not "kernel hacking", it's Debian packaging 102 and the usual stuff you need to be aware of if you deviate from the stable release or add non-devuan packages.

LMGTFY....
https://wiki.debian.org/AptConfiguration#Using_pinning
https://douglasrumbaugh.com/post/apt-pinning/