[yocto] Where is the emgd.ko module?

[autif khan]

I built the "crownbay" (not crownbay-noemgd) image as outlined in the
E660 development kit (link
http://www.yoctoproject.org/download/bsp/intel-atom-processor-e660-intel-platform-controller-hub-eg20t-development-kit-1)

I used poky-edison-6.0.tar.bz2 and crownbay-edison-6.0.0.tar.bz2 and
followed the instructions (short version - extract, move, add
meta-intel/meta-crownbay to bblayers.conf, add MACHINE="crownbay" to
local.conf, bitbake core-image-sato)

The result was the expected set of images in tmp/deploy/images

I loop mounted the core-image-sato-crownbay.ext3 and tried to find
emgd.ko in the file system - I could not find it. (find output
attached - notice that there is no emgd.ko)

Here is the kicker - crownbay-edison-6.0.0.tar.bz2 has a directory
called "binary" which contains core-image-sato-crownbay.hddimg, which
contains rootfs.img, which I also loop mounted and was able to find
the emgd.ko (however this image does not work with my hardware, I am
not sure why). Find output for this is also included below.

I very much doubt that it is included as a part of the kernel, I
looked at the kernel's .config (in
tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r2/linux-crownbay-standard-build)
and could not find emgd there either.

So, my questions is if I am doing something wrong? Do I need to do
something to get the emgd.ko to build? I am using the latest release
(6.0 "Edison" (released on October 17th, 2011)). Please advise.

Thanks

Autif

autif@xu:~/data/dev/yocto/emgd/tmp/deploy/images/1$ sudo find . | grep emgd
./usr/lib/libemgdsrv_um.so.1.5.15.3226
./usr/lib/libemgdsrv_um.so
./usr/lib/libemgdglslcompiler.so.1.5.15.3226
./usr/lib/libemgdPVR2D_DRIWSEGL.so
./usr/lib/xorg/modules/drivers/emgd_drv.so
./usr/lib/libemgdPVR2D_DRIWSEGL.so.1.5.15.3226
./usr/lib/libemgdsrv_init.so
./usr/lib/libemgdsrv_init.so.1.5.15.3226
./usr/lib/libemgdglslcompiler.so
./usr/lib/dri/emgd_dri.so
autif@xu:~/data/dev/yocto/emgd/tmp/deploy/images/1$

autif@xu:~/data/dev/yocto/poky-edison-6.0/meta-intel/meta-crownbay/binary/2$
sudo find . | grep emgd
./usr/lib/libemgdsrv_um.so
./usr/lib/dri/emgd_dri.so
./usr/lib/libemgdsrv_init.so.1.5.15.3226
./usr/lib/libemgdsrv_init.so
./usr/lib/xorg/modules/drivers/emgd_drv.so
./usr/lib/libemgdPVR2D_DRIWSEGL.so.1.5.15.3226
./usr/lib/libemgdglslcompiler.so.1.5.15.3226
./usr/lib/libemgdsrv_um.so.1.5.15.3226
./usr/lib/libemgdPVR2D_DRIWSEGL.so
./usr/lib/libemgdglslcompiler.so
./lib/modules/3.0.4-yocto-standard+/kernel/drivers/gpu/drm/emgd
./lib/modules/3.0.4-yocto-standard+/kernel/drivers/gpu/drm/emgd/emgd.ko
./etc/rpm-postinsts/kernel-module-emgd.sh.done
autif@xu:~/data/dev/yocto/poky-edison-6.0/meta-intel/meta-crownbay/binary/2$
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Where is the emgd.ko module?

[Jim Abernathy]

On Tue, 2011-12-13 at 11:13 -0500, autif khan wrote:
> I built the "crownbay" (not crownbay-noemgd) image as outlined in the
> E660 development kit (link
> http://www.yoctoproject.org/download/bsp/intel-atom-processor-e660-intel-platform-controller-hub-eg20t-development-kit-1)
> 
> I used poky-edison-6.0.tar.bz2 and crownbay-edison-6.0.0.tar.bz2 and
> followed the instructions (short version - extract, move, add
> meta-intel/meta-crownbay to bblayers.conf, add MACHINE="crownbay" to
> local.conf, bitbake core-image-sato)
> 
> The result was the expected set of images in tmp/deploy/images
> 
> I loop mounted the core-image-sato-crownbay.ext3 and tried to find
> emgd.ko in the file system - I could not find it. (find output
> attached - notice that there is no emgd.ko)
> 
> Here is the kicker - crownbay-edison-6.0.0.tar.bz2 has a directory
> called "binary" which contains core-image-sato-crownbay.hddimg, which
> contains rootfs.img, which I also loop mounted and was able to find
> the emgd.ko (however this image does not work with my hardware, I am
> not sure why). Find output for this is also included below.
> 
> I very much doubt that it is included as a part of the kernel, I
> looked at the kernel's .config (in
> tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r2/linux-crownbay-standard-build)
> and could not find emgd there either.
> 
> So, my questions is if I am doing something wrong? Do I need to do
> something to get the emgd.ko to build? I am using the latest release
> (6.0 "Edison" (released on October 17th, 2011)). Please advise.
> 
Check out the README file in the meta-crownbay directory. There are
instructions on integrating the EMGD driver files into the build.

Jim A

> Thanks
> 
> Autif
> 
> autif@xu:~/data/dev/yocto/emgd/tmp/deploy/images/1$ sudo find . | grep emgd
> ./usr/lib/libemgdsrv_um.so.1.5.15.3226
> ./usr/lib/libemgdsrv_um.so
> ./usr/lib/libemgdglslcompiler.so.1.5.15.3226
> ./usr/lib/libemgdPVR2D_DRIWSEGL.so
> ./usr/lib/xorg/modules/drivers/emgd_drv.so
> ./usr/lib/libemgdPVR2D_DRIWSEGL.so.1.5.15.3226
> ./usr/lib/libemgdsrv_init.so
> ./usr/lib/libemgdsrv_init.so.1.5.15.3226
> ./usr/lib/libemgdglslcompiler.so
> ./usr/lib/dri/emgd_dri.so
> autif@xu:~/data/dev/yocto/emgd/tmp/deploy/images/1$
> 
> autif@xu:~/data/dev/yocto/poky-edison-6.0/meta-intel/meta-crownbay/binary/2$
> sudo find . | grep emgd
> ./usr/lib/libemgdsrv_um.so
> ./usr/lib/dri/emgd_dri.so
> ./usr/lib/libemgdsrv_init.so.1.5.15.3226
> ./usr/lib/libemgdsrv_init.so
> ./usr/lib/xorg/modules/drivers/emgd_drv.so
> ./usr/lib/libemgdPVR2D_DRIWSEGL.so.1.5.15.3226
> ./usr/lib/libemgdglslcompiler.so.1.5.15.3226
> ./usr/lib/libemgdsrv_um.so.1.5.15.3226
> ./usr/lib/libemgdPVR2D_DRIWSEGL.so
> ./usr/lib/libemgdglslcompiler.so
> ./lib/modules/3.0.4-yocto-standard+/kernel/drivers/gpu/drm/emgd
> ./lib/modules/3.0.4-yocto-standard+/kernel/drivers/gpu/drm/emgd/emgd.ko
> ./etc/rpm-postinsts/kernel-module-emgd.sh.done
> autif@xu:~/data/dev/yocto/poky-edison-6.0/meta-intel/meta-crownbay/binary/2$
> ___
> 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] Where is the emgd.ko module?

[autif khan]

I think that I did. Included is an excerpt that says that I need not
do anything except bitbake core image sato when MACHINE="crownbay".

As instructed, I followed the steps in section one (Building the
meta-crownbay BSP layer) and ignored everything in section two
(Special notes for building the meta-crownbay BSP layer) which
includes instructions to patch a "crownbay-noemgd" with the Intel
driver.

Included below is the excerpt from the README. Is there a section that
I am overlooking?

Thanks

Autif

The meta-crownbay layer makes use of the proprietary Intel EMGD
userspace drivers when building the "crownbay" machine (but not when
building the "crownbay-noemgd" machine).  If you got the BSP from the
'BSP Downloads' section of the Yocto website, the EMGD binaries needed
to perform the build will already be present in the BSP, located in
the meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin-1.8
directory, and you can ignore the rest of this section.


