date:20121003

Re: [yocto] Can't fetch git SRC_URI via HTTP

2012-10-03 Thread Julian Scheel

Am Dienstag, den 02.10.2012, 23:52 +0200 schrieb Martin Jansa:
> On Tue, Oct 02, 2012 at 11:38:08PM +0200, Julian Scheel wrote:
> > 
> > Am 02.10.2012 um 23:22 schrieb Martin Jansa :
> > 
> > > On Tue, Oct 02, 2012 at 05:17:23PM -0400, Evade Flow wrote:
> > >> I'm trying to build core-image-sato for my Pandaboard ES, following the
> > >> instructions posted here:
> > >> 
> > >>  - http://maniacbug.wordpress.com/2012/08/03/pandayocto/
> > >> 
> > >> Thus, my OE build configuration looks like this:
> > >> 
> > >>> OE Build Configuration:
> > >>> BB_VERSION= "1.15.2"
> > >>> TARGET_ARCH   = "arm"
> > >>> TARGET_OS = "linux-gnueabi"
> > >>> MACHINE   = "pandaboard"
> > >>> DISTRO= "poky"
> > >>> DISTRO_VERSION= "1.2.1"
> > >>> TUNE_FEATURES = "armv7a vfp neon cortexa9"
> > >>> TARGET_FPU= "vfp-neon"
> > >>> meta
> > >>> meta-yocto= "denzil:65ffa7395055f7e012cb973f63f92380828eed0d"
> > >>> meta-ti   = 
> > >>> "(nobranch):30fb40ebc13614a74c2e237927c60ac43e01d1bc"
> > >> 
> > >> I have these lines in my .gitconfig:
> > >> 
> > >>> [http]
> > >>>proxy=http://user:pas...@usaprox.lightning.com:8080
> > >> 
> > >> so I'd expect URLs like this one (from the meta-ti layer's
> > >> linux-omap4_3.1.0.bb recipe) to work fine:
> > >> 
> > >>> SRC_URI = 
> > >>> "http://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git;protocol=git;branch=ti-ubuntu-3.1-1282
> > >>>  \
> > > 
> > > This url seems wrong, it should start with git:// if you want to clone
> > > git repo.
> > > 
> > > Because it starts with http:// normal fetch (like wget) was used so it
> > > downloaded probably some http code (see that kernel-ubuntu.git file)
> > > instead of any relevant source.
> > 
> > I ran into the same issue a few days ago. It seems yocto only supports git 
> > fetch
> > through servers providing the repositories through the git protocol. A way 
> > to use
> > git repositories which are provided through http or https would be quite a 
> > good
> > thing to have.
> 
> That's what protocol param does;
> 
> Change that to
> git://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git;protocol=http;branch=ti-ubuntu-3.1-1282
> and you'll get git fetch over http protocol.

Nice to know. Actually when I had this issue I tried it the other way
round. Use a http url and set protocol to git...
Is this noted somewhere in the documentation? I could not find it. I
think it would be worth mentioning it in the yocto reference manual as
this seems to be a quite common thing to struggle with.

-Julian


>  
> > -Julian
> > 
> > > 
> > >>>   
> > >>> file://0001-Makefile.fwinst-fix-install-breakage-for-FW-images-r.patch \
> > >>>   file://defconfig \
> > >>>   "
> > >> 
> > >> From what I can tell, though, bitbake isn't handling this SRC_URI
> > >> correctly, and I get:
> > >> 
> > >>> ERROR: Command Error: exit status: 1  Output:
> > >>> Applying patch 
> > >>> 0001-Makefile.fwinst-fix-install-breakage-for-FW-images-r.patch
> > >>> patching file scripts/Makefile.fwinst
> > >>> Hunk #1 FAILED at 27.
> > >>> 1 out of 1 hunk FAILED -- rejects in file scripts/Makefile.fwinst
> > >>> Patch 0001-Makefile.fwinst-fix-install-breakage-for-FW-images-r.patch 
> > >>> does not apply (enforce with -f)
> > >>> ERROR: Function failed: patch_do_patch
> > >> 
> > >> If I examine the folder:
> > >> 
> > >>  build/tmp/work/pandaboard-poky-linux-gnueabi/linux-omap4-3.1.0-r0
> > >> 
> > >> I see that it contains no source code. It does, however, contain a file
> > >> named 'kernel-ubuntu.git', whose content is exactly the same as you'd
> > >> get if you typed:
> > >> 
> > >>  wget http://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git
> > >> 
> > >> This seems like a bug, possibly related to one of these:
> > >> 
> > >>  - http://bugzilla.yoctoproject.org/show_bug.cgi?id=3119
> > >>  - http://bugzilla.yoctoproject.org/show_bug.cgi?id=3175
> > >> 
> > >> 
> > >> Maybe this has been fixed since denzil, but... everything I read about
> > >> the current state of support for the Pandaboard suggests sticking with
> > >> denzil/gcc 4.6. Is there some workaround I can use to get past this
> > >> error?  Also, assuming these instructions worked for the author of the
> > >> original blog post, I wonder what the difference is with my setup.
> > >> 
> > >> Here are my mods to conf/local.conf, in case it's helpful:
> > >> 
> > >>> MACHINE = "pandaboard"
> > >>> BBMASK = "meta-ti/recipes-misc"
> > >>> PACKAGE_CLASSES = "package_ipk"
> > >>> CONNECTIVITY_CHECK_URIS=""
> > >>> BB_GENERATE_MIRROR_TARBALLS = "1"
> > >>> SOURCE_MIRROR_URL ?= "file:///home/evadeflow/projects/poky-mirror/"
> > >>> INHERIT += "own-mirrors"
> > >> 
> > >> And this is my bblayers.conf:
> > >> 
> > >>> # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
> > >>> # changes incompatibly
> > >>> LCONF_VERSION = "4"
> > >>> 
> > >>> BBFILES ?= ""
> > >>> BBLAYERS ?= " \
> > >>>  /home/evadeflow

Re: [yocto] How do you release distros produced with Yocto? How should I?

2012-10-03 Thread Tomas Frydrych

Hi,

On 02/10/12 19:45, Jerrod Peach wrote:
> I don't think that's actually what we want.  The architecture of each
> machine will be the same.  That is, one ASIC will generally be on all the
> printers in a family of products.  I think I actually have one machine +
> multiple distros.  Or, should I really be counting each different printer
> as its own machine?

The fact that the underlying HW is the same can be simply reflected by
having the actual HW-related definitions in a common include file. But
if printer X requires different version of package A from printer Y then
they are really best thought of as different machines -- you can make
packages specific to a machine architecture and then reliably pin the
version, you can't make packages distro-specific (the whole OE/Yocto set
up is built around an implicit premise that any given OE/Yocto instance
is made up of a single 'distro' and many 'machines', so the distro
leaves no mark on the packages).

If all that is different are strictly the VCS revisions, you can use
branching but if someone introduces some other subtle difference, like
printer-X requires --enable-feature-x for package A and printer-Y
requires --disable-feature-x for the same package, then using different
machines is the only option to handle this. If you use branching instead
of distinct machines in this scenario, you will have to maintain
distinct build locations *and* package repositories for each branch, as
there is no way to tell package-A with --enable-feature-x from branch
printer-x from package-A with --disable-feature-x from branch printer-y.

Another reason not to use branches is that this increases the
maintenance burden when making changes to packages that are common
across the branches; from experience even with just a couple of extra
branches folk invariably forget to merge the changes everywhere they
should (or merge them into places they should not).

Using different bb files per printer seems like a good idea until you
try it, but you quickly discover it does not really work. The main
problem here is that now packages further down the line can no longer
depend on package-A, and have to depend on package-A-printer-X instead,
so you will need to have multiple versions of the dependent packages
too, and then of those depending on them, and so on ... You might think
that PROVIDES_virtual/package-A would be an answer here, but that really
only works for distinct machines, so you can specify PREFERRED_PROVIDER
or use COMPATIBLE_MACHINE.

> However, we'll likely have at least a hundred
> packages for which we need to set/manipulate revisions.  I would think that
> would get cumbersome, and in an organization the size of ours (500 or so
> developers across two sites), there's not really going to be one person or
> team who knows what should go in that file for a release.  Moreover, that
> still leaves the problem of all those developers needing to know there are
> at least two places in which their package revisions may be controlled.  Is
> your organization significantly smaller than that or are we doing something
> wrong?

I would agree that in this scenario it would best to maintain the source
revisions in the bb recipes themselves, it keeps people rom stepping on
each others toes and accidentally changing revisions for other packages
(which is easily done in automatic merge-conflict resolution gone wrong).

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

Re: [yocto] How do you release distros produced with Yocto? How should I?

2012-10-03 Thread Jerrod Peach

Tomas,

On Wed, Oct 3, 2012 at 3:59 AM, Tomas Frydrych
wrote:

> > However, we'll likely have at least a hundred
> > packages for which we need to set/manipulate revisions.  I would think
> that
> > would get cumbersome, and in an organization the size of ours (500 or so
> > developers across two sites), there's not really going to be one person
> or
> > team who knows what should go in that file for a release.  Moreover, that
> > still leaves the problem of all those developers needing to know there
> are
> > at least two places in which their package revisions may be controlled.
>  Is
> > your organization significantly smaller than that or are we doing
> something
> > wrong?
>
> I would agree that in this scenario it would best to maintain the source
> revisions in the bb recipes themselves, it keeps people rom stepping on
> each others toes and accidentally changing revisions for other packages
> (which is easily done in automatic merge-conflict resolution gone wrong).
>

Okay, so it sounds like my game plan should be to tag my metadata and
branch it only if necessary, i.e. if someone needs to change a BB
file. (That makes sense, of course, but we have had a long, storied history
of branching when it wasn't necessary in our build and library system, so
that is a change for us.)  Even if we branch our metadata, we'll be
creating a new tag once whatever modifications we need have been made.  Can
anyone see a better way to handle releases than that?

Kind regards,

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

[yocto] Correct procedure for rebuilding after a git pull

2012-10-03 Thread James Abernathy

So I'm looking for the right way to do this.  Here's the scenario.  I do a
complete build of the image core-image-cdv-media for the cedartrail
machine.  No changes from the basic BSP, except for the addition of my
meta-layer that include test audios and videos to help test the media
playback using gst-launch.  I'm tracking the latest Denzil branch.  So
everything works well to this point.

Now I see a bunch of patches pushed to Denzil branch and I want to test
them.  My build directory is untouched since the successful build before.
What do I do to rebuild my project to include the latest patches.  I've
tried things like "bitbake -c cleansstate core-image-cdv-media" before the
new "bitbake core-image-cdv-media" and I've tried just rebaking by itself.
Something always fails.  I've learned that to really test I have to
completely delete my build directory saving only my local.conf and
bblayer.conf.

Am I missing something or is a complete rebuild the only way to get the new
patches in and a successful build??

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

Re: [yocto] Correct procedure for rebuilding after a git pull

2012-10-03 Thread Burton, Ross

On 3 October 2012 14:05, James Abernathy  wrote:
> Now I see a bunch of patches pushed to Denzil branch and I want to test
> them.  My build directory is untouched since the successful build before.
> What do I do to rebuild my project to include the latest patches.  I've
> tried things like "bitbake -c cleansstate core-image-cdv-media" before the
> new "bitbake core-image-cdv-media" and I've tried just rebaking by itself.
> Something always fails.  I've learned that to really test I have to
> completely delete my build directory saving only my local.conf and
> bblayer.conf.

Just git pull ; bitbake should work -- all of the packages that
changed will rebuild without any problems.

That's the theory, and everyone who works against oe-core/poky master
does this ever day (including me).

Can you give an example of something that fails?

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

Re: [yocto] Correct procedure for rebuilding after a git pull

2012-10-03 Thread James Abernathy

On Wed, Oct 3, 2012 at 9:21 AM, Burton, Ross  wrote:

> On 3 October 2012 14:05, James Abernathy  wrote:
> > Now I see a bunch of patches pushed to Denzil branch and I want to test
> > them.  My build directory is untouched since the successful build before.
> > What do I do to rebuild my project to include the latest patches.  I've
> > tried things like "bitbake -c cleansstate core-image-cdv-media" before
> the
> > new "bitbake core-image-cdv-media" and I've tried just rebaking by
> itself.
> > Something always fails.  I've learned that to really test I have to
> > completely delete my build directory saving only my local.conf and
> > bblayer.conf.
>
> Just git pull ; bitbake should work -- all of the packages that
> changed will rebuild without any problems.
>
> That's the theory, and everyone who works against oe-core/poky master
> does this ever day (including me).
>
> Can you give an example of something that fails?
>


> The most recent patch update to Denzil included some Cedartrail BSP
> updates to the CDV PVR driver.  I was traveling last week and I was out of
> date on my poky and meta-intel by at least that long.  Monday was the
> pull.  So when the rebuild happened, I got a cdv-pvr driver configuration
> error.  I didn't look into why because of my experience of this taking
> longer than a complete rebuild.  So I deleted the build directory and did
> the rebuild.  And I didn't get the error on the rebuild.  Everything still
> works fine for me on that BSP.


Jim A


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

Re: [yocto] Correct procedure for rebuilding after a git pull

2012-10-03 Thread Jack Mitchell

On 03/10/12 14:27, James Abernathy wrote:

On Wed, Oct 3, 2012 at 9:21 AM, Burton, Ross >wrote:

On 3 October 2012 14:05, James Abernathy mailto:jfaberna...@gmail.com>> wrote:
> Now I see a bunch of patches pushed to Denzil branch and I want
to test
> them.  My build directory is untouched since the successful
build before.
> What do I do to rebuild my project to include the latest
patches.  I've
> tried things like "bitbake -c cleansstate core-image-cdv-media"
before the
> new "bitbake core-image-cdv-media" and I've tried just rebaking
by itself.
> Something always fails.  I've learned that to really test I have to
> completely delete my build directory saving only my local.conf and
> bblayer.conf.

Just git pull ; bitbake should work -- all of the packages that
changed will rebuild without any problems.

That's the theory, and everyone who works against oe-core/poky master
does this ever day (including me).

Can you give an example of something that fails?

The most recent patch update to Denzil included some Cedartrail
BSP updates to the CDV PVR driver.  I was traveling last week and
I was out of date on my poky and meta-intel by at least that
long.  Monday was the pull.  So when the rebuild happened, I got a
cdv-pvr driver configuration error.  I didn't look into why
because of my experience of this taking longer than a complete
rebuild.  So I deleted the build directory and did the rebuild. 
And I didn't get the error on the rebuild.  Everything still works

fine for me on that BSP.

Jim A

Ross

I also use this work flow. If something goes wrong with a particular 
package then I will -c cleansstate failed-package and then start the 
build again. This usually fixes it.

Regards,

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

--

  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  http://www.embed.me.uk

--

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

Re: [yocto] Correct procedure for rebuilding after a git pull

2012-10-03 Thread Burton, Ross

On 3 October 2012 14:37, Jack Mitchell  wrote:
> I also use this work flow. If something goes wrong with a particular package
> then I will -c cleansstate failed-package and then start the build again.
> This usually fixes it.

Bringing the failure on on the list / bug would be appreciated,
everything *should* rebuild cleanly (especially with recent changes in
master).

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

Re: [yocto] Correct procedure for rebuilding after a git pull

2012-10-03 Thread Jack Mitchell


On 03/10/12 14:37, Burton, Ross wrote:

On 3 October 2012 14:37, Jack Mitchell  wrote:

I also use this work flow. If something goes wrong with a particular package
then I will -c cleansstate failed-package and then start the build again.
This usually fixes it.

Bringing the failure on on the list / bug would be appreciated,
everything *should* rebuild cleanly (especially with recent changes in
master).

Ross


I'll bear that in mind.

I believe it was ext2fs that failed earlier today on my production build 
machine. Again a -c cleansstate fixed it and I didn't investigate so I 
can't add anything else!


Regards,

--

  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  http://www.embed.me.uk

--

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

Re: [yocto] Can't fetch git SRC_URI via HTTP

2012-10-03 Thread Khem Raj

On Wed, Oct 3, 2012 at 12:39 AM, Julian Scheel  wrote:
> Am Dienstag, den 02.10.2012, 23:52 +0200 schrieb Martin Jansa:
>> On Tue, Oct 02, 2012 at 11:38:08PM +0200, Julian Scheel wrote:
>> >
>> > Am 02.10.2012 um 23:22 schrieb Martin Jansa :
>> >
>> > > On Tue, Oct 02, 2012 at 05:17:23PM -0400, Evade Flow wrote:
>> > >> I'm trying to build core-image-sato for my Pandaboard ES, following the
>> > >> instructions posted here:
>> > >>
>> > >>  - http://maniacbug.wordpress.com/2012/08/03/pandayocto/
>> > >>
>> > >> Thus, my OE build configuration looks like this:
>> > >>
>> > >>> OE Build Configuration:
>> > >>> BB_VERSION= "1.15.2"
>> > >>> TARGET_ARCH   = "arm"
>> > >>> TARGET_OS = "linux-gnueabi"
>> > >>> MACHINE   = "pandaboard"
>> > >>> DISTRO= "poky"
>> > >>> DISTRO_VERSION= "1.2.1"
>> > >>> TUNE_FEATURES = "armv7a vfp neon cortexa9"
>> > >>> TARGET_FPU= "vfp-neon"
>> > >>> meta
>> > >>> meta-yocto= "denzil:65ffa7395055f7e012cb973f63f92380828eed0d"
>> > >>> meta-ti   = 
>> > >>> "(nobranch):30fb40ebc13614a74c2e237927c60ac43e01d1bc"
>> > >>
>> > >> I have these lines in my .gitconfig:
>> > >>
>> > >>> [http]
>> > >>>proxy=http://user:pas...@usaprox.lightning.com:8080
>> > >>
>> > >> so I'd expect URLs like this one (from the meta-ti layer's
>> > >> linux-omap4_3.1.0.bb recipe) to work fine:
>> > >>
>> > >>> SRC_URI = 
>> > >>> "http://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git;protocol=git;branch=ti-ubuntu-3.1-1282
>> > >>>  \
>> > >
>> > > This url seems wrong, it should start with git:// if you want to clone
>> > > git repo.
>> > >
>> > > Because it starts with http:// normal fetch (like wget) was used so it
>> > > downloaded probably some http code (see that kernel-ubuntu.git file)
>> > > instead of any relevant source.
>> >
>> > I ran into the same issue a few days ago. It seems yocto only supports git 
>> > fetch
>> > through servers providing the repositories through the git protocol. A way 
>> > to use
>> > git repositories which are provided through http or https would be quite a 
>> > good
>> > thing to have.
>>
>> That's what protocol param does;
>>
>> Change that to
>> git://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git;protocol=http;branch=ti-ubuntu-3.1-1282
>> and you'll get git fetch over http protocol.
>
> Nice to know. Actually when I had this issue I tried it the other way
> round. Use a http url and set protocol to git...
> Is this noted somewhere in the documentation? I could not find it. I
> think it would be worth mentioning it in the yocto reference manual as
> this seems to be a quite common thing to struggle with.
>

I think Paul posted a patch where bitbake will spit out a good error
message about such usage


> -Julian
>
>
>>
>> > -Julian
>> >
>> > >
>> > >>>   
>> > >>> file://0001-Makefile.fwinst-fix-install-breakage-for-FW-images-r.patch 
>> > >>> \
>> > >>>   file://defconfig \
>> > >>>   "
>> > >>
>> > >> From what I can tell, though, bitbake isn't handling this SRC_URI
>> > >> correctly, and I get:
>> > >>
>> > >>> ERROR: Command Error: exit status: 1  Output:
>> > >>> Applying patch 
>> > >>> 0001-Makefile.fwinst-fix-install-breakage-for-FW-images-r.patch
>> > >>> patching file scripts/Makefile.fwinst
>> > >>> Hunk #1 FAILED at 27.
>> > >>> 1 out of 1 hunk FAILED -- rejects in file scripts/Makefile.fwinst
>> > >>> Patch 0001-Makefile.fwinst-fix-install-breakage-for-FW-images-r.patch 
>> > >>> does not apply (enforce with -f)
>> > >>> ERROR: Function failed: patch_do_patch
>> > >>
>> > >> If I examine the folder:
>> > >>
>> > >>  build/tmp/work/pandaboard-poky-linux-gnueabi/linux-omap4-3.1.0-r0
>> > >>
>> > >> I see that it contains no source code. It does, however, contain a file
>> > >> named 'kernel-ubuntu.git', whose content is exactly the same as you'd
>> > >> get if you typed:
>> > >>
>> > >>  wget http://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git
>> > >>
>> > >> This seems like a bug, possibly related to one of these:
>> > >>
>> > >>  - http://bugzilla.yoctoproject.org/show_bug.cgi?id=3119
>> > >>  - http://bugzilla.yoctoproject.org/show_bug.cgi?id=3175
>> > >>
>> > >>
>> > >> Maybe this has been fixed since denzil, but... everything I read about
>> > >> the current state of support for the Pandaboard suggests sticking with
>> > >> denzil/gcc 4.6. Is there some workaround I can use to get past this
>> > >> error?  Also, assuming these instructions worked for the author of the
>> > >> original blog post, I wonder what the difference is with my setup.
>> > >>
>> > >> Here are my mods to conf/local.conf, in case it's helpful:
>> > >>
>> > >>> MACHINE = "pandaboard"
>> > >>> BBMASK = "meta-ti/recipes-misc"
>> > >>> PACKAGE_CLASSES = "package_ipk"
>> > >>> CONNECTIVITY_CHECK_URIS=""
>> > >>> BB_GENERATE_MIRROR_TARBALLS = "1"
>> > >>> SOURCE_MIRROR_URL ?= "file:///home/evadeflow/projects/poky-mirror/"
>> > >>> INHERIT += "own-mirrors"
>> > >>

Re: [yocto] Can't fetch git SRC_URI via HTTP

2012-10-03 Thread Paul Eggleton

On Wednesday 03 October 2012 07:04:06 Khem Raj wrote:
> On Wed, Oct 3, 2012 at 12:39 AM, Julian Scheel  wrote:
> > Am Dienstag, den 02.10.2012, 23:52 +0200 schrieb Martin Jansa:
> >> On Tue, Oct 02, 2012 at 11:38:08PM +0200, Julian Scheel wrote:
> >> > Am 02.10.2012 um 23:22 schrieb Martin Jansa :
> >> > > On Tue, Oct 02, 2012 at 05:17:23PM -0400, Evade Flow wrote:
> >> > >> I'm trying to build core-image-sato for my Pandaboard ES, following
> >> > >> the
> >> > >> 
> >> > >> instructions posted here:
> >> > >>  - http://maniacbug.wordpress.com/2012/08/03/pandayocto/
> >> > >> 
> >> > >> Thus, my OE build configuration looks like this:
> >> > >>> OE Build Configuration:
> >> > >>> BB_VERSION= "1.15.2"
> >> > >>> TARGET_ARCH   = "arm"
> >> > >>> TARGET_OS = "linux-gnueabi"
> >> > >>> MACHINE   = "pandaboard"
> >> > >>> DISTRO= "poky"
> >> > >>> DISTRO_VERSION= "1.2.1"
> >> > >>> TUNE_FEATURES = "armv7a vfp neon cortexa9"
> >> > >>> TARGET_FPU= "vfp-neon"
> >> > >>> meta
> >> > >>> meta-yocto=
> >> > >>> "denzil:65ffa7395055f7e012cb973f63f92380828eed0d"
> >> > >>> meta-ti   =
> >> > >>> "(nobranch):30fb40ebc13614a74c2e237927c60ac43e01d1bc"
> >> > >> 
> >> > >> I have these lines in my .gitconfig:
> >> > >>> [http]
> >> > >>> 
> >> > >>>proxy=http://user:pas...@usaprox.lightning.com:8080
> >> > >> 
> >> > >> so I'd expect URLs like this one (from the meta-ti layer's
> >> > >> 
> >> > >> linux-omap4_3.1.0.bb recipe) to work fine:
> >> > >>> SRC_URI =
> >> > >>> "http://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git;pro
> >> > >>> tocol=git;branch=ti-ubuntu-3.1-1282 \>> > > 
> >> > > This url seems wrong, it should start with git:// if you want to
> >> > > clone
> >> > > git repo.
> >> > > 
> >> > > Because it starts with http:// normal fetch (like wget) was used so
> >> > > it
> >> > > downloaded probably some http code (see that kernel-ubuntu.git file)
> >> > > instead of any relevant source.
> >> > 
> >> > I ran into the same issue a few days ago. It seems yocto only supports
> >> > git fetch through servers providing the repositories through the git
> >> > protocol. A way to use git repositories which are provided through
> >> > http or https would be quite a good thing to have.
> >> 
> >> That's what protocol param does;
> >> 
> >> Change that to
> >> git://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git;protocol=htt
> >> p;branch=ti-ubuntu-3.1-1282 and you'll get git fetch over http protocol.
> > 
> > Nice to know. Actually when I had this issue I tried it the other way
> > round. Use a http url and set protocol to git...
> > Is this noted somewhere in the documentation? I could not find it. I
> > think it would be worth mentioning it in the yocto reference manual as
> > this seems to be a quite common thing to struggle with.
> 
> I think Paul posted a patch where bitbake will spit out a good error
> message about such usage

Indeed, in fact coincidentally I was just trying to find this thread in my 
cluttered inbox in order to reply to it mentioning that :)

Cheers,
Paul

-- 

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

Re: [yocto] Correct procedure for rebuilding after a git pull

2012-10-03 Thread Khem Raj

On Wed, Oct 3, 2012 at 6:42 AM, Jack Mitchell  wrote:
>
> I'll bear that in mind.
>

that will help a lot in fixing sstate

> I believe it was ext2fs that failed earlier today on my production build
> machine. Again a -c cleansstate fixed it and I didn't investigate so I can't
> add anything else!

cleansstate was a stop gap but should be avoided as much as possible.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can't fetch git SRC_URI via HTTP

2012-10-03 Thread Evade Flow

> I think Paul posted a patch where bitbake will spit out a good error
> message about such usage

Oops, better have a look at:

  - http://bugzilla.yoctoproject.org/show_bug.cgi?id=3214

I just created this... :-%


On Wed, Oct 3, 2012 at 10:07 AM, Paul Eggleton
 wrote:
> On Wednesday 03 October 2012 07:04:06 Khem Raj wrote:
>> On Wed, Oct 3, 2012 at 12:39 AM, Julian Scheel  wrote:
>> > Am Dienstag, den 02.10.2012, 23:52 +0200 schrieb Martin Jansa:
>> >> On Tue, Oct 02, 2012 at 11:38:08PM +0200, Julian Scheel wrote:
>> >> > Am 02.10.2012 um 23:22 schrieb Martin Jansa :
>> >> > > On Tue, Oct 02, 2012 at 05:17:23PM -0400, Evade Flow wrote:
>> >> > >> I'm trying to build core-image-sato for my Pandaboard ES, following
>> >> > >> the
>> >> > >>
>> >> > >> instructions posted here:
>> >> > >>  - http://maniacbug.wordpress.com/2012/08/03/pandayocto/
>> >> > >>
>> >> > >> Thus, my OE build configuration looks like this:
>> >> > >>> OE Build Configuration:
>> >> > >>> BB_VERSION= "1.15.2"
>> >> > >>> TARGET_ARCH   = "arm"
>> >> > >>> TARGET_OS = "linux-gnueabi"
>> >> > >>> MACHINE   = "pandaboard"
>> >> > >>> DISTRO= "poky"
>> >> > >>> DISTRO_VERSION= "1.2.1"
>> >> > >>> TUNE_FEATURES = "armv7a vfp neon cortexa9"
>> >> > >>> TARGET_FPU= "vfp-neon"
>> >> > >>> meta
>> >> > >>> meta-yocto=
>> >> > >>> "denzil:65ffa7395055f7e012cb973f63f92380828eed0d"
>> >> > >>> meta-ti   =
>> >> > >>> "(nobranch):30fb40ebc13614a74c2e237927c60ac43e01d1bc"
>> >> > >>
>> >> > >> I have these lines in my .gitconfig:
>> >> > >>> [http]
>> >> > >>>
>> >> > >>>proxy=http://user:pas...@usaprox.lightning.com:8080
>> >> > >>
>> >> > >> so I'd expect URLs like this one (from the meta-ti layer's
>> >> > >>
>> >> > >> linux-omap4_3.1.0.bb recipe) to work fine:
>> >> > >>> SRC_URI =
>> >> > >>> "http://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git;pro
>> >> > >>> tocol=git;branch=ti-ubuntu-3.1-1282 \>> > >
>> >> > > This url seems wrong, it should start with git:// if you want to
>> >> > > clone
>> >> > > git repo.
>> >> > >
>> >> > > Because it starts with http:// normal fetch (like wget) was used so
>> >> > > it
>> >> > > downloaded probably some http code (see that kernel-ubuntu.git file)
>> >> > > instead of any relevant source.
>> >> >
>> >> > I ran into the same issue a few days ago. It seems yocto only supports
>> >> > git fetch through servers providing the repositories through the git
>> >> > protocol. A way to use git repositories which are provided through
>> >> > http or https would be quite a good thing to have.
>> >>
>> >> That's what protocol param does;
>> >>
>> >> Change that to
>> >> git://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git;protocol=htt
>> >> p;branch=ti-ubuntu-3.1-1282 and you'll get git fetch over http protocol.
>> >
>> > Nice to know. Actually when I had this issue I tried it the other way
>> > round. Use a http url and set protocol to git...
>> > Is this noted somewhere in the documentation? I could not find it. I
>> > think it would be worth mentioning it in the yocto reference manual as
>> > this seems to be a quite common thing to struggle with.
>>
>> I think Paul posted a patch where bitbake will spit out a good error
>> message about such usage
>
> Indeed, in fact coincidentally I was just trying to find this thread in my
> cluttered inbox in order to reply to it mentioning that :)
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> ___
> 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] [PATCH] psplash: Add custom bar image and color options.

2012-10-03 Thread Julian Scheel

To make more use of the option to overwrite the splash image this adds the
possibility to overwrite the bar image as well as the color header file to
make a consistent splash screen even when a different background color is
desired.

Signed-off-by: Julian Scheel 
---
 meta/recipes-core/psplash/psplash_git.bb | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/psplash/psplash_git.bb 
b/meta/recipes-core/psplash/psplash_git.bb
index 7c033e7..85c239c 100644
--- a/meta/recipes-core/psplash/psplash_git.bb
+++ b/meta/recipes-core/psplash/psplash_git.bb
@@ -11,9 +11,15 @@ PR = "r5"
 
 SRC_URI = "git://git.yoctoproject.org/${BPN};protocol=git \
file://psplash-init \
-   ${SPLASH_IMAGES}"
+   ${SPLASH_IMAGES} \
+   ${BAR_IMAGE} \
+   ${COLORS}"
 
+# Overwrite these to use custom splash images (multiple possible),
+# a custom bar image (only one possible) and a custom color header file.
 SPLASH_IMAGES = "file://psplash-poky-img.h;outsuffix=default"
+BAR_IMAGE = ""
+COLORS = ""
 
 python __anonymous() {
 oldpkgs = d.getVar("PACKAGES", True).split()
@@ -69,6 +75,20 @@ ALTERNATIVE_LINK_NAME[psplash] = "${bindir}/psplash"
 python do_compile () {
 import shutil, commands
 
+# update the bar file
+barimage = d.getVar('BAR_IMAGE', True)
+if barimage:
+fetcher = bb.fetch2.Fetch([barimage], d)
+flocal = fetcher.localpath(barimage)
+shutil.copyfile(flocal, "psplash-bar-img.h");
+
+# update the colors file
+colors = d.getVar('COLORS', True)
+if colors:
+fetcher = bb.fetch2.Fetch([colors], d)
+flocal = fetcher.localpath(colors)
+shutil.copyfile(flocal, "psplash-colors.h");
+
 # Build a separate executable for each splash image
 destfile = "%s/psplash-poky-img.h" % d.getVar('S', True)
 localfiles = d.getVar('SPLASH_LOCALPATHS', True).split()
-- 
1.7.12.2

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

[yocto] Yocto Project 1.4 Planning Process

2012-10-03 Thread Richard Purdie

Whilst I appreciate people are concentrating on 1.3, we do also need to
think about planning 1.4.

https://wiki.yoctoproject.org/wiki/Yocto_1.4_Features

is seeded with the 1.4/Future targeted enhancement requests from the
bugzilla. This is currently unsorted/unprocessed other than some guesses
from the triage team and I doubt we can actually do everything listed
there but there are plenty of good ideas.

If people can see anything that is missing from those lists which they
think is something we should consider working on in 1.4, I'd recommend
filing enhancement requests in the bugzilla so they're included in the
list.

In about a week's time, I'll be sitting down with this list and talking
with the project stakeholders about what resources are available and
which tasks we could use those resources on and generally figure out
what we're going to target in 1.4. If there are resources available I'm
unaware of, please do talk to me btw! :)

Equally, I'd also ask that if there are things you're planning to do in
the 1.4 timescale, please indicate this with an entry in the bugzilla
which you take ownership of, give a rough time estimation/ETA of and set
the status to ACCEPTED. This tells others that you're working on
something and gives us an idea of what changes to expect and when. This
is useful for planning things like demos and the beta testing.

Questions are more than welcome, as is feedback about this process.

Cheers,

Richard




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

Re: [yocto] Cannot do atom-pc build with meta-cedartrail

2012-10-03 Thread Mihai Lindner

On 2012-10-02 19:02, Tom Zanussi wrote:
> On Tue, 2012-10-02 at 18:00 +0300, Mihai Lindner wrote:
>> On 2012-09-29 23:50, Ross Burton wrote:
>>> On Thursday, 27 September 2012 at 18:07, Tom Zanussi wrote:
 Yeah, looks like the other SRC_URIs do that, but it's missing from that
 SRC_URI - I just pushed a fix for this one to meta-intel/master.
>>>
>>> Thanks Tom, I've been frequently flipping between atom-pc and cedartrail 
>>> and this was getting annoying.
>>>
>>> Ross 
>>>
>>>
>>>
>>
>> Unfortunately this change breaks SRC_URI appends, discarded or overwritten; 
>> e.g. adding meta-tlk brings no change to SRC_URI.
>>
> 
> It shouldn't though, since the application of the meta-tlk SRC_URI
> bbappend should follow the SRC_URI assignment in the cedartrail
> bbappend.  On the other hand, the layer priorities don't seem to be
> right - meta-cedartrail is supposed to have a priority of 6, but it
> doesn't actually seem to:
> 
> BBFILE_PRIORITY_cedartrail = "6" 
> 
> [trz@empanada build]$ bitbake-layers show_layers
> layer path  priority
> ==
> meta  /home/trz/yocto/crownbay-test/meta5
> meta-yocto/home/trz/yocto/crownbay-test/meta-yocto  5
> meta-yocto-bsp/home/trz/yocto/crownbay-test/meta-yocto-bsp  5
> meta-intel/home/trz/yocto/crownbay-test/meta-intel  5
> meta-cedartrail   
> /home/trz/yocto/crownbay-test/meta-intel/meta-cedartrail  5
> meta-tlk  /home/trz/yocto/crownbay-test/meta-intel/meta-tlk  5
> 
> On the other hand, meta-tlk does follow meta-cedatrail in the parse
> order so should append to the SRC_URI...
> 
> Tom
> 
> 
> 

Submitted bug #3217 https://bugzilla.yoctoproject.org/show_bug.cgi?id=3217
For the records.

Cheers,

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

[yocto] [PATCH] psplash: Add custom bar image and color options.

2012-10-03 Thread Aws Ismail


I have sent this a about two months ago but did not get a reply.
So I am sending it again to see if anyone has comments on it.

Thanks.

Aws\


-
Author: Aws Ismail 
Date:   Thu Aug 16 11:06:13 2012 -0400

Use correct blue offset value for BGR888

fs->blue_offset should be compared to 16 instead
of 8 in order to detect BGR.

Credit goes to Ulrich Feichter 
for detecting this.

Signed-off-by: Aws Ismail 
---
 psplash-fb.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/psplash-fb.c b/psplash-fb.c
index 71740cd..f65d67e 100644
--- a/psplash-fb.c
+++ b/psplash-fb.c
@@ -185,7 +185,7 @@ psplash_fb_new (int angle)
  fb->rgbmode = RGB888;
   } else if (fb->red_offset == 0 && fb->red_length == 8 &&
   fb->green_offset == 8 && fb->green_length == 8 &&
-  fb->blue_offset == 8 && fb->blue_length == 8) {
+  fb->blue_offset == 16 && fb->blue_length == 8) {
  fb->rgbmode = BGR888;
   } else {
  fb->rgbmode = GENERIC;

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

[yocto] [PATCH] psplash: use correct blue offset value for BGR888

2012-10-03 Thread Aws Ismail

Apologies. Used the wrong subject line. It is corrected now.

Aws\

 Original Message 
Subject:[yocto] [PATCH] psplash: Add custom bar image and color options.
Date:   Wed, 3 Oct 2012 12:57:40 -0400
From:   Aws Ismail 
Reply-To:   
Organization:   Wind River Systems
To: 

I have sent this a about two months ago but did not get a reply.
So I am sending it again to see if anyone has comments on it.

Thanks.

Aws\

-
Author: Aws Ismail 
Date:   Thu Aug 16 11:06:13 2012 -0400

Use correct blue offset value for BGR888

fs->blue_offset should be compared to 16 instead
of 8 in order to detect BGR.

Credit goes to Ulrich Feichter 
for detecting this.

Signed-off-by: Aws Ismail 
---
 psplash-fb.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/psplash-fb.c b/psplash-fb.c
index 71740cd..f65d67e 100644
--- a/psplash-fb.c
+++ b/psplash-fb.c
@@ -185,7 +185,7 @@ psplash_fb_new (int angle)
  fb->rgbmode = RGB888;
   } else if (fb->red_offset == 0 && fb->red_length == 8 &&
   fb->green_offset == 8 && fb->green_length == 8 &&
-  fb->blue_offset == 8 && fb->blue_length == 8) {
+  fb->blue_offset == 16 && fb->blue_length == 8) {
  fb->rgbmode = BGR888;
   } else {
  fb->rgbmode = GENERIC;

___
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] Yocto Project Technical Team Meeting

2012-10-03 Thread Liu, Song

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="Liu, Song":MAILTO:song@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Anders Da
 rander':MAILTO:and...@chargestorm.se
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Barros Pen
 a, Belen":MAILTO:belen.barros.p...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Bodke, Kis
 hore K":MAILTO:kishore.k.bo...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Bruce Ash
 field':MAILTO:bruce.ashfi...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Daniel Ca
 uchy':MAILTO:dcau...@mvista.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'deVries, 
 Alex'":MAILTO:alex.devr...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Dixon, Br
 ad'":MAILTO:brad_di...@mentor.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Dmytriyenk
 o, Denys":MAILTO:de...@ti.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Erway, Tra
 cey M":MAILTO:tracey.m.er...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Flanagan, 
 Elizabeth":MAILTO:elizabeth.flana...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Hart, Darr
 en":MAILTO:darren.h...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Hatle, Ma
 rk'":MAILTO:mark.ha...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Jeremy Pu
 hlman':MAILTO:jpuhl...@gmail.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Kridner, J
 ason":MAILTO:j...@ti.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Li, Susie":
 MAILTO:susie...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Lieu.Ta@w
 indriver.com':MAILTO:'lieu...@windriver.com'
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Lock, Josh
 ua":MAILTO:joshua.l...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'McCombe, 
 Kevin'":MAILTO:kevin.mcco...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Moeller, T
 horsten":MAILTO:thorsten.moel...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Sanjay Rai
 na:MAILTO:sra...@mvista.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Osier-mixo
 n, Jeffrey":MAILTO:jeffrey.osier-mi...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Polk, Jef
 frey'":MAILTO:jeff.p...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Purdie, Ri
 chard":MAILTO:richard.pur...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Ranslam, 
 Rob'":MAILTO:rob.rans...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Saxena, Ra
 hul":MAILTO:rahul.sax...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Stewart, D
 avid C":MAILTO:david.c.stew...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Wang, Shan
 e":MAILTO:shane.w...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Wold, Saul"
 :MAILTO:saul.w...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Zanussi, T
 om":MAILTO:tom.zanu...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Zhang, Jes
 sica":MAILTO:jessica.zh...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Rifenbark,
  Scott M":MAILTO:scott.m.rifenb...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Hudson, S
 ean'":MAILTO:sean_hud...@mentor.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Serban, La
 urentiu":MAILTO:laurentiu.ser...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Petrisor, 
 Ileana":MAILTO:ileana.petri...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Damian, Al
 exandru":MAILTO:alexandru.dam...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Burton, Ro
 ss":MAILTO:ross.bur...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Mueller, R
 obert":MAILTO:robert.muel...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Arce Moren
 o, Abraham":MAILTO:abraham.arce.mor...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Ravi Vomp
 olu':MAILTO:ravi.vomp...@mathworks.com
ATTENDEE;ROL

[yocto] Yocto Project Technical Team Meeting

2012-10-03 Thread Liu, Song

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="Liu, Song":MAILTO:song@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Rifenbark,
  Scott M":MAILTO:scott.m.rifenb...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Petrisor, 
 Ileana":MAILTO:ileana.petri...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Damian, Al
 exandru":MAILTO:alexandru.dam...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Calles Pal
 acios, Osvaldo":MAILTO:osvaldo.calles.palac...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Patel, Key
 ur R":MAILTO:keyur.r.pa...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Anders Da
 rander':MAILTO:and...@chargestorm.se
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Barros Pen
 a, Belen":MAILTO:belen.barros.p...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Bodke, Kis
 hore K":MAILTO:kishore.k.bo...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Bruce Ash
 field':MAILTO:bruce.ashfi...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Daniel Ca
 uchy':MAILTO:dcau...@mvista.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'deVries, 
 Alex'":MAILTO:alex.devr...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Dixon, Br
 ad'":MAILTO:brad_di...@mentor.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Dmytriyenk
 o, Denys":MAILTO:de...@ti.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Erway, Tra
 cey M":MAILTO:tracey.m.er...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Flanagan, 
 Elizabeth":MAILTO:elizabeth.flana...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Hart, Darr
 en":MAILTO:darren.h...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Hatle, Ma
 rk'":MAILTO:mark.ha...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Jeremy Pu
 hlman':MAILTO:jpuhl...@gmail.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Kridner, J
 ason":MAILTO:j...@ti.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Li, Susie":
 MAILTO:susie...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Lieu.Ta@w
 indriver.com':MAILTO:'lieu...@windriver.com'
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Lock, Josh
 ua":MAILTO:joshua.l...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'McCombe, 
 Kevin'":MAILTO:kevin.mcco...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Moeller, T
 horsten":MAILTO:thorsten.moel...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Sanjay Rai
 na:MAILTO:sra...@mvista.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Osier-mixo
 n, Jeffrey":MAILTO:jeffrey.osier-mi...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Polk, Jef
 frey'":MAILTO:jeff.p...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Purdie, Ri
 chard":MAILTO:richard.pur...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Ranslam, 
 Rob'":MAILTO:rob.rans...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Saxena, Ra
 hul":MAILTO:rahul.sax...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Stewart, D
 avid C":MAILTO:david.c.stew...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Wang, Shan
 e":MAILTO:shane.w...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Wold, Saul"
 :MAILTO:saul.w...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Zanussi, T
 om":MAILTO:tom.zanu...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Zhang, Jes
 sica":MAILTO:jessica.zh...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Hudson, S
 ean'":MAILTO:sean_hud...@mentor.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Serban, La
 urentiu":MAILTO:laurentiu.ser...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Burton, Ro
 ss":MAILTO:ross.bur...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Mueller, R
 obert":MAILTO:robert.muel...@intel.com
ATTEN

[yocto] The BitBake equivalent of "Hello, World!"

2012-10-03 Thread Patrick Turley

I'll start with my question (so you can decide whether you care to read
the rest):


What is the BitBake equivalent of "Hello, World!?"

Specifically, what is the minimum project structure that
correctly describes a single layer and a single recipe?


--


I'm trying to understand Yocto and BitBake thoroughly. As a start, I tried
to construct a "minimal" BitBake project, with no Yocto content.

I began by running BitBake in an empty directory and fixing each error in
turn. Eventually, I was able run BitBake without errors -- even though it
didn't actually *do* anything (which was fine).

After that, I created a single layer, and that worked fine.

Most recently, I tried to create a single recipe within my one layer. I'm
having problems I don't know how to solve.

At the bottom of this message, I show the full structure of my tree and
the contents of all the files. Since the project is "minimal," there isn't
much to show.

>From within the "build" directory of my project, I ran BitBake like this:


$ ../BitBake/bin/bitbake
Nothing to do.  Use 'bitbake world' to build everything,
or run 'bitbake --help' for usage information.


That's what I expected. Then, I tried to examine the layers:


$ ../BitBake/bin/bitbake-layers show-layers
layerpathpriority
=
LayerA   /home/pturley/Workspace/woohoo/LayerA   0


That's also what I expected. Things went wrong when I tried to examine the
recipes:


$ ../BitBake/bin/bitbake-layers show-recipes
Parsing recipes..$


That's wrong. I expected something like this:


Parsing recipes..done.
=== Available recipes: ===
a:
  LayerA   1


At first, "base.bbclass" was empty so, on a hunch, I added this:


do_hello() {
echo Hello
}

addtask hello


That changed the output to this:


$ ../BitBake/bin/bitbake-layers show-recipes
Parsing recipes..done.
=== Available recipes: ===
a:
  ?1


This is still wrong, but better (though I can't explain why).

At this point I thought it best to look for experts. I don't need
hand-holding - but I *do* need substantive, accurate hints. If you have
any, I'd be grateful.


--


Here is the tree of files in my "minimal" project, along with the contents
of those file:

/home/pturley/Workspace/woohoo
|
+-- build
|   |
|   +-- classes
|   |   |
|   |   +-- base.bbclass
|   |
|   | +---
|   | | do_hello() {
|   | | echo Hello
|   | | }
|   | |
|   | | addtask hello
|   | +---
|   |
|   +-- conf
|   |
|   +-- bblayers.conf
|   |
|   | +---
|   | | BBLAYERS ?= " \
|   | |   /home/pturley/Workspace/woohoo/LayerA \
|   | |   "
|   | +---
|   |
|   +-- bitbake.conf
|
| +---
| | CACHE = "${TOPDIR}/cache"
| +---
|
+-- LayerA
|   |
|   +-- a.bb
|   |
|   | +---
|   | | PN = 'a'
|   | | PV = '1'
|   | +---
|   |
|   +-- conf
|   |
|   +-- layer.conf
|
| +---
| | BBPATH .= ":${LAYERDIR}"
| | BBFILES += "${LAYERDIR}/*.bb"
| +---
|
+-- BitBake ...

The BitBake directory origin is:

http://git.openembedded.org/bitbake/

I have the 1.15.2 tag checked out, which is what
Yocto denzil uses.

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

Re: [yocto] The BitBake equivalent of "Hello, World!"

2012-10-03 Thread Patrick Turley

In my previous message, some of the indentation in the representation of
my file tree was wrong (because we're using Outlook, which destroy all
indentation when you paste it into an e-mail message). The errors are
small, but I want to avoid annoying anyone who might think I don't even
have the file tree constructed correctly.

The following is accurate:

>/home/pturley/Workspace/woohoo
>|
>+-- build
>|   |
>|   +-- classes
>|   |   |
>|   |   +-- base.bbclass
>|   |
>|   | +---
>|   | | do_hello() {
>|   | | echo Hello
>|   | | }
>|   | |
>|   | | addtask hello
>|   | +---
>|   |
>|   +-- conf
>|   |
>|   +-- bblayers.conf
>|   |
>|   | +---
>|   | | BBLAYERS ?= " \
>|   | |   /home/pturley/Workspace/woohoo/LayerA \
>|   | |   "
>|   | +---
>|   |
>|   +-- bitbake.conf
>|
>| +---
>| | CACHE = "${TOPDIR}/cache"
>| +---
>|
>+-- LayerA
>|   |
>|   +-- a.bb
>|   |
>|   | +---
>|   | | PN = 'a'
>|   | | PV = '1'
>|   | +---
>|   |
>|   +-- conf
>|   |
>|   +-- layer.conf
>|
>| +---
>| | BBPATH .= ":${LAYERDIR}"
>| | BBFILES += "${LAYERDIR}/*.bb"
>| +---
>|
>+-- BitBake ...
>
>The BitBake directory origin is:
>
>http://git.openembedded.org/bitbake/
>
>I have the 1.15.2 tag checked out, which is what
>Yocto denzil uses.

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

Re: [yocto] The BitBake equivalent of "Hello, World!"

2012-10-03 Thread Rudolf Streif

Hi Patrick,

I think I understand what you are looking for. I created this Bitbake Hello
World for a training class. It just uses 'raw' Bitbake and a very basic
recipe to build the Nano editor (including download from the project site).

You need to have a couple of things in place to make this work. I got to
run but I will get back to it and post it.

:rjs

On Wed, Oct 3, 2012 at 3:56 PM, Patrick Turley
wrote:

> In my previous message, some of the indentation in the representation of
> my file tree was wrong (because we're using Outlook, which destroy all
> indentation when you paste it into an e-mail message). The errors are
> small, but I want to avoid annoying anyone who might think I don't even
> have the file tree constructed correctly.
>
> The following is accurate:
>
> >/home/pturley/Workspace/woohoo
> >|
> >+-- build
> >|   |
> >|   +-- classes
> >|   |   |
> >|   |   +-- base.bbclass
> >|   |
> >|   | +---
> >|   | | do_hello() {
> >|   | | echo Hello
> >|   | | }
> >|   | |
> >|   | | addtask hello
> >|   | +---
> >|   |
> >|   +-- conf
> >|   |
> >|   +-- bblayers.conf
> >|   |
> >|   | +---
> >|   | | BBLAYERS ?= " \
> >|   | |   /home/pturley/Workspace/woohoo/LayerA \
> >|   | |   "
> >|   | +---
> >|   |
> >|   +-- bitbake.conf
> >|
> >| +---
> >| | CACHE = "${TOPDIR}/cache"
> >| +---
> >|
> >+-- LayerA
> >|   |
> >|   +-- a.bb
> >|   |
> >|   | +---
> >|   | | PN = 'a'
> >|   | | PV = '1'
> >|   | +---
> >|   |
> >|   +-- conf
> >|   |
> >|   +-- layer.conf
> >|
> >| +---
> >| | BBPATH .= ":${LAYERDIR}"
> >| | BBFILES += "${LAYERDIR}/*.bb"
> >| +---
> >|
> >+-- BitBake ...
> >
> >The BitBake directory origin is:
> >
> >http://git.openembedded.org/bitbake/
> >
> >I have the 1.15.2 tag checked out, which is what
> >Yocto denzil uses.
>
> ___
> 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] [Poky] Baking core-image-minimal with Poky from Master fails with libffi dependency

2012-10-03 Thread Rudolf Streif

I checked out Poky from Master and tried to build core-image-minimal.
do_rootfs failed on the libffi dependency [1]. Is that known/expected?

:rjs



[1]

bitbake core-image-minimal
Loading cache: 100%
||
ETA:  00:00:00
Loaded 1131 entries from dependency cache.

Build Configuration:
BB_VERSION= "1.16.0"
TARGET_ARCH   = "i586"
TARGET_OS = "linux"
MACHINE   = "qemux86"
DISTRO= "poky"
DISTRO_VERSION= "1.2+snapshot-20121003"
TUNE_FEATURES = "m32 i586"
TARGET_FPU= ""
meta
meta-yocto
meta-yocto-bsp= "master:09aaad16be178bd675750aa6cfe7a373d7c9a8a6"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Function failed: do_rootfs (see
/data/Develop/yocto-develop/x86/tmp/work/qemux86-poky-linux/core-image-minimal-1.0-r0/temp/log.do_rootfs.29559
for further information)
ERROR: Logfile of failure stored in:
/data/Develop/yocto-develop/x86/tmp/work/qemux86-poky-linux/core-image-minimal-1.0-r0/temp/log.do_rootfs.29559
Log data follows:
| DEBUG: Executing shell function do_rootfs
| Generating solve db for
/data/Develop/yocto-develop/x86/tmp/deploy/rpm/qemux86...
| Generating solve db for
/data/Develop/yocto-develop/x86/tmp/deploy/rpm/i586...
| Generating solve db for
/data/Develop/yocto-develop/x86/tmp/deploy/rpm/all...
| Generating solve db for
/data/Develop/yocto-develop/x86/tmp/deploy/rpm/all...
| Processing packagegroup-core-tools-profile...
| Processing packagegroup-core-boot...
| Processing packagegroup-core-tools-testapps...
| Processing packagegroup-core-tools-debug...
| error: Failed dependencies:
|   libffi.so.5 is needed by lttng-viewer-0.12.38-r3.i586
|   libffi.so.5 is needed by
clutter-box2d-0.12.1+git1+de5452e56b537a11fd7f9453d048ff4b4793b5a2-r1.qemux86
|   libffi.so.5 is needed by
libowl-av0-0.1+git1+03030c41ea578cfa74a2ffceb875675b248318ae-r3.i586
|   libffi.so.5 is needed by libclutter-glx-1.0-0-1.8.4-r2.i586
| ERROR: Function failed: do_rootfs (see
/data/Develop/yocto-develop/x86/tmp/work/qemux86-poky-linux/core-image-minimal-1.0-r0/temp/log.do_rootfs.29559
for further information)
ERROR: Task 7 (/data/Develop/yocto-develop/poky/meta/recipes-core/images/
core-image-minimal.bb, do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 3891 tasks of which 3890 didn't need to be
rerun and 1 failed.
No currently running tasks (3890 of 3892)

Summary: 1 task failed:
  /data/Develop/yocto-develop/poky/meta/recipes-core/images/
core-image-minimal.bb, do_rootfs
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] 1.3_M5.rc3 images

2012-10-03 Thread Flanagan, Elizabeth

All,

The autobuilder is currently building 1.3_M5.rc3. It is being built
from what will be the 1.3 release branch "danny". We've seen a few
issues so far, specifically a failure on nightly-x86-64 sanity tests
with conman and shutdown, an odd failure in the non-gplv3 buildout
(which I am running again) and for the intel QA team, failures for
both fri2 emgd and non-emgd, crownbay with emgd and sys940x.

The next (and hopefully last) release candidate will be generated this
coming Wednesday. Please view any failures for rc3 and get patches in
if they're needed/work with me if the failures are due to changes
needed within the autobuilder.

The images are being generated from the HEAD of danny and have already
had the DISTRO_NAME, DISTRO_VERSION, SDK_VENDOR and build appliance
SRCREV flipped in preparation for release. All build artifacts should
be available by 8pm Pacific Daylight Time at:

Location: http://autobuilder.yoctoproject.org/pub/nightly/20121003-4
Branch: danny
Tag: 1.3_M5.rc3

Commits:
poky: 86c9aa8081f107420cd3763d0566d779daddc2b1
eclipse-poky: aa38f8b19c921cce2f73647d8aeb7e355c868b56
meta-qt3: c86fb1727ae09526c442ec29fffde3f010aa70eb
meta-intel: 2c1e927fa99abe47865a03cf661d4757ff3147c6


-- 
Elizabeth Flanagan
Yocto Project
Build and Release
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 1/3] meta-crownbay: add 3.4 rt support

2012-10-03 Thread tom . zanussi

From: Tom Zanussi 

Add the -rt version of linux-yocto-3.4.

Signed-off-by: Tom Zanussi 
---
 .../recipes-kernel/linux/linux-yocto-rt_3.4.bbappend | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.4.bbappend

diff --git a/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.4.bbappend 
b/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.4.bbappend
new file mode 100644
index 000..2049076
--- /dev/null
+++ b/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.4.bbappend
@@ -0,0 +1,16 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
+KMACHINE_crownbay-noemgd = "crownbay"
+
+COMPATIBLE_MACHINE_crownbay = "crownbay"
+KMACHINE_crownbay = "crownbay"
+
+# Update the following to use a different BSP branch or meta SRCREV
+#KBRANCH_crownbay-noemgd = "standard/preempt-rt/base"
+#SRCREV_machine_pn-linux-yocto-rt_crownbay-noemgd ?= 
+#SRCREV_meta_pn-linux-yocto-rt_crownbay-noemgd ?= 
+
+#KBRANCH_crownbay = "standard/preempt-rt/base"
+#SRCREV_machine_pn-linux-yocto-rt_crownbay ?= 
+#SRCREV_meta_pn-linux-yocto-rt_crownbay ?= 
-- 
1.7.11.4

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

[yocto] [PATCH 0/3] meta-intel: crownbay cleanups

2012-10-03 Thread tom . zanussi

From: Tom Zanussi 

This patchset removes 3.0 kernel support and adds 3.4-rt for crownbay.

The following changes since commit 2c1e927fa99abe47865a03cf661d4757ff3147c6:

  gst-va-intel: incude gst-ffmpeg only if 'commercial' is whitelisted 
(2012-10-02 22:56:20 -0500)

are available in the git repository at:

  git://git.yoctoproject.org/meta-intel-contrib.git 
tzanussi/crownbay-1.3-cleanups
  
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/log/?h=tzanussi/crownbay-1.3-cleanups

Tom Zanussi (3):
  meta-crownbay: add 3.4 rt support
  meta-crownbay: remove -rt smp options from recipe-space
  meta-crownbay: remove 3.0 kernel support

 .../recipes-kernel/linux/linux-yocto-rt_3.2.bbappend|  4 
 ...octo-rt_3.0.bbappend => linux-yocto-rt_3.4.bbappend} |  8 ++--
 .../recipes-kernel/linux/linux-yocto_3.0.bbappend   | 17 -
 3 files changed, 2 insertions(+), 27 deletions(-)
 rename meta-crownbay/recipes-kernel/linux/{linux-yocto-rt_3.0.bbappend => 
linux-yocto-rt_3.4.bbappend} (69%)
 delete mode 100644 meta-crownbay/recipes-kernel/linux/linux-yocto_3.0.bbappend

-- 
1.7.11.4

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

[yocto] [PATCH 2/3] meta-crownbay: remove -rt smp options from recipe-space

2012-10-03 Thread tom . zanussi

From: Tom Zanussi 

SMP support is now configured in the kernel branch, remove it from
recipe-space.

Signed-off-by: Tom Zanussi 
---
 meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend | 4 
 1 file changed, 4 deletions(-)

diff --git a/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend 
b/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
index dee9bce..55537fd 100644
--- a/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
+++ b/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
@@ -3,13 +3,9 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
 COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
 KMACHINE_crownbay-noemgd = "crownbay"
 
-KERNEL_FEATURES_append_crownbay-noemgd += " cfg/smp.scc"
-
 COMPATIBLE_MACHINE_crownbay = "crownbay"
 KMACHINE_crownbay = "crownbay"
 
-KERNEL_FEATURES_append_crownbay += " cfg/smp.scc"
-
 # Update the following to use a different BSP branch or meta SRCREV
 #KBRANCH_crownbay-noemgd = "yocto/standard/preempt-rt/base"
 #SRCREV_machine_pn-linux-yocto-rt_crownbay-noemgd ?= 
-- 
1.7.11.4

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

[yocto] [PATCH 3/3] meta-crownbay: remove 3.0 kernel support

2012-10-03 Thread tom . zanussi

From: Tom Zanussi 

There's no need to support linux-yocto-3.0 for crownbay any more, so
remove the 3.0 bbappends.

Signed-off-by: Tom Zanussi 
---
 .../recipes-kernel/linux/linux-yocto-rt_3.0.bbappend | 20 
 .../recipes-kernel/linux/linux-yocto_3.0.bbappend| 17 -
 2 files changed, 37 deletions(-)
 delete mode 100644 
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
 delete mode 100644 meta-crownbay/recipes-kernel/linux/linux-yocto_3.0.bbappend

diff --git a/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend 
b/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
deleted file mode 100644
index dee9bce..000
--- a/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
+++ /dev/null
@@ -1,20 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-
-COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
-KMACHINE_crownbay-noemgd = "crownbay"
-
-KERNEL_FEATURES_append_crownbay-noemgd += " cfg/smp.scc"
-
-COMPATIBLE_MACHINE_crownbay = "crownbay"
-KMACHINE_crownbay = "crownbay"
-
-KERNEL_FEATURES_append_crownbay += " cfg/smp.scc"
-
-# Update the following to use a different BSP branch or meta SRCREV
-#KBRANCH_crownbay-noemgd = "yocto/standard/preempt-rt/base"
-#SRCREV_machine_pn-linux-yocto-rt_crownbay-noemgd ?= 
-#SRCREV_meta_pn-linux-yocto-rt_crownbay-noemgd ?= 
-
-#KBRANCH_crownbay = "yocto/standard/preempt-rt/base"
-#SRCREV_machine_pn-linux-yocto-rt_crownbay ?= 
-#SRCREV_meta_pn-linux-yocto-rt_crownbay ?= 
diff --git a/meta-crownbay/recipes-kernel/linux/linux-yocto_3.0.bbappend 
b/meta-crownbay/recipes-kernel/linux/linux-yocto_3.0.bbappend
deleted file mode 100644
index 0c92871..000
--- a/meta-crownbay/recipes-kernel/linux/linux-yocto_3.0.bbappend
+++ /dev/null
@@ -1,17 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-
-COMPATIBLE_MACHINE_crownbay = "crownbay"
-KMACHINE_crownbay  = "crownbay"
-KBRANCH_crownbay  = "yocto/standard/crownbay"
-KERNEL_FEATURES_append_crownbay += " cfg/smp.scc"
-
-COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
-KMACHINE_crownbay-noemgd  = "crownbay"
-KBRANCH_crownbay-noemgd  = "yocto/standard/crownbay"
-KERNEL_FEATURES_append_crownbay-noemgd += " cfg/smp.scc"
-
-SRCREV_machine_pn-linux-yocto_crownbay ?= 
"63c65842a3a74e4bd3128004ac29b5639f16433f"
-SRCREV_meta_pn-linux-yocto_crownbay ?= 
"59314a3523e360796419d76d78c6f7d8c5ef2593"
-
-SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= 
"63c65842a3a74e4bd3128004ac29b5639f16433f"
-SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= 
"59314a3523e360796419d76d78c6f7d8c5ef2593"
-- 
1.7.11.4

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

Re: [yocto] [Poky] Baking core-image-minimal with Poky from Master fails with libffi dependency

2012-10-03 Thread Saul Wold


On 10/03/2012 04:21 PM, Rudolf Streif wrote:

I checked out Poky from Master and tried to build core-image-minimal.
do_rootfs failed on the libffi dependency [1]. Is that known/expected?


This is interesting, I just tried it also, and it is working, see below.



:rjs



[1]

bitbake core-image-minimal
Loading cache: 100%
||
ETA:  00:00:00
Loaded 1131 entries from dependency cache.

Build Configuration:
BB_VERSION= "1.16.0"
TARGET_ARCH   = "i586"
TARGET_OS = "linux"
MACHINE   = "qemux86"
DISTRO= "poky"
DISTRO_VERSION= "1.2+snapshot-20121003"
TUNE_FEATURES = "m32 i586"
TARGET_FPU= ""
meta
meta-yocto
meta-yocto-bsp= "master:09aaad16be178bd675750aa6cfe7a373d7c9a8a6"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Function failed: do_rootfs (see
/data/Develop/yocto-develop/x86/tmp/work/qemux86-poky-linux/core-image-minimal-1.0-r0/temp/log.do_rootfs.29559
for further information)
ERROR: Logfile of failure stored in:
/data/Develop/yocto-develop/x86/tmp/work/qemux86-poky-linux/core-image-minimal-1.0-r0/temp/log.do_rootfs.29559
Log data follows:
| DEBUG: Executing shell function do_rootfs
| Generating solve db for
/data/Develop/yocto-develop/x86/tmp/deploy/rpm/qemux86...
| Generating solve db for
/data/Develop/yocto-develop/x86/tmp/deploy/rpm/i586...
| Generating solve db for
/data/Develop/yocto-develop/x86/tmp/deploy/rpm/all...
| Generating solve db for
/data/Develop/yocto-develop/x86/tmp/deploy/rpm/all...
| Processing packagegroup-core-tools-profile...
| Processing packagegroup-core-boot...
| Processing packagegroup-core-tools-testapps...
| Processing packagegroup-core-tools-debug...
| error: Failed dependencies:
|   libffi.so.5 is needed by lttng-viewer-0.12.38-r3.i586
|   libffi.so.5 is needed by
clutter-box2d-0.12.1+git1+de5452e56b537a11fd7f9453d048ff4b4793b5a2-r1.qemux86
|   libffi.so.5 is needed by
libowl-av0-0.1+git1+03030c41ea578cfa74a2ffceb875675b248318ae-r3.i586
|   libffi.so.5 is needed by libclutter-glx-1.0-0-1.8.4-r2.i586
| ERROR: Function failed: do_rootfs (see
/data/Develop/yocto-develop/x86/tmp/work/qemux86-poky-linux/core-image-minimal-1.0-r0/temp/log.do_rootfs.29559
for further information)
ERROR: Task 7
(/data/Develop/yocto-develop/poky/meta/recipes-core/images/core-image-minimal.bb
<http://core-image-minimal.bb>, do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 3891 tasks of which 3890 didn't need to
be rerun and 1 failed.
No currently running tasks (3890 of 3892)

The number of tasks and including lttng-viewer and clutter seems to be 
lartger than core-image-minimal, do you have anything in the local.conf?


Sau!


Summary: 1 task failed:

/data/Develop/yocto-develop/poky/meta/recipes-core/images/core-image-minimal.bb
<http://core-image-minimal.bb>, do_rootfs
Summary: There was 1 ERROR message shown, returning a non-zero exit code.



___
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] [Poky] Baking core-image-minimal with Poky from Master fails with libffi dependency

2012-10-03 Thread Rudolf Streif

No, nothing extra. But you are right about the number of tasks. I checked
out master a while ago, built successfully back then, now pulled the latest
today, and reused the build environment. I will try again with a fresh
environment.

:rjs
On Oct 3, 2012 6:35 PM, "Saul Wold"  wrote:

> On 10/03/2012 04:21 PM, Rudolf Streif wrote:
>
>> I checked out Poky from Master and tried to build core-image-minimal.
>> do_rootfs failed on the libffi dependency [1]. Is that known/expected?
>>
>>  This is interesting, I just tried it also, and it is working, see below.
>
>
>  :rjs
>>
>> 
>>
>> [1]
>>
>> bitbake core-image-minimal
>> Loading cache: 100%
>> |#**##**
>> #|
>> ETA:  00:00:00
>> Loaded 1131 entries from dependency cache.
>>
>> Build Configuration:
>> BB_VERSION= "1.16.0"
>> TARGET_ARCH   = "i586"
>> TARGET_OS = "linux"
>> MACHINE   = "qemux86"
>> DISTRO= "poky"
>> DISTRO_VERSION= "1.2+snapshot-20121003"
>> TUNE_FEATURES = "m32 i586"
>> TARGET_FPU= ""
>> meta
>> meta-yocto
>> meta-yocto-bsp= "master:**09aaad16be178bd675750aa6cfe7a3**73d7c9a8a6"
>>
>> NOTE: Resolving any missing task queue dependencies
>> NOTE: Preparing runqueue
>> NOTE: Executing SetScene Tasks
>> NOTE: Executing RunQueue Tasks
>> ERROR: Function failed: do_rootfs (see
>> /data/Develop/yocto-develop/**x86/tmp/work/qemux86-poky-**
>> linux/core-image-minimal-1.0-**r0/temp/log.do_rootfs.29559
>> for further information)
>> ERROR: Logfile of failure stored in:
>> /data/Develop/yocto-develop/**x86/tmp/work/qemux86-poky-**
>> linux/core-image-minimal-1.0-**r0/temp/log.do_rootfs.29559
>> Log data follows:
>> | DEBUG: Executing shell function do_rootfs
>> | Generating solve db for
>> /data/Develop/yocto-develop/**x86/tmp/deploy/rpm/qemux86...
>> | Generating solve db for
>> /data/Develop/yocto-develop/**x86/tmp/deploy/rpm/i586...
>> | Generating solve db for
>> /data/Develop/yocto-develop/**x86/tmp/deploy/rpm/all...
>> | Generating solve db for
>> /data/Develop/yocto-develop/**x86/tmp/deploy/rpm/all...
>> | Processing packagegroup-core-tools-**profile...
>> | Processing packagegroup-core-boot...
>> | Processing packagegroup-core-tools-**testapps...
>> | Processing packagegroup-core-tools-debug.**..
>> | error: Failed dependencies:
>> |   libffi.so.5 is needed by lttng-viewer-0.12.38-r3.i586
>> |   libffi.so.5 is needed by
>> clutter-box2d-0.12.1+git1+**de5452e56b537a11fd7f9453d048ff**
>> 4b4793b5a2-r1.qemux86
>> |   libffi.so.5 is needed by
>> libowl-av0-0.1+git1+**03030c41ea578cfa74a2ffceb87567**5b248318ae-r3.i586
>> |   libffi.so.5 is needed by libclutter-glx-1.0-0-1.8.4-r2.**i586
>> | ERROR: Function failed: do_rootfs (see
>> /data/Develop/yocto-develop/**x86/tmp/work/qemux86-poky-**
>> linux/core-image-minimal-1.0-**r0/temp/log.do_rootfs.29559
>> for further information)
>> ERROR: Task 7
>> (/data/Develop/yocto-develop/**poky/meta/recipes-core/images/**
>> core-image-minimal.bb <http://core-image-minimal.bb>
>> <http://core-image-minimal.bb>**, do_rootfs) failed with exit code '1'
>> NOTE: Tasks Summary: Attempted 3891 tasks of which 3890 didn't need to
>> be rerun and 1 failed.
>> No currently running tasks (3890 of 3892)
>>
>>  The number of tasks and including lttng-viewer and clutter seems to be
> lartger than core-image-minimal, do you have anything in the local.conf?
>
> Sau!
>
>  Summary: 1 task failed:
>>
>> /data/Develop/yocto-develop/**poky/meta/recipes-core/images/**
>> core-image-minimal.bb <http://core-image-minimal.bb>
>> <http://core-image-minimal.bb>**, do_rootfs
>> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>>
>>
>>
>> __**_
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.**org/listinfo/yocto<https://lists.yoctoproject.org/listinfo/yocto>
>>
>>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How do you release distros produced with Yocto? How should I?

2012-10-03 Thread Venkata ramana gollamudi

On Tue, Oct 02, 2012 at 12:43:27PM -0400, Jerrod Peach wrote:
> I was thinking about doing something very close to that in actual Yocto,
> except I'd store only the revisions/branches that were different from what
> the bb file prescribed in local.conf.  I ran that idea by a couple of
> colleagues separately and they both immediately pointed out a concern: they
> didn't want to have two different places that could manage the revision of
> the package, i.e. local.conf and the package bb file.  They don't like how
> that works in the system we have today.  Instead, they wanted to branch all
> the metadata and have people update individual bb files with different
> revisions as necessary.  That leaves only one place to manage the revision:
> the package bb file.  Doing all that branching concerns me (it seems
> heavier-weight than it needs to be, at the very least), but I can't say
> specifically why branching the bb files is harmful.  If you guys can think
> of a reason why, let me know.  If you think it's reasonable, let me know
> that too.

We have solved this issue by adding OS_VERSION variable to local.conf
Let say your product (OS) should be released in versions, Ex: 1.0 , 1.1 or 
1.1.1 etc.
Which is built from packages of different versions. So each package contains 
.inc and _.bb file.
revision number and patches are maintained in _.bb and all 
common part under .inc.

Now the problems comes to mapping the package versions to your product(OS) 
version.
This is done having a file included into disto file listing out all the 
PREFERRED_VERSIONS and PREFERRED_PROVIDERS for all packages.
  ex: conf/disto/include/osversion_1.0.inc
And this is included to disto file like
  require conf/disto/include/osversion_${OS_VERSION}.inc

This file is freezed after your one version release.
Next version will add a new file osversion_1.1.inc overiding to pick all the 
required package version changes to make your product version.

This will allow you to release multiple product(OS) versions and clearly maps 
the package version, creating individual distributions.
You can even build older version product by just giving OS_VERSION=1.0 in 
local.conf
This eliminates branching all together.

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

[yocto] [danny] multilib ends up with multiple provider error for virtual/lib32-libintl

2012-10-03 Thread Khem Raj

Hi

On danny branch I am seeing below error when multilib is enabled for
x86-64 anyone seen it ?

ERROR: Multiple .bb files are due to be built which each provide
virtual/lib32-libintl
(virtual:multilib:lib32:/work/yocto/poky/meta/recipes-core/eglibc/eglibc_2.16.bb
virtual:multilib:lib32:/work/yocto/poky/meta/recipes-core/gettext/gettext_0.18.1.1.bb).
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Poky] Baking core-image-minimal with Poky from Master fails with libffi dependency

2012-10-03 Thread Andrei Gherzan

There were some issues with libffi while updating the package. Maybe some
bumps were missed. So:
1. This is not new build. In this case a pull on master should fix it. I
think I saw some pr bumps sent as patch.
2. If 1. won't work, recompile libowl si libclutter as a workaround.

ag
 On Oct 4, 2012 4:40 AM, "Rudolf Streif"  wrote:

> No, nothing extra. But you are right about the number of tasks. I checked
> out master a while ago, built successfully back then, now pulled the latest
> today, and reused the build environment. I will try again with a fresh
> environment.
>
> :rjs
> On Oct 3, 2012 6:35 PM, "Saul Wold"  wrote:
>
>> On 10/03/2012 04:21 PM, Rudolf Streif wrote:
>>
>>> I checked out Poky from Master and tried to build core-image-minimal.
>>> do_rootfs failed on the libffi dependency [1]. Is that known/expected?
>>>
>>>  This is interesting, I just tried it also, and it is working, see below.
>>
>>
>>  :rjs
>>>
>>> 
>>>
>>> [1]
>>>
>>> bitbake core-image-minimal
>>> Loading cache: 100%
>>> |#**##**
>>> #|
>>> ETA:  00:00:00
>>> Loaded 1131 entries from dependency cache.
>>>
>>> Build Configuration:
>>> BB_VERSION= "1.16.0"
>>> TARGET_ARCH   = "i586"
>>> TARGET_OS = "linux"
>>> MACHINE   = "qemux86"
>>> DISTRO= "poky"
>>> DISTRO_VERSION= "1.2+snapshot-20121003"
>>> TUNE_FEATURES = "m32 i586"
>>> TARGET_FPU= ""
>>> meta
>>> meta-yocto
>>> meta-yocto-bsp= "master:**09aaad16be178bd675750aa6cfe7a3**
>>> 73d7c9a8a6"
>>>
>>> NOTE: Resolving any missing task queue dependencies
>>> NOTE: Preparing runqueue
>>> NOTE: Executing SetScene Tasks
>>> NOTE: Executing RunQueue Tasks
>>> ERROR: Function failed: do_rootfs (see
>>> /data/Develop/yocto-develop/**x86/tmp/work/qemux86-poky-**
>>> linux/core-image-minimal-1.0-**r0/temp/log.do_rootfs.29559
>>> for further information)
>>> ERROR: Logfile of failure stored in:
>>> /data/Develop/yocto-develop/**x86/tmp/work/qemux86-poky-**
>>> linux/core-image-minimal-1.0-**r0/temp/log.do_rootfs.29559
>>> Log data follows:
>>> | DEBUG: Executing shell function do_rootfs
>>> | Generating solve db for
>>> /data/Develop/yocto-develop/**x86/tmp/deploy/rpm/qemux86...
>>> | Generating solve db for
>>> /data/Develop/yocto-develop/**x86/tmp/deploy/rpm/i586...
>>> | Generating solve db for
>>> /data/Develop/yocto-develop/**x86/tmp/deploy/rpm/all...
>>> | Generating solve db for
>>> /data/Develop/yocto-develop/**x86/tmp/deploy/rpm/all...
>>> | Processing packagegroup-core-tools-**profile...
>>> | Processing packagegroup-core-boot...
>>> | Processing packagegroup-core-tools-**testapps...
>>> | Processing packagegroup-core-tools-debug.**..
>>> | error: Failed dependencies:
>>> |   libffi.so.5 is needed by lttng-viewer-0.12.38-r3.i586
>>> |   libffi.so.5 is needed by
>>> clutter-box2d-0.12.1+git1+**de5452e56b537a11fd7f9453d048ff**
>>> 4b4793b5a2-r1.qemux86
>>> |   libffi.so.5 is needed by
>>> libowl-av0-0.1+git1+**03030c41ea578cfa74a2ffceb87567**5b248318ae-r3.i586
>>> |   libffi.so.5 is needed by libclutter-glx-1.0-0-1.8.4-r2.**i586
>>> | ERROR: Function failed: do_rootfs (see
>>> /data/Develop/yocto-develop/**x86/tmp/work/qemux86-poky-**
>>> linux/core-image-minimal-1.0-**r0/temp/log.do_rootfs.29559
>>> for further information)
>>> ERROR: Task 7
>>> (/data/Develop/yocto-develop/**poky/meta/recipes-core/images/**
>>> core-image-minimal.bb <http://core-image-minimal.bb>
>>> <http://core-image-minimal.bb>**, do_rootfs) failed with exit code '1'
>>> NOTE: Tasks Summary: Attempted 3891 tasks of which 3890 didn't need to
>>> be rerun and 1 failed.
>>> No currently running tasks (3890 of 3892)
>>>
>>>  The number of tasks and including lttng-viewer and clutter seems to be
>> lartger than core-image-minimal, do you have anything in the local.conf?
>>
>> Sau!
>>
>>  Summary: 1 task failed:
>>>
>>> /data/Develop/yocto-develop/**poky/meta/recipes-core/images/**
>>> core-image-minimal.bb <http://core-image-minimal.bb>
>>> <http://core-image-minimal.bb>**, do_rootfs
>>> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>>>
>>>
>>>
>>> __**_
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.**org/listinfo/yocto<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: [yocto] Can't fetch git SRC_URI via HTTP

Re: [yocto] How do you release distros produced with Yocto? How should I?

Re: [yocto] How do you release distros produced with Yocto? How should I?

[yocto] Correct procedure for rebuilding after a git pull

Re: [yocto] Correct procedure for rebuilding after a git pull

Re: [yocto] Correct procedure for rebuilding after a git pull

Re: [yocto] Correct procedure for rebuilding after a git pull

Re: [yocto] Correct procedure for rebuilding after a git pull

Re: [yocto] Correct procedure for rebuilding after a git pull

Re: [yocto] Can't fetch git SRC_URI via HTTP

Re: [yocto] Can't fetch git SRC_URI via HTTP

Re: [yocto] Correct procedure for rebuilding after a git pull

Re: [yocto] Can't fetch git SRC_URI via HTTP

[yocto] [PATCH] psplash: Add custom bar image and color options.

[yocto] Yocto Project 1.4 Planning Process

Re: [yocto] Cannot do atom-pc build with meta-cedartrail

[yocto] [PATCH] psplash: Add custom bar image and color options.

[yocto] [PATCH] psplash: use correct blue offset value for BGR888

[yocto] Yocto Project Technical Team Meeting

[yocto] Yocto Project Technical Team Meeting

[yocto] The BitBake equivalent of "Hello, World!"

Re: [yocto] The BitBake equivalent of "Hello, World!"

Re: [yocto] The BitBake equivalent of "Hello, World!"

[yocto] [Poky] Baking core-image-minimal with Poky from Master fails with libffi dependency

[yocto] 1.3_M5.rc3 images

[yocto] [PATCH 1/3] meta-crownbay: add 3.4 rt support

[yocto] [PATCH 0/3] meta-intel: crownbay cleanups

[yocto] [PATCH 2/3] meta-crownbay: remove -rt smp options from recipe-space

[yocto] [PATCH 3/3] meta-crownbay: remove 3.0 kernel support

Re: [yocto] [Poky] Baking core-image-minimal with Poky from Master fails with libffi dependency

Re: [yocto] [Poky] Baking core-image-minimal with Poky from Master fails with libffi dependency

Re: [yocto] How do you release distros produced with Yocto? How should I?

[yocto] [danny] multilib ends up with multiple provider error for virtual/lib32-libintl

Re: [yocto] [Poky] Baking core-image-minimal with Poky from Master fails with libffi dependency

34 matches

Site Navigation

Mail list logo

Footer information