muka / go-bluetooth

Golang bluetooth client based on bluez DBus interfaces

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

MapToStruct: Field not found: MTU

Elara6331 opened this issue · comments

commented

I have updated my computer (running Archlinux), and have begun receiving the following error: MapToStruct: Field not found: MTU

BlueZ version: 5.62-1
Dbus version: 1.12.20-1
go-bluetooth version (from go.mod): v0.0.0-20210812063148-b6c83362e27d

This issue seems to be caused by the BlueZ 5.62 update as downgrading the package makes the issue disappear.

commented

I thought this might be an issue with using an old version of go-bluetooth, but it still happens with latest, so I think something changed in BlueZ 5.62

Ok, I'll keep this open and provide an upgrade when I can commit some time. Feel free to move forward and provide a PR eventually. Thanks

I've got similiar issue

go run main.go discovery

the output is:

ERRO[0000] Error: MapToStruct: Field not found: Roles
exit status 1

(default - current Ubuntu 21.10)
Bluez version : 5.60

Merged PR #145 Please reopen if it still an issue

the fix from #145 hasn't been incorporated into master. was it on purpose?
(I was a bit confused to get the same error even though I did go get -u github.com/muka/go-bluetooth@latest)

If it is on 5.62 master may not be aligned as it usually align with ubuntu releases (21.10 ships 5.60).

Can you try with branch bluez/5.62 or regenerate the sources using this command BLUEZ_VERSION=5.62 make all

Thanks

I could fix the error by explicitly specifying the commit from the bluez/5.62 branch.
my question was more on whether it was on purpose that fix wasn't merged into master.
and it seems it was, as you follow Ubuntu releases.
thanks :)

The code is generated from bluez docs, it is possible that the modification has been overwritten by code generation

it seems to me they live on 2 different branches.

* 9857391 (origin/master, origin/HEAD, master) added usage section
* 48824ca override MediaPlayer1.Track to an actual type, fix #133
| * 1c7f879 (HEAD -> v5.62, origin/v5.62) generated v5.62
|/  
* 62e38ae (origin/v5.60) update docs
* 7bf4032 - fix parser on broken properties - remove experimental from file names
*   b99792b Merge pull request #145 from OrgansWithoutBodies/master

to reiterate: 1c7f879 is working fine on my ArchLinux box. (well, the MTU issue is not there)

Thank you, I will try to standardize the releases!

commented

I‘ve just had this reported in evcc-io/evcc#2627. I‘m not sure how to proceed: downgrade to working commit or upgrade master? Upgrade underlying Alpine image?

On master you should find the version compatible with 5.60. There are also branch with different bluez version

commented

User is running 5.63 (evcc-io/evcc#2627 (comment)) which should have MTU as far as I understand. master shows mentioned error. I had expected user to run older bluez version and hence have the error, but why with 5.63?

I added the versioning reference on README and also generated a version for 5.63. I cannot test it right now, feel free to open PR with improvements

commented

Could you try to use branch/5.62 ?

How do I do that?

❯ go get -d github.com/muka/go-bluetooth@bluez/5.63
go get: github.com/muka/go-bluetooth@bluez/5.63: invalid version: version "bluez/5.63" invalid: disallowed version string

Good point, I added git tags and should play better with go get

go get github.com/muka/go-bluetooth@bluez-5.63

If you have suggestions on how to structure versioning of the module in a way that fit your use case I am happy to discuss.

commented

For reference: golang/go#51281

If you have suggestions on how to structure versioning of the module in a way that fit your use case I am happy to discuss.

I'm lacking the bluez insights to do so. Have asked user to retest 5.63 branch.

commented

I think the problem I've had is that I've upgraded master from

github.com/muka/go-bluetooth v0.0.0-20211122080231-b99792bbe62a

to

github.com/muka/go-bluetooth v0.0.0-20211227073548-985739196620

The first commit had MTU, the latest nicht. Not sure how that happened as it seems that MTU is a feature of newer bluez releases?

Master refer to 5.60 which may not have MTU?

commented

Right. What is confusing is that master had MTU in an older commit:

It's my fault, I merged a contribution with that part but other that was broken. Recent commits fixed that. Dbus versions need to be addressed but I need to find a proper way. Do you have an idea?

commented

That's good because the failure is now explainable. I have unfortunately no suggestion about dbus- I'm only consuming this module without deeper Linux experience.

Glad it is solved, my question is about a good way of managing go library versions in respect to the underlying blueZ version.

commented

Two options I could imagine:

  • separate go-bluetooth and go-bluetooth/bluez modules with different versions OR
  • go-bluetooth gets a version policy of supported bluez versions (assuming you can support multiple ones at the same time). One release per bluez version with patches to previous versions per policy (i.e. only last 3 bluezs will be supported).
commented

Resolved for me per #143 (comment)