Date   

Re: undefined reference to `pthread_getspecific' in perl-native_5.12.2.bb task do_compile?

Daryl Spitzer <daryl.spitzer@...>
 

Thanks Joshua. I assume that
http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html
won't be updated until the next release (if this makes it into the
next release)? And the patch should then be updated to match the new
version numbers?

--
Daryl

On Thu, Jun 9, 2011 at 3:52 PM, Joshua Lock <josh@...> wrote:
On Thu, 2011-06-09 at 11:17 -0700, Daryl Spitzer wrote:
Looks like we fixed this issue in our recent point release. Could you
try http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.1.tar.bz2 ?
I tried it, and am getting what I think is an unrelated error.  I'll
start a new thread for that.

Shouldn't documentation references to
"http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.tar.bz2"
be changed to "http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.1.tar.bz"
(such as in http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html)?
You are right Daryl, apologies for any inconvenience. I've filed a bug
with a patch attached for the Quick Start doc.

http://bugzilla.yoctoproject.org/show_bug.cgi?id=1153

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


Re: Yocto Technical Team

Liu, Song <song.liu@...>
 

Please let me know if you would like to add anything else to the Agenda. - Song

Agenda:

- Final check on Yocto 1.1 M1 release - 5 min (Song)
- Review Yocto 1.1 M2 schedule and Release Criteria - 20 min (Song)
See details at: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.1_Release_Criteria
- Design check (Sprint B, C features) - 20 min (Song)
- Opens - 10 min



Tuesday, June 14, 2011, 08:00 AM US Pacific Time
916-356-2663, 8-356-2663, Bridge: 94, Passcode: 5995524
Speed dialer: inteldialer://94,5995524 | Learn more


Results of the latest documentation audit, June 2011

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

Hello,

As a data point for where we stand in ensuring our packages are producing documentation, I have some scripts which build all recipes (using the output of bitbake -s, not world), and then check that a -doc package is generated which is populated with files.

A summary of the results using yesterday's master are as follows:

584 recipes in total
307 recipes are building documentation
277 recipes are not building documentation

20 recipes did not build, and are counted above as "not building documentation"

It's the impression of Saul and I that some of the recipes which do not build are failing due to dependency issues. In this case, it's generally not from a missing dependency, but having another recipe built first which then gets picked up (e.g, during do_configure) and causes a build failure.

For comparison, here were the results from last month (May 6th):

591 recipes in total
308 recipes are building documentation
283 recipes are not building documentation

31 recipes did not build

The lists of recipes are attached to this email. We'd like to improve the percentage of recipes that produce documentation (separated into -doc packages, of course) for our next major release in October.

Our userspace recipe maintainers should look into setting aside some time to know which of their recipes are in the "not building documentation" list and work to improve them. A lot of this is likely to be low-hanging fruit.

Thanks,

Scott

--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center


[PATCH 1/1] meta-intel: fix formfactor bbappends to use FILESEXTRAPATHS_prepend

Paul Eggleton
 

This allows meta-intel sub-layers to coexist with meta-yocto when building
formfactor for different machines with the same layer setup.

Signed-off-by: Paul Eggleton <paul.eggleton@...>
---
.../recipes-bsp/formfactor/formfactor_0.0.bbappend | 2 +-
.../recipes-bsp/formfactor/formfactor_0.0.bbappend | 2 +-
.../recipes-bsp/formfactor/formfactor_0.0.bbappend | 2 +-
.../recipes-bsp/formfactor/formfactor_0.0.bbappend | 2 +-
.../recipes-bsp/formfactor/formfactor_0.0.bbappend | 2 +-
.../recipes-bsp/formfactor/formfactor_0.0.bbappend | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/meta-crownbay/recipes-bsp/formfactor/formfactor_0.0.bbappend b/meta-crownbay/recipes-bsp/formfactor/formfactor_0.0.bbappend
index 4a41d48..54da0ff 100644
--- a/meta-crownbay/recipes-bsp/formfactor/formfactor_0.0.bbappend
+++ b/meta-crownbay/recipes-bsp/formfactor/formfactor_0.0.bbappend
@@ -1,3 +1,3 @@
-FILESEXTRAPATHS := "${THISDIR}/${PN}"
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

PRINC = "1"
diff --git a/meta-emenlow/recipes-bsp/formfactor/formfactor_0.0.bbappend b/meta-emenlow/recipes-bsp/formfactor/formfactor_0.0.bbappend
index 4a41d48..54da0ff 100644
--- a/meta-emenlow/recipes-bsp/formfactor/formfactor_0.0.bbappend
+++ b/meta-emenlow/recipes-bsp/formfactor/formfactor_0.0.bbappend
@@ -1,3 +1,3 @@
-FILESEXTRAPATHS := "${THISDIR}/${PN}"
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

PRINC = "1"
diff --git a/meta-fishriver/recipes-bsp/formfactor/formfactor_0.0.bbappend b/meta-fishriver/recipes-bsp/formfactor/formfactor_0.0.bbappend
index 4a41d48..54da0ff 100644
--- a/meta-fishriver/recipes-bsp/formfactor/formfactor_0.0.bbappend
+++ b/meta-fishriver/recipes-bsp/formfactor/formfactor_0.0.bbappend
@@ -1,3 +1,3 @@
-FILESEXTRAPATHS := "${THISDIR}/${PN}"
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

PRINC = "1"
diff --git a/meta-jasperforest/recipes-bsp/formfactor/formfactor_0.0.bbappend b/meta-jasperforest/recipes-bsp/formfactor/formfactor_0.0.bbappend
index 4a41d48..54da0ff 100644
--- a/meta-jasperforest/recipes-bsp/formfactor/formfactor_0.0.bbappend
+++ b/meta-jasperforest/recipes-bsp/formfactor/formfactor_0.0.bbappend
@@ -1,3 +1,3 @@
-FILESEXTRAPATHS := "${THISDIR}/${PN}"
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

PRINC = "1"
diff --git a/meta-n450/recipes-bsp/formfactor/formfactor_0.0.bbappend b/meta-n450/recipes-bsp/formfactor/formfactor_0.0.bbappend
index 4a41d48..54da0ff 100644
--- a/meta-n450/recipes-bsp/formfactor/formfactor_0.0.bbappend
+++ b/meta-n450/recipes-bsp/formfactor/formfactor_0.0.bbappend
@@ -1,3 +1,3 @@
-FILESEXTRAPATHS := "${THISDIR}/${PN}"
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

PRINC = "1"
diff --git a/meta-sugarbay/recipes-bsp/formfactor/formfactor_0.0.bbappend b/meta-sugarbay/recipes-bsp/formfactor/formfactor_0.0.bbappend
index 4a41d48..54da0ff 100644
--- a/meta-sugarbay/recipes-bsp/formfactor/formfactor_0.0.bbappend
+++ b/meta-sugarbay/recipes-bsp/formfactor/formfactor_0.0.bbappend
@@ -1,3 +1,3 @@
-FILESEXTRAPATHS := "${THISDIR}/${PN}"
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

PRINC = "1"
--
1.7.4.1


[PATCH 0/1] meta-intel: fix formfactor bbappends to use FILESEXTRAPATHS_prepend

Paul Eggleton
 

The following changes since commit 01d1a545477cbc1b2a1da5b66edb52fd9e783206:

meta-intel: update kernel SRCREVs (2011-06-06 16:13:01 -0500)

are available in the git repository at:
git://git.yoctoproject.org/poky-contrib paule/meta-intel-paths
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=paule/meta-intel-paths

Paul Eggleton (1):
meta-intel: fix formfactor bbappends to use FILESEXTRAPATHS_prepend

.../recipes-bsp/formfactor/formfactor_0.0.bbappend | 2 +-
.../recipes-bsp/formfactor/formfactor_0.0.bbappend | 2 +-
.../recipes-bsp/formfactor/formfactor_0.0.bbappend | 2 +-
.../recipes-bsp/formfactor/formfactor_0.0.bbappend | 2 +-
.../recipes-bsp/formfactor/formfactor_0.0.bbappend | 2 +-
.../recipes-bsp/formfactor/formfactor_0.0.bbappend | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)

--
1.7.4.1


Re: Update on build time performance - not good

Richard Purdie
 

Just for interest, for the first time ever I did a dump out of profile
information on the python side of bitbake's task execution for all tasks
of a core-image-sato build.

I enabled profiling of each forked off task with this patch:

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/temp5&id=c221b4174627ac24f4c9cae687b4f015a5b6523a

and then combined the results together in the attached profile report.
Most of it isn't a big surprise but there are some interesting numbers
such as the 278 million calls to _keys() in data_smart. For that
specific issue I have a patch which I'm considering:

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/temp5&id=f549077bbd529dfa5ff6ef75ef9432a823b3a3f5

as experience shows that function calls have overhead in python at that
number of iterations and reworking the code likely will reduce overhead.
I've yet to profile the result on this scale though.

Overall, a build makes over 10 billion python function calls. We access
data store variable flags 150 million times.

Not shown here but interestingly, early in the build process, the number
of calls to time.sleep() was low, at the end of this build its rather
significantly higher showing bitbake was hitting its idle handler a lot
more. Time spend there is an illusion as the system should have yielded
to other processes.

There are probably some other interesting things to be noticed somewhere
in that data :)

Cheers,

Richard


Re: Update on build time performance - not good

Koen Kooi
 

Op 10 jun 2011, om 10:44 heeft Richard Purdie het volgende geschreven:

We've merged a number of things which should have helped performance
recently. Changes in my test included:

* Splitting out the locale generation [not merged yet]
* Not building tar-replacement-native when we don't need it
* Cleaned up dependencies for native/nativesdk
* Cleaned up dependencies for all-arch packages
* Reduced dbus-native dependencies

The time for the benchmark timing test against master with the locale
split patch applied was:

real 105m5.813s
user 386m39.170s
sys 59m40.250s

so not that much different from where we have been :(.

I did observe things through the build process:

* The first part of the build was *fast* getting through the first 2000
of 4295 tasks in about 10 minutes.
* The CPU usage was pretty much full for that time
* The next 5 minutes covered the next 150 tasks
* gettext-native didn't seem to get built until surprisingly late in
the process
* There was a highly serialised chain of gettext-native, libelf-native,
binutils-native, binutils-cross etc.
* Once eglibc/libgcc completed, processor usage was high again for the
rest of the build

I'm hoping my BB_NUMBER_THREADS (12 on a quad core machine) was too high
causing too much context switching and as the build process might now be
more efficient, lowering it might help. I am a bit disappointed in those
numbers though.
Do you have pretty bootchart graphs for that?

regards,

Koen


Update on build time performance - not good

Richard Purdie
 

We've merged a number of things which should have helped performance
recently. Changes in my test included:

* Splitting out the locale generation [not merged yet]
* Not building tar-replacement-native when we don't need it
* Cleaned up dependencies for native/nativesdk
* Cleaned up dependencies for all-arch packages
* Reduced dbus-native dependencies

The time for the benchmark timing test against master with the locale
split patch applied was:

real 105m5.813s
user 386m39.170s
sys 59m40.250s

so not that much different from where we have been :(.

I did observe things through the build process:

* The first part of the build was *fast* getting through the first 2000
of 4295 tasks in about 10 minutes.
* The CPU usage was pretty much full for that time
* The next 5 minutes covered the next 150 tasks
* gettext-native didn't seem to get built until surprisingly late in
the process
* There was a highly serialised chain of gettext-native, libelf-native,
binutils-native, binutils-cross etc.
* Once eglibc/libgcc completed, processor usage was high again for the
rest of the build

I'm hoping my BB_NUMBER_THREADS (12 on a quad core machine) was too high
causing too much context switching and as the build process might now be
more efficient, lowering it might help. I am a bit disappointed in those
numbers though.

Cheers,

Richard


Re: undefined reference to `pthread_getspecific' in perl-native_5.12.2.bb task do_compile?

Joshua Lock <josh@...>
 

On Thu, 2011-06-09 at 11:17 -0700, Daryl Spitzer wrote:
Looks like we fixed this issue in our recent point release. Could you
try http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.1.tar.bz2 ?
I tried it, and am getting what I think is an unrelated error. I'll
start a new thread for that.

Shouldn't documentation references to
"http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.tar.bz2"
be changed to "http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.1.tar.bz"
(such as in http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html)?
You are right Daryl, apologies for any inconvenience. I've filed a bug
with a patch attached for the Quick Start doc.

http://bugzilla.yoctoproject.org/show_bug.cgi?id=1153

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


Re: Troubleshooting ERROR: Function 'Fetcher failure for URL: 'cvs://anoncvs:anoncvs@anoncvs.handhelds.org/cvs; module=apps/update-rc.d; tag=r0_7'?

Richard Purdie
 

On Thu, 2011-06-09 at 15:17 -0700, Daryl Spitzer wrote:
How do I find out where DL_DIR is pointing?

I found this line, commented out in conf/local.conf:

#DL_DIR ?= "${TOPDIR}/downloads"

It's not listed after I run `bitbake -k poky-image-sato`:

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.1"
TARGET_FPU = ""

And there is no DL_DIR environment variable defined (after I run
`source poky-bernard-5.0.1/poky-init-build-env poky-5.0.1-build`).

There is a poky-5.0.1-build/downloads directory. I'll assume that's
it. But I'd like to learn how to find out without guessing.
You can dump the bitbake datastore and find it like this:

bitbake -e | grep ^DL_DIR

Also, I think I have a patch for your problem:

diff --git a/bitbake/lib/bb/fetch2/__init__.py b/bitbake/lib/bb/fetch2/__init__.py
index 27fcc3c..02a36b5 100644
--- a/bitbake/lib/bb/fetch2/__init__.py
+++ b/bitbake/lib/bb/fetch2/__init__.py
@@ -203,7 +203,10 @@ def uri_replace(ud, uri_find, uri_replace, d):
result_decoded[loc] = uri_decoded[loc]
if isinstance(i, basestring):
if (re.match(i, uri_decoded[loc])):
- result_decoded[loc] = re.sub(i, uri_replace_decoded[loc], uri_decoded[loc])
+ if not uri_replace_decoded[loc]:
+ result_decoded[loc] = ""
+ else:
+ result_decoded[loc] = re.sub(i, uri_replace_decoded[loc], uri_decoded[loc])
if uri_find_decoded.index(i) == 2:
if ud.mirrortarball:
result_decoded[loc] = os.path.join(os.path.dirname(result_decoded[loc]), os.path.basename(ud.mirrortarball))

although I'm running some further tests on this to confirm it...

Cheers,

Richard


Re: Troubleshooting ERROR: Function 'Fetcher failure for URL: 'cvs://anoncvs:anoncvs@anoncvs.handhelds.org/cvs; module=apps/update-rc.d; tag=r0_7'?

Daryl Spitzer <daryl.spitzer@...>
 

Thanks Richard.

How do I find out where DL_DIR is pointing?

I found this line, commented out in conf/local.conf:

#DL_DIR ?= "${TOPDIR}/downloads"

It's not listed after I run `bitbake -k poky-image-sato`:

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.1"
TARGET_FPU = ""

And there is no DL_DIR environment variable defined (after I run
`source poky-bernard-5.0.1/poky-init-build-env poky-5.0.1-build`).

There is a poky-5.0.1-build/downloads directory. I'll assume that's
it. But I'd like to learn how to find out without guessing.

--
Daryl

P.S. It looks like that was a safe assumption. The build has moved
past that point of failure.


On Thu, Jun 9, 2011 at 2:54 PM, Richard Purdie
<richard.purdie@...> wrote:
On Thu, 2011-06-09 at 11:32 -0700, Daryl Spitzer wrote:
I'm continuing to try to successfully build an image for the first
time, following the instructions in the Yocto Project Quick Start
(http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html).

As suggested in
https://lists.yoctoproject.org/pipermail/yocto/2011-June/001598.html,
I'm now trying http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.1.tar.bz2.
 And I'm following the instructions in
https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy,
including defining CVS_PROXY_HOST & CVS_PROXY_PORT in my local.conf
file.

But I'm getting the following error:

NOTE: fetch http://anoncvs@autobuilder.yoctoproject.org/sources/apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz
NOTE: Fetch cvs://anoncvs:anoncvs@.../cvs;module=apps/update-rc.d;tag=r0_7
cvs [checkout aborted]: end of file from server (consult above messages if any)
ERROR: Function 'Fetcher failure for URL:
'cvs://anoncvs:anoncvs@.../cvs;module=apps/update-rc.d;tag=r0_7'.
Unable to fetch URL
cvs://anoncvs:anoncvs@.../cvs;module=apps/update-rc.d;tag=r0_7
from any source.' failed

(This is the contents of the logfile created in
poky-5.0.1-build/tmp/work/all-poky-linux/update-rc.d-0.7-r3/temp/log.do_fetch.16236.)

It's not clear to me if this is a proxy problem.

If I try `wget http://anoncvs@autobuilder.yoctoproject.org/sources/apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz`,
I see the following:

$ wget http://anoncvs@autobuilder.yoctoproject.org/sources/apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz
--2011-06-09 11:25:37--
http://anoncvs@autobuilder.yoctoproject.org/sources/apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz
Resolving gateway... 149.199.33.100, 172.22.140.250
Connecting to gateway|149.199.33.100|:8080... connected.
Proxy request sent, awaiting response... 400 Bad Request
2011-06-09 11:25:37 ERROR 400: Bad Request.

But `wget http://autobuilder.yoctoproject.org/sources/apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz`
(same as above, but s/anoncvs@//) succeeds:

 wget http://autobuilder.yoctoproject.org/sources/apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz
--2011-06-09 11:29:39--
http://autobuilder.yoctoproject.org/sources/apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz
Resolving gateway... 149.199.33.100, 172.22.140.250
Connecting to gateway|149.199.33.100|:8080... connected.
Proxy request sent, awaiting response... 200 OK
Length: 2475 (2.4K) [application/x-gzip]
Saving to: `apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz'

100%[======================================>] 2,475       --.-K/s   in 0s

2011-06-09 11:29:39 (336 MB/s) -
`apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz' saved
[2475/2475]


How do I troubleshoot or move past this?
To move past it, place the file you've downloaded into wherever DL_DIR
is pointing and also touch
apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz.done to signify the
download is complete. It should them move you past that point.

As for the root cause, we should be discarding the username information
when trying mirrors. I'll have a look and see if I can work out a patch
for the fetcher to do that...

Cheers,

Richard


Re: Troubleshooting ERROR: Function 'Fetcher failure for URL: 'cvs://anoncvs:anoncvs@anoncvs.handhelds.org/cvs; module=apps/update-rc.d; tag=r0_7'?

Richard Purdie
 

On Thu, 2011-06-09 at 11:32 -0700, Daryl Spitzer wrote:
I'm continuing to try to successfully build an image for the first
time, following the instructions in the Yocto Project Quick Start
(http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html).

As suggested in
https://lists.yoctoproject.org/pipermail/yocto/2011-June/001598.html,
I'm now trying http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.1.tar.bz2.
And I'm following the instructions in
https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy,
including defining CVS_PROXY_HOST & CVS_PROXY_PORT in my local.conf
file.

But I'm getting the following error:

NOTE: fetch http://anoncvs@autobuilder.yoctoproject.org/sources/apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz
NOTE: Fetch cvs://anoncvs:anoncvs@.../cvs;module=apps/update-rc.d;tag=r0_7
cvs [checkout aborted]: end of file from server (consult above messages if any)
ERROR: Function 'Fetcher failure for URL:
'cvs://anoncvs:anoncvs@.../cvs;module=apps/update-rc.d;tag=r0_7'.
Unable to fetch URL
cvs://anoncvs:anoncvs@.../cvs;module=apps/update-rc.d;tag=r0_7
from any source.' failed

(This is the contents of the logfile created in
poky-5.0.1-build/tmp/work/all-poky-linux/update-rc.d-0.7-r3/temp/log.do_fetch.16236.)

It's not clear to me if this is a proxy problem.

If I try `wget http://anoncvs@autobuilder.yoctoproject.org/sources/apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz`,
I see the following:

$ wget http://anoncvs@autobuilder.yoctoproject.org/sources/apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz
--2011-06-09 11:25:37--
http://anoncvs@autobuilder.yoctoproject.org/sources/apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz
Resolving gateway... 149.199.33.100, 172.22.140.250
Connecting to gateway|149.199.33.100|:8080... connected.
Proxy request sent, awaiting response... 400 Bad Request
2011-06-09 11:25:37 ERROR 400: Bad Request.

But `wget http://autobuilder.yoctoproject.org/sources/apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz`
(same as above, but s/anoncvs@//) succeeds:

wget http://autobuilder.yoctoproject.org/sources/apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz
--2011-06-09 11:29:39--
http://autobuilder.yoctoproject.org/sources/apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz
Resolving gateway... 149.199.33.100, 172.22.140.250
Connecting to gateway|149.199.33.100|:8080... connected.
Proxy request sent, awaiting response... 200 OK
Length: 2475 (2.4K) [application/x-gzip]
Saving to: `apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz'

100%[======================================>] 2,475 --.-K/s in 0s

2011-06-09 11:29:39 (336 MB/s) -
`apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz' saved
[2475/2475]


How do I troubleshoot or move past this?
To move past it, place the file you've downloaded into wherever DL_DIR
is pointing and also touch
apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz.done to signify the
download is complete. It should them move you past that point.

As for the root cause, we should be discarding the username information
when trying mirrors. I'll have a look and see if I can work out a patch
for the fetcher to do that...

Cheers,

Richard


Troubleshooting ERROR: Function 'Fetcher failure for URL: 'cvs://anoncvs:anoncvs@anoncvs.handhelds.org/cvs; module=apps/update-rc.d; tag=r0_7'?

Daryl Spitzer <daryl.spitzer@...>
 

I'm continuing to try to successfully build an image for the first
time, following the instructions in the Yocto Project Quick Start
(http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html).

As suggested in
https://lists.yoctoproject.org/pipermail/yocto/2011-June/001598.html,
I'm now trying http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.1.tar.bz2.
And I'm following the instructions in
https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy,
including defining CVS_PROXY_HOST & CVS_PROXY_PORT in my local.conf
file.

But I'm getting the following error:

NOTE: fetch http://anoncvs@autobuilder.yoctoproject.org/sources/apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz
NOTE: Fetch cvs://anoncvs:anoncvs@.../cvs;module=apps/update-rc.d;tag=r0_7
cvs [checkout aborted]: end of file from server (consult above messages if any)
ERROR: Function 'Fetcher failure for URL:
'cvs://anoncvs:anoncvs@.../cvs;module=apps/update-rc.d;tag=r0_7'.
Unable to fetch URL
cvs://anoncvs:anoncvs@.../cvs;module=apps/update-rc.d;tag=r0_7
from any source.' failed

(This is the contents of the logfile created in
poky-5.0.1-build/tmp/work/all-poky-linux/update-rc.d-0.7-r3/temp/log.do_fetch.16236.)

It's not clear to me if this is a proxy problem.

If I try `wget http://anoncvs@autobuilder.yoctoproject.org/sources/apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz`,
I see the following:

$ wget http://anoncvs@autobuilder.yoctoproject.org/sources/apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz
--2011-06-09 11:25:37--
http://anoncvs@autobuilder.yoctoproject.org/sources/apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz
Resolving gateway... 149.199.33.100, 172.22.140.250
Connecting to gateway|149.199.33.100|:8080... connected.
Proxy request sent, awaiting response... 400 Bad Request
2011-06-09 11:25:37 ERROR 400: Bad Request.

But `wget http://autobuilder.yoctoproject.org/sources/apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz`
(same as above, but s/anoncvs@//) succeeds:

wget http://autobuilder.yoctoproject.org/sources/apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz
--2011-06-09 11:29:39--
http://autobuilder.yoctoproject.org/sources/apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz
Resolving gateway... 149.199.33.100, 172.22.140.250
Connecting to gateway|149.199.33.100|:8080... connected.
Proxy request sent, awaiting response... 200 OK
Length: 2475 (2.4K) [application/x-gzip]
Saving to: `apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz'

100%[======================================>] 2,475 --.-K/s in 0s

2011-06-09 11:29:39 (336 MB/s) -
`apps.update-rc.d_anoncvs.handhelds.org_r0_7_.tar.gz' saved
[2475/2475]


How do I troubleshoot or move past this?

--
Daryl


Re: undefined reference to `pthread_getspecific' in perl-native_5.12.2.bb task do_compile?

Daryl Spitzer <daryl.spitzer@...>
 

Looks like we fixed this issue in our recent point release. Could you
try http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.1.tar.bz2 ?
I tried it, and am getting what I think is an unrelated error. I'll
start a new thread for that.

Shouldn't documentation references to
"http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.tar.bz2"
be changed to "http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.1.tar.bz"
(such as in http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html)?

Thanks Joshua and Gary.

--
Daryl


On Wed, Jun 8, 2011 at 4:57 PM, Joshua Lock <josh@...> wrote:
On Wed, 2011-06-08 at 06:48 -0700, Daryl Spitzer wrote:
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?
Hi Daryl,

Looks like we fixed this issue in our recent point release. Could you
try
http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.1.tar.bz2 ?

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


Unscheduled tasks

Richard Purdie
 

Hi,

I've talked to variois people about adding things to the unscheduled
feature list. This was buried at the bottom of the current schedule but
it now has its own page:

https://wiki.pokylinux.org/wiki/Yocto_Project_Unscheduled_Feature_List

I'd really like to get the stuff on there cleaned up. It may be these
end up as feature enhancement requests in the bugzilla and this page
becomes autogenerated from those. For now I'd like to:

a) Clean up the descriptions on this page where we can

b) Ensure we keep adding ideas to this list or bugzilla but that we do
record things somewhere.

Cheers,

Richard


Re: Fullpass Test Report for Beagleboard 1.1 M1 20110602 Build

Richard Purdie
 

On Wed, 2011-06-08 at 15:09 -0700, Stewart, David C wrote:
I think it's reasonable as a M* milestone
Agreed. The whole point of the milestones is to check for regressions
introduced by major changes like the toolchain upgrade. We now know what
the regressions are and can work to address them. The process is working
as it should :).

Cheers,

Richard


Beagleboard BSP Status

Darren Hart <dvhart@...>
 

As several people have been asking after improved Beagleboard support
with the Yocto Project, and it has been taking longer than I hoped to
refresh the BSP, I thought I'd fill you in on what the plans are and
where we are with those.

We met with the TI folks at ELC to try and sort out how to best support
the Beagleboard in the Yocto Project while still preserving the
excellent community surrounding the Beagleboard and the top-notch
support of the Beagleboard from the meta-texasinstruments layer.

The plan is to merge the contents of the linux-omap_2.6.37.bb recipe
into the linux-yocto_2.6.37.bb recipe. This involves merging linux-omap
into linux-yocto as well as merging the 200 or so patches from the
linux-omap recipe patch series. This work is complete. Thanks to Bruce
Ashfield for merging the linux-omap git tree. Of the 200 patches, I was
able to drop several that reverse applied to the linux-yocto tree, or
that weren't particularly relevant to the Beagleboard.

Beyond the kernel patches, there is the question of the defconfig.
Kernel configs are tricky as they include platform config, optional
driver configs, and various bits of policy. The goal has been to include
all of the platform config and the relevant driver configs, while
ensuring the policy configs are consistent with the yocto/standard
branch. This includes things like filesystem support, networking
protocol options, etc. This work is about half complete.

At this point I ran into the same problem reported by Gary Thomas here:
https://lists.yoctoproject.org/pipermail/poky/2011-June/006634.html

I found that by building with gcc 4.5.1, I am able to boot the
Beagleboard using a linux-yocto-2.6.37 kernel and a core-image-sato
image. I've tested serial, USB, ethernet, audio, and X. There are some
quirks to be ironed out:

o Fix gcc 4.6.0 build
o Sometimes the /dev/fb0 device doesn't appear
- workaround is to create it manually:
# mknod /dev/fb0 char 29 0
but obviously a permanent solution is needed
o Screen resolution doesn't fit on _my_display, need to see if this is
specific to me, or a general problem
o Finish pruning the kernel config

With that, we'll have decent general purpose support for the Beagleboard
in the Yocto Project. meta-texasinstruments should still be considered
the upstream, and there are some things that will remain only there.
Such as the snazzy Beagleboard Linux boot logo and the orange screen on
DVI from u-boot. At this time, we haven't yet explored video
acceleration or expansion board support, although we will include the
bluetooth and wifi drivers from the meta-ti config.

I'd like to thank everyone who has shown interest in this effort and
especially those who have tried the build, opened bugs, and are helping
to investigate open bugs.

Thanks,

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


Re: undefined reference to `pthread_getspecific' in perl-native_5.12.2.bb task do_compile?

Joshua Lock <josh@...>
 

On Wed, 2011-06-08 at 06:48 -0700, Daryl Spitzer wrote:
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?
Hi Daryl,

Looks like we fixed this issue in our recent point release. Could you
try
http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.1.tar.bz2 ?

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


Re: undefined reference to `pthread_getspecific' in perl-native_5.12.2.bb task do_compile?

Joshua Lock <josh@...>
 

On Wed, 2011-06-08 at 05:17 -0600, Gary Thomas 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, you are spot on. Looks like the patch *did* make it into the
Bernard point release (5.0.1) too!

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=bernard&id=841d0845552ae5855955f88ce446d8ac675660a5

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


Re: recipe priority in multiple metas

sushisan <sinestado@...>
 

-----Mensaje original-----
De: Darren Hart <dvhart@...>
Para: sushisan <sinestado@...>
Cc: yocto@...
Asunto: Re: [yocto] recipe priority in multiple metas
Fecha: Wed, 08 Jun 2011 16:38:25 -0700


On 06/08/2011 04:17 PM, sushisan wrote:
> Hi:
> 
> I have a project that use openssl.
> 
> I practically all recipes used are in yocto project
> but I need someones that are in meta-oe (ie: fuse)
> 
> openssl is in  meta/recipes-connectivity AND in meta-oe/recipes connectivity
> 
> I've putted meta first than meta-oe in my bblayers.conf, but when I try
> to do a bitbake openssl
> bitbake try to compile ever the meta-oe recipe
> 
> How I set priority in search recipes?

We discussed this in IRC and setting the BBFILE_PRIORITY in the
layer.conf of the respective layers seems to have addressed the
immediate issue.
------------------------------------------

Now work the priority issue.

BUT when I try to rebuild kernel I have this error now:

$] bitbake  linux-yocto

Loading cache: 100% |###################################################################################################################################| ETA:  00:00:00
Loaded 1636 entries from dependency cache.
Parsing recipes: 100% |#################################################################################################################################| Time: 00:00:02
Parsing of 1034 .bb files complete (1033 cached, 1 parsed). 1328 targets, 13 skipped, 0 masked, 0 errors.

OE Build Configuration:
BB_VERSION        = "1.13.0"
METADATA_BRANCH   = "master"
METADATA_REVISION = "a702c3dbf5fdc88eefdadd1f6c4cd6e04811c1e1"
TARGET_ARCH       = "i586"
TARGET_OS         = "linux"
MACHINE           = "qemux86"
DISTRO            = "poky"
DISTRO_VERSION    = "1.0+snapshot-20110608"
TARGET_FPU        = ""

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 461 of 908 (ID: 6, /home/opt/Yocto/ErgiOS_embedded/ErgiOS/meta/recipes-kernel/linux/linux-yocto_git.bb, do_fetch)
NOTE: package linux-yocto-2.6.37+git2+f1dc3722d45cdcc92c84ebfecf4ce616d2efed26_2+c1a74a7872fdd1152265087aa7e59b96a8f2f42a-r0: task do_fetch: Started
ERROR: '/home/opt/Yocto/ErgiOS_embedded/ErgiOS/meta/recipes-kernel/linux/linux-yocto_git.bb' failed
ERROR: Logfile of failure stored in: /home/opt/Yocto/ErgiOS_embedded/ErgiOS/build/tmp/work/qemux86-poky-linux/linux-yocto-2.6.37+git2+f1dc3722d45cdcc92c84ebfecf4ce616d2efed26_2+c1a74a7872fdd1152265087aa7e59b96a8f2f42a-r0/temp/log.do_fetch.10729
Log data follows:
| git: error while loading shared libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file or directory
|  git: error while loading shared libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file or directory
|  ERROR: Function 'Fetcher failure for URL: 'git://git.yoctoproject.org/linux-yocto-2.6.37;protocol=git;nocheckout=1;branch=yocto/standard/common-pc/base,meta;name=machine,meta'. Unable to fetch URL git://git.yoctoproject.org/linux-yocto-2.6.37;protocol=git;nocheckout=1;branch=yocto/standard/common-pc/base,meta;name=machine,meta from any source.' failed
| ERROR: Function 'Fetcher failure for URL: 'git://git.yoctoproject.org/linux-yocto-2.6.37;protocol=git;nocheckout=1;branch=yocto/standard/common-pc/base,meta;name=machine,meta'. Unable to fetch URL git://git.yoctoproject.org/linux-yocto-2.6.37;protocol=git;nocheckout=1;branch=yocto/standard/common-pc/base,meta;name=machine,meta from any source.' failed
NOTE: package linux-yocto-2.6.37+git2+f1dc3722d45cdcc92c84ebfecf4ce616d2efed26_2+c1a74a7872fdd1152265087aa7e59b96a8f2f42a-r0: task do_fetch: Failed
ERROR: Task 6 (/home/opt/Yocto/ErgiOS_embedded/ErgiOS/meta/recipes-kernel/linux/linux-yocto_git.bb, do_fetch) failed with exit code '1'