Date   

Re: build failure with xf86-video-omap

Martin Jansa
 

On Wed, Nov 21, 2012 at 11:52:30PM +0100, Nicolas Dechesne wrote:
hi ,

since xf86-video-omap was recently merged in oe-core and poky, i am trying
to remove the recipes we had staged in meta-ti trees for some weeks (
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=410dc026f2ee24a2346e7563a83f0181c79809cf).
so i was trying to build poky/master with meta-ti/master, for pandaboard,
and I get build failures in xf86-video-omap [1] and [2].

so [1] is actually trivial, as we are missing a DEPENDS in the recipe, i
can send a patch in oe-core for that.

[2] is a bit more cryptic to me.. so I quickly tried to build with danny (
i just cherry picked the commit that introduced xf86-video-omap from
master) and this time it built fine.
Check this tread:
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-November/032012.html

has anyone actually tested this recipe?
obviously no

Cheers,

if so I must be doing something > wrong, any hint would be helpful.

i also tried a build without poky, and just oe-core, and got the same
failure.

cheers

nicolas

[1] : from log_do.configure for xf86-video-omap
checking for XORG... no
configure: error: Package requirements (xorg-server >= 1.3 xproto
fontsproto libdrm >= 2.4.36 libdrm_omap xf86driproto randrproto
renderproto videoproto xextproto) were not met:



No package 'xf86driproto' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.


[2] : from log_do.configure for xf86-video-omap
checking dependency style of arm-poky-linux-gnueabi-gcc -march=armv7-a
-mthumb-\
interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a9
--sysroot=/data/psi_omap_bu\
ilds_admins/ndechesne/yocto/build-poky2/tmp/sysroots/pandaboard... (cached)
none
checking for sys/ioctl.h... (cached) yes
checking if RANDR is defined... yes
checking if RENDER is defined... yes
checking if XV is defined... yes
checking if DPMSExtension is defined... yes
checking for XORG... yes
checking for ANSI C header files... (cached) yes
checking whether to include DRI support... checking for
/usr/include/xorg/dri.h...
configure: error: cannot check for file existence when cross compiling
... and configure just
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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


Re: build error since commit: gcc: Use FILESPATH instead of FILESDIR and cleanup/simplify

Nicolas Dechesne <ndec13@...>
 



On Wed, Nov 21, 2012 at 9:41 AM, Burton, Ross <ross.burton@...> wrote:
On 21 November 2012 00:44, Nicolas Dechesne <ndec13@...> wrote:
> i was attempting a rebuild from scratch with today's master of poky, and i
> was facing issues such as:
>
> WARNING: Failed to fetch URL file://gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch,
> attempting MIRRORS if available

That bug was only briefly in the tree, so do another pull.

indeed ;-) i can see the commits now.
 