On Tue, Dec 13, 2011 at 11:28 AM, Jim Abernathy  wrote:
> On Tue, 2011-12-13 at 11:13 -0500, autif khan wrote:
>> I built the "crownbay" (not crownbay-noemgd) image as outlined in the
>> E660 development kit (link
>> http://www.yoctoproject.org/download/bsp/intel-atom-processor-e660-intel-platform-controller-hub-eg20t-development-kit-1)
>>
>> I used poky-edison-6.0.tar.bz2 and crownbay-edison-6.0.0.tar.bz2 and
>> followed the instructions (short version - extract, move, add
>> meta-intel/meta-crownbay to bblayers.conf, add MACHINE="crownbay" to
>> local.conf, bitbake core-image-sato)
>>
>> The result was the expected set of images in tmp/deploy/images
>>
>> I loop mounted the core-image-sato-crownbay.ext3 and tried to find
>> emgd.ko in the file system - I could not find it. (find output
>> attached - notice that there is no emgd.ko)
>>
>> Here is the kicker - crownbay-edison-6.0.0.tar.bz2 has a directory
>> called "binary" which contains core-image-sato-crownbay.hddimg, which
>> contains rootfs.img, which I also loop mounted and was able to find
>> the emgd.ko (however this image does not work with my hardware, I am
>> not sure why). Find output for this is also included below.
>>
>> I very much doubt that it is included as a part of the kernel, I
>> looked at the kernel's .config (in
>> tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r2/linux-crownbay-standard-build)
>> and could not find emgd there either.
>>
>> So, my questions is if I am doing something wrong? Do I need to do
>> something to get the emgd.ko to build? I am using the latest release
>> (6.0 "Edison" (released on October 17th, 2011)). Please advise.
>>
> Check out the README file in the meta-crownbay directory. There are
> instructions on integrating the EMGD driver files into the build.
>
> Jim A
>
>> Thanks
>>
>> Autif
>>
>> autif@xu:~/data/dev/yocto/emgd/tmp/deploy/images/1$ sudo find . | grep emgd
>> ./usr/lib/libemgdsrv_um.so.1.5.15.3226
>> ./usr/lib/libemgdsrv_um.so
>> ./usr/lib/libemgdglslcompiler.so.1.5.15.3226
>> ./usr/lib/libemgdPVR2D_DRIWSEGL.so
>> ./usr/lib/xorg/modules/drivers/emgd_drv.so
>> ./usr/lib/libemgdPVR2D_DRIWSEGL.so.1.5.15.3226
>> ./usr/lib/libemgdsrv_init.so
>> ./usr/lib/libemgdsrv_init.so.1.5.15.3226
>> ./usr/lib/libemgdglslcompiler.so
>> ./usr/lib/dri/emgd_dri.so
>> autif@xu:~/data/dev/yocto/emgd/tmp/deploy/images/1$
>>
>> autif@xu:~/data/dev/yocto/poky-edison-6.0/meta-intel/meta-crownbay/binary/2$
>> sudo find . | grep emgd
>> ./usr/lib/libemgdsrv_um.so
>> ./usr/lib/dri/emgd_dri.so
>> ./usr/lib/libemgdsrv_init.so.1.5.15.3226
>> ./usr/lib/libemgdsrv_init.so
>> ./usr/lib/xorg/modules/drivers/emgd_drv.so
>> ./usr/lib/libemgdPVR2D_DRIWSEGL.so.1.5.15.3226
>> ./usr/lib/libemgdglslcompiler.so.1.5.15.3226
>> ./usr/lib/libemgdsrv_um.so.1.5.15.3226
>> ./usr/lib/libemgdPVR2D_DRIWSEGL.so
>> ./usr/lib/libemgdglslcompiler.so
>> ./lib/modules/3.0.4-yocto-standard+/kernel/drivers/gpu/drm/emgd
>> ./lib/modules/3.0.4-yocto-standard+/kernel/drivers/gpu/drm/emgd/emgd.ko
>> ./etc/rpm-postinsts/kernel-module-emgd.sh.done
>> autif@xu:~/data/dev/yocto/poky-edison-6.0/meta-intel/meta-crownbay/binary/2$
>> ___
>> 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] Where is the emgd.ko module?

[Tom Zanussi]

On Tue, 2011-12-13 at 08:13 -0800, autif khan wrote:
> I built the "crownbay" (not crownbay-noemgd) image as outlined in the
> E660 development kit (link
> http://www.yoctoproject.org/download/bsp/intel-atom-processor-e660-intel-platform-controller-hub-eg20t-development-kit-1)
> 
> I used poky-edison-6.0.tar.bz2 and crownbay-edison-6.0.0.tar.bz2 and
> followed the instructions (short version - extract, move, add
> meta-intel/meta-crownbay to bblayers.conf, add MACHINE="crownbay" to
> local.conf, bitbake core-image-sato)
> 
> The result was the expected set of images in tmp/deploy/images
> 
> I loop mounted the core-image-sato-crownbay.ext3 and tried to find
> emgd.ko in the file system - I could not find it. (find output
> attached - notice that there is no emgd.ko)
> 
> Here is the kicker - crownbay-edison-6.0.0.tar.bz2 has a directory
> called "binary" which contains core-image-sato-crownbay.hddimg, which
> contains rootfs.img, which I also loop mounted and was able to find
> the emgd.ko (however this image does not work with my hardware, I am
> not sure why). Find output for this is also included below.
> 
> I very much doubt that it is included as a part of the kernel, I
> looked at the kernel's .config (in
> tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r2/linux-crownbay-standard-build)
> and could not find emgd there either.
> 

In the .config, do you see this?:

CONFIG_DRM_EGD=m

If not, then for some reason the options in drm-emgd.cfg from the
drm-emgd feature aren't being picked up.  Let me try a build myself here
from the instructions, and see if I can reproduce the problem.

A missing emgd.ko would be a kernel build/config problem, and nothing to
do with the emgd userspace tarballs...

Tom

> So, my questions is if I am doing something wrong? Do I need to do
> something to get the emgd.ko to build? I am using the latest release
> (6.0 "Edison" (released on October 17th, 2011)). Please advise.
> 
> Thanks
> 
> Autif
> 
> autif@xu:~/data/dev/yocto/emgd/tmp/deploy/images/1$ sudo find . | grep emgd
> ./usr/lib/libemgdsrv_um.so.1.5.15.3226
> ./usr/lib/libemgdsrv_um.so
> ./usr/lib/libemgdglslcompiler.so.1.5.15.3226
> ./usr/lib/libemgdPVR2D_DRIWSEGL.so
> ./usr/lib/xorg/modules/drivers/emgd_drv.so
> ./usr/lib/libemgdPVR2D_DRIWSEGL.so.1.5.15.3226
> ./usr/lib/libemgdsrv_init.so
> ./usr/lib/libemgdsrv_init.so.1.5.15.3226
> ./usr/lib/libemgdglslcompiler.so
> ./usr/lib/dri/emgd_dri.so
> autif@xu:~/data/dev/yocto/emgd/tmp/deploy/images/1$
> 
> autif@xu:~/data/dev/yocto/poky-edison-6.0/meta-intel/meta-crownbay/binary/2$
> sudo find . | grep emgd
> ./usr/lib/libemgdsrv_um.so
> ./usr/lib/dri/emgd_dri.so
> ./usr/lib/libemgdsrv_init.so.1.5.15.3226
> ./usr/lib/libemgdsrv_init.so
> ./usr/lib/xorg/modules/drivers/emgd_drv.so
> ./usr/lib/libemgdPVR2D_DRIWSEGL.so.1.5.15.3226
> ./usr/lib/libemgdglslcompiler.so.1.5.15.3226
> ./usr/lib/libemgdsrv_um.so.1.5.15.3226
> ./usr/lib/libemgdPVR2D_DRIWSEGL.so
> ./usr/lib/libemgdglslcompiler.so
> ./lib/modules/3.0.4-yocto-standard+/kernel/drivers/gpu/drm/emgd
> ./lib/modules/3.0.4-yocto-standard+/kernel/drivers/gpu/drm/emgd/emgd.ko
> ./etc/rpm-postinsts/kernel-module-emgd.sh.done
> autif@xu:~/data/dev/yocto/poky-edison-6.0/meta-intel/meta-crownbay/binary/2$
> ___
> 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] Where is the emgd.ko module?

[Jim Abernathy]

On Tue, 2011-12-13 at 11:37 -0500, autif khan wrote:
> I think that I did. Included is an excerpt that says that I need not
> do anything except bitbake core image sato when MACHINE="crownbay".
> 
> As instructed, I followed the steps in section one (Building the
> meta-crownbay BSP layer) and ignored everything in section two
> (Special notes for building the meta-crownbay BSP layer) which
> includes instructions to patch a "crownbay-noemgd" with the Intel
> driver.
> 
> Included below is the excerpt from the README. Is there a section that
> I am overlooking?
> 
> Thanks
> 
> Autif
> 
> The meta-crownbay layer makes use of the proprietary Intel EMGD
> userspace drivers when building the "crownbay" machine (but not when
> building the "crownbay-noemgd" machine).  If you got the BSP from the
> 'BSP Downloads' section of the Yocto website, the EMGD binaries needed
> to perform the build will already be present in the BSP, located in
> the meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin-1.8
> directory, and you can ignore the rest of this section.
> 
If you use the prebuilt binaries they have EMGD already included. I had
to download and install the EMGD  before baking it all, as mentioned in
the README below:

Downloading and extracting the binaries using the EMGD Linux tarball


The first step of the process is to download the EMGD 1.8 Driver.
Here is the current link to the URL from which it can be downloaded:

http://edc.intel.com/Software/Downloads/EMGD/

In the Download Now tab, select:

Intel® architecture-based product: Linux Tar Ball
Operating System: MeeGo* 1.2 IVI Linux* (kernel 2.6.37, X.server 1.9,
Mesa 7.9)

That will give you a large .tgz file:

Lin_EMGD_1_8_RC_2032.tgz

Extract the files in the tar file, which will in turn give you a
directory named IEMGD_HEAD_Linux.

The binaries are contained in an rpm file; you can extract the
binaries from the rpm file using rpm2cpio and cpio:

$ cd IEMGD_HEAD_Linux/MeeGo1.2
$ rpm2cpio emgd-bin-2032-1.6.i586.rpm > emgd-bin-2032-1.6.i586.cpio
$ mkdir extracted; cd extracted
$ cpio -idv < ../emgd-bin-2032-1.6.i586.cpio

Finally, you can copy the xorg-xserver binaries to the
emgd-driver-bin-1.8 directory in meta-intel/common:

$ cp -a usr/lib
meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin-1.8

You also need to copy the IEMGD License.txt file to the same directory:

$ cp IEMGD_HEAD_Linux/License/License.txt
meta-intel/common/recipes/xorg-xserver/emgd-driver-bin-1.8

At this point, you should be able to build meta-crownbay images as
usual.

