Re: [yocto] [meta-yocto][PATCH] poky.conf: Use weaker assignment for PREMIRROR

2013-04-03 Thread Paul Eggleton
On Tuesday 02 April 2013 22:11:50 Khem Raj wrote:
> This is to facilitate distros using poky as reference
> so that they can use ?= and provide an option for their
> users to override it if desired
> 
> Signed-off-by: Khem Raj 
> ---
>  meta-yocto/conf/distro/poky.conf |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta-yocto/conf/distro/poky.conf
> b/meta-yocto/conf/distro/poky.conf index afe328b..963b3dd 100644
> --- a/meta-yocto/conf/distro/poky.conf
> +++ b/meta-yocto/conf/distro/poky.conf
> @@ -44,7 +44,7 @@ TCLIBCAPPEND = ""
>  QEMU_TARGETS ?= "arm i386 mips mipsel ppc x86_64"
>  # Other QEMU_TARGETS "mips64 mips64el sh4"
> 
> -PREMIRRORS ?= "\
> +PREMIRRORS ??= "\
>  bzr://.*/.*   http://downloads.yoctoproject.org/mirror/sources/ \n \
>  cvs://.*/.*   http://downloads.yoctoproject.org/mirror/sources/ \n \
>  git://.*/.*   http://downloads.yoctoproject.org/mirror/sources/ \n \

I'm not sure this is a path we should be going down; potentially we could end 
up having to use ??= for just about everything.

Wouldn't you be better off using your own separate distro config (perhaps 
copying poky.conf instead of "require"ing it) and then the user can just set 
it with "=" ?

Cheers,
Paul

-- 

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


Re: [yocto] [meta-yocto][PATCH] poky.conf: Use weaker assignment for PREMIRROR

2013-04-03 Thread Khem Raj

On Apr 2, 2013, at 11:41 PM, Paul Eggleton  
wrote:

> I'm not sure this is a path we should be going down; potentially we could end 
> up having to use ??= for just about everything.
> 

whats is downside of using ??= instead of ?=

> Wouldn't you be better off using your own separate distro config (perhaps 
> copying poky.conf instead of "require"ing it) and then the user can just set 
> it with "=" ?

yes. however you are then always on lookout for changes happening in poky 
policies then
you need to mimic in your distro config

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


Re: [yocto] [meta-yocto][PATCH] poky.conf: Use weaker assignment for PREMIRROR

2013-04-03 Thread Paul Eggleton
On Tuesday 02 April 2013 23:44:06 Khem Raj wrote:
> On Apr 2, 2013, at 11:41 PM, Paul Eggleton  
wrote:
> > I'm not sure this is a path we should be going down; potentially we could
> > end up having to use ??= for just about everything.
> 
> whats is downside of using ??= instead of ?=

The volume of changes to the config that this will require, a minor memory 
usage increase (I suspect), but more importantly it increases the complexity 
for the end user. Right now ??= is used sparingly.

> > Wouldn't you be better off using your own separate distro config (perhaps
> > copying poky.conf instead of "require"ing it) and then the user can just
> > set it with "=" ?
> 
> yes. however you are then always on lookout for changes happening in poky
> policies then you need to mimic in your distro config

Wouldn't it be the reverse at the moment? We do add new things to the poky 
distro config when we need to test them and those new things might not be 
desirable in your configuration.

Distro configs should remain fairly static once initially set. FWIW, we do call 
out any needed changes between releases in the migration information within 
the documentation.

Cheers,
Paul

-- 

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


Re: [yocto] [meta-yocto][PATCH] poky.conf: Use weaker assignment for PREMIRROR

2013-04-03 Thread Khem Raj

On Apr 2, 2013, at 11:56 PM, Paul Eggleton  
wrote:

> On Tuesday 02 April 2013 23:44:06 Khem Raj wrote:
>> On Apr 2, 2013, at 11:41 PM, Paul Eggleton  
> wrote:
>>> I'm not sure this is a path we should be going down; potentially we could
>>> end up having to use ??= for just about everything.
>> 
>> whats is downside of using ??= instead of ?=
> 
> The volume of changes to the config that this will require, a minor memory 
> usage increase (I suspect), but more importantly it increases the complexity 
> for the end user. Right now ??= is used sparingly.



> 
>>> Wouldn't you be better off using your own separate distro config (perhaps
>>> copying poky.conf instead of "require"ing it) and then the user can just
>>> set it with "=" ?
>> 
>> yes. however you are then always on lookout for changes happening in poky
>> policies then you need to mimic in your distro config
> 
> Wouldn't it be the reverse at the moment? We do add new things to the poky 
> distro config when we need to test them and those new things might not be 
> desirable in your configuration.
> 

no, if one is tracking upstream and wants to remain compatible its lot better 
to take in all policies
and then customize it. and once released the policies are not changed anyway. 
Its easier to test and customize
your distro that way since changes are incremental examples are when new QA 
checks are enabled you want to fix
your own layers quickly and its one less hassle to keep syncing policies when 
your distro and you can get quicker
response to fallouts if any. From personal experience including it has been a 
better way and indirectly is more integrated.

After all poky is a reference distro policy, whether we should recommend to 
copy it or include it in custom distros,
either ways is fine with good reasons. You sound like supporting the second 
case, I am impartial to whatever is the
recommendation there are good and bad of both approaches.

I am also interested in hearing from other yocto users how are they consuming 
poky policies 


> Distro configs should remain fairly static once initially set.

after releases yes but not when you are building next gen which is for active 
development.

> FWIW, we do call 
> out any needed changes between releases in the migration information within 
> the documentation.


yes as I said once needs to sync.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] how to convert source rpm spec to bitbake recipe?

2013-04-03 Thread Paul Eggleton
Hi Michael,

On Sunday 31 March 2013 08:45:23 Michael Fainstein wrote:
> Is there a tool or guide for conversion of source rpm spec file to bitbake
> recipe?

There is scripts/create-recipe - this is aimed at just downloading source and 
using a spec file contained within as a basis for a new recipe (among other 
methods it uses to determine recipe contents), however it could be adapted to 
read a specified spec file I would think.

Cheers,
Paul

-- 

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


[linux-yocto] gdb target kernel debug

2013-04-03 Thread Lai Eddy
I want to debug the kernel module loaded in the x86_64 (jasperforest)
linux-yocto target,
so I load the 'vmlinux' with gdb on the host PC (CentOS 6.4_x64) ,
but looks like the gdb failed to connect the target,
should I add any 'kernel boot parameters' to enable the kgdb use ttyS0 ?

my target boot from a USB drive with SYSLINUX, the target's ttyS0 is used
as console output,
should I use ttyS1 on target as debug port instead of ttyS0? how can I set
that?

and , when I run "echo g > /proc/sysrq-trigger" on target console, the
target machine not freeze as expect.

--
[root@localhost linux-jasperforest-standard-build]# x86_64-poky-linux-gdb
vmlinux
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-pokysdk-linux
--target=x86_64-poky-linux".
For bug reporting instructions, please see:
...
Reading symbols
fromtmp/work/jasperforest-poky-linux/linux-yocto/3.4.26+gitAUTOINC+4fd76cc4f33e0afd8f906b1e8f231b6d13b6c993_840bb8c059418c4753415df56c9aff1c0d5354c8-r4.3/linux-jasperforest-standard-build/vmlinux...done.
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
Ignoring packet error, continuing...
warning: unrecognized item "qRelocInsn+���b5" in "qSupported" response
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Malformed response to offset query, qOffsets���4bftiprocess
(gdb)
___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [yocto] SDK creation

2013-04-03 Thread Paul Eggleton
On Friday 15 March 2013 14:12:45 Navani Srivastava wrote:
> I tried giving
> PREFERRED_PROVIDER_qt4_embedded ?= "4.8.1"
> 
> in machine configuration file but it didn't helped..
> Any suggestions?

This should be PREFERRED_VERSION_qt4-embedded = "4.8.1"
(note VERSION not PROVIDER, qt4-embedded not qt4_embedded, and = not ?= )

Cheers,
Paul

-- 

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


Re: [yocto] [PATCH] Remove clutter project templates

2013-04-03 Thread Paul Eggleton
Hi Ioana,

On Tuesday 12 March 2013 18:05:33 Ioana Grigoropol wrote:
> - support for clutter was removed from core-image-sato along with
> clutter-box2d and thus the project templates in Eclipse should not be
> supported anymore; gtk templates should be used instead

The removal of clutter-box2d doesn't signal that clutter itself is 
unsupported, so I think maybe we shouldn't be removing these templates just 
yet.

Cheers,
Paul

-- 

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


Re: [yocto] SDK creation

2013-04-03 Thread Navani Srivastava
Thanks for your reply..
It worked..
On Apr 3, 2013 12:58 PM, "Paul Eggleton" 
wrote:

> On Friday 15 March 2013 14:12:45 Navani Srivastava wrote:
> > I tried giving
> > PREFERRED_PROVIDER_qt4_embedded ?= "4.8.1"
> >
> > in machine configuration file but it didn't helped..
> > Any suggestions?
>
> This should be PREFERRED_VERSION_qt4-embedded = "4.8.1"
> (note VERSION not PROVIDER, qt4-embedded not qt4_embedded, and = not ?= )
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] [PATCH] Remove clutter project templates

2013-04-03 Thread Grigoropol, IoanaX
Hi Paul,

In my opinion, since clutter was only brought in core-image-sato and 
core-image-sato-sdk by clutter-box2d, and not independently, it means it was 
not really intended to support it. 

Do you think there should be support for clutter in the sdk images ?
Clutter + dependencies is not a small package and was only getting into images 
through testapps feature, and we could use gtk templates instead.

Thanks,
Ioana

From: Paul Eggleton [paul.eggle...@linux.intel.com]
Sent: Wednesday, April 03, 2013 11:14 AM
To: Grigoropol, IoanaX
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] [PATCH] Remove clutter project templates

Hi Ioana,

On Tuesday 12 March 2013 18:05:33 Ioana Grigoropol wrote:
> - support for clutter was removed from core-image-sato along with
> clutter-box2d and thus the project templates in Eclipse should not be
> supported anymore; gtk templates should be used instead

The removal of clutter-box2d doesn't signal that clutter itself is
unsupported, so I think maybe we shouldn't be removing these templates just
yet.

Cheers,
Paul

--

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


[yocto] Installing foreign fonts into the yocto build

2013-04-03 Thread Satya Swaroop Damarla
Hi Guys,

I have a small issue. On my device, I would like to have Chinese, Japanese,
Russian, Hebrewish, Greek fonts and all European language special
characters available for java application based on X.

In general I would like to know a method of adding custom fonts which are
scalable to X server. I tried browsing oever the internet and in the
mailing lists but not much success... Suggestions are deeply appreciated...

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


Re: [yocto] [PATCH] Remove clutter project templates

2013-04-03 Thread Paul Eggleton
On Wednesday 03 April 2013 08:42:23 Grigoropol, IoanaX wrote:
> Paul Eggleton wrote:
> > On Tuesday 12 March 2013 18:05:33 Ioana Grigoropol wrote:
> > > - support for clutter was removed from core-image-sato along with
> > > clutter-box2d and thus the project templates in Eclipse should not be
> > > supported anymore; gtk templates should be used instead
> >  
> > The removal of clutter-box2d doesn't signal that clutter itself is
> > unsupported, so I think maybe we shouldn't be removing these templates
> > just yet.
>
> In my opinion, since clutter was only brought in core-image-sato and
> core-image-sato-sdk by clutter-box2d, and not independently, it means it
> was not really intended to support it.

Possibly; the other alternative is that nobody had really considered the 
question of whether or not it should be included. I'm unsure as to which is 
the case here.

> Do you think there should be support for clutter in the sdk images ?

I would say it depends on whether we believe it will be useful to new 
application developers, or we're just keeping it around for compatibility with 
existing applications. I can see it being useful but I'd probably like to hear 
from Jessica and others as well.

> Clutter + dependencies is not a small package and was only getting into
> images through testapps feature, and we could use gtk templates instead.

True, but Gtk+ and Clutter aren't quite the same thing. I'm not an expert on 
Clutter by any means but I believe it provides a much better framework for 
animations and non-traditional UIs than Gtk+ does.

Cheers,
Paul

-- 

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


Re: [yocto] OE/Yocto Talk in Free Software and Linux Days in Turkey

2013-04-03 Thread Burton, Ross
Hi Eren,

On 28 March 2013 14:21, Eren Türkay  wrote:
> I haven't prepared slides and I have one week until the event.  I would
> really appreciate a previous seminar materials and slides. I would be
> grateful if we can discuss further on items in detail (e.g: what to
> explain). If you were to give a talk about OE, what would you explain?
> :)

I've done two presentations about Yocto from a high-level point of
view, their sources are in git at
http://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/tree/presentations
(the .pin files are the source).  It's a bit late (I've been away for
the weekend) but there might be something useful for you in there.

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


Re: [yocto] how to convert source rpm spec to bitbake recipe?

2013-04-03 Thread Samuel Stirtzel
2013/4/3 Paul Eggleton :
> Hi Michael,
>
> On Sunday 31 March 2013 08:45:23 Michael Fainstein wrote:
>> Is there a tool or guide for conversion of source rpm spec file to bitbake
>> recipe?
>
> There is scripts/create-recipe - this is aimed at just downloading source and
> using a spec file contained within as a basis for a new recipe (among other
> methods it uses to determine recipe contents), however it could be adapted to
> read a specified spec file I would think.
>
> Cheers,
> Paul

Hi Paul,
good to know.

Does this script also helps with packaging?

For KDE there are tons of sub-packages within one recipe, adding them
per hand is the major time factor in this case.
Currently I use a decrepit script [1] to do this, but maybe I can use
this one if it meets my expectations.

[1] kde-spec2bb.sh beware, contains excessive sed usage:
http://pastebin.com/3g5xDKJ5


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


Re: [yocto] how to convert source rpm spec to bitbake recipe?

2013-04-03 Thread Michael Fainstein
> -Original Message-
> From: Samuel Stirtzel [mailto:s.stirt...@googlemail.com]
> Sent: יום ד 03 אפריל 2013 13:47
> To: Paul Eggleton
> Cc: Michael Fainstein; yocto@yoctoproject.org
> Subject: Re: [yocto] how to convert source rpm spec to bitbake recipe?
> 
> 2013/4/3 Paul Eggleton :
> > Hi Michael,
> >
> > On Sunday 31 March 2013 08:45:23 Michael Fainstein wrote:
> >> Is there a tool or guide for conversion of source rpm spec file to
> bitbake
> >> recipe?
> >
> > There is scripts/create-recipe - this is aimed at just downloading source
> and
> > using a spec file contained within as a basis for a new recipe (among
> other
> > methods it uses to determine recipe contents), however it could be
> adapted to
> > read a specified spec file I would think.
> >
> > Cheers,
> > Paul
> 
> Hi Paul,
> good to know.
> 
> Does this script also helps with packaging?
> 
> For KDE there are tons of sub-packages within one recipe, adding them
> per hand is the major time factor in this case.
> Currently I use a decrepit script [1] to do this, but maybe I can use
> this one if it meets my expectations.
> 
> [1] kde-spec2bb.sh beware, contains excessive sed usage:
> http://pastebin.com/3g5xDKJ5
> 
> 
> --
> Regards
> Samuel

Hi Samuel,
kde-spec2bb.sh script references spec2bb.inc script. Can you post a link to it?

Thanks,
Michael


This e-mail message is intended for the recipient only and contains information 
which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have 
received this transmission in error, please inform us by e-mail, phone or fax, 
and then delete the original and all copies thereof.

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


Re: [yocto] how to convert source rpm spec to bitbake recipe?

2013-04-03 Thread Samuel Stirtzel
2013/4/3 Michael Fainstein :
>> -Original Message-
>> From: Samuel Stirtzel [mailto:s.stirt...@googlemail.com]
>> Sent: יום ד 03 אפריל 2013 13:47
>> To: Paul Eggleton
>> Cc: Michael Fainstein; yocto@yoctoproject.org
>> Subject: Re: [yocto] how to convert source rpm spec to bitbake recipe?
>>
>> 2013/4/3 Paul Eggleton :
>> > Hi Michael,
>> >
>> > On Sunday 31 March 2013 08:45:23 Michael Fainstein wrote:
>> >> Is there a tool or guide for conversion of source rpm spec file to
>> bitbake
>> >> recipe?
>> >
>> > There is scripts/create-recipe - this is aimed at just downloading source
>> and
>> > using a spec file contained within as a basis for a new recipe (among
>> other
>> > methods it uses to determine recipe contents), however it could be
>> adapted to
>> > read a specified spec file I would think.
>> >
>> > Cheers,
>> > Paul
>>
>> Hi Paul,
>> good to know.
>>
>> Does this script also helps with packaging?
>>
>> For KDE there are tons of sub-packages within one recipe, adding them
>> per hand is the major time factor in this case.
>> Currently I use a decrepit script [1] to do this, but maybe I can use
>> this one if it meets my expectations.
>>
>> [1] kde-spec2bb.sh beware, contains excessive sed usage:
>> http://pastebin.com/3g5xDKJ5
>>
>>
>> --
>> Regards
>> Samuel
>
> Hi Samuel,
> kde-spec2bb.sh script references spec2bb.inc script. Can you post a link to 
> it?
>

The spec2bb.inc only handles the parameters.
But sure here is the link: http://pastebin.com/S64CkYUa


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


[yocto] boost & qt-mobility-x11 added to core-image-sato

2013-04-03 Thread Edward Vidal
Hello,
I have been using the bitbake core-image-sato with

EXTRA_IMAGE_FEATURES = "debug-tweaks tools-sdk" which adds the sdk to the
image.

I since have done bitbake boost (added about 14 RPMs) and bitbake
qt-mobility-x11 (81 RPMs).

After creating the boost libs I installed the 14 RPMs on the target
with the script
rpm -Uh  \
boost-1.53.0-r1.armv7a_vfp_neon.rpm \
boost-dbg-1.53.0-r1.armv7a_vfp_neon.rpm \
boost-dev-1.53.0-r1.armv7a_vfp_neon.rpm \
boost-staticdev-1.53.0-r1.armv7a_vfp_neon.rpm \
boost-test-1.53.0-r1.armv7a_vfp_neon.rpm \
libboost-date-time1.53.0-1.53.0-r1.armv7a_vfp_neon.rpm \
libboost-filesystem1.53.0-1.53.0-r1.armv7a_vfp_neon.rpm \
libboost-graph1.53.0-1.53.0-r1.armv7a_vfp_neon.rpm \
libboost-iostreams1.53.0-1.53.0-r1.armv7a_vfp_neon.rpm \
libboost-program-options1.53.0-1.53.0-r1.armv7a_vfp_neon.rpm \
libboost-regex1.53.0-1.53.0-r1.armv7a_vfp_neon.rpm \
libboost-signals1.53.0-1.53.0-r1.armv7a_vfp_neon.rpm \
libboost-system1.53.0-1.53.0-r1.armv7a_vfp_neon.rpm \
libboost-thread1.53.0-1.53.0-r1.armv7a_vfp_neon.rpm

The qt-mobility-x11 RPMs were installed with rpm -Uh *.rpm.
The difficult part was determining what are the needed dependencies.  This
was done by running the rpm -Uh --test *.rpm many times and adding
additional RPMs to set of RPMs.

What is the correct procedure to add bitbake results to the target?
How does one know what packages are included in the image? What should be
the order first bitbake boost, bitbake qt-mobility, and then bitbake
core-image-sato?  This order did not work I still needed to install the new
RPMs after the target was running.


Any and all help will be appreciated!

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


Re: [yocto] boost & qt-mobility-x11 added to core-image-sato

2013-04-03 Thread Paul Eggleton
Hi Edward,

On Wednesday 03 April 2013 08:01:55 Edward Vidal wrote:
> I have been using the bitbake core-image-sato with
> 
> EXTRA_IMAGE_FEATURES = "debug-tweaks tools-sdk" which adds the sdk to the
> image.
> 
> I since have done bitbake boost (added about 14 RPMs) and bitbake
> qt-mobility-x11 (81 RPMs).
> 
> After creating the boost libs I installed the 14 RPMs on the target
> with the script
> rpm -Uh  \
> boost-1.53.0-r1.armv7a_vfp_neon.rpm \
> boost-dbg-1.53.0-r1.armv7a_vfp_neon.rpm \
> boost-dev-1.53.0-r1.armv7a_vfp_neon.rpm \
> boost-staticdev-1.53.0-r1.armv7a_vfp_neon.rpm \
> boost-test-1.53.0-r1.armv7a_vfp_neon.rpm \
> libboost-date-time1.53.0-1.53.0-r1.armv7a_vfp_neon.rpm \
> libboost-filesystem1.53.0-1.53.0-r1.armv7a_vfp_neon.rpm \
> libboost-graph1.53.0-1.53.0-r1.armv7a_vfp_neon.rpm \
> libboost-iostreams1.53.0-1.53.0-r1.armv7a_vfp_neon.rpm \
> libboost-program-options1.53.0-1.53.0-r1.armv7a_vfp_neon.rpm \
> libboost-regex1.53.0-1.53.0-r1.armv7a_vfp_neon.rpm \
> libboost-signals1.53.0-1.53.0-r1.armv7a_vfp_neon.rpm \
> libboost-system1.53.0-1.53.0-r1.armv7a_vfp_neon.rpm \
> libboost-thread1.53.0-1.53.0-r1.armv7a_vfp_neon.rpm
> 
> The qt-mobility-x11 RPMs were installed with rpm -Uh *.rpm.
> The difficult part was determining what are the needed dependencies.  This
> was done by running the rpm -Uh --test *.rpm many times and adding
> additional RPMs to set of RPMs.
> 
> What is the correct procedure to add bitbake results to the target?
> How does one know what packages are included in the image? What should be
> the order first bitbake boost, bitbake qt-mobility, and then bitbake
> core-image-sato?  This order did not work I still needed to install the new
> RPMs after the target was running.

Just building something doesn't mean it will be added to an image. Each image
has a set list of things that will be installed into it (IMAGE_INSTALL).
This will also automatically take care of adding dependencies.

Please see here for information on how to customise the contents of images:

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

Cheers,
Paul

-- 

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


[yocto] Prevent zImage to be copied to /boot/ in image

2013-04-03 Thread Christophe Aeschlimann
Hi,

I'm using the danny branch and I would like to know if there is a way to
not have the zImage included in the generated image under the /boot/ folder.

I'm trying to save on space in the generated image and I couldn't find
anywhere to configure that behaviour.

Thank you,

-- 
Christophe Aeschlimann

Embedded Software Engineer & IT Manager
ACN Advanced Communications Networks S.A.
2000 - Neuchâtel, Switzerland
Tel. +41 32 724 74 31
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] boost & qt-mobility-x11 added to core-image-sato

2013-04-03 Thread Burton, Ross
Hi,

On 3 April 2013 15:01, Edward Vidal  wrote:
> What is the correct procedure to add bitbake results to the target?

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

Generally you can specify the key packages and the dependencies will
pull in the rest.  In this case "boost" is a meta-package that has no
contents but simply depends on the library packages, so you can just
add "boost" if that's what you really want to do.

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


Re: [yocto] Prevent zImage to be copied to /boot/ in image

2013-04-03 Thread Bruce Ashfield

On 13-04-03 10:56 AM, Christophe Aeschlimann wrote:

Hi,

I'm using the danny branch and I would like to know if there is a way to
not have the zImage included in the generated image under the /boot/ folder.

I'm trying to save on space in the generated image and I couldn't find
anywhere to configure that behaviour.


Have you tried clearing this variable:

(from kernel.bbclass)

# Allow machines to override this dependency if kernel image files are
# not wanted in images as standard
RDEPENDS_kernel-base ?= "kernel-image"

Cheers,

Bruce





Thank you,



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


Re: [yocto] This one can't be me...

2013-04-03 Thread Darren Hart
Hi Paul,

First off, please CC the relevant maintainers of the recipes and BSPs
you are having trouble with. The README in the cedartrail BSP lists
Kishore as the maintainer, now on CC. This will help improve response
time to your post as well as getting the right people looking at it.

Kishore, can you please work with Paul to get him booting?

Some ideas on things to check/try inline below.

On 04/02/2013 02:27 PM, Paul D. DeRocco wrote:
> I've successfully built core-image-base-cedartrail-nopvr, with NO
> modifications, no meta-oe layer to pull in Samba, no attempt to partition
> the flash drive, just the .hddimg file dd'ed to /dev/sdb, to see if I can
> get something, anything to boot out of the box.
> 
> I get a kernel panic when it tries to boot on my Intel DN2800MT mobo, with
> 1GB of RAM. The error messages, which appear on the attached VGA monitor,
> are:
> 
> VFS: Cannot open root device "ram0" or unknown-block(0,0)
> Please append a correct "root=" boot option;
> here are the available partitions:
> VFS: Unable to mount root fs on unknown-block(0,0)
> User configuration error - no valid root filesystem found


Believe it or not, this is the single most common boot error in the
history of boot errors on Linux :-)

It is telling you there is no block device called "ram0" to load and
there are no other block devices detected. The USB stick doesn't show up
here because USB can take a while to enumerate and unless you tell the
kernel to wait for it, it doesn't. That shouldn't be your problem here
as you are attempting to boot from a ramdisk.

The most obvious question is whether or not the kernel you built has
ramdisk support. You can do this by analyzing the .config file in your
linux-yocto build tree
(build/tmp/work/cedartrail.../linux-yocto*/linux-cedartrail-standard-build/.config).
You want to look for:

$ grep BLK_DEV_RAM .config
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096

> 
> Here is the syslinux.cfg file that is controlling the boot:
> 
> # Automatically created by OE
> serial 0 115200
> ALLOWOPTIONS 1
> DEFAULT boot
> TIMEOUT 10
> PROMPT 1
> LABEL boot
> KERNEL /vmlinuz
> APPEND initrd=/initrd LABEL=boot  root=/dev/ram0   console=ttyS0,115200
> console=tty0 video=vesafb vga=0x318
> LABEL install
> KERNEL /vmlinuz
> APPEND initrd=/initrd LABEL=install  root=/dev/ram0   console=ttyS0,115200
> console=tty0 video=vesafb vga=0x318
> 
> This is a live-image boot, and the flash drive contains the usual five
> files. As far as I can tell, a live-image boot is a two-stage boot beginning
> with a really stripped down vmlinuz and a small RAM-disk read from initrd,
> which then reads the big rootfs.img into another RAM-disk and tries to boot
> the real kernel from that. I don't know which kernel is panicking, because
> it all flies by so fast.


Well, see my comment above, the kernel was about as explicit as it can
be - it didn't find a block device to mount as root. However, when
debugging kernel issues, it is important to be able to record the log.
You have a serial port console configured in your kernel parameters
(console=ttyS0,115200), it would be a good idea to connect to the serial
console and capture the boot messages to a file using minicom, screen,
or similar.


> Any ideas, or am I cursed?
> 

Another common problem is the hddimg format itself and conflicts with
certain firmware. You can try the zip image format as described in
poky/README.hardware under the "Intel Atom based PCs and devices" section.

Finally, usb sticks are terrible about just being bad. Many of them are
literally write once devices. They're fine so long as you don't fill
them up, which works for shuffling small files around, but writing full
OS images to them tends to kill them in a hurry. Try with a brand new stick.

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] This one can't be me...

2013-04-03 Thread Marc Ferland
"Paul D. DeRocco"  writes:

> Followup:
>
> I figured I'd try a sato build, since that's what the example on the BSP
> page uses. But core-image-sato-cedartrail-nopvr panics in the same way as
> core-image-base-cedartrail-nopvr. For sato, I surmised maybe 1GB wasn't
> enough, so I put in a second stick. This time, instead of spewing out a lot
> of kernel startup stuff ending in a panic, it gave me a SYSLINUX signon on
> the top of the screen, sat there for about 10 seconds, then rebooted into
> the BIOS, repeatedly. So I put back core-image-base-cedartrail-nopvr, and it
> also gave me the SYSLINUX signon, and rebooted after 10 seconds.
>
> The fact that it behaves differently with 2GB suggests that maybe 1GB isn't
> enough, but that seems hard to imagine even for sato, let alone the base
> console version. I've run Ubuntu on these particular RAM modules, on a
> different motherboard, so I don't think I've got bad RAM.
>
> Any help figuring this out would be appreciated. For all my work, and
> apparently successful builds, I haven't managed to boot anything yet.

Hi Paul,

The live images boot in (roughly) the following way:

1- BIOS loads the bootloader (syslinux)
2- Bootloader loads the kernel and initrd
3- Kernel starts and executes the 'init' script from the initrd
4- The 'init' script mounts sysfs, devtmpfs and procfs filesystems and
   starts udev. It then waits for a storage device containing the
   rootfs.img file to appear (udev rules will mount the device in
   /media).
5- Once the file (rootfs.img) appears it loop-mounts and switch_root to
   it to continue the booting process.

BTW, there is only _one_ kernel. The two stage process allows more
flexibility as where your rootfs is located (CD, usb flash, network
boot, etc.).

>From what I see in the kernel messages you supplied it looks like the
init script doesn't even got a chance to run. Kernel issue?

One strange thing also is the use of the 3.0 kernel on this BSP. Which
doesn't shows up in the list of available kernels (well at least on the
git.yoctoproject.org web site.) so I don't know what happens in such
cases.

It would definitely help if the maintainer of the cedartrail BSP could
drop-in and give some advice!

Good luck,

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


[yocto] Is there no official support for Erlang runtime in Yocto?

2013-04-03 Thread Hans Beckérus
Hi. We wish to bring in the Erlang runtime into our builds, tailored for
embedded systems.
I can see that OpenEmbedded provides such a package in their classic
release. But I can not seem to find it as part of Yocto, neither can I find
it among the official OpenEmbedded recipes from their Wiki index. Is there
something that I have overlooked here? Or should it be fine just to bring
in the recipe from the OpenEmbedded classic git repo and add it to our own
meta?

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


Re: [yocto] Is there no official support for Erlang runtime in Yocto?

2013-04-03 Thread Philip Balister
On 04/03/2013 12:19 PM, Hans Beckérus wrote:
> Hi. We wish to bring in the Erlang runtime into our builds, tailored for
> embedded systems.
> I can see that OpenEmbedded provides such a package in their classic
> release. But I can not seem to find it as part of Yocto, neither can I find
> it among the official OpenEmbedded recipes from their Wiki index. Is there
> something that I have overlooked here? Or should it be fine just to bring
> in the recipe from the OpenEmbedded classic git repo and add it to our own
> meta?

I'd love to see it added to meta-oe.

Philip

> 
> Hans
> 
> 
> 
> ___
> 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] This one can't be me...

2013-04-03 Thread Bodke, Kishore K
Thanks Darren, will follow up on this.

Hi Paul, 
Please try out what Darren has suggested.

-Kishore.

>-Original Message-
>From: Darren Hart [mailto:dvh...@linux.intel.com]
>Sent: Wednesday, April 03, 2013 8:39 AM
>To: Paul D. DeRocco
>Cc: yocto@yoctoproject.org; Bodke, Kishore K
>Subject: Re: [yocto] This one can't be me...
>
>Hi Paul,
>
>First off, please CC the relevant maintainers of the recipes and BSPs
>you are having trouble with. The README in the cedartrail BSP lists
>Kishore as the maintainer, now on CC. This will help improve response
>time to your post as well as getting the right people looking at it.
>
>Kishore, can you please work with Paul to get him booting?
>
>Some ideas on things to check/try inline below.
>
>On 04/02/2013 02:27 PM, Paul D. DeRocco wrote:
>> I've successfully built core-image-base-cedartrail-nopvr, with NO
>> modifications, no meta-oe layer to pull in Samba, no attempt to partition
>> the flash drive, just the .hddimg file dd'ed to /dev/sdb, to see if I can
>> get something, anything to boot out of the box.
>>
>> I get a kernel panic when it tries to boot on my Intel DN2800MT mobo, with
>> 1GB of RAM. The error messages, which appear on the attached VGA
>monitor,
>> are:
>>
>> VFS: Cannot open root device "ram0" or unknown-block(0,0)
>> Please append a correct "root=" boot option;
>> here are the available partitions:
>> VFS: Unable to mount root fs on unknown-block(0,0)
>> User configuration error - no valid root filesystem found
>
>
>Believe it or not, this is the single most common boot error in the
>history of boot errors on Linux :-)
>
>It is telling you there is no block device called "ram0" to load and
>there are no other block devices detected. The USB stick doesn't show up
>here because USB can take a while to enumerate and unless you tell the
>kernel to wait for it, it doesn't. That shouldn't be your problem here
>as you are attempting to boot from a ramdisk.
>
>The most obvious question is whether or not the kernel you built has
>ramdisk support. You can do this by analyzing the .config file in your
>linux-yocto build tree
>(build/tmp/work/cedartrail.../linux-yocto*/linux-cedartrail-standard-
>build/.config).
>You want to look for:
>
>$ grep BLK_DEV_RAM .config
>CONFIG_BLK_DEV_RAM=y
>CONFIG_BLK_DEV_RAM_COUNT=16
>CONFIG_BLK_DEV_RAM_SIZE=4096
>
>>
>> Here is the syslinux.cfg file that is controlling the boot:
>>
>> # Automatically created by OE
>> serial 0 115200
>> ALLOWOPTIONS 1
>> DEFAULT boot
>> TIMEOUT 10
>> PROMPT 1
>> LABEL boot
>> KERNEL /vmlinuz
>> APPEND initrd=/initrd LABEL=boot  root=/dev/ram0   console=ttyS0,115200
>> console=tty0 video=vesafb vga=0x318
>> LABEL install
>> KERNEL /vmlinuz
>> APPEND initrd=/initrd LABEL=install  root=/dev/ram0   console=ttyS0,115200
>> console=tty0 video=vesafb vga=0x318
>>
>> This is a live-image boot, and the flash drive contains the usual five
>> files. As far as I can tell, a live-image boot is a two-stage boot beginning
>> with a really stripped down vmlinuz and a small RAM-disk read from initrd,
>> which then reads the big rootfs.img into another RAM-disk and tries to boot
>> the real kernel from that. I don't know which kernel is panicking, because
>> it all flies by so fast.
>
>
>Well, see my comment above, the kernel was about as explicit as it can
>be - it didn't find a block device to mount as root. However, when
>debugging kernel issues, it is important to be able to record the log.
>You have a serial port console configured in your kernel parameters
>(console=ttyS0,115200), it would be a good idea to connect to the serial
>console and capture the boot messages to a file using minicom, screen,
>or similar.
>
>
>> Any ideas, or am I cursed?
>>
>
>Another common problem is the hddimg format itself and conflicts with
>certain firmware. You can try the zip image format as described in
>poky/README.hardware under the "Intel Atom based PCs and devices"
>section.
>
>Finally, usb sticks are terrible about just being bad. Many of them are
>literally write once devices. They're fine so long as you don't fill
>them up, which works for shuffling small files around, but writing full
>OS images to them tends to kill them in a hurry. Try with a brand new stick.
>
>Thanks,
>
>--
>Darren Hart
>Intel Open Source Technology Center
>Yocto Project - Technical Lead - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] Is there no official support for Erlang runtime in Yocto?

2013-04-03 Thread Paul Eggleton
On Wednesday 03 April 2013 18:19:43 Hans Beckérus wrote:
> Hi. We wish to bring in the Erlang runtime into our builds, tailored for
> embedded systems.
> I can see that OpenEmbedded provides such a package in their classic
> release. But I can not seem to find it as part of Yocto, neither can I find
> it among the official OpenEmbedded recipes from their Wiki index. Is there
> something that I have overlooked here? Or should it be fine just to bring
> in the recipe from the OpenEmbedded classic git repo and add it to our own
> meta?

Indeed, this seems to only be in OE-Classic; bringing it back into somewhere 
like meta-oe would be much appreciated I think.

Cheers,
Paul

-- 

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


[yocto] [yocto-docs][PATCH 0/5] Documentation updates

2013-04-03 Thread Paul Eggleton
The following changes since commit 3b1c5858527cba908a5acff1ddc924630cc954b0:

  dev-manual: merged "updating images" into the "working with packages" 
(2013-04-03 09:12:49 -0700)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib paule/docs3
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=paule/docs3

Paul Eggleton (5):
  ref-manual: add buildhistory SDK contents collection
  ref-manual: add info on buildhistory SRCREV value collection
  ref-manual: add preamble to buildhistory section on top-level
contents
  Update layer.conf examples to reflect current practice
  dev-manual: add new bitbake-layers show-cross-depends subcommand

 documentation/bsp-guide/bsp.xml|   10 +-
 .../dev-manual/dev-manual-common-tasks.xml |   30 ++---
 documentation/ref-manual/ref-variables.xml |6 +-
 documentation/ref-manual/usingpoky.xml |  122 
 4 files changed, 144 insertions(+), 24 deletions(-)

-- 
1.7.10.4

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


[yocto] [yocto-docs][PATCH 1/5] ref-manual: add buildhistory SDK contents collection

2013-04-03 Thread Paul Eggleton
Buildhistory can now collect information on SDK contents, so add this to
the appropriate section.

Signed-off-by: Paul Eggleton 
---
 documentation/ref-manual/usingpoky.xml |   62 
 1 file changed, 62 insertions(+)

diff --git a/documentation/ref-manual/usingpoky.xml 
b/documentation/ref-manual/usingpoky.xml
index de672b5..c8bee36 100644
--- a/documentation/ref-manual/usingpoky.xml
+++ b/documentation/ref-manual/usingpoky.xml
@@ -631,6 +631,68 @@
 
 
 
+
+Build History SDK Information
+
+Build history collects similar information on the contents
+of SDKs (for example, meta-toolchain
+or bitbake -c populate_sdk imagename)
+to that which it collects for images.
+The files produced for each SDK are as follows:
+
+files-in-sdk.txt:
+A list of files in the SDK with permissions,
+owner, group, size, and symlink information.
+This includes both the host and target parts
+of the SDK.
+
+sdk-info.txt:
+A text file containing name-value pairs with 
information
+about the SDK.
+See the following listing example for more information.
+
+Under each of the 
host and 
+target directories (for the 
portions of the
+SDK that run on the host and on the target 
respectively):
+
+depends.dot:
+Dependency graph for the SDK that is
+compatible with graphviz.
+
+
installed-package-names.txt:
+A list of installed packages by name 
only.
+
installed-package-sizes.txt:
+A list of installed packages ordered by size.
+
+
installed-packages.txt:
+A list of installed packages with full package
+filenames.
+
+
+
+
+
+
+Here is an example of sdk-info.txt:
+
+DISTRO = poky
+DISTRO_VERSION = 1.3+snapshot-20130327
+SDK_NAME = poky-eglibc-i686-arm
+SDK_VERSION = 1.3+snapshot
+SDKMACHINE = 
+SDKIMAGE_FEATURES = dev-pkgs dbg-pkgs
+BAD_RECOMMENDATIONS = 
+SDKSIZE = 352712
+
+Other than SDKSIZE, which is the
+total size of the files in the SDK in Kbytes, the
+name-value pairs are variables that may have influenced the
+content of the SDK.
+This information is often useful when you are trying to 
determine
+why a change in the package or file listings has occurred.
+
+
+
 
 Examining Build History Information
 
-- 
1.7.10.4

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


[yocto] [yocto-docs][PATCH 2/5] ref-manual: add info on buildhistory SRCREV value collection

2013-04-03 Thread Paul Eggleton
Buildhistory now collects information on SRCREV values for recipes
fetched from a version control system e.g. Git; additionally a
buildhistory-collect-srcrevs tool is provided to gather this and
convert it to a format suitable for inclusion in global configuration.
Add information on these new features to the appropriate section.

Signed-off-by: Paul Eggleton 
---
 documentation/ref-manual/usingpoky.xml |   52 
 1 file changed, 52 insertions(+)

diff --git a/documentation/ref-manual/usingpoky.xml 
b/documentation/ref-manual/usingpoky.xml
index c8bee36..101411c 100644
--- a/documentation/ref-manual/usingpoky.xml
+++ b/documentation/ref-manual/usingpoky.xml
@@ -545,6 +545,58 @@
 busybox-staticdev busybox-locale
 
 
+
+
+Finally, for those recipes that are fetched from a version 
control
+system (such as Git) there is a file that lists the source 
revision(s)
+specified in the recipe and the actual revision used when 
building
+(which may be different when SRCREV is 
set to
+${AUTOREV} for example). Here is an 
example
+of one of these files:
+
buildhistory/packages/emenlow-poky-linux/linux-yocto/latest_srcrev):
+
+ # SRCREV_machine = "b5c37fe6e24eec194bb29d22fdd55d73bcc709bf"
+ SRCREV_machine = "b5c37fe6e24eec194bb29d22fdd55d73bcc709bf"
+ # SRCREV_emgd = "caea08c988e0f41103bbe18eafca20348f95da02"
+ SRCREV_emgd = "caea08c988e0f41103bbe18eafca20348f95da02"
+ # SRCREV_meta = "c2ed0f16fdec628242a682897d5d86df4547cf24"
+ SRCREV_meta = "c2ed0f16fdec628242a682897d5d86df4547cf24"
+
+You can use the 
buildhistory-collect-srcrevs
+command to collect the stored SRCREV 
values
+from build history and report them in a format suitable for 
use in
+global configuration (for example, local.conf or a distro 
include
+file) to override floating AUTOREV values to a fixed set of 
revisions.
+Here is some example output from this command:
+
+ # emenlow-poky-linux
+ SRCREV_machine_pn-linux-yocto = "b5c37fe6e24eec194bb29d22fdd55d73bcc709bf"
+ SRCREV_emgd_pn-linux-yocto = "caea08c988e0f41103bbe18eafca20348f95da02"
+ SRCREV_meta_pn-linux-yocto = "c2ed0f16fdec628242a682897d5d86df4547cf24"
+ # core2-poky-linux
+ SRCREV_pn-kmod = "62081c0f68905b22f375156d4532fd37fa5c8d33"
+ SRCREV_pn-blktrace = "d6918c8832793b4205ed3bfede78c2f915c23385"
+ SRCREV_pn-opkg = "649"
+
+Some notes on using the 
buildhistory-collect-srcrevs
+command:
+
+By default only values where the SRCREV was
+not hardcoded (usually when AUTOREV was used) are 
reported
+- use the -a option to see all 
SRCREV
+values.
+The output statements may not have any 
effect
+in the face of overrides applied elsewhere in the 
build system
+configuration; use the -f option 
to add the
+forcevariable override to each 
output line
+if you need to work around this.
+The script does not do any special 
handling for
+building for multiple machines; however it does place a
+comment before each set of values specifying which 
triplet
+(for example emenlow-poky-linux) 
that they
+belong to as shown above.
+
+
 
 
 
-- 
1.7.10.4

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


[yocto] [yocto-docs][PATCH 3/5] ref-manual: add preamble to buildhistory section on top-level contents

2013-04-03 Thread Paul Eggleton
Add a paragraph to the top of the section on buildhistory mentioning the
metadata-revs file and the top-level directories.

Signed-off-by: Paul Eggleton 
---
 documentation/ref-manual/usingpoky.xml |8 
 1 file changed, 8 insertions(+)

diff --git a/documentation/ref-manual/usingpoky.xml 
b/documentation/ref-manual/usingpoky.xml
index 101411c..25a2259 100644
--- a/documentation/ref-manual/usingpoky.xml
+++ b/documentation/ref-manual/usingpoky.xml
@@ -503,6 +503,14 @@
 
 
 
+At the top level, there is a metadata-revs 
file
+listing the revisions of the repositories for the layers enabled
+when the build was produced. The rest of the data is split into 
separate
+packages, images and
+sdk directories, the contents of which are
+described below.
+
+
 
 Build History Package Information
 
-- 
1.7.10.4

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


[yocto] [yocto-docs][PATCH 4/5] Update layer.conf examples to reflect current practice

2013-04-03 Thread Paul Eggleton
* BBFILES should be appended to with +=
* BBPATH should be appended to with .=
* Immediate expansion is not necessary for BBFILE_PRIORITY
* Immediate expansion is not necessary for references in layer.conf
  to LAYERDIR since these are automatically expanded at the end of
  parsing the file (and have been for some time).
* Add collection name override to BBFILE_PRIORITY example
* Fix comments referring to old structure ("packages directory" or
  "recipes directory")

Signed-off-by: Paul Eggleton 
---
 documentation/bsp-guide/bsp.xml|   10 
 .../dev-manual/dev-manual-common-tasks.xml |   27 +---
 documentation/ref-manual/ref-variables.xml |6 ++---
 3 files changed, 19 insertions(+), 24 deletions(-)

diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml
index 5c34bfd..8c0a344 100644
--- a/documentation/bsp-guide/bsp.xml
+++ b/documentation/bsp-guide/bsp.xml
@@ -312,14 +312,14 @@
 

  # We have a conf and classes directory, add to BBPATH
- BBPATH := "${BBPATH}:${LAYERDIR}"
+ BBPATH .= ":${LAYERDIR}"
 
- # We have a recipes directory, add to BBFILES
- BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*.bb \
+ # We have recipes-* directories, add to BBFILES
+ BBFILES += "${LAYERDIR}/recipes-*/*.bb \
  ${LAYERDIR}/recipes-*/*.bbappend"
 
  BBFILE_COLLECTIONS += "bsp"
- BBFILE_PATTERN_bsp := "^${LAYERDIR}/"
+ BBFILE_PATTERN_bsp = "^${LAYERDIR}/"
  BBFILE_PRIORITY_bsp = "6"
 
 
@@ -329,7 +329,7 @@
 Bay conf/layer.conf file:

  BBFILE_COLLECTIONS += "crownbay"
- BBFILE_PATTERN_crownbay := "^${LAYERDIR}/"
+ BBFILE_PATTERN_crownbay = "^${LAYERDIR}/"
  BBFILE_PRIORITY_crownbay = "6"
 
 
diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml 
b/documentation/dev-manual/dev-manual-common-tasks.xml
index 43dc61f..a697b8c 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -106,14 +106,14 @@
required syntax:

  # We have a conf and classes directory, add to BBPATH
- BBPATH := "${BBPATH}:${LAYERDIR}"
+ BBPATH .= ":${LAYERDIR}"
 
- # We have a packages directory, add to BBFILES
- BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+ # We have recipes-* directories, add to BBFILES
+ BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
  ${LAYERDIR}/recipes-*/*/*.bbappend"
 
  BBFILE_COLLECTIONS += "yoctobsp"
- BBFILE_PATTERN_yoctobsp := "^${LAYERDIR}/"
+ BBFILE_PATTERN_yoctobsp = "^${LAYERDIR}/"
  BBFILE_PRIORITY_yoctobsp = "5"
 
 Here is an explanation of the example:
@@ -148,9 +148,9 @@
 used to match files from
 BBFILES into a particular
 layer.
-In this case, immediate expansion of
+In this case,
 LAYERDIR
-sets BBFILE_PATTERN to the
+is used to make 
BBFILE_PATTERN match within the
 layer's path.
 The
 BBFILE_PRIORITY
@@ -162,10 +162,7 @@
 
 Note the use of the
 LAYERDIR
-variable with the immediate expansion operator.
-The LAYERDIR variable expands to 
the directory of the current layer and
-requires the immediate expansion operator so that 
BitBake does not wait to expand the variable
-when it's parsing a different directory.
+variable, which expands to the directory of the 
current layer.
 Through the use of the 
BBPATH variable,
 BitBake locates .bbclass files, 
configuration
 files, and files that are included with 
include
@@ -402,7 +399,7 @@
 variable.
 For example:
 
- BBFILE_PRIORITY := "1"
+ BBFILE_PRIORITY_mylayer = "1"
 
 
 
@@ -1938,14 +1935,14 @@
 the layer.conf file as follows:
 
  # We have a conf and classes directory, add to BBPATH
- BBPATH := "${BBPATH}:${LAYERDIR}"
+ BBPATH .= ":${LAYERDIR}"
 
- # We have a packages directory, add to BBFILES
- BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+ # We have recipes-* directories, add to BBFILES
+ BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
  ${LAYERDIR}/recipes-*/*/*.bbappend"

[yocto] [yocto-docs][PATCH 5/5] dev-manual: add new bitbake-layers show-cross-depends subcommand

2013-04-03 Thread Paul Eggleton
Signed-off-by: Paul Eggleton 
---
 documentation/dev-manual/dev-manual-common-tasks.xml |3 +++
 1 file changed, 3 insertions(+)

diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml 
b/documentation/dev-manual/dev-manual-common-tasks.xml
index a697b8c..66df375 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -446,6 +446,9 @@
 
show-appends:
 Lists .bbappend files and the 
recipe files to which
 they apply.
+
show-cross-depends:
+Lists dependency relationships between recipes that 
cross layer boundaries.
+
 
flatten:
 Flattens the layer configuration into a separate 
output directory.
 Flattening your layer configuration builds a 
"flattened" directory that contains
-- 
1.7.10.4

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


Re: [yocto] [PATCH] Remove clutter project templates

2013-04-03 Thread Zhang, Jessica
Hi Paul,

We removed clutter project templates just because we found that the underline 
package support for it is no longer there(in core-image-sato) and assume that 
there's a reason for the change.  I'm in the same boat as you that by no means 
I'm an expert with clutter thus don't know how popular it's among developers. 
But base on my limited experiment with it when adding the template support in 
Eclipse, it seems a pretty neat framework for adding animation support, etc. 
and can be useful  for new application developers doing the work.

Thanks,
Jessica



-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Paul Eggleton
Sent: Wednesday, April 03, 2013 1:58 AM
To: Grigoropol, IoanaX
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] [PATCH] Remove clutter project templates

On Wednesday 03 April 2013 08:42:23 Grigoropol, IoanaX wrote:
> Paul Eggleton wrote:
> > On Tuesday 12 March 2013 18:05:33 Ioana Grigoropol wrote:
> > > - support for clutter was removed from core-image-sato along with
> > > clutter-box2d and thus the project templates in Eclipse should not
> > > be supported anymore; gtk templates should be used instead
> >
> > The removal of clutter-box2d doesn't signal that clutter itself is
> > unsupported, so I think maybe we shouldn't be removing these
> > templates just yet.
>
> In my opinion, since clutter was only brought in core-image-sato and
> core-image-sato-sdk by clutter-box2d, and not independently, it means
> it was not really intended to support it.

Possibly; the other alternative is that nobody had really considered the 
question of whether or not it should be included. I'm unsure as to which is the 
case here.

> Do you think there should be support for clutter in the sdk images ?

I would say it depends on whether we believe it will be useful to new 
application developers, or we're just keeping it around for compatibility with 
existing applications. I can see it being useful but I'd probably like to hear 
from Jessica and others as well.

> Clutter + dependencies is not a small package and was only getting
> into images through testapps feature, and we could use gtk templates instead.

True, but Gtk+ and Clutter aren't quite the same thing. I'm not an expert on 
Clutter by any means but I believe it provides a much better framework for 
animations and non-traditional UIs than Gtk+ does.

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] Easy one: fetch fails

2013-04-03 Thread Saridakis, Dean (US SSA)
I've got the yocto basics, but sill a novice.

I'm starting w/ an SDK based on yocto & am trying to add canutil to the build. 
There's already a recipe in meta-oe, but unfortunately I can't get through my 
corporate firewall w/ the git protocol. However I can w/ http. So I added a 
layer w/ a bbppend to change the SRC_URI

from "git://git.pengutronix.de/git/tools/canutils.git;protocol=git;tag=${TAG}"
to "http://git.pengutronix.de/git/tools/canutils.git;protocol=http;tag=${TAG}";

(and similarly for libsocketcan). If there's simpler/cleaner way to do this I'm 
open to suggestions.

Problem is the fetch fails w/
ERROR: Fetcher failure for URL: 
'http://git.pengutronix.de/git/tools/canutils.git'. The fetch command returned 
success for url http://git.pengutronix.de/git/tools/canutils.git but 
/home/ds/QorIQ-SDK-V1.3-20121114-yocto/build_p5020ds_release/../sources/canutils.git
 doesn't exist?!

I am able to manually do a git clone w/ the http url. (thought about manually 
forcing the file into the source dir, but wasn't sure exactly what's expected, 
especially w/ the tag - still a git novice as well)

Thanks,

Dean

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


Re: [yocto] Easy one: fetch fails

2013-04-03 Thread Burton, Ross
On 3 April 2013 19:52, Saridakis, Dean   (US SSA)
 wrote:
> from
> "git://git.pengutronix.de/git/tools/canutils.git;protocol=git;tag=${TAG}"
>
> to
> "http://git.pengutronix.de/git/tools/canutils.git;protocol=http;tag=${TAG}”

Don't change the leading git: to http:, as then you're not using the
git fetcher anymore.  You just need to change proto=git to proto=http.

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


Re: [yocto] This one can't be me...

2013-04-03 Thread Paul D. DeRocco
> From: Darren Hart
>
> The most obvious question is whether or not the kernel you built has
> ramdisk support. You can do this by analyzing the .config file in your
> linux-yocto build tree
> (build/tmp/work/cedartrail.../linux-yocto*/linux-cedartrail-st
> andard-build/.config).
> You want to look for:
> 
> $ grep BLK_DEV_RAM .config
> CONFIG_BLK_DEV_RAM=y
> CONFIG_BLK_DEV_RAM_COUNT=16
> CONFIG_BLK_DEV_RAM_SIZE=4096

That directory (full path is
/home/pauld/yocto-atom/build/tmp/work/cedartrail_nopvr-poky-linux/linux-yoct
o-3.0.32+git1+a4ac64fe873f08ef718e2849b88914725dc99c1c_1+1e79e03d115ed177882
ab53909a4f3555e434833-r4.1/linux-cedartrail-nopvr-standard-build) is
completely empty. Yes, I know it's supposed to be a hidden file. This is
right after completing a "successful" build of core-image-sato.

> Well, see my comment above, the kernel was about as explicit as it can
> be - it didn't find a block device to mount as root. However, when
> debugging kernel issues, it is important to be able to record the log.
> You have a serial port console configured in your kernel parameters
> (console=ttyS0,115200), it would be a good idea to connect to 
> the serial
> console and capture the boot messages to a file using minicom, screen,
> or similar.

Done. Attached.

> Another common problem is the hddimg format itself and conflicts with
> certain firmware. You can try the zip image format as described in
> poky/README.hardware under the "Intel Atom based PCs and 
> devices" section.

Tried that, same result.

> Finally, usb sticks are terrible about just being bad. Many 
> of them are
> literally write once devices. They're fine so long as you don't fill
> them up, which works for shuffling small files around, but 
> writing full
> OS images to them tends to kill them in a hurry. Try with a 
> brand new stick.

Tried a fresh one, same results. I'm using a 1GB eUSB SSD, which is
basically an industrial grade flash drive that uses SLC memory, on a card
that sits on the mobo USB header. The image doesn't come close to filling it
up. I've successfully done a live-image boot of full Ubuntu from the 2GB
version of the same drive (same vendor).

It smells to me like that first problem is the real one. Should I try a
clean rebuild? Is there anything I can do short of nuking the entire build
tree with its downloads to ensure a clean rebuild? Or would that be like
waving a dead chicken over it?

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 
Linux version 3.0.32-yocto-standard (pauld@Chroma) (gcc version 4.7.2 (GCC) ) 
#1 SMP Fri Mar 1 07:34:08 PST 2013
Disabled fast string operations
BIOS-provided physical RAM map:
 BIOS-e820:  - 0008f000 (usable)
 BIOS-e820: 0008f000 - 0009 (reserved)
 BIOS-e820: 0009 - 0009e800 (usable)
 BIOS-e820: 0009e800 - 000a (reserved)
 BIOS-e820: 000e - 0010 (reserved)
 BIOS-e820: 0010 - 3ee95000 (usable)
 BIOS-e820: 3ee95000 - 3eebf000 (reserved)
 BIOS-e820: 3eebf000 - 3000 (usable)
 BIOS-e820: 3000 - 3efbf000 (ACPI NVS)
 BIOS-e820: 3efbf000 - 3efef000 (usable)
 BIOS-e820: 3efef000 - 3efff000 (ACPI data)
 BIOS-e820: 3efff000 - 3f00 (usable)
 BIOS-e820: 3f00 - 4000 (reserved)
 BIOS-e820: e000 - e400 (reserved)
 BIOS-e820: ffe0 - 0001 (reserved)
Notice: NX (Execute Disable) protection cannot be enabled: non-PAE kernel!
DMI 2.7 present.
last_pfn = 0x3f000 max_arch_pfn = 0x10
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
found SMP MP-table at [c00fbe40] fbe40
init_memory_mapping: -377fe000
ACPI: RSDP 000f2240 00024 (v02 INTEL )
ACPI: XSDT 3effe120 00064 (v01 INTEL  DN2800MT 0098  0113)
ACPI: FACP 3eff6000 000F4 (v03 INTEL  DN2800MT 0098 MSFT 010D)
ACPI: DSDT 3eff8000 05C91 (v02 INTEL  DN2800MT 0098 MSFT 010D)
ACPI: FACS 3ef85000 00040
ACPI: SSDT 3eff7000 0043E (v01 INTEL  DN2800MT 0098 MSFT 010D)
ACPI: APIC 3eff5000 00084 (v02 INTEL  DN2800MT 0098 MSFT 010D)
ACPI: MCFG 3eff4000 0003C (v01 INTEL  DN2800MT 0098 MSFT 010D)
ACPI: HPET 3eff3000 00038 (v01 INTEL  DN2800MT 0098 MSFT 010D)
ACPI: SSDT 3eff1000 00655 (v01  PmRefCpuPm 3000 INTL 20061109)
ACPI: SSDT 3eff 00259 (v01  PmRef  Cpu0Tst 3000 INTL 20061109)
ACPI: SSDT 3efef000 0020F (v01  PmRefApTst 3000 INTL 20061109)
120MB HIGHMEM available.
887MB LOWMEM available.
  mapped low ram: 0 - 377fe000
  low ram: 0 - 377fe000
Zone PFN ranges:
  DMA  0x0010 -> 0x1000
  Normal   0x1000 -> 0x000377fe
  HighMem  0x000377fe -> 0x0003f000
Movable zone start PFN for each node
early_node_map[6] active PFN ranges
0: 0x0010 -> 0x008f
0: 0x0090 -> 0x00

Re: [linux-yocto] [PATCH 0/1][linux-yocto-3.8]meta: update atom-pc-wifi.cfg for audit purposes

2013-04-03 Thread Bruce Ashfield

On 13-04-03 03:49 AM, Hongxu Jia wrote:

The following changes since commit 1b534b2f8bbe9b8a773268cfa30a4850346f6f5f:

   meta: preempt-rt, inherit standard config (2013-03-25 13:36:42 -0700)


Thanks for the change.

I've staged the change locally, I'll have it pushed out in the
next day or so.

Cheers,

Bruce



are available in the git repository at:

   git://git.pokylinux.org/poky-contrib hongxu/fix-atompc-kernel-warn
   
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/fix-atompc-kernel-warn

Hongxu Jia (1):
   meta: update atom-pc-wifi.cfg for audit purposes

  meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-wifi.cfg |   11 ++-
  1 file changed, 2 insertions(+), 9 deletions(-)



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


Re: [yocto] This one can't be me...

2013-04-03 Thread Darren Hart


On 04/03/2013 12:57 PM, Paul D. DeRocco wrote:
>> From: Darren Hart
>>
>> The most obvious question is whether or not the kernel you built has
>> ramdisk support. You can do this by analyzing the .config file in your
>> linux-yocto build tree
>> (build/tmp/work/cedartrail.../linux-yocto*/linux-cedartrail-st
>> andard-build/.config).
>> You want to look for:
>>
>> $ grep BLK_DEV_RAM .config
>> CONFIG_BLK_DEV_RAM=y
>> CONFIG_BLK_DEV_RAM_COUNT=16
>> CONFIG_BLK_DEV_RAM_SIZE=4096
> 
> That directory (full path is
> /home/pauld/yocto-atom/build/tmp/work/cedartrail_nopvr-poky-linux/linux-yoct
> o-3.0.32+git1+a4ac64fe873f08ef718e2849b88914725dc99c1c_1+1e79e03d115ed177882
> ab53909a4f3555e434833-r4.1/linux-cedartrail-nopvr-standard-build) is
> completely empty. Yes, I know it's supposed to be a hidden file. This is
> right after completing a "successful" build of core-image-sato.


Are you building with the rm work setting? Otherwise, that should not be
empty unless you have more than one linux-yocto* directory and the other
is populated.

If not, verify rm work is not on and just build the kernel:

$ bitbake linux-yocto -c cleansstate
$ bitbake linux-yocto

>> Well, see my comment above, the kernel was about as explicit as it can
>> be - it didn't find a block device to mount as root. However, when
>> debugging kernel issues, it is important to be able to record the log.
>> You have a serial port console configured in your kernel parameters
>> (console=ttyS0,115200), it would be a good idea to connect to 
>> the serial
>> console and capture the boot messages to a file using minicom, screen,
>> or similar.
> 
> Done. Attached.
> 

Nothing in there suggests any other failure than it just didn't find a
block device. I didn't see anything in there about loading the initrd
though (I think there usually is...). Check to make sure the initrd file
does indeed exist on the boot drive.

>> Another common problem is the hddimg format itself and conflicts with
>> certain firmware. You can try the zip image format as described in
>> poky/README.hardware under the "Intel Atom based PCs and 
>> devices" section.
> 
> Tried that, same result.


That would hint at either a problem with the initrd or a lack of support
in the kernel.


>> Finally, usb sticks are terrible about just being bad. Many 
>> of them are
>> literally write once devices. They're fine so long as you don't fill
>> them up, which works for shuffling small files around, but 
>> writing full
>> OS images to them tends to kill them in a hurry. Try with a 
>> brand new stick.
> 
> Tried a fresh one, same results. I'm using a 1GB eUSB SSD, which is
> basically an industrial grade flash drive that uses SLC memory, on a card
> that sits on the mobo USB header. The image doesn't come close to filling it
> up. I've successfully done a live-image boot of full Ubuntu from the 2GB
> version of the same drive (same vendor).
> 
> It smells to me like that first problem is the real one. Should I try a
> clean rebuild? Is there anything I can do short of nuking the entire build
> tree with its downloads to ensure a clean rebuild? Or would that be like
> waving a dead chicken over it?

The nuke is the big hammer, try the slightly more subtle linux-yocto
rebuild without rm-work as described above.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] This one can't be me...

2013-04-03 Thread Paul D. DeRocco
> From: Darren Hart [mailto:dvh...@linux.intel.com] 
> 
> Are you building with the rm work setting? Otherwise, that 
> should not be
> empty unless you have more than one linux-yocto* directory 
> and the other is populated.

That option is off, and there is no other linux-yocto* directory.

> If not, verify rm work is not on and just build the kernel:
> 
> $ bitbake linux-yocto -c cleansstate
> $ bitbake linux-yocto

The first line says there is no do_cleanstate task for linux-yocto, and so
the second line finds nothing to do. Is there another way to force that?

> Nothing in there suggests any other failure than it just didn't find a
> block device. I didn't see anything in there about loading the initrd
> though (I think there usually is...). Check to make sure the 
> initrd file does indeed exist on the boot drive.

Yes, it does.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 

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


Re: [yocto] This one can't be me...

2013-04-03 Thread Bodke, Kishore K


>-Original Message-
>From: yocto-boun...@yoctoproject.org [mailto:yocto-
>boun...@yoctoproject.org] On Behalf Of Paul D. DeRocco
>Sent: Wednesday, April 03, 2013 1:50 PM
>To: 'Darren Hart'
>Cc: yocto@yoctoproject.org
>Subject: Re: [yocto] This one can't be me...
>
>> From: Darren Hart [mailto:dvh...@linux.intel.com]
>>
>> Are you building with the rm work setting? Otherwise, that
>> should not be
>> empty unless you have more than one linux-yocto* directory
>> and the other is populated.
>
>That option is off, and there is no other linux-yocto* directory.
>
>> If not, verify rm work is not on and just build the kernel:
>>
>> $ bitbake linux-yocto -c cleansstate
>> $ bitbake linux-yocto
>
>The first line says there is no do_cleanstate task for linux-yocto, and so
>the second line finds nothing to do. Is there another way to force that?
>

It's surprising that you don't see anything under 
/home/pauld/yocto-atom/build/tmp/work/cedartrail_nopvr-poky-linux/linux-yoct
o-3.0.32+git1+a4ac64fe873f08ef718e2849b88914725dc99c1c_1+1e79e03d115ed177882
ab53909a4f3555e434833-r4.1/linux-cedartrail-nopvr-standard-build

It means that Kernel is not getting build for you?
How come you were able to generate the .hddimg and trying to boot?

Do you have the rootfs under build/tmp/work/Cedartrail*/core-image-sato/?

Thanks
Kishore.


>> Nothing in there suggests any other failure than it just didn't find a
>> block device. I didn't see anything in there about loading the initrd
>> though (I think there usually is...). Check to make sure the
>> initrd file does indeed exist on the boot drive.
>
>Yes, it does.
>
>--
>
>Ciao,   Paul D. DeRocco
>Paulmailto:pdero...@ix.netcom.com
>
>___
>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] This one can't be me...

2013-04-03 Thread Darren Hart


On 04/03/2013 01:50 PM, Paul D. DeRocco wrote:
>> From: Darren Hart [mailto:dvh...@linux.intel.com] 
>>
>> Are you building with the rm work setting? Otherwise, that 
>> should not be
>> empty unless you have more than one linux-yocto* directory 
>> and the other is populated.
> 
> That option is off, and there is no other linux-yocto* directory.
> 
>> If not, verify rm work is not on and just build the kernel:
>>
>> $ bitbake linux-yocto -c cleansstate
>> $ bitbake linux-yocto
> 
> The first line says there is no do_cleanstate task for linux-yocto, and so
> the second line finds nothing to do. Is there another way to force that?

This doesn't make any sense. Can you send the actual output rather than
interpreting please?

Oh, actually, please read the command more carefully, there are two ss's in
cleansstate.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [PATCH] [poky-extras] linux-yocto*3.8: Add bbappend for linux-yocto 3.8 recipes

2013-04-03 Thread Darren Hart
Enable meta-kernel-dev support for the 3.8 kernels.

Signed-off-by: Darren Hart 
---
 .../linux/linux-yocto-rt_3.8.bbappend  |   25 
 .../recipes-kernel/linux/linux-yocto_3.8.bbappend  |   25 
 2 files changed, 50 insertions(+), 0 deletions(-)
 create mode 100644 
meta-kernel-dev/recipes-kernel/linux/linux-yocto-rt_3.8.bbappend
 create mode 100644 
meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.8.bbappend

diff --git a/meta-kernel-dev/recipes-kernel/linux/linux-yocto-rt_3.8.bbappend 
b/meta-kernel-dev/recipes-kernel/linux/linux-yocto-rt_3.8.bbappend
new file mode 100644
index 000..18eab0d
--- /dev/null
+++ b/meta-kernel-dev/recipes-kernel/linux/linux-yocto-rt_3.8.bbappend
@@ -0,0 +1,25 @@
+FILESEXTRAPATHS := "${THISDIR}/${PN}"
+
+COMPATIBLE_MACHINE = "${MACHINE}"
+
+# Note: put these in your local.conf to avoid multi-kernel build errors
+# PREFERRED_VERSION_linux-yocto-rt_${MACHINE} = "3.8%"
+
+# KMACHINE is the branch to build
+# KMACHINE_ ?= "yocto/${LINUX_KERNEL_TYPE}/${KMACHINE}"
+
+# KERNEL_FEATURES are features to be added to the kernel, and must
+# point to configurations stored on the 'meta' branch of the kernel
+# that is being built.
+# KERNEL_FEATURES ?= 
+
+# It is often nice to have a local clone of the kernel repos, to
+# allow patches to be staged, branches created, etc. Modify
+
+# KSRC_linux_yocto_3_8 to point to your local clone as appropriate.
+# KSRC_linux_yocto_3_8 ?= "/path/to/local/linux-yocto-3.8.git/"
+#SRC_URI = 
"git://${KSRC_linux_yocto_3_8};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
+
+SRCREV_machine_${MACHINE}="${AUTOREV}"
+SRCREV_meta="${AUTOREV}"
+LOCALCOUNT = "0"
diff --git a/meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.8.bbappend 
b/meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.8.bbappend
new file mode 100644
index 000..9e61e33
--- /dev/null
+++ b/meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.8.bbappend
@@ -0,0 +1,25 @@
+FILESEXTRAPATHS := "${THISDIR}/${PN}"
+
+COMPATIBLE_MACHINE = "${MACHINE}"
+
+# Note: put these in your local.conf to avoid multi-kernel build errors
+# PREFERRED_VERSION_linux-yocto_${MACHINE} = "3.8%"
+
+# KMACHINE is the branch to build
+# KMACHINE_ ?= "yocto/${LINUX_KERNEL_TYPE}/${KMACHINE}"
+
+# KERNEL_FEATURES are features to be added to the kernel, and must
+# point to configurations stored on the 'meta' branch of the kernel
+# that is being built.
+# KERNEL_FEATURES ?= 
+
+# It is often nice to have a local clone of the kernel repos, to
+# allow patches to be staged, branches created, etc. Modify
+
+# KSRC_linux_yocto_3_8 to point to your local clone as appropriate.
+# KSRC_linux_yocto_3_8 ?= "/path/to/local/linux-yocto-3.8.git/"
+# SRC_URI = 
"git://${KSRC_linux_yocto_3_8};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
+
+SRCREV_machine_${MACHINE}="${AUTOREV}"
+SRCREV_meta="${AUTOREV}"
+LOCALCOUNT = "0"
-- 
1.7.5.4

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


Re: [yocto] Easy one: fetch fails

2013-04-03 Thread John Williams
> I'm starting w/ an SDK based on yocto & am trying to add canutil to the build.
> There's already a recipe in meta-oe, but unfortunately I can't get through my
> corporate firewall w/ the git protocol. However I can w/ http. So I added a 
> layer
> w/ a bbppend to change the SRC_URI

Alternatively just use corkscrew to tunnel git via your company's http proxy:

https://gforge.ti.com/gf/project/omapandroid/wiki/?pagename=Git+Firewall

John


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


Re: [yocto] This one can't be me...

2013-04-03 Thread Paul D. DeRocco
> From: Darren Hart
> 
> Are you building with the rm work setting? Otherwise, that 
> should not be
> empty unless you have more than one linux-yocto* directory 
> and the other
> is populated.
> 
> If not, verify rm work is not on and just build the kernel:
> 
> $ bitbake linux-yocto -c cleansstate
> $ bitbake linux-yocto

After doing that (with two esses), I now have a .config file, along with a
ton of other stuff, in that folder. I have no idea what made it disappear,
because I don't use the rm_work option.

However, the only BLK_DEV_RAM line is

# CONFIG_BLK_DEV_RAM is not set

I haven't been fiddling with the kernel, because I don't know how to fiddle
with the kernel. This should be a plain vanilla build.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 
  

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


Re: [yocto] This one can't be me...

2013-04-03 Thread Paul D. DeRocco
> From: Bodke, Kishore K
> 
> It's surprising that you don't see anything under 
> /home/pauld/yocto-atom/build/tmp/work/cedartrail_nopvr-poky-li
nux/linux-yoct
> o-3.0.32+git1+a4ac64fe873f08ef718e2849b88914725dc99c1c_1+1e79e
03d115ed177882
> ab53909a4f3555e434833-r4.1/linux-cedartrail-nopvr-standard-build
> 
> It means that Kernel is not getting build for you?
> How come you were able to generate the .hddimg and trying to boot?
> 
> Do you have the rootfs under 
> build/tmp/work/Cedartrail*/core-image-sato/?

Some gremlin made that first directory go away. I've successfully rebuilt
it.

There is a rootfs directory in the second directory, and it contains things
like /dev/ram?. I captured a tree listing of my build a while back, and it
had those device nodes, too.

If I loop mount the .ext3 file that my panicking build produced, it has
/dev/ram? device nodes, too.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 

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


Re: [yocto] [PATCH] [poky-extras] linux-yocto*3.8: Add bbappend for linux-yocto 3.8 recipes

2013-04-03 Thread Bruce Ashfield

On 13-04-03 6:16 PM, Darren Hart wrote:

Enable meta-kernel-dev support for the 3.8 kernels.


Acked-by: Bruce Ashfield 

I have something similar local to my machine that I hadn't gotten
around to pushing out.

Cheers,

Bruce



Signed-off-by: Darren Hart
---
  .../linux/linux-yocto-rt_3.8.bbappend  |   25 
  .../recipes-kernel/linux/linux-yocto_3.8.bbappend  |   25 
  2 files changed, 50 insertions(+), 0 deletions(-)
  create mode 100644 
meta-kernel-dev/recipes-kernel/linux/linux-yocto-rt_3.8.bbappend
  create mode 100644 
meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.8.bbappend

diff --git a/meta-kernel-dev/recipes-kernel/linux/linux-yocto-rt_3.8.bbappend 
b/meta-kernel-dev/recipes-kernel/linux/linux-yocto-rt_3.8.bbappend
new file mode 100644
index 000..18eab0d
--- /dev/null
+++ b/meta-kernel-dev/recipes-kernel/linux/linux-yocto-rt_3.8.bbappend
@@ -0,0 +1,25 @@
+FILESEXTRAPATHS := "${THISDIR}/${PN}"
+
+COMPATIBLE_MACHINE = "${MACHINE}"
+
+# Note: put these in your local.conf to avoid multi-kernel build errors
+# PREFERRED_VERSION_linux-yocto-rt_${MACHINE} = "3.8%"
+
+# KMACHINE is the branch to build
+# KMACHINE_  ?= "yocto/${LINUX_KERNEL_TYPE}/${KMACHINE}"
+
+# KERNEL_FEATURES are features to be added to the kernel, and must
+# point to configurations stored on the 'meta' branch of the kernel
+# that is being built.
+# KERNEL_FEATURES ?=
+
+# It is often nice to have a local clone of the kernel repos, to
+# allow patches to be staged, branches created, etc. Modify
+
+# KSRC_linux_yocto_3_8 to point to your local clone as appropriate.
+# KSRC_linux_yocto_3_8 ?= "/path/to/local/linux-yocto-3.8.git/"
+#SRC_URI = 
"git://${KSRC_linux_yocto_3_8};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
+
+SRCREV_machine_${MACHINE}="${AUTOREV}"
+SRCREV_meta="${AUTOREV}"
+LOCALCOUNT = "0"
diff --git a/meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.8.bbappend 
b/meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.8.bbappend
new file mode 100644
index 000..9e61e33
--- /dev/null
+++ b/meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.8.bbappend
@@ -0,0 +1,25 @@
+FILESEXTRAPATHS := "${THISDIR}/${PN}"
+
+COMPATIBLE_MACHINE = "${MACHINE}"
+
+# Note: put these in your local.conf to avoid multi-kernel build errors
+# PREFERRED_VERSION_linux-yocto_${MACHINE} = "3.8%"
+
+# KMACHINE is the branch to build
+# KMACHINE_  ?= "yocto/${LINUX_KERNEL_TYPE}/${KMACHINE}"
+
+# KERNEL_FEATURES are features to be added to the kernel, and must
+# point to configurations stored on the 'meta' branch of the kernel
+# that is being built.
+# KERNEL_FEATURES ?=
+
+# It is often nice to have a local clone of the kernel repos, to
+# allow patches to be staged, branches created, etc. Modify
+
+# KSRC_linux_yocto_3_8 to point to your local clone as appropriate.
+# KSRC_linux_yocto_3_8 ?= "/path/to/local/linux-yocto-3.8.git/"
+# SRC_URI = 
"git://${KSRC_linux_yocto_3_8};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
+
+SRCREV_machine_${MACHINE}="${AUTOREV}"
+SRCREV_meta="${AUTOREV}"
+LOCALCOUNT = "0"


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


[yocto] Weekly build availablity

2013-04-03 Thread Flanagan, Elizabeth
The weekly build is built and available at:

http://autobuilder.yoctoproject.org/pub/nightly/20130403-2

Known issues:
Due to Bug 4186 - bitbake package-index fails over NFS, the adt-ipk
package index was created and deployed by hand. I have a temp fix in
the autobuilder to work around this issue.

nightly-multilib failed due to lib64 issues. This is a known issue and
lib64 images are new targets.

nightly-fsl-arm* failed

poky-tiny failed

meta-intel 3de2325133eb581c5c8d66133821ea5a801cf8ae
meta-qt3 4c27cce6688aa39852f3cba5e7b80ec279019605
poky fe336b149552b1f4f24d979c40302653298b98cc
bitbake b5b4b6e4fefa6a164a49b291a0993b1ff63947f4
oecore ca36be708e54c0c86535bc8512295c76c48f6cf5
meta-fsl-ppc 6e861617d3f61bcddcc944835f331e387e12db46
meta-fsl-arm 666485e1835aaa34518464265980acfee250783d

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