KLV-Airedale-rc3 with Void Linux Kernel is Available!

[rockedge]

@wiak works for me also. I deleted the start up script in /root/Startup and put Exec=start-pulseaudio-x11 back in the /etc/xdg/autostart/pulseaudio.desktop and added root, spot and weedog users to the audio group then logged into spot and back into root. Both cases worked with sound.

So I will make this change in rc4 and repackage it and upload it. I have to upload sparingly for a few days until I get Internet back online!

It appears the audio configuration is correct now and in line with upstream Void Linux

[wiak]

@wiak works for me also. I deleted the start up script in /root/Startup and put Exec=start-pulseaudio-x11 back in the /etc/xdg/autostart/pulseaudio.desktop and added root, spot and weedog users to the audio group then logged into spot and back into root. Both cases worked with sound.

So I will make this change in rc4 and repackage it and upload it. I have to upload sparingly for a few days until I get Internet back online!

It appears the audio configuration is correct now and in line with upstream Void Linux

I'm about to check it again rockedge. I'm not sure. I notice that I had left /home/Startup/pulse-audio script (or whatever it was called) on my system, so maybe the pulseaudio --start is what was actually starting the daemon for spot. I'll report back my own findings once I know anyway.

[rockedge]

@wiak I know the /home/spot/Startup is not working to start it's contents. I will test again early in the morning, it's late and my mind is needs a rest. But first tests seem to show that the configuration we are working with now is starting pulseaudio daemon in both root and spot logins.

[wiak]

@wiak I know the /home/spot/Startup is not working to start it's contents. I will test again early in the morning, it's late and my mind is needs a rest. But first tests seem to show that the configuration we are working with now is starting pulseaudio daemon in both root and spot logins.

It is proving tricky to me partly because of all these Startup pulseaudio mechanisms existing in parallel.

Thus far it 'seems' to me that /home/<normal_user>/Startup should not contain any start_pulseaudio script (i.e. remove the likes of /home/spot/Startup/start_pulseaudio scripts). However, root is a special case since pulseaudio isn't designed really to be used by root so seems to me that the /etc/xdg/autostart/pulseaudio.desktop mechanism that Exec's start-pulseaudio-x11, works for normal users but doesn't work for root (even if root put in group pulse-access). For root alone therefore it seems to me that it continues to need /root/Startup/start_pulseaudio script. Mind you I wonder if that /root/Startup/start_pulseaudio script should contain pulseaddio --start or the Void Linux wiki recommended:

Code: Select all

pulseaudio --daemonize=no --exit-idle-time=-1

, which also works despite complaining about bluetooth issues (not installed it seems - see below).

Either way, we shouldn't also use runit to start pulseaudio, and it is probably best to make sure all of spot, weedog, and root are included in /etc/group/pulse-access.

However, that brings me to another related concern:

------------------------------------------
Bluetooth. There doesn't seem to be any bluetooth support included in KLV? I realised that because above pulseaudio command comes up with error about bluetooth. Installing bluetooth per Void Linux docs fixes that situation, but I am having a problem with the bluetooth manager I also installed (blueman). The problem is that blueman-applet first appears in the panel okay, but once I enable bluetooth it disappears so I don't know how to see devices or connect to them. If I then do a "sv restart bluetoothd" the applet reappers but with bluetooth not enabled indication on it. For bluetooth installation I installed:

bluez, bluez-alsa, and blueman, and did: usermod -a -G spot bluetooth (and similarly for weedog and root user)

and prior to use, I enabled the bluetoothd service in the usual runit way: https://docs.voidlinux.org/config/services/index.html

