Building a core-image-base

Building a core-image-base

[Sebastián Bas Kana]

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

Hi,

I'm using Yocto/Poky and I'm trying to build an image for my Gumstix Overo.
I added the meta-gumstix layer and I can build the minimal image. The issue
is with the core-image-base. I get errors regarding the license of the
image recipes, so I used BBMASK to solve that. Then, an issue with netbase
appears, so I added it to BBMASK too. Then I get an error that says:

Nothing RPROVIDES 'fbset' (but
/home/sebastian/poky/meta-ti/recipes-graphics/libgles/
libgles-omap3_4.05.00.03.bb RDEPENDS on or otherwise requires it)

I tried to remove that error but then other failures arise and I just can't
get it to build. Any help will be really appreciated.

Thanks in advance!

Sebastián

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

Re: Building a core-image-base

[Denys Dmytriyenko]

On Tue, Aug 28, 2012 at 06:22:08PM -0400, Sebasti?n Bas Kana wrote:
> Hi,
> 
> I'm using Yocto/Poky and I'm trying to build an image for my Gumstix Overo.
> I added the meta-gumstix layer and I can build the minimal image. The issue
> is with the core-image-base. I get errors regarding the license of the
> image recipes, so I used BBMASK to solve that. Then, an issue with netbase
> appears, so I added it to BBMASK too. Then I get an error that says:
> 
> Nothing RPROVIDES 'fbset' (but
> /home/sebastian/poky/meta-ti/recipes-graphics/libgles/
> libgles-omap3_4.05.00.03.bb RDEPENDS on or otherwise requires it)
> 
> I tried to remove that error but then other failures arise and I just can't
> get it to build. Any help will be really appreciated.
> 
> Thanks in advance!

Apparently, your first email was held for moderation - please subscribe to the 
mailing list in order to post to it.

Your problem is that you are trying to build a raher complete image 
(core-image-base), which pulls lots of dependencies and some of them are from 
additional layers, such as meta-openembedded. For example, here's the reason 
for fbset from libgles-omap3 recipe:

> # The initscript calls fbset, cputype calls devmem2
> RDEPENDS_${PN} += "fbset devmem2"

Both fbset and devmem2 are available from meta-openembedded.

Not sure what was the problem with netbase, as it's quite self contained. Are 
you sure you are using matching branches?

Either way, you may be better off composing your own image recipe, if you 
don't want to enable additional layers.

-- 
Denys

Re: Building a core-image-base

[Tomas Frydrych]

Hi,

On 30/08/12 18:48, Denys Dmytriyenko wrote:
> On Tue, Aug 28, 2012 at 06:22:08PM -0400, Sebasti?n Bas Kana wrote:
>> I'm using Yocto/Poky and I'm trying to build an image for my Gumstix Overo.

Worth noting that meta-ti is not compatible with Yocto in numerous
subtle ways that you will have to work around; for example, in addition
to the things you noted, you might, want to add
'TOOLCHAIN_PATH="${STAGING_BINDIR_TOOLCHAIN}"' to your local.conf, or
some other suitable config location, as various meta-ti packages will
fail to compile without it.


> Not sure what was the problem with netbase, as it's quite self contained. Are 
> you sure you are using matching branches?

The problem is that meta-ti seems to be an endlessly moving target
tracking the master of oe core, while people using Yocto tend to use its
stable releases. meta-ti would really benefit from some formal release
process/schedule, but I guess as long as TI considers it to be a
community project only, this is unlikely to happen.


> Either way, you may be better off composing your own image recipe, if you 
> don't want to enable additional layers.

You don't have much of a choice here; you will need to pick some of
these packages from meta-openembedded into a layer of your own as for
now combining meta-openembedded with Yocto does not work; hopefully this
will be resolved at some point.

Tomas

Re: Building a core-image-base

[Koen Kooi]

Op 30 aug. 2012, om 21:54 heeft Tomas Frydrych <tf+lists.yocto@r-finger.com> het volgende geschreven:
> 
>> Not sure what was the problem with netbase, as it's quite self contained. Are 
>> you sure you are using matching branches?
> 
> The problem is that meta-ti seems to be an endlessly moving target
> tracking the master of oe core, while people using Yocto tend to use its
> stable releases. meta-ti would really benefit from some formal release
> process/schedule,

You mean the 'denzil' branch that tracks denzil is not enough?!?!?!

Re: Building a core-image-base

[Denys Dmytriyenko]

