[yocto] [Package Report System]Manual check recipes name list

2012-12-29 Thread Yocto Project Package Report System 
This mail was sent out by Package Report System.
It will list all the recipes which can't check upstream version by script, and 
will show how long it is since their last mannual version check.
You can check the detail information at 
http://packages.yoctoproject.org/manuallychkinfo


PackageName  Version LastChkVersion  LastChkTime
  Maintainer  NoUpgradeReason   
lsb  4.1 4.1 116 day
  Yi Zhao  
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [Package Report System]Upgrade recipes name list

2012-12-29 Thread Yocto Project Package Report System 
This mail was sent out by Package Report System.
This message list those recipes which need to be upgraded. If maintainers 
believe some of them needn't to upgrade this time, they can fill in 
RECIPE_NO_UPDATE_REASON_pn-"xxx" in upstream_tracking files to ignore this 
recipe remainder until newer upstream version was detected.
Example:
RECIPE_NO_UPDATE_REASON_pn-"xxx" = "Not upgrade to 2.0 because the new version 
is unstable"
You can check the detail information at 
http://packages.yoctoproject.org/upgradepkgname


PackageName   Version   UpVersion   
  MaintainerNoUpgradeReason 
  
sysprof   1.1.8+gitAUTOINC+4692f85  1.2.0   
  Tom Zanussi
systemtap-uprobes 1.8+gitAUTOINC+48fa6b5e1  2.0 
  Tom Zanussi
shadow4.1.4.3   4.1.5.1 
  Scott Garman
sudo  1.8.5p2   1.8.6   
  Scott Garman
blktool   4-6   4   
  Scott Garman
icu   50.1  50.1.1  
  Scott Garman
apmd  3.2.2-14  3.2.2   
  Scott Garman
openssh   6.0p1 6.1p1   
  Scott Garman
man-pages 3.44  3.45
  Saul Wold
augeas0.10.01.0.0   
  Saul Wold
libidn1.25  1.26
  Saul Wold
mc4.8.6 4.8.7   
  Saul Wold
libtasn1  2.14  3.2 
  Saul Wold
libnl 3.2.143.2.16  
  Saul Woldlibnl-3.2.2 is 
incompatible w...
createrepo0.4.110.9.9   
  Saul WoldVersions after 
0.9.* use YUM,...
apt   0.7.140.9.7.7 
  Saul Wold
pkgconfig 0.25  0.27.1  
  Saul Woldremoves glib-conf, 
adds circu...
build-appliance-image 1.0   3.2.1   
  Saul Wold
util-linux2.22.12.22.2  
  Saul Wold
resolvconf1.68  1.69
  Saul Wold
dhcp  4.2.4-P2  4.2.4   
  Saul Wold
mtdev 1.1.2 1.1.3   
  Ross Burton
logrotate 3.8.1 3.8.3   
  Robert Yang
gawk  4.0.1 4.0.2   
  Radu Moisan
iputils   s20101006 20121221
  Radu Moisan
ed1.6   1.7 
  Radu Moisan
cronie1.4.8 1.4.9   
  Radu Moisan
apr-util  1.4.1 1.5.1   
  Radu Moisan
liburcu   0.7.4 0.7.5   
  Radu Moisan
js1.7.0+1.8.0rc11.60
  Radu Moisan
u-boot-mkimage2011.06   2012.10 
  Radu Moisan
valgrind  3.7.0 3.8.1   
  Radu Moisan
rxvt-unicode  9.15  9.16
  Radu Moisan
babeltrace1.0+gitAUTOINC+f6ed7fa46  1.0.0   
  Radu Moisan
systemtap 1.8+gitAUTOINC+48fa6b5e1  2.0 
  Radu Moisan
zlib  1.2.7

[yocto] [PATCH] Documentation: Small number of typoes/grammos in Ch 4, Dev Manual.

2012-12-29 Thread Robert P. J. Day 

Signed-off-by: Robert P. J. Day 

---

diff --git a/documentation/dev-manual/dev-manual-model.xml 
b/documentation/dev-manual/dev-manual-model.xml
index 442cab3..1c27828 100644
--- a/documentation/dev-manual/dev-manual-model.xml
+++ b/documentation/dev-manual/dev-manual-model.xml
@@ -33,7 +33,7 @@
  Direct modification of temporary source code is a convenient 
development model
  to quickly iterate and develop towards a solution.
  Once the solution has been implemented, you should of course take 
steps to
- get the changes upstream and applied in the affected 
recipes.
+ get the changes upstream and applied to the affected 
recipes.
  Image Development using Hob:
  You can use the Hob to build
  custom operating system images within the build environment.
@@ -55,7 +55,7 @@
 Usually, when you want to create an image that runs on embedded 
hardware, the image does
 not require the same number of features that a full-fledged Linux 
distribution provides.
 Thus, you can create a much smaller image that is designed to use only 
the
-features for your particular hardware.
+features of your particular hardware.
 

 
@@ -99,7 +99,7 @@
 
 Set up your host development system 
to support
 development using the Yocto Project:  See the
-"The 
Linux Distributions"
+"The 
Linux Distribution"
 and the
 "The 
Packages" sections both
 in the Yocto Project Quick Start for 
requirements.
@@ -110,7 +110,7 @@
 process and to the tools you need.
 For information on how to set up the
 Source Directory, 
see the
-"Getting Setup" 
section.
+"Getting Set Up" 
section.
 Establish the 
meta-intel
 repository on your system:  Having local copies 
of the
 supported BSP layers on your system gives you access to 
the build
@@ -245,7 +245,7 @@
 
 Traditionally, when one thinks of a patched kernel, they think 
of a base kernel
 source tree and a fixed structure that contains kernel patches.
-The Yocto Project, however, employs mechanisms, that in a 
sense, result in a kernel source
+The Yocto Project, however, employs mechanisms that, in a 
sense, result in a kernel source
 generator.
 By the end of this section, this analogy will become clearer.
 
@@ -327,7 +327,7 @@
 representing and using the code on your host development 
system is another.
 Conceptually, you can think of the kernel source repositories 
as all the
 source files necessary for all the supported kernels.
-As a developer, you are just interested in the source files 
for the kernel on
+As a developer, you are just interested in the source files 
for the kernel
 on which you are working.
 And, furthermore, you need them available on your host system.
 
@@ -391,7 +391,7 @@
 
 Set up your host development 
system to support
 development using the Yocto Project:  See
-"The 
Linux Distributions" and
+"The 
Linux Distribution" and
 "The 
Packages" sections both
 in the Yocto Project Quick Start for 
requirements.
 Establish a local copy of 
project files on your
@@ -445,7 +445,7 @@
 Doing so, can produce unexpected results when the 
OpenEmbedded build system
 regenerates the configuration file.
 Once you are satisfied with the configuration 
changes made using
-menuconfig, you can directly 
examine the
+menuconfig, you can directly 
compare the
 .config file against a saved 
original and gather those
 changes into a config fragment to be referenced from 
within the kernel's
 .bbappend file.
@@ -503,11 +503,11 @@
 
 Prepare the Host System for the 
Yocto Project:
 See
-"The 
Linux Distributions" and
+"The 
Linux Distribution" and
 "The 
Packages" sections both
 in the Yocto Project Quick Start for 
requirements.
 Secure the Yocto Project Kernel 
Target Image:
-You must have a target kernel image that has been built 
using the OpenEmbeded
+You must have a target ke

[yocto] How to include RPM database into target image?

2012-12-29 Thread Alex J Lennon 


Presumably this is very obvious, apologies, but I can't track down the 
answer.


I'm building a distro based on Yocto for a Raspberry Pi but I don't seem 
to have

the RPM database / sample feeds installed on the target image.

Having hunted around and googled I can't spot the environment variable or
recipe I presumably need to set/include.

Can anybody advise?

Many Thanks,

Alex

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

[yocto] odd(?) behaviour with qemu arm image and "runqemu-extract-sdk"

2012-12-29 Thread Robert P. J. Day 

  first time perusing these sections in the yocto docs, kind of
puzzling result so i'm prepared to believe i did something silly.
reading:

http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#workflow-using-stand-alone-cross-development-toolchains

"Workflow Using Stand-alone Cross-development Toolchains", and i
already had an OE qemuarm core-image-minimal built that i can run
just fine with:

$ runqemu qemuarm

so i was reading that section and followed the link over to the ADT
manual:

http://www.yoctoproject.org/docs/1.4/adt-manual/adt-manual.html#extracting-the-root-filesystem

where it talked about "Extracting the Root Filesystem", so i figured,
what the heck, i'll give that a shot, so i ran "runqemu-extract-sdk"
on the very rootfs tarball that had been created by my build and
extracted it under ~/rootfs, then without reading any further, tried
this variation of runqemu for the first time:

$ runqemu qemuarm ~/rootfs
Assuming /home/rpjday/rootfs is an nfs rootfs
Continuing with the following parameters:
KERNEL:
[/home/rpjday/oe/builds/oe/qemuarm/tmp-eglibc/deploy/images/zImage-qemuarm.bin]
ROOTFS: [/home/rpjday/rootfs]
FSTYPE: [nfs]
Setting up tap interface under sudo
[sudo] password for rpjday:
Acquiring lockfile for tap0...
runqemu-export-rootfs restart /home/rpjday/rootfs
Error: Unable to find rpc.mountd binary in
/home/rpjday/oe/builds/oe/qemuarm/tmp-eglibc/sysroots/x86_64-linux/usr/sbin/
Have you run 'bitbake meta-ide-support'?
Set 'tap0' nonpersistent
Releasing lockfile of preconfigured tap device 'tap0'
$

  so ... how many things did i do wrong?  some random thoughts on this
before i dig back into the docs and code:

1) why the name "runqemu-extract-sdk"?  it seems that the point of
that script is to just untar a root filesystem.  i don't see anything
being "extracted" per se.


2) i notice that the "dev" directory created by that script contains
only regular files instead of actual special device files.  but if i
use "sudo" to just untar exactly the same tarball, i get real device
files.  is that the expected behaviour of that script?

3) what should i have done earlier to have the apparently necessary
usr/sbin/rpc.mountd in my sysroot?  it seems odd that i can run my
built qemu image just fine if i run it normally, but if i
runqemu-extract-sdk to unload a rootfs, suddenly my sysroot is missing
that utility.  is the documentation simply missing some simple but
critical details about what types of images are required for this?

  and one more thing.  from that first link in the dev manual, there's
that note that takes you over to the ADT manual.  and it's entirely
possible that there some critical info *before* the section
"Extracting the Root Filesystem" but given how one got there (by
following the link), the reader might miss it.

  anyway, thoughts?

rday

-- 


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

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

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

Re: [yocto] IMHO, the "meta-yocto" layer is not adequately explained

2012-12-29 Thread Sean Liming 

> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] On Behalf Of Robert P. J. Day
> Sent: Saturday, December 29, 2012 2:23 AM
> To: Yocto discussion list
> Subject: [yocto] IMHO, the "meta-yocto" layer is not adequately explained
> 
> 
>   during travels thru the docs, ran across a "layer" graphic (dang, can't
> remember where) whose bottom layers were:
> 
>   ... snip ...
>   BSPs
>   Yocto
>   OE Core
> 
> clearly showing the yocto layer sitting above OE core and directly below
BSPs.
> but that picture is somewhat misleading since it's perfectly reasonable to
> build BSPs with no inclusion of the meta-yocto layer.
> 
>   i think there's a danger that new readers will get the impression that
they
> *must* include the meta-yocto layer to do any serious work, when that's
> just not true.  i think it would be worth briefly explaining what the
meta-
> yocto (and, consequently, meta-yocto-bsp) layers bring to the table, and
> under what circumstances one can leave that out.
> 
>   i realize this sounds contradictory since this *is* the yocto project,
but a
> simple list of what constitutes meta-yocto would be handy so developers
> realize what they're pulling in, and even if they need it.
> 
> rday
> 
> --
> 
> ==
> ==
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
> 
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> ==
> ==
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


That is a great idea. It would be very helpful.

Regards,

Sean Liming
Owner
Annabooks
Tel: 714-970-7523 / Cell: 858-774-3176

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

Re: [yocto] enable netbase network interfaces?

2012-12-29 Thread Gary Thomas 

On 2012-12-29 02:58, Robert P. J. Day wrote:

On Fri, 28 Dec 2012, Gary Thomas wrote:


On 2012-12-27 23:40, Lai Eddy wrote:

Thanks Gary,

after download and extract the ti cortex A8 BSP . there's only binary image
inside, what MACHINE to use to build a beagleboard yocto image?


MACHINE="beagleboard"

Why does this matter?  You asked about how to set up *your* BSP to have
a tailored network interface file.  All you need to do is pattern your
setup after the beagleboard one, as quoted.

n.b. please don't top-post :-(



On 2012-12-25 16:31, Lai Eddy wrote:

 in the "Reference Manual "How do I make sure connected network
interfaces are brought up by default?" said 2 files need to be added to
enable network interfaces, where can I find
 template files?
 
--__--__--__-
 The default interfaces file provided by the netbase recipe does not
automatically bring up network interfaces. Therefore, you will need to add a
BSP-specific netbase that includes
 an interfaces file.
 For example, add the following files to your layer:
meta-MACHINE/recipes-bsp/__netbase/netbase/MACHINE/__interfaces
meta-MACHINE/recipes-bsp/__netbase/netbase_5.0.bbappend
 
--__--__--__--


Look in meta-ti (git://git.yoctoproject.org/__meta-ti
):
$ find meta-ti/recipes-core/netbase/
meta-ti/recipes-core/netbase/
meta-ti/recipes-core/netbase/__netbase-5.0
meta-ti/recipes-core/netbase/__netbase-5.0/beagleboard
meta-ti/recipes-core/netbase/__netbase-5.0/beagleboard/__interfaces
meta-ti/recipes-core/netbase/__netbase_5.0.bbappend


   i'm not sure where your "__" prefixes are coming from, but i know
i've pointed out before that meta-ti's netbase_5.0.bbappend file seems
to be broken.  currently, on dev branch, it contains:

THISDIR := "${@os.path.dirname(bb.data.getVar('FILE', d, True))}"
FILESPATH =. "${@base_set_filespath(["${THISDIR}/${PN}"], d)}:"

   that value for FILESPATH is incorrect -- because the directory name
for the "interfaces" file in meta-ti is netbase-5.0 (not simply
netbase), it will *not* be picked up; rather, the default "interfaces"
file from oe-core will be pulled in.

   using bitbake-env, you can *see* the FILESPATH value that's used
when building for beagle using meta-ti:

$ bitbake-env -r netbase FILESPATH | tr : '\n'
Parsing recipes..WARNING: No recipes available for:

/home/rpjday/oe/dist/layers/meta-ti/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
done.
# FILESPATH="${@base_set_filespath(["${THISDIR}/${PN}"], d)}
${@base_set_filespath(["${FILE_DIRNAME}/${BP}",
"${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
FILESPATH="/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/arm
/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/beagleboard
/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/omap3
/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/armv7a
/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/
/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/arm
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/beagleboard
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/omap3
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/armv7a
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/arm
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/beagleboard
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/omap3
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/armv7a
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/arm
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/beagleboard
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/omap3
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/armv7a
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/"
$

   you can see that FILESPATH doesn't include the very directory in
meta-ti that contains the overriding beagleboard "interfaces" file.

   or am i horribly misunderstanding something here?


I agree that file is incorrect.  I simply quoted its use as it is the only
example in a commonly available layer.  I'll send a patch for the meta-ti
file and hopefully

[yocto] IMHO, the "meta-yocto" layer is not adequately explained

2012-12-29 Thread Robert P. J. Day 

  during travels thru the docs, ran across a "layer" graphic (dang,
can't remember where) whose bottom layers were:

... snip ...
BSPs
Yocto
OE Core

clearly showing the yocto layer sitting above OE core and directly
below BSPs.  but that picture is somewhat misleading since it's
perfectly reasonable to build BSPs with no inclusion of the meta-yocto
layer.

  i think there's a danger that new readers will get the impression
that they *must* include the meta-yocto layer to do any serious work,
when that's just not true.  i think it would be worth briefly
explaining what the meta-yocto (and, consequently, meta-yocto-bsp)
layers bring to the table, and under what circumstances one can leave
that out.

  i realize this sounds contradictory since this *is* the yocto
project, but a simple list of what constitutes meta-yocto would be
handy so developers realize what they're pulling in, and even if they
need it.

rday

-- 


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

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

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

Re: [yocto] enable netbase network interfaces?

2012-12-29 Thread Robert P. J. Day 
On Fri, 28 Dec 2012, Gary Thomas wrote:

> On 2012-12-27 23:40, Lai Eddy wrote:
> > Thanks Gary,
> >
> > after download and extract the ti cortex A8 BSP . there's only binary image
> > inside, what MACHINE to use to build a beagleboard yocto image?
>
> MACHINE="beagleboard"
>
> Why does this matter?  You asked about how to set up *your* BSP to have
> a tailored network interface file.  All you need to do is pattern your
> setup after the beagleboard one, as quoted.
>
> n.b. please don't top-post :-(
>
> >
> > On 2012-12-25 16:31, Lai Eddy wrote:
> >
> > in the "Reference Manual "How do I make sure connected network
> > interfaces are brought up by default?" said 2 files need to be added to
> > enable network interfaces, where can I find
> > template files?
> > 
> > --__--__--__-
> > The default interfaces file provided by the netbase recipe does not
> > automatically bring up network interfaces. Therefore, you will need to add a
> > BSP-specific netbase that includes
> > an interfaces file.
> > For example, add the following files to your layer:
> >meta-MACHINE/recipes-bsp/__netbase/netbase/MACHINE/__interfaces
> >meta-MACHINE/recipes-bsp/__netbase/netbase_5.0.bbappend
> > 
> > --__--__--__--
> >
> >
> > Look in meta-ti (git://git.yoctoproject.org/__meta-ti
> > ):
> > $ find meta-ti/recipes-core/netbase/
> > meta-ti/recipes-core/netbase/
> > meta-ti/recipes-core/netbase/__netbase-5.0
> > meta-ti/recipes-core/netbase/__netbase-5.0/beagleboard
> > meta-ti/recipes-core/netbase/__netbase-5.0/beagleboard/__interfaces
> > meta-ti/recipes-core/netbase/__netbase_5.0.bbappend

  i'm not sure where your "__" prefixes are coming from, but i know
i've pointed out before that meta-ti's netbase_5.0.bbappend file seems
to be broken.  currently, on dev branch, it contains:

THISDIR := "${@os.path.dirname(bb.data.getVar('FILE', d, True))}"
FILESPATH =. "${@base_set_filespath(["${THISDIR}/${PN}"], d)}:"

  that value for FILESPATH is incorrect -- because the directory name
for the "interfaces" file in meta-ti is netbase-5.0 (not simply
netbase), it will *not* be picked up; rather, the default "interfaces"
file from oe-core will be pulled in.

  using bitbake-env, you can *see* the FILESPATH value that's used
when building for beagle using meta-ti:

$ bitbake-env -r netbase FILESPATH | tr : '\n'
Parsing recipes..WARNING: No recipes available for:

/home/rpjday/oe/dist/layers/meta-ti/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
done.
# FILESPATH="${@base_set_filespath(["${THISDIR}/${PN}"], d)}
${@base_set_filespath(["${FILE_DIRNAME}/${BP}",
"${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
FILESPATH="/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/arm
/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/beagleboard
/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/omap3
/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/armv7a
/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/
/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/arm
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/beagleboard
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/omap3
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/armv7a
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/arm
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/beagleboard
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/omap3
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/armv7a
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/arm
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/beagleboard
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/omap3
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/armv7a
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/"
$

  you can see that FILESPATH doesn't include the very directory in
meta-ti that contains the overriding beagleboard "interfaces" file.

  or am i horribly misunderstanding something here?

rday

-- 


Robert P. J