Maybe bluetooth is turned off in my system uefi bios or something. I still have to check that. EDIT: no, bluetooth is enabled and works in Zorin which also uses blueman so I don't know that the issue is that I'm having - bluetooth not working for me in KLV once installed. No doubt a small issue, but like you I've exhausted at the moment... so will have to come back to that.
EDIT2: Looks like I am just missing the bluetooth firmware for my machine - not surprising for this fussy laptop. I'll try and locate on Intel site and see if can get it working then. Yes, that's all it was - I needed extra bluetooth firmware for my laptop. Bluetooth-manager and bluetooth-applet now apparently working, though haven't bluetooth device present to try right now. Any bluetooth reports would be much appreciated to confim can get working. You should consider adding bluetooth support to KLV iso @rockedge since it is used a lot nowadays

[Sofiya]

viewtopic.php?p=52790#p52790
it was tested at your own peril and risk, it really works, but I don’t see the difference between what we have
Equalizer also fails to start in session root sudo -u spot pulseaudio-equalizer enable

in spot session works fine

[rockedge]

@wiak Looks like the best method is to have /etc/xdg/autostart/pulseaudio.desktop use :

Code: Select all

Exec=start-pulseaudio-x11

No startup script in any user other than root is needed.

The script /root/Startup/start_pulseaudio takes care of starting pulseaudio when logged in as the root user :

Code: Select all

#!/bin/sh
pulseaudio --start

So I am going to make the rootfs changes to use this mechanism. Bluetooth is one of the last functions we need to get going and once that's ready and working we will be really close to a production release! I will make the changes and package a fresh ISO.

[Sofiya]

the spot session is set up, I'll poke around further

[wiak]

@wiak Looks like the best method is to have /etc/xdg/autostart/pulseaudio.desktop use :

Code: Select all

Exec=start-pulseaudio-x11

No startup script in any user other than root is needed.

The script /root/Startup/start_pulseaudio takes care of starting pulseaudio when logged in as the root user :

Code: Select all

#!/bin/sh
pulseaudio --start

Yes, I agree. Root user desktop using pulseaudio is a (Linux non-standard) special case, so not surprising needs own mechanism. It is correct, IMO, for normal users to have separate pulseaudio sessions - that is recommended multi-user system practice, and the xdg scheme supports that.

[fredx181]

I'm still on rc3, and didn't read much in this thread about the pulseaudio problem TBH, but made it work well in KLV by:
- removing the pulseaudio script from /root/Startup
- following the instructions here: (skipped the systemd part) https://www.freedesktop.org/wiki/Softwa ... ystemWide/
Note that root has to be added too in /etc/groups for pulse-access, so pulse-access:x:996:root,weedog,spot

All works for me, run-as-spot firefox ... > sound, login as root , login as spot ... > sound.

The "pulse" runit service that calls pulseaudio --system is already started by default AFAIK.
I think --system is what we need in KLV, - pulseaudio started system-wide for all users - , including root, but pulseaudio warns you for that, ok, optimal security or not, it's a choice.

EDIT: I think that the Exec=start-pulseaudio-x11 is for when you run as normal user (as it works in e.g Ubuntu), not root.

[dancytron]

I'm not really caught up enough to understand how this is all set up, but I think that the "system" user is the intended configuration for running pulse audio as root, to the extent they think that running as root is okay at all.

I've been using it in debian dog since [whenever that post was] and it has just worked and been totally stable.

[fredx181]

I'm not really caught up enough to understand how this is all set up, but I think that the "system" user is the intended configuration for running pulse audio as root, to the extent they think that running as root is okay at all.

I've been using it in debian dog since [whenever that post was] and it has just worked and been totally stable.

If you exclusively run as root (means no e.g. run-as-spot either) then pulseaudio --start is ok, but run-as -spot ... and have no sound is annoying, so then indeed --system is the way.

[dancytron]

Yes. I use it for running chrome, vlc etc as a regular user with a slightly modded version of your "run-as-user" script.

I think it's more secure [seeming] too. Tricking stuff into running as root is good clean fun for us, but it makes a lot of people cringe.

[rockedge]

@fredx181 I explored using pulseaudio --system making FirstRib-Void and in the beginning alpha stage of KLV. I seem to remember it didn't work as expected but I might not have included root, spot, weedog in the pulse-access group.

