And it's not clear from the diff you send, but like linux-yocto-dev.bb example above, the recipe needs to be renamed from linux-raspberrypi_dev.bb to linux-raspberrypi-dev.bb to make it different provider.
On Thu, Jun 1, 2017 at 9:08 AM, Martin Jansa <martin.ja...@gmail.com> wrote: > Yes, Paul approach looks good to me, I think it was what was suggested in > first replies to my SRCREV change and I agree with that, I just haven't had > time to send updated patch. > > Paul if you have the patch ready please send it, thanks!. > > On Thu, Jun 1, 2017 at 8:10 AM, Paul Barker <pbar...@toganlabs.com> wrote: > >> On Thu, Jun 1, 2017 at 1:17 AM, Khem Raj <raj.k...@gmail.com> wrote: >> > On Wed, May 31, 2017 at 5:00 PM, Andrei Gherzan <and...@gherzan.ro> >> wrote: >> >> >> >> On Tue, May 30, 2017 at 6:29 PM, Khem Raj <raj.k...@gmail.com> wrote: >> >>> >> >>> On Tue, May 30, 2017 at 10:25 AM, Andre McCurdy <armccu...@gmail.com> >> >>> wrote: >> >>> > On Tue, May 30, 2017 at 10:15 AM, Paul Barker < >> pbar...@toganlabs.com> >> >>> > wrote: >> >>> >> On 30 May 2017 5:08 p.m., "Khem Raj" <raj.k...@gmail.com> wrote: >> >>> >> >> >>> >> On Tue, May 30, 2017 at 12:57 AM, Martin Jansa < >> martin.ja...@gmail.com> >> >>> >> wrote: >> >>> >>> * use latest revision in rpi-4.11.y branch >> >>> >>> * using AUTOREV causes bitbake to run git ls-remote on the >> github.com >> >>> >>> repository in order >> >>> >>> to convert AUTOREV to currently latest SRCREV even when you >> don't >> >>> >>> use >> >>> >>> linux-raspberrypi_dev >> >>> >>> at all, just happen to have meta-raspberrypi layer in your >> >>> >>> bblayers.conf, that's bad for >> >>> >>> people who want to be able to build without network access >> >>> >>> (completely >> >>> >>> from premirror) >> >>> >>> >> >>> >> >> >>> >> These branches get rebased often so locking SRCREV caused another >> >>> >> kind of problem. what we can do is. >> >>> >> >> >>> >> 1. Let user like you override the SRCREC via a bbappend or conf >> file. >> >>> >> so change the assignment to ?= >> >>> >> 2. Delete the recipe completely. We lose some of upstream testing. >> >>> >> >> >>> >> We should be able to skip the recipe if it isn't selected as the >> >>> >> preferred >> >>> >> version and/or provider of "virtual/kernel". I'm out at the minute >> so >> >>> >> can't >> >>> >> look at it now but will try to take a look later this week. >> >>> > >> >>> > The linux-yocto-dev.bb recipe contains an example of doing that. >> >>> > >> >>> >> >>> ah perfect. Thats what we need here >> >>> >> >>> >> >>> http://cgit.openembedded.org/openembedded-core/tree/meta/rec >> ipes-kernel/linux/linux-yocto-dev.bb?h=master#n28 >> >>> >> >>> please rename the recipe to be linux-raspberrypi-dev.bb and add the >> magic >> >>> above and send a v2 >> >>> >> >> >> >> Using the magic above we still hardcode a revision there. So if a user >> wants >> >> to compile the recipe without setting the preferred provider it will >> fail. >> > >> > what will be the usecase ? when you have a different kernel selected but >> > woould like to compile yet another kernel >> > >> > that rev can be a well known rev like branchpoint. Moreover, I think >> > if someone wants to use the dev recipe then its expected that they >> > switch >> > to using AUTOREV or some other local mechanism for pinning if needed. >> > >> >> I was thinking of a different approach entirerly. We can add the >> following at the top of the recipe file: >> >> python __anonymous() { >> if "linux-raspberrypi-dev" not in >> d.getVar("PREFERRED_PROVIDER_virtual/kernel"): >> msg = "Skipping linux-raspberrypi-dev as it is not the preferred >> " + \ >> "provider of virtual/kernel." >> raise bb.parse.SkipRecipe(msg) >> } >> >> (Hopefully gmail won't mangle that too much) >> >> I've just tested it and it works fine as long as it's before the use >> of ${AUTOREV}. If there's no objections to this approach I'll submit a >> patch. >> >> Cheers, >> >> -- >> Paul Barker >> Co-Founder & Principal Engineer >> Togán Labs Ltd >> -- >> _______________________________________________ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto >> > >
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto