[OE-core] fetcher uses wrong SRCREV for class-native

[Andre McCurdy]

On Wed, Nov 13, 2019 at 8:23 AM Richard Purdie
<richard.purdie at 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).