15:34 <testuser[m]> Hi

15:35 <testuser[m]> riteo that seems weird, it works fine for me

15:35 <testuser[m]> Does your device show up in `wpctl status`?

19:22 <riteo> testuser[m]: I have a theory. Do you have dbus? I have a feeling that it might be connecting to my server and freaking out. That would explain why it works on root

19:22 <riteo> lemme try the new version

19:25 <riteo> Yup, `wpctl status` says nothing, although it also mysteriously says that it 'can't load dbus library: support/libspa-dbus'

19:25 <riteo> something says me that it's just bailing out of the set up because it can't hook to some weird system configuration endpoint on dbus or something

19:26 <riteo> lemme try to start the thing without dbus

19:27 <riteo> aaand there it is

19:27 <riteo> works fine without dbus. Mystery solved ig

19:27 <riteo> W H Y I S P I P E W I R E U S I N G D B U S

19:28 <riteo> what in the world is it for that it can't f***ing initialize properly

19:28 <riteo> exit

19:29 <riteo> (oops I wanted to leave the chat client lol)

19:32 <vbt> riteo: is it possible for pipewire or xdg-portals to not use dbus in future?

19:33 <vbt> riteo: afaik, pipewire uses dbus just for getting fd. isn't it?

19:33 <riteo> xdg-portals is built around dbus, and that's justified enough AFAICT

19:34 <riteo> I'm not exactly sure what pipewire is using DBus for. It's clearly an optional feature (they even had to say it in the FAQ apparently), but I'm not sure why it's freaking out on our not-weird-at-all-why-could-you-think-that setup

19:34 <vbt> riteo: pipewire uses dbus for video sharing features

19:35 <riteo> does it? I thought that was done by the xdg portals

19:35 <vbt> riteo: so, your favorite apps can ask pipewire for video source and pipewire will return file descriptor to video source back to your app

19:35 <vbt> riteo: xdg screencast portal depends on pipewire

19:35 <riteo> yeah, but xdg-portals is pretty much just a fancy DBus API, with whatever implementation actually playing with compositors and whatnot

19:36 <riteo> but it is _by design_ a DBus thing

19:40 <vbt> riteo: how do we prepare for post xdgp world?

19:40 <riteo> vbt: what do you mean?

19:41 <vbt> riteo: one of the criticisms of systemd is that it introduces vendor lockin and attains non replaceable status. it also prevents further innovation

19:42 <vbt> the same thing applies for dbus and by extension xdg portals

19:42 <riteo> it's in no way paragonable

19:43 <riteo> DBus is a protocol. Looks a bit... bloated? But I don't know very well. But still, it's a standard for god's sake

19:43 <vbt> yes. but many apps are using it esp. browsers.

19:43 <riteo> so? It's not mandatory by any means from what I can tell

19:43 <riteo> worst case you patch it out and get something a bit less, so what

19:43 <vbt> riteo: dbus as protocol is probably bloated. it can be done better (look at s6's alternative)

19:43 <riteo> could you link the alternative?

19:44 <riteo> still, the idea _per se_ is not _bad_ and there are some very good uses for this tool, such as xdg portals

19:44 <vbt> https://skarnet.org/software/skabus/

19:45 <riteo> we should really see more implementations IMO. We already have an "unofficial" one and it's also being used by fedora IIRC

19:45 <vbt> riteo: i agree that the ideas are good but implementation seems to be bad

19:45 <vbt> riteo: unofficial one is not musl compatible

19:45 <vbt> we are screwed

19:45 <riteo> we're not. It's a standard, you can make your musl one :P

19:45 <vbt> riteo: unofficial one also depends on systemd

19:47 <riteo> also, unless I'm mistaken it uses JSON as a transport protocol? Doesn't sound too bad to parse. The hardest part might be the API itself. I think it has introspection?

19:47 <riteo> vbt: I'm very sure it doesn't. The README talked about how it's optional

19:48 <riteo> oh ok the protocol is binary, oof

19:48 <riteo> or something in between

19:49 <riteo> oh well, I don't know this thing well enough to comment it and I won't try to act like I know what I'm saying here, that wouldn't be fair

19:49 <riteo> now, for the more important stuff: why is wireplumber shitting the bed when it finds a dbus server?

20:03 <riteo> testuser[m]: Bingo! It is the device reservation module. Commenting it out and removing the dependency from the alsa device seems to do the trick

20:04 <riteo> I'm not exactly sure what this mechanism is.

20:04 <riteo> There's this tool: https://github.com/x42/alsa_request_device

20:05 <riteo> I suppose that pipewire is reserving the device to avoid other tools from using it, seeing no response and supposing that it is taken, discarding the thing. I wonder if we should patch it out or if there's some preference to disable it more gracefully

20:10 <riteo> Yes, we can :D https://pipewire.pages.freedesktop.org/wireplumber/daemon/configuration/components_and_profiles.html

20:11 <riteo> There's even a configuration for our exact usecase! Putting it into $XDG_CONFIG_DIR/pipewire/wireplumber.conf.d/profiles.conf (can be any filename) fixes the issue! :DDDDDD

20:12 <riteo> although since we build without dbus we might bundle the lil scriptlet directly into /usr/share/pipewire/wireplumber.conf.d/ directly

20:13 <riteo> Hope that helps :)

20:39 <asimovsh> hi guys

20:48 <sewn> hi asimovsh

20:48 <asimovsh> kiss still dead?

21:02 <sewn> yep

22:55 <riteo> honestly, the website was already dead in a way. I'm not sure why y'all getting so sad for that, that's the beauty of this distro, remember? The zero bus factor makes this an immortal distro and it still shows, as we still happily update the definitions and enjoy the next-to-zero infrastructure :D

22:59 <riteo> also, regarding the fact that the package manager is not getting enough updates, I think that it's like this because it's actually quite usable. It's not perfect but, especially when paired with flatpak for the really annoying __applications__, 99% of the job gets done on a super-minimal distro which would run even on a router at this point

23:00 <riteo> we have _extremely limited_ resources and yet we're keeping the boat afloat. Even some "bigger" small distros like DSL and Puppy linux had some dead moments but we? We just keep going

23:06 <riteo> Positivity folks! I always talk about what could we improved but we shall not forget how much this little distro is giving us :D