> 
> On Tue, Dec 13, 2011 at 11:28 AM, Jim Abernathy  wrote:
> > On Tue, 2011-12-13 at 11:13 -0500, autif khan wrote:
> >> I built the "crownbay" (not crownbay-noemgd) image as outlined in the
> >> E660 development kit (link
> >> http://www.yoctoproject.org/download/bsp/intel-atom-processor-e660-intel-platform-controller-hub-eg20t-development-kit-1)
> >>
> >> I used poky-edison-6.0.tar.bz2 and crownbay-edison-6.0.0.tar.bz2 and
> >> followed the instructions (short version - extract, move, add
> >> meta-intel/meta-crownbay to bblayers.conf, add MACHINE="crownbay" to
> >> local.conf, bitbake core-image-sato)
> >>
> >> The result was the expected set of images in tmp/deploy/images
> >>
> >> I loop mounted the core-image-sato-crownbay.ext3 and tried to find
> >> emgd.ko in the file system - I could not find it. (find output
> >> attached - notice that there is no emgd.ko)
> >>
> >> Here is the kicker - crownbay-edison-6.0.0.tar.bz2 has a directory
> >> called "binary" which contains core-image-sato-crownbay.hddimg, which
> >> contains rootfs.img, which I also loop mounted and was able to find
> >> the emgd.ko (however this image does not work with my hardware, I am
> >> not sure why). Find output for this is also included below.
> >>
> >> I very much doubt that it is included as a part of the kernel, I
> >> looked at the kernel's .config (in
> >> tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r2/linux-crownbay-standard-build)
> >> and could not find emgd there either.
> >>
> >> So, my questions is if I am doing something wrong? Do I need to do
> >> something to get the emgd.ko to build? I am using the latest release
> >> (6.0 "Edison" (released on October 17th, 2011)). Please advise.
> >>
> > Check out the README file in the meta-crownbay directory. There are
> > instructions on integrating the EMGD driver files into the build.
> >
> > Jim A
> >
> >> Thanks
> >>
> >> Autif
> >>
> >> autif@xu:~/data/dev/yocto/emgd/tmp/deploy/images/1$ sudo find . | grep emgd
> >> ./usr/lib/libemgdsrv_um.so.1.5.15.3226
> >> ./usr/lib/libemgdsrv_um.so
> >> ./usr/lib/libemgdglslcompiler.so.1.5.15.3226
> >> ./usr/lib/libemgdPVR2D_DRIWSEGL.so
> >> ./usr/lib/xorg/modules/drivers/emgd_drv.so
> >> ./usr/lib/libemgdPVR2D_DRIWSEGL.so.1.5.15.3226
> >> ./usr/lib/libemgdsr

[yocto] Minutes: Yocto Technical Team Meeting - Tuesday, December 13, 2011 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

[Saul Wold]

Attendees:
Sean, Beth, Tom, Richard, Darren, Bruce, Dave, Joshua, Mark, ScottR, Saul

New Action Item List:
* Action item Review - 5 min
  1. Mark will review unsorted features from Wind River team and try to 
have them scheduled (WIP)


Focus of the current week:
  M1 Stabilization, M2 Planning

Agenda:

* Opens collection - 5 min (Saul)
  RP: Autobuild & Bugs

* Opens - 10 min
 - Folded into 1.2 Status

* Yocto 1.0.2 and 1.1.1 point release update - 10 min (Josh/Beth)
  - Build issue on OpenSuse 11.04 with Host Intrusion
  - QA ran and found 7 problems, 1 will need to be fixed.
- DISTRO_VERSION needs to be updated
  *  AR Josh: Email to CCB to review QA Result
  - 1.1.1 Status
- CCB will review size of patch set in New Year
- 1.1.1rc1 will be built before Christmas
- QA will do a run between Christmas and New Years

* Yocto 1.2 M1 Status (features development) - 10 min (Song/Beth)
  https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.2_Status
  - We are coming up on M1 RC2 with a couple of issues related
QT, the Auto builder and sanity testing, Saul will pull and
get a test spin rolling

  - Richard has been clearing the Patch Queue and fixing issues with
the build, we need to do a better job of testing patches
  - M1 Review:
- All P1 Features made it into M1
  - Hob2 work occured in Hob2 branch
  - Self-Hosted Build Appliance can build almost all of world
under 6 recipes failures, with pending fixes
- Many P2 Features were also completed
  - Autoconf/Automake
  - Video Acceleration
  - Meta-Intel Config Update
  - Package History
  - Autobuilder sstate option
  - BuildStats Memory Measurements
- Other M1 P2 Items that are close and will be delivered soon
  - GTK/Directfb (in Master now)
  - Sanity Check for Userspace (Pending fixing errors discovered by
said sanity checks)
  - Host Intrusion (M2 Planning)
  - EFI (in Master now, bug fixes pending)
  - Grub for Syslinux Change (pending)

   - M2 Planning, please send Song Update as well as update Bug/Enhancment
   - Reveiwed Bug WDD and Bug Count

* Action item Review - 5 min
  1. Mark will review unsorted features from Wind River team and try to 
have them scheduled (WIP)

  2. Saul to look at RC1 image for issues with dbus
  3. Saul to pull Qt, Qemu and useradd patches into M1 Rc2 and get spin

* Weekly team sharing (20 min)

Scott R:
 Shared State documentation, Virtual Machine Appliance (Fedora Hosted), 
Webcast, Waiting for feedback from RP on Sstate

Mark: Windriver stuff
Joshua: Stable release, Planning M2 Tasks
Dave: Managing
Bruce: Working on M1 Late M2 Planning, Discussing with Tom/Darren Config 
Options, Standalone Linux-Yocto tree build

Darren: Meta-Tiny Update, Intel BSP Support Work, Bug Fixing
Richard: Chasing Autobuilder failures, sstate, patch merge Queue, Bug 
counte reduction

Tom: Intel BSP  work, Updated EMGD, Kernel Usability
Beth: License Stuff in Master, Milestone release, Stable 1.0.2 Release, 
Autobuilder fixes

Sean: Mentor
Saul: Non-Gplv3 Self Hosted, Bug investigation, Patch queue



___
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 mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] HOB usage

[Joshua Lock]

On 11/12/11 21:20, Sathishkumar Duraisamy wrote:
> Hi,
> 
> Today, I tried to reproduce the problem and magically, today, hob
> works as expected.  So, I started once again with new config, and
> again I tried to reproduce the problem. But the problem exists.
> 
> The reason for this, once we select our images in the
> edit->preference, it writes our preference in the file hob-post.conf
> file. But it doesn't parses it again unless we are restarting the hob
> again.

Hmm, your analysis seems sound enough. We do call the setVariable
command on the cooker which I had expected to ensure the variable was
set appropriately without a reparse.

We can easily add a patch to trigger a reparse once IMAGE_FSTYPES is
changed, as we do with several of the other preference values.

Something like:

joshual@shamshir:~/Projects/Yocto/poky-stable [josh/edison *]
$ git diff
diff --git a/bitbake/lib/bb/ui/crumbs/hobprefs.py
b/bitbake/lib/bb/ui/crumbs/hob
index 5dfb0e6..3f6f128 100644
--- a/bitbake/lib/bb/ui/crumbs/hobprefs.py
+++ b/bitbake/lib/bb/ui/crumbs/hobprefs.py
@@ -39,6 +39,7 @@ class HobPrefs(gtk.Dialog):
 self.selected_image_types =
handler.remove_image_output_type(ot)

 self.configurator.setConfVar('IMAGE_FSTYPES', "%s" % "
".join(self.sele
+self.reload_required = True

 def sdk_machine_combo_changed_cb(self, combo, handler):
 sdk_mach = combo.get_active_text()

Cheers,
Joshua
-- 
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] The role of "distro" and "image"

[Darren Hart]

I'm trying to wrap up my work on meta-tiny and integrate it into poky
proper. I'm having some difficulty drawing a line between the
responsibility of the distro definition versus that of the image definition.

For example, if I define a distro which uses tmpdevfs (no udev or mdev)
and specifies KMACHINE=yocto/standard/tiny to build the tiny variant of
the linux-yocto kernel, and customizes the busybox build to leave out
various things - would it make sense for someone to then try to build
core-image-sato with it? It doesn't to me, but nothing prevents the user
from doing that (other than a likely build failure).

So what does the distro define and what does the image define?

Digging around in conf/distro for meta and meta-yocto, I see things like
naming convention, additional dependencies, choice of toolchain and
libc, source mirrors, default virtual providers, etc.

The image seems to basically define the package list for the image as
well as the format of the rootfs and boot media.

If I understand this correctly, a new "tiny" distro definition would
change the preferred linux-yocto provider to a linux-yocto-tiny recipe
(which would in turn specify the default KMACHINE/KTYPE as well, the
TCLIBC, DISTRO_FEATURES_LIBC, and some naming rules.

I currently define a new task-core-tiny.bb to reset some
MACHINE_ESSENTIAL bits (qemu pulls in more than is necessary for tiny)
and redefine the REDEPENDS for the image. I believe I could do this
instead with assignments in the new distro definition and reuse
task-core-boot.bb.

As for images, I might be able to reuse core-image-minimal - but it
oddly contains "${POKY_EXTRA_INSTALL}" in the IMAGE_INSTALL. Since
core-image-minimal.bb is defined in oe-core and POKY is a distro notion
of meta-yocto, this contributes to my confusion over distro vs. image.

I'd appreciate some discussion to help me clarify where these lines
should be.

Thanks,


-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] The role of "distro" and "image"

[Joshua Lock]

On 13/12/11 12:23, Darren Hart wrote:
> I'm trying to wrap up my work on meta-tiny and integrate it into poky
> proper. I'm having some difficulty drawing a line between the
> responsibility of the distro definition versus that of the image definition.
> 
> For example, if I define a distro which uses tmpdevfs (no udev or mdev)
> and specifies KMACHINE=yocto/standard/tiny to build the tiny variant of
> the linux-yocto kernel, and customizes the busybox build to leave out
> various things - would it make sense for someone to then try to build
> core-image-sato with it? It doesn't to me, but nothing prevents the user
> from doing that (other than a likely build failure).

These all sounds like policy (and therefore distro) decisions to me. As
with much of our system there's no hard and fast rule but this certainly
sounds like a distro to me.

I think it's perfectly reasonable to assume that you can't build every
image you find in the wild for every distro configuration you create.

> 
> So what does the distro define and what does the image define?

Distro defines the build configuration policy, image defines image contents.

You shouldn't set anything in the image definition which affects how
things are built as the packages can then be used in another image.

> 
> Digging around in conf/distro for meta and meta-yocto, I see things like
> naming convention, additional dependencies, choice of toolchain and
> libc, source mirrors, default virtual providers, etc.

*nod*

> 
> The image seems to basically define the package list for the image as
> well as the format of the rootfs and boot media.

