MapToStruct: Field not found: MTU
Elara6331 opened this issue · 29 comments
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.
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
https://patchwork.kernel.org/project/bluetooth/patch/20210826164211.2936133-1-david@lechnology.com/ the API change in question that caused this afaict
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!
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
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?
Could you try to use branch/5.62 ?
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
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.
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.
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?
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?
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.
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).
Resolved for me per #143 (comment)