Greetings All,
some guidance/orientation would be highly appreciated. Big thank you in advance, if so. knows how to crack that nut !
PROBLEM STATEMENT
we've tried building Bluebox repo obtained from github but do run into issues as early as at recipe parsing stage of Yocto due to a host of old Codeaurora URIs. Seems to affect all BSPs, no matter the rev (tried 36,35,....).
https://github.com/nxp-auto-linux/auto_yocto_bsp/tree/bsp36.0
Lots of URIs to git://source.codeaurora.org in many dozens of .bb files.
ONE OFF - ATTEMPT
Tried changing them to github manually, for instance for optee package. Works. But very tedious to do for all packages.
THEORY SOUGHT
Please see embedded image.
Yocto, in its enigmatic way spits out sth about...
SRCPV -> PV -> PKGV -> EXTENDPKGV -> RDDEPENDS...
... which appears to be job security measure for yoctoproject.org consultants.
Blue arrow (in img): How exactly bitbake catches wind of new github SCM we dont know - grepped the entire folder structure recursively - github URI nowhere to be found.
Blue and Red square (in img): How exactly SRCREV_FORMAT could be used/set to which value, in order to direct bitbake to discard codeaurora URIs and proceed to github ones only is not detailed , nor described on yoctoproject.org where that var is mentioned but its use not really detailed by example.

GENERALIZING ATTEMPT CONSIDERED (could someone confirm / deny?)
Facing all these double URIs confusing bitbake,
and in absence of clear definition of how to set SRCREV_FORMAT globally,
and in rejection to having to change everything manually (in all 60..100 .bb files),
we consider conducting heresy by changing data_smart.py or utils.py in bitbake, where the ambiguity by two SCMs creates the error causing bitbake to abort.
Could someone share some thought on that ?
-OR-
Could someone advise what/if NXP is going to correct those URIs ?
Thanks everyone !
BR !