Known by us but I wonder if having no syslog logger by default is a Devuan oversight (for Debian since bookworm they have relied on systemd-journald). I think they can maybe override the 'priority' field of one preferred logger without having to fork the package itself. I suggest it's worth a Devuan bug report.

Are you thinking of the wine-development package? This was removed in May: https://bugs.debian.org/cgi-bin/bugrepo … ug=1103851

I just noticed https://web.git.kernel.org/pub/scm/linu … cd8fb1f9f8 via https://www.theregister.com/2025/05/28/ … 5_arrives/ - seems we'll be denied the option to build a vanilla kernel that can take advantage of >4GB. To be fair, as the commit log says, this is perhaps fairly niche because in the most obvious use cases (involving 64-bit CPUs) then a 64-bit kernel still works with 32-bit userspace. Still sad, though.

Thanks for the logging tips, Alverstone! I haven't had cause to use yet but useful to have in mind.

I think you are probably right about the serial port. Unexpected use of the serial port is a classic cause of unexplained problems, like debug being interleaved into operational communications and slow/blocked processing!

Perhaps some other test should be used as a proxy to determine whether the serial port is suitable, e.g. a kernel command line value or the enablement of serial logging from some other component.

Thanks for the idea, steve_v! I just set up a runit-based solution. It seems yours has a more sophisticated lifecycle integration with the session/login manager (I'm not so clued up on that stuff) but here's what I have done anyhow:

The runit scripts may be found at runit-desktop - they can be unpacked to ~/.xusersvc. Here's a sample:

#!/usr/bin/sh

SVDIR=$(dirname ${PWD}) sv start pipewire || exit 1

set -e
exec 2>&1
echo "Starting ${PWD##*/}..."

exec /usr/bin/pipewire-pulse

Then I have an XFCE Application autostart entry (cat "~/.config/autostart/User runsvdir.desktop":

[Desktop Entry]
Encoding=UTF-8
Version=0.9.4
Type=Application
Name=User runsvdir
Comment=Start user runit services
Exec=runsvdir .xusersvc
OnlyShowIn=XFCE;
RunHook=0
StartupNotify=false
Terminal=false
Hidden=false

and we are away (sv status .xusersvc/*)!

run: .xusersvc/pipewire: (pid 19758) 1035s; run: log: (pid 19757) 1035s
run: .xusersvc/pipewire-pulse: (pid 19778) 1035s; run: log: (pid 19769) 1035s
run: .xusersvc/wireplumber: (pid 19771) 1035s; run: log: (pid 19768) 1035s

With log files sitting in ~/.xuserlog/*/current:

024-04-19_22:58:50.32626 ok: run: pipewire: (pid 19758) 0s
2024-04-19_22:58:50.32632 Starting pipewire-pulse...
2024-04-19_22:58:51.58468 [W][06850.910390] default      | [   snap-policy.c:   71 pw_snap_get_audio_permissions()] snap_get_audio_permissions: kernel lacks 'fine grained unix mediation'; snap audio permissions won't be honored.

Supervision seems to end satisfactorily on session exit although I did also try a logout hook that ran pkill -HUP on the user's runsvdir but I'm not sure what it gained.

Fortunately it seems the services create their own sockets when systemd activation is absent and we don't need to worry about the various .socket units.

(Also, my first post although I have used the OS for some years - thank you Devuan people!)