*nod* though arguably the latter 3 are likely poked elsewhere also.

> If I understand this correctly, a new "tiny" distro definition would
> change the preferred linux-yocto provider to a linux-yocto-tiny recipe
> (which would in turn specify the default KMACHINE/KTYPE as well, the
> TCLIBC, DISTRO_FEATURES_LIBC, and some naming rules.

Yes!

> I currently define a new task-core-tiny.bb to reset some
> MACHINE_ESSENTIAL bits (qemu pulls in more than is necessary for tiny)
> and redefine the REDEPENDS for the image. I believe I could do this
> instead with assignments in the new distro definition and reuse
> task-core-boot.bb.

Seems like a good approach.

> As for images, I might be able to reuse core-image-minimal - but it
> oddly contains "${POKY_EXTRA_INSTALL}" in the IMAGE_INSTALL. Since
> core-image-minimal.bb is defined in oe-core and POKY is a distro notion
> of meta-yocto, this contributes to my confusion over distro vs. image.
> 
> I'd appreciate some discussion to help me clarify where these lines
> should be.

That's just a stray variable that has yet to be properly renamed by the
looks of it.

It sounds to me like your understanding is correct and this variable has
just thrown you for a loop.

Cheers,
Joshua
-- 
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] The role of "distro" and "image"

[Khem Raj]

On Tue, Dec 13, 2011 at 12:36 PM, Joshua Lock  wrote:
>
>> As for images, I might be able to reuse core-image-minimal - but it
>> oddly contains "${POKY_EXTRA_INSTALL}" in the IMAGE_INSTALL. Since
>> core-image-minimal.bb is defined in oe-core and POKY is a distro notion
>> of meta-yocto, this contributes to my confusion over distro vs. image.
>>
>> I'd appreciate some discussion to help me clarify where these lines
>> should be.
>
> That's just a stray variable that has yet to be properly renamed by the
> looks of it.

yes there was a patch to rename that to IMAGE_EXTRA_INSTALL or
COREIMAGE_EXTRA_INSTALL
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] The role of "distro" and "image"

[Richard Purdie]

On Tue, 2011-12-13 at 12:23 -0800, Darren Hart wrote:
> I'm trying to wrap up my work on meta-tiny and integrate it into poky
> proper. I'm having some difficulty drawing a line between the
> responsibility of the distro definition versus that of the image definition.
> 
> For example, if I define a distro which uses tmpdevfs (no udev or mdev)
> and specifies KMACHINE=yocto/standard/tiny to build the tiny variant of
> the linux-yocto kernel, and customizes the busybox build to leave out
> various things - would it make sense for someone to then try to build
> core-image-sato with it? It doesn't to me, but nothing prevents the user
> from doing that (other than a likely build failure).
> 
> So what does the distro define and what does the image define?

I think Joshua's response is in line with what I'm thinking. Distro is
where all the policy is specified. The image is just a list of pieces of
software to include, its not meant to be much more than that.

> Digging around in conf/distro for meta and meta-yocto, I see things like
> naming convention, additional dependencies, choice of toolchain and
> libc, source mirrors, default virtual providers, etc.

Right, all of this is "policy" at some level or another.

> The image seems to basically define the package list for the image as
> well as the format of the rootfs and boot media.

The latter is often machine specific. There are some images which
specify those things but they're a minority.

> If I understand this correctly, a new "tiny" distro definition would
> change the preferred linux-yocto provider to a linux-yocto-tiny recipe
> (which would in turn specify the default KMACHINE/KTYPE as well, the
> TCLIBC, DISTRO_FEATURES_LIBC, and some naming rules.

Yes, you'd inherit something for the base config and then customise it.

> I currently define a new task-core-tiny.bb to reset some
> MACHINE_ESSENTIAL bits (qemu pulls in more than is necessary for tiny)
> and redefine the REDEPENDS for the image. I believe I could do this
> instead with assignments in the new distro definition and reuse
> task-core-boot.bb.

The latter reuse of task-core-boot would be ideal. If that can't work
I'd be interested to see why and if we couldn't enhance it so it could
work.

> As for images, I might be able to reuse core-image-minimal - but it
> oddly contains "${POKY_EXTRA_INSTALL}" in the IMAGE_INSTALL. Since
> core-image-minimal.bb is defined in oe-core and POKY is a distro notion
> of meta-yocto, this contributes to my confusion over distro vs. image.

This is a bug and there are some patches out there to turn it into
COREIMAGE_EXTRA_INSTALL. Its a feature of the core-image.bbclass
(formerly poky.bbclass, hence the name confusion).

Not all images can be built with a given distro, our base config is
rather ride ranging though for obvious reasons. You could "enforce" this
by adding some anonymous python to the distro which does something like:

if inherits("image") and PN != core-image-minimal:
raise SkipPackage("Image PN not compatible with DISTRO=XXX")

Cheers,

Richard


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] The role of "distro" and "image"

[Chris Larson]

On Tue, Dec 13, 2011 at 2:36 PM, Richard Purdie
 wrote:
> Not all images can be built with a given distro, our base config is
> rather ride ranging though for obvious reasons. You could "enforce" this
> by adding some anonymous python to the distro which does something like:
>
> if inherits("image") and PN != core-image-minimal:
>    raise SkipPackage("Image PN not compatible with DISTRO=XXX")

This is a case where one is best 'controlling' this via policy, not
mechanism, in my opinion. This sort of arbitrary technical limitation
tends to be foolish and often bites someone somewhere down the line.
I'm sure you just wanted to note how it could be done, not recommend
that it should be done, but I thought it should be made clear. I
wouldn't recommend that anyone do this unless there is an extremely
good reason for it.
-- 
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] kernel-tools failure for linux-yoctort_3.0.bb for poky/edison branch.

[Bodke, Kishore K]

Hi,

I get failure for the linux-yoctort_3.0.bb file for the poky Edison branch.
Darren told that it was fixed and merged to master.

I wanted to bring to the list about this error message.

ERROR: Function 'do_kernel_configme' failed (see 
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
 for further information)
ERROR: Logfile of failure stored in: 
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
Log data follows:
| [INFO] doing kernel configme
| [INFO] Branch yocto/standard/preempt-rt/base used by common-pc-preempt-rt.scc
| [INFO] collecting configs in ./meta/meta-series
| mv: cannot stat 
`/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/linux-crystalforest-preempt-rt-build/.tmp.config*':
 No such file or directory
| creation of pre-processed config data failed
| config of yocto/standard/preempt-rt/base (common-pc-preempt-rt.scc) failed
| ERROR: Function 'do_kernel_configme' failed (see 
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
 for further information)
NOTE: package 
linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1:
 task do_kernel_configme: Failed
ERROR: Task 716 
(/usr/local/src/yocto_1_1_release/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb,
 do_kernel_configme) failed with exit code '1'
Waiting for 7 active tasks to finish:
0: acl-native-2.2.51-r2 do_configure (pid 12164)
1: elfutils-native-0.148-r3 do_install (pid 19851)
2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)
3: font-util-native-1.2.0-r2.1 do_configure (pid 14632)
4: bison-native-2.5-r1 do_configure (pid 20206)
5: dbus-native-1.4.12-r0 do_configure (pid 20209)
6: opensp-native-1.5-r2 do_configure (pid 20213)
Waiting for 6 active tasks to finish:
0: acl-native-2.2.51-r2 do_configure (pid 12164)
1: elfutils-native-0.148-r3 do_install (pid 19851)
2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)
3: font-util-native-1.2.0-r2.1 do_configure (pid 14632)
4: bison-native-2.5-r1 do_configure (pid 20206)
5: dbus-native-1.4.12-r0 do_configure (pid 20209)
NOTE: package opensp-native-1.5-r2: task do_configure: Succeeded
Waiting for 5 active tasks to finish:
0: acl-native-2.2.51-r2 do_configure (pid 12164)
1: elfutils-native-0.148-r3 do_install (pid 19851)
2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)
3: bison-native-2.5-r1 do_configure (pid 20206)
4: dbus-native-1.4.12-r0 do_configure (pid 20209)
NOTE: package font-util-native-1.2.0-r2.1: task do_configure: Succeeded
Waiting for 4 active tasks to finish:
0: acl-native-2.2.51-r2 do_configure (pid 12164)
1: elfutils-native-0.148-r3 do_install (pid 19851)
2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)
3: bison-native-2.5-r1 do_configure (pid 20206)
NOTE: package dbus-native-1.4.12-r0: task do_configure: Succeeded
Waiting for 3 active tasks to finish:
0: elfutils-native-0.148-r3 do_install (pid 19851)
1: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)
2: bison-native-2.5-r1 do_configure (pid 20206)
NOTE: package acl-native-2.2.51-r2: task do_configure: Succeeded
Waiting for 2 active tasks to finish:
0: elfutils-native-0.148-r3 do_install (pid 19851)
1: bison-native-2.5-r1 do_configure (pid 20206)
NOTE: package kbproto-native-1_1.0.5-r0: task do_configure: Succeeded
Waiting for 1 active tasks to finish:
0: bison-native-2.5-r1 do_configure (pid 20206)
NOTE: package elfutils-native-0.148-r3: task do_install: Succeeded
NOTE: package bison-native-2.5-r1: task do_configure: Succeeded
ERROR: 
'/usr/local/src/yocto_1_1_release/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb'
 failed

Thanks
Kishore.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Error in routerstation pro machine.conf?

[David Smoot]

I'm still very new and very clueless but I humbly submit what looks like a bug 
to me..

"routerstationpro.conf" in meta-yocto/conf/machine/ lists machine features the 
hardware does not have.

http://www.ubnt.com/wiki/RouterStation_Pro lists the hardware specs and it 
lacks a display adapter (hence no screen nor keyboard) and it also lacks USB 
slave hardware (hence no point in usbgadget).

File a bugzilla report or is there a reason for that configuration?


David

David Smoot
davidsm...@gmail.com



___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] kernel-tools failure for linux-yoctort_3.0.bb for poky/edison branch.

[Bruce Ashfield]

On 11-12-13 5:50 PM, Bodke, Kishore K wrote:

Hi,

I get failure for the linux-yoctort_3.0.bb file for the poky Edison branch.

Darren told that it was fixed and merged to master.


This shouldn't be happening on edison at all. The changes to the
kernel recipes/tools to use the merge_config.sh should never have
showed up in edison. That's yocto 1.2 development work.

So the fix for this is to find out what leaked into edison and
revert it. I'll have a look at that later tonight.

Bruce



I wanted to bring to the list about this error message.

ERROR: Function 'do_kernel_configme' failed (see
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
for further information)

ERROR: Logfile of failure stored in:
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502

Log data follows:

| [INFO] doing kernel configme

| [INFO] Branch yocto/standard/preempt-rt/base used by
common-pc-preempt-rt.scc

| [INFO] collecting configs in ./meta/meta-series

| mv: cannot stat
`/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/linux-crystalforest-preempt-rt-build/.tmp.config*':
No such file or directory