I will start testing this again as a system daemon and revisit this method. One consideration to leave the /etc/xdg/autostart/pulseaudio.desktop alone and use the current configuration in KLV-Airedale-rc4.1 is because the package manager put the .desktop file in this form in it's location. What happens during an update of pulseaudio package? Will the desktop file be over-written?

KLV-Airedale-rc4.1

This is what steered me originally away from using the --system switch.

Running PulseAudio in system-wide mode has some limitations:

All users with access to the sound server can kill/modify all sinks/sources and streams of all other connected clients
There is only a single namespace for cached sound samples, i.e. there can be only a single Gnome event sound profile active at the same time

It has some disadvantages:

Worse security, because the user can now command a server app running under another user name. He could even load/unload modules from that sound server
Settings like the stored volume levels managed by module-stream-restore are no longer per-user but system-wide

[fredx181]

One consideration to leave the /etc/xdg/autostart/pulseaudio.desktop alone

Don't know atm how you made it in rc4
In my rc3 (with the changes I made) it has Exec=start-pulseaudio-x11 and I suspect that it isn't used at all, as systemwide is already enabled, but not sure.

[rockedge]

@fredx181 Here is the post where I list what rc4.1 has and seems to work
viewtopic.php?p=76203#p76203

And I added root, spot and weedog to the pulse-access group. Also removed /home/spot/Startup

[wiak]

@fredx181 I explored using pulseaudio --system making FirstRib-Void and in the beginning alpha stage of KLV. I seem to remember it didn't work as expected but I might not have included root, spot, weedog in the pulse-access group.

I will start testing this again as a system daemon and revisit this method. One consideration to leave the /etc/xdg/autostart/pulseaudio.desktop alone and use the current configuration in KLV-Airedale-rc4.1 is because the package manager put the .desktop file in this form in it's location. What happens during an update of pulseaudio package? Will the desktop file be over-written?

KLV-Airedale-rc4.1

I just checked how my Zorin (Ubuntu-liniux-based) system handles pulseaudio since it is systemd-based. However, turns out it also opts only to use /etc/xdg/autostart/pulseaudio.desktop, which does an Exec start-pulseaudio-x11 script. i.e. per multiuser recommendations at Void Linux wiki, results in individual pulseaudio instances for each and any normal user. Lots of reasons why that is best in a multiuser system configuration.

You can also login to root desktop quite easily in Zorin (some may not know that it is trivial to do so) - you just set a root password whilst a normal user via sudo passwd root, and then Logout and system allows you to login to desktop as user root then for those who really want that as an administrative 'convenience'. However, just like I talked about for KLV root desktop, no pulse daemon is running for root when using /etc/xdg/autostart recommended method. Once again, I can start a daemon for root manually (or pulseaudio --start from a startup script being one method that can be used).

I understand the argument for instead using otherwise not-Void-or-pulse-recommended system-wide daemon as a convenience for root desktop users despite its limitation in terms of multiuser system use. It is arguable, but doesn't matter to me personally - I would just quickly remaster any such iso back to using the /etc/xdg/autostart mechanism for my own preference since I don't find it a pain using in that form myself. So, whatever the users prefer is fine by me; it is true that I don't generally use run-as-spot even though I generally use chromium browser - I cheat instead by running with --no-sandbox or if I really want to run as spot I become spot. The problem was certainly with pulseaudio-equalizer, which will not run as root user. In practice, on my Zorin system at least I normally login to desktop as normal user - I am happy doing admin work from that perspective too and can easily give permissions to my disk areas for downloading, for example, using normal-user run browsers. However, when I do want to do tons of admin I do logout and login back as root desktop - I don't bother about pulseaudio (or simply start it manually) for these admin root desktop occasions. If staying as root desktop only, then pulseaudio --start script is best from my view, but for absolute convenience involving run-as-spot scripts I can see the wish to just share a system wide single pulse instance.

[rockedge]

