[yocto] couple simple questions on building for intel galileo

[Robert P. J. Day]

  just got an intel galileo board, and want to whip together a
yocto-built image for it on my fedora rawhide system. before even
starting, a quick google showed me that people seemed to be having
trouble:

https://communities.intel.com/thread/51115

where are the canonical instructions for building a basic image for
the galileo with yocto? i found this:

http://wiki.ros.org/IntelGalileo/HydroGalileoInitialInstall

but i'd like to make sure i'm using the most current instructions to
avoid problems. thanks.

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] Third Party Components Integration in Yocto

[Meenakumari Shedole]

Thanks Alex,

Yes I installed  FILES_${PN} all package folders are creating
Tried devshell  but there is no installed bb-example in 
image/usr/include/...empty include folder. Bb-example is not loading inside 
image/..
Analysed  log_devshell , log_package, do_install, do_make.

Even I compared with other recipes folder structures  it is going right 
direction but only the binaries are not loading.

I guess I missed something in do_install ? no proper path?
After do_compile and make, at  do_install binaries are not able to load.


Regards
Meena

From: Alex J Lennon [mailto:ajlen...@dynamicdevices.co.uk]
Sent: Tuesday, May 06, 2014 9:17 PM
To: Meenakumari Shedole; yocto@yoctoproject.org; Beauchesne, Gwenole
Subject: Re: [yocto] Third Party Components Integration in Yocto


On 06/05/2014 15:57, Meenakumari Shedole wrote:
Hi,

To add 3rd party components in yocto we created bb file and modified local.conf 
file.
After a yocto build, 3rd party component executing the binaries and rpm 
packages but executed binaries are not loading inside the rpm packages, rpm 
package is empty.

Used below function in bb file.

do_install () {

  install -d ${D}${bindir}

  install -m 0755 bb-example ${D}${bindir}

}


Hi Meena,

That seems a little odd as files in ${bindir} should be packaged into the 
default output package as I understand it

ref: http://www.embeddedlinux.org.cn/OEManual/recipes_packages.html

If it were successfully installed but not packaged for any reason (e.g. in this 
case not a part of FILES_${PN}) then you should see a warning about an 
installed-vs-packaged file issue.

If you enter a devshell with bitbake -c devshell recipe-foo then do you see the 
installed bb-example file in within ../image/ tree?

Have you also tried looking (from the devshell) in ../temp/log.do_install, 
../temp/log.do_xxx to see what is happening?

Cheers,

Alex


can anyone please suggest me how to move further.

Regards
Meena


::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.




--

[Dynamic Devices Ltd]

Alex J Lennon / Director
1 Queensway, Liverpool L22 4RA

mobile: +44 (0)7956 668178

[Linkedin][Skype]

This e-mail message may contain confidential or legally privileged information 
and is intended only for the use of the intended recipient(s). Any unauthorized 
disclosure, dissemination, distribution, copying or the taking of any action in 
reliance on the information herein is prohibited. E-mails are not secure and 
cannot be guaranteed to be error free as they can be intercepted, amended, or 
contain viruses. Anyone who communicates with us by e-mail is deemed to have 
accepted these risks. Company Name is not responsible for errors or omissions 
in this message and denies any responsibility for any damage arising from the 
use of e-mail. Any opinion and other statement contained in this message and 
any attachment are solely those of the author and do not necessarily represent 
those of the company.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Third Party Components Integration in Yocto

[Alex J Lennon]

Hi Meena,

On 08/05/2014 11:05, Meenakumari Shedole wrote:
>
> Thanks Alex,
>
>  
>
> Yes I installed  FILES_${PN} all package folders are creating
>
> Tried devshell  but there is no installed bb-example in
> image/usr/include/...empty include folder. Bb-example is not loading
> inside image/..
>
> Analysed  log_devshell , log_package, do_install, do_make.
>

OK so that's helpful. I have had similar problems myself with files that
don't get installed and thus aren't packaged. In my experience it is
usually to do with the path to the source file one is trying to install.

i.e. So for some reason the bb-example file isn't where it should be to
be copied across to the target folder in the image tree.

Where does bb-example come from? Can you share the whole recipe? Can you
see it where you think it should be in the devshell folder or the folder
above?

If you included bb-example as a file:// entry added to SRC_URI then it
will be copied across to the working directory ${WORKDIR}

You might want to try something like

  install -m 0755 ${WORKDIR}/bb-example ${D}${bindir}

Alternatively if bb-example is output from a build process then it will
be in the source directory ${S}

In which case try

  install -m 0755 ${S}/bb-example ${D}${bindir}
 
Hope this helps!

Alex

>  
>
> Even I compared with other recipes folder structures  it is going
> right direction but only the binaries are not loading.
>
>  
>
> I guess I missed something in do_install ? no proper path?
>
> After do_compile and make, at  do_install binaries are not able to load.
>
>  
>
>  
>
> Regards
>
> Meena
>
>  
>
> *From:*Alex J Lennon [mailto:ajlen...@dynamicdevices.co.uk]
> *Sent:* Tuesday, May 06, 2014 9:17 PM
> *To:* Meenakumari Shedole; yocto@yoctoproject.org; Beauchesne, Gwenole
> *Subject:* Re: [yocto] Third Party Components Integration in Yocto
>
>  
>
>  
>
> On 06/05/2014 15:57, Meenakumari Shedole wrote:
>
> Hi,
>
>  
>
> To add 3rd party components in yocto we created bb file and
> modified local.conf file.
>
> After a yocto build, 3rd party component executing the binaries
> and rpm packages but executed binaries are not loading inside the
> rpm packages, rpm package is empty.
>
>  
>
> Used below function in bb file. 
>
> *do_install* () {
>
>   install *-*d *$*{D}${bindir}
>
>   install *-*m 0755 bb*-*example *$*{D}${bindir}
>
> }
>
>  
>
>
> Hi Meena,
>
> That seems a little odd as files in ${bindir} should be packaged into
> the default output package as I understand it
>
> ref: http://www.embeddedlinux.org.cn/OEManual/recipes_packages.html
>
> If it were successfully installed but not packaged for any reason
> (e.g. in this case not a part of FILES_${PN}) then you should see a
> warning about an installed-vs-packaged file issue.
>
> If you enter a devshell with bitbake -c devshell recipe-foo then do
> you see the installed bb-example file in within ../image/ tree?
>
> Have you also tried looking (from the devshell) in
> ../temp/log.do_install, ../temp/log.do_xxx to see what is happening?
>
> Cheers,
>
> Alex
>
>
> can anyone please suggest me how to move further.
>
>  
>
> Regards
>
> Meena
>
>
>
> ::DISCLAIMER::
> 
>
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as
> information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or may contain viruses in
> transmission. The e mail and its contents
> (with or without referred errors) shall therefore not attach any
> liability on the originator or HCL or its affiliates.
> Views or opinions, if any, presented in this email are solely those of
> the author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior
> written consent of authorized representative of
> HCL is strictly prohibited. If you have received this email in error
> please delete it and notify the sender immediately.
> Before opening any email and/or attachments, please check them for
> viruses and other defects.
>
> 
>

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

Re: [yocto] [PATCH 1/1] dylan: fix kconfig-frontends for ncurses --with-libterm

[Richard Purdie]

On Mon, 2014-05-05 at 23:07 +, Woodyatt, James wrote:
> commit 939c9feca3c26d4603b573d887324d6220e93819
> Author: james woodyatt 
> Date:   Mon May 5 15:54:29 2014 -0700
> 
> kconfig-frontends-native: add support for --with-libterm.
> 
> This is a cherry-pick of cefcd4b655c2b7efdc6313740f3c8af89dd8f670 from
> the kconfig-frontends project authoritative Git repository for a change
> that went into 3.9 and later revisions that enables building on hosts
> configurations where libncurses uses libtinfo.


I've dug into this to try and figure out what is breaking and I'm
struggling to understand how this error is occurring for you. In
particular, dylan's ncurses recipe has this commit:

https://gitorious.org/angstrom/jadon-openembedded/commit/10a92f252407e4487afbf44a330ba5b7b61b84b1

which is rather old but still present in the modern codebase. The linker
script there should add in linkage to libtinfo as and where needed.

I'm therefore reluctant to merge these patches without a better
understanding of exactly how we can reproduce this bug and perhaps why
the linker scripts are failing.

We have tried a build of these recipes on dylan on a CentOS 6.5 machine
and they worked out ok.

I would be interested to see the build failure logs and also to check if
the libncursesw.so file is indeed a linker script in your case. An
strace of the linker command run by the kconfig build may also reveal
something (is it preferring the system libraries for some reason for
example in your case?).

Cheers,

Richard





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

Re: [yocto] [meta-selinux][PATCH 9/9] linux-yocto: remove PRINC warning

[Martin Jansa]

On Wed, May 07, 2014 at 03:49:28PM -0400, Joe MacDonald wrote:
> Convert PRINC to PR .= so as to not break package feeds.  Next time this
> won't be necessary at all.
> 
> Signed-off-by: Joe MacDonald 
> ---
>  recipes-kernel/linux/linux-yocto_3.10.bbappend |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/recipes-kernel/linux/linux-yocto_3.10.bbappend 
> b/recipes-kernel/linux/linux-yocto_3.10.bbappend
> index 159d63b..6686974 100644
> --- a/recipes-kernel/linux/linux-yocto_3.10.bbappend
> +++ b/recipes-kernel/linux/linux-yocto_3.10.bbappend
> @@ -1,4 +1,4 @@
> -PRINC = "1"
> +PR .= "1"

Does this one really help? PRINC increments first numeric part of PR, so
in linux-yocto case it would be INC_PR and you're appending 1 to last
part.

so from r6.5 you'll get r5.51 if I parse it correctly before morning
coffee.

>  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>  
>  # Enable selinux support in the kernel if the feature is enabled
> -- 
> 1.7.10.4
> 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] couple simple questions on building for intel galileo

[Diego Sueiro]

Robert,

Here is some instructions with some workarounds:
http://www.malinov.com/Home/sergey-s-blog/intelgalileo-buildinglinuximage

And I think that you already saw meta-intel-iot-devkit:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-iot-devkit/

As soon as I get my Galileo I'll try to put Yocto on it.

Please, share your results with us.

Regards,

--
*dS
Diego Sueiro

Administrador do Embarcados
www.embarcados.com.br

/*long live rock 'n roll*/


On Thu, May 8, 2014 at 4:21 AM, Robert P. J. Day wrote:

>
>   just got an intel galileo board, and want to whip together a
> yocto-built image for it on my fedora rawhide system. before even
> starting, a quick google showed me that people seemed to be having
> trouble:
>
> https://communities.intel.com/thread/51115
>
> where are the canonical instructions for building a basic image for
> the galileo with yocto? i found this:
>
> http://wiki.ros.org/IntelGalileo/HydroGalileoInitialInstall
>
> but i'd like to make sure i'm using the most current instructions to
> avoid problems. thanks.
>
> rday
>
> --
>
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] replace udhcpc

[Burton, Ross]

On 8 May 2014 04:58, Neuer User  wrote:
> I had a brief look at connman half a year ago, but that time I was
> unable to find a good documentation about it. Do you have by chance a
> link to some tutorial or at least man entry for the configuration?

What do you need to configure?  For "when ethernet cable inserted,
bring up the interface using DHCP" this is default behaviour and won't
need any configuring.  connman is sadly under-documented but the IRC
channel is fairly responsive.

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

Re: [yocto] couple simple questions on building for intel galileo

[Robert P. J. Day]

On Thu, 8 May 2014, Diego Sueiro wrote:

> Robert,
> Here is some instructions with some workarounds:
> http://www.malinov.com/Home/sergey-s-blog/intelgalileo-buildinglinuximage
>
> And I think that you already saw meta-intel-iot-devkit:
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-iot-devkit/
>
> As soon as I get my Galileo I'll try to put Yocto on it.
>
> Please, share your results with us.

  oh, i'm currently writing all this up and, at the risk of going
