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/ > recipes-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