2.6 planning proposals and meeting

2.6 planning proposals and meeting

[Richard Purdie]

[Widely cross posted but please reply to openembedded-core only for
want of picking somewhere to discuss this]

The next big question facing us is what would we like to do in 2.6?
What can we do with the resources we have?

I'm proposing to hijack the next monthly Yocto Project technical
call[1] and dedicate it to 2.6 planning. I'm going to detail some high
level 'big' ideas blow in this email from a feature development
perspective. Anyone is welcome to join the call (or reply) and I'm
happy to answer questions about the ideas below and hear suggestions of
others.

[1] https://www.yoctoproject.org/monthly-technical-call/

Ultimately, ideas will be turned into bugzilla enhancement entries. It
will then be a case of seeing who is willing to step up and help work
on any given feature. We're using the "2.99" target milestone as our
holding area for potential ideas, only moving to 2.6 when we have a
solid commitment for someone to do something.

If nobody steps up for something, chances are it will just get pushed
out as a "Future" idea. In the past, Intel in particular has stepped up
and done a lot of feature work but for various reasons, this is not
likely to happen going forward as they focus more in Intel specific
work.

At the end of the day, we'll process the changes that make it onto the
mailing list by the freeze deadlines for the milestones. If its not
there, it won't be in the release and 2.6 will be what people put into
it.

List of high level 'big' ideas:

- Reference binary package feed (in particular to test upgrade paths)
-
Secure/trusted boot support in OE-Core
- Improved security tools (e.g.
CVE database scanning)
- Provide sstate feed out the box for reference
-
Improve binary output testing (esp. reproducibility, upgrade paths)
-
Widen the scope of our automated testing infrastructure (include
  more
layers)
- Roll processes and tooling into the wider ecosystem (e.g.
meta-
  openembedded)
- Ability to make builds more efficient by output
comparison and
  sstate prebuilt reuse in many more cases. Maybe sstate
equivalence   
  server
- Completion of migration to new autobuilder
codebase and 
  infrastructure
- Out of box experience/layer setup
tooling
- Improved binary reproducibility

Features aren't all we need to plan for. There are other areas that
need work/help:

Many other smaller features

  There are too many for me to list/call out individually but search 
  bugzilla for 2.99 Medium+ items. A good example is adding 
  support for inter-multiconfig dependencies which is a small 
  remaining multiconfig item which would make a big difference to 
  certain workflows.

  Another harder example is parallelisation of oe-selftest. Its 
  currently the thing which ends up taking the longest in most of our 
  builds, improving its performance would reduce overall testing times.

OE-Core Recipe maintenance: 840 recipes in OE-Core
  
  - General recipe
updates
  - Security fixes
  - Recipe specific bugs/regressions
  - Adapt
to new technologies/upstream changes

General patch review

  ~5000 commits/year which need review, testing, identifying 
  regressions, merging

General regressions

  Regressions tests we have are good but don't catch every race 
  condition or intermittent problem. We end up having to track
  down several, particularly runtime testing instability

Bug fixing user issues

  Users find new use cases and workflows and identify bugs which then 
  need to be addressed

  For example we can't default to mem-res bitbake as there are known 
 
issues.

Maintain the tools

  We directly maintain tools like bitbake, pseudo, devtool, recipetool
  opkg, yocto-autobuilder, patchwork+patchtest, wic

Stable release maintenance

  People all want stable releases and security fixes but someone has 
  to make these happen.


Help in any and all of these areas is much appreciated. Also keep in
mind the things above are just to get people thinking. If there are
changes you'd like to see, now is your chance to proposal and work on
them to make them a reality.

Cheers,

Richard

2.6 planning proposals and meeting

[Richard Purdie]

[Widely cross posted but please reply to openembedded-core only for
want of picking somewhere to discuss this]

The next big question facing us is what would we like to do in 2.6?
What can we do with the resources we have?

I'm proposing to hijack the next monthly Yocto Project technical
call[1] and dedicate it to 2.6 planning. I'm going to detail some high
level 'big' ideas blow in this email from a feature development
perspective. Anyone is welcome to join the call (or reply) and I'm
happy to answer questions about the ideas below and hear suggestions of
others.

[1] https://www.yoctoproject.org/monthly-technical-call/

Ultimately, ideas will be turned into bugzilla enhancement entries. It
will then be a case of seeing who is willing to step up and help work
on any given feature. We're using the "2.99" target milestone as our
holding area for potential ideas, only moving to 2.6 when we have a
solid commitment for someone to do something.

If nobody steps up for something, chances are it will just get pushed
out as a "Future" idea. In the past, Intel in particular has stepped up
and done a lot of feature work but for various reasons, this is not
likely to happen going forward as they focus more in Intel specific
work.

At the end of the day, we'll process the changes that make it onto the
mailing list by the freeze deadlines for the milestones. If its not
there, it won't be in the release and 2.6 will be what people put into
it.

List of high level 'big' ideas:

- Reference binary package feed (in particular to test upgrade paths)
-
Secure/trusted boot support in OE-Core
- Improved security tools (e.g.
CVE database scanning)
- Provide sstate feed out the box for reference
-
Improve binary output testing (esp. reproducibility, upgrade paths)
-
Widen the scope of our automated testing infrastructure (include
  more
layers)
- Roll processes and tooling into the wider ecosystem (e.g.
meta-
  openembedded)
- Ability to make builds more efficient by output
comparison and
  sstate prebuilt reuse in many more cases. Maybe sstate
equivalence   
  server
- Completion of migration to new autobuilder
codebase and 
  infrastructure
- Out of box experience/layer setup
tooling
- Improved binary reproducibility

Features aren't all we need to plan for. There are other areas that
need work/help:

Many other smaller features

  There are too many for me to list/call out individually but search 
  bugzilla for 2.99 Medium+ items. A good example is adding 
  support for inter-multiconfig dependencies which is a small 
  remaining multiconfig item which would make a big difference to 
  certain workflows.

  Another harder example is parallelisation of oe-selftest. Its 
  currently the thing which ends up taking the longest in most of our 
  builds, improving its performance would reduce overall testing times.

OE-Core Recipe maintenance: 840 recipes in OE-Core
  
  - General recipe
updates
  - Security fixes
  - Recipe specific bugs/regressions
  - Adapt
to new technologies/upstream changes

General patch review

  ~5000 commits/year which need review, testing, identifying 
  regressions, merging

General regressions

  Regressions tests we have are good but don't catch every race 
  condition or intermittent problem. We end up having to track
  down several, particularly runtime testing instability

Bug fixing user issues

  Users find new use cases and workflows and identify bugs which then 
  need to be addressed

  For example we can't default to mem-res bitbake as there are known 
 
issues.

Maintain the tools

  We directly maintain tools like bitbake, pseudo, devtool, recipetool
  opkg, yocto-autobuilder, patchwork+patchtest, wic

Stable release maintenance

  People all want stable releases and security fixes but someone has 
  to make these happen.


Help in any and all of these areas is much appreciated. Also keep in
mind the things above are just to get people thinking. If there are
changes you'd like to see, now is your chance to proposal and work on
them to make them a reality.

Cheers,

Richard

Re: [Openembedded-architecture] 2.6 planning proposals and meeting

[akuster808]

On 04/19/2018 09:17 AM, Richard Purdie wrote:
> [Widely cross posted but please reply to openembedded-core only for
> want of picking somewhere to discuss this]
>
> The next big question facing us is what would we like to do in 2.6?
> What can we do with the resources we have?
>
> I'm proposing to hijack the next monthly Yocto Project technical
> call[1] and dedicate it to 2.6 planning. I'm going to detail some high
> level 'big' ideas blow in this email from a feature development
> perspective. Anyone is welcome to join the call (or reply) and I'm
> happy to answer questions about the ideas below and hear suggestions of
> others.
>
> [1] https://www.yoctoproject.org/monthly-technical-call/
>
> Ultimately, ideas will be turned into bugzilla enhancement entries. It
> will then be a case of seeing who is willing to step up and help work
> on any given feature. We're using the "2.99" target milestone as our
> holding area for potential ideas, only moving to 2.6 when we have a
> solid commitment for someone to do something.
>
> If nobody steps up for something, chances are it will just get pushed
> out as a "Future" idea. In the past, Intel in particular has stepped up
> and done a lot of feature work but for various reasons, this is not
> likely to happen going forward as they focus more in Intel specific
> work.
>
> At the end of the day, we'll process the changes that make it onto the
> mailing list by the freeze deadlines for the milestones. If its not
> there, it won't be in the release and 2.6 will be what people put into
> it.
>
> List of high level 'big' ideas:
>
> - Reference binary package feed (in particular to test upgrade paths)
> -
> Secure/trusted boot support in OE-Core
> - Improved security tools (e.g.
> CVE database scanning)
I have ideas on the CVE scanning stuff.
> - Provide sstate feed out the box for reference
> -
> Improve binary output testing (esp. reproducibility, upgrade paths)
> -
> Widen the scope of our automated testing infrastructure (include
>   more
> layers)
> - Roll processes and tooling into the wider ecosystem (e.g.
> meta-
>   openembedded)
> - Ability to make builds more efficient by output
> comparison and
>   sstate prebuilt reuse in many more cases. Maybe sstate
> equivalence   
>   server
> - Completion of migration to new autobuilder
> codebase and 
>   infrastructure
Count me in on the new autobuilder codebase

