Recent version doesn't work on Debian buster

[aykevl]

I haven't investigated this issue yet, but I have bisected it.

Recent versions of the bluetooth package fail on the Raspberry Pi (Debian 10.4, BlueZ 5.50):

$ go run ./examples/heartrate/
starting
panic: failed to add service: Failed to create entry in database

goroutine 1 [running]:
main.must(...)
        /home/ayke/src/tinygo.org/x/bluetooth/examples/heartrate/main.go:64
main.main()
        /home/ayke/src/tinygo.org/x/bluetooth/examples/heartrate/main.go:26 +0x51c
exit status 2

The commit introducing this is 2fb3b08, introduced in #36.

[aykevl]

Also confirmed this on my laptop, running Debian buster with BlueZ 5.50 (same as the Raspberry Pi).

[mogenson]

I see the same thing. Ubuntu 20.04, bluez 5.53.

[deadprogram]

Please give a try with this branch https://github.com/tinygo-org/bluetooth/tree/update-bluez-555 which updates the go-bluetooth package to the latest version with updated Bluez wrappers.

[mogenson]

Unfortunately, I get the exact same output as before. I also tried on Arch Linux with bluez 5.55.

[aykevl]

Same for me, it still doesn't work on the update-bluez-555 branch. I suspect it's because the bluetooth package assumes a newer BlueZ version. Maybe BlueZ has made a backwards incompatible change?

[deadprogram]

I think it is something to do with changes to the wrapper generation in https://github.com/muka/go-bluetooth/commits/master/gen since the last working version, which at least on my machine is also muka/go-bluetooth@f6113f7

Note that I am testing by running "old" version of BlueZ:

$ bluetoothctl --version
bluetoothctl: 5.48

If reverting to older SHA of go-bluetooth "fixes" for most of us, we should do that while we look into what might be the root cause. What does everyone think?

[mogenson]

I think that sounds good. Keeping on top of bluez releases is going to be a constantly moving target, so this probably won't be the last time something breaks :)

Happy to try out a new branch or PR when it's available.

[deadprogram]

@mogenson and @aykevl please give a try to #49 it appears to correct this issue on my machine with BlueZ 5.50 installed. Thanks!

[aykevl]

A quick test shows that it doesn't crash anymore. I haven't checked whether it actually works but assuming you've tested it, LGTM.

[mogenson]

Unfortunately the examples are still failing for me, but now with a different error:

$ go run ./examples/heartrate
go: downloading github.com/muka/go-bluetooth v0.0.0-20200619025933-f6113f7141c5
starting
panic: failed to enable BLE stack: MapToStruct: Field not found: Roles

goroutine 1 [running]:
main.must(...)
	/home/mike/Projects/bluetooth/examples/heartrate/main.go:54
main.main()
	/home/mike/Projects/bluetooth/examples/heartrate/main.go:17 +0x7c5
exit status 2

$ go run ./examples/scanner
panic: failed to enable BLE stack: MapToStruct: Field not found: Roles

goroutine 1 [running]:
main.must(...)
	/home/mike/Projects/bluetooth/examples/scanner/main.go:23
main.main()
	/home/mike/Projects/bluetooth/examples/scanner/main.go:11 +0x1df
exit status 2

$ pacman -Qi bluez
Name            : bluez
Version         : 5.55-1

[deadprogram]

@mogenson I thought you were using Ubuntu?

[deadprogram]

Also, you perhaps want to try 5.50:

$ bluetoothctl --version
bluetoothctl: 5.50

This is the version that the recent commit downgraded to, which is, as @aykevl points out the current version on Raspian.

[mogenson]

Sorry for the delay. I have a Ubuntu 20.04 laptop. Just haven't used it recently.

$ bluetoothctl --version
bluetoothctl: 5.53

From the dev branch:

$ go run ./examples/scanner
# works great!

$ go run ./examples/heartrate
starting
panic: failed to start adv: MapToStruct: Field not found: SupportedSecondaryChannels

[deadprogram]

@mogenson can you run this while running the program that fails?

sudo dbus-monitor --system "type=error"

Thanks.

[james-lawrence]

this looks like its due to muka generating invalid UUIDs if passed 128 bit uuids for a service.

[deadprogram]

Now closing since 0.9.0 has been released. Thank you!

[aykevl]

This was most likely fixed with #216.