[yocto] [meta-raspberrypi][PATCH 1/1] mesa: Modify version to match the one from oe-core

2013-11-11 Thread Andrei Gherzan 
Signed-off-by: Andrei Gherzan 
---
 recipes-graphics/mesa/{mesa_9.1.6.bbappend => mesa_9.2.2.bbappend} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename recipes-graphics/mesa/{mesa_9.1.6.bbappend => mesa_9.2.2.bbappend} 
(100%)

diff --git a/recipes-graphics/mesa/mesa_9.1.6.bbappend 
b/recipes-graphics/mesa/mesa_9.2.2.bbappend
similarity index 100%
rename from recipes-graphics/mesa/mesa_9.1.6.bbappend
rename to recipes-graphics/mesa/mesa_9.2.2.bbappend
-- 
1.8.1.4

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

Re: [yocto] [meta-raspberrypi][PATCH 1/1] mesa: Modify version to match the one from oe-core

2013-11-11 Thread Andrei Gherzan 
On Mon, Nov 11, 2013 at 12:02 PM, Andrei Gherzan  wrote:

> Signed-off-by: Andrei Gherzan 
> ---
>  recipes-graphics/mesa/{mesa_9.1.6.bbappend => mesa_9.2.2.bbappend} | 0
>  1 file changed, 0 insertions(+), 0 deletions(-)
>  rename recipes-graphics/mesa/{mesa_9.1.6.bbappend => mesa_9.2.2.bbappend}
> (100%)
>
> diff --git a/recipes-graphics/mesa/mesa_9.1.6.bbappend
> b/recipes-graphics/mesa/mesa_9.2.2.bbappend
> similarity index 100%
> rename from recipes-graphics/mesa/mesa_9.1.6.bbappend
> rename to recipes-graphics/mesa/mesa_9.2.2.bbappend
> --
> 1.8.1.4
>
>
Merged.

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

Re: [yocto] can't build meta-raspberrypi with latest Yocto or oe-core

2013-11-11 Thread Andrei Gherzan 
On Sun, Nov 10, 2013 at 11:01 AM, Alex M <0xf...@gmail.com> wrote:

> Hello!
> I'm using latest https://github.com/djwillis/meta-raspberrypi
> repository for raspberry-pi layer.
> Can't build any of two basic images, bitbake reports the following error:
>
> ERROR: No recipes available for:
>
> /media/usb_yocto/yocto/meta-raspberrypi/recipes-graphics/mesa/mesa_9.1.6.bbappend
> ERROR: Command execution failed: Exited with 1
>
> I tried with latest Yocto git, and latest oe-core from
> openembedded.org - results the same. Possibly mesa_9.1.6.bb is removed
> from both repositories.
>
> Please, could you fix this problem, or how I can overcome this error,
> which actions I should do to fix that?
>

Fix merged in master.

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

Re: [yocto] [meta-raspberrypi][PATCH 07/11] mesa: Use libgl from mesa for raspberrypi

2013-11-11 Thread Andrei Gherzan 
On Fri, Oct 11, 2013 at 6:47 PM, Paul Barker  wrote:

> On 24 August 2013 01:02, Andrei Gherzan  wrote:
> > On Fri, Aug 23, 2013 at 3:26 PM, Martin Jansa 
> > wrote:
> >> On Fri, Aug 23, 2013 at 11:59:10AM +0100, Paul Barker wrote:
> >> >
> >> > This really needs to check whether MACHINE="raspberrypi" before
> >> > changing anything. I keep the same stack of layers and just change
> >> > MACHINE when building for raspberrypi and beagleboard.
> >>
> >
> > That's definitely a good idea. Already merged the patch but will rebase /
> > add a new commit.
> >
>
> Any plans to add an 'if' here? If not, I'll add it to my todo list.
>
>
Yes. Will push patch today. Thanks.

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

[yocto] do any yocto docs clearly distinguish between "+=" and "_append"?

2013-11-11 Thread Robert P. J. Day 

  still slogging my way through the dev manual, and here:

http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#usingpoky-extend-customimage

section 5.2.1 recommends that recipe files use:

IMAGE_INSTALL += "strace"

while, further down in section 5.2.4, developers are encouraged to add
to their personal local.conf:

IMAGE_INSTALL_append = " strace"

  is there somewhere in a yocto doc a clear explanation of the proper
usage of "+=" versus "_append"? because, in my experience, that's a
point of serious confusion for new users.

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] ldd

2013-11-11 Thread Chris Hallinan 
On Sat, Nov 9, 2013 at 9:57 AM, Gary Thomas  wrote:

> On 2013-11-09 06:42, Seth Bollinger wrote:
>
>> Hello All,
>>
>> I don't see that ldd is part of the cross toolchain build anywhere.  Am I
>> missing something?
>>
>
> It's built with the eglibc recipe and is packaged separately.
>
>
Gosh, I though ldd, originally a hard-to-maintain script, was obsoleted a
long time ago. This command:

$ readelf --dynamic 

provides the same information, and readelf can be found in every cross
toolchain.

-Chris

-- 
Life is like Linux - it never stands still.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] the current dev manual seems to overly emphasize the importance of meta-intel

2013-11-11 Thread Rifenbark, Scott M 
Robert, 

You might imply these things reading this and you might not.  The opening 
sentence about the layer "meta-intel" being maintained in its own separate Git 
repository is factual and can stand on its own arguably with no implications 
that there is anything "magical" about it. 

The second point's implication is more valid.  You could read into this 
sentence that one must have a clone of this repository in order to get started 
with BSPs, which is not true.  I can update that paragraph to give the true 
value of having that local repo, which is to possibly use them as templates or 
base BSPs when creating your own.  I have reworded that particular sentence to 
"Using Git to create a local clone of the upstream repository can be helpful if 
you are working with BSPs."  

Note that I am applying this change to "latest" only.

Thanks,
Scott 

>-Original Message-
>From: yocto-boun...@yoctoproject.org [mailto:yocto-
>boun...@yoctoproject.org] On Behalf Of Robert P. J. Day
>Sent: Saturday, November 09, 2013 1:16 AM
>To: Yocto discussion list
>Subject: [yocto] the current dev manual seems to overly emphasize the
>importance of meta-intel
>
>
>  perusing the current dev manual and it reads:
>
>"Supported Board Support Packages (BSPs): The Yocto Project provides a layer
>called meta-intel and it is maintained in its own separate Git repository..."
>
>  this wording *seems* to suggest there is something magical about the meta-
>intel layer as compared to the numerous other layers. in particular, this
>statement further down just adds to that impression:
>
>"To get started with the BSPs, you need to use Git to create a local clone of
>the upstream repository."
>
>  i see no problem with using the meta-intel layer as an *example* but that
>section should be reworded to not make the reader think that meta-intel is
>unique in some weird sense. just my $0.02.
>
>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
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] does anything still use "meta-yocto-kernel-extras"?

2013-11-11 Thread Bruce Ashfield 

On 13-11-11 10:55 AM, Rifenbark, Scott M wrote:

Darren?  Any insight on this?


It is used by developers .. such as me :) I have some pending updates
to it as well. But generally speaking we are migrating the useful
parts to meta-skeleton and the other more 'mainstream' layers.

Bruce



Scott


-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-
boun...@yoctoproject.org] On Behalf Of Robert P. J. Day
Sent: Saturday, November 09, 2013 1:23 AM
To: Yocto discussion list
Subject: [yocto] does anything still use "meta-yocto-kernel-extras"?


  still in dev manual (where i'll be all day, i suspect), section 2.2 refers to 
the
layer meta-yocto-kernel-extras, but i don't recall seeing *anything* that uses
that layer (anymore?).

  i just grepped through all of the layers i have checked out and found not a
single instance of the string "meta-yocto-kernel-extras", other than in the
documentation that mentions it.

  is it still valid? still used somewhere?

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

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



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

Re: [linux-yocto] [PATCH 0/1] [PATCH] ACPI: Code backporting for ACPI Framework

2013-11-11 Thread Darren Hart 
On Mon, 2013-11-11 at 13:42 +0800, rebecca.swee.fun.ch...@intel.com
wrote:
> From: "Chang, Rebecca Swee Fun" 
> 
> Hi all,
> 
> This is a request merge this patch into standard/common-pc-64/baytrail.
> The branch mentioned is a new branch for Baytrail BSP. There will be
> more Baytrail related patches sending out soon.
> 
> This patch is ACPI related code changes. This ACPI framework was
> backported from Linux kernel v3.9. Sorry for the huge LOC change

If the changes were backported from 3.9, then the original patches
should be preserved as much as possible. The only changes should be
minor tweaks to each patch to perform the backport - but from 3.9 to
3.8, the changes should be well... nil.

> in this patch. We have collaborated and divided the code changes based
> on component and we thought that this would be the best way.

No. If the patches came from upstream, then they belong in standard/base
in their original form, not in a vendor-tree.

> 
> Once again, please pull this patch into standard/common-pc-64/baytrail.
> Branch creation should be HEAD on commit 
> 19f949f52599ba7c3f67a5897ac6be14bfcb1200
> or at tag named v3.8.

Your patches must come to the list for review, pull requests without
patches are not acceptable. If you need help preparing these
submissions, please let us know, we'll be happy to help.

--
Darren

> 
> Thanks a lot.
> 
> Regards
> Rebecca
> 
> The following changes since commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200:
> 
>   Linux 3.8 (2013-02-18 15:58:34 -0800)
> 
> are available in the git repository at:
> 
>   git://git.yoctoproject.org/linux-yocto-contrib 
> rebeccas/standard/common-pc-64/baytrail
>   
> http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=rebeccas/standard/common-pc-64/baytrail
> 
> Chang, Rebecca Swee Fun (1):
>   ACPI: code backporting for ACPICA, ACPI/PM, ACPI/PCI, ACPI/APEI
> 
>  .../ABI/testing/sysfs-devices-power_resources_D0   |   13 +
>  .../ABI/testing/sysfs-devices-power_resources_D1   |   14 +
>  .../ABI/testing/sysfs-devices-power_resources_D2   |   14 +
>  .../testing/sysfs-devices-power_resources_D3hot|   14 +
>  .../ABI/testing/sysfs-devices-power_state  |   20 +
>  .../ABI/testing/sysfs-devices-real_power_state |   23 +
>  .../ABI/testing/sysfs-devices-resource_in_use  |   12 +
>  Documentation/acpi/enumeration.txt |4 +-
>  Documentation/acpi/scan_handlers.txt   |   77 ++
>  arch/ia64/hp/common/aml_nfw.c  |2 +-
>  arch/ia64/include/asm/acpi.h   |4 -
>  arch/x86/include/asm/acpi.h|4 -
>  arch/x86/platform/olpc/olpc-xo15-sci.c |2 +-
>  drivers/acpi/Kconfig   |2 +-
>  drivers/acpi/Makefile  |3 +-
>  drivers/acpi/ac.c  |4 +-
>  drivers/acpi/acpi_memhotplug.c |   82 +-
>  drivers/acpi/acpi_pad.c|3 +-
>  drivers/acpi/acpi_platform.c   |   92 +-
>  drivers/acpi/acpica/Makefile   |8 +-
>  drivers/acpi/acpica/accommon.h |1 +
>  drivers/acpi/acpica/acdebug.h  |   17 +
>  drivers/acpi/acpica/acevents.h |   21 +-
>  drivers/acpi/acpica/acglobal.h |   37 +-
>  drivers/acpi/acpica/acinterp.h |2 +-
>  drivers/acpi/acpica/aclocal.h  |   45 +-
>  drivers/acpi/acpica/acmacros.h |  171 +---
>  drivers/acpi/acpica/acnamesp.h |   14 +-
>  drivers/acpi/acpica/acobject.h |2 +-
>  drivers/acpi/acpica/acparser.h |   25 +-
>  drivers/acpi/acpica/acpredef.h |   14 +-
>  drivers/acpi/acpica/acresrc.h  |6 +-
>  drivers/acpi/acpica/acutils.h  |   57 +-
>  drivers/acpi/acpica/amlresrc.h |6 +
>  drivers/acpi/acpica/dsmethod.c |6 +-
>  drivers/acpi/acpica/dsobject.c |   16 +-
>  drivers/acpi/acpica/dsopcode.c |   14 +-
>  drivers/acpi/acpica/dsutils.c  |   10 +-
>  drivers/acpi/acpica/dswexec.c  |4 +-
>  drivers/acpi/acpica/dswload.c  |5 +-
>  drivers/acpi/acpica/evgpe.c|   12 +-
>  drivers/acpi/acpica/evgpeblk.c |   22 +-
>  drivers/acpi/acpica/evgpeinit.c|3 +
>  drivers/acpi/acpica/evhandler.c|  529 +++
>  drivers/acpi/acpica/evregion.c |  582 ++--
>  drivers/acpi/acpica/evsci.c|4 +-
>  drivers/acpi/acpica/evxface.c  |   34 +-
>  drivers/acpi/acpica/evxfevnt.c |5 +-
>  drivers/acpi/acpica/evxfgpe.c

Re: [yocto] do any yocto docs clearly distinguish between "+=" and "_append"?

2013-11-11 Thread Paul Eggleton 
Hi Robert,

On Monday 11 November 2013 06:30:46 Robert P. J. Day wrote:
>   still slogging my way through the dev manual, and here:
> 
> http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#usingpoky
> -extend-customimage
> 
> section 5.2.1 recommends that recipe files use:
> 
> IMAGE_INSTALL += "strace"
> 
> while, further down in section 5.2.4, developers are encouraged to add
> to their personal local.conf:
> 
> IMAGE_INSTALL_append = " strace"

There is a good reason for this difference - it's likely that IMAGE_INSTALL 
will be set using = in the image recipe, and thus if you use += to add to it 
in local.conf it will have no effect. _append on the other hand is deferred 
until later and thus it will always work from local.conf. In the image recipe 
it's OK to use IMAGE_INSTALL += because you'll be able to put it in the right 
place with regard to any other assignment of the variable.

As I've noted more than once, modifying IMAGE_INSTALL or 
CORE_IMAGE_EXTRA_INSTALL from local.conf is really only appropriate for quick 
testing - for anything beyond that users should be creating their own image 
recipe(s).

>   is there somewhere in a yocto doc a clear explanation of the proper
> usage of "+=" versus "_append"? because, in my experience, that's a
> point of serious confusion for new users.

The proper place for the general discussion about how these operators work is 
really the BitBake manual; we're planning on promoting that to a first-class 
citizen and publishing it with the rest of our manuals for 1.6.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] Request to create a new branch for Baytrail BSP