@wiak I'd like to keep it multi instances for different users, main reason is the system update that will occur at some point for pulseaudio.
We would have to ensure a way to override the /etc/xdg/autostart desktop file from being over-written. It is simpler to remain in line with upstream Void Linux packages. All that needs to happen is have a start script in /root/Startup. Which is what that special directory is for in principle.

The rc4.1 set up with start-pulseaudio-x11 is working with sound when logged in as any of the 3 users, root,spot or weedog.

[wiak]

@wiak I'd like to keep it multi instances for different users, main reason is the system update that will occur at some point for pulseaudio.
We would have to ensure a way to override the /etc/xdg/autostart desktop file from being over-written. It is simpler to remain in line with upstream Void Linux packages. All that needs to happen is have a start script in /root/Startup. Which is what that special directory is for in principle.

The rc4.1 set up with start-pulseaudio-x11 is working with sound when logged in as any of the 3 users, root,spot or weedog.

Yes, whilst running as root user desktop is nice and convenient and we all seem to do that a lot, no one can deny the problems it causes in terms of being incompatible with upstream repo expectations. That's why so much forum work is about 'workarounds' because traditionally 'Puppy' does it all differently (even the filesystem hierarchy in old Puppy case!!!). Result can indeed be a nightmare when updates/upgrades are done - not just for pulse, but anything that has been organised differently than upstream repo expects.

[wiak]

I believe, it remains the case that after using Startup method (script that runs pulseaudio --start) only for root user desktop, run-as-spot <browser_name> still works perfectly well including pulseaudio sound. The only 'pain' is that for that special run-as-spot involving pulseaudio case is that pulseaudio-equalizer-gtk doesn't work since that too needs to run as a normal user, and at same time to access same pulse bus (or might be dbus communications) - using a second pulseaudio bus-sharing app (pulseaudio-equalizer) simply wasn't thought of in design of run-as-spot the way I see it.

Again that is a special case caused by using that special run as root desktop configuration. So again the logical best way around that, as far as I see it, if you want to keep your distro properly multiuser compatible per upstream repo expectations, is to actually temporarily become spot and run both the browser and pulseaudio-equalizer from that perspective - that's exactly what I did when showing it would work (via manual in-terminal steps) and that could be scripted (modified of course per actual underlying system pulse configuration) for that special pulseaudio-equalizer case if someone wanted to do things that way: viewtopic.php?p=76072#p76072

However, pulseaudio works fine when using run-as-spot browser - it is, I repeat, simply pulseaudio-equalizer that won't work the way that run-as-spot script handles matters: since one instance of run-as-spot doesn't expect another pulseaudio-related app (in this issue case being pulseaudio-equalizer) to be also needed. I expect you could incorporate pulseaudio-equalizer on/off as spot inside that run-as-spot script as an option, or simply use a different special-purpose script for that one-special user-case. I wouldn't mess with expected up-stream pulse organisation, which is part of multiuser handling, simply because of pulseaudio-equalizer special case, but up to KLV-user wishes as long as they understand the issues system-wide pulseaudio might also cause.

In other words, the 'limitations' of run-as-spot is the issue, not any limitations in recommended typical Linux pulseaudio configuration. Run-as-spot is a useful feature to have, but it is a workaround and it is limited, but perhaps these limitations of run-as-user could be addressed (or perhaps not).

[wiak]

It would be a shame to see KLV-airedale become not really compatible with upstream Void Linux simply because of our wish to run from perspective of root user desktop. No wonder Puppy itself ended up with so many horrible hacks to workaround not only that root user desktop situation, but also traditional Puppy lack of true multiuser capability - which has always been a limitation of Puppy rather than a benefit that could be touted. My argument therefore is that 'workarounds' to allow root user desktop usage must overcome the 'pain' involved in arranging that in such a way that it never effects true upstream repo/distro multiuser compatability. To me system-wide shared pulse daemon is an ugly hack that breaks that perspective and thus alternative workaround should be found instead when wanted. But I am just one user of KLV of hopefully many and I will go with the flow and modify my own version in the end according to my preferences anyway (unless it ends becoming too much work to switch back to upstream recommendations overall).

