Does this look familiar?  Why would I be getting these errors when
following the Yocto Project Quick Start instructions, without changes?
 Did I miss something?

It does not. However this is when trying to build perl-native, i.e. Poky
is trying to build its own version of Perl but linked against your
system libraries etc and is unable to find some pthread functions to
link to.

Can you tell us which distribution/version combination you are using?

Could be that we need to patch perl-native to -lpthread ?

Is your host Ubuntu 11.04 on x86 (not x86_64)?  There was a patch for this
that I'm not sure got back ported into Bernard.

Oops. I forgot to provide those details...

My host is Ubuntu 11.04 64 bit:

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=11.04
DISTRIB_CODENAME=natty
DISTRIB_DESCRIPTION="Ubuntu 11.04"
$ uname -m
x86_64

I ran `wget http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.tar.bz2`
(as directed in the Yocto Project Quick Start). Does that 5.0
correspond to Yocto Project 1.0.1?

I found http://bit.ly/lzyY5b (an email on the gumstix-users mailing
list, archived on old.nabble.com), which appears to be the same
problem. I ran:

$ sudo apt-get install pthread*
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'libpthread-stubs0' for regex 'pthread*'
Note, selecting 'libpthread-stubs0-dev' for regex 'pthread*'
libpthread-stubs0 is already the newest version.
libpthread-stubs0 set to manually installed.
libpthread-stubs0-dev is already the newest version.
libpthread-stubs0-dev set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

I'll read through the rest of that thread to see if can find a
solution. But I thought I'd send this information off in case it
triggers someone to suggest a solution specific to the Yocto Project.

--
Daryl


On Wed, Jun 8, 2011 at 4:17 AM, Gary Thomas <gary@...> wrote:

On 06/07/2011 10:38 PM, Joshua Lock wrote:

On Tue, 2011-06-07 at 19:41 -0700, Daryl Spitzer wrote:

The good news is that following the instructions in
https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy
seems to have solved my proxy problems.  But unfortunately I'm getting
errors after running `bitbake -k poky-image-sato`, following the
"Building an Image" instructions in the Yocto Project Quick Start.  (I
didn't make any changes to the conf/local.conf file generated by
`source poky-bernard-5.0/poky-init-build-env poky-5.0-build`, except
to add the CVS setup lines as directed in the
Working_Behind_a_Network_Proxy wiki page.)  When I repeat `bitbake -k
poky-image-sato` I believe I get the same results.

Here's the output, up to and including the first error:


Loading cache...done.
Loaded 980 entries from dependency cache.
Parsing recipes...done.
Parsing of 783 .bb files complete (772 cached, 11 parsed). 991
targets, 11 skipped, 0 masked, 0 errors.

OE Build Configuration:
BB_VERSION        = "1.11.0"
METADATA_BRANCH   = "<unknown>"
METADATA_REVISION = "<unknown>"
TARGET_ARCH       = "i586"
TARGET_OS         = "linux"
MACHINE           = "qemux86"
DISTRO            = "poky"
DISTRO_VERSION    = "1.0"
TARGET_FPU        = ""

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 632 of 4961 (ID: 387,

/home/daryls/yocto/poky-bernard-5.0/meta/recipes-devtools/perl/perl-native_5.12.2.bb,
do_compile)
NOTE: package perl-native-5.12.2-r7: task do_compile: Started
ERROR: Function 'do_compile' failed (see

/home/daryls/yocto/poky-5.0-build/tmp/work/x86_64-linux/perl-native-5.12.2-r7/temp/log.do_compile.27994
for further information)
...

----------

And here's the head of log.do_compile.27994:


OTE: make -e MAKEFLAGS=
gcc -L/home/daryls/yocto/poky-5.0-build/tmp/sysroots/x86_64-linux/usr/lib

-Wl,-rpath-link,/home/daryls/yocto/poky-5.0-build/tmp/sysroots/x86_64-linux/usr/lib

-Wl,-rpath,/home/daryls/yocto/poky-5.0-build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-O1 -fstack-protector -L/usr/local/lib -o miniperl \
             gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o
reentr.o
mro.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o
doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o
perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o
\
           miniperlmain.o opmini.o perlmini.o
util.o: In function `Perl_safesysmalloc':
util.c:(.text+0x558): undefined reference to `pthread_getspecific'
util.o: In function `Perl_safesysrealloc':
util.c:(.text+0x5f0): undefined reference to `pthread_getspecific'
util.o: In function `Perl_croak_nocontext':
util.c:(.text+0x19b6): undefined reference to `pthread_getspecific'

----------

Does this look familiar?  Why would I be getting these errors when
following the Yocto Project Quick Start instructions, without changes?
 Did I miss something?

It does not. However this is when trying to build perl-native, i.e. Poky
is trying to build its own version of Perl but linked against your
system libraries etc and is unable to find some pthread functions to
link to.

Can you tell us which distribution/version combination you are using?

Could be that we need to patch perl-native to -lpthread ?

Is your host Ubuntu 11.04 on x86 (not x86_64)?  There was a patch for this
that I'm not sure got back ported into Bernard.

--
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

On 06/07/2011 10:38 PM, Joshua Lock wrote:

On Tue, 2011-06-07 at 19:41 -0700, Daryl Spitzer wrote:

The good news is that following the instructions in
https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy
seems to have solved my proxy problems. But unfortunately I'm getting
errors after running `bitbake -k poky-image-sato`, following the
"Building an Image" instructions in the Yocto Project Quick Start. (I
didn't make any changes to the conf/local.conf file generated by
`source poky-bernard-5.0/poky-init-build-env poky-5.0-build`, except
to add the CVS setup lines as directed in the
Working_Behind_a_Network_Proxy wiki page.) When I repeat `bitbake -k
poky-image-sato` I believe I get the same results.

Here's the output, up to and including the first error:


Loading cache...done.
Loaded 980 entries from dependency cache.
Parsing recipes...done.
Parsing of 783 .bb files complete (772 cached, 11 parsed). 991
targets, 11 skipped, 0 masked, 0 errors.

OE Build Configuration:
BB_VERSION = "1.11.0"
METADATA_BRANCH = "<unknown>"
METADATA_REVISION = "<unknown>"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "qemux86"
DISTRO = "poky"
DISTRO_VERSION = "1.0"
TARGET_FPU = ""

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 632 of 4961 (ID: 387,
/home/daryls/yocto/poky-bernard-5.0/meta/recipes-devtools/perl/perl-native_5.12.2.bb,
do_compile)
NOTE: package perl-native-5.12.2-r7: task do_compile: Started
ERROR: Function 'do_compile' failed (see
/home/daryls/yocto/poky-5.0-build/tmp/work/x86_64-linux/perl-native-5.12.2-r7/temp/log.do_compile.27994
for further information)
...

----------

And here's the head of log.do_compile.27994:


OTE: make -e MAKEFLAGS=
gcc -L/home/daryls/yocto/poky-5.0-build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-rpath-link,/home/daryls/yocto/poky-5.0-build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-rpath,/home/daryls/yocto/poky-5.0-build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-O1 -fstack-protector -L/usr/local/lib -o miniperl \
gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o
mro.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o
doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o
perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o
\
miniperlmain.o opmini.o perlmini.o
util.o: In function `Perl_safesysmalloc':
util.c:(.text+0x558): undefined reference to `pthread_getspecific'
util.o: In function `Perl_safesysrealloc':
util.c:(.text+0x5f0): undefined reference to `pthread_getspecific'
util.o: In function `Perl_croak_nocontext':
util.c:(.text+0x19b6): undefined reference to `pthread_getspecific'

----------

Does this look familiar? Why would I be getting these errors when
following the Yocto Project Quick Start instructions, without changes?
Did I miss something?

It does not. However this is when trying to build perl-native, i.e. Poky
is trying to build its own version of Perl but linked against your
system libraries etc and is unable to find some pthread functions to
link to.

Can you tell us which distribution/version combination you are using?

Could be that we need to patch perl-native to -lpthread ?

Is your host Ubuntu 11.04 on x86 (not x86_64)? There was a patch for this
that I'm not sure got back ported into Bernard.

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------

On Tue, 2011-06-07 at 19:41 -0700, Daryl Spitzer wrote:

The good news is that following the instructions in
https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy
seems to have solved my proxy problems. But unfortunately I'm getting
errors after running `bitbake -k poky-image-sato`, following the
"Building an Image" instructions in the Yocto Project Quick Start. (I
didn't make any changes to the conf/local.conf file generated by
`source poky-bernard-5.0/poky-init-build-env poky-5.0-build`, except
to add the CVS setup lines as directed in the
Working_Behind_a_Network_Proxy wiki page.) When I repeat `bitbake -k
poky-image-sato` I believe I get the same results.

Here's the output, up to and including the first error:


Loading cache...done.
Loaded 980 entries from dependency cache.
Parsing recipes...done.
Parsing of 783 .bb files complete (772 cached, 11 parsed). 991
targets, 11 skipped, 0 masked, 0 errors.

OE Build Configuration:
BB_VERSION = "1.11.0"
METADATA_BRANCH = "<unknown>"
METADATA_REVISION = "<unknown>"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "qemux86"
DISTRO = "poky"
DISTRO_VERSION = "1.0"
TARGET_FPU = ""

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 632 of 4961 (ID: 387,
/home/daryls/yocto/poky-bernard-5.0/meta/recipes-devtools/perl/perl-native_5.12.2.bb,
do_compile)
NOTE: package perl-native-5.12.2-r7: task do_compile: Started
ERROR: Function 'do_compile' failed (see
/home/daryls/yocto/poky-5.0-build/tmp/work/x86_64-linux/perl-native-5.12.2-r7/temp/log.do_compile.27994
for further information)
...

----------

And here's the head of log.do_compile.27994:


OTE: make -e MAKEFLAGS=
gcc -L/home/daryls/yocto/poky-5.0-build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-rpath-link,/home/daryls/yocto/poky-5.0-build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-rpath,/home/daryls/yocto/poky-5.0-build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-O1 -fstack-protector -L/usr/local/lib -o miniperl \
gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o
mro.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o
doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o
perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o
\
miniperlmain.o opmini.o perlmini.o
util.o: In function `Perl_safesysmalloc':
util.c:(.text+0x558): undefined reference to `pthread_getspecific'
util.o: In function `Perl_safesysrealloc':
util.c:(.text+0x5f0): undefined reference to `pthread_getspecific'
util.o: In function `Perl_croak_nocontext':
util.c:(.text+0x19b6): undefined reference to `pthread_getspecific'

----------

Does this look familiar? Why would I be getting these errors when
following the Yocto Project Quick Start instructions, without changes?
Did I miss something?

It does not. However this is when trying to build perl-native, i.e. Poky
is trying to build its own version of Perl but linked against your
system libraries etc and is unable to find some pthread functions to
link to.

Can you tell us which distribution/version combination you are using?

Could be that we need to patch perl-native to -lpthread ?

Thanks,
Joshua
--
Joshua Lock
Yocto Build System Monkey
Intel Open Source Technology Centre

The good news is that following the instructions in
https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy
seems to have solved my proxy problems. But unfortunately I'm getting
errors after running `bitbake -k poky-image-sato`, following the
"Building an Image" instructions in the Yocto Project Quick Start. (I
didn't make any changes to the conf/local.conf file generated by
`source poky-bernard-5.0/poky-init-build-env poky-5.0-build`, except
to add the CVS setup lines as directed in the
Working_Behind_a_Network_Proxy wiki page.) When I repeat `bitbake -k
poky-image-sato` I believe I get the same results.

Here's the output, up to and including the first error:


Loading cache...done.
Loaded 980 entries from dependency cache.
Parsing recipes...done.
Parsing of 783 .bb files complete (772 cached, 11 parsed). 991
targets, 11 skipped, 0 masked, 0 errors.

OE Build Configuration:
BB_VERSION = "1.11.0"
METADATA_BRANCH = "<unknown>"
METADATA_REVISION = "<unknown>"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "qemux86"
DISTRO = "poky"
DISTRO_VERSION = "1.0"
TARGET_FPU = ""

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 632 of 4961 (ID: 387,
/home/daryls/yocto/poky-bernard-5.0/meta/recipes-devtools/perl/perl-native_5.12.2.bb,
do_compile)
NOTE: package perl-native-5.12.2-r7: task do_compile: Started
ERROR: Function 'do_compile' failed (see
/home/daryls/yocto/poky-5.0-build/tmp/work/x86_64-linux/perl-native-5.12.2-r7/temp/log.do_compile.27994
for further information)
...

----------

And here's the head of log.do_compile.27994:


OTE: make -e MAKEFLAGS=
gcc -L/home/daryls/yocto/poky-5.0-build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-rpath-link,/home/daryls/yocto/poky-5.0-build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-rpath,/home/daryls/yocto/poky-5.0-build/tmp/sysroots/x86_64-linux/usr/lib
-Wl,-O1 -fstack-protector -L/usr/local/lib -o miniperl \
gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o
mro.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o
doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o
perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o
\
miniperlmain.o opmini.o perlmini.o
util.o: In function `Perl_safesysmalloc':
util.c:(.text+0x558): undefined reference to `pthread_getspecific'
util.o: In function `Perl_safesysrealloc':
util.c:(.text+0x5f0): undefined reference to `pthread_getspecific'
util.o: In function `Perl_croak_nocontext':
util.c:(.text+0x19b6): undefined reference to `pthread_getspecific'

----------

Does this look familiar? Why would I be getting these errors when
following the Yocto Project Quick Start instructions, without changes?
Did I miss something?

--
Daryl

On 06/06/2011 09:36 PM, Xu, Jiajun wrote:

Hi all,

This is the fullpass test report for Yocto 1.1 M1 RC2 build. There are
3 new bugs found in this testing compared with weekly testing.
Non-GPLv3 build could not work and one new LTP failure found with new
kernel. The 2 BLOCK issues on have been addressed and a new build is
ready for QA testing. Except for LTP and POSIX failures, there are 13
open bugs for RC2 build. Grub installation fails on 3 intel BSPs.
Graphics testing on sugarbay is blocked because there are no mesa-demos
and libSDL.so installed.

Jiajun, Yi Zhao,

What's the status of the Beagleboard testing, you show blocked below,
but I thought we unblocked last week, so is there any update on the
status of beagleboard testing? We need to know this since we have a
conditional GO decision based on these results.

Hi Saul,
Yi is doing testing for beagleboard and I think he would send out test status today.

I would like to also understand the sugarbay graphics testing, this is
not a blocker, it's a new requirement, correct? We have not had
mesa-demos included in any past release. I am going to add it to the
sato-sdk build only, will that be?

Sugarbay graphics testing was introduced during 1.0 M4. At that time, we had to build mesa-demos by ourselves and copy it into target image. We submitted bugs for it during 1.1 M1 because we think it better to use mesa-demos built from autobuilder.
And yes, adding it into sato-sdk is good enough.

Thanks a lot.

Sau!

Best Regards,
Jiajun

Notes

 

Attendees:

 

Shane, Dave, Saul, Darren, Richard, Tom, Julie, Ke, ScottG, JeffO, Paul, Jessica, Bruce, Beth, Dennis (TI)

 

Agenda:

• Review Yocto 1.1 M1 Release Criteria – 10 min (Julie)

• See details at: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.1_Release_Criteria
• Everything is green. We achieved this in the sense that the team has reached a conscious decision to move something from M1 to M2. Next time, we should have some must-have features defined before we go into next milestone.
• Yocto and BSPs were build.
• New bugs: 1037 is for M1, but this is not a show stopper. We are ok with this.
• No high bugs

 

• Discuss M1 1.1 M1 Release Status, go/no-go vote – 10 min (Julie)

• Beagle board can be built now, is under testing
• Our goal of these milestones is to have some major features accomplished.
• We have a conditional go for M1 provided that we get test result for beagle board test result, and no show stoppers.
• Proposed plan:

1. Saul: Check test result with Jiajun and see if there is any show stoppers
2. Beth send email for release
3. Dave follow up with a blog entry

• Review progress on M2 P1 items (see below) with incomplete designs – 30 min (Song)

• N+1 testing for distro testing is on for next milestone. N+1 is the current production version plus the next Alpha version
• LayerTooling design review: AR: Richard to review these items 

• Image creator: Jessica sent the detailed task list. Jessica signed off the design for these items. The team feels comfortable with the schedule. AR: Song to update the wiki.
• Multi-lib: we will have separate meeting to address this.

• Bug assigning process for bugs assigned to BSP/Tom:

• Bugs assigned to BSP/Tom are not necessarily BSP related. Tom would like to be involved in the bug triage process.
• Don't want to put a barrier for people to file bugs by asking people to spend more time on where the bug should belong when they file bugs.
• QA team is very resource limited, probably not appropriate to ask them to spend more time analyzing bugs.
• Solution: AR: Darren will check new BSP related bugs more regularly and work with Tom to reassign them if needed.

• Opens:

• PPC bugs (414): short term we cannot do much. Mark talked to people in PPC community.   WRS team has some plan and directions to go. Work is still in progress. We need help on resources. Find someone to work on it in July-Sep. period maybe. AR: Dave to bring this up to the advisory board for help.
• Bruce is good with the current feature and schedule including p2/p3 items.

 

 

Updates marked in yellow 

Feature Name	Description	Priority	Commit	Status	Owner	Design Signoff	Due	Comments / Bugzilla Links
Error handling in bitbake (Design)	Performance improvement (gather input from community on use cases)	1	Yes	Accept	Saul (Scott G)	Richard	M2,Sprint B	M2, Sprint A, (Scott to talk with Richard about the design of this item and then come back with update) Filed bugs (enhancement) in bugzilla, working on priorities and figure out what need to be done in the next 2 weeks.
multi-lib complete	multi-lib support for 32-bit & 64-bit and capable of being installed at the same time fully complete	1	Yes	Accept	Richard (Qing/Ke)		M2, Sprint D	M2, Sprint D
Image Creator polish	polish and refine Image Creator - See https://wiki.yoctoproject.org/wiki/BitBake/GUI/PostOneOh for details	1		Accept	Josh		M2, Sprint D	M2, Sprint D, Jessica/Josh will work on these items
kernel bloat - development	target = boot a minimal image in < 8M - development complete	1		Accept	Darren		M2, Sprint D	M2, Sprint D
LayerTooling - Dependency handling	Dependency handling	1		M2, Sprint C	Paul		M2, Sprint C	M2 Sprint C, dependent on Sprint C item (LayerTooling), check next Tuesday
LayerTooling – layer merging tool	Tool to merge (flatten) several layers into one	1		M2, Sprint C	Paul		M2, Sprint C	M2, Sprint C, under review (Richard)
LayerTooling – remote layer tool	Consider integrating Jeremy Puhlman's remote layers patch	1		M2, Sprint C	Ke/Paul		M2, Sprint C	Jeremy is working on this, M2, Sprint C
Package config option enhancement - Plan	Plan our approach to package config option enhancement	2		M2, Design	Richard			M2, Design
multi-lib infrastructure	multi-lib support for 32-bit & 64-bit and capable of being installed at the same time - infrastructure in place (multilib toolchain changes, configuration changes)	1	Yes	M2, Sprint A	Richard(Qing/Ke)		M2, Sprint B	M2, Sprint A, Sprint B
multi-lib RPM	RPM support for multilib added	1		M2, Sprint B	Richard (Qing)		M2, Sprint B	M2, Sprint B, too large, dependent on other features, Mark owns the architecture, leave for discussion with PRC team
LayerTooling – output info enhancement	1) Show a parse error if a bbappend matches no existing bb. 2) Update banner info to show layers being used and revisions/branches for each one if available	1	Yes	M2, Sprint B	Dexuan		M2, Sprint B	M2, Sprint B, Richard will look at the design again for these(LayerTooling), need discussion with PRC team
Layer Tooling - Architecture	Implement Layer Tooling changes	1	Yes	Accept	Richard (Paul/Daoxien will help)	n/a	M2, Sprint A	M2 Sprint A, still dependent on Jeremy
Optimize support for Intel hardware features	We need to understand and track each important Intel hardware feature and how it should be optimally supported in the Intel BSPS. Items that immediately come to mind are power, video, and performance counter settings, etc.	1		on-going	Tom/Darren		M2, Sprint A	M2, Sprint A, Tom/Darren will work together on the design (possibly break up this item), target: ww24.1   We had a kernel meeting, we have a list of items (a handful of) and will enter them in bugzilla. Will plan these bugs at milestone level instead of at Sprint level   Remove this from feature list, track them in bugzilla
kernel bloat - analysis (Design)	target = boot a minimal image in < 8M - analysis complete	1	Yes	Accept	Darren		M2, Sprint B	M2, Sprint B, need to have specifics and design   Beagle board kernel fix is taking longer than expected, this one needs to be moved to Sprint B.
LayerTooling – combo layer tool	Tool to manage combination repos (e.g. the poky repo)	1	Yes	70%	Ke		M2, Sprint A	M2, Sprint A
Changes for Image Creator - phase 3	Phase 3: package format job done + image output type job done	1		Accept	Joshua			M2, Sprint B, needs to work Joshua and rearrange
Changes for Image Creator - phase 4	Phase 4: complete plug-in	1		Accept	Jessica			M2, Sprint D, need reschedule

 

 

On Tue, 2011-06-07 at 10:47 -0700, Daryl Spitzer wrote:

I followed the "Building an Image" instructions in the Yocto Project
Quick Start (on a newly configured machine running Ubuntu 11.04 (64
bit), and got an error. The contents of the failure logfile is:

NOTE: fetch http://anonymous@autobuilder.yoctoproject.org/sources/config_cvs.sv.gnu.org__20080123.tar.gz

What is odd/interesting here is that its trying the http address for the
cache of this. If I click the above link, I do get the file after a
warning about the anonymous user. I wonder if that username is upsetting
wget somehow and breaking our mirroring infrastructure?

"wget
http://anonymous@autobuilder.yoctoproject.org/sources/config_cvs.sv.gnu.org__20080123.tar.gz"

does seem to work here for me...

NOTE: Fetch cvs://anonymous@.../cvsroot/config;module=config;method=pserver;date=20080123
cvs [checkout aborted]: connect to cvs.sv.gnu.org(140.186.70.72):2401
failed: Connection timed out
ERROR: Function 'Fetcher failure for URL:
'cvs://anonymous@.../cvsroot/config;module=config;method=pserver;date=20080123'.
Unable to fetch URL
cvs://anonymous@.../cvsroot/config;module=config;method=pserver;date=20080123
from any source.' failed

I'm guessing this problem is because I haven't configured CVS to work
through my employer's HTTP proxy.

I did a search, and didn't find any definitive instructions for
configuring CVS. (In fact, I found
http://www.cygwin.com/ml/kawa/2003-q3/msg00069.html, which I'm hoping
is out-of-date since it talks about a patch, which—8 years ago at
least—wasn't included in GNU CVS. I did try defining the CVS_PROXY
environment variable as directed in that page just in case the CVS
build I'm using includes that patch—but I got the same build error.)

Can anyone point me to up-to-date instructions for configuring CVS to
work through a proxy?

Good questions. I know we have people with this working behind firewalls
but I'm not sure how they have it working...

Does the wget command above work for you?

Cheers,

Richard

On 06/06/2011 09:36 PM, Xu, Jiajun wrote:

Hi all,

This is the fullpass test report for Yocto 1.1 M1 RC2 build. There are 3
new bugs found in this testing compared with weekly testing. Non-GPLv3
build could not work and one new LTP failure found with new kernel. The
2 BLOCK issues on have been addressed and a new build is ready for QA
testing. Except for LTP and POSIX failures, there are 13 open bugs for
RC2 build. Grub installation fails on 3 intel BSPs. Graphics testing on
sugarbay is blocked because there are no mesa-demos and libSDL.so installed.

Jiajun, Yi Zhao,

What's the status of the Beagleboard testing, you show blocked below,
but I thought we unblocked last week, so is there any update on the
status of beagleboard testing? We need to know this since we have a
conditional GO decision based on these results.

I would like to also understand the sugarbay graphics testing, this is
not a blocker, it's a new requirement, correct? We have not had
mesa-demos included in any past release. I am going to add it to the
sato-sdk build only, will that be?

Sau!

Helltest and Crashme could pass 24 hours testing on Jasperforest. Idle
power consumption of sugarbay and crownbay are 40.12W and 18.72W
respectively. LTP and POSIX testing is finished but the result analysis
is still on-going.

*Test Summary*

*---------------------------------------*











*Test Result Summary*



*Component*



*Target*



*Status*



*Comments*



*BSP*



SugarBay



GOOD



Graphics testing is blocked; soft keyboard will be triggered with
terminal icon;



　



CrownBay



GOOD



Grub installation failed;



　



JasperForest



GOOD



Everything runs well



　



Blacksand



GOOD



Grub installation failed; S3 does not work;



　



eMenlow



GOOD



System installation failed; S3 does not work;



　



Beagleboard



BLOCK



Build failed; A new build is ready and QA is doing testing for it;



　



Routerstationpro



GOOD



Everything runs well



　



Mpc8315e-rdb



Buggy



USB does not work



*QEMU*



qemux86



GOOD



Everything runs well



　



qemux86-64



GOOD



Everything runs well



　



qemuarm



GOOD



Everything runs well



　



qemuppc



GOOD



unfs does not work with qemuppc



　



qemumips



GOOD



Everything runs well



*Core Build System*



　



Buggy



non-GPLv3 build failed



*Power/Performance*



　



GOOD



Power consumption of sugarbay and crownbay are 40.12W and 18.72W
respectively



*Compliance*



　



In analysis



LTP result: https://wiki.pokylinux.org/wiki/LTP_result
POSIX result: https://wiki.pokylinux.org/wiki/Posix_result



*Stress*



　



GOOD



Helltest and crashme could pass 24 hours testing



*ADT*



　



Buggy



unfs does not work with qemuppc





**

　



Critical bugs, more than 50% test cases are blocked



　



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



　



Normal, Major and Critical bugs, more than 10% test cases failed






*Detailed Test Result for each component*



*Target*



*Total TCs***



*Not Run*



*Passed***



*Failed***



*Not testable (Blocked)***



*Sugarbay Sato-SDK*



64



0



60



1 (bug 1101)



3 (bug 1112, 883)



*Crownbay Sato-SDK*



60



0



55



1 (bug 1099)



4



*Jasperforest LSB-SDK*



34



0



34



0



0



*n450 Sato-SDK*



60



0



52



2 (bug 613, 1099)



6 (bug 613)



*eMenlow Sato-SDK*



60



0



48



2 (bug 1099, 503)



6 (bug 503)



*Routerstationpro Sato-SDK*



29



0



29



0



0



*Mpc8315e-rdb Sato-SDK*



30



0



26



4 (bug 766)



0



*Qemux86-64 Sato*



28



0



28



0



0



*Qemux86-64 Sato-SDK*



31



0



31



0



0



*Qemux86 Sato*



28



0



28



0



0



*Qemux86 Sato-SDK*



31



0



31



0



0



*Qemumips Sato*



26



0



26



0



0



*Qemumips Sato-SDK*



32



0



32



0



0



*Qemuppc Sato*



20



0



19



0



1 (bug 414)



*Qemuppc Sato-SDK*



26



0



25



0



1 (bug 414)



*Qemuarm Sato*



26



0



26



0



0



*Qemuarm Sato-SDK*



32



0



32



0



0



*Core Build System*



8



0



7



1 (bug 1133)



0



*ADT*



6



0



5



1 (bug 414)



0



*Power/Performance*



4



0



4



0



0



*Stress*



2



0



2



0



0



*Total*



637



0



600



12



21





**






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

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

*Commit Information*

*---------------------------------------*

Tree/Branch: Poky/1.1_M1

Poky Commit: 4ff7af11ef69849ef9c16f585eae58ac920b222b

Meta Branch: 1.1_M1

Meta Commit: fc719f0cd6530ce15148b4aa274f1644b461b298

*Issue Summary*

*---------------------------------------*

*Component*



*Bug Number*



*Target Milestone*

*System & Core OS*



*Installation & Boot*



Bug 1006: [mpc8315e-rdb & routerstationpro] minimal,sato,sato-sdk images
boot failed (nightly build 20110423-1)



1.1

Bug 1099: [blacksand/emenlow/crownbay] grub install failed with sato-sdk
live image



1.1 M2

*Power Mangement*



Bug 613: [Blacksand]system cannot enter S3 standby mode



1.1

Bug 503: [emenlow] system cannot enter S3 standby mode



1.1

*Others*



Bug 766: [mpc8315e-rdb] USB does not work on mpc8315e-rdb



1.0 M4

Bug 1101: keyboard pop up when clicking terminal icon



1.0 M2

Bug 1107: Open or add person in contacts may segfault on sugarbay/blacksand



1.1 M2

Bug 1097: The mouse can not click accurate to the icons in qemumips X



1.1 M2

*Graphics*



Bug 1112: [sugarbay] mesa-demos should be added into sato image for
graphics testing



1.1 M2

Bug 883: [Sugarbay] GFX 3D game test fail to run with sugarbay BSP image
due to libsdl.so



1.1

*Multimedia*



Works well in sugarbay/n450/eMenlow/crownbay



　

*Core Build System*



New!Bug 1136: do_menuconfig for linux-yocto needs ${B} exists

New!Bug 1133: No provider for core-image-minimal/basic for non-GPLv3 build



1.1M2

1.1 M2

*Compliance*



Compliance testing is finished, but result is still under analysis. LTP
test result is on https://wiki.pokylinux.org/wiki/LTP_result

POSIX test result is on https://wiki.pokylinux.org/wiki/Posix_result

A new LTP failure is found and reported as bug 1138: [LTP] Some
growfiles cases failed with Yocto 1.1 M1 build.



　

*Stress*



Helltest and Crashme could pass 24 hours testing



　

*ADT*



Bug 414: [PPC] kernel panic when booting poky-image-sdk-qemuppc through UNFS



1.1 M3

Best Regards,

Jiajun



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

I found https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy
(after doing a search for "yocto cvs proxy"). My compliments on the
thoroughness of your documentation. (I shouldn't have assumed this
wasn't already documented). It looks like these instructions will
solve my problem.

--
Daryl

I need to bring the autobuilders down for some buildbot upgrades and cleanup, today June 7th @ 2pm Pacific. They should be down for no more than two hours. The downloads directory and mirror infrastructure will still be available during this time.

-b

I followed the "Building an Image" instructions in the Yocto Project
Quick Start (on a newly configured machine running Ubuntu 11.04 (64
bit), and got an error. The contents of the failure logfile is:

NOTE: fetch http://anonymous@autobuilder.yoctoproject.org/sources/config_cvs.sv.gnu.org__20080123.tar.gz
NOTE: Fetch cvs://anonymous@.../cvsroot/config;module=config;method=pserver;date=20080123
cvs [checkout aborted]: connect to cvs.sv.gnu.org(140.186.70.72):2401
failed: Connection timed out
ERROR: Function 'Fetcher failure for URL:
'cvs://anonymous@.../cvsroot/config;module=config;method=pserver;date=20080123'.
Unable to fetch URL
cvs://anonymous@.../cvsroot/config;module=config;method=pserver;date=20080123
from any source.' failed

I'm guessing this problem is because I haven't configured CVS to work
through my employer's HTTP proxy.

I did a search, and didn't find any definitive instructions for
configuring CVS. (In fact, I found
http://www.cygwin.com/ml/kawa/2003-q3/msg00069.html, which I'm hoping
is out-of-date since it talks about a patch, which—8 years ago at
least—wasn't included in GNU CVS. I did try defining the CVS_PROXY
environment variable as directed in that page just in case the CVS
build I'm using includes that patch—but I got the same build error.)

Can anyone point me to up-to-date instructions for configuring CVS to
work through a proxy?

And what command-line can I use to test it?

--
Daryl

Hi Daryl - thanks again for the note. The video is up and running once again.

--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org

From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Jeremy Puhlman
Sent: Monday, June 06, 2011 3:28 PM

As discussed with others when I first dropped the remote-layering patch
that I was working internally with our management to open our content
tools, since they would likely be useful as a starting point for yocto
layering tooling. Due to some personal tragedies I have been a bit
side-lined, but here they are.

Jeremy - thanks very much to you and to MontaVista for contributing this code to the Yocto Project!

And also I am very sorry about your personal tragedies.

The repository for the tools are here:

git://gitorious.org/content-tools/content-tools.git

The wiki giving a quick run down of everything is here:
https://gitorious.org/content-tools/pages/Home

The long and the short of it is the tools provide and xml description
layer for collections/layers, and a method of describing what we call in
our product solutions. A solution is basically a group of
collections/layers, configuration options and a like that you would use
to produce any number of images or what not from a machine
configuration. You can add multiple solutions together, and they will
add the collections as needed.

The back end mirroring and content providing components work really
well, though all the references to collections could be swapped over to
layers, but it is more or less at that level the name difference is
largely meaningless. The project creation tool will need some additional
work. I have added some changes to the tool to make it work with layers
and sstate a bit better, but I don't think it is completely there, but
it is more or less a reasonable start. The main thing is the setup.sh
would need to be taught about the extra stuff in oe-init-build-env and a
method for dealing with pseudo, which it doesn't at this point.

The work their does kind of hinge on the remote layering code I provided
before, being in your bitbake to run all the way to the end. Though,
integrating what ever fetchers in to the tools is also reasonable, its
just not where we were doing it.

If you like I can try to post up a example content repository up on our
ftp server to kick around if you like. The wiki page has a run through
from beginning to end of the tools and how set an example up.

--
Jeremy Puhlman
Montavista Sofware, LLC.

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

As discussed with others when I first dropped the remote-layering patch
that I was working internally with our management to open our content
tools, since they would likely be useful as a starting point for yocto
layering tooling. Due to some personal tragedies I have been a bit
side-lined, but here they are.

The repository for the tools are here:

git://gitorious.org/content-tools/content-tools.git

The wiki giving a quick run down of everything is here:
https://gitorious.org/content-tools/pages/Home

The long and the short of it is the tools provide and xml description
layer for collections/layers, and a method of describing what we call in
our product solutions. A solution is basically a group of
collections/layers, configuration options and a like that you would use
to produce any number of images or what not from a machine
configuration. You can add multiple solutions together, and they will
add the collections as needed.

The back end mirroring and content providing components work really
well, though all the references to collections could be swapped over to
layers, but it is more or less at that level the name difference is
largely meaningless. The project creation tool will need some additional
work. I have added some changes to the tool to make it work with layers
and sstate a bit better, but I don't think it is completely there, but
it is more or less a reasonable start. The main thing is the setup.sh
would need to be taught about the extra stuff in oe-init-build-env and a
method for dealing with pseudo, which it doesn't at this point.

The work their does kind of hinge on the remote layering code I provided
before, being in your bitbake to run all the way to the end. Though,
integrating what ever fetchers in to the tools is also reasonable, its
just not where we were doing it.

If you like I can try to post up a example content repository up on our
ftp server to kick around if you like. The wiki page has a run through
from beginning to end of the tools and how set an example up.

--
Jeremy Puhlman
Montavista Sofware, LLC.

How odd! Thanks for letting us know - we'll get it back up asap.

I didn't see a discussion of this in the mailing list archives...

When I tried to play the video on http://www.yoctoproject.org/ I saw
"This video is no longer available because the uploader has closed
their YouTube account."

--
Daryl

Hi all,
The open bug number of last week decreased to 199. QA is performing fullpass testing against Yocto 1.1 M1 RC2 build. The 2 block issues for beagleboard are fixed. Bug status of WW23 could be found on https://wiki.pokylinux.org/wiki/Yocto_Bug_Trend.

Best Regards,
Jiajun

Tuesday, June 07, 2011, 08:00 AM US Pacific Time
916-356-2663, 8-356-2663, Bridge: 94, Passcode: 9320476
Speed dial for iPhone: inteldialer://94,9320476 | Learn more

 

Agenda:

• Review Yocto 1.1 M1 Release Criteria – 10 min (Julie)

• See details at:  https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.1_Release_Criteria

• Discuss M1 1.1 M1 Release Status, go/no-go vote – 10 min (Julie)
• Review progress on M2 P1 items (see below) with incomplete designs – 30 min (Song)
• Opens – 10 min

 

Feature Name	Description	Priority	Commit	Status	Owner	Design Signoff	Due	Comments / Bugzilla Links
Error handling in bitbake (Design)	Performance improvement (gather input from community on use cases)	1	Yes	Accept	Saul (Scott G)		M2,Sprint A	M2, Sprint A, (Scott to talk with Richard about the design of this item and then come back with update)
multi-lib complete	multi-lib support for 32-bit & 64-bit and capable of being installed at the same time fully complete	1	Yes	Accept	Richard (Qing/Ke)		M2, Sprint D	M2, Sprint D
Image Creator polish	polish and refine Image Creator - See https://wiki.yoctoproject.org/wiki/BitBake/GUI/PostOneOh for details	1		Accept	Josh		M2, Sprint D	M2, Sprint D, Jessica/Josh will work on these items
kernel bloat - development	target = boot a minimal image in < 8M - development complete	1		Accept	Darren		M2, Sprint D	M2, Sprint D
LayerTooling - Dependency handling	Dependency handling	1		M2, Sprint C	Paul		M2, Sprint C	M2 Sprint C, dependent on Sprint C item (LayerTooling), check next Tuesday
LayerTooling – layer merging tool	Tool to merge (flatten) several layers into one	1		M2, Sprint C	Paul		M2, Sprint C	M2, Sprint C, under review (Richard)
LayerTooling – remote layer tool	Consider integrating Jeremy Puhlman's remote layers patch	1		M2, Sprint C	Ke/Paul		M2, Sprint C	Jeremy is working on this, M2, Sprint C
Package config option enhancement - Plan	Plan our approach to package config option enhancement	2		M2, Design	Richard			M2, Design
multi-lib infrastructure	multi-lib support for 32-bit & 64-bit and capable of being installed at the same time - infrastructure in place (multilib toolchain changes, configuration changes)	1	Yes	M2, Sprint A	Richard(Qing/Ke)		M2, Sprint B	M2, Sprint A, Sprint B
multi-lib RPM	RPM support for multilib added	1		M2, Sprint B	Richard (Qing)		M2, Sprint B	M2, Sprint B, too large, dependent on other features, Mark owns the architecture, leave for discussion with PRC team
LayerTooling – output info enhancement	1) Show a parse error if a bbappend matches no existing bb. 2) Update banner info to show layers being used and revisions/branches for each one if available	1	Yes	M2, Sprint B	Dexuan		M2, Sprint B	M2, Sprint B, Richard will look at the design again for these(LayerTooling), need discussion with PRC team
Layer Tooling - Architecture	Implement Layer Tooling changes	1	Yes	Accept	Richard (Paul/Daoxien will help)	n/a	M2, Sprint A	M2 Sprint A, still dependent on Jeremy
Optimize support for Intel hardware features	We need to understand and track each important Intel hardware feature and how it should be optimally supported in the Intel BSPS. Items that immediately come to mind are power, video, and performance counter settings, etc.	1		on-going	Tom/Darren		M2, Sprint A	M2, Sprint A, Tom/Darren will work together on the design (possibly break up this item), target: ww24.1
kernel bloat - analysis (Design)	target = boot a minimal image in < 8M - analysis complete	1	Yes	Accept	Darren		M2, Sprint A	M2, Sprint A, need to have specifics and design
LayerTooling – combo layer tool	Tool to manage combination repos (e.g. the poky repo)	1	Yes	70%	Ke		M2, Sprint A	M2, Sprint A
Changes for Image Creator - phase 3	Phase 3:  package format job done + image output type job done	1		Accept	Joshua			M2, Sprint B, needs to work Joshua and rearrange
Changes for Image Creator - phase 4	Phase 4: complete plug-in	1		Accept	Jessica			M2, Sprint D, need reschedule