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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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