Date   

Agenda: Yocto Project Technical Team Meeting - Tuesday, December 04, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

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

Agenda:
 
* Opens collection - 5 min (Song)
* Yocto 1.4 status - 20 min (Song/team)
* SWAT team rotation: LaurentiuP -> Ioana Grigoropol
* Opens - 10 min
* Team Sharing - 20 min


-----Original Appointment-----

We encourage people attending the meeting to logon the Yocto IRC chancel during the meeting (optional):

Yocto IRC: http://webchat.freenode.net/?channels=#yocto
IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html

Conference details
Conference name:
Yocto Technical Team
Conference date/start time:
Tue Jun 26, 2012 at 10:00 AM Central Daylight Time
Participants:
30
Duration:
60 minutes
Participant passcode:
76994298
Dial-in number:
1.972.995.7777
US Toll Free number:
1.877.561.6828
BlackBerry users, click this link to join your conference as a participant:
1.972.995.7777x76994298#
 
Depending on where you are dialing from, either your BlackBerry will pause and enter the passcode automatically or you will be prompted to click again to dial the passcode.

Local and Global Access Numbers


Country
Dial-in number
Australia:
1800 636 843
Czech Republic:
242 430 350
China (Beijing):
From office dial 8-9957777 or 8784277
Beijing Out of Office dial 5878 4277
China (Shanghai):
From office dial 8-9957777 or 3073322
Shanghai Out of Office dial 2307 3322
China (Shenzen):
From office dial 8-9957777 or 6007877
Shenzen Out of Office dial 2600 7877
China (Other Cities):
From IP phone dial 8-9957777
Other cities - Non IP phone dial 021-23073322
Denmark:
8060 1400
Finland:
09 41333477
France:
0497 275888
Germany:
08161 803232
Holland:
030 2417490
India:
BSNL subscribers use 1800 425 9996 (Toll Free) Airtel subscribers use 0008 009 861 212 (Toll Free) From TI Campus use 89957777 Others use 2509 9555 (Landline within Bangalore) or
80 2509 9555 (Outside Bangalore)
Israel:
09 790 6715
Italy:
039 69061234 (039 is local city code not country code)
Japan:
From TI Campus use 8 995 7777
Outside TI use 03 4331 3777
Malaysia:
From IP phone dial 2643799
From Kuala Lumpur dial 4264 3799
Outside Kuala Lumpur dial (03)4264 3799
Norway:
2 295 8744
Philippines:
From Baguio City use 4471177
From Metro Manila area use 8702477
Singapore:
From IP phone dial 3894777
Outside TI use 6389 4777
South Korea:
From IP phone dial 5606998
From Seoul dial 5606998
Outside Seoul dial (02)5606998
Sweden:
08 58755577
Taiwan:
From IP phone dial 1363
From Taipei dial 2241 1363
Outside Taipei dial (02)2241 1363
Turkey:
Landline Only dial 0811 288 0001
then enter 877 633 1123
UK:
01604 663003
US:
972 995 7777 or 1877 561 6828

Recurring conferences
First scheduled conference:
Tue Jun 26, 2012
Recurrence frequency:
Weekly - Every 1 week(s) on Tuesday
Recurrence ends:
End on Fri Jun 21, 2013, 10:40 AM CDT


Re: dhcp-server and init scripts

r10kindsofpeople <r10kindsofpeople@...>
 

Thanks, Gary!  That did the trick.

John


On Mon, Dec 3, 2012 at 2:13 PM, Gary Thomas <gary@...> wrote:
On 2012-12-03 12:01, r10kindsofpeople wrote:
I seem to have figured out how to add the dhcp-server to my image, including my own dhcpd.conf and default-server files by creating a "dhcp_4.2.4-P1.bbappend" recipe.  Everything
works, except the dhcp-server doesn't run on boot.

If I login and run "update-rc.d dhcp-server defaults" on the target, then it creates the entries in /etc/rc0.d (etc) and the service starts on the next boot.

The question is, how can I get bitbake to create those entries when it creates the image?  I'm open to completely different ways of going about this as well.  Looking at other
recipes, I thought this recipe would do, but it doesn't:

{named dhcp_4.2.4-P1.bbappend}
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

inherit update-rc.d

INITSCRIPT_NAME = "dhcp-server"
INITSCRIPT_PARAMS = "defaults"

# Not sure this is needed, since I'm not adding files, just replacing the default copies
SRC_URI += "file://dhcpd.conf \
                      file://default-server \
                      "
{end file}

