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

[Paul Barker <pbarker@toganlabs.com>]

On Thu, Jun 1, 2017 at 1:17 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Wed, May 31, 2017 at 5:00 PM, Andrei Gherzan <andrei@gherzan.ro> wrote:
>>
>> On Tue, May 30, 2017 at 6:29 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>
>>> On Tue, May 30, 2017 at 10:25 AM, Andre McCurdy <armccurdy@gmail.com>
>>> wrote:
>>> > On Tue, May 30, 2017 at 10:15 AM, Paul Barker <pbarker@toganlabs.com>
>>> > wrote:
>>> >> On 30 May 2017 5:08 p.m., "Khem Raj" <raj.khem@gmail.com> wrote:
>>> >>
>>> >> On Tue, May 30, 2017 at 12:57 AM, Martin Jansa <martin.jansa@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