You'll then get image generation failures with libgl, which I'll be
fixing today. :(

well, i am not there yet, as I have more build failure (as I just reported)

thanks


build failure with xf86-video-omap

Nicolas Dechesne <ndec13@...>
 

hi ,

since xf86-video-omap was recently merged in oe-core and poky, i am trying to remove the recipes we had staged in meta-ti trees for some weeks (http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=410dc026f2ee24a2346e7563a83f0181c79809cf). so i was trying to build  poky/master with meta-ti/master, for pandaboard, and I get build failures in xf86-video-omap [1] and [2].

so [1] is actually trivial, as we are missing a DEPENDS in the recipe, i can send a patch in oe-core for that. 

[2] is a bit more cryptic to me.. so I quickly tried to build with danny ( i just cherry picked the commit that introduced xf86-video-omap from master) and this time it built fine. 

has anyone actually tested this recipe? if so I must be doing something wrong, any hint would be helpful.

i also tried a build without poky, and just oe-core, and got the same failure.

cheers

nicolas

[1] : from log_do.configure for xf86-video-omap 
checking for XORG... no
configure: error: Package requirements (xorg-server >= 1.3 xproto fontsproto libdrm >= 2.4.36 libdrm_omap xf86driproto  randrproto renderproto videoproto xextproto) were not met:
                                                                                                                                                                                      
No package 'xf86driproto' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.


[2] : from log_do.configure for xf86-video-omap 
checking dependency style of arm-poky-linux-gnueabi-gcc  -march=armv7-a     -mthumb-\
interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a9 --sysroot=/data/psi_omap_bu\
ilds_admins/ndechesne/yocto/build-poky2/tmp/sysroots/pandaboard... (cached) none
checking for sys/ioctl.h... (cached) yes
checking if RANDR is defined... yes
checking if RENDER is defined... yes
checking if XV is defined... yes
checking if DPMSExtension is defined... yes
checking for XORG... yes
checking for ANSI C header files... (cached) yes
checking whether to include DRI support... checking for /usr/include/xorg/dri.h... 
configure: error: cannot check for file existence when cross compiling 
... and configure just 


Re: inconsistent pages out there for setting up your yocto dev host

Paul Eggleton
 

On Wednesday 21 November 2012 17:23:56 Robert P. J. Day wrote:
i've noticed there are various web pages purporting to explain how
to set up a proper OE/yocto development host, but they give what is
pretty clearly contradictory information.

as one example, there's this page on getting started with OE:

http://www.openembedded.org/wiki/Getting_started
I produced this page recently; FWIW I also came up with the pared-down package
lists that went into the Quick Start Guide which this page borrows. How is
this contradictory if it uses the same information?

that claims to steal from a number of sources including the yocto QS
guide, but look at the packages one is instructed to install on that
page, particularly under fedora: python, perl, git, and so on.
So I don't recall exactly how perl got on that list; but python and git are
absolutely required on the host. That's why they're in ASSUME_PROVIDED.

as i read it, the sanity.bbclass and ASSUME_PROVIDED will dictate
what needs to be there and what will be used if it's installed
natively, no? it certainly seems that that wiki page is insructing
the developer to install a lot of software that OE will handle
automatically, no?
Er, no. Well, if by "handle automatically" you mean "error out when they are
not present" then that's not very helpful - it's much easier if people just
get a list of what they need to install up front.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


inconsistent pages out there for setting up your yocto dev host

Robert P. J. Day
 

i've noticed there are various web pages purporting to explain how
to set up a proper OE/yocto development host, but they give what is
pretty clearly contradictory information.

as one example, there's this page on getting started with OE:

http://www.openembedded.org/wiki/Getting_started

that claims to steal from a number of sources including the yocto QS
guide, but look at the packages one is instructed to install on that
page, particularly under fedora: python, perl, git, and so on.

as i read it, the sanity.bbclass and ASSUME_PROVIDED will dictate
what needs to be there and what will be used if it's installed
natively, no? it certainly seems that that wiki page is insructing
the developer to install a lot of software that OE will handle
automatically, no?

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


[meta-intel][danny][PATCH V2] mesa-dri_8.0.4.bbappend: Remove tabs from python code

Khem Raj
 

check for xserver to be non-empty before using it
fixed errors like

ERROR: Failed to parse recipe:
/b/kraj/yocto/poky/meta/recipes-graphics/mesa/mesa-dri_8.0.4.bb
ERROR: Error executing a python function in <code>:
AttributeError: 'NoneType' object has no attribute 'split'

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
.../recipes-graphics/mesa/mesa-dri_8.0.4.bbappend | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend b/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
index 6bfa968..b92831d 100644
--- a/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
+++ b/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
@@ -6,13 +6,13 @@
python __anonymous () {
import re
xserver = d.getVar('XSERVER', True)
- if 'emgd-driver-bin' in xserver.split(' '):
+ if xserver and 'emgd-driver-bin' in xserver.split(' '):
extra_oeconf = d.getVar('EXTRA_OECONF', True).split()
- take_out = ["--enable-egl", "--enable-gles1", "--enable-gles2"]
- put_in = ["--disable-egl", "--disable-gles1", "--disable-gles2"]
+ take_out = ["--enable-egl", "--enable-gles1", "--enable-gles2"]
+ put_in = ["--disable-egl", "--disable-gles1", "--disable-gles2"]
pattern = re.compile("--with-egl-platforms")
new_extra_oeconf = [ ]
- for i in extra_oeconf:
+ for i in extra_oeconf:
if ( i not in take_out ) and ( not pattern.match(i)):
new_extra_oeconf.append(i)
for i in put_in:
--
1.7.9.5


my wiki page for using OE and meta-ti layer to build for panda ES

Robert P. J. Day
 

not strictly related to yocto but i figured some folks might be
interested in a recipe for using OE and the meta-ti layer to build a
bootable system for a panda ES:

http://www.crashcourse.ca/wiki/index.php/OE-Core%2C_meta-ti_and_the_PandaBoard_ES

feedback welcome.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: Need for offline binary configuration

Bruce Ashfield <bruce.ashfield@...>
 

On 12-11-21 11:29 AM, Venkata ramana gollamudi wrote:
Reply inline

-----Original Message-----
From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
Sent: Tuesday, November 20, 2012 8:53 PM
To: Venkata ramana gollamudi
Cc: yocto@yoctoproject.org; Sanil kumar; Hatle, Mark
Subject: Re: [yocto] Need for offline binary configuration

On 12-11-20 10:09 AM, Venkata ramana gollamudi wrote:
Poky allows to build custom Linux for you, but we have cases where
the post build customization is required, like user-addition, network
configuration, service control. Even selecting the required packages
can be a post build activity.

The current model requires the image to be rebuilt to support these
configuration.
Offline Configuration tool (OCT), which allows a binary image
customization before making a final target image. This case will be
more evident in larger companies, where platform teams, product teams ,
application teams are distributed and Linux build from source will be
owned and lab tested by a single team, like platform team. Other teams
just configure to use it for product variants from same platform build.

Detailed use cases can be found in enhancement bug:3252

OCT should work on the binary pool of compiled packages generated
from poky.

The basic operations that can be supported includes
a) Select/deselect required packages from pool of binary packages
into final target image.
b) Provision to select external binary packages like ADT compiled
applications as input and add them to final target image.
c) Binary level Offline configuration can includes
Configure the users/passwords
Configure the network
Configure the host name
Select the services to be started by default
Security related configuration
Generate initrd in ramfs/ext3/... format
etc..

