[yocto] [PATCH][meta-raspberrypi] linux-raspberrypi_dev: don't use AUTOREV

Martin Jansa martin.jansa at gmail.com
Thu Jun 1 00:08:50 PDT 2017


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 <pbarker at toganlabs.com> wrote:

> On Thu, Jun 1, 2017 at 1:17 AM, Khem Raj <raj.khem at gmail.com> wrote:
> > On Wed, May 31, 2017 at 5:00 PM, Andrei Gherzan <andrei at gherzan.ro>
> wrote:
> >>
> >> On Tue, May 30, 2017 at 6:29 PM, Khem Raj <raj.khem at gmail.com> wrote:
> >>>
> >>> On Tue, May 30, 2017 at 10:25 AM, Andre McCurdy <armccurdy at gmail.com>
> >>> wrote:
> >>> > On Tue, May 30, 2017 at 10:15 AM, Paul Barker <pbarker at toganlabs.com
> >
> >>> > wrote:
> >>> >> On 30 May 2017 5:08 p.m., "Khem Raj" <raj.khem at gmail.com> wrote:
> >>> >>
> >>> >> On Tue, May 30, 2017 at 12:57 AM, Martin Jansa <
> martin.jansa at 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 at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20170601/8e7bff37/attachment.html>


More information about the yocto mailing list