| creation of pre-processed config data failed

| config of yocto/standard/preempt-rt/base (common-pc-preempt-rt.scc) failed

| ERROR: Function 'do_kernel_configme' failed (see
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
for further information)

NOTE: package
linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1:
task do_kernel_configme: Failed

ERROR: Task 716
(/usr/local/src/yocto_1_1_release/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb,
do_kernel_configme) failed with exit code '1'

Waiting for 7 active tasks to finish:

0: acl-native-2.2.51-r2 do_configure (pid 12164)

1: elfutils-native-0.148-r3 do_install (pid 19851)

2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)

3: font-util-native-1.2.0-r2.1 do_configure (pid 14632)

4: bison-native-2.5-r1 do_configure (pid 20206)

5: dbus-native-1.4.12-r0 do_configure (pid 20209)

6: opensp-native-1.5-r2 do_configure (pid 20213)

Waiting for 6 active tasks to finish:

0: acl-native-2.2.51-r2 do_configure (pid 12164)

1: elfutils-native-0.148-r3 do_install (pid 19851)

2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)

3: font-util-native-1.2.0-r2.1 do_configure (pid 14632)

4: bison-native-2.5-r1 do_configure (pid 20206)

5: dbus-native-1.4.12-r0 do_configure (pid 20209)

NOTE: package opensp-native-1.5-r2: task do_configure: Succeeded

Waiting for 5 active tasks to finish:

0: acl-native-2.2.51-r2 do_configure (pid 12164)

1: elfutils-native-0.148-r3 do_install (pid 19851)

2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)

3: bison-native-2.5-r1 do_configure (pid 20206)

4: dbus-native-1.4.12-r0 do_configure (pid 20209)

NOTE: package font-util-native-1.2.0-r2.1: task do_configure: Succeeded

Waiting for 4 active tasks to finish:

0: acl-native-2.2.51-r2 do_configure (pid 12164)

1: elfutils-native-0.148-r3 do_install (pid 19851)

2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)

3: bison-native-2.5-r1 do_configure (pid 20206)

NOTE: package dbus-native-1.4.12-r0: task do_configure: Succeeded

Waiting for 3 active tasks to finish:

0: elfutils-native-0.148-r3 do_install (pid 19851)

1: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)

2: bison-native-2.5-r1 do_configure (pid 20206)

NOTE: package acl-native-2.2.51-r2: task do_configure: Succeeded

Waiting for 2 active tasks to finish:

0: elfutils-native-0.148-r3 do_install (pid 19851)

1: bison-native-2.5-r1 do_configure (pid 20206)

NOTE: package kbproto-native-1_1.0.5-r0: task do_configure: Succeeded

Waiting for 1 active tasks to finish:

0: bison-native-2.5-r1 do_configure (pid 20206)

NOTE: package elfutils-native-0.148-r3: task do_install: Succeeded

NOTE: package bison-native-2.5-r1: task do_configure: Succeeded

ERROR:
'/usr/local/src/yocto_1_1_release/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb'
failed

Thanks

Kishore.



___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] kernel-tools failure for linux-yoctort_3.0.bb for poky/edison branch.

[Darren Hart]

On 12/13/2011 03:05 PM, Bruce Ashfield wrote:
> On 11-12-13 5:50 PM, Bodke, Kishore K wrote:
>> Hi,
>>
>> I get failure for the linux-yoctort_3.0.bb file for the poky Edison branch.
>>
>> Darren told that it was fixed and merged to master.
> 
> This shouldn't be happening on edison at all. The changes to the
> kernel recipes/tools to use the merge_config.sh should never have
> showed up in edison. That's yocto 1.2 development work.
> 
> So the fix for this is to find out what leaked into edison and
> revert it. I'll have a look at that later tonight.

No no. Kishore is using meta-kernel-dev. As such he is getting the
latest linux-yocto repository and SRC_REVs. The question, I think, is
really why isn't the kern-tools-native bbappend from meta-kernel-dev
doing this for him.

--
Darren

> 
> Bruce
> 
>>
>> I wanted to bring to the list about this error message.
>>
>> ERROR: Function 'do_kernel_configme' failed (see
>> /usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
>> for further information)
>>
>> ERROR: Logfile of failure stored in:
>> /usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
>>
>> Log data follows:
>>
>> | [INFO] doing kernel configme
>>
>> | [INFO] Branch yocto/standard/preempt-rt/base used by
>> common-pc-preempt-rt.scc
>>
>> | [INFO] collecting configs in ./meta/meta-series
>>
>> | mv: cannot stat
>> `/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/linux-crystalforest-preempt-rt-build/.tmp.config*':
>> No such file or directory
>>
>> | creation of pre-processed config data failed
>>
>> | config of yocto/standard/preempt-rt/base (common-pc-preempt-rt.scc) failed
>>
>> | ERROR: Function 'do_kernel_configme' failed (see
>> /usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
>> for further information)
>>
>> NOTE: package
>> linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1:
>> task do_kernel_configme: Failed
>>
>> ERROR: Task 716
>> (/usr/local/src/yocto_1_1_release/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb,
>> do_kernel_configme) failed with exit code '1'
>>
>> Waiting for 7 active tasks to finish:
>>
>> 0: acl-native-2.2.51-r2 do_configure (pid 12164)
>>
>> 1: elfutils-native-0.148-r3 do_install (pid 19851)
>>
>> 2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)
>>
>> 3: font-util-native-1.2.0-r2.1 do_configure (pid 14632)
>>
>> 4: bison-native-2.5-r1 do_configure (pid 20206)
>>
>> 5: dbus-native-1.4.12-r0 do_configure (pid 20209)
>>
>> 6: opensp-native-1.5-r2 do_configure (pid 20213)
>>
>> Waiting for 6 active tasks to finish:
>>
>> 0: acl-native-2.2.51-r2 do_configure (pid 12164)
>>
>> 1: elfutils-native-0.148-r3 do_install (pid 19851)
>>
>> 2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)
>>
>> 3: font-util-native-1.2.0-r2.1 do_configure (pid 14632)
>>
>> 4: bison-native-2.5-r1 do_configure (pid 20206)
>>
>> 5: dbus-native-1.4.12-r0 do_configure (pid 20209)
>>
>> NOTE: package opensp-native-1.5-r2: task do_configure: Succeeded
>>
>> Waiting for 5 active tasks to finish:
>>
>> 0: acl-native-2.2.51-r2 do_configure (pid 12164)
>>
>> 1: elfutils-native-0.148-r3 do_install (pid 19851)
>>
>> 2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)
>>
>> 3: bison-native-2.5-r1 do_configure (pid 20206)
>>
>> 4: dbus-native-1.4.12-r0 do_configure (pid 20209)
>>
>> NOTE: package font-util-native-1.2.0-r2.1: task do_configure: Succeeded
>>
>> Waiting for 4 active tasks to finish:
>>
>> 0: acl-native-2.2.51-r2 do_configure (pid 12164)
>>
>> 1: elfutils-native-0.148-r3 do_install (pid 19851)
>>
>> 2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)
>>
>> 3: bison-native-2.5-r1 do_configure (pid 20206)
>>
>> NOTE: package dbus-native-1.4.12-r0: task do_configure: Succeeded
>>
>> Waiting for 3 active tasks to finish:
>>
>> 0: elfutils-native-0.148-r3 do_install (pid 19851)
>>
>> 1: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)
>>
>> 2: bison-native-2.5-r1 do_configure (pid 20206)
>>
>> NOTE: package acl-native-2.2.51-r2: task do_configure: Succeeded
>>
>> Waiting for 2 active tasks to finish:
>>
>> 0: elfutils-native-0.148-r3 do_install (pid 19851)
>>
>> 1: bison-native-2.5-r1 do_configure (pid 20206)
>>
>> NOTE: package kbproto-native-1_1.0.5-r0: task do_configure: Succeeded
>>
>> Waiting for 1 active tasks to finish:
>>
>> 0: bison-native-2.5-r1 do_configure (

Re: [yocto] kernel-tools failure for linux-yoctort_3.0.bb for poky/edison branch.

[Bodke, Kishore K]

Yeah.  I am using local bare clone for the linux-yocto-3.0 and using 
poky-extras/meta-kernel-dev in my bblayers.conf for my build.
Sorry for not mentioning this before.

Thanks
Kishore.

-Original Message-
From: Hart, Darren 
Sent: Tuesday, December 13, 2011 3:15 PM
To: Bruce Ashfield
Cc: Bodke, Kishore K; yocto@yoctoproject.org
Subject: Re: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
branch.

On 12/13/2011 03:05 PM, Bruce Ashfield wrote:
> On 11-12-13 5:50 PM, Bodke, Kishore K wrote:
>> Hi,
>>
>> I get failure for the linux-yoctort_3.0.bb file for the poky Edison branch.
>>
>> Darren told that it was fixed and merged to master.
> 
> This shouldn't be happening on edison at all. The changes to the
> kernel recipes/tools to use the merge_config.sh should never have
> showed up in edison. That's yocto 1.2 development work.
> 
> So the fix for this is to find out what leaked into edison and
> revert it. I'll have a look at that later tonight.

No no. Kishore is using meta-kernel-dev. As such he is getting the
latest linux-yocto repository and SRC_REVs. The question, I think, is
really why isn't the kern-tools-native bbappend from meta-kernel-dev
doing this for him.

--
Darren

> 
> Bruce
> 
>>
>> I wanted to bring to the list about this error message.
>>
>> ERROR: Function 'do_kernel_configme' failed (see
>> /usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
>> for further information)
>>
>> ERROR: Logfile of failure stored in:
>> /usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
>>
>> Log data follows:
>>
>> | [INFO] doing kernel configme
>>
>> | [INFO] Branch yocto/standard/preempt-rt/base used by
>> common-pc-preempt-rt.scc
>>
>> | [INFO] collecting configs in ./meta/meta-series
>>
>> | mv: cannot stat
>> `/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/linux-crystalforest-preempt-rt-build/.tmp.config*':
>> No such file or directory
>>
>> | creation of pre-processed config data failed
>>
>> | config of yocto/standard/preempt-rt/base (common-pc-preempt-rt.scc) failed
>>
>> | ERROR: Function 'do_kernel_configme' failed (see
>> /usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
>> for further information)
>>
>> NOTE: package
>> linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1:
>> task do_kernel_configme: Failed
>>
>> ERROR: Task 716
>> (/usr/local/src/yocto_1_1_release/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb,
>> do_kernel_configme) failed with exit code '1'
>>
>> Waiting for 7 active tasks to finish:
>>
>> 0: acl-native-2.2.51-r2 do_configure (pid 12164)
>>
>> 1: elfutils-native-0.148-r3 do_install (pid 19851)
>>
>> 2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)
>>
>> 3: font-util-native-1.2.0-r2.1 do_configure (pid 14632)
>>
>> 4: bison-native-2.5-r1 do_configure (pid 20206)
>>
>> 5: dbus-native-1.4.12-r0 do_configure (pid 20209)
>>
>> 6: opensp-native-1.5-r2 do_configure (pid 20213)
>>
>> Waiting for 6 active tasks to finish:
>>
>> 0: acl-native-2.2.51-r2 do_configure (pid 12164)
>>
>> 1: elfutils-native-0.148-r3 do_install (pid 19851)
>>
>> 2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)
>>
>> 3: font-util-native-1.2.0-r2.1 do_configure (pid 14632)
>>
>> 4: bison-native-2.5-r1 do_configure (pid 20206)
>>
>> 5: dbus-native-1.4.12-r0 do_configure (pid 20209)
>>
>> NOTE: package opensp-native-1.5-r2: task do_configure: Succeeded
>>
>> Waiting for 5 active tasks to finish:
>>
>> 0: acl-native-2.2.51-r2 do_configure (pid 12164)
>>
>> 1: elfutils-native-0.148-r3 do_install (pid 19851)
>>
>> 2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)
>>
>> 3: bison-native-2.5-r1 do_configure (pid 20206)
>>
>> 4: dbus-native-1.4.12-r0 do_configure (pid 20209)
>>
>> NOTE: package font-util-native-1.2.0-r2.1: task do_configure: Succeeded
>>
>> Waiting for 4 active tasks to finish:
>>
>> 0: acl-native-2.2.51-r2 do_configure (pid 12164)
>>
>> 1: elfutils-native-0.148-r3 do_install (pid 19851)
>>
>> 2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)
>>
>> 3: bison-native-2.5-r1 do_configure (pid 20206)
>>
>> NOTE: package dbus-native-1.4.12-r0: task do_configure: Succeeded
>>
>> Waiting for 3 active tasks to finish:
>>
>> 0: elfutils-native-0.148-r3 do_install (pid 19851)
>>
>> 1: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)
>>
>> 2: bison-nat

Re: [yocto] kernel-tools failure for linux-yoctort_3.0.bb for poky/edison branch.

[Bruce Ashfield]

On 11-12-13 6:17 PM, Bodke, Kishore K wrote:

Yeah.  I am using local bare clone for the linux-yocto-3.0 and using 
poky-extras/meta-kernel-dev in my bblayers.conf for my build.
Sorry for not mentioning this before.


Aha. This is completely different then. As Darren mentioned, the bbappend
should be getting the latest tools, I can look into that.

But to be clear, is this an edison branch + meta-kernel-dev ? That
will cause problems at some point (and I'm not sure if that is what
is happening here yet), since recipe updates to use the new tools
wouldn't be reflected in that branch while you are fed the new tools.

Cheers,

Bruce



Thanks
Kishore.

-Original Message-
From: Hart, Darren
Sent: Tuesday, December 13, 2011 3:15 PM
To: Bruce Ashfield
Cc: Bodke, Kishore K; yocto@yoctoproject.org
Subject: Re: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
branch.

On 12/13/2011 03:05 PM, Bruce Ashfield wrote:

On 11-12-13 5:50 PM, Bodke, Kishore K wrote:

Hi,

I get failure for the linux-yoctort_3.0.bb file for the poky Edison branch.

Darren told that it was fixed and merged to master.


This shouldn't be happening on edison at all. The changes to the
kernel recipes/tools to use the merge_config.sh should never have
showed up in edison. That's yocto 1.2 development work.

So the fix for this is to find out what leaked into edison and
revert it. I'll have a look at that later tonight.


No no. Kishore is using meta-kernel-dev. As such he is getting the
latest linux-yocto repository and SRC_REVs. The question, I think, is
really why isn't the kern-tools-native bbappend from meta-kernel-dev
doing this for him.

--
Darren



Bruce



I wanted to bring to the list about this error message.

ERROR: Function 'do_kernel_configme' failed (see
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
for further information)

ERROR: Logfile of failure stored in:
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502

Log data follows:

| [INFO] doing kernel configme

| [INFO] Branch yocto/standard/preempt-rt/base used by
common-pc-preempt-rt.scc

| [INFO] collecting configs in ./meta/meta-series

| mv: cannot stat
`/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/linux-crystalforest-preempt-rt-build/.tmp.config*':
No such file or directory

| creation of pre-processed config data failed

| config of yocto/standard/preempt-rt/base (common-pc-preempt-rt.scc) failed

| ERROR: Function 'do_kernel_configme' failed (see
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
for further information)

NOTE: package
linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1:
task do_kernel_configme: Failed

ERROR: Task 716
(/usr/local/src/yocto_1_1_release/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb,
do_kernel_configme) failed with exit code '1'

Waiting for 7 active tasks to finish:

0: acl-native-2.2.51-r2 do_configure (pid 12164)

1: elfutils-native-0.148-r3 do_install (pid 19851)

2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)

3: font-util-native-1.2.0-r2.1 do_configure (pid 14632)

4: bison-native-2.5-r1 do_configure (pid 20206)

5: dbus-native-1.4.12-r0 do_configure (pid 20209)

6: opensp-native-1.5-r2 do_configure (pid 20213)

Waiting for 6 active tasks to finish:

0: acl-native-2.2.51-r2 do_configure (pid 12164)

1: elfutils-native-0.148-r3 do_install (pid 19851)

2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)

3: font-util-native-1.2.0-r2.1 do_configure (pid 14632)

4: bison-native-2.5-r1 do_configure (pid 20206)

5: dbus-native-1.4.12-r0 do_configure (pid 20209)

NOTE: package opensp-native-1.5-r2: task do_configure: Succeeded

Waiting for 5 active tasks to finish:

0: acl-native-2.2.51-r2 do_configure (pid 12164)

1: elfutils-native-0.148-r3 do_install (pid 19851)

2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)

3: bison-native-2.5-r1 do_configure (pid 20206)

4: dbus-native-1.4.12-r0 do_configure (pid 20209)

NOTE: package font-util-native-1.2.0-r2.1: task do_configure: Succeeded

Waiting for 4 active tasks to finish:

0: acl-native-2.2.51-r2 do_configure (pid 12164)

1: elfutils-native-0.148-r3 do_install (pid 19851)

2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)

3: bison-native-2.5-r1 do_configure (pid 20206)

NOTE: package dbus-native-1.4.12-r0: task do_confi

Re: [yocto] kernel-tools failure for linux-yoctort_3.0.bb for poky/edison branch.

[Bodke, Kishore K]

Yes. 
Its with poky Edison with poky-extras/meta-kernel-dev master branch I am using 
for my build.

Thanks
Kishore.

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] 
Sent: Tuesday, December 13, 2011 3:25 PM
To: Bodke, Kishore K
Cc: Hart, Darren; yocto@yoctoproject.org
Subject: Re: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
branch.

On 11-12-13 6:17 PM, Bodke, Kishore K wrote:
> Yeah.  I am using local bare clone for the linux-yocto-3.0 and using 
> poky-extras/meta-kernel-dev in my bblayers.conf for my build.
> Sorry for not mentioning this before.

Aha. This is completely different then. As Darren mentioned, the bbappend
should be getting the latest tools, I can look into that.

But to be clear, is this an edison branch + meta-kernel-dev ? That
will cause problems at some point (and I'm not sure if that is what
is happening here yet), since recipe updates to use the new tools
wouldn't be reflected in that branch while you are fed the new tools.

Cheers,

Bruce

>
> Thanks
> Kishore.
>
> -Original Message-
> From: Hart, Darren
> Sent: Tuesday, December 13, 2011 3:15 PM
> To: Bruce Ashfield
> Cc: Bodke, Kishore K; yocto@yoctoproject.org
> Subject: Re: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
> branch.
>
> On 12/13/2011 03:05 PM, Bruce Ashfield wrote:
>> On 11-12-13 5:50 PM, Bodke, Kishore K wrote:
>>> Hi,
>>>
>>> I get failure for the linux-yoctort_3.0.bb file for the poky Edison branch.
>>>
>>> Darren told that it was fixed and merged to master.
>>
>> This shouldn't be happening on edison at all. The changes to the
>> kernel recipes/tools to use the merge_config.sh should never have
>> showed up in edison. That's yocto 1.2 development work.
>>
>> So the fix for this is to find out what leaked into edison and
>> revert it. I'll have a look at that later tonight.
>
> No no. Kishore is using meta-kernel-dev. As such he is getting the
> latest linux-yocto repository and SRC_REVs. The question, I think, is
> really why isn't the kern-tools-native bbappend from meta-kernel-dev
> doing this for him.
>
> --
> Darren
>
>>
>> Bruce
>>
>>>
>>> I wanted to bring to the list about this error message.
>>>
>>> ERROR: Function 'do_kernel_configme' failed (see
>>> /usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
>>> for further information)
>>>
>>> ERROR: Logfile of failure stored in:
>>> /usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
>>>
>>> Log data follows:
>>>
>>> | [INFO] doing kernel configme
>>>
>>> | [INFO] Branch yocto/standard/preempt-rt/base used by
>>> common-pc-preempt-rt.scc
>>>
>>> | [INFO] collecting configs in ./meta/meta-series
>>>
>>> | mv: cannot stat
>>> `/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/linux-crystalforest-preempt-rt-build/.tmp.config*':
>>> No such file or directory
>>>
>>> | creation of pre-processed config data failed
>>>
>>> | config of yocto/standard/preempt-rt/base (common-pc-preempt-rt.scc) failed
>>>
>>> | ERROR: Function 'do_kernel_configme' failed (see
>>> /usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
>>> for further information)
>>>
>>> NOTE: package
>>> linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1:
>>> task do_kernel_configme: Failed
>>>
>>> ERROR: Task 716
>>> (/usr/local/src/yocto_1_1_release/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb,
>>> do_kernel_configme) failed with exit code '1'
>>>
>>> Waiting for 7 active tasks to finish:
>>>
>>> 0: acl-native-2.2.51-r2 do_configure (pid 12164)
>>>
>>> 1: elfutils-native-0.148-r3 do_install (pid 19851)
>>>
>>> 2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)
>>>
>>> 3: font-util-native-1.2.0-r2.1 do_configure (pid 14632)
>>>
>>> 4: bison-native-2.5-r1 do_configure (pid 20206)
>>>
>>> 5: dbus-native-1.4.12-r0 do_configure (pid 20209)
>>>
>>> 6: opensp-native-1.5-r2 do_configure (pid 20213)
>>>
>>> Waiting for 6 active tasks to finish:
>>>
>>> 0: acl-native-2.2.51-r2 do_configure (pid 12164)
>>>
>>> 1: elfutils-native-0.148-r3 do_install (pid 19851)
>>>
>>> 2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)
>>>
>>> 3: font-util-native-1.2.0-r2.1 do_configure (pid 14632)
>>>
>>> 4: bison-native-2.5-r1 do_configure (pid 20206)
>>>
>>> 5: dbus-native-1.4.12-r0 do_configure (pid 20209)
>>>
>>> NOTE:

Re: [yocto] Error in routerstation pro machine.conf?

[Bruce Ashfield]

On 11-12-13 6:05 PM, David Smoot wrote:

I'm still very new and very clueless but I humbly submit what looks like
a bug to me..

"routerstationpro.conf" in meta-yocto/conf/machine/ lists machine
features the hardware does not have.

http://www.ubnt.com/wiki/RouterStation_Pro lists the hardware specs and
it lacks a display adapter (hence no screen nor keyboard) and it also
lacks USB slave hardware (hence no point in usbgadget).

File a bugzilla report or is there a reason for that configuration?


It's based off a generic MIPS configuration, the extra configs are there
from that effort and do no harm at the moment, so I'm inclined to leave
them as is. i.e. screen doesn't really trigger anything to be added
to the image (last I checked anyway), and keyboard gets us the keymaps
(which IIRC is used on the console). So neither does any harm.

gadget on the other hand, doesn't do us any good.

The boards features are planned to be documented in a README file,
rather than the conf file.

We have an update for this to the 3.0 kernel shortly which will include
the mentioned README file.

But a low level bugzilla can't hurt for the gadget issue. We can fix
it while updating the board.

Cheers,

Bruce




David

David Smoot
davidsm...@gmail.com 





___
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] linux-libc-headers 2.6.37

[Darren Hart]

We currently build at least some MACHINES with 2.6.37 of
linux-libc-headers. This can cause problems for newer packages (such as
connman) that expect more recent headers (if_alg.h is missing prior to
2.6.39). While the proper fix is to ensure these packages can cope with
older headers, for MACHINES shipping 3.0+ kernels, seems to me we should
be using the linux-libc-headers matching the kernels. I know this has
come up in the past, but I don't recall if we have clearly stated and
justified what our policy is here.

Any thoughts on this?

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] linux-libc-headers 2.6.37

[Bruce Ashfield]

On 11-12-13 6:33 PM, Darren Hart wrote:

We currently build at least some MACHINES with 2.6.37 of
linux-libc-headers. This can cause problems for newer packages (such as
connman) that expect more recent headers (if_alg.h is missing prior to
2.6.39). While the proper fix is to ensure these packages can cope with
older headers, for MACHINES shipping 3.0+ kernels, seems to me we should
be using the linux-libc-headers matching the kernels. I know this has
come up in the past, but I don't recall if we have clearly stated and
justified what our policy is here.


They should match were possible. I updated master to have 3.0 and 3.1
headers and no longer have .37 as the default.

Where is the 2.6.37 trickling in ? i.e. which boards/branch ?

Bruce



Any thoughts on this?



___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] linux-libc-headers 2.6.37

[Darren Hart]

On 12/13/2011 03:41 PM, Bruce Ashfield wrote:
> On 11-12-13 6:33 PM, Darren Hart wrote:
>> We currently build at least some MACHINES with 2.6.37 of
>> linux-libc-headers. This can cause problems for newer packages (such as
>> connman) that expect more recent headers (if_alg.h is missing prior to
>> 2.6.39). While the proper fix is to ensure these packages can cope with
>> older headers, for MACHINES shipping 3.0+ kernels, seems to me we should
>> be using the linux-libc-headers matching the kernels. I know this has
>> come up in the past, but I don't recall if we have clearly stated and
>> justified what our policy is here.
> 
> They should match were possible. I updated master to have 3.0 and 3.1
> headers and no longer have .37 as the default.
> 
> Where is the 2.6.37 trickling in ? i.e. which boards/branch ?

This was on fri2 yocto/standard/fri2.

> 
> Bruce
> 
>>
>> Any thoughts on this?
>>
> 

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Using yocto/standard by default

[Darren Hart]

We hit another lock-step SRCREV bug earlier on the FRI2 BSP. This was
due mostly to my pushing the efi changes to meta-intel too early - but,
it highlights a maintenance step that I believe could be eliminated for
most boards.

We have a yocto/standard/fri2 branch, but it doesn't contain any
additional changes over yocto/standard/base. If we were to make
yocto/standard/base the default for KBRANCH, shouldn't we be able to
eliminate all the BSP branches that are identical to
yocto/standard/base? This would significantly reduce the number of
SRCREV updates that are required and likely reduce the number of
Autobuilder failures we experience as a result. Seems like it would also
help make the git tree easier to deal with.

Any opinions here?

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto Project community survey

[Jeff Osier-Mixon]

Only 2 more days left to respond if you haven't, and then I'll quit bugging
you. :)

On Sat, Dec 3, 2011 at 10:10 AM, Jeff Osier-Mixon  wrote:

> Hi Yoctoids - if you have a spare 2 minutes, we would really appreciate it
> if you would fill out a short end-of-year survey for the project. This will
> help us in learning more about the community and in working on future
> directions for the project, plus you could win a Yocto t-shirt, just in
> time for the holidays!
>
> https://www.surveymonkey.com/s/yoctosurvey
>
> The survey runs until December 15.
>
> thanks,
>
> --
> Jeff Osier-Mixon http://jefro.net/blog
> Yocto Project Community Manager @Intel http://yoctoproject.org
>
>


-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] kernel-tools failure for linux-yoctort_3.0.bb for poky/edison branch.

[Bruce Ashfield]

On 11-12-13 6:26 PM, Bodke, Kishore K wrote:

Yes.
Its with poky Edison with poky-extras/meta-kernel-dev master branch I am using 
for my build.


This is likely the problem. I use and test meta-kernel-dev everyday,
but that's always against master. I keep them in lockstep, since
meta-kernel-dev never really 'releases'.

That being said, we can figure out a combination that works. The
best thing to do, would be to remove the kern-tools-native bbappend
from your meta-kernel-dev layer (for now). You don't want the new
tools.

If that doesn't fix the problem, look for merge_log.txt in your
linux/meta/cfg/ directory structure and that will tell us exactly
what is going wrong.

Bruce



Thanks
Kishore.

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, December 13, 2011 3:25 PM
To: Bodke, Kishore K
Cc: Hart, Darren; yocto@yoctoproject.org
Subject: Re: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
branch.

On 11-12-13 6:17 PM, Bodke, Kishore K wrote:

Yeah.  I am using local bare clone for the linux-yocto-3.0 and using 
poky-extras/meta-kernel-dev in my bblayers.conf for my build.
Sorry for not mentioning this before.


Aha. This is completely different then. As Darren mentioned, the bbappend
should be getting the latest tools, I can look into that.

But to be clear, is this an edison branch + meta-kernel-dev ? That
will cause problems at some point (and I'm not sure if that is what
is happening here yet), since recipe updates to use the new tools
wouldn't be reflected in that branch while you are fed the new tools.

Cheers,

Bruce



Thanks
Kishore.

-Original Message-
From: Hart, Darren
Sent: Tuesday, December 13, 2011 3:15 PM
To: Bruce Ashfield
Cc: Bodke, Kishore K; yocto@yoctoproject.org
Subject: Re: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
branch.

On 12/13/2011 03:05 PM, Bruce Ashfield wrote:

On 11-12-13 5:50 PM, Bodke, Kishore K wrote:

Hi,

I get failure for the linux-yoctort_3.0.bb file for the poky Edison branch.

