2.6 planning proposals and meeting
[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
Quoted 32 lines · 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.
Quoted 7 lines
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.
Quoted 10 lines
- 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)
Quoted 8 lines
- 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
Quoted 50 lines
- Out of box experience/layer setup
tooling
- Improved binary reproducibilityFeatures 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 changesGeneral 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
Quoted 7 lines
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
Quoted 17 lines
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
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
Quoted 6 lines · 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?
Quoted 6 lines
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
Quoted 115 lines
[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 reproducibilityFeatures 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 changesGeneral 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
Hi,
Quoted 6 lines · Daniel F. Dickinson
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.
Quoted 5 lines
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.
Quoted 6 lines
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?
Quoted 4 lines
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
Quoted 10 lines · Richard Purdie
Hi,
Quoted 6 lines · Daniel F. Dickinson
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.
Quoted 3 lines
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
Quoted 52 lines
Quoted 6 lines
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.
Quoted 6 lines
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?
Quoted 4 lines
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
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
From: [email protected] [mailto:[email protected]] On Behalf Of Scott Rifenbark
Sent: den 1 maj 2018 16:56
To: Richard Purdie <[email protected]>
Cc: openembedded-core <[email protected]>
Subject: Re: [OE-core] 2.6 planning proposals and meeting
On Tue, May 1, 2018 at 7:46 AM, Richard Purdie <[email protected]<mailto:[email protected]>> wrote:
Hi,
Quoted 6 lines · Daniel F. Dickinson
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
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
Quoted 77 lines · Peter Kjellerstedt
*From:* [email protected] [mailto:
[email protected]] *On Behalf Of *Scott Rifenbark
*Sent:* den 1 maj 2018 16:56
*To:* Richard Purdie <[email protected]> *Cc:* openembedded-core <[email protected]> *Subject:* Re: [OE-core] 2.6 planning proposals and meetingOn Tue, May 1, 2018 at 7:46 AM, Richard Purdie <
[email protected]> wrote:Hi,
Quoted 6 lines · Daniel F. Dickinson
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> isbrief-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_FEATURESvariable 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
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
Quoted 77 lines · Peter Kjellerstedt
*From:* [email protected] [mailto:
[email protected]] *On Behalf Of *Scott Rifenbark
*Sent:* den 1 maj 2018 16:56
*To:* Richard Purdie <[email protected]> *Cc:* openembedded-core <[email protected]> *Subject:* Re: [OE-core] 2.6 planning proposals and meetingOn Tue, May 1, 2018 at 7:46 AM, Richard Purdie <richard.purdie@ linuxfoundation.org> wrote:
Hi,
Quoted 6 lines · Daniel F. Dickinson
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> isbrief-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_FEATURESvariable 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
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:[email protected]]
Sent: den 3 maj 2018 15:58
To: Peter Kjellerstedt <[email protected]>
Cc: Richard Purdie <[email protected]>; openembedded-core <[email protected]>; Yocto discussion list <[email protected]>
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 <[email protected]<mailto:[email protected]>> wrote:
From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Scott Rifenbark
Sent: den 1 maj 2018 16:56
To: Richard Purdie <[email protected]<mailto:[email protected]>>
Cc: openembedded-core <[email protected]<mailto:[email protected]>>
Subject: Re: [OE-core] 2.6 planning proposals and meeting
On Tue, May 1, 2018 at 7:46 AM, Richard Purdie <[email protected]<mailto:[email protected]>> wrote:
Hi,
Quoted 6 lines · Daniel F. Dickinson
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
Sorry man... I just stuck the new one in there. Alphabetical would be best. I will fix that.
Thanks,
Scott
Quoted 121 lines · Peter Kjellerstedt
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:[email protected]] *Sent:* den 3 maj 2018 15:58
*To:* Peter Kjellerstedt <[email protected]> *Cc:* Richard Purdie <[email protected]>; openembedded-core <[email protected]>; Yocto discussion list <[email protected]>*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 < [email protected]> wrote:
*From:* [email protected] [mailto:
[email protected]] *On Behalf Of *Scott Rifenbark
*Sent:* den 1 maj 2018 16:56
*To:* Richard Purdie <[email protected]> *Cc:* openembedded-core <[email protected]> *Subject:* Re: [OE-core] 2.6 planning proposals and meetingOn Tue, May 1, 2018 at 7:46 AM, Richard Purdie <richard.purdie@ linuxfoundation.org> wrote:
Hi,
Quoted 6 lines · Daniel F. Dickinson
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> isbrief-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_FEATURESvariable 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
Peter,
See
https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-BUILDHISTORY_FEATURES
for the re-ordered list.
Thanks,
Scott
Quoted 131 lines · Scott Rifenbark
Sorry man... I just stuck the new one in there. Alphabetical would be best. I will fix that.
Thanks,
ScottQuoted 120 lines · Peter Kjellerstedt
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:[email protected]] *Sent:* den 3 maj 2018 15:58
*To:* Peter Kjellerstedt <[email protected]> *Cc:* Richard Purdie <[email protected]>; openembedded-core <[email protected]>; Yocto discussion list <[email protected]>*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 < [email protected]> wrote:
*From:* [email protected] [mailto:
[email protected]] *On Behalf Of *Scott Rifenbark
*Sent:* den 1 maj 2018 16:56
*To:* Richard Purdie <[email protected]> *Cc:* openembedded-core <[email protected]> *Subject:* Re: [OE-core] 2.6 planning proposals and meetingOn Tue, May 1, 2018 at 7:46 AM, Richard Purdie <
[email protected]> wrote:Hi,
Quoted 6 lines · Daniel F. Dickinson
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> isbrief-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_FEATURESvariable 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
Quoted 14 lines · Scott Rifenbark
On Tue, May 1, 2018 at 7:46 AM, Richard Purdie <[email protected] <mailto:[email protected]>> 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.
Quoted 5 lines
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
Quoted 77 lines
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> isbrief-yoctoprojectqs
bsp-guide
overview-manual
dev-manual
sdk-manual
profile-manual
kernel-dev
ref-manual
toaster-manual
bitbake-user-guideThanks
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 [email protected] <mailto:[email protected]>
http://lists.openembedded.org/mailman/listinfo/openembedded-core
<http://lists.openembedded.org/mailman/listinfo/openembedded-core>