*slightly* off-topic, before i set up for a yocto build for this
board, i'm just trying to clarify the boot process, both without and
with the SD card, so i know i'm bulding my SD card properly.

  first, without an SD card, the board apparently boots a minimal
linux image from SPI flash. so far, so good.

  as for creating a bootable SD card, i see two possibilities. the
first is explained at sparkfun:

https://learn.sparkfun.com/tutorials/galileo-getting-started-guide/bigger-linux-image

where one can download a file called
LINUX_IMAGE_FOR_SD_Intel_Galileo_v0.7.5.7z, which uncompresses into a
simple directory structure that you copy to a FAT-formatted SD card.
so this SD card, apparently, contains a single FAT partition.

  on the other hand, over at intel's developer zone:

https://software.intel.com/en-us/iotdevkit

one can download what is described as "SD card (200MB zipped)", which
i unzipped into a file "iot-devkit-201402201605-mmcblkp0.direct",
almost 8G in size, and which "fdisk" shows me has the following
structure:

Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0007eabb

Device   Boot Start   End
Blocks  Id System
iot-devkit-201402201605-mmcblkp0.direct1 * 2048106493   52223  83 
Linux
iot-devkit-201402201605-mmcblkp0.direct2 106496  14442495 7168000  83 
Linux

  which is more what i'm used to. so am i reading both of these
correctly? there are two possible formats for the bootable SD card:

* simple, single FAT partition, or
* more "standard" pair of bootable FAT partition, and linux ext
partition.

  many thanks.

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] [PATCH 1/1] dylan: fix C++ standard library headers on OS X

[Richard Purdie]

On Mon, 2014-05-05 at 23:12 +, Woodyatt, James wrote:
> Resend, this time with all contents.
> 
> commit 562fa987cea60d61c256195adce7e83bf1c1a8c9
> Author: james woodyatt 
> Date:   Thu May 1 14:44:39 2014 -0700
> 
> Fix C++ standard library header directory configuration.
> 
> Remove the 4.2.1 directory from the --with-gxx-include-dir path provided
> to the configure script for GCC 4.7 in the cross-canadian build.
> 
> diff --git a/recipes-devtools/gcc/gcc-cross-canadian_4.7.bbappend 
> b/recipes-devtools/gcc/gcc-cross-canadian_4.7.bbappend
> index 3fcc012..083b930 100644
> --- a/recipes-devtools/gcc/gcc-cross-canadian_4.7.bbappend
> +++ b/recipes-devtools/gcc/gcc-cross-canadian_4.7.bbappend
> @@ -4,7 +4,7 @@ INSANE_SKIP_${PN}_append_darwinsdk = " staticdev"
>  LDFLAGS_darwinsdk = "${BUILDSDK_LDFLAGS} -L${libdir}/.."
>  
>  # Change gxx-include-dir
> -EXTRA_OECONF_PATHS_darwinsdk = 
> "--with-gxx-include-dir=${SDKPATH}/sysroots/${TUNE_PKGARCH}${TARGET_VENDOR}-${TARGET_OS}/usr/include/c++/4.2.1
>  \
> +EXTRA_OECONF_PATHS_darwinsdk = 
> "--with-gxx-include-dir=${SDKPATH}/sysroots/${TUNE_PKGARCH}${TARGET_VENDOR}-${TARGET_OS}/usr/include/c++
>  \
>
> --with-build-time-tools=${STAGING_DIR_NATIVE}${prefix_native}/${TARGET_SYS}/bin
>  \
>
> --with-sysroot=${SDKPATH}/sysroots/${TUNE_PKGARCH}${TARGET_VENDOR}-${TARGET_OS}
>  \
>--with-build-sysroot=${STAGING_DIR_TARGET}"
> 

I've applied this fix to the dylan, dora, daisy and master branches. I
tweaked the commit message a little to match the guidelines.

Cheers,

Richard

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

Re: [yocto] [PATCH 2/2] meta-darwin on dylan branch

[Richard Purdie]

On Thu, 2014-05-01 at 19:03 +, Woodyatt, James wrote:
> commit 4c50f7bd62a675dd1f034bc6730f833c6dca0c19
> Author: james woodyatt 
> Date:   Thu May 1 11:57:41 2014 -0700
> 
> Remove usage of ‘new typename’ constructors in ld64 part of odcctools2 
> package.
> 

I've applied this fix to the dylan, dora, daisy and master branches. I
tweaked the commit message to include the fact that this is a gcc 4.7
verses 4.8 issue and to match the guidelines (shortlog needed to start
oddctools2: for example).

Cheers,

Richard

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

Re: [yocto] replace udhcpc

[Joe MacDonald]

[Re: [yocto] replace udhcpc] On 14.05.08 (Thu 05:54) Neuer User wrote:

> Am 07.05.2014 11:27, schrieb Søren Holm:
> > Use ifplugd recipe I just submitted.
> > 
> 
> Very nice idea. Where do I find the recipe?

Søren withdrew the submission to meta-networking following further
discussion.

http://permalink.gmane.org/gmane.comp.handhelds.openembedded/63249

-J.

> 
> > Onsdag den 7. maj 2014 10:57:22 skrev Neuer User:
> >> Hi
> >>
> >> I encounter a problem with the DHCP network setup during boot:
> >>
> >> System starts. During start ifup is called. ifup calls udhcpc. Network
> >> is, however, not yet up! udhcpc exits with failure. Then network is up.
> >> But, of course, no connection, because no IP address.
> >>
> >> In earlier times I used debian based system, which seem to rely on
> >> dhclient3. My experiences here were that dhclient remained as a deamon
> >> continuing trying to get a dhcp address.
> >>
> >> What should I do best on Yocto? Replace udhcpc with dhclient? If so, how
> >> should that be done?
> >>
> >> Or can udhcpc be configured to remain in the background and try to get
> >> an IP address when network is finally up?
> >>
> >> Thanks for any help
> >>
> >> Michael
> > 
> 
> 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH 9/9] linux-yocto: remove PRINC warning

[Joe MacDonald]

[Re: [yocto] [meta-selinux][PATCH 9/9] linux-yocto: remove PRINC warning] On 
14.05.08 (Thu 12:34) Martin Jansa wrote:

> On Wed, May 07, 2014 at 03:49:28PM -0400, Joe MacDonald wrote:
> > Convert PRINC to PR .= so as to not break package feeds.  Next time this
> > won't be necessary at all.
> > 
> > Signed-off-by: Joe MacDonald 
> > ---
> >  recipes-kernel/linux/linux-yocto_3.10.bbappend |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/recipes-kernel/linux/linux-yocto_3.10.bbappend 
> > b/recipes-kernel/linux/linux-yocto_3.10.bbappend
> > index 159d63b..6686974 100644
> > --- a/recipes-kernel/linux/linux-yocto_3.10.bbappend
> > +++ b/recipes-kernel/linux/linux-yocto_3.10.bbappend
> > @@ -1,4 +1,4 @@
> > -PRINC = "1"
> > +PR .= "1"
> 
> Does this one really help? PRINC increments first numeric part of PR, so
> in linux-yocto case it would be INC_PR and you're appending 1 to last
> part.
> 
> so from r6.5 you'll get r5.51 if I parse it correctly before morning
> coffee.

Oop, yeah, you're right.  This one's a bit more complicated.

-J.

> 
> >  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> >  
> >  # Enable selinux support in the kernel if the feature is enabled
> > -- 
> > 1.7.10.4
> > 
> > -- 
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] linux-yocto custom device tree in overlay

[Andreas Galauner]

On 07/05/14 21:37, Bruce Ashfield wrote:
> So you can either patch it into the kernel, or do a bbappend with
> that copies it into the source tree
> (linux/arch/arm/boot/dts/mydevicetree.dts).

Thx! That worked fine.

