Re: [yocto] Hashserve OEEquivHash unihash issue

["Harro Verton" <wanwizard@openpli.org>]

[-- Attachment #1: Type: text/plain, Size: 1675 bytes --]

Thanks for the quick reply, much appreciated !

> 
> What this usually means is that you have two recipes that have different
> task hashes, but produce the same output so the hashserver is mapping them
> together as expected. You might want to figure out why the taskhashes are
> different; if you have the .sigdata files for those hashes (look for e.g.
> "sigdata.8da90b016d0a41cac6ce46c20d8ee64d5e7af35687de43c306544508050227e8"
> in the stamps directory) you can diff them with bitbake-diffsigs and see
> what is actually different.

This file doesn't exist in the stamps directory, and neither does an entry for the hash it was changed to.

The (relevant?) build config contains:

INHERIT += "rm_work"
PRSERV_HOST = "localhost:0"
BB_SIGNATURE_HANDLER = "OEEquivHash"
BB_HASHSERVE = "auto"

INSANE_SKIP += "version-going-backwards"
ERROR_QA:remove = "version-going-backwards"
BUILDHISTORY_CHECKVERBACKWARDS = "0"
INHERIT:remove = "buildhistory"

If I flash the image built on both devices, I see that on the first device, ffmpeg - 6.1.4-r0.0 is installed, and on the second, ffmpeg - 6.1.4-r0.1.  And as a result, the first machine shows in the "opkg list-upgradable" output "ffmpeg - 6.1.4-r0.0 - 6.1.4-r0.1". In deploy/ipks/cortexa15hf-neon-vfpv4 (same for both devices), I only have the ipk for 6.1.4-r0.1.

If I build both MACHINE's a second time, new rootfs files are generated, but to my surprise, for the first device the rootfs still contains ffmpeg - 6.1.4-r0.0, even though that does not exist anywhere in the build tree.

I have no clue where to start looking, but something changed along the way in Scarthgap that "broke" this.

[-- Attachment #2: Type: text/html, Size: 1865 bytes --]