Re: [yocto] What is the best practice for customizing libraries included in yocto distribution?
Hi, On Thu, Mar 13, 2014 at 4:52 PM, Federico Vitali fede.vit...@gmail.com wrote: Hi everyone, what should I do to customize and crosscompile a library already distributed with yocto? can you be a bit more specific? not sure i understand completely what you want to do. also how are you getting your distribution? it's prebuilt and you only have the image or you build it yourself from recipes? I see 2 possibilities: 1. Build and install a toolchain and sysrootfs on local host and untar the original library, apply yocto distributed patches and then cross compile == I'm having trouble here telling us more about the trouble might be useful. also telling how you build the toolchain and sysrootfs. 2. Use the yocto build environment itself, but I don't like this option. well, that would definitely be the more natural way of customizing existing recipes. that's what most people would do in their own layers, generally with .bbappend recipes. it's probably even easier to do that building your own toolchain/SDK to some extends.. why don't you like this option? Does anyone have already customized a library? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What is the best practice for customizing libraries included in yocto distribution?
Thank you Nicolas. I try to explain better, sorry, yesterday I wrote the email in a hurry. I'm working to build an OS based on sato, but I have to modify the code of some libraries included in the distribution. When I wrote customize I meant modify source code. I answer to your questions: can you be a bit more specific? not sure i understand completely what you want to do. also how are you getting your distribution? it's prebuilt and you only have the image or you build it yourself from recipes? I'm basing my distribution on sato-sdk. I've built it from source. I've built and installed a cross toolchain and root filesystem to use for building. I'm developing applications using the cross toolchain, adt tools and Eclipse. It is all set up properly. telling us more about the trouble might be useful. also telling how you build the toolchain and sysrootfs. I have to modify some source code of some gstreamer plugins to support some custom functionalities. During the developement I would like to work outside bitbake to develop / compile / debug on the target. I know that when I've finished I can simply add my patch to a bb append file of my own, and when the developement will be finished I will certainly do. well, that would definitely be the more natural way of customizing existing recipes. that's what most people would do in their own layers, generally with .bbappend recipes. it's probably even easier to do that building your own toolchain/SDK to some extends.. why don't you like this option? I certainly use this option when I customize existing recipes! My problem is in developement phase. This is the specific problem I get when I try to build gst-plugins-base: ake[4]: ingresso nella directory /home/vitalife/sources/gst-plugins-base-0.10.36/gst-libs/gst/tag CC libgsttag_0.10_la-gstvorbistag.lo CC libgsttag_0.10_la-gstid3tag.lo CC libgsttag_0.10_la-gstxmptag.lo gstxmptag.c: In function 'xmp_tag_type_get_name': gstxmptag.c:178:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ CC libgsttag_0.10_la-gstexiftag.lo CC libgsttag_0.10_la-lang.lo CC libgsttag_0.10_la-licenses.lo CC libgsttag_0.10_la-tags.lo CC libgsttag_0.10_la-gsttagdemux.lo CC libgsttag_0.10_la-gsttagmux.lo CC libgsttag_0.10_la-gsttageditingprivate.lo CC libgsttag_0.10_la-id3v2.lo CC libgsttag_0.10_la-id3v2frames.lo CC libgsttag_0.10_la-xmpwriter.lo CCLD libgsttag-0.10.la libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/ libgstbase-0.10.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/ libgstreamer-0.10.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/ libgobject-2.0.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/ libgmodule-2.0.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/ libgthread-2.0.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/ libglib-2.0.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libxml2.la' was moved. sed: can't read /usr/lib/libgstreamer-0.10.la: No such file or directory libtool: link: `=/usr/lib/libgstreamer-0.10.la' is not a valid libtool archive make[4]: *** [libgsttag-0.10.la] Errore 1 The library configured for cross compilation. I'm starting from the sources patched as in yocto. Any help appreciated! -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What is the best practice for customizing libraries included in yocto distribution?
On 2014-03-14 03:04, Federico Vitali wrote: Thank you Nicolas. I try to explain better, sorry, yesterday I wrote the email in a hurry. I'm working to build an OS based on sato, but I have to modify the code of some libraries included in the distribution. When I wrote customize I meant modify source code. I answer to your questions: can you be a bit more specific? not sure i understand completely what you want to do. also how are you getting your distribution? it's prebuilt and you only have the image or you build it yourself from recipes? I'm basing my distribution on sato-sdk. I've built it from source. I've built and installed a cross toolchain and root filesystem to use for building. I'm developing applications using the cross toolchain, adt tools and Eclipse. It is all set up properly. telling us more about the trouble might be useful. also telling how you build the toolchain and sysrootfs. I have to modify some source code of some gstreamer plugins to support some custom functionalities. During the developement I would like to work outside bitbake to develop / compile / debug on the target. I know that when I've finished I can simply add my patch to a bb append file of my own, and when the developement will be finished I will certainly do. well, that would definitely be the more natural way of customizing existing recipes. that's what most people would do in their own layers, generally with .bbappend recipes. it's probably even easier to do that building your own toolchain/SDK to some extends.. why don't you like this option? I certainly use this option when I customize existing recipes! My problem is in developement phase. This is the specific problem I get when I try to build gst-plugins-base: ake[4]: ingresso nella directory /home/vitalife/sources/gst-plugins-base-0.10.36/gst-libs/gst/tag CC libgsttag_0.10_la-gstvorbistag.lo CC libgsttag_0.10_la-gstid3tag.lo CC libgsttag_0.10_la-gstxmptag.lo gstxmptag.c: In function 'xmp_tag_type_get_name': gstxmptag.c:178:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ CC libgsttag_0.10_la-gstexiftag.lo CC libgsttag_0.10_la-lang.lo CC libgsttag_0.10_la-licenses.lo CC libgsttag_0.10_la-tags.lo CC libgsttag_0.10_la-gsttagdemux.lo CC libgsttag_0.10_la-gsttagmux.lo CC libgsttag_0.10_la-gsttageditingprivate.lo CC libgsttag_0.10_la-id3v2.lo CC libgsttag_0.10_la-id3v2frames.lo CC libgsttag_0.10_la-xmpwriter.lo CCLD libgsttag-0.10.la http://libgsttag-0.10.la libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libgstbase-0.10.la http://libgstbase-0.10.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libgstreamer-0.10.la http://libgstreamer-0.10.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libgobject-2.0.la http://libgobject-2.0.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libgmodule-2.0.la http://libgmodule-2.0.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libgthread-2.0.la http://libgthread-2.0.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libglib-2.0.la http://libglib-2.0.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libxml2.la http://libxml2.la' was moved. sed: can't read /usr/lib/libgstreamer-0.10.la http://libgstreamer-0.10.la: No such file or directory libtool: link: `=/usr/lib/libgstreamer-0.10.la http://libgstreamer-0.10.la' is not a valid libtool archive make[4]: *** [libgsttag-0.10.la http://libgsttag-0.10.la] Errore 1 The library configured for cross compilation. I'm starting from the sources patched as in yocto. Any help appreciated! Why not do these changes/development using your bitbake/Yocto build environment. I've found that using quilt makes this quite easy to do and helps manage the changes, patches, etc. It will also avoid the problem you are having which seems to stem from trying to build outside the original environment. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What is the best practice for customizing libraries included in yocto distribution?
On Fri, Mar 14, 2014 at 10:10 AM, Gary Thomas g...@mlbassoc.com wrote: CCLD libgsttag-0.10.la http://libgsttag-0.10.la libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libgstbase-0.10.la http://libgstbase-0.10.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libgstreamer-0.10.la http://libgstreamer-0.10.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libgobject-2.0.la http://libgobject-2.0.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libgmodule-2.0.la http://libgmodule-2.0.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libgthread-2.0.la http://libgthread-2.0.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libglib-2.0.la http://libglib-2.0.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libxml2.la http://libxml2.la' was moved. sed: can't read /usr/lib/libgstreamer-0.10.la http://libgstreamer-0.10.la: No such file or directory libtool: link: `=/usr/lib/libgstreamer-0.10.la http://libgstreamer-0.10.la' is not a valid libtool archive make[4]: *** [libgsttag-0.10.la http://libgsttag-0.10.la] Errore 1 The library configured for cross compilation. I'm starting from the sources patched as in yocto. Any help appreciated! Why not do these changes/development using your bitbake/Yocto build environment. I've found that using quilt makes this quite easy to do and helps manage the changes, patches, etc. It will also avoid the problem you are having which seems to stem from trying to build outside the original environment. yeah. i would recommend that too. I find the externalsrc class quite handy for such things. E.g. you can keep your git tree separate during development, *but* still rely on OE to build, which I think gives you the best of both world... of course for your own applications, using the SDK makes sense. nicolas -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What is the best practice for customizing libraries included in yocto distribution?
Thank you Nicholas and Gary! I'm quite experienced in linux embedded developement, but I'm new to yocto / openembedded. Nicolas, can you please explain me how to use my sources separate from OE build dir tree and still using oe built system? Do I have to edit the sources directly in builddir/tmp/work/etcetera or can I keep it separate? 2014-03-14 10:24 GMT+01:00 Nicolas Dechesne nicolas.deche...@linaro.org: On Fri, Mar 14, 2014 at 10:10 AM, Gary Thomas g...@mlbassoc.com wrote: CCLD libgsttag-0.10.la http://libgsttag-0.10.la libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/ libgstbase-0.10.la http://libgstbase-0.10.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/ libgstreamer-0.10.la http://libgstreamer-0.10.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/ libgobject-2.0.la http://libgobject-2.0.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/ libgmodule-2.0.la http://libgmodule-2.0.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/ libgthread-2.0.la http://libgthread-2.0.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/ libglib-2.0.la http://libglib-2.0.la' was moved. libtool: link: warning: library `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libxml2.la http://libxml2.la' was moved. sed: can't read /usr/lib/libgstreamer-0.10.la http://libgstreamer-0.10.la: No such file or directory libtool: link: `=/usr/lib/libgstreamer-0.10.la http://libgstreamer-0.10.la' is not a valid libtool archive make[4]: *** [libgsttag-0.10.la http://libgsttag-0.10.la] Errore 1 The library configured for cross compilation. I'm starting from the sources patched as in yocto. Any help appreciated! Why not do these changes/development using your bitbake/Yocto build environment. I've found that using quilt makes this quite easy to do and helps manage the changes, patches, etc. It will also avoid the problem you are having which seems to stem from trying to build outside the original environment. yeah. i would recommend that too. I find the externalsrc class quite handy for such things. E.g. you can keep your git tree separate during development, *but* still rely on OE to build, which I think gives you the best of both world... of course for your own applications, using the SDK makes sense. nicolas -- ___ 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] OpenEmbedded Developers meeting after ELC May 2-3
Please read: http://openembedded.org/wiki/OEDAM We'd like to get a good idea of the number of people attending. If you are waiting for approvals to travel, you could add yourself as tentative so we have some idea of total attendance for planning. If you are having trouble adding yourself on the wiki, send the info to me and I can add it for you. Thanks, Philip -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What is the best practice for customizing libraries included in yocto distribution?
Thank you Nicolas. Sorry, but I'm new to this extremely powerful building system, I'm a little confused. Now I'll read the sections you suggest! Thank you again! Federico Il giorno 14/mar/2014 11:18, Nicolas Dechesne nicolas.deche...@linaro.org ha scritto: Frederico, On Fri, Mar 14, 2014 at 11:09 AM, Federico Vitali fede.vit...@gmail.com wrote: Thank you Nicholas and Gary! I'm quite experienced in linux embedded developement, but I'm new to yocto / openembedded. Nicolas, can you please explain me how to use my sources separate from OE build dir tree and still using oe built system? Do I have to edit the sources directly in builddir/tmp/work/etcetera or can I keep it separate? Please have a look at http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-classes-externalsrc http://www.yoctoproject.org/docs/1.5.1/dev-manual/dev-manual.html#building-software-from-an-external-source let us know if you have additional questions -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building on target
On 2014-03-12 13:11, Rick Bianchi wrote: usbip from /usr/src/kernel/drivers/staging/usbip I finally managed to make this comparison. I did this by taking my Poky/Yocto built system for a i.MX6 system (ARM Cortex-A9) and replaced the rootfs with one for the Gumstix Overo (linaro). The results were nothing like yours, so it's a bit confusing. I actually built an entire Linux kernel - not just the one directory you mentioned. Poky/Yocto - 37 minutes Linaro - 48 minutes There is some flex in these numbers as they were on different [brand] SD cards, etc, but I sure did not see the 5 minutes for Linaro vs 24 hours on Yocto that you reported. Perhaps the only thing I did differently was I added the SDK tools to my Yocto system using these meta-packages instead of the list you used. packagegroup-core-sdk packagegroup-core-standalone-sdk-target You might try that to see if it makes any difference. n.b. part of what took me so long to get these results is I was trying to run this test on something closer to your Overo board. I have an older OMAP DM3730 board here that I tried to do these same steps, but it was unstable and I could not get the Linaro based file system to work at all. Very strange. In any case, I think the comparison I did get with the i.MX6 is valid. On Wed, Mar 12, 2014 at 11:44 AM, Gary Thomas g...@mlbassoc.com mailto:g...@mlbassoc.com wrote: On 2014-03-12 10:09, Rick Bianchi wrote: I completely agree with regards to the comparison, but I have compiled the same exact source on the same target (arm) and it only took 5 minutes when running the Linaro image. To clarify, the only difference is the build, one is Linaro (took 5 minutes to compile source on the target) and the other Yocto (took almost 24 hours to compile source on the target). Sorry, I missed that this was on the same hardware. What are you building? I'm going to try and duplicate this here on hardware I have that's quite similar to your Gumstix board. Is there something that I am missing? On Wed, Mar 12, 2014 at 8:28 AM, Gary Thomas g...@mlbassoc.com mailto:g...@mlbassoc.com mailto:g...@mlbassoc.com mailto:g...@mlbassoc.com wrote: On 2014-03-12 09:15, Rick Bianchi wrote: I have the gumstix-console-image with the added packages below. When I compile on the target is take a very long time for it to complete, over 24 hours. I have compiled the same code on the same target, but running Linaro image, and it only takes a few minutes. Is there another recipe that I need to add to the build to speed up compiling? Doubtful. The reason your build on the target takes so long is merely one of horsepower - that little ARM processor just doesn't have it, especially if you are comparing it to a typical desktop environment. EXTRA_IMAGE_FEATURES += dev-pkgs IMAGE_INSTALL_append = autoconf IMAGE_INSTALL_append = autofs IMAGE_INSTALL_append = automake IMAGE_INSTALL_append = ccache” IMAGE_INSTALL_append = chkconfig IMAGE_INSTALL_append = dbus-glib IMAGE_INSTALL_append = gcc IMAGE_INSTALL_append = glib-2.0 IMAGE_INSTALL_append = glib-networking IMAGE_INSTALL_append = glibmm IMAGE_INSTALL_append = packagegroup-core-buildessential IMAGE_INSTALL_append = pciutils IMAGE_INSTALL_append = pkgconfig” IMAGE_INSTALL_append = python-scons IMAGE_INSTALL_append = systemd-compat-units” IMAGE_INSTALL_append = sysfsutils IMAGE_INSTALL_append = tcp-wrappers IMAGE_INSTALL_append = usbutils IMAGE_INSTALL_append = util-macros -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building on target
If I have time today I will try to reproduce your results. If not, I will get to it first thing next week and post my result. Thanks, Rick On Fri, Mar 14, 2014 at 7:38 AM, Gary Thomas g...@mlbassoc.com wrote: On 2014-03-12 13:11, Rick Bianchi wrote: usbip from /usr/src/kernel/drivers/staging/usbip I finally managed to make this comparison. I did this by taking my Poky/Yocto built system for a i.MX6 system (ARM Cortex-A9) and replaced the rootfs with one for the Gumstix Overo (linaro). The results were nothing like yours, so it's a bit confusing. I actually built an entire Linux kernel - not just the one directory you mentioned. Poky/Yocto - 37 minutes Linaro - 48 minutes There is some flex in these numbers as they were on different [brand] SD cards, etc, but I sure did not see the 5 minutes for Linaro vs 24 hours on Yocto that you reported. Perhaps the only thing I did differently was I added the SDK tools to my Yocto system using these meta-packages instead of the list you used. packagegroup-core-sdk packagegroup-core-standalone-sdk-target You might try that to see if it makes any difference. n.b. part of what took me so long to get these results is I was trying to run this test on something closer to your Overo board. I have an older OMAP DM3730 board here that I tried to do these same steps, but it was unstable and I could not get the Linaro based file system to work at all. Very strange. In any case, I think the comparison I did get with the i.MX6 is valid. On Wed, Mar 12, 2014 at 11:44 AM, Gary Thomas g...@mlbassoc.commailto: g...@mlbassoc.com wrote: On 2014-03-12 10:09, Rick Bianchi wrote: I completely agree with regards to the comparison, but I have compiled the same exact source on the same target (arm) and it only took 5 minutes when running the Linaro image. To clarify, the only difference is the build, one is Linaro (took 5 minutes to compile source on the target) and the other Yocto (took almost 24 hours to compile source on the target). Sorry, I missed that this was on the same hardware. What are you building? I'm going to try and duplicate this here on hardware I have that's quite similar to your Gumstix board. Is there something that I am missing? On Wed, Mar 12, 2014 at 8:28 AM, Gary Thomas g...@mlbassoc.commailto: g...@mlbassoc.com mailto:g...@mlbassoc.com mailto:g...@mlbassoc.com wrote: On 2014-03-12 09:15, Rick Bianchi wrote: I have the gumstix-console-image with the added packages below. When I compile on the target is take a very long time for it to complete, over 24 hours. I have compiled the same code on the same target, but running Linaro image, and it only takes a few minutes. Is there another recipe that I need to add to the build to speed up compiling? Doubtful. The reason your build on the target takes so long is merely one of horsepower - that little ARM processor just doesn't have it, especially if you are comparing it to a typical desktop environment. EXTRA_IMAGE_FEATURES += dev-pkgs IMAGE_INSTALL_append = autoconf IMAGE_INSTALL_append = autofs IMAGE_INSTALL_append = automake IMAGE_INSTALL_append = ccache IMAGE_INSTALL_append = chkconfig IMAGE_INSTALL_append = dbus-glib IMAGE_INSTALL_append = gcc IMAGE_INSTALL_append = glib-2.0 IMAGE_INSTALL_append = glib-networking IMAGE_INSTALL_append = glibmm IMAGE_INSTALL_append = packagegroup-core-buildessential IMAGE_INSTALL_append = pciutils IMAGE_INSTALL_append = pkgconfig IMAGE_INSTALL_append = python-scons IMAGE_INSTALL_append = systemd-compat-units IMAGE_INSTALL_append = sysfsutils IMAGE_INSTALL_append = tcp-wrappers IMAGE_INSTALL_append = usbutils IMAGE_INSTALL_append = util-macros -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What is the best practice for customizing libraries included in yocto distribution?
It worked! Thank you so much! Now I have to go out, I have only to understand a couple of things... 1. how to make bitbake understand that I've only changed one or more file, now I have to do bitbake -c clean gst-plugins-base bitbake gst-plugins-base 2. how to debug via Eclipse. Thank you again! Federico 2014-03-14 11:18 GMT+01:00 Nicolas Dechesne nicolas.deche...@linaro.org: Frederico, On Fri, Mar 14, 2014 at 11:09 AM, Federico Vitali fede.vit...@gmail.com wrote: Thank you Nicholas and Gary! I'm quite experienced in linux embedded developement, but I'm new to yocto / openembedded. Nicolas, can you please explain me how to use my sources separate from OE build dir tree and still using oe built system? Do I have to edit the sources directly in builddir/tmp/work/etcetera or can I keep it separate? Please have a look at http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-classes-externalsrc http://www.yoctoproject.org/docs/1.5.1/dev-manual/dev-manual.html#building-software-from-an-external-source let us know if you have additional questions -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What is the best practice for customizing libraries included in yocto distribution?
On 2014-03-14 09:45, Federico Vitali wrote: It worked! Thank you so much! Now I have to go out, I have only to understand a couple of things... 1. how to make bitbake understand that I've only changed one or more file, now I have to do bitbake -c clean gst-plugins-base bitbake gst-plugins-base If you've only changed a file or two, try this instead: $ bitbake gst-plugins-base -C compile If you made a change that requires rerunning the 'configure' step, just use that instead of 'compile'. 2. how to debug via Eclipse. Thank you again! Federico 2014-03-14 11:18 GMT+01:00 Nicolas Dechesne nicolas.deche...@linaro.org mailto:nicolas.deche...@linaro.org: Frederico, On Fri, Mar 14, 2014 at 11:09 AM, Federico Vitali fede.vit...@gmail.com mailto:fede.vit...@gmail.com wrote: Thank you Nicholas and Gary! I'm quite experienced in linux embedded developement, but I'm new to yocto / openembedded. Nicolas, can you please explain me how to use my sources separate from OE build dir tree and still using oe built system? Do I have to edit the sources directly in builddir/tmp/work/etcetera or can I keep it separate? Please have a look at http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-classes-externalsrc http://www.yoctoproject.org/docs/1.5.1/dev-manual/dev-manual.html#building-software-from-an-external-source let us know if you have additional questions -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Issue installing External Kernel Module with same name
Hello Friends, I am using Poky version of Yocto for building images for imx28 evk. I have to included the receipe which builds the TI Comapt Wifi Driver as External Module and adds itself to the core-minimal-image. Below line is used under the layer.conf file to add TI WiFi Driver to rootfs: MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += ti-compat-wireless-wl18xx Now the problem is, as kernel also builds the wifi driver modules based on the same .config file used by external driver module. This generates two different rpm images for same wifi driver at tmp/deploy/rpm/imx28evk directory as below: test@test-VirtualBox:~/mx28_repo/mx28_build/tmp/deploy/rpm/imx28evk$ ls kernel-module-wl18xx-* kernel-module-wl18xx-3.10.32+git-r0.imx28evk.rpm kernel-module-wl18xx-r8.a8.08-0b.imx28evk.rpm The Final rootfs contains the .ko files from kernel-module-wl18xx-3.10.32+git-r0.imx28evk.rpm RPM instead of kernel-module-wl18xx-r8.a8.08-0b.imx28evk.rpm. Is there any way to modify the linux receipe not create RPMs for specific modules? Or Install specific kernel module with version as r8.a8.08-0b for wl18xx? Please feel free to share if you need further information. Thank you, Ankur -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Project Technical Team Meeting
BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft Exchange Server 2010 VERSION:2.0 BEGIN:VTIMEZONE TZID:Pacific Standard Time BEGIN:STANDARD DTSTART:16010101T02 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11 END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T02 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER;CN=Jolley, Stephen K:MAILTO:stephen.k.jol...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='achaudha@ mvista.com':MAILTO:achau...@mvista.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Anders Da rander':MAILTO:and...@chargestorm.se ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Arce Moren o, Abraham:MAILTO:abraham.arce.mor...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Ashfield, Bruce (Wind River):MAILTO:bruce.ashfi...@windriver.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Barros Pen a, Belen:MAILTO:belen.barros.p...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Burton, Ro ss:MAILTO:ross.bur...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Butler, Pa ul A (Wind River):MAILTO:paul.but...@windriver.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Chisanovic i, IonutX:MAILTO:ionutx.chisanov...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Chris Kam inski':MAILTO:chris.kamin...@tobias.tv ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Damian, Al exandru:MAILTO:alexandru.dam...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Daniel Ca uchy':MAILTO:dcau...@mvista.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=DeVries, A lex (Wind River):MAILTO:alex.devr...@windriver.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Dmytriyenk o, Denys:MAILTO:de...@ti.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Erway, Tra cey M:MAILTO:tracey.m.er...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Flanagan, Elizabeth:MAILTO:elizabeth.flana...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Gavaz, Ion ut A:MAILTO:ionut.a.ga...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Georgescu, Alexandru C:MAILTO:alexandru.c.george...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Hart, Darr en:MAILTO:darren.h...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Harvey, Mi chael:MAILTO:michael.har...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Hatle, Mar k G (Wind River):MAILTO:mark.ha...@windriver.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Hudson, S ean':MAILTO:sean_hud...@mentor.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Iorga, Cri stian:MAILTO:cristian.io...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Jeremy Pu hlman':MAILTO:jpuhl...@gmail.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Kamble, Ni tin A:MAILTO:nitin.a.kam...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Kridner, J ason:MAILTO:j...@ti.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Letnes, Th addeus C:MAILTO:thaddeus.c.let...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Liu, Song: MAILTO:song@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Long, Step hen J (Wind River):MAILTO:steve.l...@windriver.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Long, Yan ren':MAILTO:yl...@wpi.edu ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Maupin, C hase':MAILTO:chase.mau...@ti.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Moeller, T horsten:MAILTO:thorsten.moel...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Moses, Fre d:MAILTO:fred.mo...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Mueller, R obert:MAILTO:robert.muel...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Olivia Sal isbury:MAILTO:olivia.salisb...@tobias.tv ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Ong, Boon Leong:MAILTO:boon.leong@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Osier-mixo n, Jeffrey:MAILTO:jeffrey.osier-mi...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Palalau, A lexandruX:MAILTO:alexandrux.pala...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Patel, Key ur R:MAILTO:keyur.r.pa...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Petrisor,
Re: [yocto] Issue installing External Kernel Module with same name
On Thu, Mar 13, 2014 at 11:00 PM, Ankur Patel an...@embertec.com wrote: Now the problem is, as kernel also builds the wifi driver modules based on the same .config file used by external driver module. Disable the option in the component where you dont want it from. In this case kernel -Khem -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Building a metapackage
Hi, Is it possible to build a meta packages whose sole purpose is to bring in dependencies? Suppose I have package-1.deb, package-2.deb and package-3.deb. I would like add a .bb file to build a metapackage for those three packages. I have tried the following but it didn't work: SUMMARY = Package DESCRIPTION = LICENSE = CLOSED DEPENDS = \ package-1 package-2 package-3 \ inherit meta My use case is a series of voices by different manufactures which need to be installed on a per-manufacturer basis. So all the voices from manufacture1 would need to be installed on one machine and all the voices from manufacturer2 need to go on another machine. There are about 50-100 voice packages per manufacturer. Thanks, David -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building a metapackage
On 14 March 2014 16:34, David Welch djwelch...@gmail.com wrote: Is it possible to build a meta packages whose sole purpose is to bring in dependencies? You've just described a package group - have a look at anything called packagegroup-*.bb in oe-core, and packagegroup.bbclass. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building a metapackage
On 2014-03-14 10:34, David Welch wrote: Hi, Is it possible to build a meta packages whose sole purpose is to bring in dependencies? Suppose I have package-1.deb, package-2.deb and package-3.deb. I would like add a .bb file to build a metapackage for those three packages. I have tried the following but it didn't work: SUMMARY = Package DESCRIPTION = LICENSE = CLOSED DEPENDS = \ package-1 package-2 package-3 \ inherit meta My use case is a series of voices by different manufactures which need to be installed on a per-manufacturer basis. So all the voices from manufacture1 would need to be installed on one machine and all the voices from manufacturer2 need to go on another machine. There are about 50-100 voice packages per manufacturer. I think packagegroups (previously known as tasks) are what you are looking for. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building a metapackage
Thanks for your quick reponses, that works. On Fri, Mar 14, 2014 at 4:45 PM, Gary Thomas g...@mlbassoc.com wrote: On 2014-03-14 10:34, David Welch wrote: Hi, Is it possible to build a meta packages whose sole purpose is to bring in dependencies? Suppose I have package-1.deb, package-2.deb and package-3.deb. I would like add a .bb file to build a metapackage for those three packages. I have tried the following but it didn't work: SUMMARY = Package DESCRIPTION = LICENSE = CLOSED DEPENDS = \ package-1 package-2 package-3 \ inherit meta My use case is a series of voices by different manufactures which need to be installed on a per-manufacturer basis. So all the voices from manufacture1 would need to be installed on one machine and all the voices from manufacturer2 need to go on another machine. There are about 50-100 voice packages per manufacturer. I think packagegroups (previously known as tasks) are what you are looking for. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ 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] [ANNOUNCEMENT] 1.6_M3 released.
The artifacts for the 3rd milestone release of the upcoming Yocto Project 1.6 release are now available at: http://downloads.yoctoproject.org/releases/yocto/milestones/1.6_M3/ Features include: - 41 package updates - Packaging and rootfs re-factor and conversion to python - WIC extension for EFI - Documentation fixes and additions - Additional packages added support for ptest (total 38 packages now) - Additional packages added support for systemd (total 26 packages now) poky 54562006c1327c5b99daa4cc05a3ba7e38412da1 oecore 9a98b8bfe13b94d89a9e39cca821f26fdeaeffc3 meta-qt3 4772424ab69908d4e3b9d6d4717ca889468e6acd bitbake c39b99792547b642570ea5152070e7396e812390 eclipse-poky-juno 26bfc407781aa185f244a47ba63120343cee4a37 eclipse-poky-kepler f4d8e9243f9355424a01e2d72fd1abbf68d3bb7c meta-fsl-arm 40385ba8b3060adb3a535c6e5f08199b69f47754 meta-fsl-ppc 290a669e5480792836d4f7769ba2ef6f49799323 meta-intel a2e40547fd6e2e7874e1587956c4490904ce552a meta-minnow 32e4d6f17917027c3babe1ab738480de9691024d -- Elizabeth Flanagan Yocto Project Build and Release -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building on target
On 2014-03-14 08:49, Rick Bianchi wrote: If I have time today I will try to reproduce your results. If not, I will get to it first thing next week and post my result. One thing I forgot to point out is I used the identical kernel+modules for both setups. I would be interested to see if that makes any difference for you. I can't fully test it as my board doesn't have a Linaro kernel. So there are four combinations - I only tried the first two: Yocto kernel + Yocto rootfs Yocto kernel + Linaro rootfs Linaro kernel + Yocto rootfs Linaro kernel + Linaro rootfs On Fri, Mar 14, 2014 at 7:38 AM, Gary Thomas g...@mlbassoc.com mailto:g...@mlbassoc.com wrote: On 2014-03-12 13:11, Rick Bianchi wrote: usbip from /usr/src/kernel/drivers/staging/usbip I finally managed to make this comparison. I did this by taking my Poky/Yocto built system for a i.MX6 system (ARM Cortex-A9) and replaced the rootfs with one for the Gumstix Overo (linaro). The results were nothing like yours, so it's a bit confusing. I actually built an entire Linux kernel - not just the one directory you mentioned. Poky/Yocto - 37 minutes Linaro - 48 minutes There is some flex in these numbers as they were on different [brand] SD cards, etc, but I sure did not see the 5 minutes for Linaro vs 24 hours on Yocto that you reported. Perhaps the only thing I did differently was I added the SDK tools to my Yocto system using these meta-packages instead of the list you used. packagegroup-core-sdk packagegroup-core-standalone-sdk-target You might try that to see if it makes any difference. n.b. part of what took me so long to get these results is I was trying to run this test on something closer to your Overo board. I have an older OMAP DM3730 board here that I tried to do these same steps, but it was unstable and I could not get the Linaro based file system to work at all. Very strange. In any case, I think the comparison I did get with the i.MX6 is valid. On Wed, Mar 12, 2014 at 11:44 AM, Gary Thomas g...@mlbassoc.com mailto:g...@mlbassoc.com mailto:g...@mlbassoc.com mailto:g...@mlbassoc.com wrote: On 2014-03-12 10:09, Rick Bianchi wrote: I completely agree with regards to the comparison, but I have compiled the same exact source on the same target (arm) and it only took 5 minutes when running the Linaro image. To clarify, the only difference is the build, one is Linaro (took 5 minutes to compile source on the target) and the other Yocto (took almost 24 hours to compile source on the target). Sorry, I missed that this was on the same hardware. What are you building? I'm going to try and duplicate this here on hardware I have that's quite similar to your Gumstix board. Is there something that I am missing? On Wed, Mar 12, 2014 at 8:28 AM, Gary Thomas g...@mlbassoc.com mailto:g...@mlbassoc.com mailto:g...@mlbassoc.com mailto:g...@mlbassoc.com mailto:g...@mlbassoc.com mailto:g...@mlbassoc.com mailto:g...@mlbassoc.com mailto:g...@mlbassoc.com wrote: On 2014-03-12 09:15, Rick Bianchi wrote: I have the gumstix-console-image with the added packages below. When I compile on the target is take a very long time for it to complete, over 24 hours. I have compiled the same code on the same target, but running Linaro image, and it only takes a few minutes. Is there another recipe that I need to add to the build to speed up compiling? Doubtful. The reason your build on the target takes so long is merely one of horsepower - that little ARM processor just doesn't have it, especially if you are comparing it to a typical desktop environment. EXTRA_IMAGE_FEATURES += dev-pkgs IMAGE_INSTALL_append = autoconf IMAGE_INSTALL_append = autofs IMAGE_INSTALL_append = automake IMAGE_INSTALL_append = ccache” IMAGE_INSTALL_append = chkconfig IMAGE_INSTALL_append = dbus-glib IMAGE_INSTALL_append = gcc IMAGE_INSTALL_append = glib-2.0 IMAGE_INSTALL_append = glib-networking IMAGE_INSTALL_append = glibmm IMAGE_INSTALL_append = packagegroup-core-buildessential IMAGE_INSTALL_append = pciutils IMAGE_INSTALL_append = pkgconfig” IMAGE_INSTALL_append = python-scons IMAGE_INSTALL_append = systemd-compat-units” IMAGE_INSTALL_append = sysfsutils IMAGE_INSTALL_append = tcp-wrappers IMAGE_INSTALL_append =
[linux-yocto] linux-yocto-3.10 emgd-1.18 checking out as standard/base
Trying to build minnow/dora with the latest linux-yocto 3.10-ltsi
including the recent emgd fixes results in a build source tree that has no
emgd patches applied.
The recipe has good SRCREVs:
Minnow linux-yocto_3.10.bbappend:
SRC_URI_minnow =
git://git.yoctoproject.org/linux-yocto-3.10;protocol=git;nocheckout=1;bran
ch=${KBRANCH},${KMETA},emgd-1.18;name=machine,meta,emgd
SRCREV_machine_pn-linux-yocto_minnow ?=
78afd3095c9b37efbbfbfdc25eb3833ef3c6a718
SRCREV_meta_pn-linux-yocto_minnow ?=
6e0e756d51372c8b176c5d1e6f786545bceed351
SRCREV_emgd_pn-linux-yocto_minnow ?=
42d5e4548e8e79e094fa8697949eed4cf6af00a3
I verified with bitbake -e that is indeed using the correct SRC_URI and
SRCREVs.
After a clean all and fresh linux-yocto build:
$ cd
tmp/work/minnow-poky-linux/linux-yocto/3.10.32+gitAUTOINC+6e0e756d51_78afd3
095c-r0/linux
$ git rev-parse HEAD
78afd3095c9b37efbbfbfdc25eb3833ef3c6a718
This is the tip of standard/base. Appears as though the ddm-emgd feature
was not applied. But...
$ grep emgd .meta/meta-series
# _mark drm-emgd-1.18.scc start
# _kconf hardware
/build/yocto/dora/minnow_20131203165453/build/tmp/work/minnow-poky-linux/li
nux-yocto/3.10.32+gitAUTOINC+6e0e756d51_78afd3095c-r0/linux/.meta/cfg/kerne
l-cache/features/drm-emgd/drm-emgd.cfg
# _git merge emgd-1.18
# _mark drm-emgd-1.18.scc en
So it did attempt to merge in the branch...
$ git rev-parse emgd-1.18
78afd3095c9b37efbbfbfdc25eb3833ef3c6a718
Well... That's not good, emgd-1.18 is the same as standard/base in this
checkout (although clearly not in the upstream repository). Any ideas what
is going on here? I would guess one of my SRCREVs was wrong (or possibly
the name of the variable in the recipe), but they all seem correct to me,
and no warnings are issued that I have seen.
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] linux-yocto-3.10 emgd-1.18 checking out as standard/base
On 3/14/14, 13:18, Hart, Darren darren.h...@intel.com wrote:
Trying to build minnow/dora with the latest linux-yocto 3.10-ltsi
including the recent emgd fixes results in a build source tree that has no
emgd patches applied.
The recipe has good SRCREVs:
Minnow linux-yocto_3.10.bbappend:
SRC_URI_minnow =
git://git.yoctoproject.org/linux-yocto-3.10;protocol=git;nocheckout=1;bra
n
ch=${KBRANCH},${KMETA},emgd-1.18;name=machine,meta,emgd
SRCREV_machine_pn-linux-yocto_minnow ?=
78afd3095c9b37efbbfbfdc25eb3833ef3c6a718
SRCREV_meta_pn-linux-yocto_minnow ?=
6e0e756d51372c8b176c5d1e6f786545bceed351
SRCREV_emgd_pn-linux-yocto_minnow ?=
42d5e4548e8e79e094fa8697949eed4cf6af00a3
I verified with bitbake -e that is indeed using the correct SRC_URI and
SRCREVs.
After a clean all and fresh linux-yocto build:
$ cd
tmp/work/minnow-poky-linux/linux-yocto/3.10.32+gitAUTOINC+6e0e756d51_78afd
3
095c-r0/linux
$ git rev-parse HEAD
78afd3095c9b37efbbfbfdc25eb3833ef3c6a718
This is the tip of standard/base. Appears as though the ddm-emgd feature
was not applied. But...
$ grep emgd .meta/meta-series
# _mark drm-emgd-1.18.scc start
# _kconf hardware
/build/yocto/dora/minnow_20131203165453/build/tmp/work/minnow-poky-linux/l
i
nux-yocto/3.10.32+gitAUTOINC+6e0e756d51_78afd3095c-r0/linux/.meta/cfg/kern
e
l-cache/features/drm-emgd/drm-emgd.cfg
# _git merge emgd-1.18
# _mark drm-emgd-1.18.scc en
So it did attempt to merge in the branch...
$ git rev-parse emgd-1.18
78afd3095c9b37efbbfbfdc25eb3833ef3c6a718
Well... That's not good, emgd-1.18 is the same as standard/base in this
checkout (although clearly not in the upstream repository). Any ideas what
is going on here? I would guess one of my SRCREVs was wrong (or possibly
the name of the variable in the recipe), but they all seem correct to me,
and no warnings are issued that I have seen.
OK, I found it. It's rather ugly.
do_validate_branches resets the HEAD of any branch that contains
SRCREV_machine. So if a feature branch is current with standard/base for
example, that feature branch gets reset to standard/base.
Why on earth does this blob of time suckage exist?
kernel-yocto.bbclass:
349 |───# force the SRCREV in each branch that contains the specified
350 |───# SRCREV (if it isn't the current HEAD of that branch)
351 |───git checkout -q master
352 |───for b in $containing_branches; do
354 |───|───branch_head=`git show-ref -s --heads
${b}`|─|───
355 |───|───if [ $branch_head != $target_branch_head ]; then
356 |───|───|───echo [INFO] Setting branch $b to
${target_branch_head}
357 |───|───|───if [ $b = master ]; then
358 |───|───|───|───git reset --hard $target_branch_head
/dev/null
359 |───|───|───else
360 |───|───|───|───git branch -D $b /dev/null
361 |───|───|───|───git branch $b $target_branch_head
/dev/null
362 |───|───|───fi
363 |───|───fi
364 |───done
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] linux-yocto-3.10 emgd-1.18 checking out as standard/base
On Fri, Mar 14, 2014 at 5:40 PM, Hart, Darren darren.h...@intel.com wrote:
On 3/14/14, 13:18, Hart, Darren darren.h...@intel.com wrote:
Trying to build minnow/dora with the latest linux-yocto 3.10-ltsi
including the recent emgd fixes results in a build source tree that has no
emgd patches applied.
The recipe has good SRCREVs:
Minnow linux-yocto_3.10.bbappend:
SRC_URI_minnow =
git://git.yoctoproject.org/linux-yocto-3.10;protocol=git;nocheckout=1;bra
n
ch=${KBRANCH},${KMETA},emgd-1.18;name=machine,meta,emgd
SRCREV_machine_pn-linux-yocto_minnow ?=
78afd3095c9b37efbbfbfdc25eb3833ef3c6a718
SRCREV_meta_pn-linux-yocto_minnow ?=
6e0e756d51372c8b176c5d1e6f786545bceed351
SRCREV_emgd_pn-linux-yocto_minnow ?=
42d5e4548e8e79e094fa8697949eed4cf6af00a3
I verified with bitbake -e that is indeed using the correct SRC_URI and
SRCREVs.
After a clean all and fresh linux-yocto build:
$ cd
tmp/work/minnow-poky-linux/linux-yocto/3.10.32+gitAUTOINC+6e0e756d51_78afd
3
095c-r0/linux
$ git rev-parse HEAD
78afd3095c9b37efbbfbfdc25eb3833ef3c6a718
This is the tip of standard/base. Appears as though the ddm-emgd feature
was not applied. But...
$ grep emgd .meta/meta-series
# _mark drm-emgd-1.18.scc start
# _kconf hardware
/build/yocto/dora/minnow_20131203165453/build/tmp/work/minnow-poky-linux/l
i
nux-yocto/3.10.32+gitAUTOINC+6e0e756d51_78afd3095c-r0/linux/.meta/cfg/kern
e
l-cache/features/drm-emgd/drm-emgd.cfg
# _git merge emgd-1.18
# _mark drm-emgd-1.18.scc en
So it did attempt to merge in the branch...
$ git rev-parse emgd-1.18
78afd3095c9b37efbbfbfdc25eb3833ef3c6a718
Well... That's not good, emgd-1.18 is the same as standard/base in this
checkout (although clearly not in the upstream repository). Any ideas what
is going on here? I would guess one of my SRCREVs was wrong (or possibly
the name of the variable in the recipe), but they all seem correct to me,
and no warnings are issued that I have seen.
OK, I found it. It's rather ugly.
do_validate_branches resets the HEAD of any branch that contains
SRCREV_machine. So if a feature branch is current with standard/base for
example, that feature branch gets reset to standard/base.
Yep, and the answer is, don't set SRCREV to that value :)
Why on earth does this blob of time suckage exist?
Check the mailing list archives, I've answered this about 3 times :)
It has to work like this, it is fixing a specific set of bugs that
were reported, and
changes can break that workflow.
The point is that *any* branch can be built in the tree, since the .scc files
describe the BSP and the BSP descriptions have the branching information.
The SRCREV and branch are in the recipe to keep the fetcher happy, but
to make them actually *mean* something to the build (like any other git
based build .. which resets the tree to SRCREV) then any branch that
contains that SRCREV is reset to that same point. So no matter where a
BSP wanders, it finds what you've specified as the SRCREV.
Moral of the story, make sure that your SRCREV is what you want to
build, not a default value.
I've actually re-written the branch validation based on top of the fact that
the fetcher now does a lot of this checking for me, so the code is a lot
simpler.
Bruce
kernel-yocto.bbclass:
349 |───# force the SRCREV in each branch that contains the specified
350 |───# SRCREV (if it isn't the current HEAD of that branch)
351 |───git checkout -q master
352 |───for b in $containing_branches; do
354 |───|───branch_head=`git show-ref -s --heads
${b}`|─|───
355 |───|───if [ $branch_head != $target_branch_head ]; then
356 |───|───|───echo [INFO] Setting branch $b to
${target_branch_head}
357 |───|───|───if [ $b = master ]; then
358 |───|───|───|───git reset --hard $target_branch_head
/dev/null
359 |───|───|───else
360 |───|───|───|───git branch -D $b /dev/null
361 |───|───|───|───git branch $b $target_branch_head
/dev/null
362 |───|───|───fi
363 |───|───fi
364 |───done
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] linux-yocto-3.10 emgd-1.18 checking out as standard/base
On 3/14/14, 19:57, Bruce Ashfield bruce.ashfi...@gmail.com wrote:
On Fri, Mar 14, 2014 at 5:40 PM, Hart, Darren darren.h...@intel.com
wrote:
On 3/14/14, 13:18, Hart, Darren darren.h...@intel.com wrote:
Trying to build minnow/dora with the latest linux-yocto 3.10-ltsi
including the recent emgd fixes results in a build source tree that has
no
emgd patches applied.
The recipe has good SRCREVs:
Minnow linux-yocto_3.10.bbappend:
SRC_URI_minnow =
git://git.yoctoproject.org/linux-yocto-3.10;protocol=git;nocheckout=1;b
ra
n
ch=${KBRANCH},${KMETA},emgd-1.18;name=machine,meta,emgd
SRCREV_machine_pn-linux-yocto_minnow ?=
78afd3095c9b37efbbfbfdc25eb3833ef3c6a718
SRCREV_meta_pn-linux-yocto_minnow ?=
6e0e756d51372c8b176c5d1e6f786545bceed351
SRCREV_emgd_pn-linux-yocto_minnow ?=
42d5e4548e8e79e094fa8697949eed4cf6af00a3
I verified with bitbake -e that is indeed using the correct SRC_URI and
SRCREVs.
After a clean all and fresh linux-yocto build:
$ cd
tmp/work/minnow-poky-linux/linux-yocto/3.10.32+gitAUTOINC+6e0e756d51_78a
fd
3
095c-r0/linux
$ git rev-parse HEAD
78afd3095c9b37efbbfbfdc25eb3833ef3c6a718
This is the tip of standard/base. Appears as though the ddm-emgd feature
was not applied. But...
$ grep emgd .meta/meta-series
# _mark drm-emgd-1.18.scc start
# _kconf hardware
/build/yocto/dora/minnow_20131203165453/build/tmp/work/minnow-poky-linux
/l
i
nux-yocto/3.10.32+gitAUTOINC+6e0e756d51_78afd3095c-r0/linux/.meta/cfg/ke
rn
e
l-cache/features/drm-emgd/drm-emgd.cfg
# _git merge emgd-1.18
# _mark drm-emgd-1.18.scc en
So it did attempt to merge in the branch...
$ git rev-parse emgd-1.18
78afd3095c9b37efbbfbfdc25eb3833ef3c6a718
Well... That's not good, emgd-1.18 is the same as standard/base in this
checkout (although clearly not in the upstream repository). Any ideas
what
is going on here? I would guess one of my SRCREVs was wrong (or possibly
the name of the variable in the recipe), but they all seem correct to
me,
and no warnings are issued that I have seen.
OK, I found it. It's rather ugly.
do_validate_branches resets the HEAD of any branch that contains
SRCREV_machine. So if a feature branch is current with standard/base for
example, that feature branch gets reset to standard/base.
Yep, and the answer is, don't set SRCREV to that value :)
Uhm... That can't be right...
Why on earth does this blob of time suckage exist?
Check the mailing list archives, I've answered this about 3 times :)
Then it warrants some commentary in the code itself that explains the
necessity. Very few people are as close to this stuff as I am, and if it
is still non-intuitive to me, we're likely to be running into this many
more times in the future.
It has to work like this, it is fixing a specific set of bugs that
were reported, and
changes can break that workflow.
The point is that *any* branch can be built in the tree, since the .scc
files
describe the BSP and the BSP descriptions have the branching information.
The SRCREV and branch are in the recipe to keep the fetcher happy, but
to make them actually *mean* something to the build (like any other git
based build .. which resets the tree to SRCREV) then any branch that
contains that SRCREV is reset to that same point. So no matter where a
BSP wanders, it finds what you've specified as the SRCREV.
Moral of the story, make sure that your SRCREV is what you want to
build, not a default value.
But I didn't use a default value. See the SRCREVs listed from the recipe
above. I specifically stated that I wanted the head of standard/base. This
HEAD just happens to be what we merged with emgd-1.18. What this is saying
is that you can never use a SRCREV for a machine branch that exists in a
feature branch if you want to use that feature. That means the only way
the system can work is if every machine uses commits above and beyond
standard/base Which is exactly what we are trying to avoid for IA
systems.
There needs to be a way to make this work in a predictable way without all
this implicit mangling and silent failures.
--
Darren
I've actually re-written the branch validation based on top of the fact
that
the fetcher now does a lot of this checking for me, so the code is a lot
simpler.
Bruce
kernel-yocto.bbclass:
349 |───# force the SRCREV in each branch that contains the
specified
350 |───# SRCREV (if it isn't the current HEAD of that branch)
351 |───git checkout -q master
352 |───for b in $containing_branches; do
354 |───|───branch_head=`git show-ref -s --heads
${b}`|─|───
355 |───|───if [ $branch_head != $target_branch_head ]; then
356 |───|───|───echo [INFO] Setting branch $b to
${target_branch_head}
357 |───|───|───if [ $b = master ]; then
358 |───|───|───|───git reset --hard
$target_branch_head
/dev/null
359 |───|───|───else
360 |───|───|───|───git branch -D $b /dev/null
361 |───|───|───|───git branch $b
Re: [linux-yocto] linux-yocto-3.10 emgd-1.18 checking out as standard/base
On 2014-03-15, 12:50 AM, Hart, Darren wrote:
On 3/14/14, 19:57, Bruce Ashfield bruce.ashfi...@gmail.com wrote:
On Fri, Mar 14, 2014 at 5:40 PM, Hart, Darren darren.h...@intel.com
wrote:
On 3/14/14, 13:18, Hart, Darren darren.h...@intel.com wrote:
Trying to build minnow/dora with the latest linux-yocto 3.10-ltsi
including the recent emgd fixes results in a build source tree that has
no
emgd patches applied.
The recipe has good SRCREVs:
Minnow linux-yocto_3.10.bbappend:
SRC_URI_minnow =
git://git.yoctoproject.org/linux-yocto-3.10;protocol=git;nocheckout=1;b
ra
n
ch=${KBRANCH},${KMETA},emgd-1.18;name=machine,meta,emgd
SRCREV_machine_pn-linux-yocto_minnow ?=
78afd3095c9b37efbbfbfdc25eb3833ef3c6a718
SRCREV_meta_pn-linux-yocto_minnow ?=
6e0e756d51372c8b176c5d1e6f786545bceed351
SRCREV_emgd_pn-linux-yocto_minnow ?=
42d5e4548e8e79e094fa8697949eed4cf6af00a3
I verified with bitbake -e that is indeed using the correct SRC_URI and
SRCREVs.
After a clean all and fresh linux-yocto build:
$ cd
tmp/work/minnow-poky-linux/linux-yocto/3.10.32+gitAUTOINC+6e0e756d51_78a
fd
3
095c-r0/linux
$ git rev-parse HEAD
78afd3095c9b37efbbfbfdc25eb3833ef3c6a718
This is the tip of standard/base. Appears as though the ddm-emgd feature
was not applied. But...
$ grep emgd .meta/meta-series
# _mark drm-emgd-1.18.scc start
# _kconf hardware
/build/yocto/dora/minnow_20131203165453/build/tmp/work/minnow-poky-linux
/l
i
nux-yocto/3.10.32+gitAUTOINC+6e0e756d51_78afd3095c-r0/linux/.meta/cfg/ke
rn
e
l-cache/features/drm-emgd/drm-emgd.cfg
# _git merge emgd-1.18
# _mark drm-emgd-1.18.scc en
So it did attempt to merge in the branch...
$ git rev-parse emgd-1.18
78afd3095c9b37efbbfbfdc25eb3833ef3c6a718
Well... That's not good, emgd-1.18 is the same as standard/base in this
checkout (although clearly not in the upstream repository). Any ideas
what
is going on here? I would guess one of my SRCREVs was wrong (or possibly
the name of the variable in the recipe), but they all seem correct to
me,
and no warnings are issued that I have seen.
OK, I found it. It's rather ugly.
do_validate_branches resets the HEAD of any branch that contains
SRCREV_machine. So if a feature branch is current with standard/base for
example, that feature branch gets reset to standard/base.
Yep, and the answer is, don't set SRCREV to that value :)
Uhm... That can't be right...
Why on earth does this blob of time suckage exist?
Check the mailing list archives, I've answered this about 3 times :)
Then it warrants some commentary in the code itself that explains the
necessity. Very few people are as close to this stuff as I am, and if it
is still non-intuitive to me, we're likely to be running into this many
more times in the future.
It has to work like this, it is fixing a specific set of bugs that
were reported, and
changes can break that workflow.
The point is that *any* branch can be built in the tree, since the .scc
files
describe the BSP and the BSP descriptions have the branching information.
The SRCREV and branch are in the recipe to keep the fetcher happy, but
to make them actually *mean* something to the build (like any other git
based build .. which resets the tree to SRCREV) then any branch that
contains that SRCREV is reset to that same point. So no matter where a
BSP wanders, it finds what you've specified as the SRCREV.
Moral of the story, make sure that your SRCREV is what you want to
build, not a default value.
But I didn't use a default value. See the SRCREVs listed from the recipe
Right. I managed to miss that.
above. I specifically stated that I wanted the head of standard/base. This
HEAD just happens to be what we merged with emgd-1.18. What this is saying
is that you can never use a SRCREV for a machine branch that exists in a
feature branch if you want to use that feature. That means the only way
the system can work is if every machine uses commits above and beyond
standard/base Which is exactly what we are trying to avoid for IA
systems.
The error would have been me merging standard base into emgd, that
never should happen to a topic branch. When I was merging your
patches, that was my mistake.
There needs to be a way to make this work in a predictable way without all
this implicit mangling and silent failures.
All I can say, is that what is there, is there for a reason. It's
the nature of the beast, jiggling it one way breaks one thing ..
and fixes another.
That being said, this has to work now that I've got that merge in
the EMGD branch and I actually have some code for this, that checks
before patching, not during validation. Let me dust that off.
Bruce
--
Darren
I've actually re-written the branch validation based on top of the fact
that
the fetcher now does a lot of this checking for me, so the code is a lot
simpler.
Bruce
kernel-yocto.bbclass:
349 |───# force the SRCREV in each branch that