> - Out of box experience/layer setup
> tooling
> - Improved binary reproducibility
>
> Features aren't all we need to plan for. There are other areas that
> need work/help:
>
> Many other smaller features
>
>   There are too many for me to list/call out individually but search 
>   bugzilla for 2.99 Medium+ items. A good example is adding 
>   support for inter-multiconfig dependencies which is a small 
>   remaining multiconfig item which would make a big difference to 
>   certain workflows.
>
>   Another harder example is parallelisation of oe-selftest. Its 
>   currently the thing which ends up taking the longest in most of our 
>   builds, improving its performance would reduce overall testing times.
>
> OE-Core Recipe maintenance: 840 recipes in OE-Core
>   
>   - General recipe
> updates
>   - Security fixes
>   - Recipe specific bugs/regressions
>   - Adapt
> to new technologies/upstream changes
>
> General patch review
>
>   ~5000 commits/year which need review, testing, identifying 
>   regressions, merging
>
> General regressions
>
>   Regressions tests we have are good but don't catch every race 
>   condition or intermittent problem. We end up having to track
>   down several, particularly runtime testing instability
>
> Bug fixing user issues
>
>   Users find new use cases and workflows and identify bugs which then 
>   need to be addressed
>
>   For example we can't default to mem-res bitbake as there are known 
>  
> issues.
>
> Maintain the tools
>
>   We directly maintain tools like bitbake, pseudo, devtool, recipetool
>   opkg, yocto-autobuilder, patchwork+patchtest, wic
>
> Stable release maintenance
>
>   People all want stable releases and security fixes but someone has 
>   to make these happen.
I am fine continuing maintaining the stable branchs.
- Armin
>
>
> Help in any and all of these areas is much appreciated. Also keep in
> mind the things above are just to get people thinking. If there are
> changes you'd like to see, now is your chance to proposal and work on
> them to make them a reality.
>
> Cheers,
>
> Richard
>
>
>
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

Re: [Openembedded-architecture] 2.6 planning proposals and meeting

[akuster808]

On 04/19/2018 09:17 AM, Richard Purdie wrote:
> [Widely cross posted but please reply to openembedded-core only for
> want of picking somewhere to discuss this]
>
> The next big question facing us is what would we like to do in 2.6?
> What can we do with the resources we have?
>
> I'm proposing to hijack the next monthly Yocto Project technical
> call[1] and dedicate it to 2.6 planning. I'm going to detail some high
> level 'big' ideas blow in this email from a feature development
> perspective. Anyone is welcome to join the call (or reply) and I'm
> happy to answer questions about the ideas below and hear suggestions of
> others.
>
> [1] https://www.yoctoproject.org/monthly-technical-call/
>
> Ultimately, ideas will be turned into bugzilla enhancement entries. It
> will then be a case of seeing who is willing to step up and help work
> on any given feature. We're using the "2.99" target milestone as our
> holding area for potential ideas, only moving to 2.6 when we have a
> solid commitment for someone to do something.
>
> If nobody steps up for something, chances are it will just get pushed
> out as a "Future" idea. In the past, Intel in particular has stepped up
> and done a lot of feature work but for various reasons, this is not
> likely to happen going forward as they focus more in Intel specific
> work.
>
> At the end of the day, we'll process the changes that make it onto the
> mailing list by the freeze deadlines for the milestones. If its not
> there, it won't be in the release and 2.6 will be what people put into
> it.
>
> List of high level 'big' ideas:
>
> - Reference binary package feed (in particular to test upgrade paths)
> -
> Secure/trusted boot support in OE-Core
> - Improved security tools (e.g.
> CVE database scanning)
I have ideas on the CVE scanning stuff.
> - Provide sstate feed out the box for reference
> -
> Improve binary output testing (esp. reproducibility, upgrade paths)
> -
> Widen the scope of our automated testing infrastructure (include
>   more
> layers)
> - Roll processes and tooling into the wider ecosystem (e.g.
> meta-
>   openembedded)
> - Ability to make builds more efficient by output
> comparison and
>   sstate prebuilt reuse in many more cases. Maybe sstate
> equivalence   
>   server
> - Completion of migration to new autobuilder
> codebase and 
>   infrastructure
Count me in on the new autobuilder codebase

> - Out of box experience/layer setup
> tooling
> - Improved binary reproducibility
>
> Features aren't all we need to plan for. There are other areas that
> need work/help:
>
> Many other smaller features
>
>   There are too many for me to list/call out individually but search 
>   bugzilla for 2.99 Medium+ items. A good example is adding 
>   support for inter-multiconfig dependencies which is a small 
>   remaining multiconfig item which would make a big difference to 
>   certain workflows.
>
>   Another harder example is parallelisation of oe-selftest. Its 
>   currently the thing which ends up taking the longest in most of our 
>   builds, improving its performance would reduce overall testing times.
>
> OE-Core Recipe maintenance: 840 recipes in OE-Core
>   
>   - General recipe
> updates
>   - Security fixes
>   - Recipe specific bugs/regressions
>   - Adapt
> to new technologies/upstream changes
>
> General patch review
>
>   ~5000 commits/year which need review, testing, identifying 
>   regressions, merging
>
> General regressions
>
>   Regressions tests we have are good but don't catch every race 
>   condition or intermittent problem. We end up having to track
>   down several, particularly runtime testing instability
>
> Bug fixing user issues
>
>   Users find new use cases and workflows and identify bugs which then 
>   need to be addressed
>
>   For example we can't default to mem-res bitbake as there are known 
>  
> issues.
>
> Maintain the tools
>
>   We directly maintain tools like bitbake, pseudo, devtool, recipetool
>   opkg, yocto-autobuilder, patchwork+patchtest, wic
>
> Stable release maintenance
>
>   People all want stable releases and security fixes but someone has 
>   to make these happen.
I am fine continuing maintaining the stable branchs.
- Armin
>
>
> Help in any and all of these areas is much appreciated. Also keep in
> mind the things above are just to get people thinking. If there are
> changes you'd like to see, now is your chance to proposal and work on
> them to make them a reality.
>
> Cheers,
>
> Richard
>
>
>
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

Re: 2.6 planning proposals and meeting

[Daniel F. Dickinson]

On 2018-04-19 12:17 PM, Richard Purdie wrote:
> [Widely cross posted but please reply to openembedded-core only for
> want of picking somewhere to discuss this]
> 
> The next big question facing us is what would we like to do in 2.6?
> What can we do with the resources we have?
> 
> I'm proposing to hijack the next monthly Yocto Project technical
> call[1] and dedicate it to 2.6 planning. I'm going to detail some high
> level 'big' ideas blow in this email from a feature development
> perspective. Anyone is welcome to join the call (or reply) and I'm
> happy to answer questions about the ideas below and hear suggestions of
> others.

Hi,

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.

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.

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.

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?

Daniel

