Okay, I have done a couple of things:

1. I appended to the base-passwd recipe and added my own patch that would patch the passwd file to have root use a bash shell. I have verified that this is the case when I login via echo $0. It tells me that root's shell is bash.

2. I have appended to the base-files recipe and added a do_install_append() function to my bbappend file that copies the dot.bashrc to /home/root/.bashrc. I have verified that this is taking place and the .bashrc file is actually in /home/root.

3. I ran 'strace -f bash' after logging in and /home/root/.bashrc is sourced (I saw it in the output and my aliases were available).

However, upon first login, it appears that /home/root/.bashrc is NOT sourced by bash. How can I get bash to source that file when I login at a console?

Thanks for the help!
Jonathan


________________________________________
From: yocto-bounces@... [yocto-bounces@...] on behalf of Mihai Lindner [mihaix.lindner@...]
Sent: Wednesday, October 17, 2012 02:29
To: yocto@...
Subject: Re: [yocto] .bashrc not being used by root account

On 10/17/2012 09:25 AM, Venkata ramana gollamudi wrote:

You can check the same with "strace -f bash"
You can see the files being loaded, as there is a rc file loading sequence exists for bash.

Regards,
Ramana

________________________________________
From: yocto-bounces@... [yocto-bounces@...] on behalf of Jonathan Haws [Jonathan.Haws@...]
Sent: Tuesday, October 16, 2012 9:32 PM
To: yocto@...
Subject: [yocto] .bashrc not being used by root account

I have modified the .bashrc file for the system, however the root account does not seem to use it by default. What am I missing? I would rather not have to source the .bashrc file every time I login as root.

Try `echo $0` to see the shell you're in. By default you should be in
`sh`, which does not source .bashrc.
You can execute `bash` after login, or change the login shell of 'root'.

Cheers,
--Mihai

Thanks,
Jonathan

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

--
Mihai Lindner
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto

On Thursday 18 October 2012 11:29:58 Marc Ferland wrote:

Martin Jansa <martin.jansa@...> writes:

On Thu, Oct 18, 2012 at 11:13:13AM -0400, Marc Ferland wrote:

Hi,

I'm having trouble generating the module auto-loading instructions in
/etc for one of my modules. I have already many modules that all work
fine, but for some reason this one does not get listed in /etc/modules
nor /etc/modules-load.d.

The only thing that distinguishes this module from the other ones is that
it has the same name has the MACHINE and layer. So basically I have
something like:

build/conf/local.conf:
MACHINE = foo

poky/meta-foo/conf/machine/foo.conf:
module_autoload_foo = "foo"

The module gets built correctly and is included in the images. Running
'modprobe foo' works as intended on the target hardware.

Did I fall in some edge case?

Does foo have any '-' or '_'?

No. Just lower case letters.
Marc

I suspect this is falling foul of OVERRIDES since it matches ${MACHINE} which
is in OVERRIDES. What the workaround would be for this I'm not sure.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

Martin Jansa <martin.jansa@...> writes:

On Thu, Oct 18, 2012 at 11:13:13AM -0400, Marc Ferland wrote:

Hi,

I'm having trouble generating the module auto-loading instructions in
/etc for one of my modules. I have already many modules that all work
fine, but for some reason this one does not get listed in /etc/modules
nor /etc/modules-load.d.

The only thing that distinguishes this module from the other ones is that
it has the same name has the MACHINE and layer. So basically I have
something like:

build/conf/local.conf:
MACHINE = foo

poky/meta-foo/conf/machine/foo.conf:
module_autoload_foo = "foo"

The module gets built correctly and is included in the images. Running
'modprobe foo' works as intended on the target hardware.

Did I fall in some edge case?

Does foo have any '-' or '_'?

No. Just lower case letters.
Marc

On Thu, Oct 18, 2012 at 11:13:13AM -0400, Marc Ferland wrote:

Hi,

I'm having trouble generating the module auto-loading instructions in
/etc for one of my modules. I have already many modules that all work
fine, but for some reason this one does not get listed in /etc/modules
nor /etc/modules-load.d.

