On Wed, Nov 13, 2019 at 8:23 AM Richard Purdie <richard.pur...@linuxfoundation.org> wrote: > > On Wed, 2019-11-13 at 16:21 +0000, Richard Purdie wrote: > > On Wed, 2019-11-13 at 06:00 -0800, Andre McCurdy wrote: > > > With the following test recipe, foo.bb: > > > > > > LICENSE = "CLOSED" > > > PV .= "+git${SRCPV}" > > > SRCREV = "015b0cdce1a0abb68ab99510e7fc8d2f77e8ec77" > > > SRCREV_class-native = "fc3e8f717779cabcbe583cac304308eaad5f1648" > > > SRC_URI = "git://github.com/file/file.git;protocol=https" > > > S = "${WORKDIR}/git" > > > BBCLASSEXTEND = "native" > > > > > > when building foo-native, although SRCREV is set to "fc3..." via > > > the > > > class-native over-ride, the version of code actually fetched is > > > "015..": > > > > > > $ bitbake foo-native -e | grep -e ^SRCREV= -e ^PV= > > > PV="1.0+gitAUTOINC+015b0cdce1" > > > SRCREV="fc3e8f717779cabcbe583cac304308eaad5f1648" > > > > > > A similar problem happens in reverse if SRCREV is set using a > > > machine > > > specific over-ride, e.g. > > > > > > SRCREV = "015b0cdce1a0abb68ab99510e7fc8d2f77e8ec77" > > > SRCREV_mymachine = "fc3e8f717779cabcbe583cac304308eaad5f1648" > > > > > > Now foo-native fetches the target specific version "fc3..." even > > > though the machine specific over-ride shouldn't effect -native > > > variants: > > > > > > $ bitbake foo-native -e | grep -e ^SRCREV= -e ^PV= > > > PV="1.0+gitAUTOINC+fc3e8f7177" > > > SRCREV="015b0cdce1a0abb68ab99510e7fc8d2f77e8ec77" > > > > > > Commenting out the line which appends "+git${SRCPV}" to PV seems to > > > be > > > a workaround which results in the expected version of code being > > > fetched. > > > > I tried this with master and didn't see it reproduce. Do you have: > > > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=d427f58977a46f2bda4b7f30cf83793373e401d3 > > > > applied when your build sees this? > > I just reverted that and retested. I started seeing a lot of basehash > errors which tends to confirm my suspicion that the above patch is the > same issue and fixes this. It does raise the idea we may be able to > make a testcase out of this though...
I tested with 2.7 and 3.0 but not latest master, so didn't have this fix. Cherry-picking that one change does seem to fix the issue (tested with 2.7). -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core