Date   

Re: Questions about the name of qemu bin file for different archs

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

What's more, I found sometimes, for example, there's no symbolic links, so the name is very long and strange.

Such as one ppc image: zImage-2.6.34+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+9ac0daee43dd19d8bea828cf79450c9748ae0daa-r13-qemuppc-20101210020445.bin

Since I need to download the specific file, so a definite naming is needed such as for x86, it is bzImage-qemux86.bin, for arm, it is bzImage-qemuarm.bin,
For powerpc, it is bzImage-qemupowerpc.bin, etc.

Am I right?

criping

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Ke, Liping
Sent: Tuesday, December 14, 2010 3:41 PM
To: Zhang, Jessica
Cc: yocto@...
Subject: [yocto] Questions about the name of qemu bin file for
different archs

Hi, Jessica

I found qemu bin file name convention is different for different archs,
for example, for x86, it is bzImage-qemuXXX.
For arm, it is zImage-qemuXXX. My question is why it is bzXXX or zXXX,
is there any reason of such naming convention?

Or I must did name translate for each kind of arch qemu bin file?


Thanks& Regards,
criping
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: update status of M2 sprint tasks

Tom Zanussi <tom.zanussi@...>
 

On Mon, 2010-12-13 at 03:53 -0800, 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)
"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)
This is done, but there's a bug (581) against blktrace that I need to
look at.


--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)
BSP work not on the schedule has pushed this out - I'll be getting to it
as soon as that work's done, sometime this week...

Tom

"Documentation for swabber", "on track" (Alex)
"Defect triage process in public documented and implemented" (Saul)

Thanks
Kevin


Questions about the name of qemu bin file for different archs

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

Hi, Jessica

I found qemu bin file name convention is different for different archs, for example, for x86, it is bzImage-qemuXXX.
For arm, it is zImage-qemuXXX. My question is why it is bzXXX or zXXX, is there any reason of such naming convention?

Or I must did name translate for each kind of arch qemu bin file?


Thanks& Regards,
criping


Re: Try latest yocto adt script installer

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

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!
Oh, it's caused by the include grammar. I need to check how to solve the
relative path problem with include grammar in shell script. It should not
be difficult.


#############################################
# 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.
No problem, I will unify all error messages.

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!
It's expected behavior. Since powerpcc is the correct name.


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...
Log file problem is solved totally by replacing " >> " with "&>>" pointed by Lianhao.


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
Missing guard will be added here.
I will send the updated scripts which will address most of the problem.


Btw: I need someone review the script totally. I am afraid some of the scripts
Might not obey shell's world conventions since this is the first script I wrote.
I have to say I did try several blackbox test yet failed to cover all corner problems.

Updated scripts will soon be published.

Thanks & Regards,
criping


Re: Add extra parameters for qemu script

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

Hi, Scott

I have updated the patch and tested with poky-tree mode (arm, x86).
Since kvm and serial needs special processing, so for avoiding repeating the code, I will exclude serial and kvm in permitted extra-option, user need to use (serial, kvm) it they want to use it.

For "<-m XXX>" options, I will keep the original logic. If it's arm, the > 128M memory will be forced back to 128M.

It's the high-level user's responsibility to make sure other params are valid.

Any problem, just let me know.

Thanks a lot for your help!

criping

-----Original Message-----
From: Garman, Scott A
Sent: Monday, December 13, 2010 10:16 AM
To: Ke, Liping
Cc: Richard Purdie; Zhang, Jessica; Lu, Lianhao; Cui, Dexuan;
yocto@...
Subject: Re: Add extra parameters for qemu script

On 12/12/2010 05:43 PM, Ke, Liping wrote:
I tend to feel that this approach is more flexible, and scales
better
than having to support each and every qemu option with our own
script
syntax. Is this acceptable, or should we continue to support our
own
custom options in addition to Criping's new approach?
My gut feeling is that having some simplified way to trigger
possibly
complex option combinations is still desirable but adding a way to
pass
additional custom commandline is equally good. This gives us the
maximum
flexibility moving forwards but keeps the script easy to use?
Hi, Scott

So the conclusion is that I should keep the old (serial nographic)
option while
adding the new "<-XXX -XXX -XXX>" option?
OK. I will send out the modified patch to you for review later.
Yes, please respin the patch with those changes.

Thanks!

Scott

--
Scott Garman
Embedded Linux Distro Engineer - Yocto Project


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