.. well, almost. Anyway, you can get packages here or wait until Rawhide opens again (it’s currently frozen for F8t1). Credit goes to Richard for finishing this work and getting it past Havoc. This is a really huge thing; it opens up a lot of possibilities for better desktop/OS integration.
Lots of pretty colors
To actually test the packages I wrote a simple test program and thought it might be useful to share it. First, you need a program that claims a name on the system bus. I just copied the one from the dbus-python repository and modified it slightly. You can see it here.
Second, as with any service on the system message bus (as opposed to the session bus which has different security characteristics) you need a file in /etc/dbus-1/system.d. Mine is named dk.fubar.Test.conf (but note that any unique file name ending in .conf will do) and is pretty much run-of-the-mill standard stuff and shouldn’t be a surprise if you’re familiar with services on the system bus. It looks like this.
Finally, for system bus activation to work you simply need to put a service file in /usr/share/dbus-1/system-services. Mine is named dk.fubar.Test.service (again, any unique name ending in .service will do) and looks like this:
[D-BUS Service]
Name=dk.fubar.Test
Exec=/usr/sbin/dbus-sysbus-test.py
User=root
and that’s it! Provided you installed everything correctly (there’s a cheesy Makefile to do this) things should Just Work(tm) and the following command should print
$ dbus-send --system --print-reply --dest=dk.fubar.Test /SomeObject dk.fubar.Test.SampleInterface.HelloWorld string:foo
method return sender=:1.517 -> dest=:1.516 reply_serial=2
array [
string "Hello"
string " from example-service.py"
string "with unique name"
string ":1.517"
]
If your service is capable of operating correctly when running as an unprivileged system user (e.g. ftp or whatever) instead of root (think least privilege), simply change the user mentioned in both the .service and .conf files.