[rockedge]

this information reminded me of another reason not to use --system

When in system mode, shared memory data transport is disabled for security reasons, which means: much higher memory usage and CPU load in system mode

[wiak]

this information reminded me of another reason not to use --system

When in system mode, shared memory data transport is disabled for security reasons, which means: much higher memory usage and CPU load in system mode

Though probably any such extra load wouldn't be noticed in a single root-user-only system since memory not needing shared in that case anyway, but KLV is touted as a true multiuser system so it is relevant though maybe not so important to most users. Nice to maintain upstream repo compatibility expectations though - that is important.

[rockedge]

throw this message into the consideration :

Users: use your Linux distributions packages and instructions as much as possible to maintain compatibility with the systems they provide, such as updates and audio management.

[wiak]

throw this message into the consideration :

Users: use your Linux distributions packages and instructions as much as possible to maintain compatibility with the systems they provide, such as updates and audio management.

Keeping compatibility and as few hacks as possible will be even more important when upgrading will inevitably move us to using Pipewire. That's another reason not to make the likes of run-as-spot too complicated so don't want to tie too much (like pulseaudio handling) into scripts like that really unless easily re-written. In other words, best to leave upstream Void to decide what is best underlying major system handling (such as audio). Whilst Pipewire can act as a backend to Pulse apps, Jack, or Alsa, I suspect longer term better to move towards Pipewire doing everything itself rather than supporting older technologies - not that I know the ins and outs of Pipewire, except I understand it also handles video streams, which is nice.

And eventually, no doubt, we will move to use Wayland, and xfce4 doesn't work with Wayland - not just now anyway. And yet again, the likes of run-as-spot will likely need modified big-time since probably about Xwindows/ setting appropriate .Xauthority and so on - meaning more wheels to reinvent. Less wheels to reinvent as distro matures the better IMO. As far as possible, introduced system-related scripts should be as generic as possible, via plugins I feel as necessary to accommodate specifics such as different display protocols, or other underlying system components - then only small plugin part needs to be different. Easier said than done maybe, and certainly requires that kind of intention any time such a script is written rather than just hacked together for one particular use-case. Basically, I'd say that some system matters can be scripted with confidence that the way they work won't change - for example, to a major extent, basic permissions handling for file and device access - chmod type stuff and users groups and so on - which is major thing we try to handle on root user desktop for the likes of run-as-spot; but yes it is written also from X windows viewpoint only and not taking audio subsystem into account as it stands. So my argument is also: don't change the way the underlying multi-user system works per upstream compatibility, instead, when necessary, change the scripts we use to effect 'workarounds' for our special root user desktop situation, but such scripts need to be as generic as possible when it comes to possible underlying system changes such as audio handling or display protocol and so on. Otherwise we end up devoting our dev lifetimes to re-writing old scripts from scratch (which tends to be what is happening).

[Sofiya]

KLV-Airedale-rc4.1

good job ! @rockedge and @wiak Thanks for viewtopic.php?t=7615
works great

[wiak]

KLV-Airedale-rc4.1

good job ! @rockedge and @wiak Thanks for viewtopic.php?t=7615
works great

Personally, I am fine with the underlying pulseaudio startup mechanisms being used. However, regarding pulseaudio-equalizer annoyance, I hate to give anyone a headache I have, but...

I was looking at my above linked post, which worked to start pulseaudio-equalizer-gtk with firefox as user spot:

viewtopic.php?t=7615

Prior to making that post using sudo -u user, I was originally mucking about with su - spot command, but all the display stuff and xdg stuff would have needed done and also there was something weird about simply running the command:

Code: Select all

su - spot

It took ages and gave an error message. I have no idea what is causing the delay - I don't get any such delay in KLA (my Arch-based Distro). Indeed I notice that if you logout of KLV and then login as different user, there is quite a long delay when it seems to just sit there - again, that delay doesn't occur at all in KLA. What causes it?