For reference, this is what I added:
> do_install_prepend() {
>   cp ${WORKDIR}/*.dts ${WORKDIR}/linux/arch/${ARCH}/boot/dts/
> }

Cheers,
- Andy

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

[yocto] GStreamer 0.10's future

[Burton, Ross]

Hi all,

Sorry for the cross-post but I want this to have a wide audience.

For the 1.7 release I want to move GStreamer 0.10 from oe-core into
meta-multimedia, and ensure everything in oe-core has ported to
GStreamer 1.x.  GStreamer 0.10 is considered dead upstream and is
unmaintained so we don't need to be shipping both versions anymore.

Everyone in agreement?  Should I expect any hate mail over this?

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

Re: [yocto] [OE-core] GStreamer 0.10's future

[Paul Eggleton]

On Thursday 08 May 2014 15:48:40 Burton, Ross wrote:
> Hi all,
> 
> Sorry for the cross-post but I want this to have a wide audience.
> 
> For the 1.7 release I want to move GStreamer 0.10 from oe-core into
> meta-multimedia, and ensure everything in oe-core has ported to
> GStreamer 1.x.  GStreamer 0.10 is considered dead upstream and is
> unmaintained so we don't need to be shipping both versions anymore.
> 
> Everyone in agreement?  Should I expect any hate mail over this?

+1

The next question is does that mean for the "old" libav (which gst-ffmpeg 
depends upon), do we move that as well or drop it?

Cheers,
Paul

-- 

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

Re: [yocto] [OE-core] GStreamer 0.10's future

[Burton, Ross]

On 8 May 2014 16:07, Paul Eggleton  wrote:
> The next question is does that mean for the "old" libav (which gst-ffmpeg
> depends upon), do we move that as well or drop it?

If gst-ffmpeg is the sole consumer, then certainly yes.

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

Re: [yocto] linux-yocto custom device tree in overlay

[Bruce Ashfield]

On 14-05-08 09:48 AM, Andreas Galauner wrote:

On 07/05/14 21:37, Bruce Ashfield wrote:

So you can either patch it into the kernel, or do a bbappend with
that copies it into the source tree
(linux/arch/arm/boot/dts/mydevicetree.dts).


Thx! That worked fine.


Glad to hear!

Bruce



For reference, this is what I added:

do_install_prepend() {
cp ${WORKDIR}/*.dts ${WORKDIR}/linux/arch/${ARCH}/boot/dts/
}


Cheers,
- Andy



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

Re: [yocto] [OE-core] GStreamer 0.10's future

[Koen Kooi]

Op 8 mei 2014, om 16:48 heeft Burton, Ross  het volgende 
geschreven:

> Hi all,
> 
> Sorry for the cross-post but I want this to have a wide audience.
> 
> For the 1.7 release I want to move GStreamer 0.10 from oe-core into
> meta-multimedia, and ensure everything in oe-core has ported to
> GStreamer 1.x.  GStreamer 0.10 is considered dead upstream and is
> unmaintained so we don't need to be shipping both versions anymore.
> 
> Everyone in agreement?  

A plus one from me.

> Should I expect any hate mail over this?

This is the internet, of course you'll get hate mail :/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] SATO on Intel DN2800MT

[r10kindsofpeople]

I'm trying to experiment with the SATO build on a DN2800MT with a VGA
monitor, but can't seem to get going.  The binaries from Daisy and
genericX86 get as far as the Yocto progress bar complete, and then go
black.  Any quick hints?

I note also that genericX86 looks like a complete Yocto tree rather than
just BSP layers.  Am I right, and are there hints on how to combine this
with a generic Daisy tree for other processors/projects?

Yocto_11_0_0/genericx86-daisy-11.0.0/meta-yocto-bsp/recipes-graphics/xorg-xserver/xserver-xf86-config/genericx86/xorg.conf
is a zero length file.   ?

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

Re: [yocto] GStreamer 0.10's future

[Burton, Ross]

On 8 May 2014 15:48, Burton, Ross  wrote:
> For the 1.7 release I want to move GStreamer 0.10 from oe-core into
> meta-multimedia, and ensure everything in oe-core has ported to
> GStreamer 1.x.  GStreamer 0.10 is considered dead upstream and is
> unmaintained so we don't need to be shipping both versions anymore.

So the catch here is that Qt4 currently depends on GStreamer 0.10.

Can someone who doesn't come out in a rash when looking at C++ code
spend two minutes to tell if me Qt4 supports GStreamer 1.0 (unlikely)
and whether we can make GStreamer 0.10 support a build-time
configuration and simply disable it in oe-core.

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

Re: [yocto] [OE-core] GStreamer 0.10's future

[Martin Jansa]

On Thu, May 08, 2014 at 04:07:19PM +0100, Paul Eggleton wrote:
> On Thursday 08 May 2014 15:48:40 Burton, Ross wrote:
> > Hi all,
> > 
> > Sorry for the cross-post but I want this to have a wide audience.
> > 
> > For the 1.7 release I want to move GStreamer 0.10 from oe-core into
> > meta-multimedia, and ensure everything in oe-core has ported to
> > GStreamer 1.x.  GStreamer 0.10 is considered dead upstream and is
> > unmaintained so we don't need to be shipping both versions anymore.
> > 
> > Everyone in agreement?  Should I expect any hate mail over this?
> 
> +1
> 
> The next question is does that mean for the "old" libav (which gst-ffmpeg 
> depends upon), do we move that as well or drop it?

libav was migrated to oe-core quite recently and there is couple of
recipes in meta-oe, meta-webserver depending on it/ffmpeg so moving to
meta-multimedia wouldn't be very easy.

meta-multimedia/recipes-multimedia/sox/sox_14.4.0.bb:DEPENDS = "libpng libav 
libsndfile1"
meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb:DEPENDS = "libusb1 libcec 
libplist expat yajl gperf-native libxmu fribidi mpeg2dec ffmpeg samba 
fontconfig curl python libass libmodplug libmicrohttpd wavpack libmms 
cmake-native libsdl-image libsdl-mixer virtual/egl mysql5 sqlite3 libmms faad2 
libcdio libpcre boost lzo enca avahi libsamplerate0 libxinerama libxrandr 
libxtst bzip2 virtual/libsdl jasper zip-native zlib libtinyxml libmad"
meta-multimedia/recipes-multimedia/musicpd/mpd_0.18.9.bb:DEPENDS = "alsa-lib 
libsamplerate0 libsndfile1 libvorbis libogg faad2 ffmpeg curl sqlite bzip2 
pulseaudio"
meta-multimedia/recipes-multimedia/vlc/vlc.inc:   faad2 ffmpeg flac libxpm 
libxinerama fluidsynth alsa-lib libdvdcss \

meta-oe/recipes-multimedia/nonworking/minidlna/minidlna_1.0.25.bb:DEPENDS = 
"flac libav jpeg sqlite3 libexif libogg libid3tag"
meta-oe/recipes-support/opencv/opencv_2.4.bb:PACKAGECONFIG ??= "eigen gtk jpeg 
libav png tiff v4l"
meta-oe/recipes-graphics/gegl/gegl_0.2.0.bb:PACKAGECONFIG[avformat] = 
"--with-libavformat,--without-libavformat,libav"
meta-oe/recipes-multimedia/libpostproc/libpostproc_git.bb:DEPENDS = "libav"
meta-oe/recipes-multimedia/mplayer/mplayer2_git.bb:DEPENDS = "libvpx libdvdread 
libtheora virtual/libsdl ffmpeg xsp zlib \

meta-webserver/recipes-httpd/cherokee/cherokee_1.2.98.bb:PACKAGECONFIG[ffmpeg] 
= "--with-ffmpeg,--without-ffmpeg,libav"

But I would like to see migration to libav-9 which currently has negative D_P
(mplayer2 already depends on 9*, but there are few recipes which fails with
libav-9 too - see earlier world builds for list).

Regards,

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] GStreamer 0.10's future

[Paul Eggleton]

On Thursday 08 May 2014 18:19:08 Martin Jansa wrote:
> On Thu, May 08, 2014 at 04:07:19PM +0100, Paul Eggleton wrote:
> > On Thursday 08 May 2014 15:48:40 Burton, Ross wrote:
> > > Hi all,
> > > 
> > > Sorry for the cross-post but I want this to have a wide audience.
> > > 
> > > For the 1.7 release I want to move GStreamer 0.10 from oe-core into
> > > meta-multimedia, and ensure everything in oe-core has ported to
> > > GStreamer 1.x.  GStreamer 0.10 is considered dead upstream and is
> > > unmaintained so we don't need to be shipping both versions anymore.
> > > 
> > > Everyone in agreement?  Should I expect any hate mail over this?
> > 
> > +1
> > 
> > The next question is does that mean for the "old" libav (which gst-ffmpeg
> > depends upon), do we move that as well or drop it?
> 
> libav was migrated to oe-core quite recently and there is couple of
> recipes in meta-oe, meta-webserver depending on it/ffmpeg so moving to
> meta-multimedia wouldn't be very easy.
> 
> meta-multimedia/recipes-multimedia/sox/sox_14.4.0.bb:DEPENDS = "libpng libav
> libsndfile1" meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb:DEPENDS =
> "libusb1 libcec libplist expat yajl gperf-native libxmu fribidi mpeg2dec
> ffmpeg samba fontconfig curl python libass libmodplug libmicrohttpd wavpack
> libmms cmake-native libsdl-image libsdl-mixer virtual/egl mysql5 sqlite3
> libmms faad2 libcdio libpcre boost lzo enca avahi libsamplerate0
> libxinerama libxrandr libxtst bzip2 virtual/libsdl jasper zip-native zlib
> libtinyxml libmad"
> meta-multimedia/recipes-multimedia/musicpd/mpd_0.18.9.bb:DEPENDS =
> "alsa-lib libsamplerate0 libsndfile1 libvorbis libogg faad2 ffmpeg curl
> sqlite bzip2 pulseaudio" meta-multimedia/recipes-multimedia/vlc/vlc.inc:  
> faad2 ffmpeg flac libxpm libxinerama fluidsynth alsa-lib libdvdcss \
> 
> meta-oe/recipes-multimedia/nonworking/minidlna/minidlna_1.0.25.bb:DEPENDS =
> "flac libav jpeg sqlite3 libexif libogg libid3tag"
> meta-oe/recipes-support/opencv/opencv_2.4.bb:PACKAGECONFIG ??= "eigen gtk
> jpeg libav png tiff v4l"
> meta-oe/recipes-graphics/gegl/gegl_0.2.0.bb:PACKAGECONFIG[avformat] =
> "--with-libavformat,--without-libavformat,libav"
> meta-oe/recipes-multimedia/libpostproc/libpostproc_git.bb:DEPENDS = "libav"
> meta-oe/recipes-multimedia/mplayer/mplayer2_git.bb:DEPENDS = "libvpx
> libdvdread libtheora virtual/libsdl ffmpeg xsp zlib \
> 
> meta-webserver/recipes-httpd/cherokee/cherokee_1.2.98.bb:PACKAGECONFIG[ffmpe
> g] = "--with-ffmpeg,--without-ffmpeg,libav"
> 
> But I would like to see migration to libav-9 which currently has negative
> D_P (mplayer2 already depends on 9*, but there are few recipes which fails
> with libav-9 too - see earlier world builds for list).

Yes, I'm just talking about libav 0.8 here - libav 9 would remain where it is. 
That might still be problematic though given that their PN is the same. I'm 
open to better suggestions, but I think we have to do *something* here.

Cheers,
Paul

-- 

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

[yocto] [opkg-utils][PATCH 2/3] opkg-make-index: Recursively scan for packages

[Paul Barker]

The new 'relpath' argument to the initialiser of a Package object is used so
that file paths will be given relative to the base packages directory.

Paths are given relative to pkg_dir as that seems to make the most sense. It
certainly works when the 'Packages' file is written to pkg_dir. If the
'Packages' file is written elsewhere it is assumed that the user will know what
the paths are relative to. This is similar to debian feeds where the paths in a
'Packages' file is not stored in the packages pool but is stored in a separate
directory, yet paths are given relative to the common base of these directories.

Signed-off-by: Paul Barker 
---
 opkg-make-index | 29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/opkg-make-index b/opkg-make-index
index 44fa64d..2fdf95c 100755
--- a/opkg-make-index
+++ b/opkg-make-index
@@ -1,7 +1,6 @@
 #!/usr/bin/env python
 
 import sys, os, posixpath
-from glob import glob
 import subprocess
 import opkg
 import getopt
@@ -92,32 +91,40 @@ if old_filename:
 
 if (verbose):
  sys.stderr.write("Reading in all the package info from %s\n" % (pkg_dir, 
))
-files=glob(pkg_dir + '/*.opk') + glob(pkg_dir + '/*.deb') + glob(pkg_dir + 
'/*.ipk')
+
+files=[]
+opkg_extensions=['.ipk','.opk','.deb']
+for dirpath, dirnames, filenames in os.walk(pkg_dir):
+for f in filenames:
+ext = os.path.splitext(f)[1]
+if ext in opkg_extensions:
+files.append(os.path.join(dirpath, f))
+
 files.sort()
-for filename in files:
+for abspath in files:
   try:
- basename = os.path.basename(filename)
+ filename = os.path.relpath(abspath, pkg_dir)
  pkg = None
- fnameStat = os.stat(filename)
- if basename in old_pkg_hash:
-  if basename in pkgsStamps and int(fnameStat.st_mtime) == 
pkgsStamps[basename]:
+ fnameStat = os.stat(abspath)
+ if filename in old_pkg_hash:
+  if filename in pkgsStamps and int(fnameStat.st_mtime) == 
pkgsStamps[filename]:
 if (verbose):
sys.stderr.write("Found %s in Packages\n" % (filename,))
-pkg = old_pkg_hash[basename]
+pkg = old_pkg_hash[filename]
   else:
sys.stderr.write("Found %s in Packages, but mtime differs - 
re-reading\n" % (filename,))
 
  if not pkg:
   if (verbose):
sys.stderr.write("Reading info for package %s\n" % (filename,))
-  pkg = opkg.Package(filename)
+  pkg = opkg.Package(abspath, relpath=pkg_dir)
  pkg_key = ("%s:%s" % (pkg.package, pkg.architecture))
  if (pkg_key in packages.packages):
   old_filename = packages.packages[pkg_key].filename
  else:
   old_filename = ""
  s = packages.add_package(pkg)
- pkgsStamps[basename] = fnameStat.st_mtime
+ pkgsStamps[filename] = fnameStat.st_mtime
  if s == 0:
   if old_filename:
# old package was displaced by newer
@@ -127,7 +134,7 @@ for filename in files:
 print(("%s/%s" % (pkg_dir, old_filename)))
  else:
   if opt_m:
-   to_morgue(basename)
+   to_morgue(filename)
   if opt_s:
print(filename)
   except OSError as e:
-- 
1.9.2

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

[yocto] [opkg-utils][PATCH 1/3] opkg.py: Allow filename to be a relative path

[Paul Barker]

In order to support package files residing in a different directory to the
'Packages' index file, we need to allow filename entries in the index to be
relative paths. In order to not break existing code, filename remains the
basename of fn by default. However, if the new relpath argument is set then
filename is the path of fn relative to relpath.

Signed-off-by: Paul Barker 
---
 opkg.py | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/opkg.py b/opkg.py
index c839100..ae0fbcd 100644
--- a/opkg.py
+++ b/opkg.py
@@ -116,7 +116,12 @@ def parse_version(versionstr):
 class Package:
 """A class for creating objects to manipulate (e.g. create) opkg
packages."""
-def __init__(self, fn=None):
+
+# fn: Package file path
+# relpath: If this argument is set, the file path is given relative to this
+#   path when a string representation of the Package object is created. If
+#   this argument is not set, the basename of the file path is given.
+def __init__(self, fn=None, relpath=None):
 self.package = None
 self.version = 'none'
 self.parsed_version = None
@@ -150,7 +155,10 @@ class Package:
 # see if it is deb format
 f = open(fn, "rb")
 
-self.filename = os.path.basename(fn)
+if relpath:
+self.filename = os.path.relpath(fn, relpath)
+else:
+self.filename = os.path.basename(fn)
 
 ## sys.stderr.write("  extracting control.tar.gz from %s\n"% 
(fn,)) 
 
-- 
1.9.2

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

[yocto] [opkg-utils][PATCH 0/3] Patches to support hierarchical package feeds

[Paul Barker]

I'm posting these patches in the hope that someone other than me has some memory
of how the internals of opkg-utils work and can give me a quick review. I can
merge these myself but as they will affect all ipk feeds created by OpenEmbedded
I think it's worth at least trying to get a review on the changes first.

These changes are needed to support alternative feed layouts where package files
may not reside in the same directory as the 'Packages' index file. A patch to
add the option of creating such an alternative layout will also be posted to the
openembedded-core mailing list for comment.

These patches have been tested on qemuarm with opkg pointed at feeds created
with these patches applied. It has been confirmed that 'opkg update && opkg
install ncurses' works correctly where ncurses was not previously installed.

Paul Barker (3):
  opkg.py: Allow filename to be a relative path
  opkg-make-index: Recursively scan for packages
  opkg-update-index: Emit relative path to package file

 opkg-make-index   | 29 ++---
 opkg-update-index |  2 +-
 opkg.py   | 12 ++--
 3 files changed, 29 insertions(+), 14 deletions(-)

-- 
1.9.2

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

[yocto] [opkg-utils][PATCH 3/3] opkg-update-index: Emit relative path to package file

[Paul Barker]

The new relpath argument of the Package object constructor is used so that the
relative path from pkg_dir to the package file will be placed in the package
index. The allows the package file to be in a subdirectory of pkg_dir.

Signed-off-by: Paul Barker 
---
 opkg-update-index | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/opkg-update-index b/opkg-update-index
index 1b05875..353ea69 100755
--- a/opkg-update-index
+++ b/opkg-update-index
@@ -17,7 +17,7 @@ packages.read_packages_file(pkg_dir + '/Packages')
 
 names = list(packages.packages.keys())
 
-packages.add_package(opkg.Package(pkg_filename))
+packages.add_package(opkg.Package(pkg_filename, relpath=pkg_dir))
 
 packages.write_packages_file(pkg_dir + '/Packages.new')
 os.rename(pkg_dir + '/Packages.new', pkg_dir + '/Packages')
-- 
1.9.2

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

Re: [yocto] SATO on Intel DN2800MT

[Chris Tapp]

Hi John,

On 8 May 2014, at 16:25, r10kindsofpeople  wrote:

> I'm trying to experiment with the SATO build on a DN2800MT with a VGA 
> monitor, but can't seem to get going.  The binaries from Daisy and genericX86 
> get as far as the Yocto progress bar complete, and then go black.  Any quick 
> hints?

Have a look in the README file for the cedartrail BSP. At the bottom you will 
find:

Work Around for VGA and LVDS Display issue in PVR driver


The PVR driver has a issue that for some systems it causes
it to incorrectly assume that a LVDS display is connected
while infact a VGA display is connected and Vice Versa.
If your VGA or LVDS display does not work with
"cedartrail" MACHINE, then if you have connected a VGA display,
add the following to the kernel command line:

video=LVDS-1:d video=VGA-1:e



I suspect it's this. Watch out if you use HDMI as well - the VGA fix seems to 
break HDMI. On my systems the VGA then works, but the HDMI pauses a lot running 
the same image! I think you can use similar magic for HDMI (or did I just take 
it out?).

> I note also that genericX86 looks like a complete Yocto tree rather than just 
> BSP layers.  Am I right, and are there hints on how to combine this with a 
> generic Daisy tree for other processors/projects?
> 
> Yocto_11_0_0/genericx86-daisy-11.0.0/meta-yocto-bsp/recipes-graphics/xorg-xserver/xserver-xf86-config/genericx86/xorg.conf
>  is a zero length file.   ?
> 
> John
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Chris Tapp

opensou...@keylevel.com
www.keylevel.com



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

Re: [yocto] [OE-core] GStreamer 0.10's future

[Martin Jansa]

On Thu, May 08, 2014 at 05:57:54PM +0100, Paul Eggleton wrote:
> On Thursday 08 May 2014 18:19:08 Martin Jansa wrote:
> > On Thu, May 08, 2014 at 04:07:19PM +0100, Paul Eggleton wrote:
> > > On Thursday 08 May 2014 15:48:40 Burton, Ross wrote:
> > > > Hi all,
> > > > 
> > > > Sorry for the cross-post but I want this to have a wide audience.
> > > > 
> > > > For the 1.7 release I want to move GStreamer 0.10 from oe-core into
> > > > meta-multimedia, and ensure everything in oe-core has ported to
> > > > GStreamer 1.x.  GStreamer 0.10 is considered dead upstream and is
> > > > unmaintained so we don't need to be shipping both versions anymore.
> > > > 
> > > > Everyone in agreement?  Should I expect any hate mail over this?
> > > 
> > > +1
> > > 
> > > The next question is does that mean for the "old" libav (which gst-ffmpeg
> > > depends upon), do we move that as well or drop it?
> > 
> > libav was migrated to oe-core quite recently and there is couple of
> > recipes in meta-oe, meta-webserver depending on it/ffmpeg so moving to
> > meta-multimedia wouldn't be very easy.
> > 
> > meta-multimedia/recipes-multimedia/sox/sox_14.4.0.bb:DEPENDS = "libpng libav
> > libsndfile1" meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb:DEPENDS =
> > "libusb1 libcec libplist expat yajl gperf-native libxmu fribidi mpeg2dec
> > ffmpeg samba fontconfig curl python libass libmodplug libmicrohttpd wavpack
> > libmms cmake-native libsdl-image libsdl-mixer virtual/egl mysql5 sqlite3
> > libmms faad2 libcdio libpcre boost lzo enca avahi libsamplerate0
> > libxinerama libxrandr libxtst bzip2 virtual/libsdl jasper zip-native zlib
> > libtinyxml libmad"
> > meta-multimedia/recipes-multimedia/musicpd/mpd_0.18.9.bb:DEPENDS =
> > "alsa-lib libsamplerate0 libsndfile1 libvorbis libogg faad2 ffmpeg curl
> > sqlite bzip2 pulseaudio" meta-multimedia/recipes-multimedia/vlc/vlc.inc:  
> > faad2 ffmpeg flac libxpm libxinerama fluidsynth alsa-lib libdvdcss \
> > 
> > meta-oe/recipes-multimedia/nonworking/minidlna/minidlna_1.0.25.bb:DEPENDS =
> > "flac libav jpeg sqlite3 libexif libogg libid3tag"
> > meta-oe/recipes-support/opencv/opencv_2.4.bb:PACKAGECONFIG ??= "eigen gtk
> > jpeg libav png tiff v4l"
> > meta-oe/recipes-graphics/gegl/gegl_0.2.0.bb:PACKAGECONFIG[avformat] =
> > "--with-libavformat,--without-libavformat,libav"
> > meta-oe/recipes-multimedia/libpostproc/libpostproc_git.bb:DEPENDS = "libav"
> > meta-oe/recipes-multimedia/mplayer/mplayer2_git.bb:DEPENDS = "libvpx
> > libdvdread libtheora virtual/libsdl ffmpeg xsp zlib \
> > 
> > meta-webserver/recipes-httpd/cherokee/cherokee_1.2.98.bb:PACKAGECONFIG[ffmpe
> > g] = "--with-ffmpeg,--without-ffmpeg,libav"
> > 
> > But I would like to see migration to libav-9 which currently has negative
> > D_P (mplayer2 already depends on 9*, but there are few recipes which fails
> > with libav-9 too - see earlier world builds for list).
> 
> Yes, I'm just talking about libav 0.8 here - libav 9 would remain where it 
> is. 
> That might still be problematic though given that their PN is the same. I'm 
> open to better suggestions, but I think we have to do *something* here.

Ah ok, I though you meant both versions.

Then I would rather drop 0.8 completely, otherwise it will be preferred
even with negative D_P from meta-multimedia (YOCTO #2964) and we cannot
expect people which happen to have meta-multimedia layer to know that
they are expected to update P_V everytime libav is updated in oe-core.

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] GStreamer 0.10's future

[Paul Eggleton]

On Thursday 08 May 2014 19:21:44 Martin Jansa wrote:
> On Thu, May 08, 2014 at 05:57:54PM +0100, Paul Eggleton wrote:
> > On Thursday 08 May 2014 18:19:08 Martin Jansa wrote:
> > > On Thu, May 08, 2014 at 04:07:19PM +0100, Paul Eggleton wrote:
> > > > On Thursday 08 May 2014 15:48:40 Burton, Ross wrote:
> > > > > Hi all,
> > > > > 
> > > > > Sorry for the cross-post but I want this to have a wide audience.
> > > > > 
> > > > > For the 1.7 release I want to move GStreamer 0.10 from oe-core into
> > > > > meta-multimedia, and ensure everything in oe-core has ported to
> > > > > GStreamer 1.x.  GStreamer 0.10 is considered dead upstream and is
> > > > > unmaintained so we don't need to be shipping both versions anymore.
> > > > > 
> > > > > Everyone in agreement?  Should I expect any hate mail over this?
> > > > 
> > > > +1
> > > > 
> > > > The next question is does that mean for the "old" libav (which
> > > > gst-ffmpeg
> > > > depends upon), do we move that as well or drop it?
> > > 
> > > libav was migrated to oe-core quite recently and there is couple of
> > > recipes in meta-oe, meta-webserver depending on it/ffmpeg so moving to
> > > meta-multimedia wouldn't be very easy.
> > > 
> > > meta-multimedia/recipes-multimedia/sox/sox_14.4.0.bb:DEPENDS = "libpng
> > > libav libsndfile1"
> > > meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb:DEPENDS = "libusb1
> > > libcec libplist expat yajl gperf-native libxmu fribidi mpeg2dec ffmpeg
> > > samba fontconfig curl python libass libmodplug libmicrohttpd wavpack
> > > libmms cmake-native libsdl-image libsdl-mixer virtual/egl mysql5
> > > sqlite3 libmms faad2 libcdio libpcre boost lzo enca avahi
> > > libsamplerate0
> > > libxinerama libxrandr libxtst bzip2 virtual/libsdl jasper zip-native
> > > zlib
> > > libtinyxml libmad"
> > > meta-multimedia/recipes-multimedia/musicpd/mpd_0.18.9.bb:DEPENDS =
> > > "alsa-lib libsamplerate0 libsndfile1 libvorbis libogg faad2 ffmpeg curl
> > > sqlite bzip2 pulseaudio" meta-multimedia/recipes-multimedia/vlc/vlc.inc:
> > > faad2 ffmpeg flac libxpm libxinerama fluidsynth alsa-lib libdvdcss \
> > > 
> > > meta-oe/recipes-multimedia/nonworking/minidlna/minidlna_1.0.25.bb:DEPEND
> > > S =
> > > "flac libav jpeg sqlite3 libexif libogg libid3tag"
> > > meta-oe/recipes-support/opencv/opencv_2.4.bb:PACKAGECONFIG ??= "eigen
> > > gtk
> > > jpeg libav png tiff v4l"
> > > meta-oe/recipes-graphics/gegl/gegl_0.2.0.bb:PACKAGECONFIG[avformat] =
> > > "--with-libavformat,--without-libavformat,libav"
> > > meta-oe/recipes-multimedia/libpostproc/libpostproc_git.bb:DEPENDS =
> > > "libav"
> > > meta-oe/recipes-multimedia/mplayer/mplayer2_git.bb:DEPENDS = "libvpx
> > > libdvdread libtheora virtual/libsdl ffmpeg xsp zlib \
> > > 
> > > meta-webserver/recipes-httpd/cherokee/cherokee_1.2.98.bb:PACKAGECONFIG[f
> > > fmpe g] = "--with-ffmpeg,--without-ffmpeg,libav"
> > > 
> > > But I would like to see migration to libav-9 which currently has
> > > negative
> > > D_P (mplayer2 already depends on 9*, but there are few recipes which
> > > fails
> > > with libav-9 too - see earlier world builds for list).
> > 
> > Yes, I'm just talking about libav 0.8 here - libav 9 would remain where it
> > is. That might still be problematic though given that their PN is the
> > same. I'm open to better suggestions, but I think we have to do
> > *something* here.
> Ah ok, I though you meant both versions.
> 
> Then I would rather drop 0.8 completely, otherwise it will be preferred
> even with negative D_P from meta-multimedia (YOCTO #2964) and we cannot
> expect people which happen to have meta-multimedia layer to know that
> they are expected to update P_V everytime libav is updated in oe-core.

Hmm. Perhaps a less intrusive solution then would be to create a completely 
separate meta-gstreamer0.10 layer for those that still really need it rather 
than putting it in meta-multimedia?

Cheers,
Paul

-- 

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

[yocto] [meta-raspberrypi][PATCH 2/2] omxplayer: Separate build directory is broken for this package

[Andrei Gherzan]

Change-Id: If08395ecd79c1d8e9a269ba03efba863de8dbe9d
Signed-off-by: Andrei Gherzan 
---
 recipes-multimedia/omxplayer/omxplayer_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-multimedia/omxplayer/omxplayer_git.bb 
b/recipes-multimedia/omxplayer/omxplayer_git.bb
index b878fb3..cee68e1 100644
--- a/recipes-multimedia/omxplayer/omxplayer_git.bb
+++ b/recipes-multimedia/omxplayer/omxplayer_git.bb
@@ -21,7 +21,7 @@ S = "${WORKDIR}/git"
 
 COMPATIBLE_MACHINE = "raspberrypi"
 
-inherit autotools
+inherit autotools-brokensep
 
 # Needed in ffmpeg configure
 export TEMPDIR = "${S}/tmp"
-- 
1.8.5.3

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

[yocto] [meta-raspberrypi][PATCH 1/2] bcm2835: Fix recipe when using separate build directory

[Andrei Gherzan]

Change-Id: I18f41c1cd3a0b1158e96e6d2d4455268700d3496
Signed-off-by: Andrei Gherzan 
---
 recipes-bcm/bcm2835/bcm2835_1.36.bb | 25 -
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/recipes-bcm/bcm2835/bcm2835_1.36.bb 
b/recipes-bcm/bcm2835/bcm2835_1.36.bb
index b5d9992..6997565 100644
--- a/recipes-bcm/bcm2835/bcm2835_1.36.bb
+++ b/recipes-bcm/bcm2835/bcm2835_1.36.bb
@@ -8,7 +8,6 @@ AUTHOR = "Mike McCauley (mi...@open.com.au)"
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
 
-
 COMPATIBLE_MACHINE = "raspberrypi"
 
 SRC_URI = "http://www.open.com.au/mikem/bcm2835/bcm2835-${PV}.tar.gz";
@@ -16,26 +15,26 @@ SRC_URI = 
"http://www.open.com.au/mikem/bcm2835/bcm2835-${PV}.tar.gz";
 SRC_URI[md5sum] = "3299ddaef60f80b7f85de3318f08dee7"
 SRC_URI[sha256sum] = 
"b4dfcdb453d44ba9ff55634ce7e0ddca21b96355ab61e40b4c3afb9406d4b8d2"
 
-PACKAGES += "${PN}-tests"
-
-FILES_${PN} = ""
-FILES_${PN}-tests = "${libdir}/${BPN}"
-FILES_${PN}-dbg += "${libdir}/${BPN}/.debug"
-
 inherit autotools
 
 do_compile_append() {
-#Now compiling the examples provided by the package
-for file in examples/*
-do
-${CC} ${file}/${file##*/}.c -o ${file}/${file##*/} -Bstatic -L${S}/src 
-lbcm2835 -I${S}/src
+# Now compiling the examples provided by the package
+mkdir -p ${B}/examples
+for file in `ls ${S}/examples`; do
+${CC} ${S}/examples/${file}/${file}.c -o ${B}/examples/${file} 
-Bstatic -L${B}/src -lbcm2835 -I${S}/src
 done
 }
 
 do_install_append() {
 install -d ${D}/${libdir}/${BPN}
-for file in examples/*
+for file in ${B}/examples/*
 do
-install -m 0755 ${file}/${file##*/} ${D}/${libdir}/${BPN}
+install -m 0755 ${file} ${D}/${libdir}/${BPN}
 done
 }