I'm using the 8.0 "danny" release with Crown-bay BSP.  The "layer.conf" file includes IMAGE_INSTALL_append = " dhcp-server" (among other things).

Thanks in advance for any assistance you can offer,

You just missed one piece.  I have this working using these extra lines in my .bbappend:

inherit update-rc.d
INITSCRIPT_PACKAGES = "dhcp-server"
INITSCRIPT_NAME = "dhcp-server"
INITSCRIPT_PARAMS = "start 50 S . stop 50 0 6 1 ."

--
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: dhcp-server and init scripts

Gary Thomas
 

On 2012-12-03 12:01, r10kindsofpeople wrote:
I seem to have figured out how to add the dhcp-server to my image, including my own dhcpd.conf and default-server files by creating a "dhcp_4.2.4-P1.bbappend" recipe. Everything
works, except the dhcp-server doesn't run on boot.

If I login and run "update-rc.d dhcp-server defaults" on the target, then it creates the entries in /etc/rc0.d (etc) and the service starts on the next boot.

The question is, how can I get bitbake to create those entries when it creates the image? I'm open to completely different ways of going about this as well. Looking at other
recipes, I thought this recipe would do, but it doesn't:

{named dhcp_4.2.4-P1.bbappend}
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

inherit update-rc.d

INITSCRIPT_NAME = "dhcp-server"
INITSCRIPT_PARAMS = "defaults"

# Not sure this is needed, since I'm not adding files, just replacing the default copies
SRC_URI += "file://dhcpd.conf \
file://default-server \
"
{end file}

I'm using the 8.0 "danny" release with Crown-bay BSP. The "layer.conf" file includes IMAGE_INSTALL_append = " dhcp-server" (among other things).

Thanks in advance for any assistance you can offer,
You just missed one piece. I have this working using these extra lines in my .bbappend:

inherit update-rc.d
INITSCRIPT_PACKAGES = "dhcp-server"
INITSCRIPT_NAME = "dhcp-server"
INITSCRIPT_PARAMS = "start 50 S . stop 50 0 6 1 ."

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


dhcp-server and init scripts

r10kindsofpeople <r10kindsofpeople@...>
 

I seem to have figured out how to add the dhcp-server to my image, including my own dhcpd.conf and default-server files by creating a "dhcp_4.2.4-P1.bbappend" recipe.  Everything works, except the dhcp-server doesn't run on boot.  

If I login and run "update-rc.d dhcp-server defaults" on the target, then it creates the entries in /etc/rc0.d (etc) and the service starts on the next boot.

The question is, how can I get bitbake to create those entries when it creates the image?  I'm open to completely different ways of going about this as well.  Looking at other recipes, I thought this recipe would do, but it doesn't:

{named dhcp_4.2.4-P1.bbappend}
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

inherit update-rc.d

INITSCRIPT_NAME = "dhcp-server"
INITSCRIPT_PARAMS = "defaults"

# Not sure this is needed, since I'm not adding files, just replacing the default copies
SRC_URI += "file://dhcpd.conf \
                     file://default-server \
                     "
{end file}

I'm using the 8.0 "danny" release with Crown-bay BSP.  The "layer.conf" file includes IMAGE_INSTALL_append = " dhcp-server" (among other things).  

Thanks in advance for any assistance you can offer,

John


Re: Use of BBPATH in a layer.conf file.

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

On 12/03/2012 09:43 AM, Tomas Frydrych wrote:
On 02/12/12 22:51, Scott Garman wrote:
Robert Day has brought up an inconsistency in the way we append to
BBPATH within a couple of our layer.conf files.

In meta-hob, meta-yocto-bsp, and meta-intel, we do:

BBPATH := "${BBPATH}:${LAYERDIR}"

but in meta-yocto, we do:

BBPATH := "${LAYERDIR}:${BBPATH}"

Unless someone explains to me that it's necessary to use this different
ordering in meta-yocto's layer.conf, I will submit a patch to make this
more consistent.
This meta-yocto setup is intentional (there was thread about that a
while back). meta-yocto is a distro layer, and for any distro layer it
is reasonable to enforce its own precedence over any other layers is may
use, and meta-yocto chooses to do this. Non-distro layers, including all
bsp layers, are expected to always use an append operation so that they
can be stacked together.
Thanks for the concise explanation.

Scott

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


Re: Howto use yocto meta-toolchain?

Zhang, Jessica
 

Hi Marco,

Can you filed a bug about this in bugzilla? Also, you don't need to sudo to run the install script, if you choose the default location which is /opt/poky/1.3, it'll prompt you for the password, or you can specify a directory under your $HOME dir. In your bug, can you provide some detail how you build the toolchain, e.g. the local.conf file changes, etc.?

Thanks,
Jessica

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Marco
Sent: Monday, December 03, 2012 7:00 AM
To: yocto@yoctoproject.org
Subject: [yocto] Howto use yocto meta-toolchain?

Hi,
after build meta-toolchain (for beagleboard, for example) I have this script

15:32 koan@quad:~/yocto-8-danny/poky/build
$ ll tmp/deploy/sdk/poky-eglibc-x86_64-arm-toolchain-1.3.sh
-rwxr-xr-x 1 koan koan 16143 2012-12-03 15:25 tmp/deploy/sdk/poky-eglibc-x86_64-arm-toolchain-1.3.sh

Then I argued I had to launch it to install the Yocto toolchain, but I get an error

15:32 koan@quad:~/yocto-8-danny/poky/build
$ sudo tmp/deploy/sdk/poky-eglibc-x86_64-arm-toolchain-1.3.sh
[sudo] password for koan:
Enter target directory for SDK (default: /opt/poky/1.3):
You are about to install the SDK to "/opt/poky/1.3". Proceed[Y/n]?
Extracting SDK...done
Setting it up...find: `/opt/poky/1.3/sysroots/x86_64-pokysdk-linux/lib':
No such file or directory
SDK could not be set up. Relocate script failed. Abort!

What's wrong?
I wasn't able to find any document about it in YP website.

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


Re: Use of BBPATH in a layer.conf file.

Tomas Frydrych <tf+lists.yocto@...>
 

On 02/12/12 22:51, Scott Garman wrote:
Robert Day has brought up an inconsistency in the way we append to
BBPATH within a couple of our layer.conf files.

In meta-hob, meta-yocto-bsp, and meta-intel, we do:

BBPATH := "${BBPATH}:${LAYERDIR}"

but in meta-yocto, we do:

BBPATH := "${LAYERDIR}:${BBPATH}"

Unless someone explains to me that it's necessary to use this different
ordering in meta-yocto's layer.conf, I will submit a patch to make this
more consistent.
This meta-yocto setup is intentional (there was thread about that a
while back). meta-yocto is a distro layer, and for any distro layer it
is reasonable to enforce its own precedence over any other layers is may
use, and meta-yocto chooses to do this. Non-distro layers, including all
bsp layers, are expected to always use an append operation so that they
can be stacked together.

Tomas

--
http://sleepfive.com


recrdeptask not working correctly?

Jerrod Peach <peachj@...>
 

All,

I noticed the changes to recrdeptask from Yocto 1.2 to Yocto 1.3.  I saw a number of "all" tasks in the classes change like this:

-do_checkuriall[recrdeptask] = "do_checkuri"
+do_checkuriall[recrdeptask] = "do_checkuriall do_checkuri"

I have my own task that needs to work on all packages, and I assumed making the same change to my task would cause this to occur.  (Prior to this, I had noticed the task seemed to only be running on about 12 packages, where it used to run on about 60.)  So, I made the change, and indeed started running on more packages.  It only ran on about 45 packages though, which I found curious.  So, I dug a little deeper and had bitbake spit out pn-buildlist for me (with the -g option).  That list showed around 75 packages.  That meant I was still not running on a pretty large number of packages.  Then I ran checkurilall.  I noticed it, too, was running on the same list of packages as my task, i.e. NOT all of them.  

Has recrdeptask changed in some way that now prevents a task from running on all packages in a dependency graph recursively?  Was this intentional?  Is there some other (more preferable?) way for me to cause a task to run on all packages in a dependency graph?

Kind regards,

Jerrod


Disabling PREMIRRORS and upstream sources

Jon Szymaniak <jon.szymaniak@...>
 

Is there a simple way to disable the use of PREMIRRORS and MIRRORS
within a recipe?

(Perhaps the answer here might be worth mentioning in Section 12.23 of the
Poky Reference Manual?)

My use case for this is the situation where the code hasn't been released yet,
so there's no point in checking mirrors.

Thank you,
Jon


Howto use yocto meta-toolchain?

Marco <koansoftware@...>
 

Hi,
after build meta-toolchain (for beagleboard, for example) I have this script

15:32 koan@quad:~/yocto-8-danny/poky/build
$ ll tmp/deploy/sdk/poky-eglibc-x86_64-arm-toolchain-1.3.sh
-rwxr-xr-x 1 koan koan 16143 2012-12-03 15:25 tmp/deploy/sdk/poky-eglibc-x86_64-arm-toolchain-1.3.sh

Then I argued I had to launch it to install the Yocto toolchain, but I get an error

15:32 koan@quad:~/yocto-8-danny/poky/build
$ sudo tmp/deploy/sdk/poky-eglibc-x86_64-arm-toolchain-1.3.sh
[sudo] password for koan:
Enter target directory for SDK (default: /opt/poky/1.3):
You are about to install the SDK to "/opt/poky/1.3". Proceed[Y/n]?
Extracting SDK...done
Setting it up...find: `/opt/poky/1.3/sysroots/x86_64-pokysdk-linux/lib': No such file or directory
SDK could not be set up. Relocate script failed. Abort!