Considering the methods to support these in our current yocto model,
following changes can be done.
1) HOB can be the tool which can be extended to support these
Poky can generate a binary package pool as one if its output and
Hob can work on this package pool to select packages, configure and
generate image.
So HOB can support opening HOB in Binary(or OCT) mode i.e., without
build options but only with binary package selection. Configuration GUI
needs to be added to HOB.
Note:HOB+OCT is together or separate, needs a bit more thought and
overall organization as they will be intended for different users.

Is there some overlap between this point and the other ongoing
discussions
about image construction, deployment and package management ?

i.e. this thread:

[OE-core] RFC: OE-Core image creation and deployment

http://lists.linuxtogo.org/pipermail/openembedded-core/2012-
July/026938.html

These may already be coordinated, but I do see some common threads and
it would be nice to make sure everything will work together and that we
aren't duplicating effort!

Cheers,

Bruce
Bruce, Thanks for the information. After your reply, I have gone through the discussions and agree that binary pool is in similar lines. Great to see that the realization happening in yocto1.4.
Understood that package-feed can be used to generate the target image.

Is there any RFC/mail/wiki available explaining how the configuration(like fstype) during image generation will be realized?
Not that I know of. It is still under design last I heard, but MarkH is the
person to provide the details. He's out of the office at the moment, but
I'm sure that when he is back he can provide plenty of information.


I am looking for post build configuration tool, which allows the product team users also to configure users, network, services etc .
Agreed. I see this as something to start with, since it doesn't overlap
with the other efforts (that I know of), and when I first read your
email I thought it was the main focus. When you continued into image
creation and package selection, that's when I noted the overlap.

Image type, file system and Partition configuration can be one of them.
I expect the product team users who configures image and generates target image, will have a little or no knowledge of bitbake, also needs easy installation and less dependencies.

Can look in this context, how HOB will fit into this scenario or needs a new tool.
Keeping the number of tools low is a good thing, so hopefully it can fit
within the existing options.



2) Binary package pool can be a minimal/partial sstate-cache, as
complete sstate-cache is quite big and not required for product teams
as they are not expected to build but just need to select and
configure.
I think it is sufficient to keep the minimal binaries from
sstate-cache which are required to execute image.bbclass, do_rootfs
task to generate image.
Point 2, No longer applicable as package-feed is a binary pool.

3) Along with specific configuration UI implementation, a generic
configuration model similar to kernel kconfig and menuconfig can be
considered, in cases where more detailed offline configurations is
required like detailed security configuration.
Point 3, still can be thought about.
There have been other menuconfig efforts in the past (that I've heard
about, but not had direct involvement), so doing some research in this
area would be appropriate as well.

cheers,

Bruce



Regards,
Ramana
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[meta-intel][danny][PATCH] mesa-dri_8.0.4.bbappend: Remove tabs from python code

Khem Raj
 

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
.../recipes-graphics/mesa/mesa-dri_8.0.4.bbappend | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend b/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
index 6bfa968..2a49c26 100644
--- a/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
+++ b/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
@@ -8,11 +8,11 @@ python __anonymous () {
xserver = d.getVar('XSERVER', True)
if 'emgd-driver-bin' in xserver.split(' '):
extra_oeconf = d.getVar('EXTRA_OECONF', True).split()
- take_out = ["--enable-egl", "--enable-gles1", "--enable-gles2"]
- put_in = ["--disable-egl", "--disable-gles1", "--disable-gles2"]
+ take_out = ["--enable-egl", "--enable-gles1", "--enable-gles2"]
+ put_in = ["--disable-egl", "--disable-gles1", "--disable-gles2"]
pattern = re.compile("--with-egl-platforms")
new_extra_oeconf = [ ]
- for i in extra_oeconf:
+ for i in extra_oeconf:
if ( i not in take_out ) and ( not pattern.match(i)):
new_extra_oeconf.append(i)
for i in put_in:
--
1.7.9.5


Re: Need for offline binary configuration

Venkata ramana gollamudi <ramana.gollamudi@...>
 

Reply inline

-----Original Message-----
From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
Sent: Tuesday, November 20, 2012 8:53 PM
To: Venkata ramana gollamudi
Cc: yocto@yoctoproject.org; Sanil kumar; Hatle, Mark
Subject: Re: [yocto] Need for offline binary configuration

On 12-11-20 10:09 AM, Venkata ramana gollamudi wrote:
Poky allows to build custom Linux for you, but we have cases where
the post build customization is required, like user-addition, network
configuration, service control. Even selecting the required packages
can be a post build activity.

The current model requires the image to be rebuilt to support these
configuration.
Offline Configuration tool (OCT), which allows a binary image
customization before making a final target image. This case will be
more evident in larger companies, where platform teams, product teams ,
application teams are distributed and Linux build from source will be
owned and lab tested by a single team, like platform team. Other teams
just configure to use it for product variants from same platform build.

Detailed use cases can be found in enhancement bug:3252

OCT should work on the binary pool of compiled packages generated
from poky.

The basic operations that can be supported includes
a) Select/deselect required packages from pool of binary packages
into final target image.
b) Provision to select external binary packages like ADT compiled
applications as input and add them to final target image.
c) Binary level Offline configuration can includes
Configure the users/passwords
Configure the network
Configure the host name
Select the services to be started by default
Security related configuration
Generate initrd in ramfs/ext3/... format
etc..