On Thu, Aug 30, 2012 at 08:54:32PM +0100, Tomas Frydrych wrote:
> Hi,
> 
> On 30/08/12 18:48, Denys Dmytriyenko wrote:
> > On Tue, Aug 28, 2012 at 06:22:08PM -0400, Sebasti?n Bas Kana wrote:
> >> I'm using Yocto/Poky and I'm trying to build an image for my Gumstix Overo.
> 
> Worth noting that meta-ti is not compatible with Yocto in numerous
> subtle ways that you will have to work around; for example, in addition
> to the things you noted, you might, want to add
> 'TOOLCHAIN_PATH="${STAGING_BINDIR_TOOLCHAIN}"' to your local.conf, or
> some other suitable config location, as various meta-ti packages will
> fail to compile without it.

Ah, correct, DSP components still use the old TOOLCHAIN_PATH variable that is 
no longer available from oe-core/yocto. Or rather it was never ported to 
oe-core from Classic OE as part of my updated external toolchain framework... 
Most of that still lives in CSL and Linaro recipes, but TOOLCHAIN_PATH got 
lost in the process, I guess. This needs to be fixed once we get to work on 
DSP components again...


> > Not sure what was the problem with netbase, as it's quite self contained. Are 
> > you sure you are using matching branches?
> 
> The problem is that meta-ti seems to be an endlessly moving target
> tracking the master of oe core, while people using Yocto tend to use its
> stable releases. meta-ti would really benefit from some formal release
> process/schedule, but I guess as long as TI considers it to be a
> community project only, this is unlikely to happen.

FYI, there is a "denzil" branch in meta-ti, that corresponds to the same in 
yocto, as well as most of the other layers, including meta-oe...

For our TI SDK products and the new Arago "distribution", we are using said 
"denzil" branch of meta-ti. Other distributions, like Angstrom, use the same 
concept of stable releases based on Yocto Project 1.2 and denzil maintenance 
branches.


> > Either way, you may be better off composing your own image recipe, if you 
> > don't want to enable additional layers.
> 
> You don't have much of a choice here; you will need to pick some of
> these packages from meta-openembedded into a layer of your own as for
> now combining meta-openembedded with Yocto does not work; hopefully this
> will be resolved at some point.

There are some conflicts between them, but I don't think it's correct to say 
they don't work in combination at all...

-- 
Denys

Re: Building a core-image-base

[Tomas Frydrych]

Hi,

On 30/08/12 21:08, Denys Dmytriyenko wrote:
> For our TI SDK products and the new Arago "distribution", we are using said 
> "denzil" branch of meta-ti. 

Having a branch is great, but 'branch' and 'release' are very different
things; branch is a moving target, a release is a fixed point in time
that was tested and approved, and consequently one can have a reasonable
expectation (dare I say, a guarantee?), that it works. The current
denzil release is 7.0.1; there isn't a meta-ti commit that works with
this without jumping through hoops, is there? I think a BSP layer really
needs to have formal releases.

Tomas

Re: Building a core-image-base

[Denys Dmytriyenko]

On Thu, Aug 30, 2012 at 09:56:24PM +0100, Tomas Frydrych wrote:
> Hi,
> 
> On 30/08/12 21:08, Denys Dmytriyenko wrote:
> > For our TI SDK products and the new Arago "distribution", we are using said 
> > "denzil" branch of meta-ti. 
> 
> Having a branch is great, but 'branch' and 'release' are very different
> things; branch is a moving target, a release is a fixed point in time
> that was tested and approved, and consequently one can have a reasonable
> expectation (dare I say, a guarantee?), that it works. The current
> denzil release is 7.0.1; there isn't a meta-ti commit that works with
> this without jumping through hoops, is there? I think a BSP layer really
> needs to have formal releases.

There was a tag applied at the time of the Yocto Project release:

v2012.05-yocto1.2

[BTW, I'm not sure what 7.0.1 is - is it Poky versioning?]

That said, meta-ti was not ready to have a formal release at the time. 
Moreover, testing with Yocto/Poky release was not done - it was meant to be 
used with oe-core and possibly meta-oe and be Yocto-compatible. This may sound 
confusing, but since there's no better terminology available, that would do. 

Hopefully, by the next Yocto Project 1.3 release, we'll do better testing with 
just Yocto/Poky, but right now my focus is on bringing up the new Arago 
distro for our SDKs, while Koen is mostly interested in Angstrom. I do 
understand that we are getting more and more newcomers from a pure Yocto/Poky 
environment and making sure we have a smooth experience for them with meta-ti 
is important, but it will take some time...

-- 
Denys