Date   

Yocto weekly bug trend charts -- WW12

Xu, Jiajun <jiajun.xu@...>
 

Hi all,
This is latest Yocto bug trend chart for WW12. QA finished RC3 fullpass testing last week. Lots of efforts were put on bug fixing to catch up gold build this week. The open bug is 168 for last week, which is the highest number from WW08. But many bugs are supposed to be fixed in gold build for this week.

Best Regards,
Jiajun


build failure - poky-image-lsb-sdk-beagleboard

Robert Berger <gmane@...>
 

Hi,

I don't know if I'm posting to the right mailing list, but just wanted
you to know that the latest and greatest from git fails when trying to
build poky-image-lsb-sdk for beaglebaord.

| make[3]: Leaving directory
`/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/libuser-0.57.1/docs'
| [ -d sgml ] || mkdir sgml
| cd sgml; sgml2txt .././sgml/libuser.sgml
| Processing file .././sgml/libuser.sgml
| troff: fatal error: can't find macro file s
| fmt_txt::postASP: Empty output file, error when calling groff.
Aborting...
| make[2]: *** [sgml/libuser.txt] Error 1
| make[2]: Leaving directory
`/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/libuser-0.57.1/docs'
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory
`/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/libuser-0.57.1'
| make: *** [all] Error 2
| FATAL: oe_runmake failed
| ERROR: Function 'do_compile' failed (see
/work/rber/poky-2011-03-20-snap-oe-build-bb/tmp/work/armv7a-poky-linux-gnueabi/libuser-0.57.1-r1/temp/log.do_compile.5485
for further information)
NOTE: package libuser-0.57.1-r1: task do_compile: Failed
ERROR: Task 1822
(/work/rber/poky/meta/recipes-extended/libuser/libuser_0.57.1.bb,
do_compile) failed with exit code '1'


Please advise

Regards,

Robert..."Giving up on assembly language was the apple in our Garden of
Eden: Languages whose use squanders machine cycles are sinful."(Epigrams
in Programming, ACM SIGPLAN Sept. 1982)

My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1


Re: [PATCH 1/1] emenlow.conf: no need to set PACKAGE_EXTRA_ARCHS

Darren Hart <dvhart@...>
 

On 03/18/2011 06:43 AM, Joshua Lock wrote:
From: Joshua Lock<josh@...>

x86 and core2 are added to this variable by the tune-atom.inc file

Signed-off-by: Joshua Lock<josh@...>
Pulling into meta-intel bernard and master, thanks,

---
meta-emenlow/conf/machine/emenlow.conf | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/meta-emenlow/conf/machine/emenlow.conf b/meta-emenlow/conf/machine/emenlow.conf
index 78fec25..db98706 100644
--- a/meta-emenlow/conf/machine/emenlow.conf
+++ b/meta-emenlow/conf/machine/emenlow.conf
@@ -5,7 +5,6 @@
# Webs-2120 box.

TARGET_ARCH = "i586"
-PACKAGE_EXTRA_ARCHS = "x86 core2"

include conf/machine/include/tune-atom.inc
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


Fullpass Test Report for Yocto M4 RC3 20110313 Build

Xu, Jiajun <jiajun.xu@...>
 

Hi all,

       This is the fullpass test report for RC3 build 20110313. There are 7 new bugs found in this build. Among them, 2 block issues are that crownbay emgd build failed and i686 toolchain tarball are not copied to sharing folder. For BSP testing: S3 could not work on Crownbay/n450; 3D game running will meet libSDL error on Sugarbay; keyboard/mouse could not work with n450 image. For zypper/rpm, zypper still has issue with install/removal on most platforms. For sstate, a new bug is found when building poky-image-minimal.

       In summary, this build is much greener than RC2 with only few bugs in zypper and some specific bugs for BSPs. All new opened bugs in RC3 testing already have been looked by developers and some already fixed.

 

Test Summary

---------------------------------------

Test Result Summary

Component

Target

Status

Comments

BSP

SugarBay

GOOD

Zypper install/remove has issue; 3D game running failed;

 

CrownBay

BLOCK

emgd crownbay build failed; matchbox-panel segfault; S3 fail on B0 board

 

JasperForest

GOOD

The only issue is zypper install/remove bug

 

Blacksand

Buggy

mouse/keyboard do not work in X window; zypper install/remove not work well

 

Beagleboard

GOOD

Only one RTC issue exists

 

Routerstationpro

GOOD

Only zypper install has issue

 

Mpc8315e-rdb

GOOD

Only zypper install has issue

QEMU

qemux86

Buggy

Only zypper install/remove has issue

 

qemux86-64

Buggy

Only zypper install/remove has issue

 

qemuarm

Buggy

zypper could not work well

 

qemuppc

Buggy

zypper could not work well

 

qemumips

Buggy

Only zypper install has issue

SDK

 

BLOCK

i686 toolchain not copied to sharing folder; unfs does not work with qemuppc;

Poky

 

BUGGY

sstate and non-gplv3 build do not work correctly

Stress

 

GOOD

Sugarbay pass 18 hours stress and Jasperforest pass 12 hours stress

Documentation

 

GOOD

 

 

 

Critical bugs, more than 50% test cases are blocked

 

 

 

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

 

 

 

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)

 

Crownbay noemgd Sato-SDK

54

0

46

5 (bug 804, 738, 882)

3 (bug 738, 882)

 

Sugarbay Sato-SDK

59

0

54

5 (bug 804, 883)

0

 

Jasperforest LSB-SDK

36

0

33

3 (bug 804)

0

 

n450 Sato-SDK

56

0

35

4 (bug 804, 613)

17 (bug 869, 613)

 

BeagleBoard Sato

14

0

13

1 (bug 767)

0

 

BeagleBoard Sato-SDK

21

0

20

1 (bug 767)

0

 

Routerstationpro Sato-SDK

30

0

28

2 (bug 845)

0

 

Mpc8315e-rdb Sato-SDK

29

0

26

2 (bug 841)

0

 

Qemux86-64 Sato

21

0

18

3 (bug 804)

0

 

Qemux86-64 Sato-SDK

24

0

21

3 (bug 804)

0

 

Qemux86 Sato

21

0

18

3 (bug 804)

0

 

Qemux86 Sato-SDK

24

0

21

3 (bug 804)

0

 

Qemumips Sato

21

0

19

2 (bug 845)

0

 

Qemumips Sato-SDK

24

0

22

2 (bug 845)

0

 

Qemuppc Sato

18

0

16

2 (bug 841)

0

 

Qemuppc Sato-SDK

21

0

17

4 (bug 841, 780)

0

 

Qemuarm Sato

21

0

19

2 (bug 489, 490)

0

 

Qemuarm Sato-SDK

24

0

22

2 (bug 489, 490)

0

 

SDK

3

0

0

1 (bug 414)

2 (bug 884)

 

Poky

8

0

6

2 (bug 712, 894)

0

 

Documentation

1

0

1

0

0

 

Stress

2

0

2

0

0

 

Total

532

0

457

53

22

 

* You can check the detailed test result in attachment for each target.

** The failed/blocked case number is listed with failed cases’ bug number.

 

Images

http://autobuilder.pokylinux.org/nightly/20110313-2/

commit: a33a2cc024f9c9147c92c5da70d8fbb631b968f9

 

Issue Summary

Zypper/RPM:

1.     [zypper] zypper install failed on routerstationpro sdk image

http://bugzilla.pokylinux.org/show_bug.cgi?id=845

2.     [zypper] installation failure on ppc (nightly build 20110305-4)

http://bugzilla.pokylinux.org/show_bug.cgi?id=841

3.     [zypper] zypper can not search any packages after installed package by rpm on qemuarm

http://bugzilla.pokylinux.org/show_bug.cgi?id=827

4.     [zypper] zypper install does not work on qemux86/atom-pc

http://bugzilla.pokylinux.org/show_bug.cgi?id=803

5.     [zypper] zypper lose package information after zypper/rpm install/remove

http://bugzilla.pokylinux.org/show_bug.cgi?id=804

6.     rpm remove package error

http://bugzilla.pokylinux.org/show_bug.cgi?id=787

7.     [zypper] uname –m and repo arch difference

http://bugzilla.pokylinux.org/show_bug.cgi?id=489

8.     [zypper] installation failure on arm

http://bugzilla.pokylinux.org/show_bug.cgi?id=490

 

Poky:

1.     New! [sstate] do_configure failed with libtool-cross when local sstate cache used

http://bugzilla.pokylinux.org/show_bug.cgi?id=894

2.     Fail to build non-GPLv3 image

http://bugzilla.pokylinux.org/show_bug.cgi?id=712

 

SDK:

1.     New! [autobuilder] i686 toolchain not copied to sharing folder

http://bugzilla.pokylinux.org/show_bug.cgi?id=884

2.     [PPC] kernel panic when booting poky-image-sdk-qemuppc through UNFS

http://bugzilla.pokylinux.org/show_bug.cgi?id=414

 

BSP:

1.     New! [crownbay] emgd crownbay build fail on xserver-xf86-emgd fetch

http://bugzilla.pokylinux.org/show_bug.cgi?id=885

2.     New! [crownbay] system could not enter into S3 with crownbay noemgd image

http://bugzilla.pokylinux.org/show_bug.cgi?id=882

3.     New! [Sugarbay] GFX 3D game test fail to run with sugarbay BSP image due to libsdl.so

http://bugzilla.pokylinux.org/show_bug.cgi?id=883

4.     New! [n450]Blacksand keyboard/mouse do not work on X window

http://bugzilla.pokylinux.org/show_bug.cgi?id=869

5.     Reopen! matchbox-panel segfault after X startup

http://bugzilla.pokylinux.org/show_bug.cgi?id=738

6.     [Blacksand]system cannot enter S3 standby mode

http://bugzilla.pokylinux.org/show_bug.cgi?id=613

7.     [beagleboard] Can not set RTC correctly

http://bugzilla.pokylinux.org/show_bug.cgi?id=767

 

Verified Fixed:

1.     [zypper] zypper segfault in qemumips sato/sdk images

http://bugzilla.pokylinux.org/show_bug.cgi?id=825

2.     [sstate] random error message shown when sstate is used

http://bugzilla.pokylinux.org/show_bug.cgi?id=788

3.     [sstate] only few setscene tasks run even with same build environment

http://bugzilla.pokylinux.org/show_bug.cgi?id=789

4.     meta-ide-support build fail with distro/bernard brarnch

http://bugzilla.pokylinux.org/show_bug.cgi?id=819

5.     [meta-intel] No LSB image for meta-intel BSP

http://bugzilla.pokylinux.org/show_bug.cgi?id=849

6.     [n450] blacksand could not boot up with n450 BSP image

http://bugzilla.pokylinux.org/show_bug.cgi?id=837

7.     The vnc client does not pop-up on qemumips-sato-sdk

http://bugzilla.pokylinux.org/show_bug.cgi?id=782

 

Best Regards,

Jiajun


[PATCH 1/1] emenlow.conf: no need to set PACKAGE_EXTRA_ARCHS

Joshua Lock <josh@...>
 

From: Joshua Lock <josh@...>

x86 and core2 are added to this variable by the tune-atom.inc file

Signed-off-by: Joshua Lock <josh@...>
---
meta-emenlow/conf/machine/emenlow.conf | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/meta-emenlow/conf/machine/emenlow.conf b/meta-emenlow/conf/machine/emenlow.conf
index 78fec25..db98706 100644
--- a/meta-emenlow/conf/machine/emenlow.conf
+++ b/meta-emenlow/conf/machine/emenlow.conf
@@ -5,7 +5,6 @@
# Webs-2120 box.

TARGET_ARCH = "i586"
-PACKAGE_EXTRA_ARCHS = "x86 core2"

include conf/machine/include/tune-atom.inc

--
1.7.4


[PATCH 0/1] Remove duplicate PACKAGE_EXTRA_ARCHS for Emenlow

Joshua Lock <josh@...>
 

From: Joshua Lock <josh@...>

These duplicates cause problems at least at rootfs creation

Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: josh/bernard-emen
Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=josh/bernard-emen

Thanks,
Joshua Lock <josh@...>
---


Joshua Lock (1):
emenlow.conf: no need to set PACKAGE_EXTRA_ARCHS

meta-emenlow/conf/machine/emenlow.conf | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)

--
1.7.4


Re: current status for ADT

Ke, Liping <liping.ke@...>
 

Hi, Jessica

We have a first round completed test cycle against RC3 for the sdk side.

And we have updated your test temple and
Upload it on https://oldwiki.pokylinux.org/share/SDK_docs/Test
For the bugs we have found and fixed/verified, we might skip it and did not list
it on the docs.


And all our test project is under the folder of
https://oldwiki.pokylinux.org/share/SDK_docs/Test/srcs


We will continue to update the test report with further testing data those days.

Thanks & Regards,
criping

-----Original Message-----
From: Zhang, Jessica
Sent: Saturday, March 12, 2011 8:03 AM
To: Ke, Liping; Lu, Lianhao
Cc: yocto@...
Subject: RE: current status for ADT

Liping and Lianhao,

Attached is the updated 1.0 test template, feel free to add more test
cases.
I think we're building RC3 over the weekend, and once the build is done,
we should test against it which contains all the latest and needed
changes for bernard. I'll monitor the build progress over the weekend
and synch with you on testing at your beginning of the week.

Thanks,
Jessica

Ke, Liping wrote:
Hi, Jessica

We use today's latest poky master which includes all our own fixes to
build (arm, i586, mips) target fs and cross toolchains. And then we
run below test:


Test environment:

1. For the available repo, use adt-installer installed toolchain:
i686-arm.

2. For meta-toolchainsdk installed toolchain: i686-i586, i686-arm,
i686-mips.

3. target: Qemu x86

Test project:

Against our selected test c++/c/libtool projects. All works fine.

All those tests are under command line with our automatic test
scripts.
We have not tested Eclipse plugin UI yet.

One thing to do is that we need to set up test adt repos for more
archs against newer changeset so that we can cover more adt-installer
tests against different archs.

Thanks & Regards,
criping


Shared State - What does it mean and why should I care?

Richard Purdie
 

One of the biggest attractions but also one of the biggest problems with
the OpenEmbedded architecture has always been the grounding in the build
from scratch approach. From one side this is a great advantage and its
something many systems struggle with. The downside is that it also means
people spend a lot of time rebuilding things from scratch and this is
the default approach people take whenever they hit problems.

For a long time we've wanted to find ways to do this better and have
better incremental build support. It can be split into some related
problems:

a) How do we work out which pieces of the system have not changed and
which have changed?
b) How do we then remove and replace the pieces that have changed?
c) How do we use prebuilt components that don't need to be built from
scratch if they're available?

We now have answers to the questions:

a) We detect changes in the "inputs" to a given task by creating a
checksum/signature of those inputs. If the checksum/signature changes,
the inputs changed and we need to rerun it.
b) The shared state (sstate) code tracks which tasks added which output
to the build process. This means the output from a given task can be
removed/upgraded or otherwise manipulated.
c) This question is also addressed partly by b) assuming we can fetch
the sstate objects from remote locations and install them if they're
deemed to be valid.

I'm now proud to announce that we have all these pieces in place and
working. Its not a simple problem and I'm not going to claim its all bug
free but the architecture is there, we've tested it and fixed many of
the problems. This is by far the most complete and robust answer to the
above questions we've ever had, replacing ideas like the several
versions of packaged-staging that predate this.

Since its new, this subject is lacking in documentation and I'd
therefore like to dive into some of the technical details so these have
at least been covered somewhere. I'm going to tell this partly as a
story of how we've arrived at the design we have today. Over time we can
expand this and include the data in the manuals etc.

Overall Architecture
====================

Firstly, we've made a decision to make all this work on a per-task
basis. In previous versions of packaged-staging we did this on a per
recipe basis but this didn't work well. Why? Imagine you have the ipk
packaging backend enabled and you switch to deb. Your do_install and
do_package output is still valid but a per recipe approach wouldn't
include the .deb files so you'd have to invalidate the whole thing and
re-run it. This is suboptimal. You also end up having to teach the core
an awful lot of knowledge about specific tasks. This doesn't scale well
and doesn't allow users to add new tasks easily in layers or external
recipes without touching the packaged-staging core.

Checksums/Signatures
====================

So we need to detect all the inputs to a given task. For shell tasks
this turns out to be fairly easily as we generate the "run" shell script
for each task and its possible to checksum that and have a good idea of
when the data going into a task changes.

To complicate the problem, there are things we don't want to include in
the checksum. Firstly, there is the actual specific build path of a
given task (its WORKDIR). We don't really mind if that changes as that
shouldn't affect the output for target packages and we also have the
objective of making native/cross packages relocatable. We therefore need
to exclude WORKDIR. The simplistic approach is therefore to set WORKDIR
to some fixed value and checksum that "run" script. The next problem is
the "run" scripts were rather full of functions that may or may not get
called. Chris Larson added code which allowed us to figure out
dependencies between shell functions and we use this to prune the "run"
scripts down to the minimum set, thereby alleviating this problem and
making the "run" scripts much more readable as an added bonus.

So we have something that would work for shell, what about python tasks?
These are harder but the same approach applies, we needed to figure out
what variables a python function accesses and what functions it calls.
Again, Chris Larson came up with some code for this and this is exactly
what we do, figure out the variable and function dependencies, then
checksum the data that goes as an input to the task.

Like the WORKDIR case, there are some cases where we do explicitly want
to ignore a dependency as we know better than bitbake. This can be done
with a line like:

PACKAGE_ARCHS[vardepsexclude] = "MACHINE"

which would ensure that the PACKAGE_ARCHS variable does not depend on
the value of MACHINE, even if it does reference it.

Equally, there are some cases where we need to add in dependencies
bitbake isn't able to find which can be done as:

PACKAGE_ARCHS[vardeps] = "MACHINE"

which would explicitly add the MACHINE variable as a dependency for
PACKAGE_ARCHS. There are some cases with inline python for example where
bitbake isn't able to figure out the dependencies. When running in debug
mode (-DDD), bitbake does output information when it sees something it
can't figure out the dependencies within. We currently have not managed
to cover those dependencies in detail and this is something we know we
need to fix.

This covers the direct inputs into a task well but there is then the
question of the indirect inputs, the things that were already built and
present in the build directory. The information so far is referred to as
the "basehash" in the code, we then need to add the hashes of all the
tasks this task depends upon. Choosing which dependencies to add is a
policy decision but the effect is to generate a master
checksum/signature which combines the basehash and the hashes of the
dependencies.

Figuring out the dependencies and these signatures/checksums is great,
what do we then do with the checksum information? We've introduced the
notion of a signature handler into bitbake which is responsibility for
processing this information. By default there is a dummy "noop"
signature handler enabled in bitbake so behaviour is unchanged from
previous versions. OECore uses the "basic" signature hander by setting:

BB_SIGNATURE_HANDLER ?= "basic"

in bitbake.conf. At the same point we also give bitbake some extra
information to help it handle this information:

BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM USER FILESPATH USERNAME STAGING_DIR_HOST STAGING_DIR_TARGET"
BB_HASHTASK_WHITELIST ?= "(.*-cross$|.*-native$|.*-cross-initial$|.*-cross-intermediate$|^virtual:native:.*|^virtual:nativesdk:.*)"

The BB_HASHBASE_WHITELIST is effectively a list of global
vardepsexclude, those variables are never included in any checksum. This
is actually where we exclude WORKDIR since WORKDIR is constructed as a
path within TMPDIR and we whitelist TMPDIR.

The BB_HASHTASK_WHITELIST covers dependent tasks and excludes certain
kinds of tasks from the dependency chains. The effect of the example
above is to isolate the native, target and cross components, so for
example, toolchain changes don't force a rebuild of the whole system.

The end result of the "basic" handler is to make some dependency and
hash information available to the build. This includes:

BB_BASEHASH_task-<taskname> - the base hashes for each task in the recipe
BB_BASEHASH_<filename:taskname> - the base hashes for each dependent task
BBHASHDEPS_<filename:taskname> - The task dependencies for each task
BB_TASKHASH - the hash of the currently running task

There is also a "basichash" BB_SIGNATURE_HANDLER which is the same as
the basic version but adds the task hash to the stamp files. This has
the result that any metadata change that changes the task hash,
automatically causes the task to rerun. This removes the need to bump PR
values and changes to metadata automatically ripple across the build.
This isn't the default but its likely we'll do that in future and all
the functionality exists. The reason for delaying is the potential
impact to distribution feed creation as they need increasing PR fields
and we lack a mechanism to automate that yet. Its not a hard problem to
fix though.

Shared State
============

I've talked a lot about part a) of the problem above and how we detect
changes to the tasks. This solves half the problem, the other half is
using this information at the build level and being able to reuse or
rebuild specific components.

The sstate class is a relatively generic implementation of how to
"capture" a snapshot of a given task. The idea is that from the build
point of view we should never need to care where this output came from,
it could be freshly built, it could be downloaded and unpacked from
somewhere, we should never need to care.

There are two classes of output, one is just about creating a directory
in WORKDIR, e.g. the output of do_install or do_package. The other is
where a set of data is merged into a shared directory tree such as the
sysroot.

We've tried to keep the gory details of the implementation hidden in the
sstate class. From a user perspective, adding sstate wrapping to a task
is as simple as this do_deploy example taken from do_deploy.bbclass:

DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
SSTATETASKS += "do_deploy"
do_deploy[sstate-name] = "deploy"
do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"

python do_deploy_setscene () {
sstate_setscene(d)
}
addtask do_deploy_setscene

Here, we add some extra flags to the task, a name field ("deploy"), an
input directory which is where the task outputs data to, the output
directory which is where the data from the task should be eventually be
copied to. We also add a _setscene variant of the task and add the task
name to the SSTATETASKS list.

If there was a directory you just need to ensure has its contents
preserved, this can be done with a line like:

do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"

Its also worth highlighting mutliple directories can be handled as above
or as in the following input/output example:

do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}"
do_package[sstate-lockfile] = "${PACKAGELOCK}"

This also includes the ability to take a lockfile when manipulating
sstate directory structures since some cases are sensitive to file
additions/removals.

Behind the scenes, the sstate code works by looking in SSTATE_DIR and
also at any SSTATE_MIRRORS for sstate files. An example of a local file
url sstate mirror is:

SSTATE_MIRRORS ?= "\
file://.* http://someserver.tld/share/sstate/ \n \
file://.* file:///some/local/dir/sstate/"

although any standard PREMIRROR/MIRROR syntax can be used for example
with http:// urls.

The sstate package validity can be detected just by looking at the
filename since the filename contains the task checksum/signature as
detailed above. If a valid sstate package is found, it will be
downloaded and used to accelerate the task.

The task acceleration phase is what the *_setscene tasks are used for.
Bitbake goes through this phase before the main execution code and tries
to accelerate any tasks it can find sstate packages for. If a sstate
package for a task is available, the sstate package will be used, that
task will not be run and importantly, any dependencies that task will
also not be executed.

As a real world example, the aim is when building an ipk based image,
only the do_package_write_ipk tasks would have their sstate packages
fetched and extracted. Since the sysroot isn't used, it would never get
extracted. This is another reason to prefer the task based approach
sstate takes over any recipe based approach which would have to install
the output from every task.

Tips and Tricks
===============

This isn't simple code and when it goes wrong, debugging needs to be
straightforward. During development we tried to write strong debugging
tools too.

Firstly, whenever a sstate package is written out, so is a
corresponding .siginfo file. This is a pickled python database of all
the metadata that went into creating the hash for a given sstate
package.

If bitbake is run with the --dump-signatures (or -S) option, instead of
building the target package specified it will dump out siginfo files in
the stamp directory for every task it would have executed.

Finally, there is a bitbake-diffsigs command which can process these
siginfo files. If one file is specified, it will dump out the dependency
information in the file. If two files are specified, it will compare the
two files and dump out the differences between the two.

This allows the question of "What changed between X and Y?" to be
answered easily.


Trying to create an autotooled recipe

Chris Tapp
 

I've got a project that builds (and runs) using autotools under Eclipse.

If I 'make dist-gzip' I get a tar.gz that I can use as a SRC_URI target within a recipe.

The recipe builds ok, but I get

| make: *** No rule to make target `install'. Stop.
| FATAL: oe_runmake failed

when it comes to installing.

I can get it to work if I manually create the .tar.gz file, ensuring that only the source files, configure.ac and Makefile.am files are included. The Eclipse export includes all the files that are produced when autotools are run during the build.

What's the best way to get round having to do this?

I had hoped that I could control what gets packaged in the .tar.gz that comes out from 'make', but this is my first day using autotools and I've not yet found any documentation that gives me a suitable example (if it's possible) ! I can see how to stop source code files getting included, but not 'other' files.

Should I be trying to solve this at the source end or is there something I can do within my .bb file that's more generic?

Chris Tapp

opensource@...
www.keylevel.com


Re: yocto supported freescale eval boards

Robert Berger <gmane@...>
 

Hi,


We're currently using the following board.

http://search.digikey.com/scripts/DkSearch/dksus.dll?PName?Name=MPC8315E-RDBA-ND&Site=US&Lang=EN
Just FYI it looks like this board is not available in Europe from
Digikey due to U.S. export controls. Some kind of top secret U.S.
hardware, I guess ;)

As an alternative solution, which you can actually get in Europe I
ordered this: http://www.denx-cs.de/?q=mpc8315e-rdb

No ND at the and, still I hope it's going to work.

Regards,

Robert..."The scientific name for an animal that doesn't either run from
or fight its enemies is lunch." - Michael Friedman

My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1


Sanity Test Report for Yocto 1.0 RC3 20110313 Build

Xu, Jiajun <jiajun.xu@...>
 

Hi all,

       This is the sanity test report for RC3 20110313 build. Sanity test could pass on most testing targets. There are 2 block issues for crownbay and toolchain: emgd crownbay build failed and i686 toolchain tarball not copied to sharing folder on autobuilder. And on blacksand(n450), we find mouse and keyboard do not work under X window. For bug fixing, zypper segfault issues on qemumips and qemuppc are fixed. meta-ide-support build failed issue is also fixed.

 

Test Summary

---------------------------------------

Test Result Summary

 

Component

Target

Status

Comments

 

BSP

SugarBay

GOOD

No bug found with sanity test

 

 

CrownBay

BLOCK

emgd crownbay build failed

 

 

JasperForest

GOOD

No bug found with sanity test

 

 

Blacksand

Buggy

mouse/keyboard do not work in X window

 

 

Beagleboard

GOOD

Only one RTC issue exists

 

 

Routerstationpro

GOOD

No bug found with sanity test

 

 

Mpc8315e-rdb

GOOD

No bug found with sanity test

 

QEMU

qemux86

GOOD

 

 

 

qemux86-64

GOOD

 

 

 

qemuarm

GOOD

 

 

 

qemuppc

GOOD

 

 

 

qemumips

GOOD

zypper segfault bug is fixed

 

SDK

 

BLOCK

i686 toolchain not copied to sharing folder;

 

 

 

Critical bugs, more than 50% test cases are blocked

 

 

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

 

 

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)

Crownbay noemgd Sato-SDK

31

0

29

1 (bug 738)

1 (bug 738)

Sugarbay Sato-SDK

32

0

32

0

0

Jasperforest LSB-SDK

20

0

20

0

0

n450 Sato-SDK

30

0

24

0

6 (bug 869)

BeagleBoard Sato

11

0

10

1 (bug 767)

0

BeagleBoard Sato-SDK

14

0

13

1 (bug 767)

0

Routerstationpro Sato-SDK

20

0

20

0

0

Mpc8315e-rdb Sato-SDK

19

0

19

0

0

Qemux86-64 Sato

18

0

18

0

0

Qemux86-64 Sato-SDK

21

0

21

0

0

Qemux86 Sato

18

0

18

0

0

Qemux86 Sato-SDK

21

0

21

0

0

Qemumips Sato

15

0

15

0

0

Qemumips Sato-SDK

18

0

16

0

0

Qemuppc Sato

12

0

12

0

0

Qemuppc Sato-SDK

15

0

14

1 (bug 780)

0

Qemuarm Sato

15

0

15

0

0

Qemuarm Sato-SDK

18

0

18

0

0

SDK

3

0

1

0

2 (bug 884)

Total

351

0

336

4

9

* You can check the detailed test result in attachment for each target.

** The failed/blocked case number is listed with failed cases’ bug number.

 

Images

---------------------------------------

Image: http://autobuilder.pokylinux.org/nightly/20110313-2/

Tree/Branch: Poky/Bernard

Commit: a33a2cc024f9c9147c92c5da70d8fbb631b968f9

 

Issue Summary

---------------------------------------

SDK:

1.     New! [autobuilder] i686 toolchain not copied to sharing folder

http://bugzilla.pokylinux.org/show_bug.cgi?id=884

 

BSP:

1.     New! [crownbay] emgd crownbay build fail on xserver-xf86-emgd fetch

http://bugzilla.pokylinux.org/show_bug.cgi?id=885

2.     New! [n450]Blacksand keyboard/mouse do not work on X window

http://bugzilla.pokylinux.org/show_bug.cgi?id=869

3.     Re-open! matchbox-panel segfault after X startup

http://bugzilla.pokylinux.org/show_bug.cgi?id=738

4.     [beagleboard] Can not set RTC correctly

http://bugzilla.pokylinux.org/show_bug.cgi?id=767

 

Others:

1.     gcc segfault on qemuppc (nightly build 20110226-1)

http://bugzilla.pokylinux.org/show_bug.cgi?id=780

 

Verified Fixed Bugs:

1.     [zypper] zypper segfault in qemumips sato/sdk images

http://bugzilla.pokylinux.org/show_bug.cgi?id=825

2.     The vnc client does not pop-up on qemumips-sato-sdk

http://bugzilla.pokylinux.org/show_bug.cgi?id=782

3.     zypper encounter segfault when startup with qemuppc

http://bugzilla.pokylinux.org/show_bug.cgi?id=443

4.     meta-ide-support build fail with distro/bernard brarnch

http://bugzilla.pokylinux.org/show_bug.cgi?id=819

 

Best Regards,

Jiajun

 


Yocto 5.0 alpha testing result

Ricci, Davide <Davide.Ricci@...>
 

Able to connect to the git repository and check out 5.0 alpha release.

Had to solve an issue with ncurses recipe which had wrong patch set number.

Build successful - profile "minimal".

Could bring up the target through QEMU and browse filesystem.

No real showstoppers found.

Regards
Davide


Notes from Release Tracking Meeting

Fleischer, Julie N <julie.n.fleischer@...>
 

All,
Here are the notes from the March 15th Yocto Release Tracking Meeting. Feel free to send on changes/corrections.
Thanks.
- Julie

Attendees: Julie, Tom, Kevin Tian, Dave, Jeff Polk, Qing, Richard, Beth, Darren, Kevin McCombe, Saul, Jessica, Mark

See Release Criteria Status at: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.0_Release_Criteria#Yocto_v1.0_Release_Criteria

General bug status:
** All bugs need to be fixed by 9am Pacific on March 18th. **
** ONLY bugs listed on the Release Criteria (or new critical/high items) will be added to Bernard. **
** Before a fix goes in, Richard, Beth, Saul/Kevin, Jessica, Dave need to agree the patch can go in. **
** Team will do daily bug meetings at 7am Pacific and 8pm Pacific. **

Action Item: Beth/Richard will discuss using different directories for Poky and Poky-lsb.
Action Item: Beth/others: Determine if we can reduce the number of images we build. (We discussed that images were added at the request of others.)
Action Item: All: If you have /home directories on autobuilder with large files, please remove so Beth has room on autobuilder.
Action Item: Tom: Investigate Crownbay EMGD build issue where it was picking up the wrong checksum. Beth will give Tom info to reproduce.
Action Item: Chris: Send a note to discuss the timing for getting the demo hardware to ELC.


-----------------------
Julie Fleischer
Open Source Technology Center
Intel Corporation


Re: [oe] Collab Summit + ELC + TSC Meeting

Koen Kooi
 

Op 15 mrt 2011, om 02:15 heeft Philip Balister het volgende geschreven:

On 03/14/2011 08:44 PM, Jeff Osier-Mixon wrote:

There also was a request for more general purpose OEDAM over the weekend,
maybe in parallel or before/after TSC meeting:

Any thoughts on that?
Most of the replies there are from TSC people who are going to be there
with the exceptions of yourself and Mike. I'm ok with having a more
general meeting if the demand is there and Jefro can arrange it. If
there are only a few people, I'd suggest something like meeting after
the TSC meeting and finding food/drink together.

For those who don't know me, I'm Jefro. :)

As Richard says, a small crowd would probably interact better over
refreshments. If you are interested in such a gathering, send me a note at
jefro@... and let me know when you are available, and I'll see what I
can pull together.
A quick show of hands, how many OE people can be in San Francisco over the weekend of April 9-10? TSC people, go ahead and chime in for completeness.
I will be there on sunday.

regards,

Koen


Yocto weekly bug trend charts -- WW11

Xu, Jiajun <jiajun.xu@...>
 

Hi all,
This is latest Yocto bug trend chart for WW11. QA finished RC2 fullpass testing and is doing RC3 testing now. Open bug number increased a lot from 138 to 152. There remains 66 open bugs targeted to be fixed in 1.0 M4.

Best Regards,
Jiajun


Re: [oe] Collab Summit + ELC + TSC Meeting

Tom Rini <tom_rini@...>
 

On 03/14/2011 06:15 PM, Philip Balister wrote:
On 03/14/2011 08:44 PM, Jeff Osier-Mixon wrote:

There also was a request for more general purpose OEDAM over the
weekend,
maybe in parallel or before/after TSC meeting:

Any thoughts on that?
Most of the replies there are from TSC people who are going to be there
with the exceptions of yourself and Mike. I'm ok with having a more
general meeting if the demand is there and Jefro can arrange it. If
there are only a few people, I'd suggest something like meeting after
the TSC meeting and finding food/drink together.

For those who don't know me, I'm Jefro. :)

As Richard says, a small crowd would probably interact better over
refreshments. If you are interested in such a gathering, send me a
note at
jefro@... and let me know when you are available, and I'll see
what I
can pull together.
A quick show of hands, how many OE people can be in San Francisco over
the weekend of April 9-10? TSC people, go ahead and chime in for
completeness.
I'm going just for the Sunday bit.

--
Tom Rini
Mentor Graphics Corporation


Re: [oe] Collab Summit + ELC + TSC Meeting

Denys Dmytriyenko
 

On Mon, Mar 14, 2011 at 09:15:22PM -0400, Philip Balister wrote:
On 03/14/2011 08:44 PM, Jeff Osier-Mixon wrote:

There also was a request for more general purpose OEDAM over the
weekend,
maybe in parallel or before/after TSC meeting:

Any thoughts on that?
Most of the replies there are from TSC people who are going to be there
with the exceptions of yourself and Mike. I'm ok with having a more
general meeting if the demand is there and Jefro can arrange it. If
there are only a few people, I'd suggest something like meeting after
the TSC meeting and finding food/drink together.

For those who don't know me, I'm Jefro. :)

As Richard says, a small crowd would probably interact better over
refreshments. If you are interested in such a gathering, send me a note
at
jefro@... and let me know when you are available, and I'll see what
I
can pull together.
A quick show of hands, how many OE people can be in San Francisco over the
weekend of April 9-10? TSC people, go ahead and chime in for completeness.
I plan to be there.

--
Denys


Re: Race condition when building a recipe and poky-image-minimal-initramfs

Xu, Dongxiao <dongxiao.xu@...>
 

Mark Hatle wrote:
On 3/14/11 8:47 PM, Xu, Dongxiao wrote:
Hi Richard,
There was already a defect covering this. The bug number is "797".

In order to fix the problem a lock was added to the RPM generation.
This lock should be preventing both RPM package generation and rootfs
construction from running at the same time.

The code was checked into Bernard on 2011-03-10. If your image is
from after that date, please reopen the defect and add the details
below.
Yes, thanks for pointing it out. The phenomenon is similar as bug 797. I will mark it as a duplication.

Just checked that, your fixing patch for 797 is already in my build. Therefore I will re-open the bug.

My build is based on commit 43a2d098008eee711399b8d64594d84ae034b9bf.

In my side, the race condition is happened in manifest generation while executing "package_update_index_rpm()".

Thanks,
Dongxiao


--Mark

These days I found a race condition between building a recipe and
poky-image-minimal-initramfs, to reproduce it, you can try as:

1) Run "bitbake poky-image-sato-live". Build the full sato-live
image until it is successful. 2) Bump connman's PR (or some other
sato recipe's PR). 3) Rebuild the sato live image by "bitbake
poky-image-sato-live".

Sometimes, I meet build error like the following, however it does
not happen every time.

-------------------------------------------------------
Generating solve db for
/distro/dongxiao/build-qemux86/tmp/deploy/rpm/qemux86... total:
1 0.000000 MB 1.424841 secs fingerprint: 1020
0.006796 MB 0.033057 secs install: 340
0.000000 MB 0.371773 secs dbadd: 340
0.000000 MB 0.362746 secs dbget: 2196
0.000000 MB 0.004278 secs dbput: 340
1.504908 MB 0.308950 secs readhdr: 3401
2.961280 MB 0.005603 secs hdrload: 1700
4.389932 MB 0.007001 secs hdrget: 57535
0.000000 MB 0.043769 secs
Generating solve db for
/distro/dongxiao/build-qemux86/tmp/deploy/rpm/i586...
error: open of
/distro/dongxiao/build-qemux86/tmp/deploy/rpm/i586/connman-plugin-ethe
rnet-0.65-r4.i586.rpm failed: No such file or directory
rpm.real: ./rpmio_internal.h:190: fdGetOPath: Assertion `fd !=
((void *)0) && fd->magic == 0x04463138' failed.
/distro/dongxiao/build-qemux86/tmp/work/qemux86-poky-linux/poky-image-minimal-initramfs-1.0-r0/temp/run.do_rootfs.468:
line 375: 669 Aborted rpm --dbpath /var/lib/rpm
--define='_openall_before_chroot 1' -i --replacepkgs --replacefiles
--oldpackage -D "_dbpath $pkgdir/solvedb" --justdb --noaid --nodeps
--noorder --noscripts --notriggers --noparentdirs --nolinktos
--stats --ignoresize --nosignature --nodigest -D "__dbi_txn create
nofsync" $pkgdir/solvedb/manifest ERROR: Function 'do_rootfs' failed
(see
/distro/dongxiao/build-qemux86/tmp/work/qemux86-poky-linux/poky-image-
minimal-initramfs-1.0-r0/temp/log.do_rootfs.468 for further
information)
-------------------------------------------------------

The root cause for this issue should be,
poky-image-minimal-initramfs's do_rootfs task doesn't have
dependency on connman, thus their tasks will be run simultaneously.
Poky-image-minimal-initramfs's do_rootfs will call
"rootfs_rpm_do_rootfs" --> "package_update_index_rpm", where it will
update all the packages depsolver db in ${DEPLOY_DIR_RPM}.

When the package_update_index_rpm function is handling connman's rpm
package, and at the same time, connman is removing old rpm and
trying to generate a new one (e.x, from r4 to r5), then the build
error will occur, saying that it could not find r4 version of
connman-plugin-ethernet...

One choice may be to force poky-image-minimal-initramfs's do_rootfs
to depends on all recipe's do_package to ensure correctness, even
though it only depends on some basic recipes.

However I think it is not such elegant.

Do you have ideas on it?

BTW, I will file a bug 867 to track this issue.
http://bugzilla.pokylinux.org/show_bug.cgi?id=867

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


Re: Race condition when building a recipe and poky-image-minimal-initramfs

Mark Hatle <mark.hatle@...>
 

On 3/14/11 8:47 PM, Xu, Dongxiao wrote:
Hi Richard,
There was already a defect covering this. The bug number is "797".

In order to fix the problem a lock was added to the RPM generation. This lock
should be preventing both RPM package generation and rootfs construction from
running at the same time.

The code was checked into Bernard on 2011-03-10. If your image is from after
that date, please reopen the defect and add the details below.

--Mark

These days I found a race condition between building a recipe and poky-image-minimal-initramfs, to reproduce it, you can try as:

1) Run "bitbake poky-image-sato-live". Build the full sato-live image until it is successful.
2) Bump connman's PR (or some other sato recipe's PR).
3) Rebuild the sato live image by "bitbake poky-image-sato-live".

Sometimes, I meet build error like the following, however it does not happen every time.

-------------------------------------------------------
Generating solve db for /distro/dongxiao/build-qemux86/tmp/deploy/rpm/qemux86...
total: 1 0.000000 MB 1.424841 secs
fingerprint: 1020 0.006796 MB 0.033057 secs
install: 340 0.000000 MB 0.371773 secs
dbadd: 340 0.000000 MB 0.362746 secs
dbget: 2196 0.000000 MB 0.004278 secs
dbput: 340 1.504908 MB 0.308950 secs
readhdr: 3401 2.961280 MB 0.005603 secs
hdrload: 1700 4.389932 MB 0.007001 secs
hdrget: 57535 0.000000 MB 0.043769 secs
Generating solve db for /distro/dongxiao/build-qemux86/tmp/deploy/rpm/i586...
error: open of /distro/dongxiao/build-qemux86/tmp/deploy/rpm/i586/connman-plugin-ethernet-0.65-r4.i586.rpm failed: No such file or directory
rpm.real: ./rpmio_internal.h:190: fdGetOPath: Assertion `fd != ((void *)0) && fd->magic == 0x04463138' failed.
/distro/dongxiao/build-qemux86/tmp/work/qemux86-poky-linux/poky-image-minimal-initramfs-1.0-r0/temp/run.do_rootfs.468: line 375: 669 Aborted rpm --dbpath /var/lib/rpm --define='_openall_before_chroot 1' -i --replacepkgs --replacefiles --oldpackage -D "_dbpath $pkgdir/solvedb" --justdb --noaid --nodeps --noorder --noscripts --notriggers --noparentdirs --nolinktos --stats --ignoresize --nosignature --nodigest -D "__dbi_txn create nofsync" $pkgdir/solvedb/manifest
ERROR: Function 'do_rootfs' failed (see /distro/dongxiao/build-qemux86/tmp/work/qemux86-poky-linux/poky-image-minimal-initramfs-1.0-r0/temp/log.do_rootfs.468 for further information)
-------------------------------------------------------

The root cause for this issue should be, poky-image-minimal-initramfs's do_rootfs task doesn't have dependency on connman, thus their tasks will be run simultaneously. Poky-image-minimal-initramfs's do_rootfs will call "rootfs_rpm_do_rootfs" --> "package_update_index_rpm", where it will update all the packages depsolver db in ${DEPLOY_DIR_RPM}.

When the package_update_index_rpm function is handling connman's rpm package, and at the same time, connman is removing old rpm and trying to generate a new one (e.x, from r4 to r5), then the build error will occur, saying that it could not find r4 version of connman-plugin-ethernet...

One choice may be to force poky-image-minimal-initramfs's do_rootfs to depends on all recipe's do_package to ensure correctness, even though it only depends on some basic recipes.

However I think it is not such elegant.

Do you have ideas on it?

BTW, I will file a bug 867 to track this issue. http://bugzilla.pokylinux.org/show_bug.cgi?id=867

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


Race condition when building a recipe and poky-image-minimal-initramfs

Xu, Dongxiao <dongxiao.xu@...>
 

Hi Richard,

These days I found a race condition between building a recipe and poky-image-minimal-initramfs, to reproduce it, you can try as:

1) Run "bitbake poky-image-sato-live". Build the full sato-live image until it is successful.
2) Bump connman's PR (or some other sato recipe's PR).
3) Rebuild the sato live image by "bitbake poky-image-sato-live".

Sometimes, I meet build error like the following, however it does not happen every time.

-------------------------------------------------------
Generating solve db for /distro/dongxiao/build-qemux86/tmp/deploy/rpm/qemux86...
total: 1 0.000000 MB 1.424841 secs
fingerprint: 1020 0.006796 MB 0.033057 secs
install: 340 0.000000 MB 0.371773 secs
dbadd: 340 0.000000 MB 0.362746 secs
dbget: 2196 0.000000 MB 0.004278 secs
dbput: 340 1.504908 MB 0.308950 secs
readhdr: 3401 2.961280 MB 0.005603 secs
hdrload: 1700 4.389932 MB 0.007001 secs
hdrget: 57535 0.000000 MB 0.043769 secs
Generating solve db for /distro/dongxiao/build-qemux86/tmp/deploy/rpm/i586...
error: open of /distro/dongxiao/build-qemux86/tmp/deploy/rpm/i586/connman-plugin-ethernet-0.65-r4.i586.rpm failed: No such file or directory
rpm.real: ./rpmio_internal.h:190: fdGetOPath: Assertion `fd != ((void *)0) && fd->magic == 0x04463138' failed.
/distro/dongxiao/build-qemux86/tmp/work/qemux86-poky-linux/poky-image-minimal-initramfs-1.0-r0/temp/run.do_rootfs.468: line 375: 669 Aborted rpm --dbpath /var/lib/rpm --define='_openall_before_chroot 1' -i --replacepkgs --replacefiles --oldpackage -D "_dbpath $pkgdir/solvedb" --justdb --noaid --nodeps --noorder --noscripts --notriggers --noparentdirs --nolinktos --stats --ignoresize --nosignature --nodigest -D "__dbi_txn create nofsync" $pkgdir/solvedb/manifest
ERROR: Function 'do_rootfs' failed (see /distro/dongxiao/build-qemux86/tmp/work/qemux86-poky-linux/poky-image-minimal-initramfs-1.0-r0/temp/log.do_rootfs.468 for further information)
-------------------------------------------------------

The root cause for this issue should be, poky-image-minimal-initramfs's do_rootfs task doesn't have dependency on connman, thus their tasks will be run simultaneously. Poky-image-minimal-initramfs's do_rootfs will call "rootfs_rpm_do_rootfs" --> "package_update_index_rpm", where it will update all the packages depsolver db in ${DEPLOY_DIR_RPM}.

When the package_update_index_rpm function is handling connman's rpm package, and at the same time, connman is removing old rpm and trying to generate a new one (e.x, from r4 to r5), then the build error will occur, saying that it could not find r4 version of connman-plugin-ethernet...

One choice may be to force poky-image-minimal-initramfs's do_rootfs to depends on all recipe's do_package to ensure correctness, even though it only depends on some basic recipes.

However I think it is not such elegant.

Do you have ideas on it?

BTW, I will file a bug 867 to track this issue. http://bugzilla.pokylinux.org/show_bug.cgi?id=867

Thanks,
Dongxiao