[poky] SRCREV_FORMAT does not work as expected

[Martin Jansa]

do_fetch[vardeps] += " SRCREV_glibc SRCREV_localedef”

Is what we're using in recipes with SRCREV_FORMAT for years.

On Thu, Jun 21, 2018 at 12:18 PM Florea, Tudor <tflorea at curtisswright.com>
wrote:

> Hi
>
> It seems that there is a flaw in the way the recipe with more than one SCM
> is fetched.
>
> I take the cross-localedef-native_2.26.bb recipe as an example.
>
>
>
> If I change in the recipe:
>
> SRCREV_glibc ?= "some-new-revision"
>
> and try to rebuild, instead of attempting to fetch the new revision (and
> fail as “some-new-revision” cannot be fetched) “bitbake
> cross-localedef-native” command finishes  without re-running any task.
>
> From bitbake -e the cross-localedef-native output I can see:
>
> SRCREV="INVALID"
>
> SRCREV_FORMAT="glibc_localedef"
>
> SRCREV_glibc=" some-new-revision"
>
> SRCREV_localedef="dfb4afe551c6c6e94f9cc85417bd1f582168c843"
>
>
>
> One workaround for this is to add something like do_fetch[vardeps] +=
> "SRCPV” or  do_fetch[vardeps] += " SRCREV_glibc SRCREV_localedef”  in each
> recipe using multiple SCM but I think there might be a better fix for this.
>
>
>
> Should we add
>
> do_fetch[vardeps] += "SRCPV”
>
> in base.bbclass?
>
>
>
>
> *Tudor Florea *Software Development Engineer
>
> Industrial Division
>
> *Curtiss-Wright *15, Enterprise Way, Aviation Park West,
>
> Bournemouth Airport, CHRISTCHURCH, Dorset, BH23 6HH, United Kingdom
> T: +441202034125
> tflorea at curtisswright.com
>
>
> ------------------------------
> This e-mail and any files transmitted with it are proprietary and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have reason to believe that you have received this e-mail in error,
> please notify the sender and destroy this e-mail and any attached files.
> Please note that any views or opinions presented in this e-mail are solely
> those of the author and do not necessarily represent those of the
> Curtiss-Wright Corporation or any of its subsidiaries. Documents attached
> hereto may contain technology subject to the U.S. Export Regulations.
> Recipient is solely responsible for ensuring that any re-export, transfer
> or disclosure of this information is in accordance with U.S. Export
> Regulations. The recipient should check this e-mail and any attachments for
> the presence of viruses. Curtiss-Wright Corporation and its subsidiaries
> accept no liability for any damage caused by any virus transmitted by this
> e-mail.
> --
> _______________________________________________
> poky mailing list
> poky at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/poky/attachments/20180621/a5711309/attachment-0001.html>