Features in Yocto Project 1.7
As development on 1.6 finishes up, its time to think about what we should be doing in the 1.7 cycle.
I think from my perspective, in 1.7 I'd like to see us looking at "Developer Workflow". Its a generic topic which I think covered multiple areas (in no particular order):
* the ADT/SDK and how it intergrates into the rest of the system
* toaster
* python devshell
* exteralsrc.bbclass
* memory resident bitbake
* how a standalone app developer might build an image
* locked sstate
and probably more I'm forgetting.
If anyone does have things they plan to work on, or ideas for things that should be worked on, please do file enhancement requests in the bugzilla:
https://bugzilla.yoctoproject.org/
Cheers,
Richard
Hi Richard,
Quoted 7 lines · Richard Purdie
As development on 1.6 finishes up, its time to think about what we should be doing in the 1.7 cycle.
I think from my perspective, in 1.7 I'd like to see us looking at "Developer Workflow". Its a generic topic which I think covered multiple areas (in no particular order):
Quoted 7 lines
* the ADT/SDK and how it intergrates into the rest of the system
* toaster
* python devshell
* exteralsrc.bbclass
* memory resident bitbake
* how a standalone app developer might build an image
* locked sstate
Is there a wiki page that collates the enhancement requests that have lead to this list? For example, if I want to discuss the issue of "how a standalone app developer might build an image" (I do!) then where should I go? On the list? Bugzilla for 'standalone image' doesn't appear to have an item for this (unless I'm pounding my keypad incorrectly for Bugzilla).
Cheers,
Jonny
Quoted 15 lines
and probably more I'm forgetting.
If anyone does have things they plan to work on, or ideas for things that should be worked on, please do file enhancement requests in the bugzilla:
https://bugzilla.yoctoproject.org/
Cheers,
Richard
Quoted 16 lines · Jonathan Austin
Quoted 7 lines · Richard Purdie
As development on 1.6 finishes up, its time to think about what we should be doing in the 1.7 cycle.
I think from my perspective, in 1.7 I'd like to see us looking at "Developer Workflow". Its a generic topic which I think covered multiple areas (in no particular order):
Quoted 7 lines
* the ADT/SDK and how it intergrates into the rest of the system
* toaster
* python devshell
* exteralsrc.bbclass
* memory resident bitbake
* how a standalone app developer might build an image
* locked sstate
Quoted 6 lines
Is there a wiki page that collates the enhancement requests that have lead to this list? For example, if I want to discuss the issue of "how a standalone app developer might build an image" (I do!) then where should I go? On the list? Bugzilla for 'standalone image' doesn't appear to have an item for this (unless I'm pounding my keypad incorrectly for Bugzilla).
Whilst this is a key area I'd like to see worked on in 1.7 and I do have ideas related to it, they're in various states of development. Some have bugzilla entries and good information, others are much less well formulated and don't have bugzilla entries yet.
So no wiki page exists and the "standalone app developer might build an image" item isn't well defined as yet. There have been some developments which lead into it like wic and the locked sstate work though.
Here on the mailing list is probably as good a place as any for the discussion, which can then be turned into something in the bugzilla.
Cheers,
Richard
I can see this effort as a basis for re-writing the "Models" chapter of the development manual.
Scott
Quoted 41 lines
-----Original Message-----
From: [email protected] [mailto:yocto- [email protected]] On Behalf Of Richard Purdie
Sent: Monday, March 24, 2014 9:01 AM
To: openembedded-core; yocto
Subject: [yocto] Features in Yocto Project 1.7As development on 1.6 finishes up, its time to think about what we should be doing in the 1.7 cycle.
I think from my perspective, in 1.7 I'd like to see us looking at "Developer Workflow". Its a generic topic which I think covered multiple areas (in no particular order):
* the ADT/SDK and how it intergrates into the rest of the system
* toaster
* python devshell
* exteralsrc.bbclass
* memory resident bitbake
* how a standalone app developer might build an image
* locked sstateand probably more I'm forgetting.
If anyone does have things they plan to work on, or ideas for things that should be worked on, please do file enhancement requests in the bugzilla:
https://bugzilla.yoctoproject.org/
Cheers,
Richard
--
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
--conf Was: Features in Yocto Project 1.7
In reply to Richard PurdieQuoted 2 lines · Richard Purdie
I think from my perspective, in 1.7 I'd like to see us looking at "Developer Workflow".
Maybe I'm using things incorrectly :-)
But I often find that I'm switching between building different images. For example, one moment I might be building core-image-minimal (CIM), then later I'll want to build a GUI image with Wayland.
Switching between CIM and the GUI image requires changes to both conf/local.conf and conf/bblayers.conf. I will either have two separate sets of files and symlink between them, or I'll need to edit them by hand to comment/uncomment out various blocks. I often get this wrong and will need to restart a couple times before the build can hope to complete successfully.
If I could wish for one workflow change, it would be the ability to switch between various build configurations with the minimum of fuss:
- maybe the layer information could be contained within the configuration file, then on the bitbake cmdline I could just say "bitbake --conf wayland" or "bitbake --conf mycim" and it would know to find and use conf/wayland.conf or conf/mycim.conf?
- maybe the local.conf could be renamed wayland.conf and the bblayers.conf could be renamed wayland.bblayers then I could type "bitbake --conf wayland" and it would know to look for wayland.conf and wayland.bblayers?
Does this sort of workflow make sense to others? Or have people noticed this and solved it in some clever way?
Re: --conf Was: Features in Yocto Project 1.7
Quoted 28 lines · Trevor Woerner
Quoted 2 lines · Richard Purdie
I think from my perspective, in 1.7 I'd like to see us looking at "Developer Workflow".
Maybe I'm using things incorrectly :-)
But I often find that I'm switching between building different images. For example, one moment I might be building core-image-minimal (CIM), then later I'll want to build a GUI image with Wayland.
Switching between CIM and the GUI image requires changes to both
conf/local.confandconf/bblayers.conf. I will either have two separate sets of files and symlink between them, or I'll need to edit them by hand to comment/uncomment out various blocks. I often get this wrong and will need to restart a couple times before the build can hope to complete successfully.If I could wish for one workflow change, it would be the ability to switch between various build configurations with the minimum of fuss:
- maybe the layer information could be contained within the configuration file, then on the bitbake cmdline I could just say "bitbake --conf wayland" or "bitbake --conf mycim" and it would know to find and useconf/wayland.conforconf/mycim.conf?
- maybe the local.conf could be renamed wayland.conf and the bblayers.conf could be renamed wayland.bblayers then I could type "bitbake --conf wayland" and it would know to look for wayland.conf and wayland.bblayers?
Quoted 2 lines
Does this sort of workflow make sense to others? Or have people noticed this and solved it in some clever way?
Can you show some example of config you need to have wor wayland and cannot have for core-image-minimal?
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Re: --conf Was: Features in Yocto Project 1.7
Quoted 2 lines · Martin Jansa
Can you show some example of config you need to have wor wayland and cannot have for core-image-minimal?
Okay, good point. I should have thought harder to come up with a better example :-) It's funny, actually, that you're the one pressing me on this, I first encountered this issue and started thinking about it while trying to reproduce your "State of bitbake world" tests :-)
Let's say you're a board maintainer; some people want to run gstreamer, some people want to try out systemd, some want to run wayland. Each of these requires tweaks to a conf/local.conf, no? I'm constantly changing my set of IMAGE_INSTALL_append's, fiddling with preferred versions, and distro features.
If I'm just doing a one-off build then sure, adjust conf/local.conf manually. But if I'm perpetually rotating between a bunch of tests as repositories are modified, it would be easier to just specify which configuration I want from the bitbake cmdline.
As I mentioned, maybe I'm doing things wrong? Maybe others have separate build locations, or maybe others define their own images which incorporate these adjustments? But I'd be quite surprised to find I'm the only one having to edit conf/local.conf to comment/un-comment blocks before every build.
As a concrete example, currently I'm flipping between dora and master builds. For some reason I can't seem to reuse the same TMPDIR between them. So every time I "repo init -b <newbranch>" I then also have to edit conf/local.conf before bitbaking.
Re: --conf Was: Features in Yocto Project 1.7
Quoted 4 lines · Trevor Woerner
Quoted 2 lines · Martin Jansa
Can you show some example of config you need to have wor wayland and cannot have for core-image-minimal?
...
Quoted 4 lines
As a concrete example, currently I'm flipping between dora and master builds. For some reason I can't seem to reuse the same TMPDIR between them. So every time I "repo init -b <newbranch>" I then also have to edit
conf/local.confbefore bitbaking.
Use separated build directories for this, so you don't need to mangle conf/local.conf every time.
Personally I have different trees for Dora and Master and inside it I have several build directories when working in this kind of test (different distro features and like) and this is easy to maintain. For auto builder, we cooked a script to abstract the configuration in command line options so we can easily extend it and get it used in several build jobs.
Signature · 3 lines
Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
Re: --conf Was: Features in Yocto Project 1.7
Quoted 8 lines · Otavio Salvador
Quoted 4 lines
As a concrete example, currently I'm flipping between dora and master builds. For some reason I can't seem to reuse the same TMPDIR between them. So every time I "repo init -b <newbranch>" I then also have to edit
conf/local.confbefore bitbaking.Use separated build directories for this, so you don't need to mangle
conf/local.confevery time.
Quoted 6 lines
Personally I have different trees for Dora and Master and inside it I have several build directories when working in this kind of test (different distro features and like) and this is easy to maintain. For auto builder, we cooked a script to abstract the configuration in command line options so we can easily extend it and get it used in several build jobs.
I do that too. build folders are 'cheap' assuming good use of sstate and rm_work. my typical setup is:
- one workspace for each OE release branch (trees checkout)
- one <build> folder for each combination of <distro>-<machine>
- one shared downloads folder for *all* builds across all workspace
- one shared ssate for each workspace . i am not sharing sstate across OE releases, mostly because sstate-cache-management would always delete the wrong stuff otherwise.
Re: --conf Was: Features in Yocto Project 1.7
Excellent information! Thanks for all the workflow examples, this is great.
Re: --conf Was: Features in Yocto Project 1.7
In reply to Trevor WoernerQuoted 8 lines · Trevor Woerner
Quoted 2 lines · Martin Jansa
Can you show some example of config you need to have wor wayland and cannot have for core-image-minimal?
Okay, good point. I should have thought harder to come up with a better example :-) It's funny, actually, that you're the one pressing me on this, I first encountered this issue and started thinking about it while trying to reproduce your "State of bitbake world" tests :-)
:) I see, but the point is that I'm not changing those entries based on what I'm building. It's "customization" which would normally be included in distro config based on what distro supports, but in this case I'm using nodistro and want to build test more than what's "supported" in nodistro.
Quoted 5 lines
Let's say you're a board maintainer; some people want to run gstreamer, some people want to try out systemd, some want to run wayland. Each of these requires tweaks to a
conf/local.conf, no? I'm constantly changing my set of IMAGE_INSTALL_append's, fiddling with preferred versions, and distro features.
Yes, people often need to tweak local.conf, but my point is that they shouldn't tweak it based on what they are going to build.
e.g. if I decide to build qtbase with icu enabled, then I should use the same qtbase in core-image-minimal and wayland-image, otherwise I'll see a lot of rebuilds and not-so-good sstate reuse (especially if you often use sstate-cache-management which will remove your 2nd qt* variants between the builds).
Quoted 15 lines
If I'm just doing a one-off build then sure, adjust
conf/local.confmanually. But if I'm perpetually rotating between a bunch of tests as repositories are modified, it would be easier to just specify which configuration I want from the bitbake cmdline.As I mentioned, maybe I'm doing things wrong? Maybe others have separate build locations, or maybe others define their own images which incorporate these adjustments? But I'd be quite surprised to find I'm the only one having to edit
conf/local.confto comment/un-comment blocks before every build.As a concrete example, currently I'm flipping between dora and master builds. For some reason I can't seem to reuse the same TMPDIR between them. So every time I "repo init -b <newbranch>" I then also have to edit
conf/local.confbefore bitbaking.
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Quoted 15 lines · Richard Purdie
As development on 1.6 finishes up, its time to think about what we should be doing in the 1.7 cycle.
I think from my perspective, in 1.7 I'd like to see us looking at "Developer Workflow". Its a generic topic which I think covered multiple areas (in no particular order):
* the ADT/SDK and how it intergrates into the rest of the system
* toaster
* python devshell
* exteralsrc.bbclass
* memory resident bitbake
* how a standalone app developer might build an image
* locked sstate
Quoted 5 lines
and probably more I'm forgetting.
If anyone does have things they plan to work on, or ideas for things that should be worked on, please do file enhancement requests in the bugzilla:
I'd like to cover
http://lists.openembedded.org/pipermail/openembedded-core/2014-February/089287.html
but this got no replies. So I am unsure people think it is an important thing or not.
Signature · 3 lines
Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
Quoted 19 lines · Otavio Salvador
Quoted 17 lines · Richard Purdie
As development on 1.6 finishes up, its time to think about what we should be doing in the 1.7 cycle.
I think from my perspective, in 1.7 I'd like to see us looking at "Developer Workflow". Its a generic topic which I think covered multiple areas (in no particular order):
* the ADT/SDK and how it intergrates into the rest of the system
* toaster
* python devshell
* exteralsrc.bbclass
* memory resident bitbake
* how a standalone app developer might build an image
* locked sstateand probably more I'm forgetting.
Quoted 9 lines
Quoted 3 lines
If anyone does have things they plan to work on, or ideas for things that should be worked on, please do file enhancement requests in the bugzilla:
I'd like to cover
http://lists.openembedded.org/pipermail/openembedded-core/2014-February/089287.html
but this got no replies. So I am unsure people think it is an important thing or not.
I think what you have is something we need to strongly consider to YP 1.7. I advantages to supporting both the "toolchain" and populate_sdk methods for the SDK. But in the end, I think the populate_sdk method should be the default for normal users. And the 'toolchain' approach used for people who are producing incredibly targeted application SDKs.
I don't have much to add to the QT/QTe side, simply because I'm not familiar with all of the issues, but in general this should help make it easier for users to create SDKs.. hopefully use them with the eclipse environment(s) and produce working software.
I like the ability also to enhance the environment files with plug-ins via a sourced '.d' directory. This would resolve a lot of the hacky patches I've had to make in the past.
--Mark
Quoted 7 lines · Richard Purdie
As development on 1.6 finishes up, its time to think about what we should be doing in the 1.7 cycle.
I think from my perspective, in 1.7 I'd like to see us looking at "Developer Workflow". Its a generic topic which I think covered multiple areas (in no particular order):
Quoted 7 lines
* the ADT/SDK and how it intergrates into the rest of the system
* toaster
* python devshell
* exteralsrc.bbclass
* memory resident bitbake
* how a standalone app developer might build an image
+1
My wishlist:
1. Assembly of an image from a package repository using the SDK.
2. Ability to easily package multiple kernel flavours(builds with different kernel configs) with linux related bbclass:es.
Br,
David
Quoted 16 lines
* locked sstate
and probably more I'm forgetting.
If anyone does have things they plan to work on, or ideas for things that should be worked on, please do file enhancement requests in the bugzilla:
https://bugzilla.yoctoproject.org/
Cheers,
Richard
Quoted 16 lines · David Nyström
Quoted 7 lines · Richard Purdie
As development on 1.6 finishes up, its time to think about what we should be doing in the 1.7 cycle.
I think from my perspective, in 1.7 I'd like to see us looking at "Developer Workflow". Its a generic topic which I think covered multiple areas (in no particular order):
Quoted 7 lines
* the ADT/SDK and how it intergrates into the rest of the system
* toaster
* python devshell
* exteralsrc.bbclass
* memory resident bitbake
* how a standalone app developer might build an image
Quoted 6 lines
+1
My wishlist:1. Assembly of an image from a package repository using the SDK.
2. Ability to easily package multiple kernel flavours(builds with different kernel configs) with linux related bbclass:es.
I agree.. generating images, SDKs or other consumables from package feeds is high on my wish list as well.
I think we've finally gotten to the point where WIC, rootfs generation and other pieces are in place to help do an implementation of this.
--Mark
Quoted 21 lines
Br,
DavidQuoted 16 lines
* locked sstate
and probably more I'm forgetting.
If anyone does have things they plan to work on, or ideas for things that should be worked on, please do file enhancement requests in the bugzilla:
https://bugzilla.yoctoproject.org/
Cheers,
Richard
Quoted 16 lines · David Nyström
Quoted 7 lines · Richard Purdie
As development on 1.6 finishes up, its time to think about what we should be doing in the 1.7 cycle.
I think from my perspective, in 1.7 I'd like to see us looking at "Developer Workflow". Its a generic topic which I think covered multiple areas (in no particular order):
Quoted 7 lines
* the ADT/SDK and how it intergrates into the rest of the system
* toaster
* python devshell
* exteralsrc.bbclass
* memory resident bitbake
* how a standalone app developer might build an image
Quoted 6 lines
+1
My wishlist:1. Assembly of an image from a package repository using the SDK.
2. Ability to easily package multiple kernel flavours(builds with different kernel configs) with linux related bbclass:es.
Can we update the OEDAM web page with some of these ideas:
http://openembedded.org/wiki/OEDAM
Discussion should continue on the list, but we have an agenda item to talk about the next release and this would be a good time to review the ideas raised in the this thread. I put in a placeholder with the link to Otavio's email. (And I really like his thoughts)
Philip
Quoted 22 lines
Br,
DavidQuoted 16 lines
* locked sstate
and probably more I'm forgetting.
If anyone does have things they plan to work on, or ideas for things that should be worked on, please do file enhancement requests in the bugzilla:
https://bugzilla.yoctoproject.org/
Cheers,
Richard
Quoted 16 lines · David Nyström
Quoted 7 lines · Richard Purdie
As development on 1.6 finishes up, its time to think about what we should be doing in the 1.7 cycle.
I think from my perspective, in 1.7 I'd like to see us looking at "Developer Workflow". Its a generic topic which I think covered multiple areas (in no particular order):
Quoted 7 lines
* the ADT/SDK and how it intergrates into the rest of the system
* toaster
* python devshell
* exteralsrc.bbclass
* memory resident bitbake
* how a standalone app developer might build an image
Quoted 6 lines
+1
My wishlist:1. Assembly of an image from a package repository using the SDK.
2. Ability to easily package multiple kernel flavours(builds with different kernel configs) with linux related bbclass:es.
3. layer based repository splitting.
--
When having multiple users of a base repository. Ease management of customized repos, by having he ability to mark layers as "split layers", this would yield a separate repo per "split layer", which would contain packages modified/created by this layer.
Said packages would also be built for the base repo, but without split-layer modifications.
A customized distro would use a compound of the base repo + split repo, where the split repo would have higher priority.
I guess this could mean one deploy directory per split-layer.
Br,
David
Quoted 21 lines
Br,
DavidQuoted 16 lines
* locked sstate
and probably more I'm forgetting.
If anyone does have things they plan to work on, or ideas for things that should be worked on, please do file enhancement requests in the bugzilla:
https://bugzilla.yoctoproject.org/
Cheers,
Richard
Hello David,
Quoted 29 lines · David Nyström
Quoted 20 lines · David Nyström
Quoted 8 lines · Richard Purdie
As development on 1.6 finishes up, its time to think about what we should be doing in the 1.7 cycle.
I think from my perspective, in 1.7 I'd like to see us looking at "Developer Workflow". Its a generic topic which I think covered multiple areas (in no particular order):
Quoted 8 lines
* the ADT/SDK and how it intergrates into the rest of the system
* toaster
* python devshell
* exteralsrc.bbclass
* memory resident bitbake
* how a standalone app developer might build an imageQuoted 6 lines
+1
My wishlist:1. Assembly of an image from a package repository using the SDK.
2. Ability to easily package multiple kernel flavours(builds with different kernel configs) with linux related bbclass:es.
Quoted 6 lines
3. layer based repository splitting.
--
When having multiple users of a base repository. Ease management of customized repos, by having he ability to mark layers as "split layers", this would yield a separate repo per "split layer", which would contain packages modified/created by this layer.
So you mean:
* base package feed
* meta-qt5 package feed
and in case meta-qt5 adds a bbappend, in a existing recipe, what will be the behavior?
Quoted 7 lines
Said packages would also be built for the base repo, but without split-layer modifications.
A customized distro would use a compound of the base repo + split repo, where the split repo would have higher priority.
I guess this could mean one deploy directory per split-layer.
This part is easy as all package managers we use has support for it (I think) so it is a matter of proper generating those and add a method to include it in the image, the first part is the most complicated one I think...
Signature · 3 lines
Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
Quoted 4 lines · Otavio Salvador
Hello David,
On Thu, Mar 27, 2014 at 7:47 AM, David Nyström <[email protected]>
Quoted 9 lines · wrote:
Quoted 9 lines · David Nyström
Quoted 8 lines · Richard Purdie
Quoted 6 lines
As development on 1.6 finishes up, its time to think about what we should be doing in the 1.7 cycle.
I think from my perspective, in 1.7 I'd like to see us looking at "Developer Workflow". Its a generic topic which I think covered
multiple
Quoted 27 lines
Quoted 20 lines
Quoted 12 lines
Quoted 10 lines
areas (in no particular order):
* the ADT/SDK and how it intergrates into the rest of the system
* toaster
* python devshell
* exteralsrc.bbclass
* memory resident bitbake
* how a standalone app developer might build an imageQuoted 6 lines
+1
My wishlist:1. Assembly of an image from a package repository using the SDK.
2. Ability to easily package multiple kernel flavours(builds with different kernel configs) with linux related bbclass:es.Quoted 6 lines
3. layer based repository splitting.
--
When having multiple users of a base repository. Ease management of customized repos, by having he ability to mark layers as "split layers", this would yield a separate repo per "split layer", which would contain packages modified/created by this layer.
Quoted 7 lines
So you mean:
* base package feed
* meta-qt5 package feedand in case meta-qt5 adds a bbappend, in a existing recipe, what will be the behavior?
If bbappending the bash recipe, f.ex.
bash packages will be generated without meta-qt5 mods in base repo, and subsequently generated with qt5 mods in the meta-qt5 repo.
//DD
Quoted 2 lines
Quoted 2 lines
Said packages would also be built for the base repo, but without
split-layer
Quoted 21 lines
Quoted 6 lines
modifications.
A customized distro would use a compound of the base repo + split repo, where the split repo would have higher priority.
I guess this could mean one deploy directory per split-layer.
This part is easy as all package managers we use has support for it (I think) so it is a matter of proper generating those and add a method to include it in the image, the first part is the most complicated one I think...
--
Otavio SalvadorO.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core