[yocto] [meta-raspberrypi][PATCH 1/6] linux-raspberrypi: Allow override of PV

[Paul Barker]

On Wed, 15 Jun 2016 01:23:39 +0100
Andrei Gherzan <andrei at gherzan.ro> wrote:

> On Fri, Jun 03, 2016 at 08:47:45PM +0100, Paul Barker wrote:
> > On Fri, 3 Jun 2016 09:07:37 +0300
> > Ionel Badisor <ionelbadisor at gmail.com> wrote:
> >
> > > On 06/03/2016 12:25 AM, Paul Barker wrote:
> > > > On Thu, 2 Jun 2016 10:59:37 +0300
> > > > Ionel Badisor <ionelbadisor at gmail.com> wrote:
> > > >
> > > >> On 06/01/2016 08:55 PM, Paul Barker wrote:
> > > >>> On Tue, 31 May 2016 10:39:03 +0300
> > > >>> Khem Raj <raj.khem at gmail.com> wrote:
> > > >>>
> > > >>>> On May 30, 2016 3:15 PM, "Paul Barker"
> > > >>>> <paul at paulbarker.me.uk> wrote:
> > > >>>>>
> > > >>>>>
> > > >>>>> I'm trying to build from a source archive instead of a git
> > > >>>>> repository (to avoid a ~1.3GB git clone operation) so the
> > > >>>>> use of ${SRCPV} is causing me trouble.
> > > >>>>>
> > > >>>>
> > > >>>> Can you override the whole PV
> > > >>>
> > > >>> I've given this another look and I can get the recipe to
> > > >>> parse if I require linux-raspberrypi.inc before setting PV
> > > >>> instead of afterwards. However do_kernel_configme then gets
> > > >>> confused looking for a "standard/raspberrypi" configuration.
> > > >>> It only works if I modify linux-raspberrypi.inc as per my
> > > >>> patch and set PV before requiring that include file.
> > > >>>
> > > >>> I'm starting to think that I might be doing something wrong
> > > >>> here - is there a supported way to build a kernel from an
> > > >>> archive instead of a git repository within OE?
> > > >>>
> > > >>> Thanks,
> > > >>> Paul Barker
> > > >>>
> > > >> Are you trying to avoid repeated cloning operation to save
> > > >> bandwith and time or you are trying to save disk space?
> > > >
> > > > I'm trying to reduce "time to first build" on a new build
> > > > machine as well as the amount of space/bandwidth needed to
> > > > mirror downloaded files.
> > > >
> > > > Instead of setting PV in each recipe I could just duplicate
> > > > linux-raspberrypi.inc into my own layer with the change I need.
> > > > That's probably the simplest approach for now, I'll just have to
> > > > keep my eye on meta-raspberrypi going forward for any changes to
> > > > linux-raspberrypi.inc which I'd need to incorporate.
> > > >
> > > Maybe you can use the `DL_DIR ?= "/path/to/downloads/"` in your
> > > conf/local.conf file for multiple build directories and if you
> > > want you can copy downloads directory to new machine and point to
> > > it the new local.conf  then all do_fetch operations are already
> > > performed, except new changes in which case the git fetch
> > > operation is performed when git is used and takes less time then
> > > when fetching entire archive.
> > >
> > > note: multiple builds on same machine can use same downloads
> > > directory.
> >
> > I'm planning to release this as part of a distro layer in the
> > future. Not all build machines will be under my control if others
> > use the layer.
> >
> > I'm going to drop this patch for now as I can maintain my own copy
> > of linux-raspberrypi.inc. I think it'd be good to get the other
> > changes into master.
> >
> > V2 incoming.
> 
> I managed to follow the discussion. Sorry for my last reply on this.
> 
> I don't think the solution would be to manage a custom inc file. We
> need to find a solution with this. Can I see and try your changes for
> the arhive?
> 

I've sent a V2 series without this patch and without dropping the
3.18.y kernel recipe. I think the simplest approach would be to merge
that series and then come back to this afterwards so that there aren't
too many different sets of patches flying around.

My recipe and inc file is now public if you want to look at it:
    https://gitlab.com/oryx/meta-oryx/tree/master/recipes-kernel/linux

Thanks,
Paul Barker