Considering the methods to support these in our current yocto model,
following changes can be done.
1) HOB can be the tool which can be extended to support these
Poky can generate a binary package pool as one if its output and
Hob can work on this package pool to select packages, configure and
generate image.
So HOB can support opening HOB in Binary(or OCT) mode i.e., without
build options but only with binary package selection. Configuration GUI
needs to be added to HOB.
Note:HOB+OCT is together or separate, needs a bit more thought and
overall organization as they will be intended for different users.

Is there some overlap between this point and the other ongoing
discussions
about image construction, deployment and package management ?

i.e. this thread:

[OE-core] RFC: OE-Core image creation and deployment

http://lists.linuxtogo.org/pipermail/openembedded-core/2012-
July/026938.html

These may already be coordinated, but I do see some common threads and
it would be nice to make sure everything will work together and that we
aren't duplicating effort!

Cheers,

Bruce
Bruce, Thanks for the information. After your reply, I have gone through the discussions and agree that binary pool is in similar lines. Great to see that the realization happening in yocto1.4.
Understood that package-feed can be used to generate the target image.

Is there any RFC/mail/wiki available explaining how the configuration(like fstype) during image generation will be realized?

I am looking for post build configuration tool, which allows the product team users also to configure users, network, services etc .
Image type, file system and Partition configuration can be one of them.
I expect the product team users who configures image and generates target image, will have a little or no knowledge of bitbake, also needs easy installation and less dependencies.

Can look in this context, how HOB will fit into this scenario or needs a new tool.


2) Binary package pool can be a minimal/partial sstate-cache, as
complete sstate-cache is quite big and not required for product teams
as they are not expected to build but just need to select and
configure.
I think it is sufficient to keep the minimal binaries from
sstate-cache which are required to execute image.bbclass, do_rootfs
task to generate image.
Point 2, No longer applicable as package-feed is a binary pool.

3) Along with specific configuration UI implementation, a generic
configuration model similar to kernel kconfig and menuconfig can be
considered, in cases where more detailed offline configurations is
required like detailed security configuration.
Point 3, still can be thought about.


Regards,
Ramana
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [meta-intel][fri2][PATCH] meta-fri2: update README to match current emgd driver version

Darren Hart <dvhart@...>
 

On 11/21/2012 06:43 AM, Koen Kooi wrote:

Nice catch Koen, thank you.

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
meta-fri2/README | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta-fri2/README b/meta-fri2/README
index af33c0b..b90613d 100644
--- a/meta-fri2/README
+++ b/meta-fri2/README
@@ -93,7 +93,7 @@ bblayers.conf, e.g.:
The meta-fri2 layer contains support for two different machine
configurations. These configurations are identical except for the fact
that the one prefixed with 'fri2' makes use of the Intel-proprietary
-EMGD 1.10 graphics driver, while the one prefixed with 'fri2-noemgd'
+EMGD 1.14 graphics driver, while the one prefixed with 'fri2-noemgd'
does not.

If you want to enable the layer that supports EMGD graphics add the
@@ -103,10 +103,10 @@ following to the local.conf file:

The 'fri2' machine includes the emgd-driver-bin package, which has a
proprietary license that must be whitelisted by adding the string
-"license_emgd-driver-bin_1.10" to the LICENSE_FLAGS_WHITELIST variable
+"license_emgd-driver-bin_1.14" to the LICENSE_FLAGS_WHITELIST variable
in your local.conf. For example:

- LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.10"
+ LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.14"

If you want to enable the layer that does not support EMGD graphics
add the following to the local.conf file:
@@ -128,7 +128,7 @@ added to the the LICENSE_FLAGS_WHITELIST variable in your local.conf.

For example:

- LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.10 commercial"
+ LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.14 commercial"
I have taken to using:

LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin commercial"

Which avoids the constant updating based on version. Any objection to
using this instead of the version specific flag?


The reason this is needed is to prevent the image from including
anything that might violate the license terms of the packages used to
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel


[meta-intel][fri2][PATCH] meta-fri2: update README to match current emgd driver version

Koen Kooi
 

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
meta-fri2/README | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta-fri2/README b/meta-fri2/README
index af33c0b..b90613d 100644
--- a/meta-fri2/README
+++ b/meta-fri2/README
@@ -93,7 +93,7 @@ bblayers.conf, e.g.:
The meta-fri2 layer contains support for two different machine
configurations. These configurations are identical except for the fact
that the one prefixed with 'fri2' makes use of the Intel-proprietary
-EMGD 1.10 graphics driver, while the one prefixed with 'fri2-noemgd'
+EMGD 1.14 graphics driver, while the one prefixed with 'fri2-noemgd'
does not.

If you want to enable the layer that supports EMGD graphics add the
@@ -103,10 +103,10 @@ following to the local.conf file:

The 'fri2' machine includes the emgd-driver-bin package, which has a
proprietary license that must be whitelisted by adding the string
-"license_emgd-driver-bin_1.10" to the LICENSE_FLAGS_WHITELIST variable
+"license_emgd-driver-bin_1.14" to the LICENSE_FLAGS_WHITELIST variable
in your local.conf. For example:

- LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.10"
+ LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.14"

If you want to enable the layer that does not support EMGD graphics
add the following to the local.conf file:
@@ -128,7 +128,7 @@ added to the the LICENSE_FLAGS_WHITELIST variable in your local.conf.

For example:

- LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.10 commercial"
+ LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.14 commercial"

The reason this is needed is to prevent the image from including
anything that might violate the license terms of the packages used to
--
1.7.7.6


Re: build error since commit: gcc: Use FILESPATH instead of FILESDIR and cleanup/simplify

Ross Burton
 

On 21 November 2012 00:44, Nicolas Dechesne <ndec13@gmail.com> wrote:
i was attempting a rebuild from scratch with today's master of poky, and i
was facing issues such as:

WARNING: Failed to fetch URL file://gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch,
attempting MIRRORS if available
That bug was only briefly in the tree, so do another pull.

You'll then get image generation failures with libgl, which I'll be
fixing today. :(

Ross


Re: Weekly Test Report for Yocto 1.4 20121114 Build on non-x86 platforms

Alexandru Palalau <alexandrux.palalau@...>
 

Disregard the "non-x86 platforms" from mail subject :)
Weekly test results.

On 11/21/2012 10:26 AM, Palalau, AlexandruX wrote:
Hello,

Below are the test results for Yocto 1.4 20121114 build.

There are some bugs for Beagleboard and P1022DS BSPs and two
CoreBuildSystem multilib bugs.

Other than that, ADT Bug 3338 regarding autoreconf run failing on
game-toolchain.

*Test Summary
-------------------------*

*Test Result Summary*

*Component*



*Target*



*Status*



*Comments*

*BSP*



Beagleboard



GOOD



Video: black screen when playing video

 



Routerstationpro



GOOD



Everything runs well

 



Mpc8315e-rdb



GOOD



Everything runs well



P1022DS



BUGGY



Udev error: can not mount harddisk and usb stick; Some error messages
with dmesg

*QEMU*



qemuarm



GOOD



Everything runs well

 



qemuppc



GOOD



Everything runs well

 



qemumips



GOOD



Everything runs well

*Core Build System*



GOOD



*Bug 3440* <https://bugzilla.yoctoproject.org/show_bug.cgi?id=3440> -
Multilib build triggers warnings
*Bug 3453* <https://bugzilla.yoctoproject.org/show_bug.cgi?id=3453> -
Build fails when building multilib with ipk packaging

*ADT Toolchain*



BUGGY



iptables-1.4.15: autoreconf run failed on gmae-toolchain

*HOB*





GOOD



Everything runs well

BLOCK



Critical bugs, more than 50% test cases are blocked

GOOD



Only Normal, Minor or Enhancement bugs, less than 10% test cases failed

BUGGY



Normal, Major and Critical bugs, more than 10% test cases failed

*Detailed Test Result for each component*

*Target*



*Total TCs*



*Not Run*



*Passed*



*Failed*



*Not testable (Blocked)*

*Beagleboard Sato-SDK*



55



0



53



2 (bug 3458)



0

*Routerstationpro Sato-SDK*



32



0



32



0



0

*Mpc8315e-rdb Sato-SDK*



34



0



34



0



0

*P1022DS*



31



0



26



5 (bug 3451,3452)



0

*Qemuarm Sato*



31



0



31



0



0

*Qemuarm Sato-SDK*



36



0



36



0



0

*Qemumips Sato*



31



0



