date:20140422

[yocto] Rgardring GSTreamer1.0 integration on Yocto Dora

2014-04-22 Thread Dipesh Karmakar

Hi Carlos,

Do you have any plan to integrate Gstreamer-1.2.3 to Dora? I believe current 
Dora10.0.1 has GST-1.0.9.

Thanks,
Dipesh

-Original Message-
From: Carlos Rafael Giani [mailto:d...@pseudoterminal.org] 
Sent: Sunday, February 02, 2014 9:14 PM
To: Khaja Hussain Shaik
Cc: Nicolas Dechesne; yocto@yoctoproject.org; Dipesh Karmakar; Paul Eggleton; 
Kishore Divvela -ERS, HCL Tech
Subject: Re: [yocto] Rgardring GSTreamer1.0 integration on Yocto dylan

On 2014-01-28 13:49, Khaja Hussain Shaik wrote:
> Hi Carlos,
>
> Did you get a chance to look into the porting of gst1.0 to Dylan?
>
> Regards
> Khaja
>

I have now upgraded the recipes in meta-gstreamer1.0 to version 1.2.2. 
It is a backport from the current OE-core recipes. Furthermore, I added the Orc 
OE-core recipes to this layer. This way, gstreamer is built with Orc support by 
default, even for danny and dylan.

cheers,
Carlos

::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

[yocto] Problem with own kernel recipe on Dora

2014-04-22 Thread Richard Leitner - SKIDATA

Hi Yocto-Community,
as the subject already says I've a problem with my kernel recipe after the 
"migration" from the Dylan to the Dora (10.0.1) branch.
I've tried the 10.0.1 release tag as well as the current dora master 
(50e9ccb2aff7b9f9dca4fda99a6832c60f64de3b).

The kernel recipe I'm using is derived from the skeleton:
DESCRIPTION = "Linux Kernel"
SECTION = "kernel"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
inherit kernel
KSRC = "/home/leri/VCS/git/linux"
KBRANCH = "master"
SRC_URI = 
"git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel;nocheckout=1"
SRCREV = "2014_03_07"
PR = "sd_15.2"
LINUX_VERSION = "${PV}"
LINUX_VERSION_EXTENSION = "-${PR}+${SRCREV}"
COMPATIBLE_MACHINE = "skidata-harmony|smartcpu"
KERNEL_IMAGETYPE = "uImage"
SRC_URI += "file://defconfig"
require recipes-kernel/linux/linux-yocto.inc


This recipe was working well with the Dylan branch and following changes:
-SRC_URI = 
"git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel;nocheckout=1"
+SRC_URI = "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel"
+S = "${WORKDIR}/git"


When compiled with the dora branch the kernel hangs at "Starting kernel..." and 
doesn't start:
## Booting kernel from Legacy Image at  ...
   Image Name:   Linux-3.1.10-sd_15.2
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3181616 Bytes = 3 MiB
   Load Address: 8000
   Entry Point:  8000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...


I've already looked through the migration notes in the manual but I'm unable to 
find any hints...
Are there any ideas why the kernel doesn't start with the Dora branch?

Thank you for your help!

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

[yocto] Newbie question: How to get dependencies into compile of custom recipe?

2014-04-22 Thread Neuer User

Hi

Sorry for this simple question. I've just started building my first
image with yocto and would now like to add a (very simple) own recipe.

I followed the Yocto Development guide, added my own layer and included
the "helloworld" example.

Now I would like to exchange the helloworld.c code with a simple
gstreamer-rtsp server code
(http://cgit.freedesktop.org/gstreamer/gst-rtsp-server/tree/examples/test-launch.c).

I changed the bb file as follows, adding expecially the DEPENDS:

#
# This file was derived from the 'Hello World!' example recipe in the
# Yocto Project Development Manual.
#

DESCRIPTION = "Simple helloworld application"
SECTION = "multimedia"
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
PR = "r0"

SRC_URI = "file://cameraserver.c"

DEPENDS = "gst-rtsp gstreamer"

S = "${WORKDIR}"

do_compile() {
 ${CC} cameraserver.c -o cameraserver
}

do_install() {
 install -d ${D}${bindir}
 install -m 0755 cameraserver ${D}${bindir}
}


The package "gst-rtsp" is correctly built (as
libgstrtspserver-0.10-0-0.10.8-r0@cortexa9hf_vfp_neon), but the
compilation process of the "cameraserver.c" does not find the necessary
header include files.

NOTE: recipe camera-server-0.1-r0: task do_compile: Started
Log data follows:
| DEBUG: Executing shell function do_compile
| cameraserver.c:20:21: fatal error: gst/gst.h: No such file or directory
|  #include 
|  ^
| compilation terminated.
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at
/home/ubuntu/yocto/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/camera-server/0.1-r0/temp/log.do_compile.26393)
NOTE: recipe camera-server-0.1-r0: task do_compile: Failed


The debug of bitbake shows, however, that it correctly identifies the
dependent packages:

DEBUG: providers for gst-rtsp are: ['gst-rtsp']
DEBUG: sorted runtime providers for gst-rtsp are:
['/home/ubuntu/yocto/sources/meta-openembedded/meta-multimedia/recipes-multimedia/gstreamer/gst-rtsp_0.10.8.bb']
DEBUG: adding
'/home/ubuntu/yocto/sources/meta-openembedded/meta-multimedia/recipes-multimedia/gstreamer/gst-rtsp_0.10.8.bb'
to satisfy runtime 'gst-rtsp'
DEBUG: providers for gstreamer are: ['gstreamer']
DEBUG: sorted runtime providers for gstreamer are:
['/home/ubuntu/yocto/sources/poky/meta/recipes-multimedia/gstreamer/gstreamer_0.10.36.bb']
DEBUG: adding
'/home/ubuntu/yocto/sources/poky/meta/recipes-multimedia/gstreamer/gstreamer_0.10.36.bb'
to satisfy runtime 'gstreamer'


So, what am I doing wrong? Do I explicitly need to add the dependencies
to the compile environment somehow? If yes, where are the found
directories stored?

Or am I doing this all very wrong? I am really very new to Yocto.

Thanks for any help!

Michael

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

Re: [yocto] Problem with own kernel recipe on Dora

2014-04-22 Thread Richard Purdie

On Tue, 2014-04-22 at 07:52 +, Richard Leitner - SKIDATA wrote:
> Hi Yocto-Community,
> as the subject already says I've a problem with my kernel recipe after the 
> "migration" from the Dylan to the Dora (10.0.1) branch.
> I've tried the 10.0.1 release tag as well as the current dora master 
> (50e9ccb2aff7b9f9dca4fda99a6832c60f64de3b).
> 
> The kernel recipe I'm using is derived from the skeleton:
> DESCRIPTION = "Linux Kernel"
> SECTION = "kernel"
> LICENSE = "GPLv2"
> LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
> inherit kernel
> KSRC = "/home/leri/VCS/git/linux"
> KBRANCH = "master"
> SRC_URI = 
> "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel;nocheckout=1"
> SRCREV = "2014_03_07"
> PR = "sd_15.2"
> LINUX_VERSION = "${PV}"
> LINUX_VERSION_EXTENSION = "-${PR}+${SRCREV}"
> COMPATIBLE_MACHINE = "skidata-harmony|smartcpu"
> KERNEL_IMAGETYPE = "uImage"
> SRC_URI += "file://defconfig"
> require recipes-kernel/linux/linux-yocto.inc
> 
> 
> This recipe was working well with the Dylan branch and following changes:
> -SRC_URI = 
> "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel;nocheckout=1"
> +SRC_URI = "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel"
> +S = "${WORKDIR}/git"
> 
> 
> When compiled with the dora branch the kernel hangs at "Starting kernel..." 
> and doesn't start:
> ## Booting kernel from Legacy Image at  ...
>Image Name:   Linux-3.1.10-sd_15.2
>Image Type:   ARM Linux Kernel Image (uncompressed)
>Data Size:3181616 Bytes = 3 MiB
>Load Address: 8000
>Entry Point:  8000
>Verifying Checksum ... OK
>Loading Kernel Image ... OK
> OK
> 
> Starting kernel ...
> 
> 
> I've already looked through the migration notes in the manual but I'm unable 
> to find any hints...
> Are there any ideas why the kernel doesn't start with the Dora branch?

We saw an issue recently on beaglebone that looked very like this. It
turned out the load address for the kernel was conflicting in memory
with the device tree binary.

It easily be something different but I thought I'd mention it.

Cheers,

Richard

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

Re: [yocto] Newbie question: How to get dependencies into compile of custom recipe?

2014-04-22 Thread Richard Purdie

