[yocto] current poky ref manual doesn't document some top level yocto entries

2012-03-09 Thread Robert P. J. Day

  currently, the yocto/poky ref manual, Appendix A.1, Top level core
components, doesn't mention the entries meta-yocto or meta-hob.  it
also lists the meta-rt layer, which has been moved to oe-core.

  i also don't think it should list build, as that's a generated
artifact and is documented adequately elsewhere.

  in any event, the ref manual should be updated to reflect the
current yocto structure.

rday

-- 


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

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

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


[yocto] contradictory explanations of IMAGE_INSTALL in yocto manuals

2012-03-09 Thread Robert P. J. Day

  (i posted something regarding this on the oe-core list, but i wanted
to post here as well with specific examples from the yocto manuals.)

  from the yocto dev manual, section 4.3.1:

The other method for creating a custom image is to modify an existing
image. For example, if a developer wants to add strace into the
core-image-sato image, they can use the following recipe:

 require core-image-sato.bb

 IMAGE_INSTALL += strace

  however, here's the discussion of IMAGE_INSTALL in the poky ref
manual in the variables glossary:

Using IMAGE_INSTALL with the += operator from the /conf/local.conf
file or from within an image recipe is not recommended as it can cause
ordering issues.

... and that explanation goes on to recommend using
IMAGE_INSTALL_append instead.  that inconsistency should be cleared
up.

rday

-- 


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

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

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


Re: [yocto] Adding test files to an image

2012-03-09 Thread jfabernathy

On 03/08/2012 08:04 PM, Eric Bénard wrote:

Le Thu, 08 Mar 2012 17:38:40 -0500,
jfabernathyjfaberna...@gmail.com  a écrit :

So what I can get to work is the following recipe, but what I want is
not o have to specify the file extension:


you may be able to build your archive in a directory like :
myvideos-1.0/files.mp4, so that your files will be available in ${S} =
${WORKDIR}/myvideos-1.0/

Eric

Duh!  That was too easy. Not sure why it was not obvious to me.  Thanks,

So I put all my videos into a directory called myvideos-1.0 and tar 
gz'ed the whole directory.  now the following works:


DESCRIPTION = my video test files
SECTION = examples
LICENSE = CLOSED

MY_DESTINATION = /home/root/myvideos

SRC_URI = file://myvideos-1.0/myvideos-1.0.tar.gz

do_install_append() {
install -d ${D}${MY_DESTINATION}
install -m 0644 ${S}/* ${D}${MY_DESTINATION}
}

PR = r0

FILES_${PN} += ${MY_DESTINATION}/*
--

You just have to put your newly created tarball of the myvideos-1.0 
directory in the SRC_URI.


Thanks again,

JIm A

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


Re: [yocto] meta-toolchain-qte problems

2012-03-09 Thread praveenvk
Hi,
 
 I wish to create bsp for our project in which we are 
using arm1136 processor.  I have created a layer (meta_EB)
 same as meta for our project and have made required 
changes in conf file for meta_EB to get compiled.

I am trying to  bitbake -v meta-toolchain-qte, but it 
gives me an error when it reaches linux-libc-headers.

Following is the error I am getting:

NOTE: package update-rc.d-0.7-r3: task do_compile: Started
NOTE: package update-rc.d-0.7-r3: task do_compile: Succeeded
NOTE: Running task 2099 of 3217 (ID: 1368,
/home/navani/Yocto_Patches/poky-bernard-5.0/meta_EB/
recipes-core/update-rc.d/update-rc.d_0.7.bb,do_install)
NOTE: package update-rc.d-0.7-r3: task do_install: Started
NOTE: package update-rc.d-0.7-r3: task do_install: Succeeded
NOTE: Running noexec task 2100 of 3217 (ID: 939,
virtual:native:/home/navani/Yocto_Patches/poky-bernard-5.0/
meta_EB/recipes-devtools/bison/bison_2.4.3.bb,
do_package_write)
NOTE: Running noexec task 2101 of 3217 (ID: 925,
virtual:native:/home/navani/Yocto_Patches/poky-bernard-5.0/
meta_EB/recipes-devtools/flex/flex_2.5.35.bb,do_package_write)
NOTE: Running noexec task 2102 of 3217 (ID: 461,
virtual:native:/home/Yocto_Patches/poky-bernard-5.0/meta_EB/
recipes-support/libmpc/libmpc_0.8.2.bb,
do_package_write)
NOTE: Running noexec task 2103 of 3217 (ID: 447,
virtual:native:/home/Yocto_Patches/poky-bernard-5.0/meta_EB/
recipes-support/gmp/gmp_5.0.1.bb,
do_package_write)
NOTE: Running noexec task 2104 of 3217 (ID: 433,
virtual:native:/home/Yocto_Patches/poky-bernard-5.0/meta_EB/
recipes-support/mpfr/mpfr_3.0.0.bb,
do_package_write)
NOTE: Running task 2105 of 3217 (ID: 171,
/home/Yocto_Patches/poky-bernard-5.0/meta_EB/recipes-kernel/
linux-libc-headers/linux-libc-headers_2.6.37.2.bb,
do_package_write_rpm)
NOTE: package linux-libc-headers-2.6.37.2-r0: task do_package_w
rite_rpm: 
Started
NOTE: Creating RPM package for linux-libc-headers-dbg
NOTE: Not creating empty RPM package for linux-libc-headers
NOTE: Not creating empty RPM package for linux-libc-headers-doc
ERROR:
'/home//Yocto_Patches/poky-bernard-5.0/meta_EB/recipes-kernel/
linux-libc-headers/linux-libc-headers_2.6.37.2.bb'
failed
NOTE: Creating RPM package for linux-libc-headers-dev
NOTE: Not creating empty RPM package for linux-libc-
headers-locale
ERROR: Lockfile destination directory
'/home/Yocto_Patches/poky-bernard-5.0/build/tmp/deploy
/rpm' does not exist
ERROR: Function 'do_package_rpm' failed
ERROR: Logfile of failure stored in:
/home/Yocto_Patches/poky-bernard-5.0/build/tmp/work/
armv6-poky-linux-gnueabi/linux-libc-headers-2.6.37.2-r0/temp/log.do_package_write
_rpm.25095
Log data follows:
|NOTE: Creating RPM package for linux-libc-headers-dbg
|NOTE: Not creating empty RPM package for linux-libc-headers
|NOTE: Not creating empty RPM package for linux-libc-headers-doc
|NOTE: Creating RPM package for linux-libc-headers-dev
|NOTE: Not creating empty RPM package for linux-libc-headers-locale
|ERROR: Lockfile destination directory
'/home/Yocto_Patches/poky-bernard-5.0/build/tmp/deploy/rpm' 
does not exist
| ERROR: Function 'do_package_rpm' failed
NOTE: package linux-libc-headers-2.6.37.2-r0: task do_package_
write_rpm: Failed
ERROR: Task 171
(/home/Yocto_Patches/poky-bernard-5.0/meta_EB/
recipes-kernel/linux-libc-headers/linux-libc-headers_
2.6.37.2.bb,do_package_write_rpm

So what changes should I make and Could anyone please assist me 
with this problem?

Regards,
praveen vk


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


Re: [yocto] yocto and LTSI

2012-03-09 Thread Bob Cochran

On 03/09/2012 08:43 AM, Bruce Ashfield wrote:

On 12-03-09 07:20 AM, David Nyström wrote:

Hi All,

Whats yoctos take on LTSI ?

http://git.linuxfoundation.org/?p=ltsi-kernel.git;a=summary
http://lwn.net/Articles/484337/

I've noticed that LTT-ng and other kernel patches are independently
ported and maintained by the yocto project.
Are there any plans for yocto to have ltsi-kernel patches as upstream ?


We'll be syncing up with the ltsi kernel parts over the summer.
But yes, LTSI will be one of the sources used for yocto kernel trees.

Cheers,

Bruce





I just finished reviewing the slides for LTSI given at ELC: 
(https://events.linuxfoundation.org/images/stories/pdf/lf_elc12_shibata.pdf). 



Why does the Linux Foundation need to get behind yet another effort to 
maintain a kernel repository for embedded?  It seems that many of the 
objectives are the same for the two projects regarding the kernel.  Why 
not just branch a yearly Yocto kernel as long-term stable and add the 
support methodology outlined in the LTSI slides to this branch?  Perhaps 
this could also be done with the Poky repo?


How is a developer supposed to view Yocto and LTSI?  The former is 
cutting edge, developer friendly with all the bells  whistles, and 
experimental but use the latter for production???  Or maybe use the 
tools and rootfs from Yocto but the kernel from LTSI?


It seems Greg K-H of LTSI should join forces with Yocto and keep things 
simple  unified for us embedded developers (or Yocto should dump 
maintaining its own kernel repos and just draw from LTSI).



Bob






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


Re: [yocto] yocto and LTSI

2012-03-09 Thread Bruce Ashfield

On 12-03-09 09:36 AM, Bob Cochran wrote:

On 03/09/2012 08:43 AM, Bruce Ashfield wrote:

On 12-03-09 07:20 AM, David Nyström wrote:

Hi All,

Whats yoctos take on LTSI ?

http://git.linuxfoundation.org/?p=ltsi-kernel.git;a=summary
http://lwn.net/Articles/484337/

I've noticed that LTT-ng and other kernel patches are independently
ported and maintained by the yocto project.
Are there any plans for yocto to have ltsi-kernel patches as upstream ?


We'll be syncing up with the ltsi kernel parts over the summer.
But yes, LTSI will be one of the sources used for yocto kernel trees.

Cheers,

Bruce





I just finished reviewing the slides for LTSI given at ELC:
(https://events.linuxfoundation.org/images/stories/pdf/lf_elc12_shibata.pdf).


Why does the Linux Foundation need to get behind yet another effort to
maintain a kernel repository for embedded? It seems that many of the
objectives are the same for the two projects regarding the kernel. Why
not just branch a yearly Yocto kernel as long-term stable and add the
support methodology outlined in the LTSI slides to this branch? Perhaps
this could also be done with the Poky repo?


LTSI is still relatively new, a bit of patience is required for
us to effectively collaborate between the two areas.

But yocto will always have a newer kernel than LTSI as we work
throughout any given period. Quite simply put, there is no way to
have one kernel version that meets everyone's needs. That's always
been the case, and will likely continue to be the case for the
forseeable future.



How is a developer supposed to view Yocto and LTSI? The former is
cutting edge, developer friendly with all the bells  whistles, and
experimental but use the latter for production??? Or maybe use the tools
and rootfs from Yocto but the kernel from LTSI?


These sorts of things are still being worked out, when we actually
have a LSTI based yocto option, some sort of messaging will be
created.



It seems Greg K-H of LTSI should join forces with Yocto and keep things
simple  unified for us embedded developers (or Yocto should dump
maintaining its own kernel repos and just draw from LTSI).


I already have initial conact with Greg on sync'ing up my efforts with
LSTI.  Perhaps someday there will be a more complete overlap in the
two, but today there isn't a complete overlap, so there will be
additions to  LTSI that some boards/features/etc that yocto requires.
Those additions may degrade to zero over time. In fact, if everything
would just go mainline .. that would be even better.

Cheers,

Bruce




Bob






___
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] issue building iputils with uclibc

2012-03-09 Thread John Toomey

Hello all

I'm having problems compiling iputils with uclibc -

| ping6.o: In function `niquery_option_subject_name_handler':
| 
/tmp/work/i586-poky-linux-uclibc/iputils-s20101006-r2/iputils-s20101006/ping6.c:428: 
undefined reference to `dn_comp'

| collect2: ld returned 1 exit status
| make: *** [ping6] Error 1
| make: *** Waiting for unfinished jobs
| make[1]: Leaving directory 
`/tmp/work/i586-poky-linux-uclibc/iputils-s20101006-r2/iputils-s20101006/doc'

| ERROR: oe_runmake failed
NOTE: package iputils-s20101006-r2: task do_compile: Failed
ERROR: Task 4 (/poky/meta/recipes-extended/iputils/iputils_s20101006.bb, 
do_compile) failed with exit code '1'


It works fine with eglibc. Any help would be greatly appreciated!

Regards
John

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


Re: [yocto] issue building iputils with uclibc

2012-03-09 Thread Khem Raj
On Fri, Mar 9, 2012 at 7:18 AM, John Toomey john.too...@linux.intel.com wrote:
 undefined reference to `dn_comp'

add LDFLAGS_libc-uclibc_append =  -lresolv to recipe.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] contradictory explanations of IMAGE_INSTALL in yocto manuals

2012-03-09 Thread Rudolf Streif
I tried the versions _append and += as well as _prepend and =+ with the
IMAGE_INSTALL and other variables. So far I have not run into any issues
where one would behave differently from the other. The only thing you have
to remember with the _append and _prepend versions is that you have to
include a space at the beginning for _append and at the end for _prepend.
Although I have found that not always to be consistent either. However, an
additional space does not hurt.

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


Re: [yocto] contradictory explanations of IMAGE_INSTALL in yocto manuals

2012-03-09 Thread Rudolf Streif
I don't think that there is a difference. At least not from my experience.
Every time I have the choice I tried both variants and then examined the
resulting variable e.g.

bitbake recipe -e | grep IMAGE_INSTALL

It looked the same. My conclusion is to use += and =+ for variables and
_append and _prepend for tasks. But I could possibly be wrong since there
are definitely many more cases than I have tried. Hence, it would probably
be prudent to dig into Bitbake's code to see how it handles _append and
_prepend. I have not had time to do that.

Rudi

On Fri, Mar 9, 2012 at 8:56 AM, Robert P. J. Day rpj...@crashcourse.cawrote:

 On Fri, 9 Mar 2012, Rudolf Streif wrote:

  I tried the versions _append and += as well as _prepend and =+ with
  the IMAGE_INSTALL and other variables. So far I have not run into
  any issues where one would behave differently from the other. The
  only thing you have to remember with the _append and _prepend
  versions is that you have to include a space at the beginning for
  _append and at the end for _prepend. Although I have found that not
  always to be consistent either. However, an additional space does
  not hurt.

   well, as i mentioned, the manual suggests quite strongly that there
 is a fundamental difference.  i'd just like to understand clearly what
 that is.

 rday

 --

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

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

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


[yocto] propriety of asking OE-core questions on yocto list?

2012-03-09 Thread Robert P. J. Day

  i've decided to stop nibbling around the edges and, once and for
all, figure out OpenEmbedded from beginning to end.  to that end, i've
checked out oe-core and want to focus on just the fundamentals.

  the current openembedded manual here:

http://docs.openembedded.org/usermanual/usermanual.html

covers OE classic so it's not really appropriate to use as a guide.
the more recent OE material (incorporating the
oe-core/meta-openbmbedded distinction) appears to be incorporated in
the yocto[poky] reference manual:

http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html

so it would make more sense to use the yocto reference manual as my
guide, even though i would be asking fundamental questions about
oe-core.

  which is the right forum for that?  certainly the topic would be OE,
but any suggestions for improvements to the docs would be a yocto
issue.

rday

-- 


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

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

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


Re: [yocto] [KERNEL] [PATCH 0/1] Additional pvr patches

2012-03-09 Thread Bruce Ashfield

On 12-03-09 02:03 PM, kishore.k.bo...@intel.com wrote:

From: Kishore Bodkekishore.k.bo...@intel.com


Hi,

These addtional patches enable Cedarview hdmi and acpi.
Please pull thme to the yocto/pvr branch in linux-yocto-3.0 tree.


Looks fine. will Merge it shortly and send a confirmation.

Bruce



Thanks
Kishore.


The following changes since commit 3604d007243d3db5fea8704f78a3608862e592f9:

   yocto/pvr: integrate pvr support (2012-03-02 16:34:43 -0500)

are available in the git repository at:
   git://git.pokylinux.org/linux-yocto-2.6.37-contrib bodke/new-pvr-patch
   
http://git.pokylinux.org/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=bodke/new-pvr-patch

Kishore Bodke (1):
   Add new pvr patches. Additional pvr patches related to hdmi and
 acpi.

  drivers/acpi/video.c   |2 --
  sound/pci/hda/patch_hdmi.c |2 ++
  2 files changed, 2 insertions(+), 2 deletions(-)



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


[yocto] Yocto Project 1.2 M3 1.1.1 release readiness

2012-03-09 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=yocto@yoct
 oproject.org:MAILTO:yocto@yoctoproject.org
DESCRIPTION;LANGUAGE=en-US:When: Monday\, March 12\, 2012 8:00 AM-9:00 AM (
 UTC-08:00) Pacific Time (US  Canada).\nWhere: Bridge Info Enclosed\n\nNot
 e: The GMT offset above does not reflect daylight saving time adjustments.
 \n\n*~*~*~*~*~*~*~*~*~*\n\nMonday\, March 12\, 2012\, 08:00 AM US Pacific 
 Time\n916-356-2663\, 8-356-2663\, Bridge: 4\, Passcode: 1137217\nSpeed dia
 ler: inteldialer://4\,1137217 | Learn morehttp://it.intel.com/products/ha
 ndhelds/speeddial.htm\n\n\n\n
SUMMARY;LANGUAGE=en-US:Yocto Project 1.2 M3  1.1.1 release readiness
DTSTART;TZID=Pacific Standard Time:20120312T08
DTEND;TZID=Pacific Standard Time:20120312T09
UID:04008200E00074C5B7101A82E008801DDB57FEFDCC01000
 01000E7F12BECFB81CB4C9EBA3987AA976E28
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20120309T224417Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=en-US:Bridge Info Enclosed
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:646526940
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DISALLOW-COUNTER:FALSE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
END:VALARM
END:VEVENT
END:VCALENDAR
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] Request for Yocto Project 1.2 release Beta Program Users Yocto T-Shirt

2012-03-09 Thread Liu, Song
Hi all, 

It's that time again. We are starting the Beta program for Yocto Project 1.2 
release. This release focuses on usability of the Yocto Project. HOB2 is the 
second version of our Human Oriented Builder (GUI based), which will help 
developers build customized Linux image in a much more intuitive and smoother 
way. Build appliance will help users on Windows to get started with Yocto 
Project quickly. There are also many other features such as multi-lib 
improvement, error handling improvement, BSP tools, etc. 

Please volunteer or send me the names who you think should be a good candidate 
for our Beta release users. Anyone who is interested in Yocto Project and/or 
has some technical background in embedded Linux area should be just fine. And 
this time, we will send our Beta users some Yocto T-Shirts and I'm sure you 
will look more attractive in them :)

If you do want to volunteer or have someone in mind, please send me the names 
sometime next week. Thank you for your support and we really appreciate it!

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