Features in Yocto Project 1.7

Features in Yocto Project 1.7

[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

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

Re: Features in Yocto Project 1.7

[Jonathan Austin]

Hi Richard,

On 24/03/14 16:00, Richard Purdie wrote:
> 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

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
>
> 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
>
>
>

Re: [yocto] Features in Yocto Project 1.7

[Richard Purdie]

On Mon, 2014-03-24 at 16:09 +0000, Jonathan Austin wrote:
> On 24/03/14 16:00, Richard Purdie wrote:
> > 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
> 
> 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

Re: Features in Yocto Project 1.7

[Richard Purdie]

On Mon, 2014-03-24 at 16:09 +0000, Jonathan Austin wrote:
> On 24/03/14 16:00, Richard Purdie wrote:
> > 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
> 
> 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

Re: [yocto] Features in Yocto Project 1.7

I can see this effort as a  basis for re-writing the "Models" chapter of the development manual.

Scott

>-----Original Message-----
>From: yocto-bounces@yoctoproject.org [mailto:yocto-
>bounces@yoctoproject.org] On Behalf Of Richard Purdie
>Sent: Monday, March 24, 2014 9:01 AM
>To: openembedded-core; yocto
>Subject: [yocto] 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
>
>
>
>--
>_______________________________________________
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto

Re: Features in Yocto Project 1.7

[Rifenbark, Scott M]

I can see this effort as a  basis for re-writing the "Models" chapter of the development manual.

Scott

>-----Original Message-----
>From: yocto-bounces@yoctoproject.org [mailto:yocto-
>bounces@yoctoproject.org] On Behalf Of Richard Purdie
>Sent: Monday, March 24, 2014 9:01 AM
>To: openembedded-core; yocto
>Subject: [yocto] 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
>
>
>
>--
>_______________________________________________
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto

--conf Was: Features in Yocto Project 1.7

[Trevor Woerner]

On 03/24/14 12:00, Richard Purdie wrote:
> 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?

--conf Was: [OE-core] Features in Yocto Project 1.7

[Trevor Woerner]

On 03/24/14 12:00, Richard Purdie wrote:
> 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

[Martin Jansa]

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

On Mon, Mar 24, 2014 at 08:11:20PM -0400, Trevor Woerner wrote:
> On 03/24/14 12:00, Richard Purdie wrote:
> > 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?

Can you show some example of config you need to have wor wayland and
cannot have for core-image-minimal?

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [OE-core] --conf Was: Features in Yocto Project 1.7

[Martin Jansa]

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

On Mon, Mar 24, 2014 at 08:11:20PM -0400, Trevor Woerner wrote:
> On 03/24/14 12:00, Richard Purdie wrote:
> > 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?

Can you show some example of config you need to have wor wayland and
cannot have for core-image-minimal?

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: --conf Was: Features in Yocto Project 1.7

[Trevor Woerner]

On 03/25/14 01:50, Martin Jansa wrote:
> 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: [OE-core] --conf Was: Features in Yocto Project 1.7

[Trevor Woerner]

On 03/25/14 01:50, Martin Jansa wrote:
> 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

[Otavio Salvador]

On Wed, Mar 26, 2014 at 11:33 AM, Trevor Woerner
<trevor.woerner@linaro.org> wrote:
> On 03/25/14 01:50, Martin Jansa wrote:
>> Can you show some example of config you need to have wor wayland and
>> cannot have for core-image-minimal?
>
...
> 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.

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.

-- 
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: [OE-core] --conf Was: Features in Yocto Project 1.7

[Otavio Salvador]

On Wed, Mar 26, 2014 at 11:33 AM, Trevor Woerner
<trevor.woerner@linaro.org> wrote:
> On 03/25/14 01:50, Martin Jansa wrote:
>> Can you show some example of config you need to have wor wayland and
>> cannot have for core-image-minimal?
>
...
> 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.

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.

-- 
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

[Nicolas Dechesne]

On Wed, Mar 26, 2014 at 3:38 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
>> 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.
>
> 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.

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: [OE-core] --conf Was: Features in Yocto Project 1.7

[Nicolas Dechesne]

On Wed, Mar 26, 2014 at 3:38 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
>> 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.
>
> 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.

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

[Trevor Woerner]

Excellent information! Thanks for all the workflow examples, this is great.

Re: [OE-core] --conf Was: Features in Yocto Project 1.7

[Trevor Woerner]

Excellent information! Thanks for all the workflow examples, this is great.

Re: --conf Was: Features in Yocto Project 1.7

[Martin Jansa]

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

On Wed, Mar 26, 2014 at 10:33:04AM -0400, Trevor Woerner wrote:
> On 03/25/14 01:50, Martin Jansa wrote:
> > 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.

> 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).

