You are not logged in.
Wonderful. Let's wait together. When some packages turn up in Debian offering all or some of those good things you talk about, then they automatically turn up in Devuan. Unless they depend on systemd. If they do, they end up on the banned packages list. Unless someone takes on the effort of forking and untangling the systemd dependencies.
Offline
Creating yet another respin 3 people might use just for this is a ridiculous misdirection of effort.
Dang Steve, you're a mite hard to understand, you've been arguing vehemently the importance of whatever it is you're arguing about, but then in the above sentence you freely admit it may be important to like 3 people.
C'mon, jump in there and fix some stuff, it will make you feel better, i've been doing it for days now, even fixing tiny things gives me a nice feeling of accomplishment.
Sorry you didn't like my browser experiment, but it IS in fact a browser as you can browse the web with it and 95% of everything works, even video. I'm working on that as a single-purpose frontend to some web-based things like Libera-chat's web interface.
https://sourceforge.net/projects/vuu-do/ New Vuu-do isos uploaded April 2025!
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
*And no, @golinux, I'm not interested in doing theming or . . .
Read that correspondence again more carefully, steve_v. I never suggested YOU do ANYTHING specific. I only mentioned the tasks that are currently not being maintained. And I encouraged you to do SOMETHING but flap your gums from the sidelines.
Offline
you've been arguing vehemently the importance of whatever it is you're arguing about, but then in the above sentence you freely admit it may be important to like 3 people.
I've been arguing that Devuan, as a leading systemd-free distribution, should be taking a (pro)active role in solving the problems that arise from not shipping systemd... Or at least making some decisions on how these things should be handled.
The "3 people" comment was, of course, with regard to the potential userbase of yet another tiny single-developer derivative of a derivative, and the duplicated effort of creating one to solve problems better tackled where they can benefit all Devuan derivatives - i.e. in Devuan itself.
I can solve this particular problem for myself, and I already have, in several different ways. I really don't see the point in building a distro to prove it.
What I would like to know is: Which way does Devuan intend to handle this, and is there anything that needs doing there? What solutions are being considered? I contributed one possibility way upthread, is it worth persevering with or is Devuan going to do something totally different?
Is anything at all happening, or are we just going to do the "wait for debian to make a move, then delay release for 3 months while we put out fires" thing again?
Slackware has an official solution in the repos, which works out of the box. Gentoo has an official solution in the repos, which works out of the box. Artix has an official solution in the repos, which works out of the box. The latter 2 also have wiki pages on the subject, listing several alternative solutions.
Devuan unstable has... *goes looking to confirm the obvious* A pipewire package pulled verbatim from Debian, a non-functional pipewire.service, and no documentation.
I only mentioned the tasks that are currently not being maintained.
Ahh, I see. Pipewire wasn't on the list, nor were was user services in general. Do I take that to mean this is well under control and Devuan's pipewire-launcher and autostart files are being actively maintained?
I mean it sure doesn't look that way to me, is there some secret-squirrel development branch I don't know about?
Last edited by steve_v (2025-04-09 06:31:23)
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
Offline
You sound like you want to do something, so yes: Go for it! Make a debian package and submit it to debian. I'm pretty sure you will get a debian developer sponsoring it. That's also how it gets into the Devuan repository.
Offline
Pipewire works out-of-the-box on Debian, because Debian is (primarily) a systemd distro. All major Debian desktop configurations have a mechanism for user-services by default, there is no RFE to file, and no additional package is required.
This could maybe be a wishlist item as far as Debian is concerned, but frankly I don't think anyone over there really cares at this point.
I don't see how this is anything but a systemd-free problem, systemd-free is Devuan's only available desktop configuration (and primary claim-to-fame), that makes it a Devuan problem.
Last edited by steve_v (2025-04-09 07:05:46)
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
Offline
that makes it a Devuan problem.
I don't think it's a Devuan problem...I think there's nothing complicated about writing a pipewire to the DE or WM autostarting mechanism...
Offline
Well i'm not a ninja at this stuff like the devs and many of the members here, i'm just an ol redneck with a keyboard.
But it seems to me, that if all the people who have issues with pipewire and pulse over the years, got together and said to hell with soundservers, let's just improve ALSA itself and give it nice native soundserving functions with a nice GUI to configure it....that might be a better solution?
FYI in excalibur, there are some new lines in the ALSA 90-alsa-restore-rules in /etc/udev/rules.d that I don't quite understand, and are doing nothing that I can see except throwing up error messages in boot. This may be an issue going forward. I can get rid of the errors and get it working normally by replacing or modding that file to use the daedalus version.
https://sourceforge.net/projects/vuu-do/ New Vuu-do isos uploaded April 2025!
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
Morning steve_v . . .
I should have said that I only mentioned a FEW of the tasks that are currently not being addressed/maintained. In part, that is because I am still happily on chimaera and dreading the day I will have to deal with more current obstacles.
Do I take that to mean this is well under control and Devuan's pipewire-launcher and autostart files are being actively maintained? Is there some secret-squirrel development branch I don't know about?
Sadly, the dev channels are mostly silent and there is little new blood stepping up to provide redundancy and skills going forward. Feel free to be part of the solution.
Offline
The past few days I have been experimenting inside my Daedalus LXQt VM trying to wrap my head around how DEs and WMs work these days and what role xdg plays there. (Yes I am an ole pure startx+WM and ALSA guy as well.) Unfortunately my health situation mostly prevents me from being able to focus on such tasks. Nonetheless I came to the conclusion it would be a good idea for Devuan to implement a user service manager kind of thingy to have a solution for the systemd user services.
I have tried out the suggestions in this thread on how to start pipewire on a system with a DM starting a DE. And I really like the shed/c scripts by EDX-0. AFAICS they are a good starting point. Maybe EDX-0 wants to start a thread about the shed development on this forum (or is there one already?). EDX-0 should start the thread so they have control of the first post to keep it up to date with new information.
And I think shed should be talked about in a separate thread than the pipewire one here.
I'll post my solution as step-by-step instructions on how to get PW running on LXQt (as a representative for DEs) and fluxbox (for WMs) later.
Offline
I agree with the above post by debdog, i'd sure be happy to test and contribute to that project. @EDX-0
https://sourceforge.net/projects/vuu-do/ New Vuu-do isos uploaded April 2025!
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
i did start a thread about shed at https://dev1galaxy.org/viewtopic.php?id=5160 but besides Head_on_a_Stick it got no traction it seems, got a little more traction on the artix forum with a moderator, a seasoned user and an artix developer providing feedback to improve the design of shed: https://forum.artixlinux.org/index.php/ … 410.0.html
currently i want to implement some needed features for v0.3.0 but got stuck into refactor purgatory where all my lazy coding and design decisions come to bite me and prevent the addition of more features until the code is more modular and uses less global variables...
shed is something i've been cobbling together for my own use since maybe june or july of 2022 but only pushed the first commit of a usable version to github back in august of 2022, wasn't until the development cycle of v0.2.0 that i decided to adapt the design and code of shed from just being something i wanted for myself towards the roadmap of eventually becoming a full fledged session process for posix that can manage the session's processes in more than just starting every component but actually managing them from a daemon, ensure nothing dangles and lingers across logouts and logins by also taking care of doing logout (well, this means i eventually need to make shed play well with elogind's terminate-session and kill-session), and with enough hope set up a standar that shames the session processes for different desktop environments being utterly unable to implement the minimum of proper management over their session components and autostart programs when something written in shell script just can.
once shed is on the state of "can just work as session process for x11 and wayland" (likely not rn for v0.3.0 but probably for v0.4.0) then i intend to work on submitting a package to debian so that it just becomes part of the pool of packages inherited by every debian derivate, then make the pitch to devuan so that shed is the tool to reccomend not just to provide a session process for stand alone window managers but user services with sysvinit.
Offline
A solution that works for sddm+fluxbox/LXQt/Xfce using shed!
(This howto is intended for users testing shed with pipewire only!)
Install packages according to the first few posts of this thread.
\
Install shed, use following commands to the dot if you're not able to decipher them!
cd ~/Downloads
git clone https://github.com/eylles/shed.git
cd shed
# Check for the highest release with:
git tag
# Put the highest number one in the following command, at the time of writing this was v0.2.0:
git checkout v0.2.0
make install
# Copy the scripts to a user independent location:
# (If your user is in the staff group, no "su -c" required.)
su -c "cp ../../.local/bin/shed* /usr/local/bin/"
# Remove the user dependent scripts:
make uninstall
\
Create service files for shed to start the pipewire required services, on multi-user systems this has to be done for each user:
mkdir -p ~/.config/shed/services/
echo -e "NAME=pipewire\nEXEC=/usr/bin/pipewire" > ~/.config/shed/services/pipewire
echo -e "NAME=pipewire-pulse\nEXEC=/usr/bin/pipewire-pulse" > ~/.config/shed/services/pipewire-pulse
echo -e "NAME=wireplumber\nEXEC=/usr/bin/wireplumber" > ~/.config/shed/services/wireplumber
\
Add the following commands to each user's ~/.xsessionrc file:
export XDG_CONFIG_HOME=$HOME/.config/
export GUI_SESSION_PID=$$
/usr/local/bin/shed &
Copy'n'paste the following command to do so:
echo -e "export XDG_CONFIG_HOME=$HOME/.config/\nexport GUI_SESSION_PID=$$\n/usr/local/bin/shed &" >> ~/.xsessionrc
\
HOWEVER this only works for the first time login. shed sadly does not work as expected and does not kill the services on logout. The experiences accordingly will go the shed thread.
Offline
yeh the problem is that to logout with shed in it's current state you need to run
shedc logout
which is not ideal but i have to do quite some refactoring to fix that...
Offline
Hehe, that is not the reply I expected. On my plain startx+fluxbox setup running this command would not be a problem. Do you have a suggestion how to automatically do so on a DM+WM/DE setup?
Offline
Do you have a suggestion how to automatically do so on a DM+WM/DE setup?
Use XDG Desktop Application Autostart: many desktop environments also support the Desktop Application Autostart Specification.
If your environment supports the Desktop Application Autostart, you can start pipewire by symlinking the desktop file to the system
/etc/xdg/autostart
or user
${XDG_CONFIG_HOME}/autostart
or
~/.config/autostart) autostart
directory.
If you are using a desktop environment, window manager, or Wayland compositor that does not support this, a tool like
dex
can be used to add support for Desktop Application Autostart, for example:
dex --environment <window manager> --autostart --search-paths ~/.config/autostart.
Also, pipewire can be launched directly from your window manager or Wayland compositor's startup script...
Offline