[00:44] <OvenWerks> Eickmeyer: "autojack expects pulseaudio" Thats coming to an end... but not sure I'll be there in time.
[00:48] <Eickmeyer> OvenWerks: Right, that's causing problems for people who merely install "ubuntustudio-installer" as it depends on studio-controls which installs autojack which tries to restart pulseaudio which causes havoc on pipewire. Pipewire is default on Ubuntu Desktop already as of 22.10
[00:50] <Eickmeyer> Basically, the change I uploaded to Lunar needs to be SRU'd to Kinetic for that compatibility.
[00:51] <OvenWerks> Ah, ok.
[00:54] <Eickmeyer> OvenWerks: If you can't get the changes done to studio-controls, I might have to make some default config changes in lunar that allow for a pipewire-jack configuration that conflicts with studio-controls. Still hashing that out.
[18:59] <Eickmeyer> OvenWerks: Got some fairly unfortunate news. Apparently, pulseaudio and pipewire-pulse are not coinstallable since they functionally overlap. Therefore, a simple switch between the two with studio-controls will not work and must be done with packaging. Still working on this.
[18:59] <OvenWerks> Eickmeyer: that is not true
[19:00] <OvenWerks> I have both installed right now
[19:00] <Eickmeyer> Right, but what is the DE using?
[19:00] <OvenWerks> right now PW
[19:00] <Eickmeyer> How do you switch to pulse?
[19:00] <OvenWerks> systemctl enable/disable works
[19:01] <Eickmeyer> Oh, that's cool.
[19:01] <OvenWerks> Basically, if both are installed, pulse will grab the socket first and pw will drop out
[19:01] <OvenWerks> disable pulse and pw will grab things and go.
[19:02] <OvenWerks> I have even been able to do it without reboot.
[19:02] <Eickmeyer> Ok, then that leaves me worried from a seeding perspective if we want both installed by default but PW enabled by default.
[19:04] <OvenWerks> one of two things, the meta can do a preinstall to disable or to remove the symbolic link
[19:04] <OvenWerks> (same thing really)
[19:04] <Eickmeyer> Except one problem: .iso images aren't built with metas, they're built with tasks.
[19:05] <OvenWerks> do those tasks include installing packages?
[19:06] <Eickmeyer> Yes, but I'm not sure how that all works. It's quite a bit different than installing the metas as defined by the ubuntustudio-meta since it grabs directly from the seed itself.
[19:07] <Eickmeyer> It's partially why packages on the .iso aren't necessarily marked as "auto".
[19:08] <Eickmeyer> Additionally, the metas don't have a pre/postinst script.
[19:08] <OvenWerks> Couls we include this in ubuntustudio-default-settings?
[19:08] <Eickmeyer> Germinate doesn't have a facility for it.
[19:09] <Eickmeyer> We can, and that's one thing I'm working on in ubuntustudio-default-settings. I already have a "ubuntustudio-pipewire-config" package I've been working on. I can probably do a "systemctl disable pipewire" or something to that effect inside its postinst.
[19:09] <OvenWerks> autojack, while not set to do this as yet could set the switch one way or the other
[19:10] <OvenWerks> Actually you might to disable pulse
[19:10] <Eickmeyer> Better yet, mask pulse altogether and unmask it when removing the package.
[19:11] <OvenWerks> controls/autojack can (do) check for what is actually installed and running on first run.
[19:11] <Eickmeyer> There we go. I think we have a solution.
[19:12] <OvenWerks> For most people I think pw mode will just work for them
[19:12] <OvenWerks> Those who have a good idea what they are doing might want something else.
[19:13] <OvenWerks> Perhaps to finish a project
[19:13] <Eickmeyer> Right.
[19:13] <OvenWerks> (though they will have to deal with a different version of DAW possibly anyway)
[19:13] <Eickmeyer> The config I've been making installs a file to /etc/profile.d/ubuntustudio-pwjack.sh which sets the environment variables necessary for pipewire-jack.
[19:14] <Eickmeyer> It removes that upon uninstallation.
[19:14] <Eickmeyer> Also includes a script to change the buffer size.
[19:15] <Eickmeyer> Defaults to 1024
[19:16] <Eickmeyer> Though, I've found, each JACK client can set its own buffer size and that the buffer isn't global.
[19:16] <OvenWerks> is that all? pwjack installs a file in /etc/ld.so.conf.d to set the libpath already so don't add that to the environment
[19:17] <Eickmeyer> Actually, it doesn't. At least not in lunar.
[19:17] <OvenWerks> (controls adds/removes that file for switching purposes)
[19:18] <Eickmeyer> I tried it and all JACK clients would scream that JACK wasn't running until I added the necessary environment variables.
[19:19] <OvenWerks> the contents of that file: /etc/ld.so.conf.d/pipewire-jack.conf should be: ls -d /usr/lib/*/pipewire*/jack/ > /etc/ld.so.conf.d/pipewire-jack.conf
[19:20] <OvenWerks> I guess it makes more sense to say I create that file with the line: ls -d /usr/lib/*/pipewire*/jack/ > /etc/ld.so.conf.d/pipewire-jack.conf
[19:21] <OvenWerks> It has to be run as sudo of course
[19:21] <OvenWerks> In controls case it is run with pkexec
[19:23] <OvenWerks> This is the manner that upstream does things
[19:23] <Eickmeyer> Unfortunately, that file doesn't exist in lunar.
[19:23] <Eickmeyer> with pipewire-jack installed.
[19:24] <OvenWerks> I understand but a preinstall that creates the file you are creating could just as easily create this one.
[19:25] <OvenWerks> one of the packages in: https://launchpad.net/~pipewire-debian/+archive/ubuntu/pipewire-upstream must put that line in.
[19:26] <Eickmeyer> Well, we have to do this using the Ubuntu packages, not that.
[19:27] <OvenWerks> yes but that is not the point. Adding an environment variable is not the right way to make the pw libjack active
[19:28] <Eickmeyer> It is according to every single document I found. The pw-jack executable is merely a wrapper that sets the environment variables so that JACk applications can connect to JACK. This sets them system-wide.
[19:29] <OvenWerks> https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-JACK
[19:29] <OvenWerks> https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-JACK#installation to be exact
[19:30] <OvenWerks> "You also need to to create a file /etc/ld.so.conf.d/pipewire-jack-x86_64.conf containing a link to the JACK modules:"
[19:30] <OvenWerks> Like I said upstream pw recommends this way
[19:30] <Eickmeyer> Yes. PIPEWIRE_QUANTUM and LD_LIBRARY_PATH are the two environment variables that PIPEWIRE THEMSELVES SET in pw-jack.
[19:31] <Eickmeyer> export PIPEWIRE_QUANTUM="1024/48000"
[19:31] <Eickmeyer> export LD_LIBRARY_PATH='/usr/${LIB}/pipewire-0.3/jack'
[19:31] <OvenWerks> yes but that is just for running a jack application when the lib is not set up 
[19:31] <Eickmeyer> This sets the lib up.
[19:31] <OvenWerks> I have looked at that file as well.
[19:31] <Eickmeyer> It works. Trust me. I've tested it ad-nauseum.
[19:32] <OvenWerks> but that is not needed to make things work if the installation procedure laid out in the pw documentation is followed
[19:32] <OvenWerks> The installation procedure also works
[19:33] <Eickmeyer> Ok, then why isn't the Ubuntu package installing it correctly then?
[19:33] <OvenWerks> Good question
[19:33] <Eickmeyer> My point is we need to work with what we've got until that is fixed. It's in main, so I can't fix it.
[19:33] <OvenWerks> if you are going to install a file install the correct one
[19:34] <Eickmeyer> What does that file contain then?
[19:35] <OvenWerks> the file can be created with this line: ls -d /usr/lib/*/pipewire*/jack/ > /etc/ld.so.conf.d/pipewire-jack.conf
[19:35] <OvenWerks> the documentation says the line in the file is /usr/lib64/pipewire-0.3/jack/
[19:35] <OvenWerks> but... I figure the line I use will still work if the version specific line they use changes
[19:36] <OvenWerks> ]That is for pw-jack 0.4 or something
[19:38] <OvenWerks> which version of pw (or pw jack) does ubuntu use in main? The documentation says "This configuration issue should be fixed in later versions but as of 0.3.21+ it is still an issue."
[19:39] <OvenWerks> it may be the package I am using is newer?
[19:39] <Eickmeyer> Let me see.
[19:41] <Eickmeyer> No, your package is older. Lunar has 0.3.63 in proposed already.
[19:41] <OvenWerks> Yup
[19:41] <OvenWerks> so different packaging
[19:42] <Eickmeyer> Yep. The packaging is straight from Debian, synced.
[19:42] <Eickmeyer> And it's in main, so I'm not allowed to touch it.
[19:43] <OvenWerks> Thats ok
[19:45] <Eickmeyer> Figured it out: Debian interprets the ld.so.conf.d stuff as examples, not "the way to do it." Basically, there's more than one way to skin a cat.
[19:45] <Eickmeyer> They install it, but to /usr/share/doc/pipewire/examples/ld.so.conf.d
[19:46] <OvenWerks> by not putting it in /etc/ they leave jackd working
[19:46] <Eickmeyer> Correct. What's nice about the way I'm doing it is it's a simple package install/uninstall.
[19:46] <OvenWerks> this means that by not installing pulse, pw works for all desktop applications while jack users still use jack
[19:47] <OvenWerks> the way you are doing it breaks controls
[19:47] <Eickmeyer> The way I'm doing it helps people who might not want controls.
[19:47] <Eickmeyer> i.e. users of other flavors.
[19:48] <OvenWerks> yes but using the upstream method works for them as well
[19:48] <OvenWerks> And it has the benefit that all distros can work the same
[19:49] <Eickmeyer> Right, except Arch's documentation about pipewire-jack don't even mention the upstream method and mention setting an environment variable.
[19:49] <OvenWerks> wonderful...
[19:50] <OvenWerks> The package I'm using comes from a arch user  :P
[19:50] <OvenWerks> life is complicated
[19:51] <Eickmeyer> I think we're in a situation of scope creep here.
[19:51] <OvenWerks> I guess I can search for that file and -x it?
[19:51] <Eickmeyer> Well, anything in profile.d gets executed regardless of executable bit as long as the extension is .sh, so it could be renamed from .sh.
[19:52] <OvenWerks> In any case, I would ask that the installation method speced by upstream developers would be the way to go.
[19:53] <Eickmeyer> You're not wrong, but, in order for controls to work with it, distros have to agree on that as well. Right now, there seems to be confusion.
[19:53] <Eickmeyer> Debian sees it as optional, and Arch has the "Arch Way".
[19:54] <OvenWerks> That is ok, someone sends me an issue/bugreport I can at least point at the upstream installation and say if your distro doesn't do it that way, I can't help you.
[19:57] <OvenWerks> I guess controls will have to do a breaks/replaces for that package
[19:58] <OvenWerks> There is not really any difference between rename and nuke
[19:59] <OvenWerks> either one will mess with upgrades I would imagine
[20:00] <Eickmeyer> OvenWerks: I'm already on it. Right now, that package is definitely on Breaks: studio-controls
[20:01] <Eickmeyer> As far as upgrades, still working on that. I might be able to maneuver around that.
[20:01] <OvenWerks> If the file is installed as part of postinstall it is probably ok
[20:01] <Eickmeyer> It is, and removed as part of prerm.
[20:02] <Eickmeyer> In fact, it's dynamically generated by a new command: ubuntustudio-pwjack which lets the user set the default buffer size.
[20:02] <Eickmeyer> Upon installation, it sets it to 1024.
[20:02] <OvenWerks> So the only problem for me would be to look for it and nuke it if found
[20:03] <OvenWerks> (if switching to jack)
[20:04] <Eickmeyer> Honestly, it would need to be renamed to remove the .sh extension and then the user would have to relog. That's it.
[20:10] <OvenWerks> yes but the upgrade would not see the renamed file and just create a new file.
[20:12] <OvenWerks> As a sw dev creating something for the whole of the ecosystem, I have to use what upstream uses, not some kludge in some directory other than that. If using the upstream method doesn't work I have to point the user at their distro to submit a bug.
[20:15] <Eickmeyer> Right, which is precisely why I'm setting a Breaks: line in the packaging.
[22:06] <Eickmeyer> OvenWerks: The biggest problem I have with installing anything directly into /etc (as opposed to dynamically writing it) is that it requires a purge to remove it or if a newer version gets installed it requires user intervention.
[22:06] <Eickmeyer> So, believe me, I'm trying to figure out how to work ld.so.conf.d in.
[22:07] <Eickmeyer> I just can't guarantee full ownership of it.
[22:07] <Eickmeyer> It's a namespace issue and the archive admins are going to stomp all over me.
[22:33] <Eickmeyer> OvenWerks: I figured it out. I can symlink pipewire-jack.conf -> /usr/share/doc/pipewire/examples/ld.so.conf.d/pipewire-jack-*-linux-gnu.conf (to keep it ok for all archs) and it'll just  work. I'll have to keep the other file for the PIPEWIRE_QUANTUM variable, but this one does the LD_LIBRARY stuff.
[22:50] <Eickmeyer> OvenWerks: Bad news, the symlink doesn't work. It still wants the environment variable set somehow.
[22:52] <Eickmeyer> I can make the variable LD_LIBRARY_PATH=$(cat /etc/ld.so.conf.d/pipewire-jack.conf) and have it export that, but it has to have something in that variable otherwise it's completely broken.
[22:58] <Eickmeyer> Actually, it'll be LD_LIBRARY_PATH=$(cat /etc/ld.so.conf.d/pipewire-jack.conf || true), that way it retuns empty if studio-controls removes the pipewire-jack.conf file.
[23:25] <Eickmeyer> OvenWerks: Nevermind. Got the symlink to work. I forgot to put ldconfig in the postinst.
[23:25] <Eickmeyer> I can remove the Breaks: line now.
[23:25] <Eickmeyer> Ladies and gentlemen, we have a Pipewire configuration that doesn't break anything.