On Tue, 2014-04-22 at 09:57 +0200, Neuer User wrote:
> Hi
> 
> Sorry for this simple question. I've just started building my first
> image with yocto and would now like to add a (very simple) own recipe.
> 
> I followed the Yocto Development guide, added my own layer and included
> the "helloworld" example.
> 
> Now I would like to exchange the helloworld.c code with a simple
> gstreamer-rtsp server code
> (http://cgit.freedesktop.org/gstreamer/gst-rtsp-server/tree/examples/test-launch.c).
> 
> I changed the bb file as follows, adding expecially the DEPENDS:
> 
> #
> # This file was derived from the 'Hello World!' example recipe in the
> # Yocto Project Development Manual.
> #
> 
> DESCRIPTION = "Simple helloworld application"
> SECTION = "multimedia"
> LICENSE = "MIT"
> LIC_FILES_CHKSUM =
> "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
> PR = "r0"
> 
> SRC_URI = "file://cameraserver.c"
> 
> DEPENDS = "gst-rtsp gstreamer"
> 
> S = "${WORKDIR}"
> 
> do_compile() {
>  ${CC} cameraserver.c -o cameraserver
> }
> 
> do_install() {
>  install -d ${D}${bindir}
>  install -m 0755 cameraserver ${D}${bindir}
> }
> 
> 
> The package "gst-rtsp" is correctly built (as
> libgstrtspserver-0.10-0-0.10.8-r0@cortexa9hf_vfp_neon), but the
> compilation process of the "cameraserver.c" does not find the necessary
> header include files.
> 
> NOTE: recipe camera-server-0.1-r0: task do_compile: Started
> Log data follows:
> | DEBUG: Executing shell function do_compile
> | cameraserver.c:20:21: fatal error: gst/gst.h: No such file or directory
> |  #include 
> |  ^
> | compilation terminated.
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_compile (log file is located at
> /home/ubuntu/yocto/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/camera-server/0.1-r0/temp/log.do_compile.26393)
> NOTE: recipe camera-server-0.1-r0: task do_compile: Failed
> 
> 
> The debug of bitbake shows, however, that it correctly identifies the
> dependent packages:
> 
> DEBUG: providers for gst-rtsp are: ['gst-rtsp']
> DEBUG: sorted runtime providers for gst-rtsp are:
> ['/home/ubuntu/yocto/sources/meta-openembedded/meta-multimedia/recipes-multimedia/gstreamer/gst-rtsp_0.10.8.bb']
> DEBUG: adding
> '/home/ubuntu/yocto/sources/meta-openembedded/meta-multimedia/recipes-multimedia/gstreamer/gst-rtsp_0.10.8.bb'
> to satisfy runtime 'gst-rtsp'
> DEBUG: providers for gstreamer are: ['gstreamer']
> DEBUG: sorted runtime providers for gstreamer are:
> ['/home/ubuntu/yocto/sources/poky/meta/recipes-multimedia/gstreamer/gstreamer_0.10.36.bb']
> DEBUG: adding
> '/home/ubuntu/yocto/sources/poky/meta/recipes-multimedia/gstreamer/gstreamer_0.10.36.bb'
> to satisfy runtime 'gstreamer'
> 
> 
> So, what am I doing wrong? Do I explicitly need to add the dependencies
> to the compile environment somehow? If yes, where are the found
> directories stored?
> 
> Or am I doing this all very wrong? I am really very new to Yocto.

Basically, you need to pass in the correct compiler and linker flags.

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/faq/html/chapter-developing.html

Adding:

`pkg-config --cflags --libs gstreamer`

to your compiler line will probably help. The system will automatically
figure out things from there, the environment contains things that
pkg-config can use to generate the correct options.

Cheers,

Richard




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

Re: [yocto] defconfig on daisy

2014-04-22 Thread Richard Purdie

On Tue, 2014-04-22 at 08:13 +0200, Søren Holm wrote:
> Hi Bruce
> 
> I've search the meta-data repos and kernel repo for a change matching this. 
> Is 
> it fixes or did you miss it?

The change is:

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=zedd/kernel&id=a112c85c02f161dc03bf71cdb9d2b3557999bbfd

It didn't make it into the 1.6 release branch, it will go in for 1.6.1
and is queued for there and master.

Cheers,

Richard

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

Re: [yocto] Problem with own kernel recipe on Dora

2014-04-22 Thread Richard Leitner - SKIDATA

Hi Richard,
thanks for your quick response.

> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Tuesday, April 22, 2014 10:23 AM
> To: Richard Leitner - SKIDATA
> Cc: Yocto Project Discussion ML (yocto@yoctoproject.org)
> Subject: Re: [yocto] Problem with own kernel recipe on Dora
> 
> On Tue, 2014-04-22 at 07:52 +, Richard Leitner - SKIDATA wrote:
> > Hi Yocto-Community,
> > as the subject already says I've a problem with my kernel recipe after the
> "migration" from the Dylan to the Dora (10.0.1) branch.
> > I've tried the 10.0.1 release tag as well as the current dora master
> (50e9ccb2aff7b9f9dca4fda99a6832c60f64de3b).
> >
> > The kernel recipe I'm using is derived from the skeleton:
> > DESCRIPTION = "Linux Kernel"
> > SECTION = "kernel"
> > LICENSE = "GPLv2"
> > LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
> > inherit kernel
> > KSRC = "/home/leri/VCS/git/linux"
> > KBRANCH = "master"
> > SRC_URI =
> "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel;nocheckout=1"
> > SRCREV = "2014_03_07"
> > PR = "sd_15.2"
> > LINUX_VERSION = "${PV}"
> > LINUX_VERSION_EXTENSION = "-${PR}+${SRCREV}"
> > COMPATIBLE_MACHINE = "skidata-harmony|smartcpu"
> > KERNEL_IMAGETYPE = "uImage"
> > SRC_URI += "file://defconfig"
> > require recipes-kernel/linux/linux-yocto.inc
> >
> >
> > This recipe was working well with the Dylan branch and following changes:
> > -SRC_URI =
> "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel;nocheckout=1"
> > +SRC_URI = "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel"
> > +S = "${WORKDIR}/git"
> >
> >
> > When compiled with the dora branch the kernel hangs at "Starting kernel..." 
> > and
> doesn't start:
> > ## Booting kernel from Legacy Image at  ...
> >Image Name:   Linux-3.1.10-sd_15.2
> >Image Type:   ARM Linux Kernel Image (uncompressed)
> >Data Size:3181616 Bytes = 3 MiB
> >Load Address: 8000
> >Entry Point:  8000
> >Verifying Checksum ... OK
> >Loading Kernel Image ... OK
> > OK
> >
> > Starting kernel ...
> >
> >
> > I've already looked through the migration notes in the manual but I'm 
> > unable to find
> any hints...
> > Are there any ideas why the kernel doesn't start with the Dora branch?
> 
> We saw an issue recently on beaglebone that looked very like this. It turned 
> out the
> load address for the kernel was conflicting in memory with the device tree 
> binary.

Do you mean that the bootloader was loading the device tree binary into the 
load address of the kernel?

> 
> It easily be something different but I thought I'd mention it.

Do you have any idea how to further debug the problem?

regards,
Richard

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

Re: [yocto] Problem with own kernel recipe on Dora

2014-04-22 Thread Richard Purdie

On Tue, 2014-04-22 at 09:08 +, Richard Leitner - SKIDATA wrote:
> > -Original Message-
> > From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> > Sent: Tuesday, April 22, 2014 10:23 AM
> > To: Richard Leitner - SKIDATA
> > Cc: Yocto Project Discussion ML (yocto@yoctoproject.org)
> > Subject: Re: [yocto] Problem with own kernel recipe on Dora
> > 
> > On Tue, 2014-04-22 at 07:52 +, Richard Leitner - SKIDATA wrote:
> > > Hi Yocto-Community,
> > > as the subject already says I've a problem with my kernel recipe after the
> > "migration" from the Dylan to the Dora (10.0.1) branch.
> > > I've tried the 10.0.1 release tag as well as the current dora master
> > (50e9ccb2aff7b9f9dca4fda99a6832c60f64de3b).
> > >
> > > The kernel recipe I'm using is derived from the skeleton:
> > > DESCRIPTION = "Linux Kernel"
> > > SECTION = "kernel"
> > > LICENSE = "GPLv2"
> > > LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
> > > inherit kernel
> > > KSRC = "/home/leri/VCS/git/linux"
> > > KBRANCH = "master"
> > > SRC_URI =
> > "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel;nocheckout=1"
> > > SRCREV = "2014_03_07"
> > > PR = "sd_15.2"
> > > LINUX_VERSION = "${PV}"
> > > LINUX_VERSION_EXTENSION = "-${PR}+${SRCREV}"
> > > COMPATIBLE_MACHINE = "skidata-harmony|smartcpu"
> > > KERNEL_IMAGETYPE = "uImage"
> > > SRC_URI += "file://defconfig"
> > > require recipes-kernel/linux/linux-yocto.inc
> > >
> > >
> > > This recipe was working well with the Dylan branch and following changes:
> > > -SRC_URI =
> > "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel;nocheckout=1"
> > > +SRC_URI = "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel"
> > > +S = "${WORKDIR}/git"
> > >
> > >
> > > When compiled with the dora branch the kernel hangs at "Starting 
> > > kernel..." and
> > doesn't start:
> > > ## Booting kernel from Legacy Image at  ...
> > >Image Name:   Linux-3.1.10-sd_15.2
> > >Image Type:   ARM Linux Kernel Image (uncompressed)
> > >Data Size:3181616 Bytes = 3 MiB
> > >Load Address: 8000
> > >Entry Point:  8000
> > >Verifying Checksum ... OK
> > >Loading Kernel Image ... OK
> > > OK
> > >
> > > Starting kernel ...
> > >
> > >
> > > I've already looked through the migration notes in the manual but I'm 
> > > unable to find
> > any hints...
> > > Are there any ideas why the kernel doesn't start with the Dora branch?
> > 
> > We saw an issue recently on beaglebone that looked very like this. It 
> > turned out the
> > load address for the kernel was conflicting in memory with the device tree 
> > binary.
> 
> Do you mean that the bootloader was loading the device tree binary into the 
> load address of the kernel?

The kernel was large enough it was overwriting the device tree data.

Cheers,

Richard


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

Re: [yocto] No USB devices on BeagleBoard xM!

2014-04-22 Thread Jukka Rissanen

Hi Jeremy,

On su, 2014-04-20 at 08:44 +1200, Jeremy Cole-Baker wrote:
> Hi, I still can't figure out how to get the USB hardware working on my 
> BeagelBoard xM.
> 

I think you are seeing this bug
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5211

I did not manage to get usb working with the instructions in the bug
thou.


Cheers,
Jukka


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

Re: [yocto] Problem with own kernel recipe on Dora

2014-04-22 Thread Nicolas Dechesne

On Tue, Apr 22, 2014 at 9:52 AM, Richard Leitner - SKIDATA
 wrote:
> Hi Yocto-Community,
> as the subject already says I've a problem with my kernel recipe after the 
> "migration" from the Dylan to the Dora (10.0.1) branch.
> I've tried the 10.0.1 release tag as well as the current dora master 
> (50e9ccb2aff7b9f9dca4fda99a6832c60f64de3b).
>
> The kernel recipe I'm using is derived from the skeleton:
> DESCRIPTION = "Linux Kernel"
> SECTION = "kernel"
> LICENSE = "GPLv2"
> LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
> inherit kernel
> KSRC = "/home/leri/VCS/git/linux"
> KBRANCH = "master"
> SRC_URI = 
> "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel;nocheckout=1"
> SRCREV = "2014_03_07"
> PR = "sd_15.2"
> LINUX_VERSION = "${PV}"
> LINUX_VERSION_EXTENSION = "-${PR}+${SRCREV}"
> COMPATIBLE_MACHINE = "skidata-harmony|smartcpu"
> KERNEL_IMAGETYPE = "uImage"
> SRC_URI += "file://defconfig"
> require recipes-kernel/linux/linux-yocto.inc
>
>
> This recipe was working well with the Dylan branch and following changes:
> -SRC_URI = 
> "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel;nocheckout=1"
> +SRC_URI = "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel"
> +S = "${WORKDIR}/git"
>
>
> When compiled with the dora branch the kernel hangs at "Starting kernel..." 
> and doesn't start:
> ## Booting kernel from Legacy Image at  ...
>Image Name:   Linux-3.1.10-sd_15.2
>Image Type:   ARM Linux Kernel Image (uncompressed)
>Data Size:3181616 Bytes = 3 MiB
>Load Address: 8000
>Entry Point:  8000
>Verifying Checksum ... OK
>Loading Kernel Image ... OK
> OK
>
> Starting kernel ...
>
>
> I've already looked through the migration notes in the manual but I'm unable 
> to find any hints...
> Are there any ideas why the kernel doesn't start with the Dora branch?

you don't mention anything about gcc, so assuming you are using the
'default' gcc for each release, dylan has 4.7, and dora has 4.8. On a
couple of ARM platforms, i have seen similar issue when using gcc-4.8
with old kernel (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=455bd4c430b0c0a361f38e8658a0d6cb469942b5
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=418df63adac56841ef6b0f1fcf435bc64d4ed177

They should cleanly apply to v3.1 which you seem to be using.

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

Re: [yocto] Problem with own kernel recipe on Dora

2014-04-22 Thread Richard Leitner - SKIDATA

> -Original Message-
> From: Nicolas Dechesne [mailto:nicolas.deche...@linaro.org]
> Sent: Tuesday, April 22, 2014 1:35 PM
> To: Richard Leitner - SKIDATA
> Cc: Yocto Project Discussion ML (yocto@yoctoproject.org)
> Subject: Re: [yocto] Problem with own kernel recipe on Dora
> 
> On Tue, Apr 22, 2014 at 9:52 AM, Richard Leitner - SKIDATA
>  wrote:
> > Hi Yocto-Community,
> > as the subject already says I've a problem with my kernel recipe after the
> "migration" from the Dylan to the Dora (10.0.1) branch.
> > I've tried the 10.0.1 release tag as well as the current dora master
> (50e9ccb2aff7b9f9dca4fda99a6832c60f64de3b).
> >
> > The kernel recipe I'm using is derived from the skeleton:
> > DESCRIPTION = "Linux Kernel"
> > SECTION = "kernel"
> > LICENSE = "GPLv2"
> > LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
> > inherit kernel
> > KSRC = "/home/leri/VCS/git/linux"
> > KBRANCH = "master"
> > SRC_URI =
> "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel;nocheckout=1"
> > SRCREV = "2014_03_07"
> > PR = "sd_15.2"
> > LINUX_VERSION = "${PV}"
> > LINUX_VERSION_EXTENSION = "-${PR}+${SRCREV}"
> > COMPATIBLE_MACHINE = "skidata-harmony|smartcpu"
> > KERNEL_IMAGETYPE = "uImage"
> > SRC_URI += "file://defconfig"
> > require recipes-kernel/linux/linux-yocto.inc
> >
> >
> > This recipe was working well with the Dylan branch and following changes:
> > -SRC_URI =
> "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel;nocheckout=1"
> > +SRC_URI = "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel"
> > +S = "${WORKDIR}/git"
> >
> >
> > When compiled with the dora branch the kernel hangs at "Starting kernel..." 
> > and
> doesn't start:
> > ## Booting kernel from Legacy Image at  ...
> >Image Name:   Linux-3.1.10-sd_15.2
> >Image Type:   ARM Linux Kernel Image (uncompressed)
> >Data Size:3181616 Bytes = 3 MiB
> >Load Address: 8000
> >Entry Point:  8000
> >Verifying Checksum ... OK
> >Loading Kernel Image ... OK
> > OK
> >
> > Starting kernel ...
> >
> >
> > I've already looked through the migration notes in the manual but I'm 
> > unable to find
> any hints...
> > Are there any ideas why the kernel doesn't start with the Dora branch?
> 
> you don't mention anything about gcc, so assuming you are using the 'default' 
> gcc for
> each release, dylan has 4.7, and dora has 4.8. On a couple of ARM platforms, 
> i have
> seen similar issue when using gcc-4.8 with old kernel ( 
> the following linux kernel patches were used to fix the boot problem:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=455bd4c430b0c
> 0a361f38e8658a0d6cb469942b5
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=418df63adac56
> 841ef6b0f1fcf435bc64d4ed177
> 
> They should cleanly apply to v3.1 which you seem to be using.
> 

Thank you very much Nico!
These two patches fixed the problem and the kernel is booting again :-)

Just for completeness: Yes, I'm using the "default" gcc version and the two 
patches applied cleanly to my 3.1 branch.

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

Re: [yocto] Newbie question: How to get dependencies into compile of custom recipe?

2014-04-22 Thread Neuer User

Am 22.04.2014 10:42, schrieb Richard Purdie:
> 
> Basically, you need to pass in the correct compiler and linker flags.
> 
> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/faq/html/chapter-developing.html
> 
> Adding:
> 
> `pkg-config --cflags --libs gstreamer`
> 
> to your compiler line will probably help. The system will automatically
> figure out things from there, the environment contains things that
> pkg-config can use to generate the correct options.
> 
> Cheers,
> 
> Richard
> 

Thanks, that helped, but I'm still not through, I'm afraid.

My recipe look like this now:


DESCRIPTION = "Simple helloworld application"
SECTION = "multimedia"
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
PR = "r0"

SRC_URI = "file://cameraserver.c"

DEPENDS = "gst-rtsp gstreamer"

S = "${WORKDIR}"

do_compile() {
 ${CC} `pkg-config --cflags --libs gstreamer-0.10`
cameraserver.c -o cameraserver
}

do_install() {
 install -d ${D}${bindir}
 install -m 0755 cameraserver ${D}${bindir}
}

It only worked with "gstreamer-0.10". Now the compilation works, but
linking stops:

Log data follows:
| DEBUG: Executing shell function do_compile
| /tmp/cckmN8NC.o: In function `main':
| cameraserver.c:(.text+0x70): undefined reference to `gst_rtsp_server_new'
| cameraserver.c:(.text+0x7c): undefined reference to
`gst_rtsp_server_get_media_mapping'
| cameraserver.c:(.text+0x84): undefined reference to
`gst_rtsp_media_factory_new'
| cameraserver.c:(.text+0xa0): undefined reference to
`gst_rtsp_media_factory_set_launch'
| cameraserver.c:(.text+0xb4): undefined reference to
`gst_rtsp_media_mapping_add_factory'
| cameraserver.c:(.text+0xc8): undefined reference to
`gst_rtsp_server_attach'
| collect2: error: ld returned 1 exit status

As it seems only linking to gst-rtsp, not to gstreamer, if I see that
correctly.

I then tried to add "gst-rtsp" or "gst-rtsp-server" or "gst-rtsp-0.10"
or "gst-rtsp-server-0.10" to the pkg-config part, but none of them were
found.

I tell you, I feel extremely stupid. The solution is probably so simple,
yet I do not find a solution (even with using Google).


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

Re: [yocto] Newbie question: How to get dependencies into compile of custom recipe?

2014-04-22 Thread Robert Calhoun

On 4/22/14 3:57 AM, "Neuer User"  wrote:
>Sorry for this simple question. I've just started building my first
>image with yocto and would now like to add a (very simple) own recipe.

(I am not familiar with gstreamer, but it looks like a big project and
maybe not so simple!)

The yocto build system figures out dependencies and build order, sets the
environment, and generates shell scripts to do the actual tasks. The
actual "work" is done by these shell scripts, not by the python code.

Your recipe explicitly defines some steps like do_compile(). When you do
this, you are saying "Let me control the compilation, I know what I am
doing!". Your do_compile() step is going to generate a run.do_compile
script, and that has to work just as if you were running the script
yourself.

If something doesn't work, try "bitbake {pkg} -c devshell".  That will
drop you into the environment the compiler is going to see. The shell
scripts are in ../temp. Each script is a single step (do_compile etc). All
of the substitutions that Richard described will already have been made;
and you will see all the environment variables being set and the calls
made to the compiler, linker etc. This directory also contains the log
files from recent executions.

You can run these manually, e.g. ../temp/run.do_compile. (The files
without PIDs are symlinks to the latest script.) You can edit this script
and re-run the compile and link step until it works. Once you've figured
out what needs to be set or run, modify the recipe to generate that
environment or command.

An important thing to understand is that each step lives in its own little
world; an environment variable set in the do_compile is not present in
do_install unless you put it there. Avoidance of global state allows the
build system to run multiple tasks in parallel.

-Rob Calhoun
(still figuring this stuff out myself)

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

Re: [yocto] Newbie question: How to get dependencies into compile of custom recipe?

2014-04-22 Thread Gary Thomas


On 2014-04-22 06:56, Neuer User wrote:

Am 22.04.2014 10:42, schrieb Richard Purdie:


Basically, you need to pass in the correct compiler and linker flags.

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/faq/html/chapter-developing.html

Adding:

`pkg-config --cflags --libs gstreamer`

to your compiler line will probably help. The system will automatically
figure out things from there, the environment contains things that
pkg-config can use to generate the correct options.

Cheers,

Richard



Thanks, that helped, but I'm still not through, I'm afraid.

My recipe look like this now:


DESCRIPTION = "Simple helloworld application"
SECTION = "multimedia"
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
PR = "r0"

SRC_URI = "file://cameraserver.c"

DEPENDS = "gst-rtsp gstreamer"


Try adding gst-plugins-good to DEPENDS - that's where the rtsp stuff lives.



S = "${WORKDIR}"

do_compile() {
  ${CC} `pkg-config --cflags --libs gstreamer-0.10`
cameraserver.c -o cameraserver
}

do_install() {
  install -d ${D}${bindir}
  install -m 0755 cameraserver ${D}${bindir}
}

It only worked with "gstreamer-0.10". Now the compilation works, but
linking stops:

Log data follows:
| DEBUG: Executing shell function do_compile
| /tmp/cckmN8NC.o: In function `main':
| cameraserver.c:(.text+0x70): undefined reference to `gst_rtsp_server_new'
| cameraserver.c:(.text+0x7c): undefined reference to
`gst_rtsp_server_get_media_mapping'
| cameraserver.c:(.text+0x84): undefined reference to
`gst_rtsp_media_factory_new'
| cameraserver.c:(.text+0xa0): undefined reference to
`gst_rtsp_media_factory_set_launch'
| cameraserver.c:(.text+0xb4): undefined reference to
`gst_rtsp_media_mapping_add_factory'
| cameraserver.c:(.text+0xc8): undefined reference to
`gst_rtsp_server_attach'
| collect2: error: ld returned 1 exit status

As it seems only linking to gst-rtsp, not to gstreamer, if I see that
correctly.

I then tried to add "gst-rtsp" or "gst-rtsp-server" or "gst-rtsp-0.10"
or "gst-rtsp-server-0.10" to the pkg-config part, but none of them were
found.

I tell you, I feel extremely stupid. The solution is probably so simple,
yet I do not find a solution (even with using Google).




--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] Newbie question: How to get dependencies into compile of custom recipe?

2014-04-22 Thread Neuer User

H Rob

Thanks for the information.

To clarify: My recipe is a very simple one. It is just one c file with
maybe 40 lines or so.

But it uses library functions from another recipe "gst-rtsp", which
again uses "gstreamer".

Both, "gstreamer" and "gst-rtsp" are compiled and working nicely, as far
as I can tell.

Now I have a simple c program file that needs to be compiled and linked
against "gst-rtsp". Hmmm.

I don't have a makefile. I don't use any autotools for this file. The bb
recipe is based on the example in the Yocto Development guide for a
simple c file.

I have to admit: I am extremely new to Yocto. I am also not a c
programmer. If I program, I typically use python or Qt5. :-)

