Date   

Cannot do atom-pc build with meta-cedartrail

Ross Burton
 

Hi,

If I add meta-intel and meta-cedartrail to my bblayers, when I try and
do an atom-pc build (which I thought should still work, right?) I get
the following error:

NOTE: Error during finalise of
/home/ross/Yocto/poky/meta/recipes-kernel/linux/linux-yocto_3.0.bb
ERROR: ExpansionError during parsing
/home/ross/Yocto/poky/meta/recipes-kernel/linux/linux-yocto_3.0.bb:
Failure expanding variable SRCPV, expression was
${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError:
Fetcher failure for URL:
'git://git.yoctoproject.org/linux-yocto-3.0;protocol=git;bareclone=1;branch=yocto/standard/common-pc/atom-pc,meta,yocto/pvr;name=machine,meta,pvr'.
Please set SRCREV to a valid value

That's a bug, right?

Ross


Re: Yocto Bug Trend ww38

Serban, Laurentiu <laurentiu.serban@...>
 

Hello,

Yes they can be separated from the Medium bugs (now they are all counted together).

Also if we want their “weight” to differ from the Medium ones we can change that too (I would suggest from 1.4 on)

 

Br,

Laurentiu

 

From: Stewart, David C
Sent: Thursday, September 27, 2012 1:22 AM
To: Serban, Laurentiu; yocto@...
Subject: Re: [yocto] Yocto Bug Trend ww38

 

I just noticed that the open bug trends don't call out the medium+ bugs. Can these be added?

 

From: <Serban>, Laurentiu Serban <laurentiu.serban@...>
Date: Monday, September 24, 2012 2:32 PM
To: "yocto@..." <yocto@...>
Subject: [yocto] Yocto Bug Trend ww38

 

Hello,

 

The Yocto Bug Trend was updated for ww38 https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend

 

Br,

 

Laurentiu Serban

QA Engineer

Open Source Technology Center

System Software Division Romania

Desk: +40 31 8604742

iNET: 88451042

 


Re: Yocto info

Zhang, Jessica
 

Hi Joy and Kishore,

 

2 things you need to fix/check:

 

1.       Please extract your toolchain to /opt/poky, basically go to your root directory “/” and run “sudo tar –xvjf path to your toolchain tar ball”.  Extract toolchain to a user specified directory is a feature of 1.3 so your 1.2.1 toolchain won’t support it. 

2.       Base on the error seems your toolchain and your target arch is mismatch, for example if your toolchain is i686-arm(host x86 32bits and target arm) and you set your target arch as i586, then it won’t work.

 

All the toolchain and sysroot setup is clearly documented in our ADT user manual please follow the steps list there.

 

Thanks,

Jessica

 

From: Bodke, Kishore K
Sent: Wednesday, September 26, 2012 4:24 PM
To: Shetler, Joy; Zhang, Jessica
Cc: yocto@...; Stewart, David C
Subject: RE: Yocto info

 

Copying to the Yocto Mailing list.

 

Is anyone familiar with Eclipse tool  and Yocto Project ADT?

 

Thanks

Kishore.

 

From: Shetler, Joy
Sent: Wednesday, September 26, 2012 4:14 PM
To: Bodke, Kishore K
Subject: FW: Yocto info

 

Kishore,

This is a company that is building several thousand embedded boards for ISG.  They are having trouble setting up the Eclipse tool.

 

Can you help with this?

Yours,

Joy

 

From: Terasic - David Wei [mailto:david@...]
Sent: Wednesday, September 26, 2012 4:08 PM
To: Shetler, Joy
Subject: Re: Yocto info

 

Hello Joy,

We are having a little problem, as shown in the attachment where we expect both toolchain and host arch to be x32, but we keep getting error.

Is there a document to guide the settings step by step ? If not, have you encountered this problem before and how did you solve it ?

Thanks,

David

On 2012/9/26 上午 12:04, Shetler, Joy wrote:

David,

 

Yes, you can use Linux drivers in the Yocto build.  You do not need a driver that is specially designed for Yocto.

 

We are building a Yocto image for Cedarview that will be targeted for the DE2i-150 board.  I have been setting up the tools and environment to do this.

 

Yours,

Joy

 

From: Terasic - David Wei [mailto:david@...]
Sent: Tuesday, September 25, 2012 5:37 AM
To: Shetler, Joy
Subject: Re: Yocto info

 

Hello Joy,

It seems this one has kernal of Cedarview and driver of VGA only. It's missing drivers for other peripherals. Do you know where we can get the rest drivers on Yocto ?

By the way, do you know if the driver of HDMI and PCIe WiFi under Yocto is available ? If so, could you help us build the custom image when the time comes ?

Many thanks,

David

On 2012/9/12 上午 02:00, Shetler, Joy wrote:

The description below is for a Yocto binary file in the BSP package. on how to obtain a copy of the BSP binary for CedarView.

1.1.1                             Linux - Yocto distribution

The Yocto project is

http://www.yoctoproject.org/

 

A BSP (Board Support Package) for the

 Yocto distribution is available on the following webpage:

http://www.yoctoproject.org/download

 

Select the BSP download page from there.

 

 

The BSP package for the Intel® Atom™ Processor N2000 and D2000 Series-based Platform (CEDAR TRAIL) with PowerVR Graphics, which supports CedarView is available on the download page (as shown next).

 

Steps to use binaries w/o modification:

Get a USB based Flash storage device.

Copy the tarball onto a “host” Unix system.

Untar – tar –svfj <tarball_file_name>

Mount the device on a “host” Linux system.

Use the commands provided in the README file to setup the binary on the USB device as a “bootable” image.

 

The latest version available for CedarView is the following:

This can be used as a starting point for checking out the system.  Linux SW drivers can be added.

 

There are some limitations on long term usage.  So, ideally a new image needs to be developed specifically for the DE2i-150 board.

 

Yours,

Joy

 

 


Re: Yocto info

Bodke, Kishore K <kishore.k.bodke@...>
 

Copying to the Yocto Mailing list.

 

Is anyone familiar with Eclipse tool  and Yocto Project ADT?

 

Thanks

Kishore.

 

From: Shetler, Joy
Sent: Wednesday, September 26, 2012 4:14 PM
To: Bodke, Kishore K
Subject: FW: Yocto info

 

Kishore,

This is a company that is building several thousand embedded boards for ISG.  They are having trouble setting up the Eclipse tool.

 

Can you help with this?

Yours,

Joy

 

From: Terasic - David Wei [mailto:david@...]
Sent: Wednesday, September 26, 2012 4:08 PM
To: Shetler, Joy
Subject: Re: Yocto info

 

Hello Joy,

We are having a little problem, as shown in the attachment where we expect both toolchain and host arch to be x32, but we keep getting error.

Is there a document to guide the settings step by step ? If not, have you encountered this problem before and how did you solve it ?

Thanks,

David

On 2012/9/26 上午 12:04, Shetler, Joy wrote:

David,

 

Yes, you can use Linux drivers in the Yocto build.  You do not need a driver that is specially designed for Yocto.

 

We are building a Yocto image for Cedarview that will be targeted for the DE2i-150 board.  I have been setting up the tools and environment to do this.

 

Yours,

Joy

 

From: Terasic - David Wei [mailto:david@...]
Sent: Tuesday, September 25, 2012 5:37 AM
To: Shetler, Joy
Subject: Re: Yocto info

 

Hello Joy,

It seems this one has kernal of Cedarview and driver of VGA only. It's missing drivers for other peripherals. Do you know where we can get the rest drivers on Yocto ?

By the way, do you know if the driver of HDMI and PCIe WiFi under Yocto is available ? If so, could you help us build the custom image when the time comes ?

Many thanks,

David

On 2012/9/12 上午 02:00, Shetler, Joy wrote:

The description below is for a Yocto binary file in the BSP package. on how to obtain a copy of the BSP binary for CedarView.

1.1.1                             Linux - Yocto distribution

The Yocto project is

http://www.yoctoproject.org/

 

A BSP (Board Support Package) for the

 Yocto distribution is available on the following webpage:

http://www.yoctoproject.org/download

 

Select the BSP download page from there.

 

 

The BSP package for the Intel® Atom™ Processor N2000 and D2000 Series-based Platform (CEDAR TRAIL) with PowerVR Graphics, which supports CedarView is available on the download page (as shown next).

 

Steps to use binaries w/o modification:

Get a USB based Flash storage device.

Copy the tarball onto a “host” Unix system.

Untar – tar –svfj <tarball_file_name>

Mount the device on a “host” Linux system.

Use the commands provided in the README file to setup the binary on the USB device as a “bootable” image.

 

The latest version available for CedarView is the following:

This can be used as a starting point for checking out the system.  Linux SW drivers can be added.

 

There are some limitations on long term usage.  So, ideally a new image needs to be developed specifically for the DE2i-150 board.

 

Yours,

Joy

 

 


Re: Yocto Bug Trend ww38

David Stewart
 

I just noticed that the open bug trends don't call out the medium+ bugs. Can these be added?

From: <Serban>, Laurentiu Serban <laurentiu.serban@intel.com<mailto:laurentiu.serban@intel.com>>
Date: Monday, September 24, 2012 2:32 PM
To: "yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>" <yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>>
Subject: [yocto] Yocto Bug Trend ww38

Hello,

The Yocto Bug Trend was updated for ww38 https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend

Br,

Laurentiu Serban
QA Engineer
Open Source Technology Center
System Software Division Romania
Desk: +40 31 8604742
iNET: 88451042


Re: 1.3_M5.rc2 status.

Wolfgang Denk <wd@...>
 

Dear Chris,

In message <CABcZANmPe_D+GPWxnkVZCmE9ti011ZDSXxPix8ztW4vrdYiyZA@mail.gmail.com> you wrote:

Well, the comment in "meta-yocto/conf/bblayers.conf.sample" says:

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly

This suggests that such changes are not exactly unusual. But any such
change will cause the build to fail, because the sanity checker uses a
different value.
This is wrong. A compatibility break in bblayers.conf is *extremely* rare.

If such a change is allowed and is done intentionally, then it should
be considered "sane", and the sanity checker should not complain.
Wrong. The user has to know that they may need to change their
bblayers.conf to match the upstream structure. If it didn't complain,
they could silently break or encounter unexpected behavior.
Sorry, but I don't get how this is supposed to work.

I have an incompatible change, and increase LAYER_CONF_VERSION in my
meta layer's bblayers.conf.sample . When sourcing oe-init-build-env,
this file gets copied to the build dir as conf/bblayers.conf.
Building with this setting fails, because the samity checker does not
accept the value. So I have to actually undo the change I made in
bblayers.conf.sample to make it build.

My internal sanity checker barfs on such logic...

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Tell the truth and run." - Yugoslav proverb


Re: 1.3_M5.rc2 status.

Chris Larson <clarson@...>
 

On Wed, Sep 26, 2012 at 11:36 AM, Wolfgang Denk <wd@denx.de> wrote:
By "better way to deal with these", what would you suggest? I don't see any
alternative that avoids the BSP components just disappearing for users who
have existing configurations.
Well, the comment in "meta-yocto/conf/bblayers.conf.sample" says:

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly

This suggests that such changes are not exactly unusual. But any such
change will cause the build to fail, because the sanity checker uses a
different value.
This is wrong. A compatibility break in bblayers.conf is *extremely* rare.

If such a change is allowed and is done intentionally, then it should
be considered "sane", and the sanity checker should not complain.
Wrong. The user has to know that they may need to change their
bblayers.conf to match the upstream structure. If it didn't complain,
they could silently break or encounter unexpected behavior.

The problem (and the longer I think about it the less I hesitate to
call it a plain bug) is that we allow for meta layer specific values
of LAYER_CONF_VERSION, while still assuming a single hard-coded
value in meta/conf/sanity.conf could be used as reference.

This _cannot_ work.

But when I'm supposed to overwrite the setting (to match the sanity
checker's expectations) in my local conf/bblayers.conf, then why do we
bother to set a dieferent value in the meta layer in the first place?
And hey, why do we check this value at all if all we can do is always
make it match manually?
Not everyone using oe-core (meta) also uses meta-yocto. Only those
using the latter were affected by this particular upstream structure
change.

I understand the intention, but the current implementation is just
broken, and I don't see a way to fix it. It would probably be better
to remove this test than to leave it as is.
Again, that'd leave the user with a bblayers.conf that may no longer
do what they intended it to do. Better to fail than potentially build
in ways not matching the user's previous expectations.
--
Christopher Larson


Re: 1.3_M5.rc2 status.

Wolfgang Denk <wd@...>
 

Dear Paul,

In message <224780988.1nyHnvScgz@helios> you wrote:

If meta layer specific values of LAYER_CONF_VERSION are allowed, the
sanity checker needs a better way to deal with these; alternatively,
above setting in meta-yocto/conf/distro/poky.conf is wrong. So either
of these should be fixed.
By "better way to deal with these", what would you suggest? I don't see any
alternative that avoids the BSP components just disappearing for users who
have existing configurations.
Well, the comment in "meta-yocto/conf/bblayers.conf.sample" says:

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly

This suggests that such changes are not exactly unusual. But any such
change will cause the build to fail, because the sanity checker uses a
different value.

If such a change is allowed and is done intentionally, then it should
be considered "sane", and the sanity checker should not complain.

The problem (and the longer I think about it the less I hesitate to
call it a plain bug) is that we allow for meta layer specific values
of LAYER_CONF_VERSION, while still assuming a single hard-coded
value in meta/conf/sanity.conf could be used as reference.

This _cannot_ work.

But when I'm supposed to overwrite the setting (to match the sanity
checker's expectations) in my local conf/bblayers.conf, then why do we
bother to set a dieferent value in the meta layer in the first place?
And hey, why do we check this value at all if all we can do is always
make it match manually?

I understand the intention, but the current implementation is just
broken, and I don't see a way to fix it. It would probably be better
to remove this test than to leave it as is.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If a packet hits a pocket on a socket on a port,
And the bus is interrupted as a very last resort,
And the address of the memory makes your floppy disk abort,
Then the socket packet pocket has an error to report! - Ken Burchill?


Re: 1.3_M5.rc2 status.

Paul Eggleton
 

On Wednesday 26 September 2012 16:20:45 Wolfgang Denk wrote:
Dear Paul Eggleton,
In message <2428256.OTjtN2nWn5@helios> you wrote:
Ah, OK. Well, I decided to update meta/conf/sanity.conf to have a
matching value of LAYER_CONF_VERSION, so this is solved.
That will work, but normally you would edit conf/bblayers.conf, since
meta/conf/sanity.conf is part of the metadata.
Well, what is the rationale for setting LAYER_CONF_VERSION=6 in
meta-yocto/conf/distro/poky.conf, then?
The rationale is for this specific increase is this: if you previously had
meta-yocto in your existing bblayers.conf, since the reference BSP parts of
meta-yocto were split out into meta-yocto-bsp for the upcoming release, you
now need to add that layer to get the same functionality back. So we use this
mechanism to get users to do that.

If meta layer specific values of LAYER_CONF_VERSION are allowed, the
sanity checker needs a better way to deal with these; alternatively,
above setting in meta-yocto/conf/distro/poky.conf is wrong. So either
of these should be fixed.
By "better way to deal with these", what would you suggest? I don't see any
alternative that avoids the BSP components just disappearing for users who
have existing configurations.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Re: 1.3_M5.rc2 status.

Chris Larson <clarson@...>
 

On Wed, Sep 26, 2012 at 7:20 AM, Wolfgang Denk <wd@denx.de> wrote:
In message <2428256.OTjtN2nWn5@helios> you wrote:

Ah, OK. Well, I decided to update meta/conf/sanity.conf to have a
matching value of LAYER_CONF_VERSION, so this is solved.
That will work, but normally you would edit conf/bblayers.conf, since
meta/conf/sanity.conf is part of the metadata.
Well, what is the rationale for setting LAYER_CONF_VERSION=6 in
meta-yocto/conf/distro/poky.conf, then?

If meta layer specific values of LAYER_CONF_VERSION are allowed, the
sanity checker needs a better way to deal with these; alternatively,
above setting in meta-yocto/conf/distro/poky.conf is wrong. So either
of these should be fixed.
They're both set exactly the way they should be. You're only affected
by the bblayers compatibility change if you use poky, as far as I'm
aware.
--
Christopher Larson


Re: 1.3_M5.rc2 status.

Wolfgang Denk <wd@...>
 

Dear Paul Eggleton,

In message <2428256.OTjtN2nWn5@helios> you wrote:

Ah, OK. Well, I decided to update meta/conf/sanity.conf to have a
matching value of LAYER_CONF_VERSION, so this is solved.
That will work, but normally you would edit conf/bblayers.conf, since
meta/conf/sanity.conf is part of the metadata.
Well, what is the rationale for setting LAYER_CONF_VERSION=6 in
meta-yocto/conf/distro/poky.conf, then?

If meta layer specific values of LAYER_CONF_VERSION are allowed, the
sanity checker needs a better way to deal with these; alternatively,
above setting in meta-yocto/conf/distro/poky.conf is wrong. So either
of these should be fixed.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Build a system that even a fool can use and only a fool will want to
use it.


Re: 1.3_M5.rc2 status.

Paul Eggleton
 

On Wednesday 26 September 2012 15:28:51 Wolfgang Denk wrote:
In message <1767865.bvfduhkKG5@helios> you wrote:
On Wednesday 26 September 2012 15:06:53 Wolfgang Denk wrote:
this is expected, at the moment you need to follow the instructions
and make the appropriate changes to your conf/bblayers.conf. However,
there is a patch out for review that we would like to include for the
1.3
final release which will take care of this automatically for you.
Thanks. Please excuse my ignorance: where would I find the respective
instructions?
It does have some very brief instructions in the error message:
Please compare the two files and merge any changes before
continuing.
Matching the version numbers will remove this message.
"meld conf/bblayers.conf
/home/wd/git/eldk-5.3/meta*/conf/bblayers.conf.sample" is a good way
to visualise the changes.
I appreciate this is not as helpful as it could be, hence why we are
working to do this automatically for the user.
Ah, OK. Well, I decided to update meta/conf/sanity.conf to have a
matching value of LAYER_CONF_VERSION, so this is solved.
That will work, but normally you would edit conf/bblayers.conf, since
meta/conf/sanity.conf is part of the metadata.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Re: 1.3_M5.rc2 status.

Wolfgang Denk <wd@...>
 

Dear Paul,

In message <1767865.bvfduhkKG5@helios> you wrote:
On Wednesday 26 September 2012 15:06:53 Wolfgang Denk wrote:
this is expected, at the moment you need to follow the instructions
and make the appropriate changes to your conf/bblayers.conf. However,
there is a patch out for review that we would like to include for the 1.3
final release which will take care of this automatically for you.
Thanks. Please excuse my ignorance: where would I find the respective
instructions?
It does have some very brief instructions in the error message:

Please compare the two files and merge any changes before continuing.
Matching the version numbers will remove this message.
"meld conf/bblayers.conf
/home/wd/git/eldk-5.3/meta*/conf/bblayers.conf.sample" is a good way
to visualise the changes.
I appreciate this is not as helpful as it could be, hence why we are working
to do this automatically for the user.
Ah, OK. Well, I decided to update meta/conf/sanity.conf to have a
matching value of LAYER_CONF_VERSION, so this is solved.

Sorry, I misinterpreted your note and expected any additional
instructions for building 1.3_M5

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
In the pitiful, multipage, connection-boxed form to which the flow-
chart has today been elaborated, it has proved to be useless as a
design tool -- programmers draw flowcharts after, not before, writing
the programs they describe. - Fred Brooks, Jr.


Re: 1.3_M5.rc2 status.

Paul Eggleton
 

On Wednesday 26 September 2012 15:06:53 Wolfgang Denk wrote:
this is expected, at the moment you need to follow the instructions
and make the appropriate changes to your conf/bblayers.conf. However,
there is a patch out for review that we would like to include for the 1.3
final release which will take care of this automatically for you.
Thanks. Please excuse my ignorance: where would I find the respective
instructions?
It does have some very brief instructions in the error message:

Please compare the two files and merge any changes before continuing.
Matching the version numbers will remove this message.
"meld conf/bblayers.conf
/home/wd/git/eldk-5.3/meta*/conf/bblayers.conf.sample" is a good way
to visualise the changes.
I appreciate this is not as helpful as it could be, hence why we are working
to do this automatically for the user.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Re: 1.3_M5.rc2 status.

Wolfgang Denk <wd@...>
 

Dear Paul Eggleton,

In message <10067256.0vCsjtRvv5@helios> you wrote:

Am I doing anyhting wrong?
No, this is expected, at the moment you need to follow the instructions and
make the appropriate changes to your conf/bblayers.conf. However, there is a
patch out for review that we would like to include for the 1.3 final release
which will take care of this automatically for you.
Thanks. Please excuse my ignorance: where would I find the respective
instructions?

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Misquotation is, in fact, the pride and privilege of the learned. A
widely-read man never quotes accurately, for the rather obvious
reason that he has read too widely.
- Hesketh Pearson _Common Misquotations_ introduction


Re: 1.3_M5.rc2 status.

Paul Eggleton
 

Hi Wolfgang,

On Wednesday 26 September 2012 13:39:00 Wolfgang Denk wrote:
This commit has:

meta-yocto/conf/distro/poky.conf:LAYER_CONF_VERSION ?= "6"

But:

meta/conf/sanity.conf:LAYER_CONF_VERSION ?= "5"


So for me the sanity checker bails out with:

ERROR: OE-core's config sanity checker detected a potential
misconfiguration. Either fix the cause of this error or at your own risk
disable the checker (see sanity.conf). Following is the list of potential
problems / advisories:

Your version of bblayers.conf was generated from an older version of
bblayers.conf.sample and there have been updates made to this file. Please
compare the two files and merge any changes before continuing. Matching the
version numbers will remove this message.
"meld conf/bblayers.conf
/home/wd/git/eldk-5.3/meta*/conf/bblayers.conf.sample" is a good way to
visualise the changes.

ERROR: Execution of event handler 'check_sanity_eventhandler' failed


Am I doing anyhting wrong?
No, this is expected, at the moment you need to follow the instructions and
make the appropriate changes to your conf/bblayers.conf. However, there is a
patch out for review that we would like to include for the 1.3 final release
which will take care of this automatically for you.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


[PATCH] meta-emenlow: add missing exa dependency

Ross Burton
 

The psb video drivers use the EXA framework, so add a dependency on
xserver-xorg-module-exa.

[YOCTO #3149]

Signed-off-by: Ross Burton <ross.burton@intel.com>
---
.../xserver-xorg-video-psb/xserver-xorg-video-psb_0.32.1.bb | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta-emenlow/recipes-graphics/xserver-xorg-video-psb/xserver-xorg-video-psb_0.32.1.bb b/meta-emenlow/recipes-graphics/xserver-xorg-video-psb/xserver-xorg-video-psb_0.32.1.bb
index 9de68f4..7972fcd 100644
--- a/meta-emenlow/recipes-graphics/xserver-xorg-video-psb/xserver-xorg-video-psb_0.32.1.bb
+++ b/meta-emenlow/recipes-graphics/xserver-xorg-video-psb/xserver-xorg-video-psb_0.32.1.bb
@@ -1,7 +1,7 @@
DESCRIPTION = "2D graphics driver for Poulsbo"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://MIT_License.txt;md5=732825ecdcf420261531d935fcd914a7"
-PR = "r2"
+PR = "r3"

inherit autotools

@@ -34,4 +34,6 @@ FILES_${PN} += "${libdir}/xorg/modules/drivers/libmm.so \

DEPENDS += "virtual/libgl virtual/xserver"

+RDEPENDS_${PN} = "xserver-psb-module-exa"
+
COMPATIBLE_MACHINE = "emenlow"
--
1.7.10


Re: 1.3_M5.rc2 status.

Wolfgang Denk <wd@...>
 

Dear "Flanagan, Elizabeth",

In message <CAPhnLPCYC9_xvdinu9=prhUOz8FfquYK5TVrBKiHLZ4FyK267g@mail.gmail.com> you wrote:

1.3_M5.rc2 was started a bit late today due to some miscommunication.
The build has begun and judging from recent autobuilder performance,
I'm expecting it to complete in about six and a half hours from now.
For those doing QA against 1.3_M5.rc2, if you can, please begin
testing what you can as soon as build artifacts become available.

Download: http://autobuilder.yoctoproject.org/pub/nightly/20120926-1
poky: 718eb85806e080d0b165344b272e531ef19421eb
This commit has:

meta-yocto/conf/distro/poky.conf:LAYER_CONF_VERSION ?= "6"

But:

meta/conf/sanity.conf:LAYER_CONF_VERSION ?= "5"


So for me the sanity checker bails out with:

ERROR: OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
Following is the list of potential problems / advisories:

Your version of bblayers.conf was generated from an older version of bblayers.conf.sample and there have been updates made to this file. Please compare the two files and merge any changes before continuing.
Matching the version numbers will remove this message.
"meld conf/bblayers.conf /home/wd/git/eldk-5.3/meta*/conf/bblayers.conf.sample" is a good way to visualise the changes.

ERROR: Execution of event handler 'check_sanity_eventhandler' failed


Am I doing anyhting wrong?

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Insufficient facts always invite danger.
-- Spock, "Space Seed", stardate 3141.9


Re: How can I build gstreamer and its plugins without x11?

Ross Burton
 

On 26 September 2012 00:12, Chris Tapp <opensource@keylevel.com> wrote:
This is due to 'inherit gconf'.
Which tells me that you are not using master but a release, presumably denzil.

Feel free to backport oe-core 6facee8443966b646cd1e72f14ae13e58a13f621
or poky e72157e71c7e3a823d83253f68a9af881e2ab2a0 ("gconf: Disable gtk
support").

Ross


Re: How can I build gstreamer and its plugins without x11?

Ross Burton
 

On 26 September 2012 08:32, Chris Tapp <opensource@keylevel.com> wrote:
Thanks Ross. Is the reference to librsvg in gst-plugins-bad similar? This pulls in gtk+ (which will not build for my DirectFB distro), but it still builds if I remove it.
librsvg has gtk+ as a build dependency but the librsvg library itself
won't depend on GTK+.

Ross