💾 Archived View for gemini.ctrl-c.club › ~phoebos › logs › kisslinux-2024-03-10.txt captured on 2024-03-21 at 15:44:11.
-=-=-=-=-=-=-
[2024-03-10T15:34:45Z] <testuser[m]> Hi [2024-03-10T15:35:49Z] <testuser[m]> riteo that seems weird, it works fine for me [2024-03-10T15:35:58Z] <testuser[m]> Does your device show up in `wpctl status`? [2024-03-10T19:22:21Z] <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 [2024-03-10T19:22:26Z] <riteo> lemme try the new version [2024-03-10T19:25:24Z] <riteo> Yup, `wpctl status` says nothing, although it also mysteriously says that it 'can't load dbus library: support/libspa-dbus' [2024-03-10T19:25:47Z] <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 [2024-03-10T19:26:26Z] <riteo> lemme try to start the thing without dbus [2024-03-10T19:27:13Z] <riteo> aaand there it is [2024-03-10T19:27:22Z] <riteo> works fine without dbus. Mystery solved ig [2024-03-10T19:27:45Z] <riteo> W H Y I S P I P E W I R E U S I N G D B U S [2024-03-10T19:28:08Z] <riteo> what in the world is it for that it can't f***ing initialize properly [2024-03-10T19:28:51Z] <riteo> exit [2024-03-10T19:29:06Z] <riteo> (oops I wanted to leave the chat client lol) [2024-03-10T19:32:57Z] <vbt> riteo: is it possible for pipewire or xdg-portals to not use dbus in future? [2024-03-10T19:33:18Z] <vbt> riteo: afaik, pipewire uses dbus just for getting fd. isn't it? [2024-03-10T19:33:30Z] <riteo> xdg-portals is built around dbus, and that's justified enough AFAICT [2024-03-10T19:34:13Z] <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 [2024-03-10T19:34:37Z] <vbt> riteo: pipewire uses dbus for video sharing features [2024-03-10T19:35:08Z] <riteo> does it? I thought that was done by the xdg portals [2024-03-10T19:35:15Z] <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 [2024-03-10T19:35:33Z] <vbt> riteo: xdg screencast portal depends on pipewire [2024-03-10T19:35:56Z] <riteo> yeah, but xdg-portals is pretty much just a fancy DBus API, with whatever implementation actually playing with compositors and whatnot [2024-03-10T19:36:14Z] <riteo> but it is _by design_ a DBus thing [2024-03-10T19:40:32Z] <vbt> riteo: how do we prepare for post xdgp world? [2024-03-10T19:40:46Z] <riteo> vbt: what do you mean? [2024-03-10T19:41:51Z] <vbt> riteo: one of the criticisms of systemd is that it introduces vendor lockin and attains non replaceable status. it also prevents further innovation [2024-03-10T19:42:05Z] <vbt> the same thing applies for dbus and by extension xdg portals [2024-03-10T19:42:20Z] <riteo> it's in no way paragonable [2024-03-10T19:43:01Z] <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 [2024-03-10T19:43:08Z] <vbt> yes. but many apps are using it esp. browsers. [2024-03-10T19:43:23Z] <riteo> so? It's not mandatory by any means from what I can tell [2024-03-10T19:43:31Z] <riteo> worst case you patch it out and get something a bit less, so what [2024-03-10T19:43:43Z] <vbt> riteo: dbus as protocol is probably bloated. it can be done better (look at s6's alternative) [2024-03-10T19:43:54Z] <riteo> could you link the alternative? [2024-03-10T19:44:16Z] <riteo> still, the idea _per se_ is not _bad_ and there are some very good uses for this tool, such as xdg portals [2024-03-10T19:44:35Z] <vbt> https://skarnet.org/software/skabus/ [2024-03-10T19:45:05Z] <riteo> we should really see more implementations IMO. We already have an "unofficial" one and it's also being used by fedora IIRC [2024-03-10T19:45:06Z] <vbt> riteo: i agree that the ideas are good but implementation seems to be bad [2024-03-10T19:45:23Z] <vbt> riteo: unofficial one is not musl compatible [2024-03-10T19:45:30Z] <vbt> we are screwed [2024-03-10T19:45:49Z] <riteo> we're not. It's a standard, you can make your musl one :P [2024-03-10T19:45:54Z] <vbt> riteo: unofficial one also depends on systemd [2024-03-10T19:47:06Z] <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? [2024-03-10T19:47:19Z] <riteo> vbt: I'm very sure it doesn't. The README talked about how it's optional [2024-03-10T19:48:26Z] <riteo> oh ok the protocol is binary, oof [2024-03-10T19:48:40Z] <riteo> or something in between [2024-03-10T19:49:12Z] <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 [2024-03-10T19:49:31Z] <riteo> now, for the more important stuff: why is wireplumber shitting the bed when it finds a dbus server? [2024-03-10T20:03:57Z] <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 [2024-03-10T20:04:28Z] <riteo> I'm not exactly sure what this mechanism is. [2024-03-10T20:04:49Z] <riteo> There's this tool: https://github.com/x42/alsa_request_device [2024-03-10T20:05:33Z] <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 [2024-03-10T20:10:10Z] <riteo> Yes, we can :D https://pipewire.pages.freedesktop.org/wireplumber/daemon/configuration/components_and_profiles.html [2024-03-10T20:11:51Z] <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 [2024-03-10T20:12:43Z] <riteo> although since we build without dbus we might bundle the lil scriptlet directly into /usr/share/pipewire/wireplumber.conf.d/ directly [2024-03-10T20:13:48Z] <riteo> Hope that helps :) [2024-03-10T20:39:59Z] <asimovsh> hi guys [2024-03-10T20:48:41Z] <sewn> hi asimovsh [2024-03-10T20:48:55Z] <asimovsh> kiss still dead? [2024-03-10T21:02:41Z] <sewn> yep [2024-03-10T22:55:16Z] <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 [2024-03-10T22:59:08Z] <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 [2024-03-10T23:00:59Z] <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 [2024-03-10T23:06:43Z] <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