I guess, I try the "devshell" and see what variables are set and what
pkg-config output is like.

In the end, it is probably very simple to do, but for a Newbie like
me... :-)

Am 22.04.2014 16:32, schrieb Robert Calhoun:
> 
> 
> On 4/22/14 3:57 AM, "Neuer User"
>  wrote:
>> Sorry for this simple question. I've just started building my
>> first image with yocto and would now like to add a (very simple)
>> own recipe.
> 
> (I am not familiar with gstreamer, but it looks like a big project
> and maybe not so simple!)
> 
> The yocto build system figures out dependencies and build order, sets
> the environment, and generates shell scripts to do the actual tasks.
> The actual "work" is done by these shell scripts, not by the python
> code.
> 
> Your recipe explicitly defines some steps like do_compile(). When you
> do this, you are saying "Let me control the compilation, I know what
> I am doing!". Your do_compile() step is going to generate a
> run.do_compile script, and that has to work just as if you were
> running the script yourself.
> 
> 
> If something doesn't work, try "bitbake {pkg} -c devshell".  That
> will drop you into the environment the compiler is going to see. The
> shell scripts are in ../temp. Each script is a single step
> (do_compile etc). All of the substitutions that Richard described
> will already have been made; and you will see all the environment
> variables being set and the calls made to the compiler, linker etc.
> This directory also contains the log files from recent executions.
> 
> You can run these manually, e.g. ../temp/run.do_compile. (The files 
> without PIDs are symlinks to the latest script.) You can edit this
> script and re-run the compile and link step until it works. Once
> you've figured out what needs to be set or run, modify the recipe to
> generate that environment or command.
> 
> An important thing to understand is that each step lives in its own
> little world; an environment variable set in the do_compile is not
> present in do_install unless you put it there. Avoidance of global
> state allows the build system to run multiple tasks in parallel.
> 
> -Rob Calhoun (still figuring this stuff out myself)
> 


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