> 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.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [OE-core] --conf Was: Features in Yocto Project 1.7

[Martin Jansa]

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

On Wed, Mar 26, 2014 at 10:33:04AM -0400, Trevor Woerner wrote:
> On 03/25/14 01:50, Martin Jansa wrote:
> > 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.

> 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).

> 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.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Features in Yocto Project 1.7

[Otavio Salvador]

On Mon, Mar 24, 2014 at 1:00 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> 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:

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.

-- 
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: [OE-core] Features in Yocto Project 1.7

[Otavio Salvador]

On Mon, Mar 24, 2014 at 1:00 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> 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:

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.

-- 
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: Features in Yocto Project 1.7

[Mark Hatle]

On 3/25/14, 7:22 AM, Otavio Salvador wrote:
> On Mon, Mar 24, 2014 at 1:00 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> 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:
>
> 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

Re: Features in Yocto Project 1.7

[David Nyström]

On 2014-03-24 17:00, Richard Purdie wrote:
> 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

+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


> * 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
>
>
>

Re: [OE-core] Features in Yocto Project 1.7

[David Nyström]

On 2014-03-24 17:00, Richard Purdie wrote:
> 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

+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


> * 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
>
>
>

Re: Features in Yocto Project 1.7

[Mark Hatle]

On 3/25/14, 9:31 AM, David Nyström wrote:
> On 2014-03-24 17:00, Richard Purdie wrote:
>> 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
>
> +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

> Br,
> David
>
>
>> * 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
>>
>>
>>
>

Re: [yocto] Features in Yocto Project 1.7

[Philip Balister]

On 03/25/2014 07:31 AM, David Nyström wrote:
> On 2014-03-24 17:00, Richard Purdie wrote:
>> 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
> 
> +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


> 
> Br,
> David
> 
> 
>> * 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
>>
>>
>>
> 

Re: [OE-core] Features in Yocto Project 1.7

[Philip Balister]

On 03/25/2014 07:31 AM, David Nyström wrote:
> On 2014-03-24 17:00, Richard Purdie wrote:
>> 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
> 
> +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


> 
> Br,
> David
> 
> 
>> * 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
>>
>>
>>
> 

Re: Features in Yocto Project 1.7

[David Nyström]

On 2014-03-25 15:31, David Nyström wrote:
> On 2014-03-24 17:00, Richard Purdie wrote:
>> 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
>
> +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

> Br,
> David
>
>
>> * 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
>>
>>
>>
>

Re: [OE-core] Features in Yocto Project 1.7

[David Nyström]

On 2014-03-25 15:31, David Nyström wrote:
> On 2014-03-24 17:00, Richard Purdie wrote:
>> 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
>
> +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

> Br,
> David
>
>
>> * 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
>>
>>
>>
>

Re: Features in Yocto Project 1.7

[Otavio Salvador]

Hello David,

On Thu, Mar 27, 2014 at 7:47 AM, David Nyström <david.nystrom@enea.com> wrote:
> On 2014-03-25 15:31, David Nyström wrote:
>>
>> On 2014-03-24 17:00, Richard Purdie wrote:
>>>
>>> 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
>>
>>
>> +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.

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?

> 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...

-- 
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: [OE-core] Features in Yocto Project 1.7

[Otavio Salvador]

Hello David,

On Thu, Mar 27, 2014 at 7:47 AM, David Nyström <david.nystrom@enea.com> wrote:
> On 2014-03-25 15:31, David Nyström wrote:
>>
>> On 2014-03-24 17:00, Richard Purdie wrote:
>>>
>>> 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
>>
>>
>> +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.

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?

> 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...

-- 
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: Features in Yocto Project 1.7

[David Nystrom]

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

On 28 Mar 2014 16:24, "Otavio Salvador" <otavio@ossystems.com.br> wrote:
>
> Hello David,
>
> On Thu, Mar 27, 2014 at 7:47 AM, David Nyström <david.nystrom@enea.com>
wrote:
> > On 2014-03-25 15:31, David Nyström wrote:
> >>
> >> On 2014-03-24 17:00, Richard Purdie wrote:
> >>>
> >>> 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
> >>
> >>
> >> +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.
>
> 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?

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

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

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

Re: [OE-core] Features in Yocto Project 1.7

[David Nystrom]

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

On 28 Mar 2014 16:24, "Otavio Salvador" <otavio@ossystems.com.br> wrote:
>
> Hello David,
>
> On Thu, Mar 27, 2014 at 7:47 AM, David Nyström <david.nystrom@enea.com>
wrote:
> > On 2014-03-25 15:31, David Nyström wrote:
> >>
> >> On 2014-03-24 17:00, Richard Purdie wrote:
> >>>
> >>> 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
> >>
> >>
> >> +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.
>
> 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?

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

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

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