doas apt install gstreamer1.0-pipewire libpipewire-0.3-{0,dev,modules} libspa-0.2-{bluetooth,dev,jack,modules} pipewire{,-{audio-client-libraries,pulse,bin,jack,alsa,v4l2,libcamera,locales,tests}}

...leave out the locales package if you can do without it, and instead do:

doas apt install gstreamer1.0-pipewire libpipewire-0.3-{0,dev,modules} libspa-0.2-{bluetooth,dev,jack,modules} pipewire{,-{audio-client-libraries,pulse,bin,jack,alsa,v4l2,libcamera,tests}}

You might have some of the above packages already installed in Devuan Daedalus, but apt should pass on those.

Install some 'recommends':

doas apt install libcamera-ipa pipewire-doc

Useful also, including pavucontrol to control audio levels:

doas apt install libpipewire-0.3-modules-x11 pavucontrol
doas apt-get install wireplumber{,-doc} gir1.2-wp-0.4 libwireplumber-0.4-{0,dev}

Make sure that apt responds to the following by saying that xdg-desktop-portal is installed:

apt list --installed | grep xdg-desktop-portal

If not, install it.  In my experience, at least in my gtk environment, to avoid some muted videos in a browser for example, it is good to also install a portal backend for xdg-desktop-portal.  So depending on whether your desktop environment is Gnome, gtk, KDE, etc, one of the following could be helpful to install:

$ apt-cache search xdg-desktop-portal
xdg-desktop-portal - desktop integration portal for Flatpak and Snap
xdg-desktop-portal-dev - desktop integration portal - development files
xdg-desktop-portal-gnome - GNOME portal backend for xdg-desktop-portal
xdg-desktop-portal-gtk - GTK+/GNOME portal backend for xdg-desktop-portal
xdg-desktop-portal-kde - backend implementation for xdg-desktop-portal using Qt
xdg-desktop-portal-tests - desktop integration portal - automated tests
xdg-desktop-portal-wlr - xdg-desktop-portal backend for wlroots

Get rid of some material, which, in my experience, might not have been purged by apt:

doas apt purge libkf5pulseaudioqt3 libpulsedsp pulseaudio-utils
doas apt autoclean && doas apt autoremove

Next, make pipewire and wireplumber start properly, say, by using the so-called 'Alpine solution' mentioned in post No. 4 above.  At the moment, Devuan users might have to prepare scripts, whereas Debian uses systemd services instead.  The Alpine solution script, as an autostart file or using a similar text in your ~/.xinitrc file if you have one, might not be the appropriate solution, however, so you might have to investigate.  Other similar scripts appear in this forum.

A good tip from Altoid could be to avoid having some other package dragging pulseaudio back on your system.  So pin the package off by opening an editor and starting a new file like so:

doas rnano -w /etc/apt/preferences.d/avoid_pulseaudio

Enter the following text in that file.  Ctr+S to save and Ctr+x to exit that rnano editor.

Package: pulseaudio:*
Pin: version *
Pin-Priority: -1

Reboot.  I hope this helps.  If anyone can improve on this, please let us know.  Thank you.

EDIT:  This upstream Debian pipewire github page may not mention any configuration;  pipewire currently seems to fail for me without any.  Note that I am only a user, but I am trying to share my successes.  So, we'll continue by following Debian 12's wiki section and adapting it to Devuan Daedalus;  note particularly:

Debian 12's wiki section otherwise tracks the section for Debian 11, so we will update any such references in Debian's 11's wiki section to /usr/share/pipewire/ .

Also, instead of applying the systemd or perhaps also pactl directives, we'll rely as stated earlier on running pipewire and wireplumber either from .xinitrc or in autostart batch files (or perhaps in .xsessionrc).  The wiki also uses systemctl commands (a "daemonless "systemctl" command to manage services without systemd", according to apt), but in my experience, perhaps one might be able to do without installing that.

The wiki recommends applying instructions of "all" three sections, yet somehow there is also a fourth section -- PulseAudio ("replacing PulseAudio completely"), Alsa, JACK and bluetooth:

At any rate, bluetooth seems to take care of itself, as no configuration action is mentioned; we had already installed libspa-0.2-bluetooth earlier.

For PulseAudio, which is being replaced:

doas mkdir /usr/share/pipewire/media-session.d
doas touch /usr/share/pipewire/media-session.d/with-pulseaudio

As mentioned earlier, we'll pass over the commands to create services ("Create a pipewire-pulse service by copying the example files"); we'll also pass over the guide to run wireplumber as root.

Next, for Alsa:

doas touch /usr/share/pipewire/media-session.d/with-alsa

Our master guide (Debian 11 as a guide for Debian 12) then instructs: # cp /usr/share/doc/pipewire/examples/alsa.conf.d/99-pipewire-default.conf /etc/alsa/conf.d/ .  As there appears to be no Alsa configuration example folder in Daedalus (/usr/share/doc/pipewire/examples/alsa.conf.d/), hopefully there is no Alsa configuration file needed.

Next, for JACK, and remembering to use /usr/share/pipewire instead of /etc/pipewire:

doas touch /usr/share/pipewire/media-session.d/with-jack

There is one example configuration file for JACK, and it's not yet at the target folder (/etc/ld.so.conf.d/), so try copying it over:

doas cp /usr/share/doc/pipewire/examples/ld.so.conf.d/pipewire-jack-*.conf /etc/ld.so.conf.d/

Create links and cache:

doas ldconfig

Now launch pavucontrol aka PulseAudio Volume Control (although it is hardly dependent on PulseAudio in Devuan), and under 'Configuration', set one or more profiles to 'Pro audio'.  Pipewire runs fine now for me.

Note:  As an alternative to being inspired by the 'Alpine solution' above, I am now starting up packages in .xinitrc as suggested elsewhere in this forum, but adding 2-4 second delays.  Try placing the instructions high up in .xinitrc (or perhaps .xsessionrc), before any audio package command such as amixer;  perhaps those may need to be delayed similarly.

pipewire &
( sleep 2 ; pipewire-pulse) &
( sleep 4 ; wireplumber) &

I hope this helps.

p.s. I often record parts of radio streams with 'audio-recorder' and my concern about purging 'pulse' is if I will still be able to do that with 'pipewire'.

After I read this thread, I took note of the pulseaudio home directory.
The user "pulse"'s home directory is /run/pulse, defined in /etc/passwd.

However, /run/pulse was not exist in my fresh installation.
Other similar daemon home directories are existing, e.g. /run/openntpd, /run/avahi-daemon, or /run/sshd.
grep mkdir /etc/init.d showed that these directories were explicitly mkdir'd, except /run/pulse.

Therefore, I have added an init script that does mkdir /run/pulse && chown pulse:pulse /run/pulse and it seems that /.config is no longer recreated now.
The files are not actually placed in /run/pulse even after I added it, but it may be origin for determining some relative directories.

I hope this will be of some hint.
Thanks.

Maybe no even harm, obvious or not.
But *something* left behind that could/may, in conjunction with something else, bring up a problem or a situation that could bring up a problem.

Good idea ...
Please keep us posted.

Thanks for your input.

Best,

A.

All those "won't fix because it is harmless" issues, warnings and/or bug reports which end up being swept under the rug will are not healthy.
I see it as lousy coding and may (eventually) end up causing issues somewhere in the system.

Yep, just because there's no obvious harm at the moment doesn't mean there isn't some hidden/future problem.

-

I've just remembered inotify, which can monitor filesystem use - so inotifywait --daemon -e create / should log when a directory is created in root, and inotifywait --daemon -r /.cache will monitor all events within that directory, to see if it's being used - although it doesn't look like inotifywait reports pid/uid information, so the first one probably isn't useful, but if files are being created/removed the names may give a clue as to what it is doing it.

Please do.

Not that you know of.

Indeed ...

I think that what is annoying is that something (unknown to you) is creating a .config dir in /.

And from what I have been told, it should not be happening.
Unless at some time your $HOME was set to /.
Which does not seem to be the case.

Granted, it may not be a big deal, but it should not be happening.

My idea of things like these is that they should be investigated and fixed.
If it is a bug or an oversight, it should be squashed/fixed.

All those "won't fix because it is harmless" issues, warnings and/or bug reports which end up being swept under the rug will are not healthy.
I see it as lousy coding and may (eventually) end up causing issues somewhere in the system.

Of course, YMMV.

Best,

A.

So what is result of...

That returns "home=/root;config=;cache=;"

Good idea.  During two boots the messages preceeding creation of /.cache were coming from smartd, but I don't know why it would need a cache file.  I deleted /.cache and restarted that service, and several others (chrony, opensmtpd, dovecot, rsyslog, cron, dbus), without a new /.cache being created.  I'll keep digging.  Or maybe not.  It's not hurting anything, it's just annoying now that I know about it.

Not here:

~$ uname -a
Linux devuan 5.10.0-0.deb10.16-amd64 #1 SMP Debian 5.10.127-2~bpo10+1 (2022-07-28) x86_64 GNU/Linux
~$ 

There is no .cache in my /.
All of them live in the /home/user dir.

And this is all the pulse I have:

~$ apt list | grep installed | grep -i pulse*
--- snip ---
debian-pulseaudio-config-override/oldstable,oldstable,now 1.0 all [installed,automatic]
libpulse0/oldstable,now 12.2-4+deb10u1 amd64 [installed,automatic]
libpulse0/oldstable,now 12.2-4+deb10u1 i386 [installed,automatic]
~$ 

Maybe something else is doing that?

Best,

A.

echo "home=$HOME;config=$XDG_CONFIG_HOME;cache=$XDG_CACHE_HOME;"

...when running as root?

Or I guess:

awk -F: '$6~"^/?$"' /etc/passwd

?

Also, have you identified precisely when during boot it gets re-created? i.e. use stat to get the precise time, and compare with files in /var/log to see what happens around the same time.

... as systemd user-units become more popular. continues to extend its tentacles further and further into Linux.   <--- reads better now, I think.

Not only on chimaera.

I run Devuan Beowulf with a backported kernel.
I suspect it was there since ascii but can't confirm.

So I have seen.

Probably to be reported to Debian.
Don't think it's a Devuan thing, but ...

... if that is so, it could/may be due to an incomplete/faulty sanitisation of the pulseaudio package by the Devuan devs.

Thanks for your input.

Best,

A.

# apt purge pulseaudio && apt autoclean && apt autoremove

Much as I too dislike pulseaudio, if one wants such niceties as on-the-fly switching of bluetooth sinks and whatnot, pure ALSA is a PITA.
While it is still far too complicated IMO, pipewire does at least solve some of the more glaring deficiencies of pulseaudio. Anyone wanting modern convenience features on a laptop or such will probably need one or the other.

FWIW, I have been playing with pipewire on my (openrc) Gentoo desktop too. Gentoo uses exactly the same pipewire-launcher.sh (anybody's guess who nicked it from who), and while it should work on any distro it does come with one problem - it has no facility for terminating pipewire / wireplumber when the user logs out.
That's not a big deal on a single-user system, nor is it a problem if one has logind set to kill user processes (which in turn breaks the old-school ability to background a task and leave it running after logout though).
If neither of those are true however, it results in stale pipewire processes left running and blocking the sound device when one user logs out and another logs in.

To solve this, I lifted a solution from slackware, namely using daemon to manage the equivalent of systemd "user-units".

The result is 3 autostart files (pipewire, pipewire-pulse, wireplumber), like e.g.:

[Desktop Entry]
Version=1.0
Name=Pipewire
Comment=PipeWire media server
Exec=/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire /usr/bin/pipewire
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1
X-GNOME-HiddenUnderSystemd=true
X-KDE-HiddenUnderSystemd=true
X-systemd-skip=true

Zero launcher shell scripts or hacky anti-race sleeps, and the ability to do things like:

$ daemon --list
cdemu
pipewire
pipewire-pulse
pipewire-wireplumber
systembus-notify

As well as stopping, starting, and restarting these user daemons without resorting to pkill and co, giving them pid files, retrying failed starts, and binding to the user's logind session so they exit when they should.

Fractionally more effort (IIRC daemon is in the devuan repos already), but cleaner and more flexible IMO.
Just something to consider, FWIW I strongly suspect we're going to need something like daemon for more than just pipewire in future (I'm also using it for cdemu-daemon and the dbus-notifier part of earlyoom here), as systemd user-units become more popular.

To return to the OT, yes, this /.config and /.cache garbage is created on chimera (default desktop-live/refracta install) as well, and AFAICT the culprit is pulseaudio. Removing pulse will prevent their creation but not remove them if they exist, as they are not tracked by dpkg (for extra nastiness).

Whatever ones opinion of pulseaudio, it shouldn't be creating XDG configuration directories in the system root and so long as devuan is shipping it in the default desktop, I absolutely consider this a bug to be fixed.
I don't have a debian install to compare right now, but my suspicion is that this has to do with pulse assuming systemd and doing broken things when started as root by traditional init (i.e. when XDG_FOO isn't set).

Yes, but do remember to check the link I posted.
You don't want pulseaudio pulled in again by some uncouth package.

~$ cat /etc/apt/preferences.d/avoid_pulseaudio
Package: pulseaudio:*
Pin: version *
Pin-Priority: -1
~$ 

Best,

A.

No matter, quite easy to fix.

First this:

# apt purge pulseaudio && apt autoclean && apt autoremove

Very good point.  I'm using pipewire & wireplumber on my phone & tablet (with mobian bookworm) and it seems to work so I can now just ditch pulseaudio on my destop.

Edit 1: Except the phone and tablet have systemd, of course, and setting up pipewire without that is a bit more complicated.

Edit 2: Actually, the "Alpine solution" turned out to be pretty simple.  pipewire-launcher.sh worked without modifications.   I use XFCE so it needed the desktop file in ~/.config/autostart/ (with Exec= adapted).  I killed pulseaudio, started pipewire, reset the volume control, and it's done.