Extract sd-bus from systemd to build dbus-broker/miraclecast

[geki]

Yea, well, there are some projects depending mainly on sd-bus rather than on systemd.
I am interested in replacing good ol' dbus with dbus-broker. Gtk 3 needs a dbus session to work best.

I use MATE which uses Gtk 3. To get LibreOffice Gtk 3 native menubar; you need that dbus session.
See bugreport: can't go back in file menu after folding up the next submenu - I reference into the source at comment #8.

There is a thread about miraclecast to support non-systemd systems. The way to go is to extract sd-bus from systemd.
See topic: Implement OpenRC support on Systemd based project - I posted my initial hacks there.

Feel free to jump in and help with the following tasks:

• DONE Create a sys-libs/libsystemd ebuild.
  See https://github.com/geki-yaba/gekis-play ... libsystemd
• DONE Cleanse meson.build file that just need minor changes from future versions.
  See https://github.com/geki-yaba/gekis-play ... eson.build
• DONE Cleanse busctl source code to build and install successfully. Necessary for dbus-broker.
• Create and maintain a project with own repository and a clean codebase et al.
• Create and maintain update scripts, that generate diff files for changes from systemd version to version. And better, do scripts that apply most changes with tagging or such automagically.
  See https://github.com/geki-yaba/gekis-play ... on_bump.sh

I will check dbus-broker next. DONE Installs fine but needs busctl binary. DONE


So I put my post from miraclecast thread once more here:
_______________________________________
I actually was in mood this evening ~ it seems I cannot trust myself these days ~ to strip sys-apps/systemd down to libsystemd with only sd-bus, sd-event, sd-id128 and sd-daemon.
I share my hacks, so if anyone feels like doing a clean independent meson.build, instead of patching. I just want to see, if dbus-broker works with this cleansed libsystemd. for funs sake(=ffs, right? ).

I do NOT recommend to merge the hacked systemd ebuild and source. You will trash your system. It needs above-mentioned cleanup and maybe renaming.

Patch to ebuild, source and finally files to cherry-pick.

[geki]

I created a sys-libs/libsystemd ebuild to support SD-BUS without systemd.
See https://github.com/geki-yaba/gekis-play ... libsystemd

Code: Select all

ana ~ # equery files libsystemd
 * Searching for libsystemd ...
 * Contents of sys-libs/libsystemd-237:
/lib64
/lib64/libsystemd.so -> libsystemd.so.0
/lib64/libsystemd.so.0 -> libsystemd.so.0.21.0
/lib64/libsystemd.so.0.21.0
/usr
/usr/include
/usr/include/systemd
/usr/include/systemd/_sd-common.h
/usr/include/systemd/sd-bus-protocol.h
/usr/include/systemd/sd-bus-vtable.h
/usr/include/systemd/sd-bus.h
/usr/include/systemd/sd-daemon.h
/usr/include/systemd/sd-event.h
/usr/include/systemd/sd-id128.h
/usr/lib64
/usr/lib64/pkgconfig
/usr/lib64/pkgconfig/libsystemd.pc
/usr/share
/usr/share/doc
/usr/share/doc/libsystemd-237
/usr/share/doc/libsystemd-237/NEWS.bz2
/usr/share/doc/libsystemd-237/README.bz2
/usr/share/doc/libsystemd-237/README.md.bz2
/usr/share/doc/libsystemd-237/TODO.bz2
/usr/share/doc/systemd
/usr/share/doc/systemd/GVARIANT-SERIALIZATION.bz2
ana ~ #

[mblnx]

This is definitely useful, I guess I am really lucky you've just coded this ebuild.

Thanks

[depontius]

A simple question here...

How does dbus relate to sd-bus? Do they talk to each other? Can you have both at the same time? What happens when ProgramA works with dbus and ProgramB works with sd-bus?

If you're in the lock-step systemd world this is probably a null question, but here it seems real to me - unless sd-bus and/or dbus are being treated merely as inescapable build-time dependencies, not as run-time functions.

[geki]

Well, not yet tested by me, but

• dbus-broker can be used as drop-in replacement[0] for dbus daemon with system and user session.
• Next to the dbus daemon, there are dbus client libraries[1] to abstract away from user code to dbus messaging. And these can be exchanged as mentioned in [1].

There are some dbus binaries in /usr/bin/dbus-* that dbus-broker requires to function properly. I will see how it goes. I expect no malfunctioning; once properly set up with openrc.

The dbus-broker developers tested with fedora and had no issues at one point. No link(source), sadly, I read this once ...

[0] https://github.com/bus1/dbus-broker/wik ... bus-broker
[1] http://0pointer.net/blog/the-new-sd-bus ... stemd.html

[depontius]

Shouldn't there be a "virtual/dbus" at some point, then?

[geki]

I guess, no virtual. Time will tell. dbus-broker would need to copy the dbus helper binaries. I wonder if they care. Or dbus development will be abandoned in favour of dbus-broker. Well, this is just my crystal ball talking.

[Naib]

Interesting. The absolute worst thing about systemd is how it is so intertwined into a monolithic wetdream for exploiters. The fact effort has been spent to attempt to split of a "subproject" highlights this. Doesn't matter if it was 5min or 5months it was effort that shouldn't have occured.

If systemd are "improving" on infrastructure then all should take credit where possible without the systemD dependency.

I did like the sound of sd-bus when it was announced, as in dealing with dbus issues (poor code) in re-implementation rather than forcing into the kernel (kdbus, I am glad that failed)

[geki]

Bumped to v238. One more task to do:

• DONE Cleanse busctl source code to build and install successfully. Necessary for dbus-broker.

edit #1
Actually, adding necessary source files from src/shared and libraries to linker within meson.build did it to compile busctl.

[geki]

UPDATE v238 ships with /usr/bin/busctl now.