there are two SprotErrors, no relation

[jclulow]

$ pfexec /tmp/humility hiffy -c SpRot.status
humility: attached to 0483:3754:003300324741500820383733 via ST-Link V3
humility hiffy failed: SprotError matches more than one enum: attest_data::messages::SprotError as GOFF 0x00039350 (object 21), drv_sprot_api::error::SprotError as GOFF 0x00044a4a (object 21)

$ /tmp/humility --version
humility 0.11.11

In this case I'm looking for drv_sprot_api::error::SprotError, but it seems that the phonebook now contains an attest_data::messages::SprotError as well. Bryan suggests that we usually correct this condition by qualifying stuff in the idol files?

[labbott]

Fully qualifying the path didn't work for mysterious reasons

$ humility -a target/gimletlet/dist/default/build-gimletlet-image-default.zip hiffy -c SpRot.status
humility: attached via ST-Link V3
humility hiffy failed: failed to find error type Result { ok: AttributedTy { ty: Ty("SprotStatus"), recv: FromBytes }, err: Complex(Ty("drv_sprot_api::SprotError")) }

Taking the easy path out and renaming one of the types instead

[cbiffle]

Fully qualifying the path didn't work for mysterious reasons

FWIW, Humility historically discarded all crate/module path information. There are parallel APIs I've been gradually adding to use fully qualified names, but each module has to be ported over to use them, and we've been adding new code (using the old APIs) faster than I've been able to keep up.

This suggests that the Idol module does not use the fully-qualified APIs.

Edited to add: Tracking as oxidecomputer/humility#512