I see, that explains why it got confused running on a Devuan system!

If you're installing Devuan from Debian (or the other way around) I would recommend using the --foreign/--second-stage method. This has worked for me in the past, when the standard single-stage method didn't.

Thanks for the feedback, rolfie. I guess PipeWire works better with your type of desktop install. That makes sense, I guess. Modern software is designed to work with modern setups. I just noticed this is now happening on both of the Devuan systems where I have installed PipeWire alongside xinit. When I shut down X, my mixer settings are unchanged, but when I restart X, PW has reset my audio devices. I need to test it on a system with a display manager, to see if that makes a difference.

I figured out a workaround for now. I saved a reasonable set of defaults to a file using alsactl, then put a line in my .xsessionrc to load these settings on a delay at startup. It isn't really a "fix," as it still resets my mixer settings every time I start an X session, but at least it loads a set of defaults that actually works.

The problem for me is that the fastest mirrors from my location seem to change pretty often. I usually just keep it at us.deb.devuan.org. If I use the global URL (deb.devuan.org) I always seem to hit an extremely slow mirror eventually. However, there was a while last summer where the only mirror that gave me a decent connection was in Taiwan.

All I have to do to switch mirrors is change which line is commented out:

URIs: http://us.deb.devuan.org/merged/
#URIs: https://tw1.mirror.blendbyte.net/devuan/merged/

I'll be honest, I don't even remember where I got that snippet. It made the EQ controls appear in greenjeans' app, but I didn't do listening tests. I'm guessing the second block should read type equal, not type plug. Why would someone put a deliberate error in there? Wait... did I get tricked into copying AI slop?!

Whenever you see broken packages, it's a good idea to try apt-get -f install to see if apt can fix the problems for you. It doesn't always work, but it is worth trying. libc6-dev might be important. For example, I need it to install my WiFi drivers. This makes me wonder if you are having connection issues. Are you able to install any packages at all? What error message are you seeing when you enter apt install synaptic?

The API documentation is an absolute nightmare. In fact, the only real "documentation" is the source comments. They get scraped by doxygen and posted to the ALSA site, but most of the links from the index page just go to blank pages. It's been this way for years!

At least there's some online documentation for the C API, I guess. ALSA has an official set of Python bindings which wrap essentially the entire C API. The ALSA devs call it "pyalsa," but if you search for that name, you will find only a completely unrelated, unfinished, decade-old hobbyist project. (in fact, I think there might be two of them!) There is absolutely no online documentation for the real Python ALSA bindings. In fact, the only way to read the documentation is from within Python itself.

Unfortunately, the ALSA bindings also seem pretty buggy. get_volume works, but get_volume_dB always seems to return zero. Maybe I'm using it wrong, but the sparse documentation certainly doesn't give any hints. Attempting to use the mixer callback facility invariably results in the Python interpreter crashing.

I saw some confusing things when I was looking at other people's mixer code. There seemed to be this persistent belief that you had to open the snd_hctl device before opening the snd_mixer interface. I have no idea where they got this idea, but it's completely unnecessary.

Even the ALSA devs don't fully implement their own API. I have a card that shows the "Mic Boost" control twice in alsamixer. The element shows up during both capture and playback enumeration, but it's marked as "common." The application should check for this attribute and only show the control once.

EDIT: After posting the question below, I realized something potentially more important. The value of XDG_RUNTIME_DIR set by shed isn't being exported to the session. As a result, pipewire commands run in terminal windows (such as pactl & wpctl) don't work. If I manually export it as /tmp/1000-runtime-dir from my ~/.xsessionrc then everything works fine. I'm not sure why this happens, since I see in your code that shed explicitly exports the variable. Of course shed can't export the value, I should have realized a script can't export to its invoking script unless it's sourced. However, in this case, even sourcing doesn't work, probably because shed runs in the background and doesn't exit.

I noticed I was accumulating multiple GUISessionXXXX directories on repeated login/logout cycles, since shed was creating a new directory each time from the new PID. It all gets cleaned out on reboot, but the XDG spec says we're supposed to delete these directories between login sessions. Would it make sense for shed to delete the directory on exit if shed created it? I'm not sure whether there might be processes still trying to access this directory after shed exits, but I'm guessing if shed created it, then only shed services are using it.

Has anyone actually been able to get file sharing to work on Windows 10 or later? I gave up a while ago. My searches indicated that Microsoft has completely broken local file sharing in recent versions Windows to push "the cloud." Users asking for help on support.microsoft.com just get a sales pitch for OneDrive.

When I have to boot into Windows, I use Cygwin to mount remote SSHFS shares hosted on the Linux systems. Unfortunately, I can't get it to work in the other direction, even though Cygwin supposedly supports it now.

Huh, that's strange. I installed fail2ban on both a Trixie and an Excalibur system recently and both worked perfectly (once I set the proper logging method.) Maybe it's because I used nftables and pynotify from the start? Those seem to be part of some people's "fixes."

OK, thanks. It didn't occur to me that the logic to handle XDG_RUNTIME_DIR being unset wasn't be in the release version. I will update to master and keep an eye on the log.

(Later edit) It's all working now. I cloned from master, ran make && make install, then confirmed shed was running. It automatically creates a runtime directory at /tmp/1000-runtime-dir/GUISessionXXXX each time the X server starts. I put the three PipeWire service files in ~/.config/shed/services/ as you showed in the other thread, and now they're starting as well. Now I'm thinking about what else it might be good for. I think I'll try creating a service for starting Deskflow. It's not quite as complicated to run as PipeWire (it doesn't need a socket, for example) but it would still be neater to use shed.

Glad I could help. I'm catching up on the thread and looking at the code for EDX-0's shed, and I have to say, he had all the runtime directory stuff figured out a long time ago. I wasn't aware of how much work had already been done on the problem, or how complex it was.