Bringing forth runit integration regarding desktop environments

[Lorenzo]

Hello,

as you can guess by my two weeks delay reply I don't have the time to
follow up on this right now, although I will during the freeze.

On Sat, 9 Nov 2024 19:42:55 +0000
Andrew Bower <andrew at bower.uk> wrote:

> I wonder how much time (or more importantly, upload cycles) we have
> to get improvements to runit viability into Trixie and what the
> highest priority gaps are that could use help?

runit is RC buggy and addressing that (#981799, #981937) is absorbing
90% of my Debian-time right now.
After that there is 2.1.2-61 and bugfixing for runit-services package;
maybe there is time for 2.2.0 new upstream release (stashed here[1] for
now).
experimenting with an unofficial package or even stage in experimental
is fine but from my point of view it's too late for new runit packages
or new features, except if needed to fix outstanding bugs.  

On Sat, 09 Nov 2024 13:40:38 +0100
Martin Steigerwald <martin at lichtvoll.de> wrote:

> 
> However I wonder about doing some work for desktop integration as
> well.
> [...]
> And again I also wondered about pipewire integration as well. AFAIR
> according to some discussion about it this cannot really be handled
> as a system service, but needs to be tied to the user session,
> probably by DBUS activation.

> 1) Whether an init agnostic approach is actually workable for
> Pipewire? Runit user services would work if done properly, also for
> quitting Pipewire with the session. Stuff like this could indeed go
> into some runit-desktop package :)

I think the mechanism to start and stop the session could be shared
between inits but services definition and the way they are managed is
init specific.

> 
> 2) How to do Runit user services properly? You mentioned Lorenzo is 
> thinking about this for a while.

the long term idea is to interface with session manager deamons; for a
short term solution see the package draft below

> 
> 3) If an init agnostic approach is not possible, how to do it for
> other inits? I'd focus on Runit anyway, if no init agnostic approach
> is possible, as I need to focus in order to get something
> accomplished.

a runit-user session can be available to users of other init systems via
the runit-run package, although it's still a runit-centric solution.
It's really up to sysvinit and openrc maintainers to say if they are
satisfied with that or they prefer to work on their own solution.
The latter need some coordination.

>> I wonder what ideas Lorenzo has up his sleeve for a general solution
>> to
>> user runit supervision?  
>
>As do I! :)

this is a 1 year old draft that I never had the time to test, just put
into git and pushed, you may want to have a look
https://salsa.debian.org/debian/runit-services/-/tree/user-services?ref_type=heads

To test it,
* build runit-services package from user-services branch;

* Apply this patch
  https://salsa.debian.org/debian/runit/-/commit/e940123cc1ebf1821d00416c159793d5e0f6bb4e
  to /usr/bin/cpsv in your system (yes really do this)

* install the runit-user-session package

* logout and login, (maybe a reboot is needed): if your user is
  "martin" you should see a runsvdir at martin service enabled and
  running, that points to ./service inside you home.

The package is configured so that only login via display-manager (sddm,
lightdm, ..) will start a rusnvdir user instance, logins via vt
(including startx from vt) or remote logins will not start a
user instance.

I'm still on X11, so the thing that I'm not sure is if it will work
with wayland and pipewire (a concern is the fact that runsvdir is not a
child of the graphic session, so pipewire&co will run on a different
tree than wayland..)

Best,
Lorenzo

[1] https://salsa.debian.org/Lorenzo.ru.g-guest/runit/-/tree/next?ref_type=heads