31



0



0

*Qemumips Sato-SDK*



36



0



36



0



0

*Qemuppc Sato*



31



0



31



0



0

*Qemuppc Sato-SDK*



36



0



36



0



0

*Core Build System*



42



0



40



2(bug 3440,bug3453)



0

*ADT Toolchain*



52



0



51



1 (bug 3338)



0

*HOB*



17



0



17



0



0

*Total*



464



0



454



10



0


* You can check the detailed test result in attachment for each target.
** The failed/blocked case number is listed with failed cases’ bug number.


*Commit information
--------------------------------*
Location: http://autobuilder.yoctoproject.org/pub/nightly/20121114-1/
<http://autobuilder.yoctoproject.org/pub/nightly/20121114-1>
Tree/Branch: poky/master
Poky: 1fd9a16d2a4594a4e9179dc7353ac51ce32eb712

*
Issue Summary
-----------------------------------*

*Component*



*Bug Number*



*Target Milestone*

*System & Core OS*



*System Usage*



New! Bug 3458 Beagleboard: No pictures shown when playing video
New! Bug 3452 [p1022ds] udev error: can not mount harddisk and usb stick
New! Bug 3451 [p1022ds] Some error messages with dmesg



---
1.4
1.4 M1

*Others*



Bug 2766 coreutils build error with long TMPDIR: Argument list too long
Bug 2759 qt4-native-4.8.1-r14.1 build error with long TMPDIR:
initializer-string for array of chars is too long [-fpermissive]



1.4 M1
1.4

*Core Build System*



Bug 3440 <https://bugzilla.yoctoproject.org/show_bug.cgi?id=3440> -
Multilib build triggers warnings
Bug 3453 <https://bugzilla.yoctoproject.org/show_bug.cgi?id=3453> -
Build fails when building multilib with ipk packaging



1.4
1.4

*ADT Toolchain*



Bug 3338 iptables-1.4.15: autoreconf run failed on gmae-toolchain



1.4 M1



Best Regards,


--

Alexandru Palalau

QA Contractor @ Yocto Project

Open-source Technology Center Romania

System Software Division








_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
Alexandru Palalau


FW: Weekly Test Report for Yocto 1.4 20121114 Build on non-x86 platforms

Palalau, AlexandruX <alexandrux.palalau@...>
 

Hello,

 

Below are the test results for Yocto 1.4 20121114 build.

There are some bugs for Beagleboard and P1022DS BSPs and two CoreBuildSystem multilib bugs.

Other than that, ADT Bug 3338 regarding autoreconf run failing on game-toolchain.

 

Test Summary
-------------------------

Test Result Summary

Component

Target

Status

Comments

BSP

Beagleboard

GOOD

Video: black screen when playing video

 

Routerstationpro

GOOD

Everything runs well

 

Mpc8315e-rdb

GOOD

Everything runs well

P1022DS

BUGGY

Udev error: can not mount harddisk and usb stick; Some error messages with dmesg

QEMU

qemuarm

GOOD

Everything runs well

 

qemuppc

GOOD

Everything runs well

 

qemumips

GOOD

Everything runs well

Core Build System

GOOD

Bug 3440 - Multilib build triggers warnings
Bug 3453 - Build fails when building multilib with ipk packaging

ADT Toolchain

BUGGY

iptables-1.4.15: autoreconf run failed on gmae-toolchain

HOB

 

GOOD

Everything runs well

 

BLOCK

Critical bugs, more than 50% test cases are blocked

GOOD

Only Normal, Minor or Enhancement bugs, less than 10% test cases failed

BUGGY

Normal, Major and Critical bugs, more than 10% test cases failed

 

Detailed Test Result for each component

Target

Total TCs

Not Run

Passed

Failed

Not testable (Blocked)

Beagleboard Sato-SDK

55

0

53

2 (bug 3458)

0

Routerstationpro Sato-SDK

32

0

32

0

0

Mpc8315e-rdb Sato-SDK

34

0

34

0

0

P1022DS

31

0

26

5 (bug 3451,3452)

0

Qemuarm Sato

31

0

31

0

0

Qemuarm Sato-SDK

36

0

36

0

0

Qemumips Sato

31

0

31

0

0

Qemumips Sato-SDK

36

0

36

0

0

Qemuppc Sato

31

0

31

0

0

Qemuppc Sato-SDK

36

0

36

0

0

Core Build System

42

0

40

2(bug 3440,bug3453)

0

ADT Toolchain

52

0

51

1 (bug 3338)

0

HOB

17

0

17

0

0

Total

464

0

454

10

0


* You can check the detailed test result in attachment for each target.
** The failed/blocked case number is listed with failed cases bug number.


Commit information
--------------------------------

Location: http://autobuilder.yoctoproject.org/pub/nightly/20121114-1/
Tree/Branch: poky/master
Poky: 1fd9a16d2a4594a4e9179dc7353ac51ce32eb712


Issue Summary
-----------------------------------

Component

Bug Number

Target Milestone

System & Core OS

System Usage

New! Bug 3458 Beagleboard: No pictures shown when playing video
New! Bug 3452 [p1022ds] udev error: can not mount harddisk and usb stick
New! Bug 3451 [p1022ds] Some error messages with dmesg

---
1.4
1.4 M1

Others

Bug 2766 coreutils build error with long TMPDIR: Argument list too long 
Bug 2759 qt4-native-4.8.1-r14.1 build error with long TMPDIR: initializer-string for array of chars is too long [-fpermissive]

1.4 M1
1.4

Core Build System

Bug 3440 - Multilib build triggers warnings
Bug 3453 - Build fails when building multilib with ipk packaging

1.4
1.4

ADT Toolchain

Bug 3338 iptables-1.4.15: autoreconf run failed on gmae-toolchain

1.4 M1

 

 

Best Regards,


--

Alexandru Palalau

QA Contractor @ Yocto Project

Open-source Technology Center Romania

System Software Division







Minutes: Yocto Project Technical Team Meeting - Tuesday, November 20, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

Liu, Song <song.liu@...>
 

Attendees:
Nitin, Ramana, ErenT, Saul, Beth, Daren, JeffP, TomZ, PaulE, DavidW, DaveST, ChrisL, BjornS, ScottR, Nitin, MihaiL, MarkH, BruceA, Amit, Denys, JessicaZ, RP, Song
 
Minutes:
 
* Opens collection - 5 min (Song)
* Yocto 1.4 status - 20 min (Song/team)
. Status update in Bugzilla: please update status by Monday morning. Use the status field please.
. Always schedule the features with higher priority first.
. Things in master:
opkg: added alternative ln patch. Use 'ln -n' to avoid dereferencing links to host files.
Python: resolve intermediate staging issues, simplifying python recipe and the compile process.
Fixed a bug in make-3.82 for archive expression expansion.
Initial integration of python-smartpm recipe for SMART updater.
Various bitbake improvement including ensuring last tasks are displayed correctly in the footer, remove obsolete console log code, add error to return of runCommand, etc.
Various HOB improvement such as saving proxy settings, adding a button for network testing, UI improvement around progress bar, etc.
Share state improvement, allow only partial installation, speed up things in some cases.
colorize the bitbake console output
Reduce the amount directories when searching. patches on the mailing list.
. 1.4 M1 feature complete: Nov. 25th. Running full pass testing this week.
. Master status: Building, there was an issue for QT, looking at it now. Will have the build ready for QA this week.

 
* SWAT team rotation: Jessica -> Ross
 
