Date   

Re: Try latest yocto adt script installer

Zhang, Jessica
 

Ke, Liping wrote:
Hi, Jessica

I have put the installer script tar ball in the below links:
http://llu-piketon.sh.intel.com/installer.tar

You can have a try. Below is some key notes:

1. since now version has problems, we have submit bug 586
http://bugzilla.pokylinux.org/show_bug.cgi?id=586
So currently we have no available x86_64 repository. (same packages
now belong to different version because they are built in two days).
So currently only 32 bit host could run the script
2. after untar this installer, under adt_installer folder, directly
running $ ./yocto_installer.
Why we must run the script under the adt-installer directory? Actually I
tried to run under $HOME or / but specifying the full path to
yocto_installer, and got the error:
[ADT_INST] script file util is not found!

#############################################
# Meet error when installing Yocto ADT.
#############################################

2 comments here:
1. we should be able to allow user run the yocto_installer script from any
location and it should be able to locate the needed surporting files or
scripts
2. As a convention and to be consistent, I'd suggest change the above error
message as "[ADT_INST] Error: Script file util is not found!" There're
several error messages in the scripts has the Error message format that I'm
talking about here, which you can look up as a reference.

3. Build log are located @ adt_installer/yoctoadt_installer.log
4. User config ( install which targets) are defined/changed in
Yocto_installer.conf. Note: now only i586 qemu rootfs are available
in repository.

Any problem, just let me know.
Just by playing with it, I change YOCTOADT_TARGETS="ppc" in
yocto_installer.conf. And the prompt that I got is as follows:

[ADT_INST] selected archs defined in Host Area Item: YOCTOADT_TARGETS is not
valid!
Error: Terminate installation process due to errors!

Comments here:
1. Add the "Error: " to the error message as mentioned before
2. YOCTADT_TARGETS is now replaces by the specified value (ppc)
3. It would be nice to point out Host Area resides in which file, and also
tells user what are the valid entries
4. It's not consistent when existing the program when running into errors,
see the above and here just "Error: "...

During the Make opkg..., there're bunch of warning messages can we redirect
them to the log file?
Also, it seems the log file contents is less than what shows on the screen
(STDOUT), which I think should be the reverse case, people should be able to
trace more info in the log file? E.g. during downloading rootfs, all the
info where it download from and saved to where are showed on the screen but
missing in the log file...

Toward the end of the installation, I run into:

[ADT_INST] Re-generate environment script file according to rootfs location.
Ls: cannot access /opt/poky/0.9+snapshot-20101211/environment-setup-i586*:
No such file or directory
Sed: no input files

################################################
# Yocto ADT has been successfully installed.
################################################

Since there's error, why it claims successfully installed?

In general, as I mentioned, we need to do more thorough unit test for the
script since we're in the refining phase of the implementation...

Thanks,
Jessica


Re: version problems about SDK

Zhang, Jessica
 

Joshua Lock wrote:
On Sun, 2010-12-12 at 23:53 -0800, Zhang, Jessica wrote:
Tian, Kevin wrote:
From: Ke, Liping
Sent: Monday, December 13, 2010 2:53 PM

Hi, Jessica & Josh

When we are trying to run installer script on lianhao's x86_64
machine, we found if the images are build in two days, according to
current version naming convention, some of the packages will be
installed to /opt/poky/0.9+snapshot-20101210, some will be to
/opt/poky/0.9+snapshot-20101210.
It will cause problem since we need to know the exact version
number before installing and searching some files (environment
script file, etc). And the same releases of packages belong to
different version (just the build date is not in the same day)
seems very strange and hard to handle for us?
I think Josh has laid down the base for multiple version SDK
support. The only problem is:

SDKPATH = "/opt/${DISTRO}/${DISTRO_VERSION}"

which obviously is not what we want. We need a similar variable like
SDK_VERSION, which is incremented only when SDK team thinks there's
a need for a new version release or
else it keeps same in the life cycle of current version.
I disagree, I think it's definitely useful to know which distribution
version your SDK is built against. In fact as the SDK components are
generated from the distro metadata introducing an extra variable
seems a little superfluous and just increases the number of things
which need to be changed for a release.

Also note the DATE element is only included in the DISTRO_VERSION for
development snapshots.
Since the DATE element is only included in the DISTRO_VERSION for
development, then I'd suggest that our SDK_VERSION logic to be as:
If DISTRO_VERSION contains snapshot
SDK_VERSION = 0.9+snapshot (stripe off the date part)
Else
SDK_VERSION = DISTRO_VERSION (which means the DISTRO is a stablized and
meaningful version, e.g. M3_RC1, etc, or 1.0 relrease, etc.)

SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}"

This way we can easily link the SDK_VERSION to DISTRO_VERSION and avoid the
unnecessary version issue during the development cycle...


[PATCH 1/1] linux-yocto/stable: add blktrace configuration to standard branch

Bruce Ashfield <bruce.ashfield@...>
 

Enable the kernel configuration values required for blktrace
by default. Individual boards can opt out as required.

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
.../conf/distro/include/poky-default-revisions.inc | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/conf/distro/include/poky-default-revisions.inc b/meta/conf/distro/include/poky-default-revisions.inc
index be635e5..60f2f06 100644
--- a/meta/conf/distro/include/poky-default-revisions.inc
+++ b/meta/conf/distro/include/poky-default-revisions.inc
@@ -94,7 +94,7 @@ SRCREV_machine_pn-linux-yocto-stable_atom-pc ?= "0431115c9d720fee5bb105f6a7411ef
SRCREV_machine_pn-linux-yocto-stable_routerstationpro ?= "2ec2edaf256dd8500ee3d4763fee6ca3ecd6da4b"
SRCREV_machine_pn-linux-yocto-stable_mpc8315e-rdb ?= "986e6eb66c26007cee7916d5d12f4756e6b5436f"
SRCREV_machine_pn-linux-yocto-stable_beagleboard ?= "0431115c9d720fee5bb105f6a7411efb4f851d26"
-SRCREV_meta_pn-linux-yocto-stable ?= "d1cd5c80ee97e81e130be8c3de3965b770f320d6"
+SRCREV_meta_pn-linux-yocto-stable ?= "50ccd2b3213b6a1bacb3f898c035119802dac420"
# development SRCREVs
SRCREV_machine_pn-linux-yocto_qemuarm = "87e00a2d47ba80b4ad1f9170cb3f6cf81f21d739"
SRCREV_machine_pn-linux-yocto_qemumips = "7231e473dd981a28e3cea9f677ed60583e731550"
--
1.7.0.4


[PATCH 0/1] linux-yocto/stable: enable blktrace

Bruce Ashfield <bruce.ashfield@...>
 

Richard/Saul,

This has been queued for some time, but was held up for
the 2.6.37 work.

Enable the kernel configuration values required for blktrace
by default. Individual boards can opt out as required.

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

Thanks,
Bruce Ashfield <bruce.ashfield@...>
---


Bruce Ashfield (1):
linux-yocto/stable: add blktrace configuration to standard branch

.../conf/distro/include/poky-default-revisions.inc | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)


Re: [PATCH 0/1] bug#565: adding environment files

Saul Wold <sgw@...>
 

On 12/13/2010 04:07 AM, Lianhao Lu wrote:
I rebased the previous patch of adding package of environment files to
be compatible with the new cross-canadian.bbclass
Lianhao,

This may require Richard to look at a little more closely, I do notice that you are missing the LIC_FILES_CHKSUM, for this on you can use one similar to recipes-core/tasks/task-base.bb

The first line of the commit message synopsis needs to be more descriptive, and the bug id needs to be in the commit message so that we can parse it out later.

Synopsis is normally
<recipe | file> : Synopsis

Example:
meta-environment: Added package of meta-environment-${TARGET_ARCH} for environment files.

In the body of the commit message you can add the bug id according to this format:

[BUGID# NNN], where NNN is the bugid

Please fix these issues and resubmit, also you should use the poky@... for bug submissions.

Sau!

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

Thanks,
Lianhao Lu<lianhao.lu@...>
---


Lianhao Lu (1):
Fix bug #565.

meta/classes/toolchain-scripts.bbclass | 32 ++++++++++
meta/recipes-core/meta/meta-environment.bb | 74 ++++++++++++++++++++++++
meta/recipes-core/tasks/task-cross-canadian.bb | 1 +
3 files changed, 107 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-core/meta/meta-environment.bb

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


Re: update status of M2 sprint tasks

Saul Wold <sgw@...>
 

On 12/13/2010 08:31 AM, Mark Hatle wrote:
On 12/13/10 5:53 AM, Tian, Kevin wrote:
Hi, owners,

Since M2 code frozen happened last week and now M2 test has been started, could owners
of each M2 sprint tasks update the latest status on the wiki?

https://wiki.yoctoproject.org/wiki/Yocto_1.0_Schedule

As Saul sent out earlier, we only accept bug fixes on M2 branch now. So if a given task has
not been done (WIP or on track), could you either move it into M3 or fill an updated date
when current one is past?

--M2SB--

"Distro Audit: Package Description/Summary completed", "WIP, Done by Dec 08" (Mark)
I have the work done and tested. Is it too late to submit this?
Mark, go ahead and submit it, so that we can have it available, and can make the call, there is clearly going to be a rebuild of M2 due to the kernel failures, but I am not sure that I want to bring in more than targeted changes at this point.

Remember we are in the stabilize window, which means targeted bug fixes.

Sau!

(There are no code changes, just recipe Description/Summary changes..)

"Zypper/RPM (small writeup)", "WIP, Done by Dec 06" (Mark/Qing)
The write up is done, and outside of the tree.. I just have to post it on the wiki..

"oprofileUI", "WIP, done by Dec 10 " (Jessica)

--M2SC--
"Distro Audit: Licence Checksums ", "WIP, done by Dec 10 " (Saul)
"Zypper/RPM (upgrade to latest version)", "Starting, done by Dec 10" (Mark/Qing)
"push of all relevant Wind River patchs to Yocto ", "WIP, on track for completion by Dec 03 " (Mark)
"Tracing: blktrace and sysprof recipes ", "sysprof by Dec 03 " (Tom)

--M2SD--
"Yocto Installer for SDK Generator Installation functions support ", "WIP, done Dec 09" (Jessica)
"Yocto Installer support for image-creator ", "WIP" (Jessica)

--M2SE--
"Zypper/RPM (integration design)", "slipped out from sprint D" (Mark/Qing)
"Distro Audit: Upgrades Completed (Phase1)", "WIP" (Saul)
"Distro Audit: Src Checksums", "WIP, Done by Dec 9" (Saul)
"enable KVM with qemu", "on track" (Saul/Edwin)
"Performance Enhancement Completed", "on track being reviewed" (Saul/Dongxiao/Qing)
"User specified qemu config support", "on track for Dec 9" (Saul/Criping)
"SDK Version Control support in SDK generator installer", "on track" (Jessica)
"Tracing: Initial SystemTap recipe", "on track" (Tom)
"Documentation for swabber", "on track" (Alex)
"Defect triage process in public documented and implemented" (Saul)

Thanks
Kevin

--
Sau!

Saul Wold
Yocto Component Wrangler @ Intel
Yocto Project / Poky Build System


Re: [poky] [PATCH 0/1] qemuppc: fix 2.6.37 build failure

Saul Wold <sgw@...>
 

On 12/12/2010 09:41 PM, Bruce Ashfield wrote:
Somehow the ppc32 irq routines were only partially updated
to 2.6.37. I'll have to check later to see what happened, since
these were all built and booted here.

The fix is simple enough, here's the update for the SRCREV
that gets qemuppc building again.

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

Thanks,
Bruce Ashfield<bruce.ashfield@...>
---


Bruce Ashfield (1):
qemuppc: update 2.6.37 SRCREV

.../conf/distro/include/poky-default-revisions.inc | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

_______________________________________________
poky mailing list
poky@...
https://lists.yoctoproject.org/listinfo/poky
Bruce,

Thanks for the fast turn on these fixes, there are pulled into master and the 1.0 M2 branch.

Sau!


Re: update status of M2 sprint tasks

Saul Wold <saul.wold@...>
 

On 12/13/2010 08:31 AM, Mark Hatle wrote:
On 12/13/10 5:53 AM, Tian, Kevin wrote:
Hi, owners,

Since M2 code frozen happened last week and now M2 test has been started, could owners
of each M2 sprint tasks update the latest status on the wiki?

https://wiki.yoctoproject.org/wiki/Yocto_1.0_Schedule

As Saul sent out earlier, we only accept bug fixes on M2 branch now. So if a given task has
not been done (WIP or on track), could you either move it into M3 or fill an updated date
when current one is past?

--M2SB--

"Distro Audit: Package Description/Summary completed", "WIP, Done by Dec 08" (Mark)
I have the work done and tested. Is it too late to submit this?
Mark, go ahead and submit it, so that we can have it available, and can make the call, there is clearly going to be a rebuild of M2 due to the kernel failures, but I am not sure that I want to bring in more than targeted changes at this point.

Remember we are in the stabilize window, which means targeted bug fixes.

Sau!

(There are no code changes, just recipe Description/Summary changes..)

"Zypper/RPM (small writeup)", "WIP, Done by Dec 06" (Mark/Qing)
The write up is done, and outside of the tree.. I just have to post it on the wiki..

"oprofileUI", "WIP, done by Dec 10 " (Jessica)

--M2SC--
"Distro Audit: Licence Checksums ", "WIP, done by Dec 10 " (Saul)
"Zypper/RPM (upgrade to latest version)", "Starting, done by Dec 10" (Mark/Qing)
"push of all relevant Wind River patchs to Yocto ", "WIP, on track for completion by Dec 03 " (Mark)
"Tracing: blktrace and sysprof recipes ", "sysprof by Dec 03 " (Tom)

--M2SD--
"Yocto Installer for SDK Generator Installation functions support ", "WIP, done Dec 09" (Jessica)
"Yocto Installer support for image-creator ", "WIP" (Jessica)

--M2SE--
"Zypper/RPM (integration design)", "slipped out from sprint D" (Mark/Qing)
"Distro Audit: Upgrades Completed (Phase1)", "WIP" (Saul)
"Distro Audit: Src Checksums", "WIP, Done by Dec 9" (Saul)
"enable KVM with qemu", "on track" (Saul/Edwin)
"Performance Enhancement Completed", "on track being reviewed" (Saul/Dongxiao/Qing)
"User specified qemu config support", "on track for Dec 9" (Saul/Criping)
"SDK Version Control support in SDK generator installer", "on track" (Jessica)
"Tracing: Initial SystemTap recipe", "on track" (Tom)
"Documentation for swabber", "on track" (Alex)
"Defect triage process in public documented and implemented" (Saul)

Thanks
Kevin


Re: Some simple tests about pseudo performance

Peter Seebach <peter.seebach@...>
 

On Thu, 09 Dec 2010 21:09:36 -0600, Xu, Dongxiao <dongxiao.xu@...> wrote:

fp = fopen("/tmp/12321.txt", "w");
fakeroot doesn't intercept or alter fopen(). It'd be better to test something
that is actually affected by fakeroot for a comparison. :)

fakeroot only traps things like stat and chmod, pseudo traps file system opens
in general. So I would expect a pretty huge difference in this case.

Keep in mind that pseudo's overhead is all around opens, closes, and things
like stat/chmod; reads and writes are unaffected. Most real-world programs that
manipulate files spend a lot more time reading or writing files than opening
them, so a huge impact on file open time is relatively small on actual execution
time.

-s
--
Listen, get this. Nobody, with a good compiler, needs to be justified.


Re: update status of M2 sprint tasks

Saul Wold <saul.wold@...>
 

On 12/13/2010 03:53 AM, Tian, Kevin wrote:
Hi, owners,

Since M2 code frozen happened last week and now M2 test has been started, could owners
of each M2 sprint tasks update the latest status on the wiki?

https://wiki.yoctoproject.org/wiki/Yocto_1.0_Schedule

As Saul sent out earlier, we only accept bug fixes on M2 branch now. So if a given task has
not been done (WIP or on track), could you either move it into M3 or fill an updated date
when current one is past?

--M2SB--

"Distro Audit: Package Description/Summary completed", "WIP, Done by Dec 08" (Mark)
"Zypper/RPM (small writeup)", "WIP, Done by Dec 06" (Mark/Qing)
"oprofileUI", "WIP, done by Dec 10 " (Jessica)

--M2SC--
"Distro Audit: Licence Checksums ", "WIP, done by Dec 10 " (Saul)
Pending Patch is in distro Stage

"Zypper/RPM (upgrade to latest version)", "Starting, done by Dec 10" (Mark/Qing)
"push of all relevant Wind River patchs to Yocto ", "WIP, on track for completion by Dec 03 " (Mark)
"Tracing: blktrace and sysprof recipes ", "sysprof by Dec 03 " (Tom)

--M2SD--
"Yocto Installer for SDK Generator Installation functions support ", "WIP, done Dec 09" (Jessica)
"Yocto Installer support for image-creator ", "WIP" (Jessica)

--M2SE--
"Zypper/RPM (integration design)", "slipped out from sprint D" (Mark/Qing)
"Distro Audit: Upgrades Completed (Phase1)", "WIP" (Saul)
Phase one status was best effort on the the update list, and I will have a summary later this week.

"Distro Audit: Src Checksums", "WIP, Done by Dec 9" (Saul)
All recipes now have SRC_URI Checksums, the checking work is part of the Fetch which is pending with Ke and Richard.

"enable KVM with qemu", "on track" (Saul/Edwin)
Done and in Master

"Performance Enhancement Completed", "on track being reviewed" (Saul/Dongxiao/Qing)
Code is being review by RP, and I think there is some questions about the usage of the hard links.

"User specified qemu config support", "on track for Dec 9" (Saul/Criping)
Not sure what the status of this is currently.

"SDK Version Control support in SDK generator installer", "on track" (Jessica)
"Tracing: Initial SystemTap recipe", "on track" (Tom)
"Documentation for swabber", "on track" (Alex)
"Defect triage process in public documented and implemented" (Saul)
Bug Triage Process is on the Public website, some images need to be updated and I now have the source for those, this can be independent from the release process.


Thanks
Kevin


Re: Bug Verify

Bruce Ashfield <bruce.ashfield@...>
 

On 10-12-13 11:47 AM, Scott Garman wrote:
On 12/13/2010 01:20 AM, Yu, Ke wrote:
Hi,

I hate to raise this question, but there is still bunch of bugs that
is fixed but not verified. According to the process, it is reporter's
responsibility to verify the bug, so could I ask the reporter's help
on this? Process is sometime tedious but helpful to quality
assurance. Thanks a lot for your effort.
I have now verified all my bugs.

However, the process doesn't seem right to me. As the person who fixed
the bug, presumably I performed verification that my fix actually works,
which is why I marked the bug as fixed to begin with.

At every other company I've been with, bug verification is performed by
the QA team - and I think the purpose of it is to ensure someone other
than the developer who fixed the bug can independently verify the bug is
indeed resolved. A second pair of eyes can spot new problems more easily.
I'd second Scott's opinion here. I wasn't marking my bugs
as verified, since as a submitter, I've never had to do
this in 10+ years in the 'biz'.

Cheers,

Bruce


JMO,

Scott


Re: Bug Verify

Scott Garman <scott.a.garman@...>
 

On 12/13/2010 01:20 AM, Yu, Ke wrote:
Hi,

I hate to raise this question, but there is still bunch of bugs that
is fixed but not verified. According to the process, it is reporter's
responsibility to verify the bug, so could I ask the reporter's help
on this? Process is sometime tedious but helpful to quality
assurance. Thanks a lot for your effort.
I have now verified all my bugs.

However, the process doesn't seem right to me. As the person who fixed the bug, presumably I performed verification that my fix actually works, which is why I marked the bug as fixed to begin with.

At every other company I've been with, bug verification is performed by the QA team - and I think the purpose of it is to ensure someone other than the developer who fixed the bug can independently verify the bug is indeed resolved. A second pair of eyes can spot new problems more easily.

JMO,

Scott

--
Scott Garman
Embedded Linux Distro Engineer - Yocto Project


Re: update status of M2 sprint tasks

Mark Hatle <mark.hatle@...>
 

On 12/13/10 5:53 AM, Tian, Kevin wrote:
Hi, owners,

Since M2 code frozen happened last week and now M2 test has been started, could owners
of each M2 sprint tasks update the latest status on the wiki?

https://wiki.yoctoproject.org/wiki/Yocto_1.0_Schedule

As Saul sent out earlier, we only accept bug fixes on M2 branch now. So if a given task has
not been done (WIP or on track), could you either move it into M3 or fill an updated date
when current one is past?

--M2SB--

"Distro Audit: Package Description/Summary completed", "WIP, Done by Dec 08" (Mark)
I have the work done and tested. Is it too late to submit this?

(There are no code changes, just recipe Description/Summary changes..)

"Zypper/RPM (small writeup)", "WIP, Done by Dec 06" (Mark/Qing)
The write up is done, and outside of the tree.. I just have to post it on the wiki..

"oprofileUI", "WIP, done by Dec 10 " (Jessica)

--M2SC--
"Distro Audit: Licence Checksums ", "WIP, done by Dec 10 " (Saul)
"Zypper/RPM (upgrade to latest version)", "Starting, done by Dec 10" (Mark/Qing)
"push of all relevant Wind River patchs to Yocto ", "WIP, on track for completion by Dec 03 " (Mark)
"Tracing: blktrace and sysprof recipes ", "sysprof by Dec 03 " (Tom)

--M2SD--
"Yocto Installer for SDK Generator Installation functions support ", "WIP, done Dec 09" (Jessica)
"Yocto Installer support for image-creator ", "WIP" (Jessica)

--M2SE--
"Zypper/RPM (integration design)", "slipped out from sprint D" (Mark/Qing)
"Distro Audit: Upgrades Completed (Phase1)", "WIP" (Saul)
"Distro Audit: Src Checksums", "WIP, Done by Dec 9" (Saul)
"enable KVM with qemu", "on track" (Saul/Edwin)
"Performance Enhancement Completed", "on track being reviewed" (Saul/Dongxiao/Qing)
"User specified qemu config support", "on track for Dec 9" (Saul/Criping)
"SDK Version Control support in SDK generator installer", "on track" (Jessica)
"Tracing: Initial SystemTap recipe", "on track" (Tom)
"Documentation for swabber", "on track" (Alex)
"Defect triage process in public documented and implemented" (Saul)

Thanks
Kevin


Re: Some simple tests about pseudo performance

Mark Hatle <mark.hatle@...>
 

On 12/9/10 9:09 PM, Xu, Dongxiao wrote:
Test results are:

Native: 2.729 secs
Fakeroot: 2.752 secs
Pseudo: 51.814 secs

We saw pseudo cost about 20 times of seconds than native and fakeroot.
I believe that this is part of the fundamental differences between fakeroot and
pseudo. Fakeroot only persists data on shutdown, while pseudo does persistence
during the read/writes.

What I'm surprised by is that opening/closing the SAME file is so busy. I would
have expected the larger overhead to be in multiple file read/writes.

I did a profile when the program is running. From the following table we saw
that a lot of cycles are within sqlite3 operations...

I am wondering whether this point can be optimized? For example, is it
workable to cache those database operations in memory and finally flush it into
disk when pseudo exits?
Pseudo is using sqlite directly.

I did some basic checking, and sqlite has been instructed to run with the
following modes:

PRAGMA legacy_file_format = OFF
PRAGMA journal_mode = PERSIST
PRAGMA locking_mode = EXCLUSIVE
PRAGMA synchronous = OFF

Without doing any further investigation perhaps those modes aren't the best ones
to use? Also in prior work I've done with sqlite using transaction cues seemed
to also help with performance.

It would be interesting to determine where the performance penalties are in
this. I'm guessing it's the name resolution... but I'm still surprised at the
speed. (There is also an IPC transaction between libpseudo and the pseudo
server. From your logs that doesn't appear to be too bad though.)

--Mark

It's just a first thought and any suggestion and comment is welcome.

Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000
samples % image name app name symbol name
693127 58.2980 no-vmlinux no-vmlinux /no-vmlinux
211108 17.7560 libsqlite3.so.0.8.6 libsqlite3.so.0.8.6 /usr/lib/libsqlite3.so.0.8.6
112269 9.4428 libc-2.10.1.so libc-2.10.1.so /lib/tls/i686/cmov/libc-2.10.1.so
16792 1.4124 [vdso] (tgid:28674 range:0xfd0000-0xfd1000) a.out [vdso] (tgid:28674 range:0xfd0000-0xfd1000)
15256 1.2832 libpthread-2.10.1.so libpthread-2.10.1.so pthread_mutex_lock
13163 1.1071 libpthread-2.10.1.so libpthread-2.10.1.so __pthread_mutex_unlock_usercnt
7386 0.6212 libpseudo.so libpseudo.so pseudo_client_op
6753 0.5680 libpseudo.so libpseudo.so pseudo_debug_real
6680 0.5618 pseudo pseudo pseudo_server_start
6663 0.5604 [vdso] (tgid:28676 range:0x8d6000-0x8d7000) pseudo [vdso] (tgid:28676 range:0x8d6000-0x8d7000)
5049 0.4247 pseudo pseudo pseudo_op
4906 0.4126 [vdso] (tgid:28467 range:0xd32000-0xd33000) a.out [vdso] (tgid:28467 range:0xd32000-0xd33000)
4427 0.3723 [vdso] (tgid:28607 range:0x5c0000-0x5c1000) a.out [vdso] (tgid:28607 range:0x5c0000-0x5c1000)
4391 0.3693 [vdso] (tgid:29027 range:0x6d0000-0x6d1000) a.out [vdso] (tgid:29027 range:0x6d0000-0x6d1000)
4188 0.3522 [vdso] (tgid:29172 range:0x41a000-0x41b000) a.out [vdso] (tgid:29172 range:0x41a000-0x41b000)
3584 0.3014 [vdso] (tgid:2411 range:0x892000-0x893000) a.out [vdso] (tgid:2411 range:0x892000-0x893000)
2985 0.2511 pseudo pseudo pseudo_debug_real
2921 0.2457 postgres postgres /usr/lib/postgresql/8.3/bin/postgres
2905 0.2443 vim.basic vim.basic /usr/bin/vim.basic
2449 0.2060 bash bash /bin/bash
2439 0.2051 libpseudo.so libpseudo.so fopen
2163 0.1819 [vdso] (tgid:28609 range:0x3da000-0x3db000) pseudo [vdso] (tgid:28609 range:0x3da000-0x3db000)
2096 0.1763 [vdso] (tgid:29029 range:0xfef000-0xff0000) pseudo [vdso] (tgid:29029 range:0xfef000-0xff0000)
2086 0.1755 libpseudo.so libpseudo.so pseudo_append_element
1917 0.1612 [vdso] (tgid:28469 range:0xe72000-0xe73000) pseudo [vdso] (tgid:28469 range:0xe72000-0xe73000)
1835 0.1543 libpseudo.so libpseudo.so wrap_fopen
1833 0.1542 libpseudo.so libpseudo.so pseudo_msg_receive
1819 0.1530 libpseudo.so libpseudo.so __lxstat64
1762 0.1482 libpseudo.so libpseudo.so __i686.get_pc_thunk.bx

Thanks,
Dongxiao


Re: version problems about SDK

Tian, Kevin <kevin.tian@...>
 

From: Joshua Lock
Sent: Monday, December 13, 2010 8:01 PM

On Sun, 2010-12-12 at 23:53 -0800, Zhang, Jessica wrote:
Tian, Kevin wrote:
From: Ke, Liping
Sent: Monday, December 13, 2010 2:53 PM

Hi, Jessica & Josh

When we are trying to run installer script on lianhao's x86_64
machine, we found if the images are build in two days, according to
current version naming convention, some of the packages will be
installed to /opt/poky/0.9+snapshot-20101210, some will be to
/opt/poky/0.9+snapshot-20101210.
It will cause problem since we need to know the exact version number
before installing and searching some files (environment script file,
etc). And the same releases of packages belong to different version
(just the build date is not in the same day) seems very strange and
hard to handle for us?
I think Josh has laid down the base for multiple version SDK support.
The only problem is:

SDKPATH = "/opt/${DISTRO}/${DISTRO_VERSION}"

which obviously is not what we want. We need a similar variable like
SDK_VERSION, which is incremented only when SDK team thinks there's a
need for a new version release or
else it keeps same in the life cycle of current version.
I disagree, I think it's definitely useful to know which distribution
version your SDK is built against. In fact as the SDK components are
generated from the distro metadata introducing an extra variable seems a
little superfluous and just increases the number of things which need to
be changed for a release.
Yes, SDK is generated from the distro metadata, which however doesn't prevent SDK
as a standalone component to have its own version variable. We can have:

SDK_VERSION = ${DISTRO_VERSION}

or,

SDK_VERSION = ${DISTRO_VERSION}${SDK_REVISION}

or,

SDK_VERSION = ...

I'm just a little bit worried to deduce SDK version from another variable (SDKPATH)
implicitly.

I agree that to have distribution version included will be informative, e.g in Android:
"SDK platform Andriod 2.3, API 9, revision 1"


Also note the DATE element is only included in the DISTRO_VERSION for
development snapshots.
Good to know this info.

Thanks
Kevin


Re: Bug Verify

Tian, Kevin <kevin.tian@...>
 

From: Joshua Lock [mailto:josh@...]
Sent: Monday, December 13, 2010 8:07 PM

On Mon, 2010-12-13 at 19:56 +0800, Tian, Kevin wrote:
From: Joshua Lock
Sent: Monday, December 13, 2010 7:49 PM

On Mon, 2010-12-13 at 17:20 +0800, Yu, Ke wrote:
Hi,

I hate to raise this question, but there is still bunch of bugs that is fixed but not verified.
According to the process, it is reporter's responsibility to verify the bug, so could I ask
the
reporter's help on this? Process is sometime tedious but helpful to quality assurance.
Thanks
a lot for your effort.

I've just gone through and verified the bugs I've filed. I think we
could make this process easier to remember if we had a shared saved
search "bugs I need to verify"?
You should be able to save that search under your account directly... :-)
Of course, but I can only create a saved search for myself (and I now
have that).

However, I was assuming the bugzilla admin could create a search which
would show the logged in user all of their bugs which need verifying.

Just trying to think of ways to make this process more obvious for the
team.
Got it. I'm not an export on Bugzilla. Perhaps Kangkang can have some comment whether
this is feasible. It looks a good thing though. :-)

Thanks
Kevin


[PATCH 0/1] bug#565: adding environment files

Lianhao Lu <lianhao.lu@...>
 

I rebased the previous patch of adding package of environment files to
be compatible with the new cross-canadian.bbclass

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

Thanks,
Lianhao Lu <lianhao.lu@...>
---


Lianhao Lu (1):
Fix bug #565.

meta/classes/toolchain-scripts.bbclass | 32 ++++++++++
meta/recipes-core/meta/meta-environment.bb | 74 ++++++++++++++++++++++++
meta/recipes-core/tasks/task-cross-canadian.bb | 1 +
3 files changed, 107 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-core/meta/meta-environment.bb


Re: Bug Verify

Joshua Lock <josh@...>
 

On Mon, 2010-12-13 at 19:56 +0800, Tian, Kevin wrote:
From: Joshua Lock
Sent: Monday, December 13, 2010 7:49 PM

On Mon, 2010-12-13 at 17:20 +0800, Yu, Ke wrote:
Hi,

I hate to raise this question, but there is still bunch of bugs that is fixed but not verified.
According to the process, it is reporter's responsibility to verify the bug, so could I ask the
reporter's help on this? Process is sometime tedious but helpful to quality assurance. Thanks
a lot for your effort.

I've just gone through and verified the bugs I've filed. I think we
could make this process easier to remember if we had a shared saved
search "bugs I need to verify"?
You should be able to save that search under your account directly... :-)
Of course, but I can only create a saved search for myself (and I now
have that).

However, I was assuming the bugzilla admin could create a search which
would show the logged in user all of their bugs which need verifying.

Just trying to think of ways to make this process more obvious for the
team.

Cheers,
Joshua
--
Joshua Lock
Intel Open Source Technology Centre


Re: version problems about SDK

Joshua Lock <joshua.lock@...>
 

On Sun, 2010-12-12 at 23:53 -0800, Zhang, Jessica wrote:
Tian, Kevin wrote:
From: Ke, Liping
Sent: Monday, December 13, 2010 2:53 PM

Hi, Jessica & Josh

When we are trying to run installer script on lianhao's x86_64
machine, we found if the images are build in two days, according to
current version naming convention, some of the packages will be
installed to /opt/poky/0.9+snapshot-20101210, some will be to
/opt/poky/0.9+snapshot-20101210.
It will cause problem since we need to know the exact version number
before installing and searching some files (environment script file,
etc). And the same releases of packages belong to different version
(just the build date is not in the same day) seems very strange and
hard to handle for us?
I think Josh has laid down the base for multiple version SDK support.
The only problem is:

SDKPATH = "/opt/${DISTRO}/${DISTRO_VERSION}"

which obviously is not what we want. We need a similar variable like
SDK_VERSION, which is incremented only when SDK team thinks there's a
need for a new version release or
else it keeps same in the life cycle of current version.
I disagree, I think it's definitely useful to know which distribution
version your SDK is built against. In fact as the SDK components are
generated from the distro metadata introducing an extra variable seems a
little superfluous and just increases the number of things which need to
be changed for a release.

Also note the DATE element is only included in the DISTRO_VERSION for
development snapshots.

Cheers,
Joshua
--
Joshua Lock
Intel Open Source Technology Centre

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: update status of M2 sprint tasks

Tian, Kevin <kevin.tian@...>
 

I tried to CC all the owners in original mail, which however ended up to need moderation
because too many recipients. (not sure why only Saul is kept. :-)) So please take a look
on below list to make sure your owned item being updated.

Thanks
Kevin

From: Tian, Kevin
Sent: Monday, December 13, 2010 7:54 PM

Hi, owners,

Since M2 code frozen happened last week and now M2 test has been started, could owners
of each M2 sprint tasks update the latest status on the wiki?

https://wiki.yoctoproject.org/wiki/Yocto_1.0_Schedule

As Saul sent out earlier, we only accept bug fixes on M2 branch now. So if a given task has
not been done (WIP or on track), could you either move it into M3 or fill an updated date
when current one is past?

--M2SB--

"Distro Audit: Package Description/Summary completed", "WIP, Done by Dec 08" (Mark)
"Zypper/RPM (small writeup)", "WIP, Done by Dec 06" (Mark/Qing)
"oprofileUI", "WIP, done by Dec 10 " (Jessica)

--M2SC--
"Distro Audit: Licence Checksums ", "WIP, done by Dec 10 " (Saul)
"Zypper/RPM (upgrade to latest version)", "Starting, done by Dec 10" (Mark/Qing)
"push of all relevant Wind River patchs to Yocto ", "WIP, on track for completion by Dec 03
" (Mark)
"Tracing: blktrace and sysprof recipes ", "sysprof by Dec 03 " (Tom)

--M2SD--
"Yocto Installer for SDK Generator Installation functions support ", "WIP, done Dec 09"
(Jessica)
"Yocto Installer support for image-creator ", "WIP" (Jessica)

--M2SE--
"Zypper/RPM (integration design)", "slipped out from sprint D" (Mark/Qing)
"Distro Audit: Upgrades Completed (Phase1)", "WIP" (Saul)
"Distro Audit: Src Checksums", "WIP, Done by Dec 9" (Saul)
"enable KVM with qemu", "on track" (Saul/Edwin)
"Performance Enhancement Completed", "on track being reviewed" (Saul/Dongxiao/Qing)
"User specified qemu config support", "on track for Dec 9" (Saul/Criping)
"SDK Version Control support in SDK generator installer", "on track" (Jessica)
"Tracing: Initial SystemTap recipe", "on track" (Tom)
"Documentation for swabber", "on track" (Alex)
"Defect triage process in public documented and implemented" (Saul)

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