[yocto] Query about how Yocto handles the bbclass file when it exists in multi-layers
If one bbclass exists in multi-layers, which one will Yocto pick up? It seems BBFILE_PRIORITY doesn't impact bbclass file. Best Regards, Zhenhua ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Query about how Yocto handles the bbclass file when it exists in multi-layers
On Thursday 29 December 2011 09:37:07 Luo Zhenhua-B19537 wrote: > If one bbclass exists in multi-layers, which one will Yocto pick up? It > seems BBFILE_PRIORITY doesn't impact bbclass file. I believe for bbclass files it's the order in which the layers are listed in your bblayers.conf. We could fix this, however I'm not sure we should be encouraging duplication of class files - people should ideally be getting their functionality into the OE- Core classes and not just overlaying their own version of the class. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Query about how Yocto handles the bbclass file when it exists in multi-layers
> -Original Message- > From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] > Sent: Thursday, December 29, 2011 5:41 PM > > > If one bbclass exists in multi-layers, which one will Yocto pick up? > > It seems BBFILE_PRIORITY doesn't impact bbclass file. > > I believe for bbclass files it's the order in which the layers are listed in > your bblayers.conf. > > We could fix this, [Luo Zhenhua-B19537] Thanks. the function is useful > however I'm not sure we should be encouraging duplication of > class files - people should ideally be getting their functionality into the > OE- > Core classes and not just overlaying their own version of the class. [Luo Zhenhua-B19537] Agree. Best Regards, Zhenhua ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to require image recipe from another layer?
On Thu, Dec 29, 2011 at 11:14 AM, autif khan wrote: > Can you please help me with setting up my recipes so that all the > hello world apps are included when I use the following recipe. > > require recipes-sato/images/core-image-sato.bb > IMAGE_FEATURES += "helloworld" > > I am guessing that I would have to tell the hw1 recipe that it is a > helloworld feature. How do I go about doing this? commit f9f4416a8cfbd37c7d3a8eb19ee82820e2e6b38cAuthor: Chris Larson Date: Mon Aug 8 16:09:37 2011 -0700 image: implement IMAGE_FEATURES IMAGE_FEATURES is analagous to DISTRO_FEATURES and MACHINE_FEATURES, for root filesystem construction. Currently, the only supported features are any defined package groups, as used by the oe.packagegroup python module. Example usage: PACKAGE_GROUP_myfeature = "vim iptables" IMAGE_FEATURES += "myfeature" Signed-off-by: Chris Larson -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to require image recipe from another layer?
Another recipe question along the same path.
The following recipe does not actually put helloworld in the image -
it does not even build it.
require recipes-sato/images/core-image-sato.bb
IMAGE_FEATURES += "helloworld"
The following one does.
require recipes-sato/images/core-image-sato.bb
IMAGE_INSTALL += "helloworld"
I am guessing that if I have several recipes in my layer (say) hw1,
hw2, hw3 etc, I would have to use the following recipe.
require recipes-sato/images/core-image-sato.bb
IMAGE_INSTALL += "hw1 hw2 hw3 etc"
However, I am sure there is a way to ties these up with
"IMAGE_FEATURE" variable.
Can you please help me with setting up my recipes so that all the
hello world apps are included when I use the following recipe.
require recipes-sato/images/core-image-sato.bb
IMAGE_FEATURES += "helloworld"
I am guessing that I would have to tell the hw1 recipe that it is a
helloworld feature. How do I go about doing this?
Here it is for reference:
DESCRIPTION = "hello world app"
SECTION = "autif"
LICENSE = "SomeLic"
LIC_FILES_CHKSUM = "file://COPYING;md5=178c09540123ca26c1b9c1ccbfbcde87"
PR = "r0"
SRC_URI = "file://COPYING \
file://helloworld.c"
S = "${WORKDIR}"
do_compile () {
${CC} helloworld.c -o helloworld
}
do_install () {
install -d ${D}${bindir}
install -m 0755 helloworld ${D}${bindir}
}
Thanks again!
Autif
On Wed, Dec 28, 2011 at 3:43 PM, autif khan wrote:
> Must be the hangover from the holidays!
>
> I typed the path as you suggested (I did replace recipes-core with
> recipes-sato), but I must have had a type somewhere and it did not
> work and gave the same error. I then tried the relative path - which I
> copied and pasted - instead of typing and it worked. So I assumed
> thats what it must have been.
>
> Now, I have the following as my recipe and it works just fine. As I
> said - must be the hangover from the holidays.
>
> require recipes-sato/images/core-image-sato.bb
> IMAGE_FEATURES += "helloworld"
>
> Thanks again
>
> Autif
>
> On Wed, Dec 28, 2011 at 3:31 PM, Chris Larson wrote:
>> On Wed, Dec 28, 2011 at 1:22 PM, autif khan wrote:
>>> Thats right. Accounting for the relative, path, the following recipe
>>> seems to works.
>>>
>>> require ../../../meta/recipes-sato/images/core-image-sato.bb
>>> IMAGE_FEATURES += "helloworld"
>>
>>
>> That's not what I was referring to. You don't need the full relative
>> path. It will automatically search BBPATH if you require a relative
>> path. if you do require recipes-sato/images/core-image-sato.bb, it
>> will search your layers and find it.
>> --
>> Christopher Larson
>> clarson at kergoth dot com
>> Founder - BitBake, OpenEmbedded, OpenZaurus
>> Maintainer - Tslib
>> Senior Software Engineer, Mentor Graphics
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build error on meta-cedarview
On 12/28/2011 09:26 PM, Andrew Schweitzer wrote: Jim Abernathy writes: While running a build of the core-image-sato using the edison latest commits and the meta-cedartrail bsp, I notices some errors fly by and thought I'd see if anyone knows the reason. The build is just to test the bsp with no changes. Basically, doing the Appendix A of the Development manual substituting cedartrail for crownbay. snippet of the console log below: NOTE: package icon-naming-utils-native-0.8.7-r3: task do_unpack: Started ERROR: Function 'Unpack failure for URL: 'http://tango.freedesktop.org/releases/icon-naming-utils-0.8.7.tar.gz'. I don't know the reason, but I did get the same error when trying to build yocto per the getting started page, changing local.conf to create qemuarm I would be interested in knowing the reason too. There has been a bug filed against this issue, it seems that the tarballs have moved or are unavailable from that location for some reason. You are getting a download page, and I believe that the failure should occur earlier with a checksum mismatch, but is not. You can fetch this file from our mirror at: http://downloads.yoctoproject.org/mirror/sources/icon-naming-utils-0.8.7.tar.gz Sau! Andy ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Manuaaly copying library to rootfs/lib
Hi,
I need to copy a library manually to rootfs. I want to put it in the manner
that on doing bitbake of initscripts this library should get copied to the
rootfs in the same manner as it used to copy contents under etc/ to rootfs. I
am successful in porting this library to
tmp/work/armv6-poky-linux-gnueabi/initscripts-1.0-r124/image/lib/libc-2.11.1.so,
now I am unable to put it in rootfs. When I am compiling rootfs I am unable to
see this library.
I tried giving cp -d ${WORKDIR}/libc-2.11.1.so
${D}${sysconfdir}/
in initscripts_1.0.bb then the same library got copied in rootfs/etc/ . What I
am supposed to do to copy it to rootfs/lib ?
Thanks & Regards,
Navani Kamal Srivastava
Larsen & Toubro Limited
www.larsentoubro.com
This Email may contain confidential or privileged information for the intended
recipient (s) If you are not the intended recipient, please do not use or
disseminate the information, notify the sender and delete it from your system.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to require image recipe from another layer?
On Thursday 29 December 2011 13:14:20 autif khan wrote: > The following recipe does not actually put helloworld in the image - > it does not even build it. > > require recipes-sato/images/core-image-sato.bb > IMAGE_FEATURES += "helloworld" > > The following one does. > > require recipes-sato/images/core-image-sato.bb > IMAGE_INSTALL += "helloworld" > > I am guessing that if I have several recipes in my layer (say) hw1, > hw2, hw3 etc, I would have to use the following recipe. > > require recipes-sato/images/core-image-sato.bb > IMAGE_INSTALL += "hw1 hw2 hw3 etc" > > However, I am sure there is a way to ties these up with > "IMAGE_FEATURE" variable. IMAGE_FEATURES do not refer to individual packages, they are specially defined package groups (or behaviours in the case of e.g. package-management). If you have a look at classes/core-image.bbclass and classes/image.bbclass you can see how the package groups are set up (PACKAGE_GROUP_featurename). As you found, at the moment there is nothing checking that features in IMAGE_FEATURES are valid, thus as there is no PACKAGE_GROUP_helloworld and nothing checking for "helloworld" in IMAGE_FEATURES, it does nothing. However, if all you want to do is add a few specific packages it's just fine to add their names to the end of IMAGE_INSTALL - IMAGE_FEATURES might be overkill. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RFC: Yocto BSP and kernel usability tools
On Wed, 2011-12-28 at 00:36 +, McClintock Matthew-B29882 wrote: > (This probably belongs somewhere inline but I got lost on the long email) > > A lot of times users would already have a git tree containing linux > and/or u-boot already working for their boards. Perhaps you could let > the user point at external linux and/or u-boot trees with defconfigs, > u-boot configs, device trees, etc for their target BSP? > Yes, definitely, I think that makes sense and should be easily doable using the templating mechanism e.g. using the 'choicelist' input method the user could be presented with a choice of kernel recipes to use similarly to how xserver-choice is defined in the examples. Choosing for example the Yocto 3.0 kernel would select what's already been described, but additional choices could select alternate kernels and allow the user to point those recipes at specific git repos or tarballs, attach defconfigs, .dts files or whatever to those kernels' SRC_URIs. There would need to be a way for the user to specify the files to include, etc, but that could also be easily done by adding some python code for that purpose (or maybe that's already covered by the code that adds patches to a SRC_URI). In any case, I haven't thought about all the details yet but I think the problem can be generalized even further and those details will come out in the implementation. But as a general answer to your question, I think that yes, it is possible and desirable, and I'll at least try to have a simple example of it implemented in the first pass. Tom > -M > > On Mon, Dec 19, 2011 at 10:55 AM, Tom Zanussi wrote: > > Hi, > > > > This is what I hope to implement in the M2 timeframe. > > > > Any and all comments welcome... > > > > Thanks, > > > > Tom > > > > --- > > [snip] ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