+
+PACKAGES += "${PN}-tests"
+
+FILES_${PN} = ""
+FILES_${PN}-tests = "${libdir}/${BPN}"
+FILES_${PN}-dbg += "${libdir}/${BPN}/.debug"
-- 
1.8.5.3

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

Re: [yocto] [meta-raspberrypi][PATCH] xserver-xf86-config: remove changes of THISDIR and FILESPATH

[Andrei Gherzan]

On Fri, Apr 18, 2014 at 4:04 PM, Michaël Burtin
wrote:

> THISDIR and FILESPATH are not supposed to be changed from within
> recipes. This was causing troubles with other bbappend.
>
> Change-Id: I7c3c788ddb61b0b790a9fe06f86e4bd93a822c8c
> Signed-off-by: Michaël Burtin 
> ---
>  recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git
> a/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
> b/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
> index 3e86645..0b4dc31 100644
> --- a/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
> +++ b/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
> @@ -3,9 +3,6 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>  # Don't forget to bump PRINC if you update the extra files.
>  PRINC := "${@int(PRINC) + 5}"
>
> -THISDIR := "${@os.path.dirname(bb.data.getVar('FILE', d, True))}"
> -FILESPATH =. "${@base_set_filespath(["${THISDIR}/${PN}"], d)}:"
> -
>  SRC_URI_append_raspberrypi = " file://xorg.conf.d/10-evdev.conf "
>
>  do_install_append_raspberrypi () {
> --
> 1.9.1
>

Merged. Thank you.

-- 
*Andrei Gherzan*
m: +40.744.478.414 |  f: +40.31.816.28.12
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SATO on Intel DN2800MT

[r10kindsofpeople]

On Thu, May 8, 2014 at 12:39 PM, Chris Tapp  wrote:

> Hi John,
>
> On 8 May 2014, at 16:25, r10kindsofpeople 
> wrote:
>
> > I'm trying to experiment with the SATO build on a DN2800MT with a VGA
> monitor, but can't seem to get going.  The binaries from Daisy and
> genericX86 get as far as the Yocto progress bar complete, and then go
> black.  Any quick hints?
>
> Have a look in the README file for the cedartrail BSP. At the bottom you
> will find:
>
> Work Around for VGA and LVDS Display issue in PVR driver
> 
>
> The PVR driver has a issue that for some systems it causes
> it to incorrectly assume that a LVDS display is connected
> while infact a VGA display is connected and Vice Versa.
> If your VGA or LVDS display does not work with
> "cedartrail" MACHINE, then if you have connected a VGA display,
> add the following to the kernel command line:
>
> video=LVDS-1:d video=VGA-1:e
>
> 
>
> I suspect it's this. Watch out if you use HDMI as well - the VGA fix seems
> to break HDMI. On my systems the VGA then works, but the HDMI pauses a lot
> running the same image! I think you can use similar magic for HDMI (or did
> I just take it out?).
>
> > I note also that genericX86 looks like a complete Yocto tree rather than
> just BSP layers.  Am I right, and are there hints on how to combine this
> with a generic Daisy tree for other processors/projects?
> >
> >
> Yocto_11_0_0/genericx86-daisy-11.0.0/meta-yocto-bsp/recipes-graphics/xorg-xserver/xserver-xf86-config/genericx86/xorg.conf
> is a zero length file.   ?
> >
> > John
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
> Chris Tapp
>
> opensou...@keylevel.com
> www.keylevel.com
>
>
> Chris,

Thanks!  What version Yocto are you using?  I ask because you suggest I
check the README file for the cedartrail BSP, but I've been unable to FIND
a cedartrail BSP in anything newer than Denzil, and that only by searching
the git trees.  genericX86 is said to cover cedartrail, but it does seem,
well, generic, with nothing particularly specific to cedartrail, and much
more than what I'm used to in a Yocto BSP.

At any rate, I'll try what you suggest in terms of the kernel command line.

Thanks again,

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

Re: [yocto] couple simple questions on building for intel galileo

[Robert P. J. Day]

On Thu, 8 May 2014, Diego Sueiro wrote:

> Robert,
> Here is some instructions with some workarounds:
> http://www.malinov.com/Home/sergey-s-blog/intelgalileo-buildinglinuximage
>
> And I think that you already saw meta-intel-iot-devkit:
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-iot-devkit/

  at the moment, i am at my wit's end trying to build a simple
bootable SD card for the galileo, and since i need one of those to
boot my eventual yocto build, i figure this is at least remotely on
topic.

  what is the proper and acceptable format for a bootable SD card for
the galileo, and how does one boot from it? i have read *numerous*
online recipes, all of which differ subtlely but maddeningly from one
another. there is an alleged linux image file one can download:

  LINUX_IMAGE_FOR_SD_Intel_Galileo_v0.7.5.7z

which uncompresses and unloads into the following:

./core-image-minimal-initramfs-clanton.cpio.gz
./bzImage
./image-full-clanton.ext3
./boot
./boot/grub
./boot/grub/grub.conf

but how one "installs" that on an SD card that is bootable by a
galileo board is a mystery i have yet to fathom, and various recipes
online differ in what they think is required:

* some recipes insist the filesystem must be FAT or FAT16, while
others claim FAT or FAT32
* one recipe will claim that the partition must be bootable, another
insists it works without that
* some recipes explain that the SD card should contain one partition
(as in, you know, /dev/sdc1), while another recipe *appears* to claim
that you need to format the *raw* SD card as a FAT partition

  i have tried various incantations of fdisk and mkfs and so on, to
the point where i am quite prepared to toss this board out a second
story window.

  can anyone point me at a set of instructions that will give me a
bootable SD card for this board?

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] [meta-raspberrypi][PATCH] Remove uses of PRINC

[Andrei Gherzan]

On Fri, May 02, 2014 at 03:46:44PM +, Paul Barker wrote:
> PRINC is now obsolete and the PR Service should be used instead to keep PR
> values incrementing on change.
>
> A patch has also been submitted to openembedded-core to bump the appropriate 
> PR
> values so that PR doesn't move backwards. This patch should only be applied
> after that patch, and only to branches which include that patch (ie. if that
> patch doesn't go into daisy in oe-core, this patch shouldn't go into daisy in
> meta-raspberrypi).
>
> Signed-off-by: Paul Barker 
> ---
>  recipes-bsp/formfactor/formfactor_0.0.bbappend | 1 -
>  recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend | 3 ---
>  2 files changed, 4 deletions(-)
>
> diff --git a/recipes-bsp/formfactor/formfactor_0.0.bbappend 
> b/recipes-bsp/formfactor/formfactor_0.0.bbappend
> index 0003480..72d991c 100644
> --- a/recipes-bsp/formfactor/formfactor_0.0.bbappend
> +++ b/recipes-bsp/formfactor/formfactor_0.0.bbappend
> @@ -1,2 +1 @@
>  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> -PRINC = "1"
> diff --git a/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend 
> b/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
> index 3e86645..e37f942 100644
> --- a/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
> +++ b/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
> @@ -1,8 +1,5 @@
>  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
> -# Don't forget to bump PRINC if you update the extra files.
> -PRINC := "${@int(PRINC) + 5}"
> -
>  THISDIR := "${@os.path.dirname(bb.data.getVar('FILE', d, True))}"
>  FILESPATH =. "${@base_set_filespath(["${THISDIR}/${PN}"], d)}:"
>

Merged. Thanks.

--
Andrei Gherzan
m: +40.744.478.414 | f: +40.31.816.28.12
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Daisy branch for meta-raspberrypi

[Andrei Gherzan]

Daisy branch was created in all repos (yocto, github and gerrit). Thanks.


On Wed, Apr 30, 2014 at 8:14 PM, Paul Barker  wrote:

> Hi,
>
> I'm looking to create a new Raspberry Pi image now Yocto 1.6 is out.
> oe-core has a 'daisy' branch and meta-openembedded should be following
> soon.
>
> Could we get a 'daisy' branch created in meta-raspberrypi? If there's
> anything which needs doing before that is branched let me know and
> I'll see if I have time to help out.
>
> Thanks,
>
> --
> Paul Barker
>
> Email: p...@paulbarker.me.uk
> http://www.paulbarker.me.uk
>



-- 
*Andrei Gherzan*
m: +40.744.478.414 |  f: +40.31.816.28.12
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 9/9] linux-yocto: migrate from 3.10 to 3.14

[Joe MacDonald]

The default kernel is now 3.14.  Since the removal of PRINC support leaves
the 3.10 recipe in a difficult-to-work-with state, now seems like a good
time to move to the new kernel.

Signed-off-by: Joe MacDonald 
---
 .../linux/{linux-yocto_3.10.bbappend => linux-yocto_3.14.bbappend}|1 -
 1 file changed, 1 deletion(-)
 rename recipes-kernel/linux/{linux-yocto_3.10.bbappend => 
linux-yocto_3.14.bbappend} (97%)

So, really, I started trying to make sure that the 3.10 kernel package feeds
wouldn't go backward and then realized this was kind of a fool's errand, since
we're building 3.14 by default anyway and without an existing linux-yocto-*
bbappend for it, it's never had the PRINC problem.  So I propose ignoring the
problem since it's going away on its own anyway.

diff --git a/recipes-kernel/linux/linux-yocto_3.10.bbappend 
b/recipes-kernel/linux/linux-yocto_3.14.bbappend
similarity index 97%
rename from recipes-kernel/linux/linux-yocto_3.10.bbappend
rename to recipes-kernel/linux/linux-yocto_3.14.bbappend
index 159d63b..4118cc0 100644
--- a/recipes-kernel/linux/linux-yocto_3.10.bbappend
+++ b/recipes-kernel/linux/linux-yocto_3.14.bbappend
@@ -1,4 +1,3 @@
-PRINC = "1"
 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
 
 # Enable selinux support in the kernel if the feature is enabled
-- 
1.7.10.4

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

Re: [yocto] couple simple questions on building for intel galileo

[Robert P. J. Day]

On Thu, 8 May 2014, Rob Woolley wrote:

> Hi Rob,
> Have you seen the Quark BSP Build Guide?
>
> https://communities.intel.com/servlet/JiveServlet/previewBody/21882-102-1-25153/Quark_BSPBuildGuide_329687_001.pdf

  already on my reading/testing list, but i'm still reluctant to jump
over this issue and move on to more advanced stuff. for the purpose of
process, i want to clarify how to boot this board off of simple SD
card, and i have yet to figure that out. g ...

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] couple simple questions on building for intel galileo

[Rob Woolley]

Hi Rob,

Have you seen the Quark BSP Build Guide?

https://communities.intel.com/servlet/JiveServlet/previewBody/21882-102-1-25153/Quark_BSPBuildGuide_329687_001.pdf

Regards,
Rob



On Thu, May 8, 2014 at 1:58 PM, Robert P. J. Day wrote:

> On Thu, 8 May 2014, Diego Sueiro wrote:
>
> > Robert,
> > Here is some instructions with some workarounds:
> >
> http://www.malinov.com/Home/sergey-s-blog/intelgalileo-buildinglinuximage
> >
> > And I think that you already saw meta-intel-iot-devkit:
> > http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-iot-devkit/
>
>   at the moment, i am at my wit's end trying to build a simple
> bootable SD card for the galileo, and since i need one of those to
> boot my eventual yocto build, i figure this is at least remotely on
> topic.
>
>   what is the proper and acceptable format for a bootable SD card for
> the galileo, and how does one boot from it? i have read *numerous*
> online recipes, all of which differ subtlely but maddeningly from one
> another. there is an alleged linux image file one can download:
>
>   LINUX_IMAGE_FOR_SD_Intel_Galileo_v0.7.5.7z
>
> which uncompresses and unloads into the following:
>
> ./core-image-minimal-initramfs-clanton.cpio.gz
> ./bzImage
> ./image-full-clanton.ext3
> ./boot
> ./boot/grub
> ./boot/grub/grub.conf
>
> but how one "installs" that on an SD card that is bootable by a
> galileo board is a mystery i have yet to fathom, and various recipes
> online differ in what they think is required:
>
> * some recipes insist the filesystem must be FAT or FAT16, while
> others claim FAT or FAT32
> * one recipe will claim that the partition must be bootable, another
> insists it works without that
> * some recipes explain that the SD card should contain one partition
> (as in, you know, /dev/sdc1), while another recipe *appears* to claim
> that you need to format the *raw* SD card as a FAT partition
>
>   i have tried various incantations of fdisk and mkfs and so on, to
> the point where i am quite prepared to toss this board out a second
> story window.
>
>   can anyone point me at a set of instructions that will give me a
> bootable SD card for this board?
>
> rday
>
> --
>
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SATO on Intel DN2800MT

[Chris Tapp]

On 8 May 2014, at 18:52, r10kindsofpeople  wrote:

> On Thu, May 8, 2014 at 12:39 PM, Chris Tapp  wrote:
> Hi John,
> 
> On 8 May 2014, at 16:25, r10kindsofpeople  wrote:
> 
> > I'm trying to experiment with the SATO build on a DN2800MT with a VGA 
> > monitor, but can't seem to get going.  The binaries from Daisy and 
> > genericX86 get as far as the Yocto progress bar complete, and then go 
> > black.  Any quick hints?
> 
> Have a look in the README file for the cedartrail BSP. At the bottom you will 
> find:
> 
> Work Around for VGA and LVDS Display issue in PVR driver
> 
> 
> The PVR driver has a issue that for some systems it causes
> it to incorrectly assume that a LVDS display is connected
> while infact a VGA display is connected and Vice Versa.
> If your VGA or LVDS display does not work with
> "cedartrail" MACHINE, then if you have connected a VGA display,
> add the following to the kernel command line:
> 
> video=LVDS-1:d video=VGA-1:e
> 
> 
> 
> I suspect it's this. Watch out if you use HDMI as well - the VGA fix seems to 
> break HDMI. On my systems the VGA then works, but the HDMI pauses a lot 
> running the same image! I think you can use similar magic for HDMI (or did I 
> just take it out?).
> 
> > I note also that genericX86 looks like a complete Yocto tree rather than 
> > just BSP layers.  Am I right, and are there hints on how to combine this 
> > with a generic Daisy tree for other processors/projects?
> >
> > Yocto_11_0_0/genericx86-daisy-11.0.0/meta-yocto-bsp/recipes-graphics/xorg-xserver/xserver-xf86-config/genericx86/xorg.conf
> >  is a zero length file.   ?
> >
> > John
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> 
> Chris Tapp
> 
> opensou...@keylevel.com
> www.keylevel.com
> 
> 
> 
> Chris,
> 
> Thanks!  What version Yocto are you using?  I ask because you suggest I check 
> the README file for the cedartrail BSP, but I've been unable to FIND a 
> cedartrail BSP in anything newer than Denzil, and that only by searching the 
> git trees.  genericX86 is said to cover cedartrail, but it does seem, well, 
> generic, with nothing particularly specific to cedartrail, and much more than 
> what I'm used to in a Yocto BSP.

I'm using 'danny' as that's the latest version which includes video hardware 
acceleration for the DN2800.

>   At any rate, I'll try what you suggest in terms of the kernel command line.

The README says this fixes the issue for the PVR drivers, but I don't think 
they're included in later versions.

If you've still got problems, it may be worth posting to the meta-intel mailing 
list as well as that's where Intel BSPs are discussed.

> Thanks again,
> 
> John

Chris Tapp

opensou...@keylevel.com
www.keylevel.com



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

[yocto] Does Yocto need some "LTS" releases?

[Chris Tapp]

I've had a few potential clients ask how security updates and general patches 
are applied to embedded products built using Yocto.

If they're really embedded, then the only way to to this is by replacing the 
rootfs - especially when they boot read-only.

A second complication is when support for a BSP gets dropped so later versions, 
which generally include updates and patches, can't be used.

It feels to me as if there should be some "LTS" releases which developers could 
focus on when choosing a version.

Or is there already some way of doing this that I just haven't spotted?

Chris Tapp

opensou...@keylevel.com
www.keylevel.com



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

Re: [yocto] Does Yocto need some "LTS" releases?

[Mark Hatle]

On 5/8/14, 2:54 PM, Chris Tapp wrote:

I've had a few potential clients ask how security updates and general patches
are applied to embedded products built using Yocto.


The Yocto Project, via it's contributors usually provides support for the -two- 
releases + master.


That means effectively a one year community (best-effort) support model for each 
release.  So today that would be 1.5 and 1.6.  (Master is continuously 
developed, and I'd expect any relevant fixes to go there as well.)


Note, this is all contingent upon contributions from Yocto Project members and 
the Open Embedded community at large.  Without contributions, there is no support.



If they're really embedded, then the only way to to this is by replacing the
rootfs - especially when they boot read-only.


See the million threads on "field upgrade".  There is no one answer.  Device 
upgrade, Image upgrade, package upgrade, and file upgrades are all 
possibilities... but these need to be built into the device during it's design. 
 There are no best practices available, as everyone seems to have different 
requirements.



A second complication is when support for a BSP gets dropped so later
versions, which generally include updates and patches, can't be used.


If you are releasing a product, you shouldn't be expecting to migrate (in a 
product lifecycle) from YP 1.4 to YP 1.5 to YP 1.6, etc.  Each release is 
individual, and an overall target based upgrade and BSP obsolescence is not part 
of the project.  This is really the realm of the device manufacturer, OSV and 
other commercial vendors of YP components.



It feels to me as if there should be some "LTS" releases which developers
could focus on when choosing a version.


It all comes down to contributions in the end.  If nobody is contributing, don't 
expect updates.  There has been talk over time of an LTS type release.  I've 
heard everything from extending the 1 year to '2' years.. or as contributions 
are available.


But if you want long term support, your best bet is to find an OSV (or other 
Yocto Project participant) that is willing to do long term support and 
maintenance of a product.


(Speaking for Wind River for a second, we do offer extended support for many 
many more years then what I would ever expect the community to support.  I would 
expect the same from our competitors.)



Or is there already some way of doing this that I just haven't spotted?


This is where community support really transitions to commercial.  The community 
is interested in enabling new designs and 'maker' projects.  Commercial is 
interested in building products and long term support.  (IMHO, others might 
disagree.)


--Mark


Chris Tapp

opensou...@keylevel.com
www.keylevel.com




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

Re: [yocto] Does Yocto need some "LTS" releases?

[Chris Tapp]

Hi Mark,

Thanks for the comments.

On 8 May 2014, at 21:11, Mark Hatle  wrote:

> On 5/8/14, 2:54 PM, Chris Tapp wrote:
>> I've had a few potential clients ask how security updates and general patches
>> are applied to embedded products built using Yocto.
> 
> The Yocto Project, via it's contributors usually provides support for the 
> -two- releases + master.
> 
> That means effectively a one year community (best-effort) support model for 
> each release.  So today that would be 1.5 and 1.6.  (Master is continuously 
> developed, and I'd expect any relevant fixes to go there as well.)
> 
> Note, this is all contingent upon contributions from Yocto Project members 
> and the Open Embedded community at large.  Without contributions, there is no 
> support.

That's true, and I've always been very impressed with the number and quality of 
the contributors to YP. It's a really good case-study to throw at those who say 
opensource doesn't work or make commercial sense ;-)

> If they're really embedded, then the only way to to this is by replacing the
>> rootfs - especially when they boot read-only.
> 
> See the million threads on "field upgrade".  There is no one answer.  Device 
> upgrade, Image upgrade, package upgrade, and file upgrades are all 
> possibilities... but these need to be built into the device during it's 
> design.  There are no best practices available, as everyone seems to have 
> different requirements.

Yes, I've followed a few of those with interest. We've moved to a model of 
using iPXE to network boot (we have a closed client-server system) a read-only 
image to make it easier (for us).

> A second complication is when support for a BSP gets dropped so later
>> versions, which generally include updates and patches, can't be used.
> 
> If you are releasing a product, you shouldn't be expecting to migrate (in a 
> product lifecycle) from YP 1.4 to YP 1.5 to YP 1.6, etc.  Each release is 
> individual, and an overall target based upgrade and BSP obsolescence is not 
> part of the project.  This is really the realm of the device manufacturer, 
> OSV and other commercial vendors of YP components.

That's how I try and work, sticking with a single version of YP until a major 
version change of our application or we need to switch to different hardware. A 
bit of layer management is all that's been needed so far to allow me to build 
for different hardware.

> It feels to me as if there should be some "LTS" releases which developers
>> could focus on when choosing a version.
> 
> It all comes down to contributions in the end.  If nobody is contributing, 
> don't expect updates.  There has been talk over time of an LTS type release.  
> I've heard everything from extending the 1 year to '2' years.. or as 
> contributions are available.
> 
> But if you want long term support, your best bet is to find an OSV (or other 
> Yocto Project participant) that is willing to do long term support and 
> maintenance of a product.
> 
> (Speaking for Wind River for a second, we do offer extended support for many 
> many more years then what I would ever expect the community to support.  I 
> would expect the same from our competitors.)
> 
>> Or is there already some way of doing this that I just haven't spotted?
> 
> This is where community support really transitions to commercial.  The 
> community is interested in enabling new designs and 'maker' projects.  
> Commercial is interested in building products and long term support.  (IMHO, 
> others might disagree.)

Basically, this all fits with my expectations / understanding. I can now show 
clients that I am talking about "the real world" (TM) and not simply trying to 
add support costs ;-)

However, I still need to work at convincing people that it's not always as 
simple as updating one package as the update can have knock-on effects else 
where - which is why a "simple" update can end up being very time consuming 
and/or costly to implement.

One option may be to convince them that it'll be cheaper to upgrade the 
hardware at the same time if the best option is to move to a newer YP version 
and it does not include the BSP that's required.

Chris Tapp

opensou...@keylevel.com
www.keylevel.com



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

[yocto] [meta-selinux] build issue

[akuster@mvista]

Hello,

I am trying to build meta-selinux and ran into some build issues. I 
started by cloning poky and meta-selinux. I am using master on both. 
When I run "bitbake core-image-selinux", I get the following errors.


ERROR: No recipes available for:

/home/armin/work/yocto/poky/meta-selinux/recipes-core/util-linux/util-linux_2.23.2.bbappend

/home/armin/work/yocto/poky/meta-selinux/recipes-connectivity/bind/bind_9.8.1.bbappend

/home/armin/work/yocto/poky/meta-selinux/recipes-kernel/linux/linux-yocto_3.8.bbappend

/home/armin/work/yocto/poky/meta-selinux/recipes-connectivity/openssh/openssh_6.4p1.bbappend

/home/armin/work/yocto/poky/meta-selinux/recipes-extended/psmisc/psmisc_22.20.bbappend

/home/armin/work/yocto/poky/meta-selinux/recipes-extended/augeas/augeas_1.1.0.bbappend

/home/armin/work/yocto/poky/meta-selinux/recipes-graphics/mesa/mesa_9.2.2.bbappend


Is this a config issue or am I using the wrong sources?

regards,
Armin
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] GStreamer 0.10's future

[Richard Purdie]

On Thu, 2014-05-08 at 17:57 +0100, Paul Eggleton wrote:
> Yes, I'm just talking about libav 0.8 here - libav 9 would remain where it 
> is. 
> That might still be problematic though given that their PN is the same. I'm 
> open to better suggestions, but I think we have to do *something* here.

We could put a PROVIDES += "xxx" into one of the libavs and then DEPENDS
on that in the corresponding recipes...

Cheers,

Richard

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

Re: [yocto] Does Yocto need some "LTS" releases?

[Michael Stickel]

On 08.05.2014 23:00, Chris Tapp wrote:
> However, I still need to work at convincing people that it's not always as 
> simple as updating one package as the update can have knock-on effects else 
> where - which is why a "simple" update can end up being very time consuming 
> and/or costly to implement.

"Mystical man month"

You need more that a hacker in a garage to build a system of software
infrastructure.

Best regards
Michael

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

Re: [yocto] Does Yocto need some "LTS" releases?

[Philip Balister]

On 05/08/2014 02:53 PM, Michael Stickel wrote:
> 
> On 08.05.2014 23:00, Chris Tapp wrote:
>> However, I still need to work at convincing people that it's not always as 
>> simple as updating one package as the update can have knock-on effects else 
>> where - which is why a "simple" update can end up being very time consuming 
>> and/or costly to implement.
> 
> "Mystical man month"
> 
> You need more that a hacker in a garage to build a system of software
> infrastructure.

But the Yocto Project does make it easier for him :)

Philip

> 
> Best regards
> Michael
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Definition of Yocto tasks

[Bob Feretich]

On 5/7/2014 5:58 AM, Paul Eggleton wrote:

On Tuesday 06 May 2014 15:23:45 Bob Feretich wrote:

On 5/6/2014 2:38 AM, Paul Eggleton wrote:

On Tuesday 06 May 2014 06:47:08 Rifenbark, Scott M wrote:

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-
boun...@yoctoproject.org] On Behalf Of Bob Feretich
Sent: Monday, May 05, 2014 4:52 PM
To: yocto@yoctoproject.org
Subject: [yocto] Definition of Yocto tasks

Is there a document that provides a detailed definition of what each
these
tasks do?
Yocto, OE, and bitbake manuals tell us how to command a specific task to
be
run, but not what they do.

The task name provides a good hint sometimes, but often that is not
enough.
Users shouldn't have to read the python code for this information. These
descriptions should be a part of the yocto manual.

Sections 5.3.4 to 5.3.11 of the Yocto mega-manual provide a good
overview
of some of these tasks in the context of a workflow, but doesn't mention
most of these tasks and doesn't go into enough detail on the tasks it
discusses.

It wouldn't be appropriate to add more detail at that point in the
manual,
but it would be appropriate to include details regarding all of the
tasks
in an appendix.

Examples...
The manual states that do_fetch fetches source, but doesn't state that
when
git is used whether it performs a pull, fetch, or clone. What are the
common failure conditions of do_fetch? And what should the user do to
fix
the problem?

do_build is mentioned a few times, but there is no reference to it being
the default task or what tasks are invoked by do_build and which are
omitted.

do_rm_work and do_wm_work_all are not mentioned at all.

Result of listtasks:
do_fetchall
... snipped ...
do_rm_work_all

I don't have the knowledge to create such an appendix, but I volunteer
to be a proofreader.

An appendix for a reference of these tasks seems like a good idea.

FYI, you may already have seen it but we have a bit of coverage for the
common>
tasks in the following section of the manual:
http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#clo
ser-look

This section seems to be a more polished version of the mega manual
Sections 5.3.4 to 5.3.11.

They should be identical. The mega manual is simply the other manuals combined
together...


It provides an overview to the build process, but its still at a very high
level (few details).

Could you expand on the details are you looking for that you're not finding
there?
I was looking for more detailed information because I was trying to 
trouble shoot failures that occurred during the "do_fetch" of some source.
The most common failure was the inability to access any of the servers 
that contained the source. This was probably due to those servers being 
temporarily down for maintenance. Simply restarting the bitbake fixed 
those problems.
(A common failure that users should be told not to be concerned about. I 
did read that somewhere, but I don't remember where.)


The next problem was a recipe error effecting "do_install" of some 
recipe. I troubleshot this and got a fix from the Angstrom people. while 
troubleshooting (doing lots of double Control-Cs), I believe that I hung 
the "do_fetch" mechanism. (some "do_fetch" tasks were being executed in 
parallel with the broken "do_install"). After the "do_install" problem 
was fixed, "do_fetch" seemed to run, but didn't transfer any data (no 
network traffic), and it would eventually time out.


That raised the question regarding the use of lock files. (Did my 
Control-Cs leave a Yocto lock file intact that needed to be cleaned up? 
Did "do_fetch" use any locking mechanism? How could I do a partial 
"clean" that would fix the problem without setting my progress back 
further than necessary?)


During my search for info, I found e-mail discussions of  clean, 
cleanstate, and cleanall.  My "do_fetch" failure was occurring at about 
step 6900 of 8100 build steps. With my internet connection, restarting 
would have set me back 48 hrs, with no guarantee that the restart would 
result in a fix. I was looking for ways to "clean" the condition without 
having to completely start over. Eventually, I gave up and did the 
cleanall... it did not fix the problem.
Even though none of cleanxxx tasks worked for me in fixing the 
"do_fetch" hang, info about them should have been easier to find.


I fixed the problem with a shotgun approach.
I erased the entire Yocto build directory, rebooted my host build 
system, and power cycled my network router and DSL modem. This worked, 
but was probably more than I needed to do. (I now think that my 
"do_fetch" hang was do to not properly reinitializing a firewall port.)


My searches also led me to the "do_fetchall" task, as I has just visited 
with a friend whose network connection was 10x better than mine. Had I 
know about fetchall, I would have used it during the visit.


In general, the appendix should contain a description of the program 
logic of the task

Re: [yocto] [meta-selinux] build issue

[Joe MacDonald]

Hi Armin,

I'm guessing you don't have BB_DANGLINGAPPENDS_WARNONLY set in your
local.conf.  I'm working through some other build issues right now,
but certainly nothing like what you're seeing.  :-)

-J.

On Thu, May 8, 2014 at 5:07 PM, akuster@mvista  wrote:
> Hello,
>
> I am trying to build meta-selinux and ran into some build issues. I started
> by cloning poky and meta-selinux. I am using master on both. When I run
> "bitbake core-image-selinux", I get the following errors.
>
> ERROR: No recipes available for:
>
> /home/armin/work/yocto/poky/meta-selinux/recipes-core/util-linux/util-linux_2.23.2.bbappend
>
> /home/armin/work/yocto/poky/meta-selinux/recipes-connectivity/bind/bind_9.8.1.bbappend
>
> /home/armin/work/yocto/poky/meta-selinux/recipes-kernel/linux/linux-yocto_3.8.bbappend
>
> /home/armin/work/yocto/poky/meta-selinux/recipes-connectivity/openssh/openssh_6.4p1.bbappend
>
> /home/armin/work/yocto/poky/meta-selinux/recipes-extended/psmisc/psmisc_22.20.bbappend
>
> /home/armin/work/yocto/poky/meta-selinux/recipes-extended/augeas/augeas_1.1.0.bbappend
>
> /home/armin/work/yocto/poky/meta-selinux/recipes-graphics/mesa/mesa_9.2.2.bbappend
>
>
> Is this a config issue or am I using the wrong sources?
>
> regards,
> Armin
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
Joe MacDonald
:wq
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Question / issue

[Paul McGougan]

Hi all.

We are currently using Poky 1.5.0.

We have created our own custom layer for our powerpc-based board.

We are running u-boot as our bootloader and want to use the new FIT (FDT) style 
kernel/dtb image blob.

To that end, in our custom layer we have a file 
poky/meta-OURS/recipes-kernel/linux/linux-yocto_3.10.bbappend, and in that file 
I have a function do_install_append() in which I call u-boot's mkimage passing 
it the kernel and DTB files that we want stored in the FIT image that we will 
use to boot from u-boot.

My first question is, is there a better place to be making the FIT image?

As a side-question to that, I was surprised that there isn't native support 
already for creating this type of u-boot image considering how useful it is, 
does anyone know if there is a specific reason no one has done this yet?

Secondly, (and this is our main issue) I have found that by adding the 
do_install_append function, even if it is completely empty, whenever I try to 
bitbake anything that depends on the kernel, that bitbake always re-runs the 
kernel install stage, even when there have been no changes. Literally I can run 
a bitbake, then run the same bitbake command again, and both times the kernel 
install stage gets run (this is a problem because it takes a long time to run). 
It appears to be happening because the stampfile is not found every time (the 
hash appears to be wrong). Is this a bug? Is there a fix or work-around for 
this problem?

Thanks.

Paul.

Confidentiality Notice:  This message (including attachments) is a private 
communication solely for use of the intended recipient(s).  
If you are not the intended recipient(s) or believe you received this message 
in error, notify the sender immediately and then delete this 
message.  Any other use, retention, dissemination or copying is prohibited and 
may be a violation of law, including the Electronic 
Communication Privacy Act of 1986."
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Definition of Yocto tasks

[Rifenbark, Scott M]

Bob, 

This is good information regarding the process you had to go through and what 
would have helped along the way.  I am currently working on a new chapter that 
documents the do_ tasks in the YP Reference Manual.  

Scott

>-Original Message-
>From: yocto-boun...@yoctoproject.org [mailto:yocto-
>boun...@yoctoproject.org] On Behalf Of Bob Feretich
>Sent: Thursday, May 08, 2014 4:25 PM
>To: yocto@yoctoproject.org
>Subject: Re: [yocto] Definition of Yocto tasks
>
>
>On 5/7/2014 5:58 AM, Paul Eggleton wrote:
>> On Tuesday 06 May 2014 15:23:45 Bob Feretich wrote:
>>> On 5/6/2014 2:38 AM, Paul Eggleton wrote:
 On Tuesday 06 May 2014 06:47:08 Rifenbark, Scott M wrote:
>> -Original Message-
>> From: yocto-boun...@yoctoproject.org [mailto:yocto-
>> boun...@yoctoproject.org] On Behalf Of Bob Feretich
>> Sent: Monday, May 05, 2014 4:52 PM
>> To: yocto@yoctoproject.org
>> Subject: [yocto] Definition of Yocto tasks
>>
>> Is there a document that provides a detailed definition of what
>> each these tasks do?
>> Yocto, OE, and bitbake manuals tell us how to command a specific
>> task to be run, but not what they do.
>>
>> The task name provides a good hint sometimes, but often that is
>> not enough.
>> Users shouldn't have to read the python code for this information.
>> These descriptions should be a part of the yocto manual.
>>
>> Sections 5.3.4 to 5.3.11 of the Yocto mega-manual provide a good
>> overview of some of these tasks in the context of a workflow, but
>> doesn't mention most of these tasks and doesn't go into enough
>> detail on the tasks it discusses.
>>
>> It wouldn't be appropriate to add more detail at that point in the
>> manual, but it would be appropriate to include details regarding
>> all of the tasks in an appendix.
>>
>> Examples...
>> The manual states that do_fetch fetches source, but doesn't state
>> that when git is used whether it performs a pull, fetch, or clone.
>> What are the common failure conditions of do_fetch? And what
>> should the user do to fix the problem?
>>
>> do_build is mentioned a few times, but there is no reference to it
>> being the default task or what tasks are invoked by do_build and
>> which are omitted.
>>
>> do_rm_work and do_wm_work_all are not mentioned at all.
>>
>> Result of listtasks:
>> do_fetchall
>> ... snipped ...
>> do_rm_work_all
>>
>> I don't have the knowledge to create such an appendix, but I
>> volunteer to be a proofreader.
> An appendix for a reference of these tasks seems like a good idea.
 FYI, you may already have seen it but we have a bit of coverage for
 the
 common>
 tasks in the following section of the manual:
 http://www.yoctoproject.org/docs/current/ref-manual/ref-
>manual.html#clo
 ser-look
>>> This section seems to be a more polished version of the mega manual
>>> Sections 5.3.4 to 5.3.11.
>> They should be identical. The mega manual is simply the other manuals
>> combined together...
>>
>>> It provides an overview to the build process, but its still at a very
>>> high level (few details).
>> Could you expand on the details are you looking for that you're not
>> finding there?
>I was looking for more detailed information because I was trying to trouble
>shoot failures that occurred during the "do_fetch" of some source.
>The most common failure was the inability to access any of the servers that
>contained the source. This was probably due to those servers being
>temporarily down for maintenance. Simply restarting the bitbake fixed those
>problems.
>(A common failure that users should be told not to be concerned about. I did
>read that somewhere, but I don't remember where.)
>
>The next problem was a recipe error effecting "do_install" of some recipe. I
>troubleshot this and got a fix from the Angstrom people. while
>troubleshooting (doing lots of double Control-Cs), I believe that I hung the
>"do_fetch" mechanism. (some "do_fetch" tasks were being executed in
>parallel with the broken "do_install"). After the "do_install" problem was
>fixed, "do_fetch" seemed to run, but didn't transfer any data (no network
>traffic), and it would eventually time out.
>
>That raised the question regarding the use of lock files. (Did my Control-Cs
>leave a Yocto lock file intact that needed to be cleaned up?
>Did "do_fetch" use any locking mechanism? How could I do a partial "clean"
>that would fix the problem without setting my progress back further than
>necessary?)
>
>During my search for info, I found e-mail discussions of  clean, cleanstate, 
>and
>cleanall.  My "do_fetch" failure was occurring at about step 6900 of 8100 build
>steps. With my internet connection, restarting would have set me back 48 hrs,
>with no guarantee that the restart would result in a fix. I was looking for 
>ways
>to "clean" the condition wi

Re: [yocto] Third Party Components Integration in Yocto

[Meenakumari Shedole]

Thanks for your response Alex.

I gone with all these steps but not helpful.

Here I am sharing my recipe and bb-example.bb and do_install log.


bb-example.bb:

LICENSE = "GPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"

PR = "r0"

inherit module

SRC_URI =   "file://bb-example.tar.bz2/"

S = "${WORKDIR}/bb-example"

inherit autotools pkgconfig 

do_compile() {
        make
}

do_install() {
      install -d ${D}${bindir} /
      install -m 0755 bb-example ${D}${bindir}
}
FILES_${PN} += " ${libdir}/bb-example/*.so"


do_install log:

NOTE: Executing RunQueue Tasks
+ cd /home/user1/poky/build/tmp/work/baytrail32-poky-linux/bb-example/1.0-r0/bb-example
+ do_install
+ install -d /home/user1/poky/build/tmp/work/baytrail32-poky-linux/bb-example/1.0-r0/image/usr/bin

+ install -m 0755 bb-example /home/user1/poky/build/tmp/work/baytrail32-poky-linux/bb-example/1.0-r0/image/usr/bin/

install: cannot stat `bb-example': No such file or directory
+ bb_exit_handler
+ ret=1
+ echo WARNING: exit code 1 from a shell command.
WARNING: exit code 1 from a shell command.
+ exit 1

Recipe:
cd   /home/user1/poky/meta/recipes-sato/bb-App/bb-example/bb-example.tar.bz2
cd   /home/user1/poky/meta/recipes-sato/bb-App/bb-example.bb


tar -xvf  bb-example.tar.bz2

/gdbus, /Release, Makefile, bb-example.c bb-example.h


cd  /Release,

/gdbus, makefile, objects.mk, sources.mk, subdir.mk

After do_compile and make
/home/user1/poky/build/tmp/work/baytrail32-poky-linux/bb-example/1.0-r1/./image  ./license-destdir ./bb-example.all depended folders.

Inside ./bb-example all my binaries are executing but not loading to ./image/tree..


Hope now it is very clear understanding to my problem.


Regards
Meena
















From: Alex J Lennon [ajlen...@dynamicdevices.co.uk]
Sent: Thursday, May 08, 2014 3:52 PM
To: Meenakumari Shedole
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Third Party Components Integration in Yocto



Hi Meena,

On 08/05/2014 11:05, Meenakumari Shedole wrote:



Thanks Alex,
 
Yes I installed  FILES_${PN} all package folders are creating

Tried devshell  but there is no installed bb-example in image/usr/include/…empty include folder. Bb-example is not loading inside image/……
Analysed  log_devshell , log_package, do_install, do_make.



OK so that's helpful. I have had similar problems myself with files that don't get installed and thus aren't packaged. In my experience it is usually to do with the path to the source file one is trying to install.

i.e. So for some reason the bb-example file isn't where it should be to be copied across to the target folder in the image tree.

Where does bb-example come from? Can you share the whole recipe? Can you see it where you think it should be in the devshell folder or the folder above?

If you included bb-example as a 
file:// entry added to SRC_URI then it will be copied across to the working directory ${WORKDIR}

You might want to try something like

  install -m 0755 ${WORKDIR}/bb-example ${D}${bindir}

Alternatively if bb-example is output from a build process then it will be in the source directory ${S}

In which case try

  install -m 0755 ${S}/bb-example ${D}${bindir}
  
Hope this helps!

Alex



 
Even I compared with other recipes folder structures  it is going right direction but only the binaries are not loading.
 
I guess I missed something in do_install ? no proper path?

After do_compile and make, at  do_install binaries are not able to load.
 
 
Regards
Meena
 


From: Alex J Lennon [mailto:ajlen...@dynamicdevices.co.uk]

Sent: Tuesday, May 06, 2014 9:17 PM
To: Meenakumari Shedole; 
yocto@yoctoproject.org; Beauchesne, Gwenole
Subject: Re: [yocto] Third Party Components Integration in Yocto


 
 

On 06/05/2014 15:57, Meenakumari Shedole wrote:



Hi,


 


To add 3rd party components in yocto we created bb file and modified local.conf file.


After a yocto build, 3rd party component executing the binaries and rpm packages but executed binaries are not loading inside the rpm packages, rpm package is empty.


 


Used below function in bb file. 



do_install () {


  install -d ${D}${bindir}


  install -m 0755 bb-example 
${D}${bindir}


}


 





Hi Meena,

That seems a little odd as files in ${bindir} should be packaged into the default output package as I understand it

ref: 
http://www.embeddedlinux.org.cn/OEManual/recipes_packages.html

If it were successfully installed but not packaged for any reason (e.g. in this case not a part of FILES_${PN}) then you should see a warning about an installed-vs-packaged file issue.

If you enter a devshell with bitbake -c devshell recipe-foo then do you see the installed bb-example file in within ../image/ tree?

Have you also tried looking (from the devshell) in ../temp/log.do_install, ../temp/log.do_xxx to see what is happening?

Cheers, 

Alex






can anyone please suggest me how to move further.


 


Regards

Meena






::DISCLAIMER::
---