* Opens - 10 min
- Eren docs: finished hello-world doc (http://erenturkay.com/doc/from-bitbake-to-image/), would like to feedback. It's ok to be independent or integrated into existing YP docs. ScottR to follow up With Eren.
- RP: various notes about profiling (bitbake). There is wiki page (https://wiki.yoctoproject.org/wiki/Profiling), working in progress. Hopefully to integrate something to bitbake manual. Tom is working on profiling for the target system.
- Dave: offline configuration tool. Ramana: would like to take it to the next step. RP: encourage people to talk to each other. Mark and Darren posted something that could be overlapping with this. Suggest Ramana, Mark and Darren to talk.
- Bjorn: patches for package testing coming, first glib dbus testing.
 
* Team Sharing - 20 min
- DavidW: share experience building with a toolchain on a shared file system (Samba). 3min vs. 8min. Will try to reconfig shared storage. Michael: NFS worked well for us.
- MichaelH: Added new status values in Bugzilla and regression types for bugs. Will add hover text for the definition of regression types. meta-intel BSPs released, helped in that process. Working on some code review tools. Went over who has access to the security bugs, added some people. Let me know if anyone else needs access that.
- ScottR: had a meeting with Huawei, engaging with them, they would like to start contributing to YP documentation. Will be working with them.
- Eren: getting the security bug in advance, it would be very helpful. security question. RP: we are in cc? list, can we go one step further, join some other list so that we can get warnings earlier. We started from base level, no plans, but if anyone can get us in that circle it would be great. Song will pass this on to ScottG and CC Mark.


build error since commit: gcc: Use FILESPATH instead of FILESDIR and cleanup/simplify

Nicolas Dechesne <ndec13@...>
 

hello,

i was attempting a rebuild from scratch with today's master of poky, and i was facing issues such as:

WARNING: Failed to fetch URL file://gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch, attempting MIRRORS if available
ERROR: Fetcher failure: Unable to find file file://gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch anywhere. The paths that were searched were:
    /yocto/poky/meta/recipes-devtools/gcc/gcc-4.7.2
    /yocto/build-poky-master/downloads
ERROR: Function failed: Fetcher failure for URL: 'file://gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch'. Unable to fetch URL from any source.

This seems to be since this commit:

commit 90616875b432a932415063b08497266e70c49d75
Author: Richard Purdie <richard.purdie@...>
Date:   Mon Nov 19 21:18:52 2012 +0000

    gcc: Use FILESPATH instead of FILESDIR and cleanup/simplify
    
    Signed-off-by: Richard Purdie <richard.purdie@...>

and looking at a similar patch sent to oe-core (http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/29668) not merged yet, the following patch fixes my problem...

--- a/meta/recipes-devtools/gcc/gcc-4.7.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.7.inc
@@ -18,6 +18,8 @@ PV = "4.7.2"

 BINV = "4.7.2"

+FILESPATH = "${FILE_DIRNAME}/gcc-4.7"
+
 DEPENDS =+ "mpfr gmp libmpc"
 NATIVEDEPS = "mpfr-native gmp-native libmpc-native zlib-native"

without that, bitbake is looking for 'file://xxx' from recipe in the wrong folder (e.g. gcc-4.7.2 instead of gcc-4.7)

is there anything that i am overlooking here?

cheers

nicolas


Re: is anyone getting pathetic git download from the new kmod SRC_URI?

Robert P. J. Day
 

On Tue, 20 Nov 2012, Gary Thomas wrote:

On 2012-11-20 14:08, Robert P. J. Day wrote:
On Tue, 20 Nov 2012, Tom Zanussi wrote:

On Tue, 2012-11-20 at 15:27 -0500, Robert P. J. Day wrote:
maybe it's something i'm doing, but oe-core just changed the SRC_URI
for kmod to git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git,
and the response from the URL couldn't suck any worse than if it
sucked totally. i've yet to get a successful clone.

thoughts? is that working fine for others?
No problems here:

[trz@empanada tmp]$ time git clone
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
Cloning into 'kmod'...
remote: Counting objects: 4003, done.
remote: Compressing objects: 100% (1599/1599), done.
remote: Total 4003 (delta 2811), reused 3196 (delta 2264)
Receiving objects: 100% (4003/4003), 4.59 MiB | 850 KiB/s, done.
Resolving deltas: 100% (2811/2811), done.

real 0m7.183s
user 0m0.361s
sys 0m0.429s
i can't explain it -- i've yet to have a successful clone from that
URL. hangs partway through every time.
Maybe it's a routing thing - where are you located?

n.b. it just worked for me - in about the same <10 seconds
left where i was, tried again sitting at the bar with a pint of
dutch pilsner, and it worked fine. i'm sure it's the pilsner.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: is anyone getting pathetic git download from the new kmod SRC_URI?

Gary Thomas
 

On 2012-11-20 14:08, Robert P. J. Day wrote:
On Tue, 20 Nov 2012, Tom Zanussi wrote:

On Tue, 2012-11-20 at 15:27 -0500, Robert P. J. Day wrote:
maybe it's something i'm doing, but oe-core just changed the SRC_URI
for kmod to git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git,
and the response from the URL couldn't suck any worse than if it
sucked totally. i've yet to get a successful clone.

thoughts? is that working fine for others?
No problems here:

[trz@empanada tmp]$ time git clone git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
Cloning into 'kmod'...
remote: Counting objects: 4003, done.
remote: Compressing objects: 100% (1599/1599), done.
remote: Total 4003 (delta 2811), reused 3196 (delta 2264)
Receiving objects: 100% (4003/4003), 4.59 MiB | 850 KiB/s, done.
Resolving deltas: 100% (2811/2811), done.

real 0m7.183s
user 0m0.361s
sys 0m0.429s
i can't explain it -- i've yet to have a successful clone from that
URL. hangs partway through every time.
Maybe it's a routing thing - where are you located?

n.b. it just worked for me - in about the same <10 seconds

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------


Re: is anyone getting pathetic git download from the new kmod SRC_URI?

Robert P. J. Day
 

On Tue, 20 Nov 2012, Tom Zanussi wrote:

On Tue, 2012-11-20 at 15:27 -0500, Robert P. J. Day wrote:
maybe it's something i'm doing, but oe-core just changed the SRC_URI
for kmod to git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git,
and the response from the URL couldn't suck any worse than if it
sucked totally. i've yet to get a successful clone.

thoughts? is that working fine for others?
No problems here:

[trz@empanada tmp]$ time git clone git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
Cloning into 'kmod'...
remote: Counting objects: 4003, done.
remote: Compressing objects: 100% (1599/1599), done.
remote: Total 4003 (delta 2811), reused 3196 (delta 2264)
Receiving objects: 100% (4003/4003), 4.59 MiB | 850 KiB/s, done.
Resolving deltas: 100% (2811/2811), done.

real 0m7.183s
user 0m0.361s
sys 0m0.429s
i can't explain it -- i've yet to have a successful clone from that
URL. hangs partway through every time.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================