What's wrong?
I wasn't able to find any document about it in YP website.

TIA
--
Marco


Fetcher failure for mercurial repos: 'unknown revision' due to -r <SRCREV> in both clone and update?

Jon Szymaniak <jon.szymaniak@...>
 

I've been running into "Fetcher failures" for my recipes using
mercurial recently. They only seem to crop up the first time a package
that comes from a hg repo is fetched.

I believe the issue stems from the combination of the arguments used
by the hg fetcher and the fact that I specified a tag rather than
revision number.

I've included a "trimmed" log at the end of this post, where I've
pruned out useless and personal information. Here are some of of my
comments and questions. I'm no mercurial expert, so please do correct
me if and where I'm wrong!

- Why is GIT_CONFIG being exported for mercurial invocations?
- I think the 'clone -r v1.1.0' followed by the 'update -C -r v1.1.0'
is possibly responsible for the failure.
- In mercurial, the tag is a commit after the revision that's being tagged.
tip 41:58b8f368be68
v1.1.0 40:a925b596c163
v1.0.4 39:6bf84da2571e
- In the above, rev 41 contains the action of tagging 40 as 'v1.1.0'
- Therefore, if we clone the version associated with tag v1.1.0, we
get rev 40 and earlier. At this point, there's no "knowledge" of there
being a 'v1.1.0' tag!
- As such, the 'hg update -C -r v1.1.0' that follows the 'hg clone
-r v1.1.0' fails.

- One possible fix might be to remove the "-r <rev>" usage from the hg
fetcher. (lines 101 and 102 in bitbake/lib/bb/fetch2/hg.py)
- A fetch always follows an update to the revision anyway, doesn't
it. (Per comment @ lines 142-143).
- Con: You have to fetch the whole darn repo. It makes sense that we
wouldn't want to do that when we don't have to. :)
- Pro: You'll have the revision you wanted.
- Disclaimer: I'm not familiar enough with this code to know whether
this would cause undesired side effects or break things!

- Workaround: Don't use tags in SRCREV
- This stinks, because I like to write my .bb's as follows, so that
updating a version is just a matter of copy/renaming the .bb
require <my_package>.inc
PR = "${INC_PR}.0"
SRCREV = "v${PV}"

DEBUG: Fetch: checking for module directory
'/export/home/jon/projects/yocto/poky/build/test/downloads/hg/host/some_dir/my_package'
NOTE: Fetch hg://hg@host/some_dir;module=my_package;protocol=ssh
DEBUG: Running /usr/bin/env hg clone -r v1.1.0
ssh://hg@host/some_dir/my_package my_package
DEBUG: Fetcher accessed the network with the command /usr/bin/env hg
clone -r v1.1.0 ssh://hg@host/some_dir/my_package my_package
DEBUG: Running export HOME="/export/home/jon"; export
SSH_AGENT_PID="1234"; export SSH_AUTH_SOCK="<snipped>"; export
GIT_CONFIG="<snipped>/gitconfig"; export PATH="<snipped>";
/usr/bin/env hg clone -r v1.1.0 ssh://hg@host/some_dir/my_package
my_package
DEBUG: Running /usr/bin/env hg update -C -r v1.1.0
DEBUG: Running export HOME="/export/home/jon"; export
SSH_AGENT_PID="1234"; export SSH_AUTH_SOCK="<snipped>"; export
GIT_CONFIG="<snipped>/gitconfig"; export PATH="<snipped>";
/usr/bin/env hg update -C -r v1.1.0
WARNING: Failed to fetch URL
hg://hg@host/some_dir;module=my_package;protocol=ssh, attempting
MIRRORS if available
DEBUG: Fetcher failure: Fetch command failed with exit code 255, output:
abort: unknown revision 'v1.1.0'!

DEBUG: Python function base_do_fetch finished
DEBUG: Python function do_fetch finished
ERROR: Function failed: Fetcher failure for URL:
'hg://hg@host/some_dir;module=my_package;protocol=ssh'. Unable to
fetch URL from any source.


Thank you,
Jon


sysroot for use with GDB

Wolfgang Denk <wd@...>
 

Hello,

according to the documentation [1] the right way to debug applications
on the target is to load the target library information in GDB using

set solib-absolute-prefix /path/to/tmp/rootfs

i. e. referring it to the libraries in the target root file system
image. Assuming the target root file system uses by defualt stripped
libraries, we need to set up a copy of the rootfs with debug
information included.

But do we really have to? Why cannot we use the libraries present in
the SDK's sysroot directory (i. e. what OECORE_TARGET_SYSROOT points
to) ?

Trying to do so, we see that it fails. Our current suspicion is that
maybe prelinking of the target images and libraries introduces some
incompatibility. Is this a reasonable assumption, and if so, is this
a problem that should be fixed, or unavoidable for some reason? Or is
there a problem with the libraries in OECORE_TARGET_SYSROOT ?

All help welcome - thanks in advance.

[1] http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#platdev-gdb-remotedebug-launch-gdb


Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Beware of bugs in the above code; I have only proved it correct, not
tried it." - Donald Knuth


Re: Image libraries

Chris Tapp
 

Hi Ross,

On 3 Dec 2012, at 09:51, Burton, Ross wrote:

On 1 December 2012 22:39, Chris Tapp <opensource@keylevel.com> wrote:
Is there a recipe available for a library which can load image files into memory / GL textures?
Into memory, the lowest level would be libjpeg or libpng, but then
it's your responsibility to match the pixel formats.
If you're using GL and you don't have a higher level abstraction, you
might want to look at Cogl (GL specifics abstraction and sanity layer)
or Clutter (toolkit based on Cogl). Both of these are in oe-core.
Thanks, I'll have a look at that.

I've been using libsdl-image to get me going as I can use that to get at the image data and it's fairly easy to work out the pixel format.

Ross
Chris Tapp

opensource@keylevel.com
www.keylevel.com


Re: Image libraries

Chris Tapp
 

Hi Ross,

On 3 Dec 2012, at 09:51, Burton, Ross wrote:

On 1 December 2012 22:39, Chris Tapp <opensource@keylevel.com> wrote:
Is there a recipe available for a library which can load image files into memory / GL textures?
Into memory, the lowest level would be libjpeg or libpng, but then
it's your responsibility to match the pixel formats.
If you're using GL and you don't have a higher level abstraction, you
might want to look at Cogl (GL specifics abstraction and sanity layer)
or Clutter (toolkit based on Cogl). Both of these are in oe-core.
Thanks, I'll have a look at that.

I've been using libsdl-image to get me going as I can use that to get at the image data and it's fairly easy to work out the pixel format.

Ross
Chris Tapp

opensource@keylevel.com
www.keylevel.com


Re: Use of BBPATH in a layer.conf file.

Paul Eggleton
 

On Monday 03 December 2012 03:16:10 Robert P. J. Day wrote:
On Sun, 2 Dec 2012, Paul Eggleton wrote:
On Sunday 02 December 2012 15:35:54 you wrote:
On 12/02/2012 03:24 PM, Paul Eggleton wrote:
On Sunday 02 December 2012 14:51:28 Scott Garman wrote:
Robert Day has brought up an inconsistency in the way we append to
BBPATH within a couple of our layer.conf files.

In meta-hob, meta-yocto-bsp, and meta-intel, we do:

BBPATH := "${BBPATH}:${LAYERDIR}"

but in meta-yocto, we do:

BBPATH := "${LAYERDIR}:${BBPATH}"

Unless someone explains to me that it's necessary to use this
different
ordering in meta-yocto's layer.conf, I will submit a patch to make
this
more consistent.
I think it actually ought to be:

BBPATH .= ":${LAYERDIR}"
Oh? Would this apply just to meta-yocto or all layer.conf files?
All, really. Functionally it makes no real difference, but I think it's
preferred stylistically based on previous discussions.
hang on ... i thought the ordering of BBPATH would affect the
processing of "include" directives. no?
Yes, it does. What I mean is, functionally _within layer.conf_ the following
two are equivalent:

BBPATH := "${BBPATH}:${LAYERDIR}"

BBPATH .= ":${LAYERDIR}"

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Re: Image libraries

Burton, Ross <ross.burton@...>
 

On 1 December 2012 22:39, Chris Tapp <opensource@keylevel.com> wrote:
Is there a recipe available for a library which can load image files into memory / GL textures?
Into memory, the lowest level would be libjpeg or libpng, but then
it's your responsibility to match the pixel formats.

If you're using GL and you don't have a higher level abstraction, you
might want to look at Cogl (GL specifics abstraction and sanity layer)
or Clutter (toolkit based on Cogl). Both of these are in oe-core.

Ross


Re: Use of BBPATH in a layer.conf file.

Robert P. J. Day
 

On Sun, 2 Dec 2012, Paul Eggleton wrote:

On Sunday 02 December 2012 15:35:54 you wrote:
On 12/02/2012 03:24 PM, Paul Eggleton wrote:
On Sunday 02 December 2012 14:51:28 Scott Garman wrote:
Robert Day has brought up an inconsistency in the way we append to
BBPATH within a couple of our layer.conf files.

In meta-hob, meta-yocto-bsp, and meta-intel, we do:

BBPATH := "${BBPATH}:${LAYERDIR}"

but in meta-yocto, we do:

BBPATH := "${LAYERDIR}:${BBPATH}"

Unless someone explains to me that it's necessary to use this different
ordering in meta-yocto's layer.conf, I will submit a patch to make this
more consistent.
I think it actually ought to be:

BBPATH .= ":${LAYERDIR}"
Oh? Would this apply just to meta-yocto or all layer.conf files?
All, really. Functionally it makes no real difference, but I think it's
preferred stylistically based on previous discussions.
hang on ... i thought the ordering of BBPATH would affect the
processing of "include" directives. no?

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: Use of BBPATH in a layer.conf file.

Paul Eggleton
 

On Sunday 02 December 2012 15:35:54 you wrote:
On 12/02/2012 03:24 PM, Paul Eggleton wrote:
On Sunday 02 December 2012 14:51:28 Scott Garman wrote:
Robert Day has brought up an inconsistency in the way we append to
BBPATH within a couple of our layer.conf files.

In meta-hob, meta-yocto-bsp, and meta-intel, we do:

BBPATH := "${BBPATH}:${LAYERDIR}"

but in meta-yocto, we do:

BBPATH := "${LAYERDIR}:${BBPATH}"

Unless someone explains to me that it's necessary to use this different
ordering in meta-yocto's layer.conf, I will submit a patch to make this
more consistent.
I think it actually ought to be:

BBPATH .= ":${LAYERDIR}"
Oh? Would this apply just to meta-yocto or all layer.conf files?
All, really. Functionally it makes no real difference, but I think it's
preferred stylistically based on previous discussions.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Re: Use of BBPATH in a layer.conf file.

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

On 12/02/2012 03:24 PM, Paul Eggleton wrote:
On Sunday 02 December 2012 14:51:28 Scott Garman wrote:
Robert Day has brought up an inconsistency in the way we append to
BBPATH within a couple of our layer.conf files.

In meta-hob, meta-yocto-bsp, and meta-intel, we do:

BBPATH := "${BBPATH}:${LAYERDIR}"

but in meta-yocto, we do:

BBPATH := "${LAYERDIR}:${BBPATH}"

Unless someone explains to me that it's necessary to use this different
ordering in meta-yocto's layer.conf, I will submit a patch to make this
more consistent.
I think it actually ought to be:

BBPATH .= ":${LAYERDIR}"
Oh? Would this apply just to meta-yocto or all layer.conf files?

Scott

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


Re: Use of BBPATH in a layer.conf file.

Paul Eggleton
 

On Sunday 02 December 2012 14:51:28 Scott Garman wrote:
Robert Day has brought up an inconsistency in the way we append to
BBPATH within a couple of our layer.conf files.

In meta-hob, meta-yocto-bsp, and meta-intel, we do:

BBPATH := "${BBPATH}:${LAYERDIR}"

but in meta-yocto, we do:

BBPATH := "${LAYERDIR}:${BBPATH}"

Unless someone explains to me that it's necessary to use this different
ordering in meta-yocto's layer.conf, I will submit a patch to make this
more consistent.
I think it actually ought to be:

BBPATH .= ":${LAYERDIR}"

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre