Consider using zbus instead of dbus for easy cross compliation

[sinhpham]

bluer currently depends on dbus, which in turn depends on libdbus, a C library. As a result, cross compiling bluer is hard.

Please consider using a pure Rust alternative to dbus, zbus perhaps? https://crates.io/crates/zbus

See a related issue in a similar crate using dbus: https://github.com/hoodie/notify-rust/issues/85

[laszlourszuly]

What do you mean by "cross compiling bluer is hard"? Cross compiling to different platforms (win, mac linux etc)?

Zbus is currently claimed to be Linux specific. Wouldn't that be equally hard to cross compile, if so?

[sinhpham]

No not different platforms but different architectures. In our case they're various Raspberry Pi devices (RPi 3, 4, Zero), so armv7-unknown-linux-gnueabihf, armv5te-unknown-linux-gnueabi, maybe more.

• For building/CI: you need correct linkers (plural, one with the host architecture for building crates with custom build.rs, one for the target architecture for libdbus), correct linker settings (don't forget the host & target linkers), correct libdbus version & architecture, correct paths, etc...
• At runtime: sometimes we really want statically linked binary, similar to https://github.com/hoodie/notify-rust/issues/85. And libdbus is a deal breaker in those scenarios.

Would you be open to accepting PRs to switch dbus to zbus?

[laszlourszuly]

Thanks for clarifying! I'm just an eager follower of bluer project and can't answer your practical questions regarding PR's and such. Sorry.

[sinhpham]

Haha no worries, I guess it's a question for @surban

[surban]

Yes, generally I am open for it, provided that no functionality is lost. I've successfully cross-compiled BlueR myself, but reducing C dependencies is a good idea in my opinion.

I've never worked with zbus before, but from a quick glance over its documentation it seems that async D-Bus server support is still missing. This would have to be implemented in zbus before it becomes usable for BlueR.

Also, sometimes we have to return "no property" errors over D-Bus because BlueZ tests for existence of properties to determine the write/notify method of a GATT characteristic. I don't know if this can currently be done with zbus.

[zeenix]

Hi there, zbus developer here.

I've never worked with zbus before, but from a quick glance over its documentation it seems that async D-Bus server support is still missing. This would have to be implemented in zbus before it becomes usable for BlueR.

This was added some months back in 2.0 beta and last month we had 2.0 stable release (finally). :) To be clear, that was the high-level API that was missing.

Also, sometimes we have to return "no property" errors over D-Bus because BlueZ tests for existence of properties to determine the write/notify method of a GATT characteristic. I don't know if this can currently be done with zbus.

Quick look at the code you linked to, I'm not sure if you're using some kind of high-level API (does dbus-rs even have that?) or lower-level one (where you do message passing). With the (not so) low-level API of zbus, you can do almost anything.

However, I just checked and you're right that we don't support returning errors from property getters in dbus_interface currently. Nobody reported this or asked for this before today (when I just happen to stumble on this issue) so that's the only reason we missed out on this.

I'll fix this soon. Once fixed, you can easily define custom errors to return on the bus, through DBusError trait and derive macro. You can track the progress in this issue I just created.

[zeenix]

Zbus is currently claimed to be Linux specific. Wouldn't that be equally hard to cross compile, if so?

Now unix-specific but I'm about to merge the PR for windows support and CI. So the coming release should be quite portable in terms of OS.

[surban]

Quick look at the code you linked to, I'm not sure if you're using some kind of high-level API (does dbus-rs even have that?) or lower-level one (where you do message passing). With the (not so) low-level API of zbus, you can do almost anything.

This was a high level API. In fact dbus_crossroads even provides a high-level framework for implementing D-Bus servers.

I'll fix this soon. Once fixed, you can easily define custom errors to return on the bus, through DBusError trait and derive macro. You can track the progress in this issue I just created.

I am looking forward to that! Although I cannot make any promises right now when I'll port to zbus due to limited time.

[zeenix]

Quick look at the code you linked to, I'm not sure if you're using some kind of high-level API (does dbus-rs even have that?) or lower-level one (where you do message passing). With the (not so) low-level API of zbus, you can do almost anything.

This was a high level API. In fact dbus_crossroads even provides a high-level framework for implementing D-Bus servers.

Gotcha, thanks.

I'll fix this soon. Once fixed, you can easily define custom errors to return on the bus, through DBusError trait and derive macro. You can track the progress in this issue I just created.

I am looking forward to that! Although I cannot make any promises right now when I'll port to zbus due to limited time.

Awesome! There is no hurry. :)

[surban]

Would you be open to accepting PRs to switch dbus to zbus?

@sinhpham Now that zbus is ready for use, would you be willing to provide some PRs? ;-)

[wash2]

If there is still interest in PRs switching from dbus to zbus, I'd be happy to start working on them :)

[zeenix]

If there is still interest in PRs switching from dbus to zbus, I'd be happy to start working on them :)

Pretty sure there is (right @surban?) but tbh I haven't yet gotten around to addressing https://gitlab.freedesktop.org/dbus/zbus/-/issues/251 yet. If you could contribute that first, that would be great. Otherwise, you'll have to either use low-level API for interface properties until the missing zbus support is added or wait till I get around to that.

[surban]

Yes, definitely!!!

But I agree with @zeenix that we should add missing features to zbus first. Using a low level API would make BlueR more complex without any benefit.

[wash2]

Ok I will look into that first 👍

[zeenix]

wow @wash2 wasn't messing around. Thanks to them, git main of zbus now supports fallible property getters. @surban There is a small gotcha that currently you can only return fdo::Error though but given that fdo:Error covers a lot of common errors and has a generic variant too, I'm hoping that's not a show-stopper here.

[zeenix]

just FYI I publish zbus 3.10.0 which includes the needed feature.

[zeenix]

@wash2 How is it coming along? Please do let me know if you need any help figuring out the zbus API for this. In case you didn't know already, we've a #zbus:matrix.org Matrix room to get help quickly.

[wash2]

@wash2 How is it coming along? Please do let me know if you need any help figuring out the zbus API for this. In case you didn't know already, we've a #zbus:matrix.org Matrix room to get help quickly.

Hi! To be honest, I have not made much progress on this in the last couple weeks. I will hopefully work on it more soon, but I'm worried that I won't be able to test everything that I'm changing 😅. I assume I will need some advice, so thank you for sharing the link :)

[zeenix]

but I'm worried that I won't be able to test everything that I'm changing sweat_smile

Let's hope @surban can help with that part. Maybe a Draft PR first?

I assume I will need some advice

I can certainly try my best to help with the D-Bus and zbus bits. Unfortunately don't know much about bluez.

[surban]

We don't have tests per se, but most of the functionality is exercised by the examples and tools. If they behave as before, you didn't break it ;)

For testing you don't need anything more that two Raspberry Pis and some basic knowledge of Bluetooth.

[jhartzell42]

Hi @wash2 , I'd be interested in collaborating on this.

[wash2]

Hi @wash2 , I'd be interested in collaborating on this.

@jhartzell42 Honestly, I really haven't had a chance to work on the PR yet, so if you'd like to work on it, go ahead. I would be happy to help where I can but I've unfortunately been very busy on some other projects :smiling_face_with_tear:

[Athorus]

Hello, any news about zbus ? I would like to cross compile from x64 linux to raspberry zero, so it would help a lot.

I was used to compile for target arm-unknown-linux-gnueabi, but since bookworm, ld-linux.so.3 file lib is no longer available on raspberry, so I cannot use anymore the package libdbus-1-dev:armel on compilation host.

Maybe buildroot can do the job…

[zeenix]

@Athorus I think it's just waiting on someone to do the work.

[surban]

@Athorus A workaround for you might be to switch to a distribution that has a desktop counterpart and Raspberry Pi version. For example Ubuntu is available for both x86_64 and aarch64.

[Athorus]

@Athorus A workaround for you might be to switch to a distribution that has a desktop counterpart and Raspberry Pi version. For example Ubuntu is available for both x86_64 and aarch64.

It works for Raspberry pi Zero 2, because aarch64 is compiled with same options, but doern’t work for armhf, because Raspberry Pi armhf (arm v6 + hf) is not compiled with same options as standard Debian armhf (arm v7). In bulleyes I used the trick to compile to armel (arm v5 without hf), but doesn’t work anymore.