[linux-yocto] v2g_bridge driver required

2014-04-22 Thread Bremalatha Ramalingam - ERS, HCL Tech

How to implement the kernel driver which will invoke the v4l2 driver module to 
capture the image from the USB camera can anyone help in this regard..

In some of the intel application they have used the v2g_bridge kernel module to 
invoke the v4l2 and DRM.

I need this implementation details


Thanks.


::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.


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

[yocto] [solved] Re: Newbie question: How to get dependencies into compile of custom recipe?

2014-04-22 Thread Neuer User

Got it working!

The hint with the "devshell" helped very much. I could try out
"pkg-config --list-all|grep rtsp" and found the name pkg-config was
expecting.

So, the line must be:

pkg-config --cflags --libs gstreamer-0.10 gst-rtsp-server-0.10

(Thought I had tried this, but maybe had a typo in the name.)

Now it compiled and build the package. Great!!

Hope, the package does work :-)

Thanks again. I learned a lot!

Michael

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

[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, April 22, 2014 8:00 AM US Pacific Time

2014-04-22 Thread Jolley, Stephen K

Attendees: Stephen, Armin, Jessica, Scott, Matthew, Tom, Belen, Ross, Paul, 
Jefro, Mark, Michael B., Alex, Richard, Michael H., Saul, Nitin,



* Opens collection - 5 min (Stephen)

Armin - When is the best time to request package updates? Saul controls this 
and usually drives it.  We have a package tracking system and we try to upgrade 
a number of them early in the release cycle.

Scott - Docs are closed for change as of the end of today for 1.6.

Rob - Version numbers and names?  Release names are at: 
https://wiki.yoctoproject.org/wiki/Releases

* Yocto 1.6 status - 5 min (Stephen/team)

  https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.6_Status

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

YP 1.6 Status -We had a boot problem with BeagleBone board on rc4.  The fix for 
just this should finish QA today.  We should be able to ship by the end of the 
week.

YP 1.5.2 Status - We did a build over the weekend and saw issues with it.  6 to 
7 failures were found, we haven't root caused the issues but we will do another 
build as soon as patches are in to cover it.

YP 1.7 Planning - We are planning the schedule for 1.7 at this time.  If you 
have 1.7 features you want included, please submit enhancement requests now!

YP 1.6.1 Planning - We are planning to schedule a slot in the 1.7 schedule for 
1.6.1, but no critical patches yet drive us to this release.

* SWAT team rotation: Laurentiu -> Nitin

  https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

* Opens - 10 min

* Team Sharing - 10 min
Michael - The Error report web is up and running.

No meeting next week since most are at ELC or traveling.

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:  (503) 712-0534
*Cell:(208) 244-4460
* Email: stephen.k.jol...@intel.com

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

Re: [yocto] eglibc-2.18 is not compiling

2014-04-22 Thread Khem Raj

On Tue, Apr 22, 2014 at 7:08 AM, Kai Ulrich  wrote:
> tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/eglibc/2.18-r0/build-arm-poky-linux-gnueabi/shlib.lds:150:
> syntax error
> collect2: error: ld returned 1 exit status
> make[2]: ***
> [/home/kulrich/Development/yocto_dora/poky/build_beagle_xm_ml/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/eglibc/2.18-r0/build-arm-poky-linux-gnueabi/libc.so]
> Error 1
> make[2]: Leaving directory
> `/home/kulrich/Development/yocto_dora/poky/build_beagle_xm_ml/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/eglibc/2.18-r0/eglibc-2.18/libc/elf'
> make[1]: *** [elf/subdir_lib] Error 2
> make[1]: Leaving directory
> `/home/kulrich/Development/yocto_dora/poky/build_beagle_xm_ml/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/eglibc/2.18-r0/eglibc-2.18/libc'
> make: *** [all] Error 2


whats the make version on your build host which is being used here. I
hope its 3.82 or newer.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] defconfig on daisy

2014-04-22 Thread Søren Holm

Thanks Richard.

Tirsdag den 22. april 2014 09:46:04 skrev Richard Purdie:
> On Tue, 2014-04-22 at 08:13 +0200, Søren Holm wrote:
> > Hi Bruce
> > 
> > I've search the meta-data repos and kernel repo for a change matching
> > this. Is it fixes or did you miss it?
> 
> The change is:
> 
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=zedd/kernel&id=a
> 112c85c02f161dc03bf71cdb9d2b3557999bbfd
> 
> It didn't make it into the 1.6 release branch, it will go in for 1.6.1
> and is queued for there and master.
> 
> Cheers,
> 
> Richard

-- 
Søren Holm
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Question about rebuilding RPM package index for updated RPMs when bitbake completes

2014-04-22 Thread Mark Hatle


On 4/22/14, 1:50 AM, Alex J Lennon wrote:


On 22/04/2014 02:36, Mark Hatle wrote:

On 4/20/14, 7:15 AM, Alex J Lennon wrote:

Hi,

I'm trying to put in place a development workflow using the PR server,
RPM package feeds and smart update/install on a target.

I see that when I modify and rebuild my recipe, foo, the PR server
increments its count within the RPM filename, but the RPM feed data
doesn't seem to update.



...


So if I am understanding the above correctly, when I make a change to a
recipe and build it, PR automatically
updates, the old RPM is removed and the new RPM added to the feed
directory. However the package index
for the feed is not updated.

So if at that point I try to make use of the feed on a target I am
likely to find something is broken.


The feed is normally indexed (createrepo) either when you manually run the
package-index operation, or when you construct a filesystem.  Until you do
that, the feed directories are transient.



Is there a reason for this? Surely having a package index that is out of sync
with the packages until a manual operation is performed isn't ideal?


Yes, if you re-indexed the set of packages after each package, you will add 
multiple minutes to the construction of each package, and introduce locking into 
the system.  (You won't be able to generate multiple recipes in parallel due to 
this.)  (I don't consider it a package feed until all of the packages are built 
and the index is constructed.)



If that is true would it make sense to leave the old RPM in the feed
directory until package-index
is re-ran, or to run package-index automatically at the end of a build
when RPMs have changed?


I -never- export the feed directories from the project directory. Instead, I
copy the packages from the feed directory to where I share them, and then run
the indexer against the external repository.  This preserves the older
versions and also makes the new ones available.

To run the indexer I have to configure and run it manually...

PATH=/home/mhatle/build-6.0-RCPL-test/build/tmp/sysroots/x86_64-linux/bin:/home/mhatle/build-6.0-RCPL-test/bitbake/tmp/sysroots/x86_64-linux/usr/bin:$PATH

/home/mhatle/build-6.0-RCPL-test/bitbake/tmp/sysroots/x86_64-linux/usr/bin/createrepo
--update -q 

So for qemux86_64, I end up running the above three times.  all, x86_64 and
qemux86_64.

Then on the target I just do:

smart update
smart upgrade -y



Thanks, that's useful

However I still believe the core question stands, which is why the package index
is out of sync, and why it's a good thing to have to run bitbake package-index


The other option is to remove the repo indexes when packages are written. 
Again, I don't consider these out of sync though, as the files have different 
purposes and constraints.  They are simply constructed to enable the rootfs 
generation.  Upgrades are external of the build system.



manually to bring the package index back into sync with the packages?

I too export the feed directories to a server for 3rd party consumption via
compressed rsync over SSH. I don't want to expose more on the server than a
simple SSH endpoint, and rsync seems a sensible way to minimise copying times,
so either I need the package index to be correct prior to the rsync, I need to
export, say, an NFS filesystem which I don't want to do, or I need some
createrepo specifics on what I would prefer to be a dumb web-server.


For an rsync, I would either index on the server using a cron-job.. so when new 
packages appear they get added to the index, or have a local mirror of the 
directory including the updated index... you just want to make sure the index 
files are synced last somehow.


--Mark


Best,

Alex


--Mark


Thanks,

Alex







--

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] eglibc-2.18 is not compiling

2014-04-22 Thread Kai Ulrich

thanx for your interest
yes, it seams all right
gcc-Version 4.7.3 (Gentoo 4.7.3-r1 p1.4, pie-0.5.5)
make-Version GNU Make 3.82 Built for x86_64-pc-linux-gnu



2014-04-22 18:10 GMT+02:00 Khem Raj :

> On Tue, Apr 22, 2014 at 7:08 AM, Kai Ulrich  wrote:
> >
> tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/eglibc/2.18-r0/build-arm-poky-linux-gnueabi/shlib.lds:150:
> > syntax error
> > collect2: error: ld returned 1 exit status
> > make[2]: ***
> >
> [/home/kulrich/Development/yocto_dora/poky/build_beagle_xm_ml/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/eglibc/2.18-r0/build-arm-poky-linux-gnueabi/libc.so]
> > Error 1
> > make[2]: Leaving directory
> >
> `/home/kulrich/Development/yocto_dora/poky/build_beagle_xm_ml/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/eglibc/2.18-r0/eglibc-2.18/libc/elf'
> > make[1]: *** [elf/subdir_lib] Error 2
> > make[1]: Leaving directory
> >
> `/home/kulrich/Development/yocto_dora/poky/build_beagle_xm_ml/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/eglibc/2.18-r0/eglibc-2.18/libc'
> > make: *** [all] Error 2
>
>
> whats the make version on your build host which is being used here. I
> hope its 3.82 or newer.
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] eglibc-2.18 is not compiling

2014-04-22 Thread Khem Raj

On Apr 22, 2014 12:47 PM, "Kai Ulrich"  wrote:
>
> thanx for your interest
> yes, it seams all right
> gcc-Version 4.7.3 (Gentoo 4.7.3-r1 p1.4, pie-0.5.5)
> make-Version GNU Make 3.82 Built for x86_64-pc-linux-gnu
>
>
>
> 2014-04-22 18:10 GMT+02:00 Khem Raj :
>
>> On Tue, Apr 22, 2014 at 7:08 AM, Kai Ulrich  wrote:
>> >
tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/eglibc/2.18-r0/build-arm-poky-linux-gnueabi/shlib.lds:150:
>> > syntax error
>> > collect2: error: ld returned 1 exit status
>> > make[2]: ***
>> >
[/home/kulrich/Development/yocto_dora/poky/build_beagle_xm_ml/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/eglibc/2.18-r0/build-arm-poky-linux-gnueabi/libc.so]
>> > Error 1
>> > make[2]: Leaving directory
>> >
`/home/kulrich/Development/yocto_dora/poky/build_beagle_xm_ml/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/eglibc/2.18-r0/eglibc-2.18/libc/elf'
>> > make[1]: *** [elf/subdir_lib] Error 2
>> > make[1]: Leaving directory
>> >
`/home/kulrich/Development/yocto_dora/poky/build_beagle_xm_ml/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/eglibc/2.18-r0/eglibc-2.18/libc'
>> > make: *** [all] Error 2
>>
>>
>> whats the make version on your build host which is being used here. I
>> hope its 3.82 or newer.
>
>

and you are using gawk and not mawk or something else
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Question about rebuilding RPM package index for updated RPMs when bitbake completes

2014-04-22 Thread Alex J Lennon


On 22/04/2014 19:14, Mark Hatle wrote:
> On 4/22/14, 1:50 AM, Alex J Lennon wrote:
>>
>> On 22/04/2014 02:36, Mark Hatle wrote:
>>> On 4/20/14, 7:15 AM, Alex J Lennon wrote:
 Hi,

 I'm trying to put in place a development workflow using the PR server,
 RPM package feeds and smart update/install on a target.

 I see that when I modify and rebuild my recipe, foo, the PR server
 increments its count within the RPM filename, but the RPM feed data
 doesn't seem to update.

>>>
>>> ...
>>>
 So if I am understanding the above correctly, when I make a change
 to a
 recipe and build it, PR automatically
 updates, the old RPM is removed and the new RPM added to the feed
 directory. However the package index
 for the feed is not updated.

 So if at that point I try to make use of the feed on a target I am
 likely to find something is broken.
>>>
>>> The feed is normally indexed (createrepo) either when you manually
>>> run the
>>> package-index operation, or when you construct a filesystem.  Until
>>> you do
>>> that, the feed directories are transient.
>>>
>>
>> Is there a reason for this? Surely having a package index that is out
>> of sync
>> with the packages until a manual operation is performed isn't ideal?
>
> Yes, if you re-indexed the set of packages after each package, you
> will add multiple minutes to the construction of each package, and
> introduce locking into the system.  (You won't be able to generate
> multiple recipes in parallel due to this.)  (I don't consider it a
> package feed until all of the packages are built and the index is
> constructed.)
>

I wasn't suggesting that the index is built mid-run . Not knowing the
internals of the bitbake dependency chain, presumably the package index
would/could be rebuilt at the end of the build process and so would not
block parallelisation (which I agree would be a time-sink)

 If that is true would it make sense to leave the old RPM in the feed
 directory until package-index
 is re-ran, or to run package-index automatically at the end of a build
 when RPMs have changed?
>>>
>>> I -never- export the feed directories from the project directory.
>>> Instead, I
>>> copy the packages from the feed directory to where I share them, and
>>> then run
>>> the indexer against the external repository.  This preserves the older
>>> versions and also makes the new ones available.
>>>
>>> To run the indexer I have to configure and run it manually...
>>>
>>> PATH=/home/mhatle/build-6.0-RCPL-test/build/tmp/sysroots/x86_64-linux/bin:/home/mhatle/build-6.0-RCPL-test/bitbake/tmp/sysroots/x86_64-linux/usr/bin:$PATH
>>>
>>>
>>> /home/mhatle/build-6.0-RCPL-test/bitbake/tmp/sysroots/x86_64-linux/usr/bin/createrepo
>>>
>>> --update -q 
>>>
>>> So for qemux86_64, I end up running the above three times.  all,
>>> x86_64 and
>>> qemux86_64.
>>>
>>> Then on the target I just do:
>>>
>>> smart update
>>> smart upgrade -y
>>>
>>
>> Thanks, that's useful
>>
>> However I still believe the core question stands, which is why the
>> package index
>> is out of sync, and why it's a good thing to have to run bitbake
>> package-index
>
> The other option is to remove the repo indexes when packages are
> written. Again, I don't consider these out of sync though, as the
> files have different purposes and constraints.  They are simply
> constructed to enable the rootfs generation.  Upgrades are external of
> the build system.
>

Fair comment. I take the view that these feeds are available, could
easily be relied upon not to be transient, and I'd like to use them
locally to speed up my development workflow. I think other users would too.

Much of the value of the build environment is the automation. If bitbake
can do a task that means I don't have to remember to do it, and I don't
have to explain to somebody else that they need to do it, then that
seems like a win to me (even if that is an option I can turn on).

>> manually to bring the package index back into sync with the packages?
>>
>> I too export the feed directories to a server for 3rd party
>> consumption via
>> compressed rsync over SSH. I don't want to expose more on the server
>> than a
>> simple SSH endpoint, and rsync seems a sensible way to minimise
>> copying times,
>> so either I need the package index to be correct prior to the rsync,
>> I need to
>> export, say, an NFS filesystem which I don't want to do, or I need some
>> createrepo specifics on what I would prefer to be a dumb web-server.
>
> For an rsync, I would either index on the server using a cron-job.. so
> when new packages appear they get added to the index, or have a local
> mirror of the directory including the updated index... you just want
> to make sure the index files are synced last somehow.
>

To me the server side customisation brings in in extra work that
shouldn't be needed in all cases, (although will undoubtely be needed in
some cases).

I would much prefer not to h

[yocto] [Package Report System]Upgrade recipes name list

2014-04-22 Thread package-rep...@yoctoproject.org

This mail was sent out by Package Report System.
This message list those recipes which need to be upgraded. If maintainers 
believe some of them needn't to upgrade this time, they can fill in 
RECIPE_NO_UPDATE_REASON_pn-"xxx" in upstream_tracking files to ignore this 
recipe remainder until newer upstream version was detected.
Example:
RECIPE_NO_UPDATE_REASON_pn-"xxx" = "Not upgrade to 2.0 because the new version 
is unstable"
You can check the detail information at 
http://packages.yoctoproject.org/upgradepkgname


PackageName   Version   UpVersion   
  MaintainerNoUpgradeReason 
  
puzzles   r10116N/A 
  Valentin Popa
matchbox-panel-2  2.0+gitAUTOINC+26a3a67b41 
2.0+gitAUTOINC+1a7304dValentin Popa
matchbox-desktop  2.0+gitAUTOINC+71e3e6e042 
2.0+gitAUTOINC+09170f4Valentin Popa
matchbox-keyboard 0.0+gitAUTOINC+217f1bfe14 
0.0+gitAUTOINC+0899b02Valentin Popa
blktrace  1.0.5+gitAUTOINC+d6918c8  
1.0.5+gitAUTOINC+ce9ded7  Tom Zanussi
systemtap-uprobes 2.5+gitAUTOINC+ae91e3d552 
2.5+gitAUTOINC+996ca2fTom Zanussi
sysprof   1.2.0+gitAUTOINC+cd44ee6  
1.2.0+gitAUTOINC+6901897  Tom Zanussi
mkelfimage4.0+gitAUTOINC+686a48a339 
4.0+gitAUTOINC+d6060b7Saul Wold   
 
oprofileui-server 0.0+gitAUTOINC+f168b8bfdc 
0.0+gitAUTOINC+389e187Saul Wold   
 PRS Reports Incorrectly   
mx-1.01.4.7+gitAUTOINC+9b1db6b  
1.99.4+gitAUTOINC+63da1f2 Saul Wold   
 PRS 1.99 is dev version   
x264  r2265+gitAUTOINC+585324f  
r2265+gitAUTOINC+d6b4e63  Paul Eggleton  
lz4   r112  N/A 
  No Maintainer info
gummiboot 43+gitAUTOINC+4062c51075  
44+gitAUTOINC+9a356dd No Maintainer info
piglit1.0+gitrAUTOINC+bbeff5d2  
1.0+gitrAUTOINC+072385f   No Maintainer info
unfs3 0.9.22.r490   N/A 
  No Maintainer info
xf86-video-omap   0.4.2+gitrAUTOINC+ae0394  
0.4.3+gitrAUTOINC+d48d09c Laurentiu Palcu
tcf-agent 0.4.0+gitAUTOINC+4ef94ec  
8.0+gitAUTOINC+3b3f94aLaurentiu Palcu
btrfs-tools   3.12+gitAUTOINC+8cae1840  
3.14.1+gitAUTOINC+f2d42b7 Laurentiu Palcu
xinput-calibrator 0.7.5+gitAUTOINC+c01c5af  
0.7.5+gitAUTOINC+03dadf5  Laurentiu Palcu
oprofileui0.0+gitAUTOINC+f168b8bfdc 
0.0+gitAUTOINC+389e187Laurentiu Palcu
trace-cmd 1.2+gitAUTOINC+7055ffd37b 
2.3.2+gitAUTOINC+8435f51  Darren Hart   
kernelshark   1.2+gitAUTOINC+7055ffd37b 
2.3.2+gitAUTOINC+8435f51  Darren Hart   
0.2 is the latest version.
mtd-utils 1.5.0+gitAUTOINC+dcea43e  
1.5.1+gitAUTOINC+5923077  Cristiana Voicu
u-boot-mkimagev2013.07+gitAUTOINC+62c1  
v2013.07+gitAUTOINC+b149  Cristiana Voicu
kmod  16+gitAUTOINC+36c4bb928a  
17+gitAUTOINC+f5cdd57 Cristiana Voicu
ubootchart0.0+r12   N/A 
  Cristiana Voicu
systemtap 2.5+gitAUTOINC+ae91e3d552 
2.5+gitAUTOINC+996ca2fCristiana Voicu
babeltrace1.1.1+gitAUTOINC+a386e24  
1.2.1+gitAUTOINC+8a2cd19  Cristiana Voicu
mobile-broadband-provider-info20120614+gitrAUTOINC+4ed  
20120614+gitrAUTOINC+35d  Cristiana Voicu
tremor20120314  N/A 
  Cristian Iorga  Same revision on 
different SV...
linux-firmware0.0+gitAUTOINC+600caefd83 
0.0+gitAUTOINC+dec41bcCristian Iorga  
kern-tools-native 0.2+gitAUTOINC+a42509b01c 
0.2+gitAUTOINC+a212a4aBruce Ashfield  
Upgradable Count: 28
Upgrade Total Count: 32
The based commit merge time is:
Tue Apr 22 16:15:53 2014 +0100
The based commit is:
commit 02384f00105938befb3e79dc69f434918af99d46
Author: Scott Rifenbark 
Date:   Mon Apr 21 16:46:41 2014 -0700
Any problem, please contact Saul Wold  
recipe_color.inc/17: RECIPE_COLOR = "green"
-- 
_

[yocto] Canceled: Yocto Project Technical Team Meeting

2014-04-22 Thread Jolley, Stephen K

BEGIN:VCALENDAR
METHOD:CANCEL
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="Jolley, Stephen K":MAILTO:stephen.k.jol...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='achaudha@
 mvista.com':MAILTO:achau...@mvista.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Anders Da
 rander':MAILTO:and...@chargestorm.se
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Arce Moren
 o, Abraham":MAILTO:abraham.arce.mor...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Ashfield, 
 Bruce (Wind River)":MAILTO:bruce.ashfi...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Barros Pen
 a, Belen":MAILTO:belen.barros.p...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Burton, Ro
 ss":MAILTO:ross.bur...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Butler, Pa
 ul A (Wind River)":MAILTO:paul.but...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Chisanovic
 i, IonutX":MAILTO:ionutx.chisanov...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Chris Kam
 inski':MAILTO:chris.kamin...@tobias.tv
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Damian, Al
 exandru":MAILTO:alexandru.dam...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Daniel Ca
 uchy':MAILTO:dcau...@mvista.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="DeVries, A
 lex (Wind River)":MAILTO:alex.devr...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Dmytriyenk
 o, Denys":MAILTO:de...@ti.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Erway, Tra
 cey M":MAILTO:tracey.m.er...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Flanagan, 
 Elizabeth":MAILTO:elizabeth.flana...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Gavaz, Ion
 ut A":MAILTO:ionut.a.ga...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Georgescu,
  Alexandru C":MAILTO:alexandru.c.george...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Hart, Darr
 en":MAILTO:darren.h...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Harvey, Mi
 chael":MAILTO:michael.har...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Hatle, Mar
 k G (Wind River)":MAILTO:mark.ha...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Hudson, S
 ean'":MAILTO:sean_hud...@mentor.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Iorga, Cri
 stian":MAILTO:cristian.io...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Jeremy Pu
 hlman':MAILTO:jpuhl...@gmail.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Kamble, Ni
 tin A":MAILTO:nitin.a.kam...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Kridner, J
 ason":MAILTO:j...@ti.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Letnes, Th
 addeus C":MAILTO:thaddeus.c.let...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Liu, Song":
 MAILTO:song@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Long, Step
 hen J (Wind River)":MAILTO:steve.l...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Long, Yan
 ren'":MAILTO:yl...@wpi.edu
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Maupin, C
 hase'":MAILTO:chase.mau...@ti.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Moeller, T
 horsten":MAILTO:thorsten.moel...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Moses, Fre
 d":MAILTO:fred.mo...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Mueller, R
 obert":MAILTO:robert.muel...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Olivia Sal
 isbury:MAILTO:olivia.salisb...@tobias.tv
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Ong, Boon 
 Leong":MAILTO:boon.leong@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Osier-mixo
 n, Jeffrey":MAILTO:jeffrey.osier-mi...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Palalau, A
 lexandruX":MAILTO:alexandrux.pala...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Patel, Key
 ur R":MAILTO:keyur.r.pa...@intel.com
ATTENDEE;ROLE=

Re: [yocto] [meta-ivi][PATCH] weston: Add weston.ini config file

2014-04-22 Thread sujith h

Hi,

Any comments about this patch?

Thanks,
Sujith H


On Wed, Apr 16, 2014 at 1:42 PM, Sujith H  wrote:

> Adding weston.ini to $ROOT_HOME/.config. With this change
> user can login to $ROOT_HOME and launch weston with ivi-shell.
>
> Signed-off-by: Sujith H 
> ---
>  recipes-graphics/wayland/weston_1.4.0.bbappend | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/recipes-graphics/wayland/weston_1.4.0.bbappend
> b/recipes-graphics/wayland/weston_1.4.0.bbappend
> index 7a8ba6f..a2713d6 100644
> --- a/recipes-graphics/wayland/weston_1.4.0.bbappend
> +++ b/recipes-graphics/wayland/weston_1.4.0.bbappend
> @@ -12,3 +12,16 @@ PR = "r1"
>
>  FILES_${PN} += "${libdir}/weston/*"
>  FILES_${PN}-dbg += "${libdir}/weston/.debug/*"
> +
> +do_install_append() {
> +   install -d ${D}${ROOT_HOME}/.config
> +   install -m 0644 
> ${S}/ivi-shell/weston.ini.in${D}${ROOT_HOME}/.config/weston.ini
> +   sed -i -e  's/hmi-controller.so/hmi-controller.so, ivi-controller.so/'
> ${D}${ROOT_HOME}/.config/weston.ini
> +   sed -i -e 's|\@libexecdir\@|${libexecdir}|'
> ${D}${ROOT_HOME}/.config/weston.ini
> +   sed -i -e 's|\@abs_top_builddir\@\/data|${datadir}\/weston|'
> ${D}${ROOT_HOME}/.config/weston.ini
> +   sed -i -e 's|\@abs_top_builddir\@\/clients|${bindir}|'
> ${D}${ROOT_HOME}/.config/weston.ini
> +}
> +
> +PACKAGES += "${PN}-ini"
> +
> +FILES_${PN}-ini = "${ROOT_HOME}/.config"
> --
> 1.8.4
>
>


-- 
സുജിത് ഹരിദാസന്
Bangalore
Contributor to KDE project
http://fci.wikia.com/wiki/Anti-DRM-Campaign
 http://sujithh.info
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-ivi][PATCH] weston: Add weston.ini config file

2014-04-22 Thread Khem Raj

On Wed, Apr 16, 2014 at 1:12 AM, Sujith H  wrote:
> Adding weston.ini to $ROOT_HOME/.config. With this change
> user can login to $ROOT_HOME and launch weston with ivi-shell.

what if I am not root ? IOW is there more systemwide way of doing it ?

>
> Signed-off-by: Sujith H 
> ---
>  recipes-graphics/wayland/weston_1.4.0.bbappend | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/recipes-graphics/wayland/weston_1.4.0.bbappend 
> b/recipes-graphics/wayland/weston_1.4.0.bbappend
> index 7a8ba6f..a2713d6 100644
> --- a/recipes-graphics/wayland/weston_1.4.0.bbappend
> +++ b/recipes-graphics/wayland/weston_1.4.0.bbappend
> @@ -12,3 +12,16 @@ PR = "r1"
>
>  FILES_${PN} += "${libdir}/weston/*"
>  FILES_${PN}-dbg += "${libdir}/weston/.debug/*"
> +
> +do_install_append() {
> +   install -d ${D}${ROOT_HOME}/.config
> +   install -m 0644 ${S}/ivi-shell/weston.ini.in 
> ${D}${ROOT_HOME}/.config/weston.ini
> +   sed -i -e  's/hmi-controller.so/hmi-controller.so, ivi-controller.so/' 
> ${D}${ROOT_HOME}/.config/weston.ini
> +   sed -i -e 's|\@libexecdir\@|${libexecdir}|' 
> ${D}${ROOT_HOME}/.config/weston.ini
> +   sed -i -e 's|\@abs_top_builddir\@\/data|${datadir}\/weston|' 
> ${D}${ROOT_HOME}/.config/weston.ini
> +   sed -i -e 's|\@abs_top_builddir\@\/clients|${bindir}|' 
> ${D}${ROOT_HOME}/.config/weston.ini
> +}
> +
> +PACKAGES += "${PN}-ini"
> +
> +FILES_${PN}-ini = "${ROOT_HOME}/.config"
> --
> 1.8.4
>
> --
> ___
> 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] [RFT] gcc 4.9

2014-04-22 Thread Khem Raj

On Sun, Mar 23, 2014 at 1:35 AM, Khem Raj  wrote:
> Hi
>
> gcc 4.9 release is coming in summer therefore I have put together the recipes 
> here
>
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-4.9
>
> So far my testing has been booting angstrom/systemd-image on all supported
> qemu machines (except qemumips64 where there is a know kernel issue) both 
> eglibc/uclibc
> images
>
> we would like to target them for 1.7 release so if you have cycles to test out
> your image/machine combos please do so I would be interested in feedback and 
> would accumulate fixes in this branch
>
> If you run into some issues with some packages then its recommended to go 
> through
>
> http://gcc.gnu.org/gcc-4.9/changes.html
>
> and especially http://gcc.gnu.org/gcc-4.9/porting_to.html
>
> Which could help in cooking patches
>

Hi All

As you might have noticed gcc 4.9.0 was released today

changed are here http://gcc.gnu.org/gcc-4.9/changes.html

I have updated my contrib tree to use the release tar balls. Please
test the branch out. If you are using OE-Core
standalone you don't need to do anything once you apply the patches
from contrib branch it should select 4.9
I have left 4.8 still there since we want to phase it out only when we
are sure that complete ecosystem is working
fine with 4.9

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

Re: [yocto] [meta-ivi][PATCH] weston: Add weston.ini config file

2014-04-22 Thread sujith h

Hi Khem Raj,


On Wed, Apr 23, 2014 at 9:04 AM, Khem Raj  wrote:

> On Wed, Apr 16, 2014 at 1:12 AM, Sujith H  wrote:
> > Adding weston.ini to $ROOT_HOME/.config. With this change
> > user can login to $ROOT_HOME and launch weston with ivi-shell.
>
> what if I am not root ? IOW is there more systemwide way of doing it ?
>

I couldn't find any other login variable( like $ROOT_HOME) in bitbake.conf.
I agree that if we can do it in a more systemwide
way then it would be a clean solution. Any pointers to look at?


> >
> > Signed-off-by: Sujith H 
> > ---
> >  recipes-graphics/wayland/weston_1.4.0.bbappend | 13 +
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/recipes-graphics/wayland/weston_1.4.0.bbappend
> b/recipes-graphics/wayland/weston_1.4.0.bbappend
> > index 7a8ba6f..a2713d6 100644
> > --- a/recipes-graphics/wayland/weston_1.4.0.bbappend
> > +++ b/recipes-graphics/wayland/weston_1.4.0.bbappend
> > @@ -12,3 +12,16 @@ PR = "r1"
> >
> >  FILES_${PN} += "${libdir}/weston/*"
> >  FILES_${PN}-dbg += "${libdir}/weston/.debug/*"
> > +
> > +do_install_append() {
> > +   install -d ${D}${ROOT_HOME}/.config
> > +   install -m 0644 
> > ${S}/ivi-shell/weston.ini.in${D}${ROOT_HOME}/.config/weston.ini
> > +   sed -i -e  's/hmi-controller.so/hmi-controller.so,
> ivi-controller.so/' ${D}${ROOT_HOME}/.config/weston.ini
> > +   sed -i -e 's|\@libexecdir\@|${libexecdir}|'
> ${D}${ROOT_HOME}/.config/weston.ini
> > +   sed -i -e 's|\@abs_top_builddir\@\/data|${datadir}\/weston|'
> ${D}${ROOT_HOME}/.config/weston.ini
> > +   sed -i -e 's|\@abs_top_builddir\@\/clients|${bindir}|'
> ${D}${ROOT_HOME}/.config/weston.ini
> > +}
> > +
> > +PACKAGES += "${PN}-ini"
> > +
> > +FILES_${PN}-ini = "${ROOT_HOME}/.config"
> > --
> > 1.8.4
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>



-- 
സുജിത് ഹരിദാസന്
Bangalore
Contributor to KDE project
http://fci.wikia.com/wiki/Anti-DRM-Campaign
 http://sujithh.info
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-ivi][PATCH] weston: Add weston.ini config file

2014-04-22 Thread Khem Raj

On Tue, Apr 22, 2014 at 10:59 PM, sujith h  wrote:
>> what if I am not root ? IOW is there more systemwide way of doing it ?
>
>
> I couldn't find any other login variable( like $ROOT_HOME) in bitbake.conf.
> I agree that if we can do it in a more systemwide
> way then it would be a clean solution. Any pointers to look at?

well, its not really OE issue. see if weston can read configuration
files somewhere in /etc/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Rgardring GSTreamer1.0 integration on Yocto Dora

[yocto] Problem with own kernel recipe on Dora

[yocto] Newbie question: How to get dependencies into compile of custom recipe?

Re: [yocto] Problem with own kernel recipe on Dora

Re: [yocto] Newbie question: How to get dependencies into compile of custom recipe?

Re: [yocto] defconfig on daisy

Re: [yocto] Problem with own kernel recipe on Dora

Re: [yocto] Problem with own kernel recipe on Dora

Re: [yocto] No USB devices on BeagleBoard xM!

Re: [yocto] Problem with own kernel recipe on Dora

Re: [yocto] Problem with own kernel recipe on Dora

Re: [yocto] Newbie question: How to get dependencies into compile of custom recipe?

Re: [yocto] Newbie question: How to get dependencies into compile of custom recipe?

Re: [yocto] Newbie question: How to get dependencies into compile of custom recipe?

Re: [yocto] Newbie question: How to get dependencies into compile of custom recipe?

[linux-yocto] v2g_bridge driver required

[yocto] [solved] Re: Newbie question: How to get dependencies into compile of custom recipe?

[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, April 22, 2014 8:00 AM US Pacific Time

Re: [yocto] eglibc-2.18 is not compiling

Re: [yocto] defconfig on daisy

Re: [yocto] Question about rebuilding RPM package index for updated RPMs when bitbake completes

Re: [yocto] eglibc-2.18 is not compiling

Re: [yocto] eglibc-2.18 is not compiling

Re: [yocto] Question about rebuilding RPM package index for updated RPMs when bitbake completes

[yocto] [Package Report System]Upgrade recipes name list

[yocto] Canceled: Yocto Project Technical Team Meeting

Re: [yocto] [meta-ivi][PATCH] weston: Add weston.ini config file

Re: [yocto] [meta-ivi][PATCH] weston: Add weston.ini config file

Re: [yocto] [RFT] gcc 4.9

Re: [yocto] [meta-ivi][PATCH] weston: Add weston.ini config file

Re: [yocto] [meta-ivi][PATCH] weston: Add weston.ini config file

31 matches

Site Navigation

Mail list logo

Footer information