The only thing that distinguishes this module from the other ones is that
it has the same name has the MACHINE and layer. So basically I have
something like:

build/conf/local.conf:
MACHINE = foo

poky/meta-foo/conf/machine/foo.conf:
module_autoload_foo = "foo"

The module gets built correctly and is included in the images. Running
'modprobe foo' works as intended on the target hardware.

Did I fall in some edge case?

Does foo have any '-' or '_'?

If yes then foo needs to match module name, not name of kernel
module package (where we always have '-').

Regards,

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

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

Hi,

I'm having trouble generating the module auto-loading instructions in
/etc for one of my modules. I have already many modules that all work
fine, but for some reason this one does not get listed in /etc/modules
nor /etc/modules-load.d.

The only thing that distinguishes this module from the other ones is that
it has the same name has the MACHINE and layer. So basically I have
something like:

build/conf/local.conf:
MACHINE = foo

poky/meta-foo/conf/machine/foo.conf:
module_autoload_foo = "foo"

The module gets built correctly and is included in the images. Running
'modprobe foo' works as intended on the target hardware.

Did I fall in some edge case?

Regards,

Marc

On 18 October 2012 10:33, Burton, Ross <ross.burton@...> wrote:

A concrete example might help. For example there is a "bluetooth"
machine feature that means bluez (the bluetooth daemon) is built and
added to the image, ConnMan enabled bluetooth support, and so on.

I say machine feature, I mean distro feature.

Ross

On 18 October 2012 10:20, Paul Eggleton <paul.eggleton@...> wrote:

I don't know the relationship between "features" and "packages"... maybe it
is a one-to-one relationship.

It's definitely not 1-1, and sometimes a feature doesn't just control the
installation of a package or packages, but influences how certain recipes are
built, e.g. it might determine whether a particular configure option is
specified within do_configure for a particular recipe.

A concrete example might help. For example there is a "bluetooth"
machine feature that means bluez (the bluetooth daemon) is built and
added to the image, ConnMan enabled bluetooth support, and so on.

Ross

On Wednesday 17 October 2012 21:07:20 Rifenbark, Scott M wrote:

Thanks for the added investigation here. The original bug report listed
COMMON_FEATURES as an undocumented variable. I see, however, that the
variable referred to by both you and Paul Eggleton is COMBINED_FEATURES. I
just did a grep through my entire poky tree, which had built out the
core-image-minimal image for the qemux86 MACHINE and came up empty for
"COMMON_FEATURES" except where the string is part of other variables. So,
it appears there is no COMMON_FEATURES variable.

According to Paul, COMBINED_FEATURES is a list of features common to both
MACHINE_FEATURES and DISTRO_FEATURES.

Yes, the variable is COMBINED_FEATURES.

It also seems that the lists presented in the documentation for both valid
distro and machine options are not really finite lists.

Correct, the list is not set in stone. People are free to add new features to
MACHINE_FEATURES and DISTRO_FEATURES in their own setups and check for them in
their own recipes/configuration files if it helps them handle different machines
they want to target or different types of distros they want to build
respectively. However, we should document all of the features we have defined
out of the box.

But, the fact that you grep'ed out such a huge list of
DF below shows that they far exceed the 16 features listed in the
documentation. I'll update the preamble to the "Distro" and "Machine"
sections in the reference manual when I get the real story on those lists.

I can try to help document all of the features. It's possible that some of
them that we refer to are effectively placeholders that don't do anything at
the moment (e.g. ipv6 in DISTRO_FEATURES).

I don't know the relationship between "features" and "packages"... maybe it
is a one-to-one relationship.

It's definitely not 1-1, and sometimes a feature doesn't just control the
installation of a package or packages, but influences how certain recipes are
built, e.g. it might determine whether a particular configure option is
specified within do_configure for a particular recipe.

But, there are some other variables that
affect packages and features (according to the documentation) that are
considered during the build. These are the ones listed in the manual's
glossary section:

* MACHINE_ESSENTIAL_EXTRA_RDEPENDS

* MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS

* MACHINE_EXTRA_RDEPENDS

* MACHINE_EXTRA-RRECOMMENDS

* DISTRO_EXTRA_RRECOMMENDS

Let's not muddy the waters too much here - these aren't directly related to
features although they are related to machine and distro configuration.

I suspect that there is a DISTRO_EXTRA_RDEPENDS variable as well but I don't
have it in the manual (should be added if so).

Yes, that exists and should be documented.

Also, not sure if there are variables for DISTRO_ESSENTIAL_EXTRA_RDEPENDS
and DISTRO_ESSENTIAL_EXTRA_RRECOMMENDS. If those really exist, then I need
to add them as well.

No, there are no such variables.

Finally, the BACKFILL variables also contribute to the MACHINE_FEATURES and
DISTRO_FEATURES set. It looks like *_FEATURES_BACKFILL, which is set in
the bitbake.conf file, is a way to make sure a feature is always included
as part of *_FEATURES. While *_BACKFILL_CONSIDERED is used in specific
machine configurations (<machine>.conf) to disable a particular feature
when it also appears with *_FEATURES_BACKFILL. So these variables add to
the mix also.

We have added the 9.4 section on "Feature backfilling" that should cover what
these are for and how they work. If the explanation there is not clear enough
then by all means lets enhance that section and/or the entries in the glossary
for these variables, but they are at least documented now.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

On 17 October 2012 22:58, Bodke, Kishore K <kishore.k.bodke@...> wrote:

Wanted to check if you had a chance to look into the cpu uitilization?
We had less than 15% cpu uitilization, with the acceleration while playing the video.

With sintel_trailer-720p.mp4 (and ffmpeg codecs so the audio is also
being decoded), 4% according to top.

Ross

From: Rahul Saxena <rahul.saxena@...>

Add header files from development packages

Signed-off-by: Rahul Saxena <Rahul.Saxena@...>
---
.../xorg-driver/cdv-pvr-driver_1.0.3.bb | 33 +++++++++++++++++++-
1 files changed, 32 insertions(+), 1 deletions(-)

diff --git a/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb b/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb
index 2f44649..e9d4ede 100644
--- a/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb
+++ b/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb
@@ -14,7 +14,7 @@ LIC_FILES_CHKSUM = " \

DEPENDS = "rpm-native libva"

-PR = "r3"
+PR = "r4"

PSB-VIDEO = "psb-video-cdv-1.0.3-1.1.i586.rpm"
PSB-VIDEO-REV = "1.0.3"
@@ -23,8 +23,10 @@ PVR-BIN = "pvr-bin-cdv-1.0.3-1.1.i586.rpm"
PVR-BIN-REV = "1.7.862890"
PVR-BIN-REV_N = "1.7.862890_05"
PVR-BIN-REV_LIC = "1.0.3"
+PVR-BIN-DEV = "pvr-bin-cdv-devel-1.0.3-1.1.i586.rpm"

LIBWSBM = "libwsbm-cdv-1.1.0-3.1.i586.rpm"
+LIBWSBM-DEV = "libwsbm-cdv-devel-1.1.0-3.1.i586.rpm"


NON-OSS-PATH = "http://repo.meego.com/MeeGo/updates/1.2.0/repos/non-oss/ia32/packages/"
@@ -33,17 +35,26 @@ OSS-PATH = "http://repo.meego.com/MeeGo/updates/1.2.0/repos/oss/ia32/package

SRC_URI = "${NON-OSS-PATH}${PSB-VIDEO};name=psbrpm;unpack=0 \
${NON-OSS-PATH}${PVR-BIN};name=pvrrpm;unpack=0 \
+ ${NON-OSS-PATH}${PVR-BIN-DEV};name=pvrrpmdev;unpack=0 \
${OSS-PATH}${LIBWSBM};name=wsbmrpm;unpack=0 \
+ ${OSS-PATH}${LIBWSBM-DEV};name=wsbmrpmdev;unpack=0 \
"
SRC_URI[pvrrpm.md5sum] = "3ae7db98825af642445f75f4b5ddb303"
SRC_URI[pvrrpm.sha256sum] = "42b97e5d663444f35b1ee51cdf9573e3b1d5a4f49ae854218c5c4c9a66ba95cf"

+SRC_URI[pvrrpmdev.md5sum] = "e8f0815b5bbf94311a7cf229451f651f"
+SRC_URI[pvrrpmdev.sha256sum] = "facb67f6b8413504e7ba570a4e3e3ee20cb90d7bd02b303653f9ce5cc4fd7b20"
+
SRC_URI[psbrpm.md5sum] = "ec486193dc4b3f91bc7c5e18d9ca9d8a"
SRC_URI[psbrpm.sha256sum] = "0861d69b44d5ce29a3f778ac82976a22f7726af84d9b2e5438c18da5263ffdac"

SRC_URI[wsbmrpm.md5sum] = "b8b21ca8325abd7850d197f9bf3071c7"
SRC_URI[wsbmrpm.sha256sum] = "f436386967c1adec5211e662251bd542bbe0b8cd55e1d9f9c203da5ee934d4f0"

+SRC_URI[wsbmrpmdev.md5sum] = "895d0cafd878fcbe4e2f845b8e09eea3"
+SRC_URI[wsbmrpmdev.sha256sum] = "605ba605a2617ee67863d5becac114ce7f4ea440854543f75465e16f463bad70"
+
+
# make sure generated rpm packages get non conflicting names
PKG_${PN} = "cdv-pvr-driver"
PKG_${PN}-dev = "cdv-pvr-driver-dev"
@@ -149,6 +160,26 @@ do_install() {
install -d -m 0755 ${D}${datadir}/doc/psb-video-cdv-${PSB-VIDEO-REV}
install -d -m 0755 ${D}${datadir}/doc/pvr-bin-cdv-${PVR-BIN-REV_N}

+ rpm2cpio.sh ${S}/${PVR-BIN-DEV} | cpio -id
+ install -d -m 0644 ${D}${includedir}
+ install -d -m 0644 ${D}${includedir}/GLES
+ install -d -m 0644 ${D}${includedir}/VG
+ install -d -m 0644 ${D}${includedir}/GLES2
+ install -d -m 0644 ${D}${includedir}/KHR
+ install -d -m 0644 ${D}${includedir}/EGL
+
+ install -m 0644 ${S}/${includedir}/GLES/*.h ${D}${includedir}/GLES
+ install -m 0644 ${S}/${includedir}/VG/*.h ${D}${includedir}/VG
+ install -m 0644 ${S}/${includedir}/GLES2/*.h ${D}${includedir}/GLES2
+ install -m 0644 ${S}/${includedir}/KHR/*.h ${D}${includedir}/KHR
+ install -m 0644 ${S}/${includedir}/EGL/*.h ${D}${includedir}/EGL
+
+ rpm2cpio.sh ${S}/${LIBWSBM-DEV} | cpio -id
+ install -d -m 0644 ${D}${includedir}/wsbm
+
+ install -m 0644 ${S}/${includedir}/wsbm/*.h ${D}${includedir}/wsbm
+ install -m 0644 ${S}/${libdir}/libwsbm.so ${D}${libdir}/libwsbm.so
+
install -m 0755 ${S}/usr/share/doc/psb-video-cdv-${PSB-VIDEO-REV}/license.txt ${D}${datadir}/doc/psb-video-cdv-${PSB-VIDEO-REV}/license.txt

}
--
1.7.4.1

From: Rahul Saxena <rahul.saxena@...>

cdv-pvr-driver was generating rpm packages with name "libwsbm"
This name can potentialy clash with other package names.
Fix this problem by specifying package names in the recipe with the
PKG_ vars
This fixes bug: [YOCTO #3286]

Signed-off-by: Rahul Saxena <rahul.saxena@...>
---
.../xorg-driver/cdv-pvr-driver_1.0.3.bb | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb b/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb
index cd3407c..2f44649 100644
--- a/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb
+++ b/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb
@@ -14,7 +14,7 @@ LIC_FILES_CHKSUM = " \

DEPENDS = "rpm-native libva"

-PR = "r2"
+PR = "r3"

PSB-VIDEO = "psb-video-cdv-1.0.3-1.1.i586.rpm"
PSB-VIDEO-REV = "1.0.3"
@@ -44,6 +44,12 @@ SRC_URI[psbrpm.sha256sum] = "0861d69b44d5ce29a3f778ac82976a22f7726af84d9b2e5438c
SRC_URI[wsbmrpm.md5sum] = "b8b21ca8325abd7850d197f9bf3071c7"
SRC_URI[wsbmrpm.sha256sum] = "f436386967c1adec5211e662251bd542bbe0b8cd55e1d9f9c203da5ee934d4f0"

+# make sure generated rpm packages get non conflicting names
+PKG_${PN} = "cdv-pvr-driver"
+PKG_${PN}-dev = "cdv-pvr-driver-dev"
+PKG_${PN}-dbg = "cdv-pvr-driver-dbg"
+PKG_${PN}-doc = "cdv-pvr-driver-doc"
+
S = "${WORKDIR}/cdv-graphics-drivers_${PV}"

# These are closed binaries generated elsewhere so don't check ldflags
--
1.7.4.1

From: Rahul Saxena <rahul.saxena@...>

Add CPU and Chipset product names. Explicitly state support for Gfx & Media
acceleration.

Signed-off-by: Rahul Saxena <rahul.saxena@...>
---
meta-cedartrail/README | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/meta-cedartrail/README b/meta-cedartrail/README
index 81a1260..bd00d19 100755
--- a/meta-cedartrail/README
+++ b/meta-cedartrail/README
@@ -2,6 +2,13 @@ This README file contains information on building the meta-cedartrail
BSP layer, and booting the images contained in the /binary directory.
Please see the corresponding sections below for details.

+The 'Cedar Trail' platform consists of the Cedarview (Intel® Atom™
+N2600, N2800 and D2550) processor, plus the Tiger Point
+(Intel® NM10 Express) Chipset.
+
+It also supports on-chip SGX545 graphics and media accelerator
+via the Cedar Trail Power VR (PVR) graphics driver.
+
Dependencies
============

--
1.7.4.1

From: Rahul Saxena <rahul.saxena@...>

This patch series does the following:
-- Update README with product name and state Gfx acceleration support
-- Fix package naming issue: Yocto bugzilla bug #3286.
-- Add development headers in pvr driver recipe

Pl pull into master branch

Thanks
Rahul
--
The following changes since commit 5164713bfbef16e1a49bc599ec0d738df52ab254:

meta-crystalforest: Update SRCREV for meta. (2012-10-15 14:38:40 -0500)

are available in the git repository at:
git://git.pokylinux.org/meta-intel-contrib master16oct-rsaxena
http://git.pokylinux.org/cgit.cgi/meta-intel-contrib/log/?h=master16oct-rsaxena

Rahul Saxena (3):
meta-cedartrail: Update README with product name and state Gfx
acceleration support
meta-cedartrail: Fix package naming issue
meta-cedartrail: Add development packages to pvr driver recipe

meta-cedartrail/README | 7 ++++
.../xorg-driver/cdv-pvr-driver_1.0.3.bb | 39 +++++++++++++++++++-
2 files changed, 45 insertions(+), 1 deletions(-)

--
1.7.4.1

Hi, again---I thought we were switching h/w platforms, but it turns out
we'll be sticking with this system for a bit longer.

I am guessing its some sort of Tegra CPU which had FPU but no neon
unit...

Right, it's a Tegra 2 T20, which lacks the NEON extension.

we dont have default tunes available readily that are good for tegra
but its not hard to create one

Erm. :-% I guess 'hard' is relative. Could you provide an extra hint
about this? Do you mean I should make a copy of 'tune-cortexa9.inc' and
change DEFAULTTUNE from 'cortexa9-neon' to 'cortexa9'? Or, is there a
way to include the existing file and override the default?

Also, I'm not sure what do to with the 'VFP Tunes'. I found this thread

- http://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg09497.html

which seems to talk about some of these issues. I think I need to add
'-mfpu=vfpv3-d16' to the compiler flags, but, as this is the first
'real' thing I've tried to do with bitbake, I'm unsure how to accomplish
this...



On Fri, Aug 31, 2012 at 7:00 PM, Khem Raj <raj.khem@...> wrote:

Hi Evade,

Glad it worked for you at first go. Thats quite an achievement for yocto

On Fri, Aug 31, 2012 at 2:58 PM, Evade Flow <evadeflow@...> wrote:

Now I'm wondering: is there any easy way to optimize for the actual
target(s) a bit more than the qemuarm MACHINE type does? The example
Makefiles for the old project all contain this line:

CFLAGS = -g -mcpu=arm1136jf-s -O2 -pipe

What's the best way to arrange for that '-mcpu' option to be used by all
recipes? Also, are there other optimizations I should consider? I'm
appending some details about the board in question, as well as the
complete output from booting it to a prompt. I'd be ever so grateful if
someone could recommend sensible base settings for this system, and
explain how to create a Poky 'layer', or 'machine'---or whatever the
right nomenclature is---to apply these settings.

Sorry for the long post, and thanks in advance for any advice!


----------

~ # uname -a
Linux localhost 2.6.36.2-WR3.0.2ax_standard #1 SMP PREEMPT Wed Oct 19 21:58:54
EEST 2011 armv7l armv7l armv7l GNU/Linux ODBP D1.0.1 (10.11.2011)

~ # cat /proc/cpuinfo
Processor : ARMv7 Processor rev 0 (v7l)
processor : 0
BogoMIPS : 1795.68

Features : swp half thumb fastmult vfp edsp vfpv3 vfpv3d16

I am guessing its some sort of Tegra CPU which had FPU but no neon unit
there is rich set of tuning available for arm.

So you would create configuration file for your machine. May be just
start by making a copy of
qemuarm.conf

then you would select the right tuning

require conf/machine/include/tune-arm926ejs.inc currently select arm926
you might want something more appropriate.

add
conf/machine/include/tune-arm1136jf-s.inc

this will get to what you had in old project

and you can also go a step further and make it more appropriate for
tegra cpu that you have
we dont have default tunes available readily that are good for tegra
but its not hard to create one

Look at

e.g on tune-cortexa9.inc

you would create something similar for your cpu and then select proper
default tunings.

Have fun

-Khem

On Wed, Oct 17, 2012 at 1:52 PM, Zhang, Jessica <jessica.zhang@...> wrote:

As to sato-sdk for qemuarm issue (3290), I think Beth has regenerated it. Can we have a quick check to ensure it’s working now?

Yes, this was due to us needing to regenerate qemuarm. Only the main
builder populates the adtrepo. As the images for the first run were
incorrectly generated for qemuarm, they had to be done by hand. This
was finished yesterday and the bug report updated.

-b

Thanks,

Jessica



From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Serban, Laurentiu
Sent: Wednesday, October 17, 2012 12:48 PM
To: yocto@...
Subject: [yocto] 1.3 RC4 full pass results





Hello guys,



Here are the test results for the 1.3 RC4 full pass.

The commit id is: 1b1b83651af33ffcb204031e2790719e3b0b45bb



For the performance tests: the build for sato x86 took 88 minutes (same as for RC3)



The following issue are encountered. I also updated with comments from Jessica and Saul:

- For the BSPs:

o For qemu x86_64 images – the zypper refresh fails (2694),

- For core build system:

o There are still errors with the do_rootfs fails for lib64-core-image-sato-sdk (2918)

- For ADT

o ADT couldn't be installed properly for RC4 because sato sdk for qemuarm does not exist (3290)

o GL support still available on qemuarm (3287)







Test Result Summary

Component

Target

Status

Comments

Boards

p1022ds

GOOD

Everything runs well

Beagleboard

GOOD

Everything runs well

Routerstationpro

GOOD

Everything runs well

Mpc8315e-rdb

GOOD

Sudoku-savant issue (2878)

eMenlow-sato-sdk

BUGGY

Usb mount fails (2643)

Blacksand-sato-sdk

GOOD

Everything runs well

Sugarbay sato-sdk

GOOD

Everything runs well

Crownbay-emgd-sato-sdk

GOOD

Standby fails (2792), Xorg issue (1258),

FRI2-sato

BUGGY

Blocked (3294)

HuronRiver-sato

GOOD

Everything runs well

Jasperforest-lsb

BUGGY

zypper is not installed in core-image-lsb-sdk (3098)

QEMU







Qemuarm

GOOD

Everything runs well

Qemuppc

GOOD

Everything runs well

Qemumips

GOOD

Everything runs well

qemux86

GOOD

Everything runs well

qemux86-64

BUGGY

Zypper issue (2694)

Core build system



BUGGY

lib64-core-image-sato-sdk fails due to do_rootfs issue (2918)

HOB



GOOD

Everything runs well

ADT



BUGGY

ADT couldn't be installed properly for RC4 because sato sdk for qemuarm does not exist (3290)

GL support still available on qemuarm (3287)

Stress Testing

GOOD

Both Crashme and Helltest on Jasperforest could pass 24 hours stress testing

Distribution Support

GOOD

Everything runs well for Ubuntu 12.04, Ubuntu 12.10 – nightly, OpenSuse 12.1, OpenSuse 12.2 RC2, Fedora 17, CentOs 6.3, Fedora 16

Power and Performance

GOOD

one qemux86 sato build on a Core i7 machine costs 88 minutes with the packages previously fetched.

Compliance

GOOD

Tests on Huron River and BlackSand passed

Build Appliance

GOOD

Everything runs well on VMWare Player (on Ubuntu). The relevant tests were performed also for qemu-kvm on Fedora 17 libvirt and

VMWare Workstation.(Ubuntu)





Detailed Test Result for each component

Target

Total TCs

Not Run

Passed

Failed

Not testable (Blocked)

Beagleboard Sato-SDK

42

0

42

0

0

Routerstationpro Sato-SDK

35

0

35

0

0

p1022ds-sato-sdk

37

0

37

0

0

Mpc8315e-rdb Sato-SDK

37

0

37

0

0

eMenlow Sato-sdk

67

0

66

1 (bug 2643)

0

n450 Sato-sdk

67

0

67

0

0

Crownbay-Sato-sdk

65

0

62

2 (1258, 2792)

1 (2792)

FRI2 Sato-sdk

85

0

0

0

85 (3294)

HuronRiver Sato-sdk

68

0

68

0

0

Sugarbay sato-sdk

68

0

68

0

0

Jasperforest lsb-sdk

34

0

27

7 (3098)

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

Qemux86-64 Sato

30

0

27

3 (bug 2694)

0

Qemux86-64 Sato-SDK

36

0

32

4 (bug 2694)

0

Qemux86 Sato

30

0

30

0

0

Qemux86 Sato-SDK

36

0

36

0

0

Core build system

59

0

57

2 (2918)

0

HOB

38

0

38

0

0

ADT

52

0

45

7(3290, 3287)

0

Build Appliance

42

0

34

7 (3290)

1 (centos gtk issue)

Total

1129

0

1009

33

87





Component

Bug Number

Target Milestone

System & Core OS

System Usage

Bug 2694 [QEMU-X86_64]zypper refresh fail

Core build system

Bug 2918 lib64-core-image-sato-sdk fails due to do_rootfs issue.

ADT

Bug 3287 GL support still available on qemuarm

Bug 3290 ADT couldn't be installed properly for RC4 because sato sdk for qemuarm does not exist









Laurentiu Serban

QA Engineer

Open Source Technology Center

System Software Division Romania

Desk: +40 31 8604742

iNET: 88451042




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

--
Elizabeth Flanagan
Yocto Project
Build and Release

On Wednesday, 17 October 2012 at 22:23, Tom Zanussi wrote:

Does this supercede the one in the 'Cedar Trail and gst-vaapi fixes'
patchset?

This patch is incorrect, the one I sent today was the correct one.

Also, do you have a branch we can pull from?

I do now - git.yoctoproject.org:user-contrib/ross/meta-intel, in the "cdt" branch. Don't just pull the entire branch, you'll want to cherry-pick the commits I mailed. There are other commits in that branch that depend on patches that haven't landed in oe-core yet…

Ross

Does this supercede the one in the 'Cedar Trail and gst-vaapi fixes'
patchset?

Also, do you have a branch we can pull from?

Tom