Date   

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


Re: naming .bb files

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

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.

Belen

On 08/07/2013 16:37, "Burton, Ross" <ross.burton@intel.com> wrote:

On 8 July 2013 16:02, Barros Pena, Belen <belen.barros.pena@intel.com>
wrote:
There seem to be certain rules regarding .bb files naming, but
apparently
those are not written anywhere. Some of those rules seem to be:

* No spaces
* Underscores can only by used to separate name and version
* No ASCII special characters
* No non-ASCII characters
* No uppercase letters

Does anybody know of any others we should be aware of?
I wasn't aware of any restrictions on uppercase, but the recipe name
part is probably restricted to ASCII alphanumeric (a-z, 0-9) and ASCII
hyphens, then a underscore for the version separator, which is
alphanumeric and periods.

Ross

---------------------------------------------------------------------
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: Yocto 1.4: Bad behavior between rm_work and packaging causing failures?

Paul Eggleton
 

Hi Jerrod,

On Monday 08 July 2013 09:25:12 Jerrod Peach wrote:
Re-sending as we've hit another rash of these issues and it ate up a couple
days of investigation that still led to no resolution or figuring out how
to reproduce it. I'm going to log a bug in a day or so, even though my
information is incomplete, if no one knows what's going on here and can
explain how to avoid it (other than turning rm_work off, which I suspect
would fix the problem but cost us a bunch of disk space as a trade-off).

---------- Forwarded message ----------
From: Jerrod Peach <peachj@lexmark.com>
Date: Thu, Jun 13, 2013 at 12:28 PM
Subject: Yocto 1.4: Bad behavior between rm_work and packaging causing
failures?
To: yocto <yocto@yoctoproject.org>


All,

Since upgrading to Yocto 1.4, several people at our organization have
noticed a couple of weird build failures related to rm_work and packaging.
Here are the two failure scenarios:

1) A user builds package, but bitbake only re-runs the do_pkg_write_rpm
task without having run any other build tasks. This appears to be due to a
supposedly-valid stamp file existing for the other tasks in the task graph.
This would normally result in an empty rpm being created, but the rpm
creation code (smartly) refuses to create empty rpms. This, then, causes a
build failure during image creation (if the package is needed for the
image, of course) because the rpm isn't present. We think this situation
leads to the second failure we see.

2) Whether a build succeeds or fails, if it's run on our build
infrastructure, we upload its sstate to an sstate mirror. sstate is still
uploaded for the do_package_write_rpm task in case 1 for builds performed
on our infrastructure. That means the sstate, then, contains no rpm for
the package in question. This causes later builds to fail with the same
error as in case 1 (the rpm isn't present when the image needs it), but for
a different reason (getting a hit on poisoned sstate).

We do not know how to reproduce this problem. We think it's related to
commit f090c15 (in the poky repo), but we haven't had much time to
investigate further. I suspect there is only one bug to fix here (i.e.,
whatever is causing stamp files to incorrectly exist), but since there are
some number of unknowns here, I thought I'd be better off describing the
whole situation, just in case.

Has anyone else seen this? Does anyone have ideas as to what's causing it?
I haven't seen this, but then I don't often run with rm_work enabled. I have
asked Martin Jansa (the OE rm_work expert, who also made the change you have
pointed to) about it but he has not seen any similar issues in his setup.

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 Eggleton
Intel Open Source Technology Centre


How to create a mobile access point using new Yocto layer

Jukka Rissanen <jukka.rissanen@...>
 

Hi,

I have been experimenting with Yocto and created a new layer called meta-eca that builds ECA (Embedded Connectivity Appliance). ECA is a platform for building network appliances. One such use case is mobile access point which uses ConnMan tethering functionality to tether wifi, bluetooth, USB gadget and ethernet connections.

There is a howto at http://metaeca.wordpress.com/ which gives detailed build instructions how to create ECA using Yocto. There are build instructions for Beagleboard xM, Beaglebone Black, Atom-PC, VirtualBox, Intel NUC, Intel FRI2 and Raspberry Pi devices.

The meta-eca layer source code is at https://github.com/jukkar/meta-eca


Cheers,
Jukka


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

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

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-look-at-the-yocto-project-development-environment

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: Layer input

Bruce Ashfield <bruce.ashfield@...>
 

On 13-07-08 11:16 AM, Paul Eggleton wrote:
On Friday 28 June 2013 14:36:48 Khem Raj wrote:
On Jun 28, 2013, at 4:22 AM, "Rifenbark, Scott M"
<scott.m.rifenbark@intel.com> wrote:
I count eight meta-* layers in the YP repositories that don't exist in the
OE area. I understand what you are saying though and I can word it that
way to dampen the existence of the "many" differences :)
hmm may be they should be added to layer index. at least the ones which are
still maintained.
This is down to me, I've been keeping the layer index up-to-date for the
layers on yoctoproject.org. Listing the ones that aren't there, with comments
as to why not:

experimental/meta-darwin
- ancient, unmaintained, no conf/layer.conf
experimental/meta-m2
- ancient, unmaintained
experimental/meta-maemo
- ancient, unmaintained, no conf/layer.conf
experimental/meta-trusted
- not actively maintained
experimental/meta-x32
- ancient, we should probably just delete this
meta-dlna
- replaced by collaboration with meta-guacamayo
meta-extras
- not usable as a layer, most recipes unbuildable; I'm slowly whittling it
down as bits of it reappear in OE layers until one day hopefully it'll
become empty
meta-intel-contrib
- contrib repo for meta-intel
meta-jarvis
- joke layer
meta-meson
- (probably could add)
meta-meson-bsp
- (probably could add)
meta-minnow
- (was waiting for hardware availability)
meta-yocto-kernel-extras
- now submitted to the layer index
meta-zynq
- status not entirely clear, but seems to have been superseded?
Superseded. The xilinx guys have linux-yocto support in hand in their
layers no, so we can mark this as dead.

Bruce


Cheers,
Paul