2013-11-11 Thread Darren Hart 
On Sun, 2013-11-10 at 23:53 -0500, Bruce Ashfield wrote:
> On 11/10/2013, 10:43 PM, Chang, Rebecca Swee Fun wrote:
> > Hi all,
> >
> > I would like to request the community to create a new branch for
> > Baytrail BSP in linux-yocto-3.8.
> >
> > Baytrail BSP will run on both 32bit and also 64bit configurations.
> >
> > We plan to maintain only 1 branch for both 32 bit and 64 bit because the
> > recipes
> >
> > are the same.
> >
> > The branch name will be standard/common-pc-64/baytrail
> >
> > Branch HEAD on commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200 (Tag v3.8)
> >
> > After the community are done with branch creation, I will start upstream
> > the patches to the branch.
> 
> I can create the branch at any time, so consider it created. Are you
> looking for the branch creation to enable your local testing, or something
> else ?


Bruce, do not create this branch. Baytrail will be fully supported
upstream, we cannot have a branch called "baytrail" containing the
equivalent of a vendor tree". These branches, if they exist at all,
should be for specific boards that for some very special cases need
patches which are not acceptable upstream. This should be approaching
zero for Intel hardware.

We will work with Rebecca to come up with an acceptable solution.

--
Darren


> 
> The reason I ask, is that if you have patches, you can test and send
> the series before the branch creation, so there's no need to wait
> for it to appear in the tree before sending changes.
> 
> The summary and strategy is useful, so that is appreciated and the
> right thing to do versus just a large series of changes without any
> prior notice.
> 
> Cheers,
> 
> Bruce
> 
> >
> > Please do give me some comments if there are any better ways of doing this.
> >
> > Thanks!
> >
> > Best Regards
> >
> > Rebecca
> >
> >
> >
> > ___
> > linux-yocto mailing list
> > linux-yo...@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/linux-yocto
> >
> 
> ___
> linux-yocto mailing list
> linux-yo...@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto

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


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

Re: [yocto] does anything still use "meta-yocto-kernel-extras"?

2013-11-11 Thread Rifenbark, Scott M 
Darren?  Any insight on this?

Scott

>-Original Message-
>From: yocto-boun...@yoctoproject.org [mailto:yocto-
>boun...@yoctoproject.org] On Behalf Of Robert P. J. Day
>Sent: Saturday, November 09, 2013 1:23 AM
>To: Yocto discussion list
>Subject: [yocto] does anything still use "meta-yocto-kernel-extras"?
>
>
>  still in dev manual (where i'll be all day, i suspect), section 2.2 refers 
> to the
>layer meta-yocto-kernel-extras, but i don't recall seeing *anything* that uses
>that layer (anymore?).
>
>  i just grepped through all of the layers i have checked out and found not a
>single instance of the string "meta-yocto-kernel-extras", other than in the
>documentation that mentions it.
>
>  is it still valid? still used somewhere?
>
>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
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] Request to create a new branch for Baytrail BSP

2013-11-11 Thread Bruce Ashfield 

On 13-11-11 11:05 AM, Darren Hart wrote:

On Sun, 2013-11-10 at 23:53 -0500, Bruce Ashfield wrote:

On 11/10/2013, 10:43 PM, Chang, Rebecca Swee Fun wrote:

Hi all,

I would like to request the community to create a new branch for
Baytrail BSP in linux-yocto-3.8.

Baytrail BSP will run on both 32bit and also 64bit configurations.

We plan to maintain only 1 branch for both 32 bit and 64 bit because the
recipes

are the same.

The branch name will be standard/common-pc-64/baytrail

Branch HEAD on commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200 (Tag v3.8)

After the community are done with branch creation, I will start upstream
the patches to the branch.


I can create the branch at any time, so consider it created. Are you
looking for the branch creation to enable your local testing, or something
else ?



Bruce, do not create this branch. Baytrail will be fully supported
upstream, we cannot have a branch called "baytrail" containing the
equivalent of a vendor tree". These branches, if they exist at all,
should be for specific boards that for some very special cases need
patches which are not acceptable upstream. This should be approaching
zero for Intel hardware.

We will work with Rebecca to come up with an acceptable solution.


Ack'd.

Bruce



--
Darren




The reason I ask, is that if you have patches, you can test and send
the series before the branch creation, so there's no need to wait
for it to appear in the tree before sending changes.

The summary and strategy is useful, so that is appreciated and the
right thing to do versus just a large series of changes without any
prior notice.

Cheers,

Bruce



Please do give me some comments if there are any better ways of doing this.

Thanks!

Best Regards

Rebecca



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



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




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

Re: [yocto] i think the explanation of "Build Directory" in dev manual is wrong

2013-11-11 Thread Rifenbark, Scott M 
Robert,

I think you are correct here.  I tried them and no intermediate directory is 
created using the second example and the third example created a build 
directory whose name is "mybuilds".  I need to fix these up and will do that.

Scott

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Michael Gloff
Sent: Saturday, November 09, 2013 8:13 PM
To: Robert P. J. Day
Cc: Yocto discussion list
Subject: Re: [yocto] i think the explanation of "Build Directory" in dev manual 
is wrong


The build dir will definitely be created by the script(s) (assuming 
permissions). The default build dir will be created under the level of the 
script as 'build', but you can specify any path.

As you point this out I see the sentence:

The 
TOPDIR
 variable points to the Build Directory.
can be ambiguous. TOPDIR is not well defined. Maybe it should be called 
BUILD_DIR and defined somewhere in local.conf as a default commented out like 
DL_DIR and TMPDIR in addition to the ability to specify BUILD_DIR on the 
command line.
Michael Gloff


On Sat, Nov 9, 2013 at 4:09 AM, Robert P. J. Day 
mailto:rpj...@crashcourse.ca>> wrote:

  here:

http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#yocto-project-terms

explanation of "Build Directory", one reads (start quote):

Provide a directory path and specifically name the build directory.
This next example creates a Build Directory named YP-11.0.0 in your
home directory within the directory mybuilds. If mybuilds does not
exist, the directory is created for you:

 $ source poky-tbd-11.0.0/oe-init-build-env $HOME/mybuilds/YP-11.0.0

Provide an existing directory to use as the Build Directory and use
the default build name.

 $ source poky-tbd-11.0.0/oe-init-build-env $HOME/mybuilds/

 === end quote ===

  i don't think either of those is correct, are they? pretty sure that
oe-init-build-env *doesn't* create intermediate directories and, in
that second example, wouldn't that just use ~/mybuilds as the build
directory? i don't foresee a default build name subdirectory being
created there. or am i just confused?

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



--
Michael Gloff

mgl...@emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 310
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Agenda: Yocto Project Technical Team Meeting - Tuesday, November 12, 2013 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

2013-11-11 Thread Liu, Song 
Agenda:

* Opens collection - 5 min (Song)
* Yocto 1.6 status - 10 min (Song/team)
  https://wiki.yoctoproject.org/wiki/Yocto_1.6_Features
  https://wiki.yoctoproject.org/wiki/Yocto_1.6_Schedule
* SWAT team rotation: Laurentiu Nitin -> Beth
* 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 Project Technical Team
Conference date/start time: Tue Jun 25, 2013 at 11:00 AM Eastern Daylight 
Time (GMT-0400)
Participants:   30
Duration:   60 minutes
Participant passcode:   42001078
Dial-in number: 1.972.995.
US Toll Free number:1.877.561.6828
BlackBerry users, click this link to join your conference as a participant: 
1.972.995.x42001078#
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-995 or 8784277
Beijing Out of Office dial 5878 4277

China (Shanghai):
>From office dial 8-995 or 3073322
Shanghai Out of Office dial 2307 3322

China (Shenzen):
>From office dial 8-995 or 6007877
Shenzen Out of Office dial 2600 7877

China (Other Cities):
>From IP phone dial 8-995
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 8995
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 
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:
01908 355599

US:
972 995  or 1877 561 6828


Recurring conferences
First scheduled conference: Tue Jun 25, 2013
Recurrence frequency:   Weekly - Every 1 week(s) on Tuesday
Recurrence ends:End after 52 occurrences


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

[yocto] [meta-raspberrypi][PATCH] mesa: Match bbappend to OE-Core mesa version

2013-11-11 Thread Khem Raj 
Remove PRINC now that we have a chance

Signed-off-by: Khem Raj 
---
 recipes-graphics/mesa/{mesa_9.1.6.bbappend => mesa_9.2.2.bbappend} | 2 --
 1 file changed, 2 deletions(-)
 rename recipes-graphics/mesa/{mesa_9.1.6.bbappend => mesa_9.2.2.bbappend} (97%)

diff --git a/recipes-graphics/mesa/mesa_9.1.6.bbappend 
b/recipes-graphics/mesa/mesa_9.2.2.bbappend
similarity index 97%
rename from recipes-graphics/mesa/mesa_9.1.6.bbappend
rename to recipes-graphics/mesa/mesa_9.2.2.bbappend
index 88e5eab..7d158f2 100644
--- a/recipes-graphics/mesa/mesa_9.1.6.bbappend
+++ b/recipes-graphics/mesa/mesa_9.2.2.bbappend
@@ -1,5 +1,3 @@
-PRINC := "${@int(PRINC) + 1}"
-
 #
 # FIXME
 # We may a way to disable EGL and GL ES2, these are provided by userland 
package
-- 
1.8.3.2

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