[OE-core] 2.6 planning proposals and meeting

[Scott Rifenbark]

On Tue, May 1, 2018 at 7:46 AM, Richard Purdie <
richard.purdie at linuxfoundation.org> wrote:

> Hi,
>
> On Fri, 2018-04-20 at 08:02 -0400, Daniel F. Dickinson wrote:
> > I'm relatively new to OE; I've written a couple of pre-alpha layers
> > to try some idea, and worked on meta-openembedded, but I've not had a
> > chance to go in depth on the Yocto documentation, and at the some
> > there see to be things (based on the lists) that are out of date, or
> > new things that aren't even mentioned, which makes getting up speed
> > somewhat difficult.
>
> Writing down where you think there are issues would be a help so that
> we can see if there is some way we can improve that.
>

Yes - please indicate any areas in the documentation you believe need
updated, changed, or added.  I have been trying to bring things up-to-date
in several manuals during the 2.5 process.  So, identifying areas in the
2.5 manual set would be very helpful.  To be sure you are viewing 2.5
manuals use the following form for the URL:

      yoctoproject.org/docs/2.5/<manual_folder>/<manual_folder>.html

      where <manual_folder> is

           brief-yoctoprojectqs
           bsp-guide
           overview-manual
           dev-manual
           sdk-manual
           profile-manual
           kernel-dev
           ref-manual
           toaster-manual
           bitbake-user-guide

Thanks
Scott




>
> > In any even one thing that I'm wondering if is of interest, is
> > modifying the build process to build an eSDK which is used to build
> > everything else.  The advantage of this, in my view, is that it makes
> > it easier to do things like use GitHub+Travis integration on
> > individual recipes.
>
> I know people who've tried travis with OE and the challenge is the
> length of the builds and the data usage. I'm not sure that problem
> changes regardless of whether the eSDK or native sstate is used as the
> size would be comparable.
>
> > The biggest challenge for this type of per-recipe build is dealing
> > with dependencies, but I think it would be helpful to get rid of 3-
> > day+ world builds.
> >
> > At the very least having a 'standard' binary eSDK for external layers
> > to use for this purpose would helpful in my view.
>
> How would that differ from a specific version of OE-Core used for
> testing for which a known good set of sstate were available?
>
> > I'm interested in working on this, but I don't think I've got a good
> > enough handle on OE for making this a 2.6 goal from me.
> >
> > Thoughts?
>
> I like the idea of thinking more in this area and would certainly
> welcome help. I think the issue is more one of tools to generate a
> locked sstate which layers then reuse rather than anything eSDK
> specific. Its therefore partly a process problem of generating that
> specific config and sstate which others would reuse. You could do this
> from things that already exist, e.g. from the OE-Core milestone
> releases but its not something people have really adopted for testing
> of other layers.
>
> Certainly worth exploring but the devil is in the details.
>
> Also worth mentioning that build-appliance exists which is an image
> capable of "self hosting" builds. There are often specific patches
> applied to native tools and version requirements which mean that the
> -native recipes are often essential to the build though.
>
> Cheers,
>
> Richard
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180501/f3309433/attachment-0002.html>