Darren told that it was fixed and merged to master.


This shouldn't be happening on edison at all. The changes to the
kernel recipes/tools to use the merge_config.sh should never have
showed up in edison. That's yocto 1.2 development work.

So the fix for this is to find out what leaked into edison and
revert it. I'll have a look at that later tonight.


No no. Kishore is using meta-kernel-dev. As such he is getting the
latest linux-yocto repository and SRC_REVs. The question, I think, is
really why isn't the kern-tools-native bbappend from meta-kernel-dev
doing this for him.

--
Darren



Bruce



I wanted to bring to the list about this error message.

ERROR: Function 'do_kernel_configme' failed (see
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
for further information)

ERROR: Logfile of failure stored in:
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502

Log data follows:

| [INFO] doing kernel configme

| [INFO] Branch yocto/standard/preempt-rt/base used by
common-pc-preempt-rt.scc

| [INFO] collecting configs in ./meta/meta-series

| mv: cannot stat
`/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/linux-crystalforest-preempt-rt-build/.tmp.config*':
No such file or directory

| creation of pre-processed config data failed

| config of yocto/standard/preempt-rt/base (common-pc-preempt-rt.scc) failed

| ERROR: Function 'do_kernel_configme' failed (see
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
for further information)

NOTE: package
linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1:
task do_kernel_configme: Failed

ERROR: Task 716
(/usr/local/src/yocto_1_1_release/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb,
do_kernel_configme) failed with exit code '1'

Waiting for 7 active tasks to finish:

0: acl-native-2.2.51-r2 do_configure (pid 12164)

1: elfutils-native-0.148-r3 do_install (pid 19851)

2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)

3: font-util-native-1.2.0-r2.1 do_configure (pid 14632)

4: bison-native-2.5-r1 do_configure (pid 20206)

5: dbus-native-1.4.12-r0 do_configure (pid 20209)

6: opensp-native-1.5-r2 do_configure (pid 20213)

Waiting for 6 active tasks to finish:

0: acl-native-2.2.51-r2 do_configure (pid 12164)

1: elfutils-

Re: [yocto] linux-libc-headers 2.6.37

[Bruce Ashfield]

On 11-12-13 6:43 PM, Darren Hart wrote:



On 12/13/2011 03:41 PM, Bruce Ashfield wrote:

On 11-12-13 6:33 PM, Darren Hart wrote:

We currently build at least some MACHINES with 2.6.37 of
linux-libc-headers. This can cause problems for newer packages (such as
connman) that expect more recent headers (if_alg.h is missing prior to
2.6.39). While the proper fix is to ensure these packages can cope with
older headers, for MACHINES shipping 3.0+ kernels, seems to me we should
be using the linux-libc-headers matching the kernels. I know this has
come up in the past, but I don't recall if we have clearly stated and
justified what our policy is here.


They should match were possible. I updated master to have 3.0 and 3.1
headers and no longer have .37 as the default.

Where is the 2.6.37 trickling in ? i.e. which boards/branch ?


This was on fri2 yocto/standard/fri2.


What does your: meta/conf/distro/include/tcmode-default.inc have
as the default ? It should be LINUXLIBCVERSION ?= "3.1".

I'm talking about master for that default. In the release branches
it was still back on 2.6.37.

Is that being overridden somewhere in meta-intel that would trigger
the 2.6.37 (the old default) ? I didn't find anything, but that doesn't
mean I didn't miss it.

Bruce





Bruce



Any thoughts on this?







___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Using yocto/standard by default

[Bruce Ashfield]

On 11-12-13 6:46 PM, Darren Hart wrote:

We hit another lock-step SRCREV bug earlier on the FRI2 BSP. This was
due mostly to my pushing the efi changes to meta-intel too early - but,
it highlights a maintenance step that I believe could be eliminated for
most boards.

We have a yocto/standard/fri2 branch, but it doesn't contain any
additional changes over yocto/standard/base. If we were to make
yocto/standard/base the default for KBRANCH, shouldn't we be able to
eliminate all the BSP branches that are identical to
yocto/standard/base? This would significantly reduce the number of
SRCREV updates that are required and likely reduce the number of
Autobuilder failures we experience as a result. Seems like it would also
help make the git tree easier to deal with.

Any opinions here?


It's a valid config, and something that works now. So there's no
reason to not use it. New branches can be created IF a board really
does need to merge conflicting patches. The emgd stuff was a problem
and required branches, but if we have nothing like that, squashing the
branches is a nice simplification.

Cheers,

Bruce





___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] kernel-tools failure for linux-yoctort_3.0.bb for poky/edison branch.

[Darren Hart]

On 12/13/2011 09:13 PM, Bruce Ashfield wrote:
> On 11-12-13 6:26 PM, Bodke, Kishore K wrote:
>> Yes.
>> Its with poky Edison with poky-extras/meta-kernel-dev master branch I am 
>> using for my build.
> 
> This is likely the problem. I use and test meta-kernel-dev everyday,
> but that's always against master. I keep them in lockstep, since
> meta-kernel-dev never really 'releases'.
> 
> That being said, we can figure out a combination that works. The
> best thing to do, would be to remove the kern-tools-native bbappend
> from your meta-kernel-dev layer (for now). You don't want the new
> tools.

That won't work.  He is using the latest kernel which has needs
merge_config.sh - as I ran into myself last week. I had Kishore
cherry-pick the last two patches to kern-tools-native from master and
that got things going for him. So again, the question is: Why didn't the
kern-tools-native bbappend do that for him?

--
Darren

> 
> If that doesn't fix the problem, look for merge_log.txt in your
> linux/meta/cfg/ directory structure and that will tell us exactly
> what is going wrong.
> 
> Bruce
> 
>>
>> Thanks
>> Kishore.
>>
>> -Original Message-
>> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
>> Sent: Tuesday, December 13, 2011 3:25 PM
>> To: Bodke, Kishore K
>> Cc: Hart, Darren; yocto@yoctoproject.org
>> Subject: Re: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
>> branch.
>>
>> On 11-12-13 6:17 PM, Bodke, Kishore K wrote:
>>> Yeah.  I am using local bare clone for the linux-yocto-3.0 and using 
>>> poky-extras/meta-kernel-dev in my bblayers.conf for my build.
>>> Sorry for not mentioning this before.
>>
>> Aha. This is completely different then. As Darren mentioned, the bbappend
>> should be getting the latest tools, I can look into that.
>>
>> But to be clear, is this an edison branch + meta-kernel-dev ? That
>> will cause problems at some point (and I'm not sure if that is what
>> is happening here yet), since recipe updates to use the new tools
>> wouldn't be reflected in that branch while you are fed the new tools.
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>> Thanks
>>> Kishore.
>>>
>>> -Original Message-
>>> From: Hart, Darren
>>> Sent: Tuesday, December 13, 2011 3:15 PM
>>> To: Bruce Ashfield
>>> Cc: Bodke, Kishore K; yocto@yoctoproject.org
>>> Subject: Re: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
>>> branch.
>>>
>>> On 12/13/2011 03:05 PM, Bruce Ashfield wrote:
 On 11-12-13 5:50 PM, Bodke, Kishore K wrote:
> Hi,
>
> I get failure for the linux-yoctort_3.0.bb file for the poky Edison 
> branch.
>
> Darren told that it was fixed and merged to master.

 This shouldn't be happening on edison at all. The changes to the
 kernel recipes/tools to use the merge_config.sh should never have
 showed up in edison. That's yocto 1.2 development work.

 So the fix for this is to find out what leaked into edison and
 revert it. I'll have a look at that later tonight.
>>>
>>> No no. Kishore is using meta-kernel-dev. As such he is getting the
>>> latest linux-yocto repository and SRC_REVs. The question, I think, is
>>> really why isn't the kern-tools-native bbappend from meta-kernel-dev
>>> doing this for him.
>>>
>>> --
>>> Darren
>>>

 Bruce

>
> I wanted to bring to the list about this error message.
>
> ERROR: Function 'do_kernel_configme' failed (see
> /usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
> for further information)
>
> ERROR: Logfile of failure stored in:
> /usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
>
> Log data follows:
>
> | [INFO] doing kernel configme
>
> | [INFO] Branch yocto/standard/preempt-rt/base used by
> common-pc-preempt-rt.scc
>
> | [INFO] collecting configs in ./meta/meta-series
>
> | mv: cannot stat
> `/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/linux-crystalforest-preempt-rt-build/.tmp.config*':
> No such file or directory
>
> | creation of pre-processed config data failed
>
> | config of yocto/standard/preempt-rt/base (common-pc-preempt-rt.scc) 
> failed
>
> | ERROR: Function 'do_kernel_configme' failed (see
> /usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
> for further 

Re: [yocto] Using yocto/standard by default

[Darren Hart]

On 12/13/2011 09:27 PM, Bruce Ashfield wrote:
> On 11-12-13 6:46 PM, Darren Hart wrote:
>> We hit another lock-step SRCREV bug earlier on the FRI2 BSP. This was
>> due mostly to my pushing the efi changes to meta-intel too early - but,
>> it highlights a maintenance step that I believe could be eliminated for
>> most boards.
>>
>> We have a yocto/standard/fri2 branch, but it doesn't contain any
>> additional changes over yocto/standard/base. If we were to make
>> yocto/standard/base the default for KBRANCH, shouldn't we be able to
>> eliminate all the BSP branches that are identical to
>> yocto/standard/base? This would significantly reduce the number of
>> SRCREV updates that are required and likely reduce the number of
>> Autobuilder failures we experience as a result. Seems like it would also
>> help make the git tree easier to deal with.
>>
>> Any opinions here?
> 
> It's a valid config, and something that works now. So there's no
> reason to not use it. New branches can be created IF a board really
> does need to merge conflicting patches. The emgd stuff was a problem
> and required branches, but if we have nothing like that, squashing the
> branches is a nice simplification.
> 

Hrm maybe I missed that in the fri2 branches. It does need emgd, so I'll
double check that.

> Cheers,
> 
> Bruce
> 
>>
> 

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto