Date   

replace outdated opencv bitbake file

Zafrullah Syed <zafrullahmehdi@...>
 

How to replace outdated opencv bitbake file?

When i build image, i get this following error, may be bitbake is unable to fetch files. How to update these files? 

WARNING: Failed to fetch URL svn://code.opencv.org/svn/opencv/branches/2.4;module=opencv;protocol=http, attempting MIRRORS if available
ERROR: Fetcher failure: Fetch command failed with exit code 1, output:
svn: E000002: Unable to connect to a repository at URL 'http://code.opencv.org/svn/opencv/branches/2.4/opencv'
svn: E000002: Could not open the requested SVN filesystem

ERROR: Function failed: Fetcher failure for URL: 'svn://code.opencv.org/svn/opencv/branches/2.4;module=opencv;protocol=http'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /home/siguser/yocto2013-05-21/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/opencv-2.4.2-r1/temp/log.do_fetch.26358
ERROR: Task 565 (/home/siguser/yocto2013-05-21/poky/meta-openembedded/meta-oe/recipes-support/opencv/opencv_2.4.bb, do_fetch) failed with exit code '1'
NOTE: Tasks Summary: Attempted 2688 tasks of which 2330 didn't need to be rerun and 1 failed.
Waiting for 0 running tasks to finish:

Summary: 1 task failed:
  /home/siguser/yocto2013-05-21/poky/meta-openembedded/meta-oe/recipes-support/opencv/opencv_2.4.bb, do_fetch
Summary: There were 2 WARNING messages shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.



[PATCH] Update Powertop command for YP SDK

Ioana Grigoropol <ioanax.grigoropol@...>
 

- powertop package has been updated from 1.13 to 2.3 and the command line options have changed
- option '-d' no longer exists -> option --debug seems to its successor
- option '-t' is not documented, but still works -> changed to --time, which is documented

[Yocto #4830]
Signed-off-by: Ioana Grigoropol <ioanax.grigoropol@intel.com>
---
.../sdk/remotetools/actions/PowertopModel.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/PowertopModel.java b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/PowertopModel.java
index af6cca0..79bef61 100644
--- a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/PowertopModel.java
+++ b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/PowertopModel.java
@@ -60,7 +60,7 @@ public class PowertopModel extends BaseModel {
remoteFile = new String(REMOTE_FILE_PREFIX + currentDate);
localFile = new String(remoteFile + LOCAL_FILE_SUFFIX);

- String args = "start -l " + remoteFile + " powertop -d -t " + time.toString();
+ String args = "start -l " + remoteFile + " powertop --debug --time " + time.toString();
if(showpid)
args += " -p";
runRemoteShellExec(monitor, args, true);
--
1.7.9.5


Yocto Full Pass Report for 1.5_M2.rc1 - 2013-07-03-3 build

Georgescu, Alexandru C <alexandru.c.georgescu@...>
 

Hello,

Here is the Full pass report for the 1.5_m2.rc1 – 2013-07-03-3 build.

 

Issue summary:

ADT

·         4783 - ARM: target arch change from armv5te to armv7a-vfp-neon in environment setting script.

BSPs

  • 4812 - sudoku-savant fails at 'make': 'cstdlib: No such file or directory'
  • 4816 - beagleboard could not startup with 20130703-3 image ( upgrade to gcc 4.8)
  • 4815 - reboot/shutdown compromises installation for lsb-sdk images - cannot reboot
  • 4817 - [p1022ds] ltp fail to build with 1.5 M2.rc1

OE-core

  • 4360 -  archiver.bbclass fails to filter package licenses - reopened - found on master

Runtime

  • 4814 -  rpm is broken on 1.5 M2 RC1 lsb images - change the assignee (Bogdan Marinescu)

Eclipse plugin

  • Cannot compile autotools project using i586 toolchain - 4813
  • Cannot use powertop and systemtap within eclipse - 4830, 4831

Hob

  • Many tests were blocked by 4793 (save issue) which was fixed recently

Build Appliance

  • 4829 - Build core-image-minimal with build-appliance-image

 

 

All the bugs found in the test run can be found in the summary below or by accessing the detailed report: https://wiki.yoctoproject.org/wiki/WW27_-_2013-07-03-3_-_Fullpass_Yocto_1.5_M2.RC1

 

 

Testing data

 Test type: 
 Branch: master
 Milestone: M2
 Build name: Fullpass
 poky commit: eaa5df34af42b6a37f6506847d0f3ef6ba0d298a
 poky commit date: Fri Jun 28 18:49:53 2013 +0000
 meta-intel commit: e0d6134ed2e2687ff9f2ee77701666447842bf33
 Eclipse Plugin commit: e35dfd79e3970f88a8273125890a54f75f108b97
 Autobuilder images repository: http://autobuilder.yoctoproject.org/pub/nightly/20130703-3/
 
 Distributions tested:  Fedora 18 32bit, Fedora 18 64bit, Ubuntu 13.04, Ubuntu 12.04, OpenSUSE 12.3 64bit, CentOS 6.4 x86_64 

Summary Report

Testing Summary Report

Test Run

Test Plan

Environment

Passed

Other issues

Failed

Failing bugs

Blocked

Blocking bugs

Complete

855 861

ADT: master branch

Fedora 18 i686

94.8%

none

5.2%

4783

0.0%

none

100.0%

854 858

ADT: master branch

Ubuntu 13.04 x86_64

94.8%

none

5.2%

4783

0.0%

none

100.0%

849

BSP/QEMU: master branch

Atom PC

97.2%

none

2.8%

4812 4005

0.0%

none

100.0%

846 847

BSP/QEMU: master branch

Beagleboard

0.0%

none

2.9%

4816

97.1%

4816

100.0%

843 845

BSP/QEMU: master branch

Crownbay-noemgd

98.7%

none

1.3%

4812

0.0%

none

100.0%

831 832

BSP/QEMU: master branch

Emenlow

98.7%

none

1.3%

4812

0.0%

none

100.0%

842 844

BSP/QEMU: master branch

Fish River Island 2 (FRI2)

95.1%

none

2.4%

2646 2415

2.4%

2415

100.0%

828 826 828

BSP/QEMU: master branch

Jasperforest

72.5%

none

5.9%

4812 4815

21.6%

4814 4815

100.0%

856 860

BSP/QEMU: master branch

MPC8315e-rdb

94.1%

none

5.9%

4812

0.0%

none

100.0%

836

BSP/QEMU: master branch

NUC(Next Unit of Computing)

100.0%

none

0.0%

none

0.0%

none

100.0%

869 870

BSP/QEMU: master branch

P1022ds

0.0%

none

2.1%

4817

97.9%

4817

100.0%

837 850

BSP/QEMU: master branch

qemu-x86

96.2%

none

3.8%

4812 4834

0.0%

none

100.0%

839 862 872

BSP/QEMU: master branch

qemuarm

96.5%

none

3.5%

4024 4812

0.0%

none

100.0%

864 865 867

BSP/QEMU: master branch

qemumips

98.8%

none

1.2%

4812

0.0%

none

100.0%

863 866 868

BSP/QEMU: master branch

qemuppc

98.8%

none

1.2%

4812

0.0%

none

100.0%

838 873

BSP/QEMU: master branch

qemux86-64

98.1%

none

1.9%

4812

0.0%

none

100.0%

857 859

BSP/QEMU: master branch

Routerstationpro

2.0%

none

0.0%

none

98.0%

4566

100.0%

820 825

BSP/QEMU: master branch

Sugarbay

98.7%

none

1.3%

4812

0.0%

none

100.0%

830

Eclipse Plugin: master branch

Fedora 18 x86_64

100.0%

none

0.0%

none

0.0%

none

100.0%

833

Eclipse Plugin: master branch

Ubuntu 12.10 x86_64

88.9%

none

11.1%

4830 4831

0.0%

none

100.0%

848

Meta-yocto: master branch

Ubuntu 13.04 x86-64

90.9%

none

9.1%

3908

0.0%

none

100.0%

851 852

Hob: master branch

Ubuntu 12.04 x86_64

81.3%

none

0.0%

none

18.8%

4793

100.0%

819 822

OE-Core: master branch

Multiple environments

95.2%

none

4.8%

4630 4529

0.0%

none

100.0%

834 835

BitBake: master branch

Multiple Environments

100.0%

none

0.0%

none

0.0%

none

100.0%

823 824

Runtime: master branch

Multiple Environments

55.6%

none

0.0%

none

44.4%

4816 4814

100.0%

853

Build Appliance: master branch

qemu-kvm on Ubuntu 12.04 libvirt

50.0%

none

50.0%

4829

0.0%

none

100.0%

Total: 26

Test Case Status Report

Status

Count

BLOCKED

183

FAILED

43

PASSED

1200

Total: 1426

 

Bug Status Report

ID

Priority

Status

Resolution

Test Runs

Description

Version

Target Milestone

Age (days)

2415

Medium

NEW

844

connman doesn't provide a 3g configuration utility

1.2

Future

425

2646

Medium

ACCEPTED

844

Windows switching failure

1.2

1.5

376

3908

Medium+

IN PROGRESS REVIEW

848

Kernel panic on qemux86-64 when using runqemu kvm and cpu host

1.4

1.5 M2

134

4005

Low

NEW

849

dmesg log errors in Atom-PC

1.3.1

1.5

114

4024

Undecided

RESOLVED

FIXED

862 839

start qemuarm with "core-image-sato", use "dmesg | grep -i error" shows 2 errors

1.4

---

110

4529

Medium

NEW

822

x32 build fails with gmp_5.1.1 do_configure

1.5

1.5

42

4566

Medium+

ACCEPTED

857 859

routerstation pro cannot bootup with NFS in yocto 1.5 20130521-1 build

1.5

1.5 M2

36

4630

Medium

REOPENED

819

archiver.bbclass fails to filter package licenses

1.5

1.5

23

4783

Medium+

NEW

854 855

[adt-installer] ARM: target arch change from armv5te to armv7a-vfp-neon in environment setting script.

1.5

1.5 M2

6 (Recent)

4793

Undecided

RESOLVED

FIXED

852 851

Clicking "Save" button from "Settings" and "Advanced Configuration" fails

1.5

---

2 (Recent)

4812

Medium+

NEW

832 850 849 856 826 825 873 867 860 843 872 868

sudoku-savant fails at 'make': 'cstdlib: No such file or directory'

1.5

1.5

NEW

4814

Medium+

NEW

828 824

rpm is broken on 1.5 M2 RC1 lsb images

1.5

1.5 M3

NEW

4815

Medium+

NEW

826

reboot/shutdown compromises installation for lsb-sdk images

1.5

1.5 M2

NEW

4816

High

ACCEPTED

846 847 824

beagleboard could not startup with 20130703-3 image

1.5

1.5 M3

NEW

4817

Medium

ACCEPTED

870 869

[p1022ds] ltp fail to build with 1.5 M2.rc1

1.5

1.5

NEW

4829

Medium+

RESOLVED

DUPLICATE

853

[Test Case 340] Build core-image-minimal with build-appliance-image

1.5

1.5 M3

NEW

4830

Medium

NEW

833

cannot use powertop within eclipse

1.5

1.5 M2

NEW

4831

Medium

IN PROGRESS REVIEW

833

error when running systemtap within eclipse

1.5

1.5 M2

NEW

4834

Undecided

RESOLVED

DUPLICATE

850

[Test Case 225] ethernet static ip set in connman

1.5

---

NEW

Total: 19

 

 

Here is the build performance comparison charts for the last milestones incuding 1.5_M2.rc2. I attached also the detailed report spreadsheet. As you can see, there is no big difference between the last milestones. The performance test data was compiled by using the data available on Performance Test wiki: https://wiki.yoctoproject.org/wiki/Performance_Test

 

 

Regards,

--

Alexandru Georgescu

Yocto QA Engineer

SSG/SSD Open Source Technology Center Romania

 


Re: [meta-freescale] Compile error for boost_1.54.0

Khem Raj
 

On Jul 9, 2013, at 1:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote:

On Tue, Jul 09, 2013 at 09:25:30PM +0100, Chris Tapp wrote:
Forwarding to Yocto mailing list:

On 9 Jul 2013, at 21:21, Otavio Salvador wrote:

On Tue, Jul 9, 2013 at 5:19 PM, Chris Tapp <opensource@keylevel.com> wrote:

On 9 Jul 2013, at 20:09, Chris Tapp wrote:

I'm getting a failure in do_compile when building boost_1.54.0 using master-next for the wandboard-quad.

The log is about 1.5MB, but the important bit seems to be that uintptr_t isn't defined but is required by /boost/atomic/atomic.hpp.

Has anyone seen this before?
I also meant to say that adding:

typedef unsigned long long uintptr_t;

to atomic.hpp 'fixes' the build, but this is not a good solution ;-)
It needs to be checked against normal Poky to ensure it is BSP
specific; I doubt it is.
See
http://lists.openembedded.org/pipermail/openembedded-devel/2013-July/091331.html
in above thread answering to your question if you want to include <cstblib> you need to specify
-std=gnu++0x or -std=c++0x to cppflags. above container is not supported prior to c++0x standard



But maybe it wasn't caused by eglibc upgrade (and header cleanup in
eglibc) but by boost upgrade.

--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [meta-freescale] Compile error for boost_1.54.0

Khem Raj
 

On Jul 9, 2013, at 8:17 PM, Saul Wold <sgw@linux.intel.com> wrote:

On 07/09/2013 01:50 PM, Martin Jansa wrote:
On Tue, Jul 09, 2013 at 09:25:30PM +0100, Chris Tapp wrote:
Forwarding to Yocto mailing list:

On 9 Jul 2013, at 21:21, Otavio Salvador wrote:

On Tue, Jul 9, 2013 at 5:19 PM, Chris Tapp <opensource@keylevel.com> wrote:

On 9 Jul 2013, at 20:09, Chris Tapp wrote:

I'm getting a failure in do_compile when building boost_1.54.0 using master-next for the wandboard-quad.

The log is about 1.5MB, but the important bit seems to be that uintptr_t isn't defined but is required by /boost/atomic/atomic.hpp.

Has anyone seen this before?
I also meant to say that adding:

typedef unsigned long long uintptr_t;

to atomic.hpp 'fixes' the build, but this is not a good solution ;-)
It needs to be checked against normal Poky to ensure it is BSP
specific; I doubt it is.
See
http://lists.openembedded.org/pipermail/openembedded-devel/2013-July/091331.html

But maybe it wasn't caused by eglibc upgrade (and header cleanup in
eglibc) but by boost upgrade.
I did the boost update and with the older eglibc, which is why it seemed to work for me.

I just did another build with the updated boost and both eglibc version 2.17 and 2.18, seems like the 2.18 version causes this breakage, as it built fine with 2.17, I also tried to revert the boost updated and build the older boost with 2.18 and it worked.

So it must be something with the newer boost and eglibc in combination, more digging is required.
its related to https://bugzilla.yoctoproject.org/show_bug.cgi?id=4812


Sau!



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


Re: [meta-freescale] Compile error for boost_1.54.0

Saul Wold <sgw@...>
 

On 07/09/2013 01:50 PM, Martin Jansa wrote:
On Tue, Jul 09, 2013 at 09:25:30PM +0100, Chris Tapp wrote:
Forwarding to Yocto mailing list:

On 9 Jul 2013, at 21:21, Otavio Salvador wrote:

On Tue, Jul 9, 2013 at 5:19 PM, Chris Tapp <opensource@keylevel.com> wrote:

On 9 Jul 2013, at 20:09, Chris Tapp wrote:

I'm getting a failure in do_compile when building boost_1.54.0 using master-next for the wandboard-quad.

The log is about 1.5MB, but the important bit seems to be that uintptr_t isn't defined but is required by /boost/atomic/atomic.hpp.

Has anyone seen this before?
I also meant to say that adding:

typedef unsigned long long uintptr_t;

to atomic.hpp 'fixes' the build, but this is not a good solution ;-)
It needs to be checked against normal Poky to ensure it is BSP
specific; I doubt it is.
See
http://lists.openembedded.org/pipermail/openembedded-devel/2013-July/091331.html

But maybe it wasn't caused by eglibc upgrade (and header cleanup in
eglibc) but by boost upgrade.
I did the boost update and with the older eglibc, which is why it seemed to work for me.

I just did another build with the updated boost and both eglibc version 2.17 and 2.18, seems like the 2.18 version causes this breakage, as it built fine with 2.17, I also tried to revert the boost updated and build the older boost with 2.18 and it worked.

So it must be something with the newer boost and eglibc in combination, more digging is required.

Sau!



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


Re: poky and gnuradio

Edward Vidal <vidal.develone@...>
 

Phillip,
This just started after a git pull of meta-oe
This is what I found in
/home/vidal/POKY/build070913_dylan/poky/build/tmp/work/all-poky-linux/uhd-firmware/1_003.005.002-r0/temp/less log.do_fetch.28656

 wget -t 2 -T 30 -nv --passive-ftp --no-check-certificate -P /home/vidal/POKY/linux_src_dnloads/downloads 'http://sources.openembedded.org/uhd-images_003.005.002-release.tar.gz'
http://sources.openembedded.org/uhd-images_003.005.002-release.tar.gz:
2013-07-09 19:08:10 ERROR 404: Not Found.
I tried the above in a shell.

I also tried with firefox 'http://sources.openembedded.org/uhd-images_003.005.002-release.tar.gz' I get the same error.
This new version of branch dylan does not include the gsl-1.15 (that you added for me) instead it has gsl-1.12.
I also have not the upgrade of gnuplot-4.4.4 to gnuplot-4.6.3
 
Let me know if I can provide other information.
Thanks


On Tue, Jul 9, 2013 at 6:49 PM, Philip Balister <philip@...> wrote:
It is not clear from your email if the failure is only with dylan. Does
one work and another build fail?

Can you wget the url it is trying to fetch?

Philip

On 07/09/2013 08:38 PM, Edward Vidal wrote:
> Hello,
> What is the best method to you the dylan branch of meta-oe with an gnuradio
> from meta-oe           =
> "(nobranch):ed84e64d22400595b68da4e75b48ab7ecc342aa9"?
>
> Any and all help will be appreciated.
>
> Build Configuration:
> BB_VERSION        = "1.18.0"
> BUILD_SYS         = "x86_64-linux"
> NATIVELSBSTRING   = "Fedora-18"
> TARGET_SYS        = "arm-poky-linux-gnueabi"
> MACHINE           = "beagleboard"
> DISTRO            = "poky"
> DISTRO_VERSION    = "1.4.1"
> TUNE_FEATURES     = "armv7a vfp neon"
> TARGET_FPU        = "vfp-neon"
> meta
> meta-yocto        = "dylan:64273e53f2789d2ea8393fc80909ac7086f168a7"
> meta-oe           = "dylan:13ae5105ee30410136beeae66ec41ee4a8a2e2b0"
> meta-java         = "master:59696d89fd33df6953dcb2dd54ccd3b362513f28"
> meta-yocto-bsp    = "dylan:64273e53f2789d2ea8393fc80909ac7086f168a7"
>
> The above build gets the following errors.
>
> ERROR: Fetcher failure for URL: '
> http://files.ettus.com/binaries/uhd_stable/releases/uhd_003.005.002-release/uhd-images_003.005.002-release.tar.gz'.
> Checksum mismatch!
> ERROR: Function failed: Fetcher failure for URL: '
> http://files.ettus.com/binaries/uhd_stable/releases/uhd_003.005.002-release/uhd-images_003.005.002-release.tar.gz'.
> Unable to fetch URL from any source.
> ERROR: Logfile of failure stored in:
> /home/vidal/POKY/build070913_dylan/poky/build/tmp/work/all-poky-linux/uhd-firmware/1_003.005.002-r0/temp/log.do_fetch.28656
> ERROR: Task 3499
> (/home/vidal/POKY/build070913_dylan/poky/meta-oe/meta-oe/recipes-connectivity/uhd/
> uhd-firmware_003.005.002.bb, do_fetch) failed with exit code '1'
>
> I went back to a meta-oe branch that I had built for the beagleboard,
> beaglebone, and pandaboard.
>
> Build Configuration:
> BB_VERSION        = "1.18.0"
> BUILD_SYS         = "x86_64-linux"
> NATIVELSBSTRING   = "Fedora-18"
> TARGET_SYS        = "arm-poky-linux-gnueabi"
> MACHINE           = "beagleboard"
> DISTRO            = "poky"
> DISTRO_VERSION    = "1.4.1"
> TUNE_FEATURES     = "armv7a vfp neon"
> TARGET_FPU        = "vfp-neon"
> meta
> meta-yocto        = "dylan:64273e53f2789d2ea8393fc80909ac7086f168a7"
> meta-oe           = "(nobranch):ed84e64d22400595b68da4e75b48ab7ecc342aa9"
> meta-java         = "master:59696d89fd33df6953dcb2dd54ccd3b362513f28"
> meta-yocto-bsp    = "dylan:64273e53f2789d2ea8393fc80909ac7086f168a7"
>
> Thanks
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@...
> https://lists.yoctoproject.org/listinfo/yocto
>


Re: poky and gnuradio

Philip Balister
 

It is not clear from your email if the failure is only with dylan. Does
one work and another build fail?

Can you wget the url it is trying to fetch?

Philip

On 07/09/2013 08:38 PM, Edward Vidal wrote:
Hello,
What is the best method to you the dylan branch of meta-oe with an gnuradio
from meta-oe =
"(nobranch):ed84e64d22400595b68da4e75b48ab7ecc342aa9"?

Any and all help will be appreciated.

Build Configuration:
BB_VERSION = "1.18.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "Fedora-18"
TARGET_SYS = "arm-poky-linux-gnueabi"
MACHINE = "beagleboard"
DISTRO = "poky"
DISTRO_VERSION = "1.4.1"
TUNE_FEATURES = "armv7a vfp neon"
TARGET_FPU = "vfp-neon"
meta
meta-yocto = "dylan:64273e53f2789d2ea8393fc80909ac7086f168a7"
meta-oe = "dylan:13ae5105ee30410136beeae66ec41ee4a8a2e2b0"
meta-java = "master:59696d89fd33df6953dcb2dd54ccd3b362513f28"
meta-yocto-bsp = "dylan:64273e53f2789d2ea8393fc80909ac7086f168a7"

The above build gets the following errors.

ERROR: Fetcher failure for URL: '
http://files.ettus.com/binaries/uhd_stable/releases/uhd_003.005.002-release/uhd-images_003.005.002-release.tar.gz'.
Checksum mismatch!
ERROR: Function failed: Fetcher failure for URL: '
http://files.ettus.com/binaries/uhd_stable/releases/uhd_003.005.002-release/uhd-images_003.005.002-release.tar.gz'.
Unable to fetch URL from any source.
ERROR: Logfile of failure stored in:
/home/vidal/POKY/build070913_dylan/poky/build/tmp/work/all-poky-linux/uhd-firmware/1_003.005.002-r0/temp/log.do_fetch.28656
ERROR: Task 3499
(/home/vidal/POKY/build070913_dylan/poky/meta-oe/meta-oe/recipes-connectivity/uhd/
uhd-firmware_003.005.002.bb, do_fetch) failed with exit code '1'

I went back to a meta-oe branch that I had built for the beagleboard,
beaglebone, and pandaboard.

Build Configuration:
BB_VERSION = "1.18.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "Fedora-18"
TARGET_SYS = "arm-poky-linux-gnueabi"
MACHINE = "beagleboard"
DISTRO = "poky"
DISTRO_VERSION = "1.4.1"
TUNE_FEATURES = "armv7a vfp neon"
TARGET_FPU = "vfp-neon"
meta
meta-yocto = "dylan:64273e53f2789d2ea8393fc80909ac7086f168a7"
meta-oe = "(nobranch):ed84e64d22400595b68da4e75b48ab7ecc342aa9"
meta-java = "master:59696d89fd33df6953dcb2dd54ccd3b362513f28"
meta-yocto-bsp = "dylan:64273e53f2789d2ea8393fc80909ac7086f168a7"

Thanks



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


poky and gnuradio

Edward Vidal <vidal.develone@...>
 

Hello,
What is the best method to you the dylan branch of meta-oe with an gnuradio from meta-oe           = "(nobranch):ed84e64d22400595b68da4e75b48ab7ecc342aa9"?

Any and all help will be appreciated.

Build Configuration:
BB_VERSION        = "1.18.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "Fedora-18"
TARGET_SYS        = "arm-poky-linux-gnueabi"
MACHINE           = "beagleboard"
DISTRO            = "poky"
DISTRO_VERSION    = "1.4.1"
TUNE_FEATURES     = "armv7a vfp neon"
TARGET_FPU        = "vfp-neon"
meta             
meta-yocto        = "dylan:64273e53f2789d2ea8393fc80909ac7086f168a7"
meta-oe           = "dylan:13ae5105ee30410136beeae66ec41ee4a8a2e2b0"
meta-java         = "master:59696d89fd33df6953dcb2dd54ccd3b362513f28"
meta-yocto-bsp    = "dylan:64273e53f2789d2ea8393fc80909ac7086f168a7"

The above build gets the following errors.

ERROR: Fetcher failure for URL: 'http://files.ettus.com/binaries/uhd_stable/releases/uhd_003.005.002-release/uhd-images_003.005.002-release.tar.gz'. Checksum mismatch!
ERROR: Function failed: Fetcher failure for URL: 'http://files.ettus.com/binaries/uhd_stable/releases/uhd_003.005.002-release/uhd-images_003.005.002-release.tar.gz'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /home/vidal/POKY/build070913_dylan/poky/build/tmp/work/all-poky-linux/uhd-firmware/1_003.005.002-r0/temp/log.do_fetch.28656
ERROR: Task 3499 (/home/vidal/POKY/build070913_dylan/poky/meta-oe/meta-oe/recipes-connectivity/uhd/uhd-firmware_003.005.002.bb, do_fetch) failed with exit code '1'

I went back to a meta-oe branch that I had built for the beagleboard, beaglebone, and pandaboard. 

Build Configuration:
BB_VERSION        = "1.18.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "Fedora-18"
TARGET_SYS        = "arm-poky-linux-gnueabi"
MACHINE           = "beagleboard"
DISTRO            = "poky"
DISTRO_VERSION    = "1.4.1"
TUNE_FEATURES     = "armv7a vfp neon"
TARGET_FPU        = "vfp-neon"
meta             
meta-yocto        = "dylan:64273e53f2789d2ea8393fc80909ac7086f168a7"
meta-oe           = "(nobranch):ed84e64d22400595b68da4e75b48ab7ecc342aa9"
meta-java         = "master:59696d89fd33df6953dcb2dd54ccd3b362513f28"
meta-yocto-bsp    = "dylan:64273e53f2789d2ea8393fc80909ac7086f168a7"

Thanks


Minutes: Yocto Project Technical Team Meeting - Tuesday, July 09, 2013 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

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

Attendees:
AlexG, MichaelH, ScottR, PaulE, AnnM, Saul, JeffP, Denys, Darren, TomZ, AlexG, LaurentiuP, NitinK, Cristian, Belen, Ross, Mark, SeanH, MatthewW, Song
 
Agenda:
 
* Opens collection - 5 min (Song)
* Yocto 1.5 status - 10 min (Song/team)
  . RC1 QA is almost done. QA report is available here:https://wiki.yoctoproject.org/wiki/WW27_-_2013-07-03-3_-_Fullpass_Yocto_1.5_M2.RC1
  . Saul and the triage team will look at the bugs we have and decide if we need RC2. 
  . Bug fixing is slow last week, mostly due to the US holidays. Call the team to focus more on bug fixing and bring the wdd number down.
  . Please update Bugzilla with your feature/bug status. Move items to future milestones if they did not get done in the target milestone. (Do not move high features/bugs by yourself)
* SWAT team rotation: Ioana -> Laurentiu Palcu
* Opens - 10 min
  - AlexG: Doc changes for feature verification. Michael started working on that. ETA the end of this week. RFC sent out weeks ago. No comments or objection so far. but Saul/Darren has concerns now. Song: please reply to the email asap. We need to resolve this really soon.
* Team Sharing - 20 min
  - Paul: automated runtime testing framework from Stephan is merged in master. If you are interested, please take a look. More patches are coming. A new series of patches for 1.4 backporting. In preparation for 1.4.2.
  - Saul: pulling patches and doing review now. Trying to determine whether we should have M2 RC2. Will be doing that later today.
  - AlexD: Finally we reached a point where we can demonstrate the basic workflow of WebHOB.
  - Michael: heading down open source lab. Will be working with Saul on RC2 if there is. Package reporting system is working.
  - Sean: encourage people to comment on Richard's comment on TSC. OE board is considering recommendations we would like to make regarding that topic.
 
 
 


Re: [meta-freescale] Compile error for boost_1.54.0

Martin Jansa
 

On Tue, Jul 09, 2013 at 09:25:30PM +0100, Chris Tapp wrote:
Forwarding to Yocto mailing list:

On 9 Jul 2013, at 21:21, Otavio Salvador wrote:

On Tue, Jul 9, 2013 at 5:19 PM, Chris Tapp <opensource@keylevel.com> wrote:

On 9 Jul 2013, at 20:09, Chris Tapp wrote:

I'm getting a failure in do_compile when building boost_1.54.0 using master-next for the wandboard-quad.

The log is about 1.5MB, but the important bit seems to be that uintptr_t isn't defined but is required by /boost/atomic/atomic.hpp.

Has anyone seen this before?
I also meant to say that adding:

typedef unsigned long long uintptr_t;

to atomic.hpp 'fixes' the build, but this is not a good solution ;-)
It needs to be checked against normal Poky to ensure it is BSP
specific; I doubt it is.
See
http://lists.openembedded.org/pipermail/openembedded-devel/2013-July/091331.html

But maybe it wasn't caused by eglibc upgrade (and header cleanup in
eglibc) but by boost upgrade.

--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com


Re: [meta-freescale] Compile error for boost_1.54.0

Chris Tapp
 

Forwarding to Yocto mailing list:

On 9 Jul 2013, at 21:21, Otavio Salvador wrote:

On Tue, Jul 9, 2013 at 5:19 PM, Chris Tapp <opensource@keylevel.com> wrote:

On 9 Jul 2013, at 20:09, Chris Tapp wrote:

I'm getting a failure in do_compile when building boost_1.54.0 using master-next for the wandboard-quad.

The log is about 1.5MB, but the important bit seems to be that uintptr_t isn't defined but is required by /boost/atomic/atomic.hpp.

Has anyone seen this before?
I also meant to say that adding:

typedef unsigned long long uintptr_t;

to atomic.hpp 'fixes' the build, but this is not a good solution ;-)
It needs to be checked against normal Poky to ensure it is BSP
specific; I doubt it is.

--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
Chris Tapp

opensource@keylevel.com
www.keylevel.com


Re: Yocto 1.4: Bad behavior between rm_work and packaging causing failures?

Jerrod Peach <peachj@...>
 



I think it's probably worth concentrating on the first issue. I can run some
tests, but the question is are you able to elaborate on what builds might have
been done before the user runs the problem build, and the nature of any
changes that were made between prior builds and the failing build? Are you
adding any custom tasks in your setup at all?

Cheers,
Paul


Paul,

So, I just came to a realization: We don't have any commonalities in tasks being added (or whether tasks are added at all) in the packages we saw it in.  However, we are running the builds automatically through Jenkins (the open source continuous integration software, if you're not familiar with it).  We've never seen this on a build that wasn't run through Jenkins, though we've only seen it twice, so that's not saying a whole lot.  We're wondering if a build aborted through Jenkins gets a SIGKILL, and if it does AND that happens during rm_work, I bet that could cause this problem.  Granted, this is all speculation, and we don't even know if the failures occurred immediately after aborted builds, but that's the only thing my colleagues and I can think of right now.

If you do want to continue investigating (which might be worthwhile, as our speculation could be totally off-base), the packages from poky with which we had this problem were eglibc-mtrace and systemd-serialgetty.  (We had the problem with 5 other packages, but they're all custom packages of ours.)  I find the latter particularly interesting, as that recipe seems to be quite boring aside from its several python functions.  That makes me think even more that we're seeing some weird combination of factors in our Jenkins builds.

Kind regards,

Jerrod


Installing Extra Libraries in SDK

squirem
 

Hello,

I'm currently developing a Qt application targeting the Freescale i.MX6.

I've build the meta-toolchain-qt SDK and am using it to cross-compile my
application.
So far I'm able to compile my application when only using Qt & POSIX
functions.

However, libcurl is not present in the sysroots of the SDK, which installed
here:
/opt/poky/1.4.1

I was able to compile libcurl code by manually copying libcurl, gnutls,
and libtasn1 libraries and headers located in the build directory into
/opt/poky/1.4.1/sysroots, but I would prefer to see
them installed with the sdk.

Is there any way of accomplishing this?

Any help would be appreciated.

Best regards,
squirem


Re: naming .bb files

Barros Pena, Belen <belen.barros.pena@...>
 

On 09/07/2013 14:47, "Khem Raj" <raj.khem@gmail.com> wrote:


On Jul 9, 2013, at 6:45 AM, "Barros Pena, Belen"
<belen.barros.pena@intel.com> wrote:

On 09/07/2013 11:35, "Paul Barker" <paul@paulbarker.me.uk> wrote:

On 9 July 2013 11:27, Barros Pena, Belen <belen.barros.pena@intel.com>
wrote:
Thanks Ross!

I've tried a .bb file name with capital letters and Hob is not liking
it
at all. So it looks like uppercase might also be a problem.
This is from memory and a month or so back but I think the problem
with capital letters is that opkg rejects .ipk files with capital
letters. I didn't have any problems with it when producing .deb files.
It sounds like the safe thing for Hob to do is to reject uppercase
letters
in .bb file names (just in case).
not only names but also in PR string if it has letters in it.
Noted, thanks!




Thanks!



--
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

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

_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

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


Re: Documenting YP Development Environment in more detail - user configuration

Rifenbark, Scott M <scott.m.rifenbark@...>
 

Dave,

Thanks for the comments and the suggestions. I think the color/style convention is a good idea. I will play around with that. I will also not that fact about the build directory.

Scott

-----Original Message-----
From: Stewart, David C
Sent: Tuesday, July 09, 2013 6:51 AM
To: Rifenbark, Scott M
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Documenting YP Development Environment in more
detail - user configuration



On 7/8/13 10:54 PM, "Rifenbark, Scott M" <scott.m.rifenbark@intel.com>
wrote:

Here is a link to draft section on the user configuration block of the
YP
Development Environment work. Check this out and provide feedback for
appropriate level of detail, usefulness, missing info, ect. This draft
section, once we settle on it, will set the tone and level for the
remaining detailed sections that make up the general environment
diagram.


http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#a-
closer-l
ook-at-the-yocto-project-development-environment
I think it will look really good.

Would it make sense to adopt some kind of notation for when a directory
is
a "source" vs "destination" type directory? For example, in the diagram
you have there, maybe color the source and destination directory boxes
differently or use hashed lines vs solid? Not sure it will be clear or
confusing once you get into more examples.

Also, it's a nit, but I think oe-init-build-env only creates the Build
Directory if it doesn't already exist.


Thanks,
Scott

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-
bounces@yoctoproject.org] On Behalf Of Burton, Ross
Sent: Tuesday, June 25, 2013 2:55 AM
To: Philip Balister
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Documenting YP Development Environment in more
detail - user configuration

On 25 June 2013 01:39, Philip Balister <philip@balister.org> wrote:
I totally agree we drifted way beyond the initial discussion of the
figure. The key thought here is understanding how Poky differs from
a
typical use of oe-core + other layers.
Is there such a thing as a "typical" use of oe-core + layers? Poky
uses a custom tool (combo-layer, in oe-core/scripts) to merge the
layers into a single repo. You could also use git submodules to make
a single repo (such as Guacamayo), or git subtree merges, or use repo
(gumstix), or have a script that manages the fetching of multiple
layers (Angstrom).

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


Re: Documenting YP Development Environment in more detail - user configuration

David Stewart
 

On 7/8/13 10:54 PM, "Rifenbark, Scott M" <scott.m.rifenbark@intel.com>
wrote:

Here is a link to draft section on the user configuration block of the YP
Development Environment work. Check this out and provide feedback for
appropriate level of detail, usefulness, missing info, ect. This draft
section, once we settle on it, will set the tone and level for the
remaining detailed sections that make up the general environment diagram.


http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#a-closer-l
ook-at-the-yocto-project-development-environment
I think it will look really good.

Would it make sense to adopt some kind of notation for when a directory is
a "source" vs "destination" type directory? For example, in the diagram
you have there, maybe color the source and destination directory boxes
differently or use hashed lines vs solid? Not sure it will be clear or
confusing once you get into more examples.

Also, it's a nit, but I think oe-init-build-env only creates the Build
Directory if it doesn't already exist.


Thanks,
Scott

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-
bounces@yoctoproject.org] On Behalf Of Burton, Ross
Sent: Tuesday, June 25, 2013 2:55 AM
To: Philip Balister
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Documenting YP Development Environment in more
detail - user configuration

On 25 June 2013 01:39, Philip Balister <philip@balister.org> wrote:
I totally agree we drifted way beyond the initial discussion of the
figure. The key thought here is understanding how Poky differs from a
typical use of oe-core + other layers.
Is there such a thing as a "typical" use of oe-core + layers? Poky
uses a custom tool (combo-layer, in oe-core/scripts) to merge the
layers into a single repo. You could also use git submodules to make
a single repo (such as Guacamayo), or git subtree merges, or use repo
(gumstix), or have a script that manages the fetching of multiple
layers (Angstrom).

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


Re: naming .bb files

Khem Raj
 

On Jul 9, 2013, at 6:45 AM, "Barros Pena, Belen" <belen.barros.pena@intel.com> wrote:

On 09/07/2013 11:35, "Paul Barker" <paul@paulbarker.me.uk> wrote:

On 9 July 2013 11:27, Barros Pena, Belen <belen.barros.pena@intel.com>
wrote:
Thanks Ross!

I've tried a .bb file name with capital letters and Hob is not liking it
at all. So it looks like uppercase might also be a problem.
This is from memory and a month or so back but I think the problem
with capital letters is that opkg rejects .ipk files with capital
letters. I didn't have any problems with it when producing .deb files.
It sounds like the safe thing for Hob to do is to reject uppercase letters
in .bb file names (just in case).
not only names but also in PR string if it has letters in it.



Thanks!



--
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

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

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


Re: naming .bb files

Barros Pena, Belen <belen.barros.pena@...>
 

On 09/07/2013 11:35, "Paul Barker" <paul@paulbarker.me.uk> wrote:

On 9 July 2013 11:27, Barros Pena, Belen <belen.barros.pena@intel.com>
wrote:
Thanks Ross!

I've tried a .bb file name with capital letters and Hob is not liking it
at all. So it looks like uppercase might also be a problem.
This is from memory and a month or so back but I think the problem
with capital letters is that opkg rejects .ipk files with capital
letters. I didn't have any problems with it when producing .deb files.
It sounds like the safe thing for Hob to do is to reject uppercase letters
in .bb file names (just in case).


Thanks!



--
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

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


Re: naming .bb files

Paul Barker <paul@...>
 

On 9 July 2013 11:27, Barros Pena, Belen <belen.barros.pena@intel.com> wrote:
Thanks Ross!

I've tried a .bb file name with capital letters and Hob is not liking it
at all. So it looks like uppercase might also be a problem.
This is from memory and a month or so back but I think the problem
with capital letters is that opkg rejects .ipk files with capital
letters. I didn't have any problems with it when producing .deb files.

--
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk