You are not logged in.
Pages: 1
Hey Devuan community!
Unfortunately over the last few years more and more sysv-init scripts have been removed from the debian repo, resulting in a less than optimal situation. Powerprofiles don't work out of the box meaning that even the netinstaller will drain your laptop's battery quickly, pipewire doesn't work unless you manually configure it, etc.
More and more people are starting to hate systemd and want to get away from it. Then they try Devuan and notice that they just don't get this "out of the box" experience they get on Debian. They're going to think Devuan sucks and we're going to lose them.
This is why I propose the "Seamless Devuan Project" ![]()
As far as I know the Devuan team maintains specialised packages for Devuan while pulling the rest from the Debian repos.
The goal is to provide the Devuan maintainers with a script that automatically patches those packages pulled from Debian to enable the same "out of the box"-experience debian has, but better (because we're going to support 6-7 init-systems).
For now I only checked each package in the excalibur repo for amd64 for init scripts. There are are lists for what packages contain scripts for which init system:
https://git.devuan.org/Daemonratte/Seam … lists-init
Step 1
For now we should only fokus on full coverage for SysVinit and OpenRC for Devuan Excalibur.
Here is the list of packages that we have to take care of:
https://git.devuan.org/Daemonratte/Seam … g_sysvinit
Step 2
Next in line is going to be runit. Void Linux is probably going to be the main source for runit scripts that can be copies.
Step 3 and 4
After we prepared all the services for OpenRC, SysVinit and Runit the next step is either going to be creating scripts for sinit, s6, shepherd and dinit (hey, there's no way this won't be added in the future) or doing the same for Freia, Ceres, Daedalus and Chimaera (in that order).
Step 5
When we're done it's time to create a script that automatically patches every .deb downloaded from the Debian repo. This way we can eliminate both the maintainance burden for the Devuan maintainers while also keeping users happy.
What you can do:
When you go to https://git.devuan.org/Daemonratte/Seam … atchfolder you're going to find folders for each package containing a script. Every package should have a systemd init script. Only half of the packages contain a SysVinit script. Feel free to upload working solutions that work on your machine ![]()
Please test all packages listed here:
https://git.devuan.org/Daemonratte/Seam … totest.txt
The plan is to get every package to work out of the box for each init script, which is why it's also important to update the postinstall, preremove and postremove scripts (DEBIAN/postinst | DEBIAN/prerm | DEBIAN/postrm) whenever you contribute to a package.
Last edited by Daemonratte (Yesterday 09:49:41)
Offline
This is a good idea. Devuan's Runit and OpenRC (the latter I've never used, but have been informed on) implementations aren't as complete as other distros have theirs. I'd say even Slackware has a more pure SysVinit implementation.
Retroactive support for Chimaera and Daedalus is also a good idea, since there are many of us who have yet to switch to Excalibur and would appreciate more optimal service management in exchange.
Online
don't use github = microsoft !!
Offline
@Daemonratte:
Consider using Devuan's official Git repository. That way, you ensure Micro$lop doesn't remove you for whatever reason, and your hard work isn't lost.
Online
I am not convinced it is worth copying runit service directories or initscripts from other distros: almost always the required work is minimal but there's often a lot of legacy crud (especially in Debian initscripts) that was perceived to be important once but isn't anymore.
It's better to write from scratch.
The challenging parts, such as they are, often relate to system integration considerations that are distro-specific, how to ensure consistent behaviour across init systems and how to make sure upgrades work well.
Honestly, the systemd service units are a better source of ideas but even they often cargo-cult from what has gone before (including otiose initscripts).
Online
I suggest you take a look at antiX, they have various init systems, & have been using them for some time now...
Last edited by Camtaf (Yesterday 09:12:46)
Offline
Alright guys, migration is done (goodbye github!).
Thanks for all the suggestions.
I already added scripts for the following packages (only tested with SysVinit):
accountsservice
nftables
pipewire
pipewire-pulse
polkitd
power-profiles-daemon
wireplumber
There is a caveat though:
For pipewire, pipewire-pulse and wireplumber I couldn't create services (I don't want them to run as root).
Instead it's handled via /etc/xdg/autostart/pipewire.desktop
[Desktop Entry]
Type=Application
Name=PipeWire
Comment=Start the PipeWire media server for the current user session
Exec=/usr/libexec/pipewire/pipewire-session-start/usr/libexec/pipewire/pipewire-session-start
#!/bin/sh
set -eu
# Rootless session starter for PipeWire on Devuan.
# This is intended for graphical user sessions only (for now).
# Do nothing if a runtime directory is not available.
[ -n "${XDG_RUNTIME_DIR:-}" ] || exit 0
[ -d "$XDG_RUNTIME_DIR" ] || exit 0
# Avoid duplicate instances for the same user.
if command -v pgrep >/dev/null 2>&1; then
if pgrep -u "$(id -u)" -x pipewire >/dev/null 2>&1; then
exit 0
fi
fi
# If a session D-Bus is already available, start directly.
if [ -n "${DBUS_SESSION_BUS_ADDRESS:-}" ]; then
exec /usr/bin/pipewire
fi
# If dbus-run-session exists, use it as a fallback for sessions that do not
# already provide a user bus.
if command -v dbus-run-session >/dev/null 2>&1; then
exec dbus-run-session /usr/bin/pipewire
fi
# Last resort: start PipeWire anyway. This supports minimal setups that provide
# enough environment without a session bus.
exec /usr/bin/pipewireWhen wireplumber OR pipewire-pulse are installed a little file will be added to /usr/share/pipewire/pipewire.conf.d that automatically loads the installed package when pipewire starts. I also made sure that pipewire-pulse starts AFTER wireplumber
10-wireplumber.conf
context.exec = [
{ path = "/usr/bin/wireplumber" args = "" }
]20-pipewire-pulse.conf
context.exec = [
{ path = "/usr/bin/pipewire-pulse" args = "" }
]My requirements aren't fulfilled though, because there's one thing I definitely want and one thing that you guys MIGHT want:
I want to displaymanagers like sddm, lightdm, tdm, etc to have their own pipewire session. This isn't only useful for a greeter sound, but also screenreaders.
This is one of the reasons why xdg autostart really isn't ideal. Please let me know if you have any good ideas. Having pipewire when only using a tty would also be nice.
Meanwhile you guys might want a way to have pipewire and wireplumber installed, but disabled. Let me know if that's what you want, because it will be important for porting all systemd services that should only run in a user session.
Last edited by Daemonratte (Yesterday 13:09:18)
Offline
Pipewire works in plain console. No X is necessary. I start it with daemon as described here: https://dev1galaxy.org/viewtopic.php?pid=47569#p47569 except that I put all three daemon commands in one script. I can run that script without an xsession. If I use startx to get the the desktop, pipewire continues to work. If I use a display manager, I have to start pipewire again on the desktop.
Offline
Hey nice!
I've been struggling with complicated solutions described. The only issue is this extra dependency on daemon.
How would you guys prefer handling user daemons?
Using a script that automatically makes use of packages when they're installed. (For making use of daemon or init systems with user services when available with a fallback)
Also include user services for init systems that support it
Just adding daemon as a dependency and use that
I think it's important to define how we should go about with "user serices"
Offline
Hi, here"s how runing Pipewire in MX:
/usr/bin/pipewire-start
#!/bin/bash
configfile="$HOME/.config/Devuan/pipewire-start.conf"
if [ ! -e "$configfile" ]; then
echo "#delay wireplumber session manager to give pipewire time to settle before launch" > "$configfile"
echo "wireplumber_delay=2" >> "$configfile"
fi
source "$configfile"
#start them up
echo "starting pipewire"
#kill existing servers per user
if [ -n "$(pgrep -x -u $USER pipewire)" ]; then
pkill -x -u $USER pipewire
fi
if [ -n "$(pgrep -x -u $USER pipewire-pulse)" ]; then
pkill -x -u $USER pipewire-pulse
fi
if [ -n "$(pgrep -x -u $USER wireplumber)" ]; then
pkill -u $USER wireplumber
fi
#start up new servers
/usr/bin/pipewire 2>/dev/null &
/usr/bin/pipewire-pulse &
#ignore config file value if not a postive non-zero number
check=$(echo "$wireplumber_delay>0" | bc -l)
if [ $check == 1 ]; then
echo "delay wireplumber server start $wireplumber_delay seconds"
echo "configurable in $configfile"
sleep $wireplumber_delay
fi
/usr/bin/wireplumber 2>/dev/null &
exit 0/usr/bin/wireplumber-start
#!/bin/bash
#try to start wireplumber all the time
if [ -z "$(pgrep -x -u $USER wireplumber)" ]; then
echo "start wireplumber"
/usr/bin/wireplumber &
fi
exit 0/etc/xdg/autostart/pipewire-start.desktop
[Desktop Entry]
Encoding=UTF-8
Version=0.9.4
Type=Application
Name=pipewire (sysVinit)
Comment=pipewire (sysvinit)
Exec=/usr/bin/pipewire-start
Terminal=false
Hidden=falseLast edited by Valera (Today 12:22:13)
Offline
I've been struggling with complicated solutions described. The only issue is this extra dependency on daemon.
How would you guys prefer handling user daemons?
Since you asked...and keeping in mind i'm a sample size of one and do not speak for others, in general i'd prefer to have as few running as possible. I can't imagine having to use 3 just to get sound when in fact it's possible to use none at all.
That being said my post will likely trigger a lecture from steve_v about the minimal ram usage of such things, lol.
Pipewire is fast becoming a thing of way too many tendrils for a simple sound server, this seems systemd-ish behavior to me.
https://sourceforge.net/projects/vuu-do/ New Vuu-do isos uploaded March 2026!
Vuu-do GNU/Linux, minimal Devuan-based Openbox and Mate systems to build on. Also a max version for OB.
Devuan 5 mate-mini iso, pure Devuan, 100% no-vuu-do.
Devuan 6 version also available for testing.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
A lot of work is being done on user services for different init systems for Debian. The runit packages are getting a solution soon that has been long in development, I think there's an openrc solution AND at least one generic solution, and that's just the ones going into standard packages. And on the specifics of pipewire integration for existing Devuan releases there's a huge thread for that already.
Online
polkitd already works fine for me, probably launched by dbus. Same with accountsservice.
I'd also advise against patching the DEBAIN/postinst etc. maintscripts - these are _outputs_ of the package build process and this is just asking for trouble over time. Better to patch the source packages in the proper way and let the debhelpers set up the maintscripts. Better still, try to do it in Debian first and then in Devuan if a maintainer absolutely refuses to co-operate with a polite attempt to contribute.
Online
Pages: 1