<mnkydeth>
I've changed my setup around a bit. My backup server is now running Crux 3.7 ... :) ... I setup nfs shares for the source and package directories for the server and my main computer. So I can share the source files between them. And for a quick re-install if needed I have all the pre-made packages there for me to use. znver3 for the main desktop and ivybridge package dirs for the respective machines. This
<mnkydeth>
should help when things like crux.ster or other source locations have issues.
<mnkydeth>
Some reason I do need to manually do a mount -a as root or run /etc/rc.d/nfsclient start after a reboot however. Even setting _netdev on the fstab line won't mount it. It will throw an error on boot. Oh well.... I'll work on that later.
<mnkydeth>
I'm still trying to wrap my head around XDG stuff for wayland, pipewire and sway however. I still don't have audio. Thats the main goal currently. Then I really want to see if I can get bluetooth setup with a game controller. Once complete.... A mass backup of all config files.
<mnkydeth>
Just figured I would share current stuff from me with Crux.
<jaeger>
Plenty with which to keep busy, sounds like
<jaeger>
I still use pulseaudio... pipewire was fine for me for a while and then stopped producing sound but gave no errors. I haven't looked into that yet
<mnkydeth>
Ahh yeah... I thought it was working just fine for a bit. Not sure what I did. However, after the sources issue ... I did a full install on my backup server. So I could start storing source and pre-made packages.
<mnkydeth>
Came back to the main desktop got it setup for that scenario and noticed the sound wasn't working.
<cruxbot>
[opt.git/3.7]: rsyslog: updated to version 8.2212.0
<mnkydeth>
Maybe it's how I start sway. With a ./start_sway.sh file. Most of my errors seem to revolve around XDG stuff so I must not have it setup correctly.
<jaeger>
how are you calling it inside that script?
<cruxbot>
[contrib.git/3.7]: qemu-guest-agent: updated to version 7.2.0
<cruxbot>
[contrib.git/3.7]: python3-zipp: updated to version 3.11.0
<mnkydeth>
I have the gsettings stuff inside the .config/sway/config now
<cruxbot>
[contrib.git/3.7]: python3-texttable: updated to version 1.6.7
<cruxbot>
[contrib.git/3.7]: python3-jsonschema: updated to version 4.17.3
<cruxbot>
[contrib.git/3.7]: python3-importlib_metadata: updated to version 5.1.0
<cruxbot>
[contrib.git/3.7]: osinfo-db: updated to version 20221130
<cruxbot>
[contrib.git/3.7]: open-vm-tools: updated to version 12.1.5-20735119
<cruxbot>
[contrib.git/3.7]: nginx: updated to version 1.23.3
<cruxbot>
[contrib.git/3.7]: libvirt-python: updated to version 8.10.0
<cruxbot>
[contrib.git/3.7]: libvirt: updated to version 8.10.0
<jaeger>
Hrmm... I don't think you need to set XDG_RUNTIME_DIR manually anymore.. and also 2 execs back to back probably won't do what you want
<mnkydeth>
Do a && between them?>
<jaeger>
I would suggest in this case moving the pipewire calls into the sway config
<jaeger>
but leave the dbus-run-session call as the last line
ppetrov^ has joined #crux
<mnkydeth>
Ok, so I basically commented out the entire file except the dbus-run-session sway line. I put /usr/bin/pipewire && /usr/bin/pipewire-pulse at the bottom of the sway config file. Pipewire seems to have started. I don't see any XDG errors. :)
<mnkydeth>
alsamixer says however.... This sound device does not have any controls. So, it is further along then before
<mnkydeth>
Thank you
<jaeger>
No problem.. for reference, the exec calls would be appropriate in sway's config but not in the bash script
<mnkydeth>
Yeah, I was going off of many other examples. And I do want to say ... maybe on a previous install. Everything worked. I need to start documenting better.
<jaeger>
alsa stuff might work if you also install alsa-plugins (after pulse/pipewire)
<mnkydeth>
I just went through and recompiled all alsa, pipewire and pulse that is installed just to make sure. I will need to try to move forward another day. It's late here. And I do appreciate you getting me further along with the sway launching stuff. At least pipewire starts now.
<jaeger>
No problem. beerman can probably help more, he's more familiar with it than I am
<chrcav>
mnkydeth: it looks like you are missing a session manager like pipewire-media-session or wireplumber. Without having pipewire-media-session running I get the same error in alsamixer.
chrcav has quit [Quit: leaving]
chrcav has joined #crux
_moth_ has joined #crux
<farkuhar>
adding onto chrcav's suggestion: you don't need three separate exec lines in your sway config. Just put one line to exec pipewire, and then set up the files under ~/.config/pipewire to launch the compatibility layer pipewire-pulse, and the session manager (wireplumber is what I use).
<farkuhar>
and I agree with jaeger that manually manipulating XDG variables is no longer needed. On a fresh install of CRUX 3.7, the pam library dumb_runtime_dir should be enabled by default (check /etc/pam.d/common-session to be sure), but you can also replace it with pam_xdg (from contrib).
ocb has quit [Remote host closed the connection]
ocb has joined #crux
ocb_ has joined #crux
ocb has quit [Remote host closed the connection]
_moth_ has quit [Remote host closed the connection]
_moth_ has joined #crux
ocb_ has quit [Remote host closed the connection]
ocb has joined #crux
_moth_ has quit [Remote host closed the connection]
_moth_ has joined #crux
_moth_ has quit [Client Quit]
chrcav has quit [Quit: leaving]
ppetrov^ has quit [Quit: Leaving]
<mnkydeth>
Thanks for the tips. I removed pipewire-pulse from my sway config. I tried out greetd instead of using the sway_start.sh file I made. All seems good that way so far.
<mnkydeth>
I'll be going to work shortly. But, if I launch pavucontrol it says dummy device as my sound device. If I do an alsamixer it says This sound device does not have any controls. Launching pipewire-media-session in a terminal and then doing alsamixer it does show a volume bar. But it still doesn't show my sound card device.
<stenur>
i love X; now "unprivileged".
<stenur>
and nothing over native ALSA; except that put a dmix as the basis for bluealsa
<mnkydeth>
Same issue with alsamixer using wireplumber.
<stenur>
and i am all in favour for my pam_xdg over what is in core, anyhow; not to mention i need to carry the /etc/profile fix along
<stenur>
never understood all that, kernel should just mix it; maybe soft interrupt threads or what, but just want dmix on the hw, and anything else should stack on top of that.
<mnkydeth>
https://pastebin.com/0p8JQNn7 <-- alsactl info shows my device. Honestly I can't say I've had this sort of issue on Crux before. My audio has always just worked. I'll have to take a look at the config files for alsa and such. I never messed with any of the files, never had to.
<stenur>
yaml is an interesting language. i do not like the flag of the beasts
<stenur>
i have no idea of that stuff mnkydeth
<stenur>
i booted an archlinux kernel once and then built a kernel with the necessary modules, then alsaconf once iirc. i have an /etc/asound.conf where i tried a looong time with few success.
<stenur>
ah it was alsactl info output
<stenur>
..out..
maledictium has joined #crux
<jaeger>
anyone using greetd and tuigreet, does --remember-session actually work?
maledictium has quit [Quit: WeeChat 3.0]
maledictium has joined #crux
maledictium has quit [Client Quit]
maledictium has joined #crux
maledictium has quit [Client Quit]
maledictium has joined #crux
_moth_ has joined #crux
<SiFuh>
I don't even know what that is
<jaeger>
For now I've told it to only look at wayland sessions and ignore X sessions, that works... but telling it to remember I selected sway instead of i3 did not
<jaeger>
On the positive side I was able to get sound working again with pipewire on the laptop