So that issue is one headache. The other one is that that the command sudo -u user was just something I tried after consulting "man sudo", not knowing what it would do exactly, but surprisingly worked, including gui commands thereafter finding root desktop's X display. Truth is I know not much at all about sudo so don't know the ins and outs of how it works. Do you?

But the main headache I have is that if I try that same command on the other distro I use a lot (Zorin) trying "sudo -u username" command just results in a sudo help page, so the command not being accepted as a valid command in Zorin it seems...

As I say, I am fine with the overall pulseaudio enabling setup for root user (via /root/Startup) and normal users (via /etc/xdg/autostart) - it is pretty much the same I also use in KLA (Arch-based), except I actually start root user's pulseaudio in /root/.config/openbox/autostart (using pulseaudio --start), which has the benefit that when I switch to normal user desktop that pulseaudio instance gets automatically killed when root desktop exited.

So two matters to think about:

1. how does command "sudo -u spot" actually work in KLV and do what it does (correct Xdisplay and so on), and
2. why is there such a long delay after Logout and trying to login as, say, user spot at the console? It is not a huge delay, so it is fine really, but just wondering what causes it.

I simply don't know the answers to either of these questions of my own. The overall pulseaudio setup itself seems fine to me though.

[rockedge]

@wiak sudo -u spot <application> allow the start of the application as if user spot was logged in.

I use a small script in /root/Startup/set_xhost that will allow other users than root access the X server instance :

Code: Select all

#!/bin/sh
xhost +

It was a workaround to get things going from the first KLV alpha's onwards to allow run-as-spot <application> and sudo -u root <application> to run programs and connect to the graphics.

[wiak]

@wiak sudo -u spot <application> allow the start of the application as if user spot was logged in.

I use a small script in /root/Startup/set_xhost that will allow other users than root access the X server instance :

Code: Select all

#!/bin/sh
xhost +

It was a workaround to get things going from the first KLV alpha's onwards to allow run-as-spot <application> and sudo -u root <application> to run programs and connect to the graphics.

Yes, I use the command sudo <options> <applications> often rockedge, but in that howto get spot pulseaudio-equalizer started up method I provided as howto list of instructions I simply used command spot -u spot; didn't mention <application> at all and the result was similar to using su - spot but with correct environment for getting access to root desktop's X server. That usage was new to me, but seemed to be indicated in man sudo page, and worked in KLV. However, when I try it in Zorin, or KLA for that matter, it doesn't work but instead shows help page for sudo. I'm wondering if something to do with sudo configuration difference, but I don't know.

EDIT: oh I see, at least as far as you using xhost + as a workaround, but still don't know about sudo -u spot (without application being mentioned).

[rockedge]

I use octoxbps.desktop files in /root/.local/share/applications to override the .desktop file from being over-written during updates/upgrades of octoxbps.
The sudo -u spot has to be used to run octoxbps normally as the root user. Running octoxbps with run-as-spot also worked but had quirks whereas sudo -u spot method ran cleaner.

Code: Select all

Exec=sudo -u spot octoxbps

[wiak]

I use octoxbps.desktop files in /root/.local/share/applications to override the .desktop file from being over-written during updates/upgrades of octoxbps.
The sudo -u spot has to be used to run octoxbps normally as the root user. Running octoxbps with run-as-spot also worked but had quirks whereas sudo -u spot method ran cleaner.

Code: Select all

Exec=sudo -u spot octoxbps

Yes, as I said rockedge, I know that works. But it isn't what is concerning me - it was the command I used in viewtopic.php?p=76072#p76072
There I didn't mention any package name at all; just used sudo -u spot
As far as man sudo page tells me there is no such usage; what is available is the form: sudo -u spot -i, where -i means "simulate initial login". No actual filename like octoxbps or anything is then required at the end. It remains a mystery to me how I got away with missing out the -i when using sudo in this manner.