[poky] SRCREV_FORMAT does not work as expected

[Martin Jansa]

I forgot to mention that this is needed only if your PV doesn't include
SRCPV.

On Thu, Jun 21, 2018 at 1:32 PM Martin Jansa <martin.jansa at gmail.com> wrote:

> 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/e25f6b70/attachment.html>