> 
> [1] https://www.yoctoproject.org/monthly-technical-call/
> 
> Ultimately, ideas will be turned into bugzilla enhancement entries. It
> will then be a case of seeing who is willing to step up and help work
> on any given feature. We're using the "2.99" target milestone as our
> holding area for potential ideas, only moving to 2.6 when we have a
> solid commitment for someone to do something.
> 
> If nobody steps up for something, chances are it will just get pushed
> out as a "Future" idea. In the past, Intel in particular has stepped up
> and done a lot of feature work but for various reasons, this is not
> likely to happen going forward as they focus more in Intel specific
> work.
> 
> At the end of the day, we'll process the changes that make it onto the
> mailing list by the freeze deadlines for the milestones. If its not
> there, it won't be in the release and 2.6 will be what people put into
> it.
> 
> List of high level 'big' ideas:
> 
> - Reference binary package feed (in particular to test upgrade paths)
> -
> Secure/trusted boot support in OE-Core
> - Improved security tools (e.g.
> CVE database scanning)
> - Provide sstate feed out the box for reference
> -
> Improve binary output testing (esp. reproducibility, upgrade paths)
> -
> Widen the scope of our automated testing infrastructure (include
>    more
> layers)
> - Roll processes and tooling into the wider ecosystem (e.g.
> meta-
>    openembedded)
> - Ability to make builds more efficient by output
> comparison and
>    sstate prebuilt reuse in many more cases. Maybe sstate
> equivalence
>    server
> - Completion of migration to new autobuilder
> codebase and
>    infrastructure
> - Out of box experience/layer setup
> tooling
> - Improved binary reproducibility
> 
> Features aren't all we need to plan for. There are other areas that
> need work/help:
> 
> Many other smaller features
> 
>    There are too many for me to list/call out individually but search
>    bugzilla for 2.99 Medium+ items. A good example is adding
>    support for inter-multiconfig dependencies which is a small
>    remaining multiconfig item which would make a big difference to
>    certain workflows.
> 
>    Another harder example is parallelisation of oe-selftest. Its
>    currently the thing which ends up taking the longest in most of our
>    builds, improving its performance would reduce overall testing times.
> 
> OE-Core Recipe maintenance: 840 recipes in OE-Core
>    
>    - General recipe
> updates
>    - Security fixes
>    - Recipe specific bugs/regressions
>    - Adapt
> to new technologies/upstream changes
> 
> General patch review
> 
>    ~5000 commits/year which need review, testing, identifying
>    regressions, merging
> 
> General regressions
> 
>    Regressions tests we have are good but don't catch every race
>    condition or intermittent problem. We end up having to track
>    down several, particularly runtime testing instability
> 
> Bug fixing user issues
> 
>    Users find new use cases and workflows and identify bugs which then
>    need to be addressed
> 
>    For example we can't default to mem-res bitbake as there are known
>   
> issues.
> 
> Maintain the tools
> 
>    We directly maintain tools like bitbake, pseudo, devtool, recipetool
>    opkg, yocto-autobuilder, patchwork+patchtest, wic
> 
> Stable release maintenance
> 
>    People all want stable releases and security fixes but someone has
>    to make these happen.
> 
> 
> Help in any and all of these areas is much appreciated. Also keep in
> mind the things above are just to get people thinking. If there are
> changes you'd like to see, now is your chance to proposal and work on
> them to make them a reality.
> 
> Cheers,
> 
> Richard
> 
> 
> 

Re: 2.6 planning proposals and meeting

[Richard Purdie]

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.

> 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

Re: 2.6 planning proposals and meeting

[Scott Rifenbark]

[-- Attachment #1: Type: text/plain, Size: 3675 bytes --]

On Tue, May 1, 2018 at 7:46 AM, Richard Purdie <
richard.purdie@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@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 4993 bytes --]

Re: 2.6 planning proposals and meeting

[Peter Kjellerstedt]

[-- Attachment #1: Type: text/plain, Size: 2204 bytes --]



From: openembedded-core-bounces@lists.openembedded.org [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of Scott Rifenbark
Sent: den 1 maj 2018 16:56
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] 2.6 planning proposals and meeting

On Tue, May 1, 2018 at 7:46 AM, Richard Purdie <richard.purdie@linuxfoundation.org<mailto:richard.purdie@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/<http://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
Is there any special process to get manual updates accepted? I am asking because I sent an update for the BUILDHISTORY_FEATURES variable to the Yocto mailing list (https://lists.yoctoproject.org/pipermail/yocto/2018-January/039787.html) at the end of January (last pinged a month ago) and it still has not made it into the manual AFAICT and it has not received any feedback.
//Peter


[-- Attachment #2: Type: text/html, Size: 7068 bytes --]

Re: 2.6 planning proposals and meeting

[Scott Rifenbark]

[-- Attachment #1: Type: text/plain, Size: 2796 bytes --]

Peter,

Sorry I missed this.  My fault for not monitoring that mail list close
enough.  I will take a look at this and get back to you.

Regarding special processes for getting doc changes done.  Any form of
contact with me "should" work.  What you did should have been caught.  An
email directly to me will work.  A chat over #yocto over IRC will work.

Thanks,
Scott

On Thu, May 3, 2018, 1:29 AM Peter Kjellerstedt <peter.kjellerstedt@axis.com>
wrote:

>
>
>
>
> *From:* openembedded-core-bounces@lists.openembedded.org [mailto:
> openembedded-core-bounces@lists.openembedded.org] *On Behalf Of *Scott
> Rifenbark
> *Sent:* den 1 maj 2018 16:56
> *To:* Richard Purdie <richard.purdie@linuxfoundation.org>
> *Cc:* openembedded-core <openembedded-core@lists.openembedded.org>
> *Subject:* Re: [OE-core] 2.6 planning proposals and meeting
>
>
>
> On Tue, May 1, 2018 at 7:46 AM, Richard Purdie <
> richard.purdie@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
>
> Is there any special process to get manual updates accepted? I am asking
> because I sent an update for the BUILDHISTORY_FEATURES variable to the
> Yocto mailing list (
> https://lists.yoctoproject.org/pipermail/yocto/2018-January/039787.html)
> at the end of January (last pinged a month ago) and it still has not made
> it into the manual AFAICT and it has not received any feedback.
>
> //Peter
>
>
>

[-- Attachment #2: Type: text/html, Size: 6336 bytes --]

Re: 2.6 planning proposals and meeting

[Scott Rifenbark]

[-- Attachment #1: Type: text/plain, Size: 2875 bytes --]

Hi Peter,

Thanks for the patch.  I have applied it to the 2.5 version of the Yocto
Project Reference Manual (see
https://yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-BUILDHISTORY_FEATURES).
You can also see
https://yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-BUILDHISTORY_FEATURES
for the commit in the yocto-docs repository.

Please look it over as I did a bit of modification for manual purposes.

Regards,
Scott

On Thu, May 3, 2018 at 12:29 AM, Peter Kjellerstedt <
peter.kjellerstedt@axis.com> wrote:

>
>
>
>
> *From:* openembedded-core-bounces@lists.openembedded.org [mailto:
> openembedded-core-bounces@lists.openembedded.org] *On Behalf Of *Scott
> Rifenbark
> *Sent:* den 1 maj 2018 16:56
> *To:* Richard Purdie <richard.purdie@linuxfoundation.org>
> *Cc:* openembedded-core <openembedded-core@lists.openembedded.org>
> *Subject:* Re: [OE-core] 2.6 planning proposals and meeting
>
>
>
> On Tue, May 1, 2018 at 7:46 AM, Richard Purdie <richard.purdie@
> 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
>
> Is there any special process to get manual updates accepted? I am asking
> because I sent an update for the BUILDHISTORY_FEATURES variable to the
> Yocto mailing list (https://lists.yoctoproject.org/pipermail/yocto/2018-
> January/039787.html) at the end of January (last pinged a month ago) and
> it still has not made it into the manual AFAICT and it has not received any
> feedback.
>
> //Peter
>
>
>

[-- Attachment #2: Type: text/html, Size: 6639 bytes --]

Re: [OE-core] 2.6 planning proposals and meeting

[Peter Kjellerstedt]

[-- Attachment #1: Type: text/plain, Size: 3592 bytes --]

Not sure why you reordered the descriptions of the features from image,package,sdk,task to image,task,package,sdk (I added “task” at the end since that kept them sorted alphabetically), but apart from that it looks fine to me.

//Peter

From: Scott Rifenbark [mailto:srifenbark@gmail.com]
Sent: den 3 maj 2018 15:58
To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>; openembedded-core <openembedded-core@lists.openembedded.org>; Yocto discussion list <yocto@yoctoproject.org>
Subject: Re: [OE-core] 2.6 planning proposals and meeting

Hi Peter,
Thanks for the patch.  I have applied it to the 2.5 version of the Yocto Project Reference Manual (see https://yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-BUILDHISTORY_FEATURES).  You can also see https://yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-BUILDHISTORY_FEATURES for the commit in the yocto-docs repository.
Please look it over as I did a bit of modification for manual purposes.
Regards,
Scott

On Thu, May 3, 2018 at 12:29 AM, Peter Kjellerstedt <peter.kjellerstedt@axis.com<mailto:peter.kjellerstedt@axis.com>> wrote:


From: openembedded-core-bounces@lists.openembedded.org<mailto:openembedded-core-bounces@lists.openembedded.org> [mailto:openembedded-core-bounces@lists.openembedded.org<mailto:openembedded-core-bounces@lists.openembedded.org>] On Behalf Of Scott Rifenbark
Sent: den 1 maj 2018 16:56
To: Richard Purdie <richard.purdie@linuxfoundation.org<mailto:richard.purdie@linuxfoundation.org>>
Cc: openembedded-core <openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>>
Subject: Re: [OE-core] 2.6 planning proposals and meeting

On Tue, May 1, 2018 at 7:46 AM, Richard Purdie <richard.purdie@linuxfoundation.org<mailto:richard.purdie@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/<http://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
Is there any special process to get manual updates accepted? I am asking because I sent an update for the BUILDHISTORY_FEATURES variable to the Yocto mailing list (https://lists.yoctoproject.org/pipermail/yocto/2018-January/039787.html) at the end of January (last pinged a month ago) and it still has not made it into the manual AFAICT and it has not received any feedback.
//Peter



[-- Attachment #2: Type: text/html, Size: 11649 bytes --]

Re: [OE-core] 2.6 planning proposals and meeting

[Scott Rifenbark]

[-- Attachment #1: Type: text/plain, Size: 3803 bytes --]

Sorry man... I just stuck the new one in there.  Alphabetical would be
best.  I will fix that.

Thanks,
Scott

On Fri, May 4, 2018 at 9:26 AM, Peter Kjellerstedt <
peter.kjellerstedt@axis.com> wrote:

> Not sure why you reordered the descriptions of the features from
> image,package,sdk,task to image,task,package,sdk (I added “task” at the end
> since that kept them sorted alphabetically), but apart from that it looks
> fine to me.
>
>
>
> //Peter
>
>
>
> *From:* Scott Rifenbark [mailto:srifenbark@gmail.com]
> *Sent:* den 3 maj 2018 15:58
> *To:* Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> *Cc:* Richard Purdie <richard.purdie@linuxfoundation.org>;
> openembedded-core <openembedded-core@lists.openembedded.org>; Yocto
> discussion list <yocto@yoctoproject.org>
>
> *Subject:* Re: [OE-core] 2.6 planning proposals and meeting
>
>
>
> Hi Peter,
>
> Thanks for the patch.  I have applied it to the 2.5 version of the Yocto
> Project Reference Manual (see https://yoctoproject.org/docs/
> 2.5/ref-manual/ref-manual.html#var-BUILDHISTORY_FEATURES).  You can also
> see https://yoctoproject.org/docs/2.5/ref-manual/ref-manual.
> html#var-BUILDHISTORY_FEATURES for the commit in the yocto-docs
> repository.
>
> Please look it over as I did a bit of modification for manual purposes.
>
> Regards,
>
> Scott
>
>
>
> On Thu, May 3, 2018 at 12:29 AM, Peter Kjellerstedt <
> peter.kjellerstedt@axis.com> wrote:
>
>
>
>
>
> *From:* openembedded-core-bounces@lists.openembedded.org [mailto:
> openembedded-core-bounces@lists.openembedded.org] *On Behalf Of *Scott
> Rifenbark
> *Sent:* den 1 maj 2018 16:56
> *To:* Richard Purdie <richard.purdie@linuxfoundation.org>
> *Cc:* openembedded-core <openembedded-core@lists.openembedded.org>
> *Subject:* Re: [OE-core] 2.6 planning proposals and meeting
>
>
>
> On Tue, May 1, 2018 at 7:46 AM, Richard Purdie <richard.purdie@
> 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
>
> Is there any special process to get manual updates accepted? I am asking
> because I sent an update for the BUILDHISTORY_FEATURES variable to the
> Yocto mailing list (https://lists.yoctoproject.org/pipermail/yocto/2018-
> January/039787.html) at the end of January (last pinged a month ago) and
> it still has not made it into the manual AFAICT and it has not received any
> feedback.
>
> //Peter
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 9267 bytes --]

Re: [OE-core] 2.6 planning proposals and meeting

[Scott Rifenbark]

[-- Attachment #1: Type: text/plain, Size: 4176 bytes --]

Peter,

See
https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-BUILDHISTORY_FEATURES
for the re-ordered list.

Thanks,
Scott

On Fri, May 4, 2018 at 9:53 AM, Scott Rifenbark <srifenbark@gmail.com>
wrote:

> Sorry man... I just stuck the new one in there.  Alphabetical would be
> best.  I will fix that.
>
> Thanks,
> Scott
>
> On Fri, May 4, 2018 at 9:26 AM, Peter Kjellerstedt <
> peter.kjellerstedt@axis.com> wrote:
>
>> Not sure why you reordered the descriptions of the features from
>> image,package,sdk,task to image,task,package,sdk (I added “task” at the end
>> since that kept them sorted alphabetically), but apart from that it looks
>> fine to me.
>>
>>
>>
>> //Peter
>>
>>
>>
>> *From:* Scott Rifenbark [mailto:srifenbark@gmail.com]
>> *Sent:* den 3 maj 2018 15:58
>> *To:* Peter Kjellerstedt <peter.kjellerstedt@axis.com>
>> *Cc:* Richard Purdie <richard.purdie@linuxfoundation.org>;
>> openembedded-core <openembedded-core@lists.openembedded.org>; Yocto
>> discussion list <yocto@yoctoproject.org>
>>
>> *Subject:* Re: [OE-core] 2.6 planning proposals and meeting
>>
>>
>>
>> Hi Peter,
>>
>> Thanks for the patch.  I have applied it to the 2.5 version of the Yocto
>> Project Reference Manual (see https://yoctoproject.org/docs/
>> 2.5/ref-manual/ref-manual.html#var-BUILDHISTORY_FEATURES).  You can also
>> see https://yoctoproject.org/docs/2.5/ref-manual/ref-manual.html
>> #var-BUILDHISTORY_FEATURES for the commit in the yocto-docs repository.
>>
>> Please look it over as I did a bit of modification for manual purposes.
>>
>> Regards,
>>
>> Scott
>>
>>
>>
>> On Thu, May 3, 2018 at 12:29 AM, Peter Kjellerstedt <
>> peter.kjellerstedt@axis.com> wrote:
>>
>>
>>
>>
>>
>> *From:* openembedded-core-bounces@lists.openembedded.org [mailto:
>> openembedded-core-bounces@lists.openembedded.org] *On Behalf Of *Scott
>> Rifenbark
>> *Sent:* den 1 maj 2018 16:56
>> *To:* Richard Purdie <richard.purdie@linuxfoundation.org>
>> *Cc:* openembedded-core <openembedded-core@lists.openembedded.org>
>> *Subject:* Re: [OE-core] 2.6 planning proposals and meeting
>>
>>
>>
>> On Tue, May 1, 2018 at 7:46 AM, Richard Purdie <
>> richard.purdie@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
>>
>> Is there any special process to get manual updates accepted? I am asking
>> because I sent an update for the BUILDHISTORY_FEATURES variable to the
>> Yocto mailing list (https://lists.yoctoproject.or
>> g/pipermail/yocto/2018-January/039787.html) at the end of January (last
>> pinged a month ago) and it still has not made it into the manual AFAICT and
>> it has not received any feedback.
>>
>> //Peter
>>
>>
>>
>>
>>
>
>

[-- Attachment #2: Type: text/html, Size: 10039 bytes --]

Re: 2.6 planning proposals and meeting

[Daniel F. Dickinson]

On 2018-05-01 10:55 AM, Scott Rifenbark wrote:
> 
> 
> On Tue, May 1, 2018 at 7:46 AM, Richard Purdie 
> <richard.purdie@linuxfoundation.org 
> <mailto:richard.purdie@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 

Will do (I've afraid I didn't write things down earlier, but will now). 
I also realized I somehow completely missed the path from qs to overview 
and ended up working on things like a (trivial) bsp, a runit-based 
distro (decided it wasn't worth it due to lack of proper dependencies), 
and a different way of doing read-only rootfs (i.e. even on ro media the 
ro rootfs is root and a the initramfs-framework is 'borrowed' to do 
pre-init stuff without sacrificing space for an actual initramfs 
(basically a 'volatiles' like approach gets used for persistent data 
too; only pre-planned persistent data exists in that approach; I'm 
thinking of seeing if I can extend volatiles in systemd so that the 
pre-init part no longer is necessary).

Anyway, the 2.5 manuals have been pretty good so far, the only thing I'd 
missed on this read through is actually in Overview §4.3.1 where I'm not 
clear on the difference in scripts used / path taken when using Poky vs. 
using OE-Core + BitBake + layer's of one's choice.  I'm interested in 
that because I've

a) seen a bit on the ML about Poky being problematic
b) gotten along fine without while working Khem Raj's meta-openwrt repo; 
it's distro-less, which I find interesting; it can generate images but 
is still a buffet of recipes (as much as possible with openwrt 
sub-projects anyway).
c) am interested in doing a Yocto/OE based distro for routing and 
network appliance projects that are intended for more constrained 
hardware, and figure the starting point should be distro-less rather 
than hacking on Poky.

[aside]
I'm actually thinking that the main things I'm interested in from 
Openwrt are the light networking, firewall, and init; but would rather 
see if there is a way to have systemd-minimal that handles those without 
being excessively large (also to evaluate just how much of a real 
difference there is between the the full 
init+networking+dynamic-firewall in terms of size (and/or what the size 
gets you).
[aside]

Regards,

Daniel

> 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/ 
> <http://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@lists.openembedded.org
>     <mailto:Openembedded-core@lists.openembedded.org>
>     http://lists.openembedded.org/mailman/listinfo/openembedded-core
>     <http://lists.openembedded.org/mailman/listinfo/openembedded-core>
> 
>