Re: [yocto] help with meta-java

[Shockley, Timothy]

I have a first pass at porting the patch files for openjdk-8-native and 
openjre-8 but I'm having trouble in the do_configure task. autoreconf is not 
happy because Java build is wanting to have $TOPDIR/common/autoconf/build-aux 
directory available. Wondering if there's something obvious I've overlooked or 
done incorrectly? 


 log.do_configure ---

DEBUG: Executing shell function autotools_preconfigure
DEBUG: Shell function autotools_preconfigure finished
DEBUG: Executing python function autotools_aclocals
DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc', 'bit-64', 
'x86_64-linux', 'common']
DEBUG: Python function autotools_aclocals finished
DEBUG: Executing shell function do_configure
automake (GNU automake) 1.16.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later 
<https://gnu.org/licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey 
   and Alexandre Duret-Lutz .
AUTOV is 1.16
NOTE: Executing ACLOCAL="aclocal 
--system-acdir=/home/tshockley/encinitas-bsp/build/tmp/work/x86_64-linux/openjdk-8-native/232b09-r0/recipe-sysroot-native/usr/share/aclocal/
 
--automake-acdir=/home/tshockley/encinitas-bsp/build/tmp/work/x86_64-linux/openjdk-8-native/232b09-r0/recipe-sysroot-native/usr/share/aclocal-1.16"
 autoreconf -Wcross --verbose --install --force --exclude=autopoint -I 
/home/tshockley/encinitas-bsp/build/tmp/work/x86_64-linux/openjdk-8-native/232b09-r0/jdk8u-6b9f309807a2/common/autoconf/
 -I 
/home/tshockley/encinitas-bsp/build/tmp/work/x86_64-linux/openjdk-8-native/232b09-r0/jdk8u-6b9f309807a2/common/autoconf/build-aux/
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal 
--system-acdir=/home/tshockley/encinitas-bsp/build/tmp/work/x86_64-linux/openjdk-8-native/232b09-r0/recipe-sysroot-native/usr/share/aclocal/
 
--automake-acdir=/home/tshockley/encinitas-bsp/build/tmp/work/x86_64-linux/openjdk-8-native/232b09-r0/recipe-sysroot-native/usr/share/aclocal-1.16
 -I 
/home/tshockley/encinitas-bsp/build/tmp/work/x86_64-linux/openjdk-8-native/232b09-r0/jdk8u-6b9f309807a2/common/autoconf/
 -I 
/home/tshockley/encinitas-bsp/build/tmp/work/x86_64-linux/openjdk-8-native/232b09-r0/jdk8u-6b9f309807a2/common/autoconf/build-aux/
 --force
autoreconf: configure.ac: tracing
autoreconf: configure.ac: creating directory $TOPDIR/common/autoconf/build-aux
autoreconf: cannot create $TOPDIR/common/autoconf/build-aux: No such file or 
directory
autoreconf: configure.ac: not using Libtool
autoreconf: running: 
/home/tshockley/encinitas-bsp/build/tmp/work/x86_64-linux/openjdk-8-native/232b09-r0/recipe-sysroot-native/usr/bin/autoconf
 
--include=/home/tshockley/encinitas-bsp/build/tmp/work/x86_64-linux/openjdk-8-native/232b09-r0/jdk8u-6b9f309807a2/common/autoconf/
 
--include=/home/tshockley/encinitas-bsp/build/tmp/work/x86_64-linux/openjdk-8-native/232b09-r0/jdk8u-6b9f309807a2/common/autoconf/build-aux/
 --force
autoreconf: running: 
/home/tshockley/encinitas-bsp/build/tmp/work/x86_64-linux/openjdk-8-native/232b09-r0/recipe-sysroot-native/usr/bin/autoheader
 
--include=/home/tshockley/encinitas-bsp/build/tmp/work/x86_64-linux/openjdk-8-native/232b09-r0/jdk8u-6b9f309807a2/common/autoconf/
 
--include=/home/tshockley/encinitas-bsp/build/tmp/work/x86_64-linux/openjdk-8-native/232b09-r0/jdk8u-6b9f309807a2/common/autoconf/build-aux/
 --force
autoreconf: configure.ac: not using Automake
autoreconf: running: gnu-configize
gnu-configize: cannot create $TOPDIR/common/autoconf/build-aux: No such file or 
directory
cp: cannot create regular file '/common/autoconf/build-aux/': No such file or 
directory
gnu-configize: cp failed with exit status: 1
autoreconf: gnu-configize failed with exit status: 1
ERROR: autoreconf execution failed.
WARNING: exit code 1 from a shell command.
ERROR: Execution of 
'/home/tshockley/encinitas-bsp/build/tmp/work/x86_64-linux/openjdk-8-native/232b09-r0/temp/run.do_configure.9248'
 failed with exit code 1:


 

-Original Message-
From: Richard Leitner  
Sent: Tuesday, November 5, 2019 01:26
To: Vincent Prince ; Shockley, Timothy 

Cc: yocto@yoctoproject.org; henn...@itconsulting-heinold.de; Maxin B. John 
; Otavio Salvador 
Subject: Re: [yocto] help with meta-java

Hi,
unfortunately, due to a different focus on my day job in the previous months I 
didn't had time for doing any work on meta-java.

This will change in the coming weeks and I will start to review and test 
patches again.

Nonetheless it would be great if one of the other listed maintainers (or 
somebody else) can support me as there will be significant refactoring, cleanup 
and update work to be done ;-)

regards;Richard.L


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

Re: [yocto] help with meta-java

[Ross Burton]

On 05/11/2019 08:18, Vincent Prince wrote:

Main layer maintainers:
   Henning Heinold 
   Maxin John 
   Otavio Salvador 
   Richard Leitner 


Maxin no longer works at Intel and I believe doesn't work on Yocto 
anymore either.


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

Re: [yocto] help with meta-java

[Richard Leitner]

Hi,
unfortunately, due to a different focus on my day job in the previous 
months I didn't had time for doing any work on meta-java.


This will change in the coming weeks and I will start to review and test 
patches again.


Nonetheless it would be great if one of the other listed maintainers (or 
somebody else) can support me as there will be significant refactoring, 
cleanup and update work to be done ;-)


regards;Richard.L

On 05/11/2019 09:18, Vincent Prince wrote:

Hi Tim,

There are some pending stuff on meta-java ML
openembedded-de...@lists.openembedded.org and layer is not zeus
compatible yet.
I'm trying to contact layer maintainers for several weeks, i don't
know if information is obsolete or if people are too busy/away?

Main layer maintainers:
   Henning Heinold 
   Maxin John 
   Otavio Salvador 
   Richard Leitner 

For now, I just use master-next, and I'm considering using
https://github.com/AdoptOpenJDK/ prebuilds, meta-java is quite hard to
understand I found :)

Best regards,
Vincent

Le lun. 4 nov. 2019 à 18:23, Shockley, Timothy
 a écrit :


Helllo,



I am looking for some help with meta-java, specifically upgrading to zeus 
branch and also upgrading openjdk to a more recent release in order to address 
CVEs. Wondering if there is anyone else working / needing this?



Thanks,

Tim Shockley



--
___
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] help with meta-java

[Vincent Prince]

Hi Tim,

There are some pending stuff on meta-java ML
openembedded-de...@lists.openembedded.org and layer is not zeus
compatible yet.
I'm trying to contact layer maintainers for several weeks, i don't
know if information is obsolete or if people are too busy/away?

Main layer maintainers:
  Henning Heinold 
  Maxin John 
  Otavio Salvador 
  Richard Leitner 

For now, I just use master-next, and I'm considering using
https://github.com/AdoptOpenJDK/ prebuilds, meta-java is quite hard to
understand I found :)

Best regards,
Vincent

Le lun. 4 nov. 2019 à 18:23, Shockley, Timothy
 a écrit :
>
> Helllo,
>
>
>
> I am looking for some help with meta-java, specifically upgrading to zeus 
> branch and also upgrading openjdk to a more recent release in order to 
> address CVEs. Wondering if there is anyone else working / needing this?
>
>
>
> Thanks,
>
> Tim Shockley
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] help with meta-java

[Shockley, Timothy]

Helllo,

I am looking for some help with meta-java, specifically upgrading to zeus 
branch and also upgrading openjdk to a more recent release in order to address 
CVEs. Wondering if there is anyone else working / needing this?

Thanks,
Tim Shockley

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

[yocto] Help needed add own variable to toolchain environment

[Johann Obermayr]

Hello,

i have trouble to add a own variable to the toolchain environment
I see that environment-setup-i586-poky-linx script calls all files in 
sysroot//environment-setup.d/*

But what is the simples and correct way to add follow line (export KSRC...)

do_something() {

mkdir -p ${D}${SDKPATHNATIVE}/environment-setup.d/
script=${D}${SDKPATHNATIVE}/environment-setup.d/sigmatek.sh

echo '# own environment settings' > $script
echo 'export 
KSRC="${OECORE_NATIVE_SYSROOT}/lib/modules/${KERNEL_VERSION}/build"' >> $script
}
Is the best way for create a new bb file.

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

Re: [yocto] [help] Multiconfig - Depending on Recipe multiple times

[Mark Hatle]

On 8/29/19 10:05 AM, Johannes Wiesböck wrote:
> Hello Everyone,
> 
> i am using Yocto on the thud branch to build images for a real-time

This is not implemented in thud.  Thud had multiconfig supported, but didn't yet
allow for dependencies between configurations.

Master has support for multiconfig dependencies as well, but I'm not sure how
well tested they are.

--Mark

> operating system based on FreeRTOS. I would like to run multiple images
> on different CPU cores in an asynchronous multi-processing (AMP) 
> configuration.
> Each image will contain the software for only one single core. For
> deployment, i would like to pack all images into one package.
> 
> Therefore, i would like to use multiconfig to build the same recipe four
> times for the same hardware but with different compiler options,
> determined by to core the image should run on. These builds are all based on
> the same source code but differ in compiler options used for building. After
> the images for all configurations are built, i would like to pack all images
> into a single package for deployment.
> 
> I have created two recipes, one called amp-image, that should be built
> once for every multiconfig. A second recipe called master-image,
> depends on amp-image for every configuration, i.e. i have the line
> 
> do_compile[mcdepends] = "multiconfig:amp-c0:amp-c0:amp-image:do_build 
> multiconfig:amp-c0:amp-c1:amp-image:do_build"
> 
> in my master-image.bb file. I also have set up my multiconfigs according
> to [0].
> 
> When i try to build master-image with 
> 
> bitbake multiconfig:amp-c0:master-image
> 
> i get an error, which i have attached in [1].
> 
> My question is: Is it generally possible for a recipe to depend on one
> recipe multiple times but from a different multiconfig, like shown above?
> Also, if possible, are the sysroots of the dependencies automatically
> populated to the recipe depending on them, like with the usual DEPENDS
> variable.
> 
> 
> Thanks for any help!
> Johannes Wiesboeck
> 
> [0] 
> https://www.yoctoproject.org/docs/2.6/dev-manual/dev-manual.html#dev-building-images-for-multiple-targets-using-multiple-configurations
> [1] https://home.in.tum.de/~wiesboec/bitbake.txt
> 

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

[yocto] [help] Multiconfig - Depending on Recipe multiple times

[Johannes Wiesböck]

Hello Everyone,

i am using Yocto on the thud branch to build images for a real-time
operating system based on FreeRTOS. I would like to run multiple images
on different CPU cores in an asynchronous multi-processing (AMP) configuration.
Each image will contain the software for only one single core. For
deployment, i would like to pack all images into one package.

Therefore, i would like to use multiconfig to build the same recipe four
times for the same hardware but with different compiler options,
determined by to core the image should run on. These builds are all based on
the same source code but differ in compiler options used for building. After
the images for all configurations are built, i would like to pack all images
into a single package for deployment.

I have created two recipes, one called amp-image, that should be built
once for every multiconfig. A second recipe called master-image,
depends on amp-image for every configuration, i.e. i have the line

do_compile[mcdepends] = "multiconfig:amp-c0:amp-c0:amp-image:do_build 
multiconfig:amp-c0:amp-c1:amp-image:do_build"

in my master-image.bb file. I also have set up my multiconfigs according
to [0].

When i try to build master-image with 

bitbake multiconfig:amp-c0:master-image

i get an error, which i have attached in [1].

My question is: Is it generally possible for a recipe to depend on one
recipe multiple times but from a different multiconfig, like shown above?
Also, if possible, are the sysroots of the dependencies automatically
populated to the recipe depending on them, like with the usual DEPENDS
variable.


Thanks for any help!
Johannes Wiesboeck

[0] 
https://www.yoctoproject.org/docs/2.6/dev-manual/dev-manual.html#dev-building-images-for-multiple-targets-using-multiple-configurations
[1] https://home.in.tum.de/~wiesboec/bitbake.txt
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Help to add uboot/standalone binary program for yocto projects

[Szabolcs Báder]

Hello

I follow my last email, I solved the reboot things. Works fine.. but I
found a cool/interesting thing, what I would like to integrate. >>

I read about standalone binaries (from C, or with Rust generated too?)
could use at uboot.
http://www.denx.de/wiki/view/DULG/UBootCmdGroupExec#Section_5.9.4.1
Hello World example: http://www.denx.de/wiki/view/DULG/UBootStandalone

I understand but really not, how possible use with Yocto. I just create a
similar hello_world.c program like at example and solved? Drop to the same
folder? .. (I use rpi3.) Somebody did similar thing in the past? Or good
example?

On Stackoverflow:
https://stackoverflow.com/questions/49814470/u-boot-how-to-run-a-standalone-binary-program
"You can use the Yocto toolchain but you cannot link against the C library
(which is done by default) so you have to put some extra options to GCC to
let it know that, also, you cannot use the go instruction from U-Boot to
jump to an ELF binary that you just loaded in memory, the ELF binary has to
be converted to a 'raw' binary (list of ARM instructions in your case) with
the tool objdump. An ELF binary it's a specific format that encapsulate
your code/your data and some extra information, and the first part of the
ELF is the description of the binary, so right now, when you do a go at the
first address, you are trying to tell the CPU to execute something which is
not an ARM instruction. You basically want to execute what we call the
'.text' section of the ELF binary."

Many thanks,
Szabolcs
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Help with cleaning/rebuidling

[Edward Wingate]

On Fri, Feb 1, 2019 at 7:57 AM Yann CARDAILLAC 
wrote:

> Hi Ed,
>
> I don't want to state the obvious but firstly did you check that you have
> the stuff asked :
>
>
> *CMake Error: The source directory "/mnt/drive/yocto/poky/build/t*
> *mp/work/cortexa9-vfp-neon-poky**-linux-gnueabi/mosquitto/1.5.*
> *5-r0/mosquitto-1.5.5" does not exist.*
>
> If
> /mnt/drive/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.5.5-r0/mosquitto-1.5.5
> is not reachable then that's the issue.
>
>
That directory does not exist.  I believe the cleanall removed that
directory.  The question is why doesn't bitbake make the directory and
untar into it, like it did the very first time I bitbaked mosquitto?  To
work around this, I have to manually untar the mosquitto tarball from my
DL_DIR into that directory, and then mosquitto will build properly.




> Regards,
>
> On Mon, Jan 28, 2019 at 6:19 PM Edward Wingate 
> wrote:
>
>> The first time I did a build, my mosquitto recipe worked.  Then I did
>> a 'bitbake -ccleanall mosquitto', and now when I do 'bitbake
>> mosquitto', I get this error:
>>
>> DEBUG: Executing python function sysroot_cleansstate
>> DEBUG: Python function sysroot_cleansstate finished
>> DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32',
>> 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
>> 'common']
>> DEBUG: Executing shell function autotools_preconfigure
>> DEBUG: Shell function autotools_preconfigure finished
>> DEBUG: Executing python function autotools_copy_aclocals
>> DEBUG: Python function autotools_copy_aclocals finished
>> DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32',
>> 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
>> 'common']
>> DEBUG: Executing shell function do_configure
>> CMake Error: The source directory
>>
>> "/mnt/drive/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.5.5-r0/mosquitto-1.5.5"
>> does not exist.
>> Specify --help for usage, or press the help button on the CMake GUI.
>> WARNING: exit code 1 from a shell command.
>> ERROR: Function failed: do_configure (log file is located at
>>
>> /mnt/drive/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.5.5-r0/temp/log.do_configure.37839)
>>
>> It seems like it doesn't fetch/unpack the source before do_configure.
>> I tried to do 'bitbake -c fetch mosquitto' and 'bitbake -c unpack
>> mosquitto', and they both say all tasks didn't need to be rerun. I
>> forced it by adding '-f', but that didn't help either.
>>
>> I'm still using jethro and my mosquitto_1.5.5.bb recipe is this:
>>
>> === BEGIN RECIPE ===
>> SUMMARY = "MQTT 3.1 compliant library"
>> HOMEPAGE = "https://mosquitto.org";
>> MAINTAINER = "Robert Lehmann "
>>
>> LICENSE = "EPL-1.0"
>> LIC_FILES_CHKSUM =
>> "file://LICENSE.txt;md5=62ddc846179e908dc0c8efec4a42ef20"
>>
>> SRC_URI = "https://mosquitto.org/files/source/mosquitto-${PV}.tar.gz";
>> SRC_URI[md5sum] = "a17dffc6f63b2a4ab2eb5c51139e60e9"
>> SRC_URI[sha256sum] =
>> "fcdb47e340864c545146681af7253399cc292e41775afd76400fda5b0d23d668"
>>
>> DEPENDS = "openssl"
>> RDEPENDS_${PN} = "util-linux"
>>
>> inherit cmake
>>
>> # Specify any options you want to pass to cmake using EXTRA_OECMAKE:
>> EXTRA_OECMAKE = " -DCMAKE_SKIP_RPATH=ON "
>> === END RECIPE ===
>>
>> Can anyone help with this?
>>
>> Thanks,
>> Ed
>> --
>> ___
>> 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] Help with cleaning/rebuidling

[Yann CARDAILLAC]

Hi Ed,

I don't want to state the obvious but firstly did you check that you have
the stuff asked :


*CMake Error: The source directory "/mnt/drive/yocto/poky/build/t*
*mp/work/cortexa9-vfp-neon-poky**-linux-gnueabi/mosquitto/1.5.*
*5-r0/mosquitto-1.5.5" does not exist.*

If
/mnt/drive/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.5.5-r0/mosquitto-1.5.5
is not reachable then that's the issue.

Regards,

On Mon, Jan 28, 2019 at 6:19 PM Edward Wingate  wrote:

> The first time I did a build, my mosquitto recipe worked.  Then I did
> a 'bitbake -ccleanall mosquitto', and now when I do 'bitbake
> mosquitto', I get this error:
>
> DEBUG: Executing python function sysroot_cleansstate
> DEBUG: Python function sysroot_cleansstate finished
> DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32',
> 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
> 'common']
> DEBUG: Executing shell function autotools_preconfigure
> DEBUG: Shell function autotools_preconfigure finished
> DEBUG: Executing python function autotools_copy_aclocals
> DEBUG: Python function autotools_copy_aclocals finished
> DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32',
> 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
> 'common']
> DEBUG: Executing shell function do_configure
> CMake Error: The source directory
>
> "/mnt/drive/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.5.5-r0/mosquitto-1.5.5"
> does not exist.
> Specify --help for usage, or press the help button on the CMake GUI.
> WARNING: exit code 1 from a shell command.
> ERROR: Function failed: do_configure (log file is located at
>
> /mnt/drive/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.5.5-r0/temp/log.do_configure.37839)
>
> It seems like it doesn't fetch/unpack the source before do_configure.
> I tried to do 'bitbake -c fetch mosquitto' and 'bitbake -c unpack
> mosquitto', and they both say all tasks didn't need to be rerun. I
> forced it by adding '-f', but that didn't help either.
>
> I'm still using jethro and my mosquitto_1.5.5.bb recipe is this:
>
> === BEGIN RECIPE ===
> SUMMARY = "MQTT 3.1 compliant library"
> HOMEPAGE = "https://mosquitto.org";
> MAINTAINER = "Robert Lehmann "
>
> LICENSE = "EPL-1.0"
> LIC_FILES_CHKSUM =
> "file://LICENSE.txt;md5=62ddc846179e908dc0c8efec4a42ef20"
>
> SRC_URI = "https://mosquitto.org/files/source/mosquitto-${PV}.tar.gz";
> SRC_URI[md5sum] = "a17dffc6f63b2a4ab2eb5c51139e60e9"
> SRC_URI[sha256sum] =
> "fcdb47e340864c545146681af7253399cc292e41775afd76400fda5b0d23d668"
>
> DEPENDS = "openssl"
> RDEPENDS_${PN} = "util-linux"
>
> inherit cmake
>
> # Specify any options you want to pass to cmake using EXTRA_OECMAKE:
> EXTRA_OECMAKE = " -DCMAKE_SKIP_RPATH=ON "
> === END RECIPE ===
>
> Can anyone help with this?
>
> Thanks,
> Ed
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>


-- 
[image: SMILE] 

20 rue des Jardins
92600 Asnières-sur-Seine
*Yann CARDAILLAC*
Ingénieur Linux Embarqué

[image: email] yann.cardail...@smile.fr
[image: url] http://www.smile.eu

[image: Twitter]  [image: Facebook]
 [image: LinkedIn]
 [image: Github]



[image: eco] Pour la planète, n'imprimez ce mail que si c'est nécessaire
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Help with cleaning/rebuidling

[Edward Wingate]

The first time I did a build, my mosquitto recipe worked.  Then I did
a 'bitbake -ccleanall mosquitto', and now when I do 'bitbake
mosquitto', I get this error:

DEBUG: Executing python function sysroot_cleansstate
DEBUG: Python function sysroot_cleansstate finished
DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32',
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
'common']
DEBUG: Executing shell function autotools_preconfigure
DEBUG: Shell function autotools_preconfigure finished
DEBUG: Executing python function autotools_copy_aclocals
DEBUG: Python function autotools_copy_aclocals finished
DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32',
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
'common']
DEBUG: Executing shell function do_configure
CMake Error: The source directory
"/mnt/drive/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.5.5-r0/mosquitto-1.5.5"
does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
WARNING: exit code 1 from a shell command.
ERROR: Function failed: do_configure (log file is located at
/mnt/drive/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.5.5-r0/temp/log.do_configure.37839)

It seems like it doesn't fetch/unpack the source before do_configure.
I tried to do 'bitbake -c fetch mosquitto' and 'bitbake -c unpack
mosquitto', and they both say all tasks didn't need to be rerun. I
forced it by adding '-f', but that didn't help either.

I'm still using jethro and my mosquitto_1.5.5.bb recipe is this:

=== BEGIN RECIPE ===
SUMMARY = "MQTT 3.1 compliant library"
HOMEPAGE = "https://mosquitto.org";
MAINTAINER = "Robert Lehmann "

LICENSE = "EPL-1.0"
LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=62ddc846179e908dc0c8efec4a42ef20"

SRC_URI = "https://mosquitto.org/files/source/mosquitto-${PV}.tar.gz";
SRC_URI[md5sum] = "a17dffc6f63b2a4ab2eb5c51139e60e9"
SRC_URI[sha256sum] =
"fcdb47e340864c545146681af7253399cc292e41775afd76400fda5b0d23d668"

DEPENDS = "openssl"
RDEPENDS_${PN} = "util-linux"

inherit cmake

# Specify any options you want to pass to cmake using EXTRA_OECMAKE:
EXTRA_OECMAKE = " -DCMAKE_SKIP_RPATH=ON "
=== END RECIPE ===

Can anyone help with this?

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

Re: [yocto] Help with Nano Recipe

[Kosta Zertsekel]

> It is very unusual to implement a recipe this way , and you should
> rely on base classes to do that for you. For reference there is a
> recipe for 'nano' in meta-oe already.
> http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/nano/nano_3.0.bb?h=master

And if you find anything amiss in this ``nano_3.0.bb`` recipe, you should have 
definitely begun with ``devtool``.
For example:
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#using-devtool-in-your-sdk-workflow

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

Re: [yocto] Help with Nano Recipe

[Nicolas Dechesne]

On Tue, Oct 30, 2018 at 5:38 PM nick  wrote:
>
> Greetings All,
> I am trying to get the below recipe to build:
> SUMMARY = "Recipe to build the 'nano' editor"
>
> PN = "nano"
> PV = "2.2.6"
> LICENSE="GPLv3"
>
> SITE = "http://www.nano-editor.org/dist";
> PV_MAJOR = "${@d.getVar('PV',d,1).split('.')[0]}"
> PV_MINOR = "${@d.getVar('PV',d,1).split('.')[1]}"
> LIC_FILES_CHKSUM = 
> "${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949"
>
> SRC_URI = "${SITE}/v${PV_MAJOR}.${PV_MINOR}/${PN}-${PV}.tar.gz"
> SRC_URI[md5sum] = "03233ae480689a008eb98feb1b599807"
> SRC_URI[sha256sum] = \
> "be68e133b5e81df41873d32c517b3e5950770c00fc5f4dd23810cd635abce67a"
> LIC_FILES_CHKSUM = 
> "${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949

You are missing a quote at the end.

>
>
> python do_fetch() {
> bb.plain("Downloading source tarball from ${SRC_URI} ...")
> src_uri = (d.getVar('SRC_URI', True) or "").split()
> if len(src_uri) == 0:
>bb.fatal("Empty URI")
> try:
>fetcher = bb.fetch2.Fetch(src_uri, d)
>fetcher.download()
> except bb.fetch2.BBFetchException:
>bb.fatal("Could not fetch source tarball.")
> bb.plain("Download successful.")
> }

It is very unusual to implement a recipe this way , and you should
rely on base classes to do that for you. For reference there is a
recipe for 'nano' in meta-oe already.

http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/nano/nano_3.0.bb?h=master

>
> addtask fetch before do_build
>
> python do_unpack() {
> bb.plain("Unpacking source tarball ...")
> os.system("tar x -C ${WORKDIR} -f ${DL_DIR}/${P}.tar.gz")
> bb.plain("Unpacked source tarball.")
> }
>
> addtask unpack before do_build after do_fetch
>
> python do_configure() {
> bb.plain("Configuring source package ...")
> os.system("cd ${WORKDIR}/${P} && ./configure")
> bb.plain("Configured source package.")
> }
>
> addtask configure before do_build after do_unpack
>
> python do_compile() {
> bb.plain("Compiling package...")
> os.system("cd ${WORKDIR}/${P} && make")
> bb.plain("Compiled package.")
> }
>
> addtask compile before do_build after do_configure
>
> do_clean[nostamp] = "1"
> do_clean() {
> rm -rf ${WORKDIR}/${P}
> rm -f ${TMPDIR}/stamps/*
> }
>
> addtask clean
>
> And am working why this error is occuring:
> ERROR: ParseError at /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb:15: 
> unparsed line: 'LIC_FILES_CHKSUM = 
> "${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949'
>
> I looked through the logs already and it was reported but only changed the 
> file number seemed to change it. I am wondering if there is a better
> solution or why that's a bad CHSUM variable according to bitbake.
>
> Thanks,
> Nick
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Help with Nano Recipe

[nick]

Greetings All, 
I am trying to get the below recipe to build:
SUMMARY = "Recipe to build the 'nano' editor"

PN = "nano"
PV = "2.2.6"
LICENSE="GPLv3"

SITE = "http://www.nano-editor.org/dist";
PV_MAJOR = "${@d.getVar('PV',d,1).split('.')[0]}"
PV_MINOR = "${@d.getVar('PV',d,1).split('.')[1]}"
LIC_FILES_CHKSUM = 
"${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949"

SRC_URI = "${SITE}/v${PV_MAJOR}.${PV_MINOR}/${PN}-${PV}.tar.gz"
SRC_URI[md5sum] = "03233ae480689a008eb98feb1b599807"
SRC_URI[sha256sum] = \
"be68e133b5e81df41873d32c517b3e5950770c00fc5f4dd23810cd635abce67a"
LIC_FILES_CHKSUM = 
"${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949


python do_fetch() {
bb.plain("Downloading source tarball from ${SRC_URI} ...")
src_uri = (d.getVar('SRC_URI', True) or "").split()
if len(src_uri) == 0:
   bb.fatal("Empty URI")
try:
   fetcher = bb.fetch2.Fetch(src_uri, d)
   fetcher.download()
except bb.fetch2.BBFetchException:
   bb.fatal("Could not fetch source tarball.")
bb.plain("Download successful.")
}

addtask fetch before do_build

python do_unpack() {
bb.plain("Unpacking source tarball ...")
os.system("tar x -C ${WORKDIR} -f ${DL_DIR}/${P}.tar.gz")
bb.plain("Unpacked source tarball.")
}

addtask unpack before do_build after do_fetch

python do_configure() {
bb.plain("Configuring source package ...")
os.system("cd ${WORKDIR}/${P} && ./configure")
bb.plain("Configured source package.")
}

addtask configure before do_build after do_unpack

python do_compile() {
bb.plain("Compiling package...")
os.system("cd ${WORKDIR}/${P} && make")
bb.plain("Compiled package.")
}

addtask compile before do_build after do_configure

do_clean[nostamp] = "1"
do_clean() {
rm -rf ${WORKDIR}/${P}
rm -f ${TMPDIR}/stamps/*
}

addtask clean

And am working why this error is occuring:
ERROR: ParseError at /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb:15: 
unparsed line: 'LIC_FILES_CHKSUM = 
"${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949' 

I looked through the logs already and it was reported but only changed the file 
number seemed to change it. I am wondering if there is a better
solution or why that's a bad CHSUM variable according to bitbake.

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

[yocto] help required to build 32-bit executable using yocto gcc

[Ram Regar (rregar)]

Hi,

I am looking to use gcc built by yocto sdk with –m32 option.

I changed MACHINE to genericx86-64 local.conf and also added these lines to be 
able to add multilib support with gcc.

IMAGE_INSTALL_append = " glibc-staticdev"
NO32LIBS = "0"

require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"

But I get these these errors. I am using dizzy branch, a bit old but I believe 
this branch also support –m32 in gcc that it build internally. Gcc can generate 
64 bit binaries but not 32-bit binaries.

[dizzy@dizzy-centos7 core-minimal]$ x86_64-poky-linux-gcc -m32 -march=core2 
-mtune=core2 -msse3 -mfpmath=sse 
--sysroot=/home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/core2-64-poky-linux
 ~/thread.c
/home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.9.1/ld:
 skipping incompatible 
/home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/core2-64-poky-linux/usr/lib64/x86_64-poky-linux/4.9.1/libgcc.a
 when searching for -lgcc
/home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.9.1/ld:
 cannot find -lgcc
/home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.9.1/ld:
 skipping incompatible 
/home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/core2-64-poky-linux/usr/lib64/libc.so
 when searching for -lc
/home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.9.1/ld:
 skipping incompatible 
/home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/core2-64-poky-linux/usr/lib64/libc.a
 when searching for -lc
/home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.9.1/ld:
 cannot find -lc
/home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.9.1/ld:
 skipping incompatible 
/home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/core2-64-poky-linux/usr/lib64/x86_64-poky-linux/4.9.1/libgcc.a
 when searching for -lgcc
/home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.9.1/ld:
 cannot find -lgcc
/home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.9.1/ld:
 skipping incompatible 
/home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/core2-64-poky-linux/lib64/libgcc_s.so
 when searching for -lgcc_s
/home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.9.1/ld:
 cannot find -lgcc_s
collect2: error: ld returned 1 exit status
[dizzy@dizzy-centos7 core-minimal]$

Thanks for your help in advance.

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

[yocto] Help on mono yocto build

[bing mao]

Hi Yocto,
We are going to use mono on Yocto, I followed the instructions to build
mono and found following issue. I have searched on internet, I found
similar issue reported, but didn't find helpful answer, could you share me
some light on this?

Thanks,
Bing

mono-complete has been installed on my ubuntu-16.4, ad below is my mono
version on build host.

cmaobi@ubuntu:~/poky/build$ mono --version
Mono JIT compiler version 5.14.0.177 (tarball Mon Aug  6 09:13:43 UTC 2018)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors.
www.mono-project.com
TLS:   __thread
SIGSEGV:   altstack
Notifications: epoll
Architecture:  amd64
Disabled:  none
Misc:  softdebug
Interpreter:   yes
LLVM:  yes(3.6.0svn-mono-/)
GC:sgen (concurrent by default)


==
Build Configuration:
BB_VERSION   = "1.39.1"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "i586-poky-linux"
MACHINE  = "qemux86"
DISTRO   = "poky"
DISTRO_VERSION   = "2.5+snapshot-20180920"
TUNE_FEATURES= "m32 i586"
TARGET_FPU   = ""
meta
meta-poky
meta-yocto-bsp   = "HEAD:b78597a4e038ed64b379f11257002e5a5f24886f"
meta-mono= "HEAD:05edfa6067b21e308b977a3116e07756e88ab086"
meta-oe  = "HEAD:a06c29be2f5bc204f965ee07298c34232c5c39fc"

Initialising tasks: 100%
|#|
Time: 0:00:04
Sstate summary: Wanted 22 Found 19 Missed 3 Current 2140 (86% match, 99%
complete)
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: mono-5.12.0.226-r0 do_package_qa: QA Issue:
/usr/lib/mono/4.6.2-api/Mono.Debugger.Soft.dll contained in package
mono-api-4.6.2 requires mono(Mono.Cecil), but no providers found in
RDEPENDS_mono-api-4.6.2? [file-rdeps]
ERROR: mono-5.12.0.226-r0 do_package_qa: QA Issue:
/usr/lib/mono/mono-configuration-crypto/4.5/Mono.Configuration.Crypto.dll
contained in package mono-configuration-crypto requires
mono(System.Configuration), but no providers found in
RDEPENDS_mono-configuration-crypto? [file-rdeps]
ERROR: mono-5.12.0.226-r0 do_package_qa: QA Issue:
/usr/lib/mono/mono-configuration-crypto/4.5/mono-configuration-crypto.exe
contained in package mono-configuration-crypto requires mono(System), but
no providers found in RDEPENDS_mono-configuration-crypto? [file-rdeps]
ERROR: mono-5.12.0.226-r0 do_package_qa: QA Issue:
/usr/lib/mono/mono-configuration-crypto/4.5/mono-configuration-crypto.exe
contained in package mono-configuration-crypto requires mono(mscorlib), but
no providers found in RDEPENDS_mono-configuration-crypto? [file-rdeps]
ERROR: mono-5.12.0.226-r0 do_package_qa: QA Issue:
/usr/lib/mono/mono-configuration-crypto/4.5/Mono.Configuration.Crypto.dll
contained in package mono-configuration-crypto requires
mono(Mono.Security), but no providers found in
RDEPENDS_mono-configuration-crypto? [file-rdeps]
ERROR: mono-5.12.0.226-r0 do_package_qa: QA Issue:
/usr/lib/mono/mono-configuration-crypto/4.5/Mono.Configuration.Crypto.dll
contained in package mono-configuration-crypto requires mono(System.Xml),
but no providers found in RDEPENDS_mono-configuration-crypto? [file-rdeps]
ERROR: mono-5.12.0.226-r0 do_package_qa: QA Issue:
/usr/lib/mono/4.0-api/System.Net.Http.Formatting.dll contained in package
mono-libs-4.0 requires mono(System.Net.Http), but no providers found in
RDEPENDS_mono-libs-4.0? [file-rdeps]
ERROR: mono-5.12.0.226-r0 do_package_qa: QA Issue:
/usr/lib/mono/4.0-api/Mono.Debugger.Soft.dll contained in package
mono-libs-4.0 requires mono(Mono.Cecil), but no providers found in
RDEPENDS_mono-libs-4.0? [file-rdeps]
ERROR: mono-5.12.0.226-r0 do_package_qa: QA Issue:
/usr/lib/mono/4.5/Microsoft.CodeAnalysis.Scripting.dll contained in package
mono-libs-4.5 requires mono(System.Runtime.Loader), but no providers found
in RDEPENDS_mono-libs-4.5? [file-rdeps]
ERROR: mono-5.12.0.226-r0 do_package_qa: QA Issue:
/usr/lib/mono/4.7-api/Mono.Debugger.Soft.dll contained in package
mono-api-4.7 requires mono(Mono.Cecil), but no providers found in
RDEPENDS_mono-api-4.7? [file-rdeps]
ERROR: mono-5.12.0.226-r0 do_package_qa: QA Issue:
/usr/lib/mono/3.5-api/Microsoft.Build.Engine.dll contained in package
mono-libs-3.5 requires mono(System.Xml), but no providers found in
RDEPENDS_mono-libs-3.5? [file-rdeps]
ERROR: mono-5.12.0.226-r0 do_package_qa: QA Issue:
/usr/lib/mono/3.5-api/Microsoft.Build.Tasks.v3.5.dll contained in package
mono-libs-3.5 requires mono(System), but no providers found in
RDEPENDS_mono-libs-3.5? [file-rdeps]
ERROR: mono-5.12.0.226-r0 do_package_qa: QA Issue:
/usr/lib/mono/3.5-api/Microsoft.Build.Framework.dll contained in package
mono-libs-3.5 requires mono(mscorlib), but no providers found in
RDEPENDS_mono-libs-3.5? [file-rdeps]
ERROR: mono-5.12.0.226-r0 do_package_qa: QA Issue:
/usr/lib/mono/gac/Microsoft.Build.Framework/14.0.0.0__b03f5f7f11d

Re: [yocto] HELP!

[Bas Mevissen]

On 2018-08-09 14:39, Dhanush K.S wrote:

Hello,

I am currently trying to migrate from Yocto 1.8 Poky Fido 13.0.0 to
Yocto 2.5.

After cloning the Poky repository, I was confused with which tag to
checkout with.



With a fresh release like Sumo, it is better to stay at the HEAD of the 
sumo branch for some time. Updates here should not break things, but fix 
bugs instead.
When it stabilizes or when you are making a release, you can use a 
certain commit or release tag.



Could you please help me understand the difference between the tags
"SUMO-19.0.0" and "YOCTO-2.5"



Both tags point to the same commit (da3625c52e), so choose one.


As far as I understand, both mean the same since "2.5" is the
DISTRO_VERSION and "sumo" is the DISTRO_CODENAME.

But is still the same with the checkout tags as well?

Many thanks in advance!

Mit freundlichen Grüßen / Best Regards,
Dhanush Keshava Reddy Soppahalli
Mob: +4915216144064


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

Re: [yocto] HELP!

[Alexander Kanavin]

You don't need to check out a specific tag. Just switch to the latest
commit in the branch you want (e.g. sumo).

Alex

2018-08-09 14:39 GMT+02:00 Dhanush K.S :
> Hello,
>
> I am currently trying to migrate from Yocto 1.8 Poky Fido 13.0.0 to Yocto
> 2.5.
>
> After cloning the Poky repository, I was confused with which tag to checkout
> with.
>
> Could you please help me understand the difference between the tags
> "sumo-19.0.0" and "yocto-2.5"
>
> As far as I understand, both mean the same since "2.5" is the DISTRO_VERSION
> and "sumo" is the DISTRO_CODENAME.
>
> But is still the same with the checkout tags as well?
>
> Many thanks in advance!
>
> Mit freundlichen Grüßen / Best Regards,
> Dhanush Keshava Reddy Soppahalli
> Mob: +4915216144064
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] HELP!

[Dhanush K.S]

Hello,

I am currently trying to migrate from Yocto 1.8 Poky Fido 13.0.0 to Yocto
2.5.

After cloning the Poky repository, I was confused with which tag to
checkout with.

Could you please help me understand the difference between the tags
*"sumo-19.0.0"
*and *"yocto-2.5"*

As far as I understand, both mean the same since "2.5" is the
DISTRO_VERSION and "sumo" is the DISTRO_CODENAME.

But is still the same with the checkout tags as well?

Many thanks in advance!

Mit freundlichen Grüßen / Best Regards,
Dhanush Keshava Reddy Soppahalli
Mob: +4915216144064
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] HELP: Release Candidate Build for yocto-2.4.3.rc2 now available.

[Richard Purdie]

Hi David,

On Tue, 2018-05-29 at 03:36 +, Reyna, David wrote:
> I apologize for sending this patch for Toaster for Roco 2.4.3 very
> late. I have been focused on Sumo and I thought I had more time.
> 
> The Toaster for Rocko is broken on HEAD. There are two patches that
> made it into master and Sumo, but missed Rocko.
> 
> I have just now sent the missing patch set to "bitbake-dev". The
> first patch fixes an error that breaks the initialization of Toaster.
> The second patches fixes a change in behavior for Django that creates
> an extra thread that blocks Toaster from shutting down.
> 
> Please accept these patches for Rocko. They are confined to Toaster
> and do not affect the rest of the release.

I've added the patches onto the rocko/2.36 branches but 2.4.3 is
already in QA now so we'd have to break process to add those in
potentially untested or go to an rc3.

At least they will be on the branch ready for update for anyone that
runs into the issue and we can release note. Lets see what else (if
anything) is found in rc2...

Cheers,

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

[yocto] HELP: Release Candidate Build for yocto-2.4.3.rc2 now available.

[Reyna, David]

Hi Richard,

I apologize for sending this patch for Toaster for Roco 2.4.3 very late. I have 
been focused on Sumo and I thought I had more time.

The Toaster for Rocko is broken on HEAD. There are two patches that made it 
into master and Sumo, but missed Rocko.

I have just now sent the missing patch set to "bitbake-dev". The first patch 
fixes an error that breaks the initialization of Toaster. The second patches 
fixes a change in behavior for Django that creates an extra thread that blocks 
Toaster from shutting down.

Please accept these patches for Rocko. They are confined to Toaster and do not 
affect the rest of the release.

Thanks,
David


-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Richard Purdie
Sent: Thursday, May 24, 2018 1:16 AM
To: yocto
Cc: ota...@ossystems.com.br; CHAN, AARON CHUN YEW
Subject: [yocto] Release Candidate Build for yocto-2.4.3.rc2 now available.

A release candidate build for yocto-2.4.3.rc2 is now available at:


https://autobuilder.yocto.io/pub/releases/yocto-2.4.3.rc2


Please begin QA on this build as soon as possible.


Build hash information: 
meta-intel : f66ce51d059d291a441d896854be8db70de5a554 
meta-qt4 : e290738759ef3f39c9e079eaa9b606a62107e5ba 
meta-mingw : 1cc620b38f6f30a0bdd181783297998fe073387f 
meta-qt3 : 8ef7261a331e0869a0461ab2fb44e39980cedc02 
meta-gplv2 : f875c60ecd6f30793b80a431a2423c4b98e51548 
poky : 7e7ee662f5dea4d090293045f7498093322802cc 

This is an automated message from The Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder
-- 
___
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] Help with Bitbake: (bitbake-layers show-recipes)

[Zoran Stojsavljevic]

H... I called my best friend www.google.com to the help, since it seems
to me that you are trying to do Docker, and that you need to set your
kernel differently then it is done by default.

The link I found: definitely worth trying/reading. At least, I should say.

In the book: Embedded Linux Development Using Yocto Project Cookbook:
Practical recipes (Second Edition) By Alex González it says (pages 338 and
339):

Yocto Cookbook page 339


Please, go to the page 339 and read carefully both 338 and 339 pages.

Please, let us all know if this helps! ;-)

Zoran
___

On Mon, Apr 30, 2018 at 6:18 PM, Luis Martins 
wrote:

> Good afternoon,
>
> The path that lead me to bitbake's recipe building is going to be
> presented next, if the setup isn't important the warnings and errors are
> highlited in green and you can skip it to there.
>
> Similar to this thread
> ,
> i'm having some hard time building the openembedded filesystem.
> So far I have managed to follow this tutorial
>  until the
> "Booting the board" section. After running the board some errors appear
> during the execution:
>
> [image: Inline image OWAPstImg945310]
> [image: Inline image OWAPstImg953070]
>
> This lead me to follow the *"Addendum B: Building the OpenEmbedded
> filesysytem from source" *
> (I thought this part was optional since in this section "Initialising a
> workspace" it says "The script will guide you through the process of
> initialising your workspace, automatically downloading all relevant source
> files and required binaries.")
>
> I executed this commands with no problems:
>
> */* Create workspace */*
>
> */* WARNING: Do *not* create this as a subdirectory of the main Linaro Arm
> Platforms workspace created by `workspace_yy.mm '
> above */*
>
> *$ mkdir openembedded*
>
> *$ cd openembedded*
>
> *$ export OE_HOME=`pwd`*
>
> *$ git clone git://git.linaro.org/openembedded/jenkins-setup.git
> *
>
> *$ cd $OE_HOME/jenkins-setup*
>
> *$ git checkout release-YY.MM*
>
> *$ cd $OE_HOME*
>
> *$ sudo jenkins-setup/pre-build-root-install-dependencies.sh*
>
> *$ jenkins-setup/init-and-build.sh*
>
> *$ cd $OE_HOME/openembedded-core*
>
> *$ ./oe-init-build-env*
>
> */* Add bitbake to your $PATH */*
>
> *$ export PATH=$OE_HOME/openembedded-core/bi**tbake/bin:$PATH*
>
>
> But, after running this commands:
>
> *$ cd $OE_HOME/build*
>
> *$ bitbake-layers show-recip**es*
>
>
> I get the following Warnings and Errors (from the log file located in the
> directory /Desktop/openembedded/build/tmp-glibc/log/cooker)):
>
> *WARNING:
> /home/lfpm1993/Desktop/openembedded/meta-linaro/meta-ilp32/recipes-overlayed/glibc/glibc_2.26.bb
> : Exception during build_dependencies for do_install*
>
> *WARNING:
> /home/lfpm1993/Desktop/openembedded/meta-linaro/meta-ilp32/recipes-overlayed/glibc/glibc_2.26.bb
> : Error during finalise of
> /home/lfpm1993/Desktop/openembedded/meta-linaro/meta-ilp32/recipes-overlayed/glibc/glibc_2.26.bb
> *
>
> *WARNING:
> /home/lfpm1993/Desktop/openembedded/meta-linaro/meta-ilp32/recipes-overlayed/glibc/glibc-initial_2.26.bb
> : Exception during build_dependencies for
> do_install*
>
> *WARNING:
> /home/lfpm1993/Desktop/openembedded/meta-linaro/meta-ilp32/recipes-overlayed/glibc/glibc-initial_2.26.bb
> : Error during finalise of
> /home/lfpm1993/Desktop/openembedded/meta-linaro/meta-ilp32/recipes-overlayed/glibc/glibc-initial_2.26.bb
> *
>
> *ERROR: ExpansionError during parsing
> /home/lfpm1993/Desktop/openembedded/meta-linaro/meta-ilp32/recipes-overlayed/glibc/glibc_2.26.bb
> *
>
> *Traceback (most recent call last):*
>
> *bb.data_smart.ExpansionError: Failure expanding variable do_install,
> expression wasoe_runmake
> install_root=/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/image
> install*
>
> *for r in bootparam_prot.x nlm_prot.x rstat.x
>  yppasswd.x klm_prot.x rex.x sm_inter.x mount.x   rusers.x spray.x
> nfs_prot.x rquota.x key_prot.x; do*
>
> *h=`echo $r|sed -e's,\.x$,.h,'`*
>
> *install -m 0644
> /home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/git/sunrpc/rpcsvc/$h
> /home/lfpm1993/Desktop/openembedded/b

Re: [yocto] Help with Bitbake: (bitbake-layers show-recipes)

[Trevor Woerner]

*$ git clone git://git.linaro.org/openembedded/jenkins-setup.git
*

Since the repository from which you're working comes from Linaro, maybe
you'll have better luck getting support from their mailing list?
openembedded-c...@lists.openembedded.org
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Help with Bitbake: (bitbake-layers show-recipes)

[Luis Martins]

Good afternoon,

The path that lead me to bitbake's recipe building is going to be presented 
next, if the setup isn't important the warnings and errors are highlited in 
green and you can skip it to there.

Similar to this 
thread,
 i'm having some hard time building the openembedded filesystem.
So far I have managed to follow this 
tutorial until the 
"Booting the board" section. After running the board some errors appear during 
the execution:

[Inline image OWAPstImg945310]
[Inline image OWAPstImg953070]

This lead me to follow the "Addendum B: Building the OpenEmbedded filesysytem 
from source"
(I thought this part was optional since in this section "Initialising a 
workspace" it says "The script will guide you through the process of 
initialising your workspace, automatically downloading all relevant source 
files and required binaries.")

I executed this commands with no problems:


/* Create workspace */

/* WARNING: Do *not* create this as a subdirectory of the main Linaro Arm 
Platforms workspace created by `workspace_yy.mm' above */

$ mkdir openembedded

$ cd openembedded

$ export OE_HOME=`pwd`

$ git clone git://git.linaro.org/openembedded/jenkins-setup.git

$ cd $OE_HOME/jenkins-setup

$ git checkout release-YY.MM

$ cd $OE_HOME

$ sudo jenkins-setup/pre-build-root-install-dependencies.sh

$ jenkins-setup/init-and-build.sh

$ cd $OE_HOME/openembedded-core

$ ./oe-init-build-env

/* Add bitbake to your $PATH */

$ export PATH=$OE_HOME/openembedded-core/bitbake/bin:$PATH

But, after running this commands:


$ cd $OE_HOME/build

$ bitbake-layers show-recipes

I get the following Warnings and Errors (from the log file located in the 
directory /Desktop/openembedded/build/tmp-glibc/log/cooker)):


WARNING: 
/home/lfpm1993/Desktop/openembedded/meta-linaro/meta-ilp32/recipes-overlayed/glibc/glibc_2.26.bb:
 Exception during build_dependencies for do_install

WARNING: 
/home/lfpm1993/Desktop/openembedded/meta-linaro/meta-ilp32/recipes-overlayed/glibc/glibc_2.26.bb:
 Error during finalise of 
/home/lfpm1993/Desktop/openembedded/meta-linaro/meta-ilp32/recipes-overlayed/glibc/glibc_2.26.bb

WARNING: 
/home/lfpm1993/Desktop/openembedded/meta-linaro/meta-ilp32/recipes-overlayed/glibc/glibc-initial_2.26.bb:
 Exception during build_dependencies for do_install

WARNING: 
/home/lfpm1993/Desktop/openembedded/meta-linaro/meta-ilp32/recipes-overlayed/glibc/glibc-initial_2.26.bb:
 Error during finalise of 
/home/lfpm1993/Desktop/openembedded/meta-linaro/meta-ilp32/recipes-overlayed/glibc/glibc-initial_2.26.bb

ERROR: ExpansionError during parsing 
/home/lfpm1993/Desktop/openembedded/meta-linaro/meta-ilp32/recipes-overlayed/glibc/glibc_2.26.bb

Traceback (most recent call last):

bb.data_smart.ExpansionError: Failure expanding variable do_install, expression 
wasoe_runmake 
install_root=/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/image
 install

for r in bootparam_prot.x nlm_prot.x rstat.x   yppasswd.x 
klm_prot.x rex.x sm_inter.x mount.x   rusers.x spray.x nfs_prot.x 
rquota.x key_prot.x; do

h=`echo $r|sed -e's,\.x$,.h,'`

install -m 0644 
/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/git/sunrpc/rpcsvc/$h
 
/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/image//usr/include/rpcsvc/

done

install -Dm 0644 
/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/etc/ld.so.conf
 
/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/image//etc/ld.so.conf

install -d 
/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/image/usr/lib/locale

make -f 
/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/generate-supported.mk
 
IN="/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/git/localedata/SUPPORTED"
 
OUT="/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/SUPPORTED"

# get rid of some broken files...

for i in ; do

sed -i "/$i/d" 
/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/SUPPORTED

done

rm -f 
/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/image/etc/rpc

rm -rf 
/home/lfpm1993/Desktop/openembedded/build/tmp-glibc/work/aarch64-oe-linux/glibc/2.26-r0/image/usr/share/zoneinfo

rm -rf 
/home/lfpm1993/Desktop/openembedded

[yocto] Help Compiling vlc for i.MX6 SABRE-SD

[victor_wang.Winmate]

Hi,

 

I am new in Yocto, I have to admit it, please be patient with my stupid 
questions.

I built vlc on meta-fsl-arm layers and fsl-imx-x11 distro on machine 
imx6dlsabresd.

I used commend `bitbake vlc` to build it and will get errors like bellow link.

 

https://gist.github.com/victorwangwinmate/3fb03f42a47f3405b5aef05c3ac47bdc

 

After some googling, I try to modify my local.conf like bellow link.

 

https://gist.github.com/victorwangwinmate/3593c1c63cf96a0d44537a24cc6d17c5

 

And I try to build the image with this commend `bitbake –C compile 
fsl-image-gui `

Unfortunately, I will get the same error as the first link.

 

The first question is why it will show the error that one of 
libjpeg-turbo_8d+1.4.1.bb and jpeg_9a.bb is missing something.

The second is which one I should use and how?

The third is how can I fix this error in the proper way?

 

Please help

 

Thanks in advance

Best Regards

Victor Wang

=

Winmate Commuication INC.

  Tel:+886-2-8511-0288 ext 878; Fax:+886-2-85110211

✉   victor_w...@winmate.com.tw

 

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

[yocto] Help With TEMPLATECONF & Automated Continuous Integration (CI)

[Thomas A. F. Thorne MEng AUS MIET]

Good morning,

I am trying to setup an automate Jenkins CI server to build an image. 
To do this I need to automate the process of setting up the Yocto work
area completely.  As part of this process I am trying to eliminate the
use of or automate the production of local.conf and bblayers.conf
files.  It is working out how to deal with the selection of layers to
include that I am having difficulty with right now. 

_TEMPLATECONF_
In the documentation I have found a reference to the .templateconf file
which can be edited to set the TEMPLATECONF variable to point at a set
of templates for the local.conf and bblayers.conf files.  I suppose I
could somehow overwrite any existing .templateconf file with my own
version copied from somewhere but that seems a little messy when all the
other files are checked out of source control and manipulated only via
bitbake.  I wonder if a TEMPLATECONF environment variable would be
picked up as that would feel a little tidier to me, I shall experiment
after lunch. 

_What I Have Working_
The top level work area is formed using the Gerrit Repo tool.  This
gives me the basic set of core layers and my proprietary layer
(imaginatively named meta-net2edge).  Jenkins is able to operate repo as
it can other SCM options. 

I think I have eliminated the need to a hand crafted local.conf file
already.  I have a proprietary Yocto Board Support Package (BSP) a
costume Image Class and a set of packagegroups added to image using
IMAGE_INSTALL.  With the target MACHINE set using an environment
variable on the call to `source oe-init-build-env` there is no need to
hand craft the local.conf. 

_General Questions_
I also feel like I may have missed some documentation or instruction
that discusses going from prototyping in local.conf and bblayers.conf to
a more formal production system that minimises their use.  The
documentation for creating BSPs is good.  The documentation for creating
distributions and feature packages is a little weak in places.  Maybe I
am wrongly expecting structure where Yocto tries to be flexible. 
Am I just overcomplicating things by trying to minimise the work any one
user or machine needs to do besides checking out the work area with repo? 
How do other people perform CI or continuous delivery for their Yocto
targets?

Any help or advice would be most gratefully received. 

Regards,

-- 
Thomas A. F. Thorne MEng. AUS MIET
*Software Engineer*

*NET2EDGE*

Tel: +44 3450 130 030 
Email: thomas.tho...@net2edge.com 
Web: http://www.Net2Edge.com/ 

Net2Edge Limited is a company registered in England & Wales (Company No.
2438435, VAT No. GB 537553821) Kulite House, Stroudley Road, Basingstoke
RG24 8UG. This email transmission is confidential and intended solely
for the person or organisation to whom it is addressed (i.e. the Yocto
public community mailgroupin this case). If you are not the intended
recipient, you must not copy, distribute or disseminate the information,
or take any action in reliance of it. Any views expressed in this
message are those of the individual sender, except where the sender
specifically states them to be the views of any organisation or
employer. If you have received this message in error, do not open any
attachment but please notify the sender (above) and delete this message
from your system. Please rely on your own virus check. Although all
outbound mail is checked for viruses, no responsibility is taken by the
sender for any damage rising out of any bug or virus infection.



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

Re: [yocto] help

[Suneetha Lakshmi G]

Hi Khem,


Sorry for late response .

While building Kernel 4.1.17 with gcc 4.9.4 we are using gcc as a External 
toolchain (asdk-4.9.4-a7-EL-3.10-g2.19-a32nt-160219)


Regards,

Suneetha


From: Khem Raj 
Sent: Friday, March 10, 2017 11:45:23 PM
To: Suneetha Lakshmi G
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] help



On Fri, Mar 10, 2017 at 6:25 AM, Suneetha Lakshmi G 
mailto:suneeth...@tataelxsi.co.in>> wrote:

Hi All,


Im new to yocto and trying to build for my customer device im facing this issue.


| arm-linux-gnueabi-xgcc: error: unrecognized command line option 
'-mgeneral-regs-only'
| arm-linux-gnueabi-xgcc: error: unrecognized command line option 
'-mcmodel=large'
| make: *** [opkg-compare-versions] Error 1
| ERROR: oe_runmake failed

Please guide how to progress further.


​xgcc is internal name during building/testing gcc itself, which package it 
failing like this for you ?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] help

[Schmitt, Richard]

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Suneetha Lakshmi G
Sent: Friday, March 10, 2017 8:25 AM
To: yocto@yoctoproject.org
Subject: Re: [yocto] help


Hi All,



Im new to yocto and trying to build for my customer device im facing this issue.


| arm-linux-gnueabi-xgcc: error: unrecognized command line option 
'-mgeneral-regs-only'
| arm-linux-gnueabi-xgcc: error: unrecognized command line option 
'-mcmodel=large'
| make: *** [opkg-compare-versions] Error 1
| ERROR: oe_runmake failed

Please guide how to progress further.

[ras] please provide what target you are building from, where you got your 
yocto layers from, what bitbake command you are using.  My WAG is that your 
toolchain is misconfigured, possible because you haven't specified a MACHINE 
variable.

Regards,
Suneetha



From: yocto-boun...@yoctoproject.org<mailto:yocto-boun...@yoctoproject.org> 
mailto:yocto-boun...@yoctoproject.org>> on 
behalf of yocto-requ...@yoctoproject.org<mailto:yocto-requ...@yoctoproject.org> 
mailto:yocto-requ...@yoctoproject.org>>
Sent: Friday, March 10, 2017 7:20 PM
To: yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
Subject: yocto Digest, Vol 78, Issue 45

Send yocto mailing list submissions to
yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.yoctoproject.org/listinfo/yocto
or, via email, send a message with subject or body 'help' to
yocto-requ...@yoctoproject.org<mailto:yocto-requ...@yoctoproject.org>

You can reach the person managing the list at
yocto-ow...@yoctoproject.org<mailto:yocto-ow...@yoctoproject.org>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of yocto digest..."


Today's Topics:

   1. Re: Raspberry Pi2 Fails to boot into LXDE. (Steve Plant)
   2. Re: update mechanisms (Kristian Amlie)
   3. Proposal: dealing with language-specific build
  tools/dependency management tools (Alexander Kanavin)


--

Message: 1
Date: Fri, 10 Mar 2017 13:31:40 +
From: Steve Plant mailto:ste...@hotmail.com>>
To: Gary Thomas mailto:g...@mlbassoc.com>>
Cc: "yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>" 
mailto:yocto@yoctoproject.org>>
Subject: Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.
Message-ID:

mailto:sg2pr0301mb20164f99a2af83afc01ecdcfd1...@sg2pr0301mb2016.apcprd03.prod.outlook.com>>

Content-Type: text/plain; charset="iso-8859-1"

Thanks Gary,


You where spot on! I have now been able to SSH into the rpi and have posted the 
Xorg.log file to the mailing list.


I think Xorg is failing to load correctly because it cannot find the evdev 
module. Looking into how to fix this now..


Regards, Steve.



From: yocto-boun...@yoctoproject.org<mailto:yocto-boun...@yoctoproject.org> 
mailto:yocto-boun...@yoctoproject.org>> on 
behalf of Gary Thomas mailto:g...@mlbassoc.com>>
Sent: Friday, 10 March 2017 5:42 a.m.
To: yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
Subject: Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.

On 2017-03-10 01:55, Steve Plant wrote:
> OK, I have spent the last day googling my heart out trying to find the 
> Xorg.log file without any luck.
>
>
> The problem is that due to the rpi hanging on boot, the only way I can access 
> the SD card to look for the file is place
> it in a USB SD card reader and use my VirtualBox based Debian to "ls" 
> directores etc.
>
> Having established that there is no file located at /var/log/Xorg.log (there 
> isn't a log directory) but there is a
> symbolic link in the var directory - goes nowhere.
>
>
> After goggling I discovered that the file could also be in the 
> ~/.local/share/xorg/Xorg.0.log, however if I try to look
> there I get "permission denied" and cannot seem to get to the root directory 
> of the card and I can't find a way around
> this as I'm trying to access this directory through the USB card reader.
>
>
> Looked everywhere with no answers, Is there anyone who could help me here??

/var/log is on a volatile file system (i.e. it does not live on the SD card)

If you can get into your board via SSH, you can copy the file and send it

> 
> *From:* Khem Raj mailto:raj.k...@gmail.com>>
> *Sent:* Wednesday, 8 March 2017 5:17 p.m.
> *To:* Steve Plant
> *Cc:* yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
> *Subject:* Re: [yocto] Raspberry Pi2 Fails to boo

Re: [yocto] help

[Khem Raj]

On Fri, Mar 10, 2017 at 6:25 AM, Suneetha Lakshmi G <
suneeth...@tataelxsi.co.in> wrote:

> Hi All,
>
>
> Im new to yocto and trying to build for my customer device im facing this
> issue.
>
>
> | arm-linux-gnueabi-xgcc: error: unrecognized command line option
> '-mgeneral-regs-only'
> | arm-linux-gnueabi-xgcc: error: unrecognized command line option
> '-mcmodel=large'
> | make: *** [opkg-compare-versions] Error 1
> | ERROR: oe_runmake failed
>
> Please guide how to progress further.
>
>
​xgcc is internal name during building/testing gcc itself, which package it
failing like this for you ?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] help

[Suneetha Lakshmi G]

Hi All,


Im new to yocto and trying to build for my customer device im facing this issue.


| arm-linux-gnueabi-xgcc: error: unrecognized command line option 
'-mgeneral-regs-only'
| arm-linux-gnueabi-xgcc: error: unrecognized command line option 
'-mcmodel=large'
| make: *** [opkg-compare-versions] Error 1
| ERROR: oe_runmake failed

Please guide how to progress further.

Regards,
Suneetha





From: yocto-boun...@yoctoproject.org  on behalf 
of yocto-requ...@yoctoproject.org 
Sent: Friday, March 10, 2017 7:20 PM
To: yocto@yoctoproject.org
Subject: yocto Digest, Vol 78, Issue 45

Send yocto mailing list submissions to
yocto@yoctoproject.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.yoctoproject.org/listinfo/yocto
or, via email, send a message with subject or body 'help' to
yocto-requ...@yoctoproject.org

You can reach the person managing the list at
yocto-ow...@yoctoproject.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of yocto digest..."


Today's Topics:

   1. Re: Raspberry Pi2 Fails to boot into LXDE. (Steve Plant)
   2. Re: update mechanisms (Kristian Amlie)
   3. Proposal: dealing with language-specific build
  tools/dependency management tools (Alexander Kanavin)


--

Message: 1
Date: Fri, 10 Mar 2017 13:31:40 +
From: Steve Plant 
To: Gary Thomas 
Cc: "yocto@yoctoproject.org" 
Subject: Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.
Message-ID:



Content-Type: text/plain; charset="iso-8859-1"

Thanks Gary,


You where spot on! I have now been able to SSH into the rpi and have posted the 
Xorg.log file to the mailing list.


I think Xorg is failing to load correctly because it cannot find the evdev 
module. Looking into how to fix this now..


Regards, Steve.



From: yocto-boun...@yoctoproject.org  on behalf 
of Gary Thomas 
Sent: Friday, 10 March 2017 5:42 a.m.
To: yocto@yoctoproject.org
Subject: Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.

On 2017-03-10 01:55, Steve Plant wrote:
> OK, I have spent the last day googling my heart out trying to find the 
> Xorg.log file without any luck.
>
>
> The problem is that due to the rpi hanging on boot, the only way I can access 
> the SD card to look for the file is place
> it in a USB SD card reader and use my VirtualBox based Debian to "ls" 
> directores etc.
>
> Having established that there is no file located at /var/log/Xorg.log (there 
> isn't a log directory) but there is a
> symbolic link in the var directory - goes nowhere.
>
>
> After goggling I discovered that the file could also be in the 
> ~/.local/share/xorg/Xorg.0.log, however if I try to look
> there I get "permission denied" and cannot seem to get to the root directory 
> of the card and I can't find a way around
> this as I'm trying to access this directory through the USB card reader.
>
>
> Looked everywhere with no answers, Is there anyone who could help me here??

/var/log is on a volatile file system (i.e. it does not live on the SD card)

If you can get into your board via SSH, you can copy the file and send it

> 
> *From:* Khem Raj 
> *Sent:* Wednesday, 8 March 2017 5:17 p.m.
> *To:* Steve Plant
> *Cc:* yocto@yoctoproject.org
> *Subject:* Re: [yocto] Raspberry Pi2 Fails to boot into LXDE.
>
> On 17-03-08 12:40:51, Steve Plant wrote:
>> Hi All,
>>
>>
>> Very new to all this linux world, and especially Yocto.
>>
>>
>> I'm working on a embedded project at the moment using a raspberry pi2 board.
>>
>>
>> I have used toaster with Morty 2.2 to compile an image 
>> using"rpi-basic-image", to this I have added the following bitbake variables:
>>
>> Bitbake variables
>>
>> DISTRO
>> poky
>> DL_DIR
>> /home/steve/poky/downloads
>> IMAGE_FSTYPES
>> ext3 jffs2 tar.bz2 rpi-sdimg
>> IMAGE_INSTALL_append
>> packagegroup-core-x11-base packagegroup-lxde-base connman
>> PACKAGE_CLASSES
>> package_rpm
>> SSTATE_DIR
>> /home/steve/poky/sstate-cache
>>
>> DISABLE_OVERSCAN
>> 1
>> GPU_MEM_1024
>> 512
>>
>> I have dd'ed the image to an SD card increased the sdb2 partition to the max 
>> size and powered up the rpi. Everything looks fine to start with, as it 
>> displays the four raspberrys in the top left, then the white "Yocto Project" 
>> splash screen complete with small blue dot to the side appears, the progress 
>> bar moves across to 100 percent, then the screen turns black with a white
> cursor in the middle and it appears to freeze with only a very dim one second 
> flash of the "act" led.
>>
>>
>> I have then connected the 7" touchscreen and apart from the added 
>> multicolored square at the very beginning I get the exact same boot up 
>> problem, hangs on the black screen with white cursor (good to see its 

Re: [yocto] help

[Robert P. J. Day]

On Fri, 10 Mar 2017, Suneetha Lakshmi G wrote:

> Hi All,
>
> Im new to yocto and trying to build for my customer device im facing
> this issue.

  first advice is to use meaningful subject lines ... simply yelling
"help" is a good way to get people to not take you seriously right
from the beginning.

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] Help with out of (python) tree python modules in SDK

[Burton, Ross]

On 4 November 2016 at 18:55, Brad Bishop 
wrote:

> I am on Krogoth.  I have an autotools inheriting recipe.  The configure
> script runs a python script (in repo), that imports an out-of-python-distro
> module.
>
> I can’t seem to wrap my head around the correct way to express this in
> terms of dependencies, such that when I build with an SDK, I can import
> this module.
>

Put this in your image recipe that the SDK is generated from.

TOOLCHAIN_HOST_TASK_append = " nativesdk-python-foomodule"

TOOLCHAIN_HOST_TASK is the variable that list everything to be installed in
the SDK that is for the *host*, not the *target*.

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

[yocto] Help with out of (python) tree python modules in SDK

[Brad Bishop]

I am on Krogoth.  I have an autotools inheriting recipe.  The configure script 
runs a python script (in repo), that imports an out-of-python-distro module.

I can’t seem to wrap my head around the correct way to express this in terms of 
dependencies, such that when I build with an SDK, I can import this module.

What does seem to work is adding nativesdk-python-foomodule to 
RRECOMMENDS_python-core_append_class-nativesdk in the python recipe.  Is there 
a better way?

My intuition says that:

DEPENDS += “python-foomodule-native” 

translated to words means: to build this package, you need 
python-foomodule-native.  And given that the target -dev packages get included 
in the SDK when you do this…the same doesn’t appear to be the case for python 
modules?

I feel like I am missing a fundamental concept.

Thx for your time.

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

Re: [yocto] Help with DISTRO settings

[Khem Raj]

> On Jul 25, 2016, at 10:00 PM, Paul Eggleton  
> wrote:
> 
> On Mon, 25 Jul 2016 20:34:32 Khem Raj wrote:
>>> On Jul 25, 2016, at 8:31 PM, Edward Wingate  wrote:
>>> 
>>> On Mon, Jul 25, 2016 at 1:27 AM, Nicolas Dechesne
>>> 
>>>  wrote:
 hmm. you shouldn't set DISTRO in conf/layer.conf, that doesn't sound
 right. DISTRO needs to be set in local.conf (or any of the other build
 specific conf files).
>>> 
>>> I agree, I don't know why I had it in conf/layer.conf.  Just
>>> beginner's mistake.
>>> 
>>> I moved DISTRO to local.conf (changed the existing DISTRO ?= "poky" to
>>> DISTRO ?= "mydistro") and it still works.  But if I remove DISTRO from
>>> conf/distro/mydistro.conf, DISTRO will revert to "poky", even though
>>> it is set to my "mydistro" in local.conf.  So it seems I have to have
>>> it in both places.
>> 
>> in your mydistro.conf you should first set the settings that you want to
>> customize then include conf/distro/poky.conf not other way around. May be
>> we should change poky.conf to use ??= so the substitution happens at the
>> end of parsing. but thats for another time.
> 
> I'm clearly missing something - why must it be done that way around? If you
> were to set the values you want *after* the include/require then that should
> work just fine, and would be the way I would recommend doing it - it's also
> the way poky-lsb distro does it.
> 
> One thing to note is that poky.conf itself sets DISTRO, mostly for historical
> reasons I believe. Thus if you do include/require poky.conf then you may wish
> to set DISTRO back to whatever it should be and you'd have to do that after
> the include/require, not before it.

Those are valid assertions. However user is changing DISTRO ?= “poky”
which will take effect if DISTRO is unset before above is parsed.

> 
> Another thing to consider is that any _poky overrides will only be applied if
> DISTRO = "poky", thus include/require of poky.conf won't incorporate those
> into your custom distro. You can set DISTROOVERRIDES to include "poky" to
> counter this. In practice though there aren't too many of these - in fact I
> can only see one in the psplash recipe.
> 
> Cheers,
> Paul
> 
> --
> 
> Paul Eggleton
> Intel Open Source Technology Centre



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Help with DISTRO settings

[Paul Eggleton]

On Mon, 25 Jul 2016 20:34:32 Khem Raj wrote:
> > On Jul 25, 2016, at 8:31 PM, Edward Wingate  wrote:
> > 
> > On Mon, Jul 25, 2016 at 1:27 AM, Nicolas Dechesne
> > 
> >  wrote:
> >> hmm. you shouldn't set DISTRO in conf/layer.conf, that doesn't sound
> >> right. DISTRO needs to be set in local.conf (or any of the other build
> >> specific conf files).
> > 
> > I agree, I don't know why I had it in conf/layer.conf.  Just
> > beginner's mistake.
> > 
> > I moved DISTRO to local.conf (changed the existing DISTRO ?= "poky" to
> > DISTRO ?= "mydistro") and it still works.  But if I remove DISTRO from
> > conf/distro/mydistro.conf, DISTRO will revert to "poky", even though
> > it is set to my "mydistro" in local.conf.  So it seems I have to have
> > it in both places.
> 
> in your mydistro.conf you should first set the settings that you want to
> customize then include conf/distro/poky.conf not other way around. May be
> we should change poky.conf to use ??= so the substitution happens at the
> end of parsing. but thats for another time.

I'm clearly missing something - why must it be done that way around? If you 
were to set the values you want *after* the include/require then that should 
work just fine, and would be the way I would recommend doing it - it's also 
the way poky-lsb distro does it.

One thing to note is that poky.conf itself sets DISTRO, mostly for historical 
reasons I believe. Thus if you do include/require poky.conf then you may wish 
to set DISTRO back to whatever it should be and you'd have to do that after 
the include/require, not before it.

Another thing to consider is that any _poky overrides will only be applied if 
DISTRO = "poky", thus include/require of poky.conf won't incorporate those 
into your custom distro. You can set DISTROOVERRIDES to include "poky" to 
counter this. In practice though there aren't too many of these - in fact I 
can only see one in the psplash recipe.

Cheers,
Paul

-- 

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

Re: [yocto] Help with DISTRO settings

[Khem Raj]

> On Jul 25, 2016, at 8:31 PM, Edward Wingate  wrote:
> 
> On Mon, Jul 25, 2016 at 1:27 AM, Nicolas Dechesne
>  wrote:
>> hmm. you shouldn't set DISTRO in conf/layer.conf, that doesn't sound
>> right. DISTRO needs to be set in local.conf (or any of the other build
>> specific conf files).
> 
> I agree, I don't know why I had it in conf/layer.conf.  Just
> beginner's mistake.
> 
> I moved DISTRO to local.conf (changed the existing DISTRO ?= "poky" to
> DISTRO ?= "mydistro") and it still works.  But if I remove DISTRO from
> conf/distro/mydistro.conf, DISTRO will revert to "poky", even though
> it is set to my "mydistro" in local.conf.  So it seems I have to have
> it in both places.

in your mydistro.conf you should first set the settings that you want to 
customize
then include conf/distro/poky.conf not other way around. May be we should 
change poky.conf
to use ??= so the substitution happens at the end of parsing. but thats for 
another time.


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Help with DISTRO settings

[Edward Wingate]

On Mon, Jul 25, 2016 at 1:27 AM, Nicolas Dechesne
 wrote:
> hmm. you shouldn't set DISTRO in conf/layer.conf, that doesn't sound
> right. DISTRO needs to be set in local.conf (or any of the other build
> specific conf files).

I agree, I don't know why I had it in conf/layer.conf.  Just
beginner's mistake.

I moved DISTRO to local.conf (changed the existing DISTRO ?= "poky" to
DISTRO ?= "mydistro") and it still works.  But if I remove DISTRO from
conf/distro/mydistro.conf, DISTRO will revert to "poky", even though
it is set to my "mydistro" in local.conf.  So it seems I have to have
it in both places.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Help with DISTRO settings

[Nicolas Dechesne]

On Mon, Jul 25, 2016 at 9:13 AM, Edward Wingate  wrote:
>> Just conf/distro/mydistro.conf is needed.
>
> Well, it didn't work if it is only in conf/distro/mydistro.conf.  I
> had to have it in conf/layer.conf as well.

hmm. you shouldn't set DISTRO in conf/layer.conf, that doesn't sound
right. DISTRO needs to be set in local.conf (or any of the other build
specific conf files). DISTRO is then used by bitbake.conf file which
does :

include conf/distro/${DISTRO}.conf

this is how your DISTRO config file gets used in the build configuration.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Help with DISTRO settings

[Edward Wingate]

On Sun, Jul 24, 2016 at 7:38 AM, Khem Raj  wrote:
> On Sun, Jul 24, 2016 at 12:34 AM, Edward Wingate  wrote:
>> Ah, I found it.  I had inadvertently deleted one line
>> (DISTRO="mydistro") from my layer's conf/layer.conf.
>>
>> Am I doing this right though?  Do I need DISTRO="mydistro" in both
>> conf/layer.conf and conf/distro/mydistro.conf?
>
> Just conf/distro/mydistro.conf is needed.

Well, it didn't work if it is only in conf/distro/mydistro.conf.  I
had to have it in conf/layer.conf as well.

>>  Removing it from
>> either doesn't work, but it seems redundant to put it in mydistro.conf
>> as well.
>
> did you make any other changes ?

Not that I know of.  It stopped working when it was mistakenly removed
from conf/layer.conf.  Started working again when I put it back in.
And just to test it, I removed it from conf/distro/mydistro.conf and
that also didn't work.  I have to have it in both places.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Help with DISTRO settings

[Khem Raj]

On Sun, Jul 24, 2016 at 12:34 AM, Edward Wingate  wrote:
> Ah, I found it.  I had inadvertently deleted one line
> (DISTRO="mydistro") from my layer's conf/layer.conf.
>
> Am I doing this right though?  Do I need DISTRO="mydistro" in both
> conf/layer.conf and conf/distro/mydistro.conf?

Just conf/distro/mydistro.conf is needed.

 Removing it from
> either doesn't work, but it seems redundant to put it in mydistro.conf
> as well.

did you make any other changes ?

>
>
> On Sun, Jul 24, 2016 at 12:04 AM, Edward Wingate  wrote:
>> On Sat, Jul 23, 2016 at 11:05 PM, Khem Raj  wrote:
>>> Move these DISTRO settings above require conf/distro/poky.conf
>>
>> That didn't change anything.  And it had been working like that for a
>> long time now.  Just a few days ago, it stopped taking effect and
>> reverting back to poky.  I have not been able to figure out what
>> caused it to stop working.
>>
>> Thanks for your reply nonetheless.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Help with DISTRO settings

[Edward Wingate]

Ah, I found it.  I had inadvertently deleted one line
(DISTRO="mydistro") from my layer's conf/layer.conf.

Am I doing this right though?  Do I need DISTRO="mydistro" in both
conf/layer.conf and conf/distro/mydistro.conf?  Removing it from
either doesn't work, but it seems redundant to put it in mydistro.conf
as well.


On Sun, Jul 24, 2016 at 12:04 AM, Edward Wingate  wrote:
> On Sat, Jul 23, 2016 at 11:05 PM, Khem Raj  wrote:
>> Move these DISTRO settings above require conf/distro/poky.conf
>
> That didn't change anything.  And it had been working like that for a
> long time now.  Just a few days ago, it stopped taking effect and
> reverting back to poky.  I have not been able to figure out what
> caused it to stop working.
>
> Thanks for your reply nonetheless.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Help with DISTRO settings

[Edward Wingate]

On Sat, Jul 23, 2016 at 11:05 PM, Khem Raj  wrote:
> Move these DISTRO settings above require conf/distro/poky.conf

That didn't change anything.  And it had been working like that for a
long time now.  Just a few days ago, it stopped taking effect and
reverting back to poky.  I have not been able to figure out what
caused it to stop working.

Thanks for your reply nonetheless.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Help with DISTRO settings

[Khem Raj]

On Sat, Jul 23, 2016 at 10:49 PM, Edward Wingate  wrote:
> This is in my layer's conf/distro/mydistro.conf file:
>
> require conf/distro/poky.conf
> DISTRO = "mydistro"
> DISTRO_NAME = "MyDistro"

Move these DISTRO settings above require conf/distro/poky.conf

>
> These variables took effect before, but now bitbake is reverting back
> to DISTRO="poky" and DISTRO_NAME = "Poky (Yocto Project Reference
> Distro)" (used for /etc/issue) for some reason.
>
> How can I determine what is reverting it?  I don't know what I might
> have changed to make it do this. Thank you.
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Help with DISTRO settings

[Edward Wingate]

This is in my layer's conf/distro/mydistro.conf file:

require conf/distro/poky.conf
DISTRO = "mydistro"
DISTRO_NAME = "MyDistro"

These variables took effect before, but now bitbake is reverting back
to DISTRO="poky" and DISTRO_NAME = "Poky (Yocto Project Reference
Distro)" (used for /etc/issue) for some reason.

How can I determine what is reverting it?  I don't know what I might
have changed to make it do this. Thank you.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] help

[Herman van Hazendonk]

Alternatively when you are using meta-qt5 layer, you could use something 
like Maliit input framework (which is used by various distributions 
(Jolla/Sailfish/Ubuntu/LuneOS) as well).


https://github.com/meta-qt5/meta-qt5/tree/master/recipes-qt/maliit

Herrie

On 2016-05-13 11:26, Burton, Ross wrote:

On 13 May 2016 at 08:25, Chandrakanth Sherkhane (IC Nexus)
 wrote:


Could anyone help to provide more details for,

1. Yocto Virtual Keyboard in French language - is it available now?

2. If not available, when will it be available?

3. Is the Yocto Virtual Keyboard available in any other languages?


There's no such thing as the Yocto Virtual Keyboard.  I presume you
mean matchbox-keyboard.  Looking at the sources:

$ ls layouts/*xml
layouts/keyboard-dvorak.xmllayouts/keyboard-fi.xml
layouts/keyboard-ru.xml  layouts/keyboard.xml
layouts/keyboard-extended.xml  layouts/keyboard-numpad.xml
layouts/keyboard-us.xml

There's no French layout, but these should provide plenty of examples
as to how to build it yourself.  If you implement the layout, please
consider sending the patch so everyone else can use it.

Ross


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

Re: [yocto] help

[Burton, Ross]

On 13 May 2016 at 08:25, Chandrakanth Sherkhane (IC Nexus) <
c...@icnexus.com.tw> wrote:

> Could anyone help to provide more details for,
>
> 1. Yocto Virtual Keyboard in French language - is it available now?
>
> 2. If not available, when will it be available?
>
> 3. Is the Yocto Virtual Keyboard available in any other languages?
>

There's no such thing as the Yocto Virtual Keyboard.  I presume you mean
matchbox-keyboard.  Looking at the sources:

$ ls layouts/*xml
layouts/keyboard-dvorak.xmllayouts/keyboard-fi.xml
 layouts/keyboard-ru.xml  layouts/keyboard.xml
layouts/keyboard-extended.xml  layouts/keyboard-numpad.xml
 layouts/keyboard-us.xml

There's no French layout, but these should provide plenty of examples as to
how to build it yourself.  If you implement the layout, please consider
sending the patch so everyone else can use it.

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

Re: [yocto] help

[Chris Z.]

​

On Fri, May 13, 2016 at 9:25 AM, Chandrakanth Sherkhane (IC Nexus) <
c...@icnexus.com.tw> wrote:

> Dear Yocto mailing list,
>
>
>
> We are IC Nexus Co. Ltd. in Taipei City – Taiwan, a developer and
> manufacturer of ARM-based Embedded Single Board Computers and Smart LCD
> Display products (on Android / Linux / Yocto Project). We are currently
> selling our products with Yocto O.S. to our worldwide customers.
>
>
>
> Could anyone help to provide more details for,
>
> 1. Yocto Virtual Keyboard in French language - is it available now?
>
> 2. If not available, when will it be available?
>
> 3. Is the Yocto Virtual Keyboard available in any other languages?
>
>
>
> We will appreciate your quick reply - Thank you very much!
>
>
>
> Kind Regards,
>
> Chandrakanth Sherkhane
>
> IC Nexus Co. Ltd.
>
> Tel: +886-2-2789-1200 ext. 114
>
> Email: c...@icnexus.com.tw
>
> Web: http://www.icnexus.com.tw
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] help

[Chandrakanth Sherkhane (IC Nexus)]

Dear Yocto mailing list,

 

We are IC Nexus Co. Ltd. in Taipei City - Taiwan, a developer and
manufacturer of ARM-based Embedded Single Board Computers and Smart LCD
Display products (on Android / Linux / Yocto Project). We are currently
selling our products with Yocto O.S. to our worldwide customers.

 

Could anyone help to provide more details for,

1. Yocto Virtual Keyboard in French language - is it available now?

2. If not available, when will it be available?

3. Is the Yocto Virtual Keyboard available in any other languages?

 

We will appreciate your quick reply - Thank you very much!

 

Kind Regards,

Chandrakanth Sherkhane

IC Nexus Co. Ltd.

Tel: +886-2-2789-1200 ext. 114

Email: c...@icnexus.com.tw

Web: http://www.icnexus.com.tw

 

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

Re: [yocto] Help on submitting patch to yocto projcet

[Khem Raj]

> On Apr 29, 2016, at 2:46 AM, SIVA SUBRAMANIAN.P  wrote:
> 
> Hi,
> Can any one guide me on submitting or upstreaming  patch to
> git.yoctoproject.org recipe? Thanks in advance.

Generally README of the concerned project describes the upstreaming process.
Additionally you can read 
http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
for preparing the patch properly.

-Khem


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Help on submitting patch to yocto projcet

[SIVA SUBRAMANIAN.P]

Hi,
Can any one guide me on submitting or upstreaming  patch to
git.yoctoproject.org recipe? Thanks in advance.

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

[yocto] Help with mosquitto_1.3.4 recipe

[Edward Wingate]

The first time I used mosquitto_1.3.4.bb from
meta-intel-iot-middleware a few months ago, it worked and I've been
using it in my build since.  Today, I created a new yocto build
directory and having trouble getting mosquitto to build now.

The directory 
/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.3.4-r0/mosquitto-1.3.4
is empty, whereas in my original build directory, the mosquitto source
is there.  I don't see any errors in log.do_fetch, but the error comes
during do_configure:

WARNING: Could not copy license file
/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.3.4-r0/mosquitto-1.3.4/LICENSE.txt
to 
/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.3.4-r0/license-destdir/mosquitto/LICENSE.txt:
[Errno 2] No such file or directory:
'/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.3.4-r0/mosquitto-1.3.4/LICENSE.txt'
ERROR: Function failed: mosquitto: LIC_FILES_CHKSUM points to an
invalid file: 
/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.3.4-r0/mosquitto-1.3.4/LICENSE.txt
ERROR: Logfile of failure stored in:
/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.3.4-r0/temp/log.do_configure.31424
Log data follows:
| DEBUG: Executing python function sysroot_cleansstate
| DEBUG: Python function sysroot_cleansstate finished
| DEBUG: Executing shell function do_configure
| DEBUG: Shell function do_configure finished
| DEBUG: Executing python function do_qa_configure
| NOTE: Checking autotools environment for common misconfiguration
| DEBUG: Python function do_qa_configure finished
| ERROR: Function failed: mosquitto: LIC_FILES_CHKSUM points to an
invalid file: 
/yocto/poky/build/tmp/work/cortexa9-vfp-neon-poky-linux-gnueabi/mosquitto/1.3.4-r0/mosquitto-1.3.4/LICENSE.txt
ERROR: Task 388
(/yocto/meta-intel-iot-middleware/recipes-connectivity/mosquitto/mosquitto_1.3.4.bb,
do_configure) failed with exit code '1'

Can anyone suggest where to look next to debug this? log.do_fetch
doesn't show any errors.  I am using fido branch of poky and this
revision of meta-intel-iot-middleware:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-iot-middleware/commit/?id=cfdd40032ca389bc1359a8b2e13e1da8f21e2561
(before the mosquitto recipe was upgraded to 1.4)

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

Re: [yocto] Help Cross Compiling for AVR

[Khem Raj]

> On Apr 5, 2016, at 8:18 AM, Washburn, David (washbudh)  
> wrote:
> 
> Hi All,
> 
> I am attempting to get the AVR Toolchain working inside of Yocto, but 
> unfortunately I'm relatively new to Yocto and keep seeing various errors I 
> cannot resolve. I was able to follow the instructions HERE 
>  to get 
> everything working locally, but I'm seeing various issues inside of Yocto. I 
> was able to get binutils configured and installed correctly but I haven't had 
> any luck getting GCC installed. I am able to get pass the configure and 
> compile stages in Yocto, but when I get to the install task, there's always a 
> failure. The failure stems from this task below, which is a part of GCC:
> 
> # Add unwind.h, it comes from libgcc which we don't want to build again
> install 
> /build-bundle/poky/build/tmp/sysroots/x86_64-linux/usr/lib/avr/gcc/avr/4.9.3/include/unwind.h
> /build-bundle/poky/build/tmp/work/cortexa53-vfp-neon-poky-linux-gnueabi/gcc-target-avr/4.9.3-r0/image/usr/lib/gcc/avr/4.9.3/include/
> 
> The reason it fails is because one of the two paths is always incorrect, no 
> matter how I attempt to configure the build. If I configure the TARGET_SYS to 
> be 'avr' during the install task, the path to 'unwind.h' becomes what is 
> shown above, but the unwind header is not there. I *think* it's due to the 
> fact that the TARGET_SYS was set to our default 'arm-poky-linux-gnueabi' 
> during the configure stage. If I try to set the configuration to have a 
> TARGET_SYS of 'avr' it might resolve the issue, but unfortunately doing this 
> causes the compile stage to fail with:
> | Makefile:1571: t-oe: No such file or directory
> | make[1]: *** No rule to make target `t-oe'.  Stop.
> 

I think you should try with master first

> I am using a slightly modified version of the recipes shown in the link below.
>  
> https://lists.yoctoproject.org/pipermail/yocto/2014-December/022781.html 
> 
> 
> Lastly, here is a link to the GCC commit that talks about the need to copy 
> over the file that is causing issues for me:
>  https://gcc.gnu.org/ml/gcc-patches/2003-03/msg00367.html 
> 
> 
> Thanks in advance for any help you can give, and I apologize if any of this 
> is unclear, I am still relatively new to Yocto.
> 
> Kind Regards,
>   David Washburn
> 
> 
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto 
> 


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Help Cross Compiling for AVR

[Washburn, David (washbudh)]

Hi All,

I am attempting to get the AVR Toolchain working inside of Yocto, but 
unfortunately I'm relatively new to Yocto and keep seeing various errors I 
cannot resolve. I was able to follow the instructions 
HERE to get 
everything working locally, but I'm seeing various issues inside of Yocto. I 
was able to get binutils configured and installed correctly but I haven't had 
any luck getting GCC installed. I am able to get pass the configure and compile 
stages in Yocto, but when I get to the install task, there's always a failure. 
The failure stems from this task below, which is a part of GCC:

# Add unwind.h, it comes from libgcc which we don't want to build again
install 
/build-bundle/poky/build/tmp/sysroots/x86_64-linux/usr/lib/avr/gcc/avr/4.9.3/include/unwind.h
/build-bundle/poky/build/tmp/work/cortexa53-vfp-neon-poky-linux-gnueabi/gcc-target-avr/4.9.3-r0/image/usr/lib/gcc/avr/4.9.3/include/

The reason it fails is because one of the two paths is always incorrect, no 
matter how I attempt to configure the build. If I configure the TARGET_SYS to 
be 'avr' during the install task, the path to 'unwind.h' becomes what is shown 
above, but the unwind header is not there. I *think* it's due to the fact that 
the TARGET_SYS was set to our default 'arm-poky-linux-gnueabi' during the 
configure stage. If I try to set the configuration to have a TARGET_SYS of 
'avr' it might resolve the issue, but unfortunately doing this causes the 
compile stage to fail with:
| Makefile:1571: t-oe: No such file or directory
| make[1]: *** No rule to make target `t-oe'.  Stop.

I am using a slightly modified version of the recipes shown in the link below.
 
https://lists.yoctoproject.org/pipermail/yocto/2014-December/022781.html

Lastly, here is a link to the GCC commit that talks about the need to copy over 
the file that is causing issues for me:
 https://gcc.gnu.org/ml/gcc-patches/2003-03/msg00367.html

Thanks in advance for any help you can give, and I apologize if any of this is 
unclear, I am still relatively new to Yocto.

Kind Regards,
  David Washburn



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

Re: [yocto] Help with Opensips Recipe - QA run found fatal errors

[Caio]

Paul,
 Ok, thank you for your elucidation.
This could be a prefix problem, because I'm using a make install from
Makefile.

I will find this problem and fix it.

Thank you very much.

Regards,

Caio Pereira



2015-12-01 14:56 GMT-02:00 Paul Eggleton :

> Hi Caio,
>
> compile-host-path isn't about the path being different - it's about the
> path
> being something possibly bad i.e. on the host system. You really ought to
> fix
> that one rather than disable it.
>
> Cheers,
> Paul
>
> On Tue, 01 Dec 2015 10:21:03 Caio wrote:
> > Hi Paul,
> >
> > Thank you very much for your help.
> > I added INSANE_SKIP_${PN} += " libdir compile-host-path" because the
> > instalation is different from /usr/lib.
> >
> > Thank you very much!
> >
> > Regards,
> >
> > Caio Pereira
> >
> > 2015-11-25 20:26 GMT-02:00 Paul Eggleton  >:
> > > Hi Caio,
> > >
> > > On Tuesday 24 November 2015 11:48:13 Caio wrote:
> > > > I'm writing a recipe to a Sip proxy Opensips, but I'm having problems
> > >
> > > with
> > >
> > > > QA Issues.
> > > > In the First time I tried to use make install from Opensips Makefile
> I
> > >
> > > had
> > >
> > > > problem with QA Issues,  so I added all the folders to FILES_${PN}
> and
> > > > FILES_${PN} but I still having problem.
> > > >
> > > > So I decided to start small, creating the folder structure and copy
> only
> > > > the binary files and after I will copy all the files using the
> > >
> > > do_install
> > >
> > > > function.
> > > >
> > > > But when I added the folders and I started to have problems with QA
> > >
> > > again.
> > >
> > > > FILES_${PN} = " \
> > > >
> > > > ${sbindir}/* \
> > > > ${sysconfdir}/* \
> > > > ${sysconfdir}/opensips/* \
> > > > ${libdir}/* \
> > > > ${libdir}/opensips/* \
> > > > ${libdir}/opensips/modules/* \
> > > > "
> > > >
> > > > Someone could help me with this problem?
> > > >
> > > >
> > > > Thank you very much
> > > >
> > > > Best Regards,
> > > >
> > > > Caio Pereira
> > > >
> > > >
> > > > ERROR: QA Issue: opensips: The compile log indicates that host
> include
> > > > and/or library paths were used.
> > > >
> > > >  Please check the log
> > >
> > >
> '/home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-po
> > > ky>
> > > > -linux-gnueabi/opensips/2.2.0-r0/temp/log.do_compile' for more
> > >
> > > information.
> > >
> > > > [compile-host-path]
> > > >
> > > >
> > > > ERROR: QA run found fatal errors. Please consider fixing them.
> > > > ERROR: Function failed: do_package_qa
> > >
> > > > ERROR: Logfile of failure stored in:
> > >
> /home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-pok
> > > y->
> > > > linux-gnueabi/opensips/2.2.0-r0/temp/log.do_package_qa.30973 ERROR:
> Task
> > >
> > > 9
> > >
> > >
> (/home/icchw/fsl-community-bsp/sources/icchw/meta-caio/recipes-telephony/o
> > > pe>
> > > > nsips/ opensips_2.2.0.bb, do_package_qa) failed with exit code '1'
> > > >
> > > >
> > > > cat
> > >
> > >
> /home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-pok
> > > y->
> > > > linux-gnueabi/opensips/2.2.0-r0/temp/log.do_package_qa.30973
> > > >
> > > > DEBUG: Python function read_subpackage_metadata finished
> > > > ERROR: QA Issue: opensips: The compile log indicates that host
> include
> > > > and/or library paths were used.
> > > >
> > > >  Please check the log
> > >
> > >
> '/home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-po
> > > ky>
> > > > -linux-gnueabi/opensips/2.2.0-r0/temp/log.do_compile' for more
> > >
> > > information.
> > >
> > > > [compile-host-path]
> > >
> > > Did you check the mentioned compile log?
> > >
> > > FYI a good reference for these QA checks is:
> > >
> > >
> > >
> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#qa-err
> > > ors-and-warnings
> > >
> > > As mentioned there you should find somewhere in that log "is unsafe for
> > > cross-compilation" or "CROSS COMPILE Badness".
> > >
> > > Cheers,
> > > Paul
> > >
> > > --
> > >
> > > Paul Eggleton
> > > Intel Open Source Technology Centre
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>



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

Re: [yocto] Help with Opensips Recipe - QA run found fatal errors

[Paul Eggleton]

Hi Caio,

compile-host-path isn't about the path being different - it's about the path 
being something possibly bad i.e. on the host system. You really ought to fix 
that one rather than disable it.

Cheers,
Paul

On Tue, 01 Dec 2015 10:21:03 Caio wrote:
> Hi Paul,
> 
> Thank you very much for your help.
> I added INSANE_SKIP_${PN} += " libdir compile-host-path" because the
> instalation is different from /usr/lib.
> 
> Thank you very much!
> 
> Regards,
> 
> Caio Pereira
> 
> 2015-11-25 20:26 GMT-02:00 Paul Eggleton :
> > Hi Caio,
> > 
> > On Tuesday 24 November 2015 11:48:13 Caio wrote:
> > > I'm writing a recipe to a Sip proxy Opensips, but I'm having problems
> > 
> > with
> > 
> > > QA Issues.
> > > In the First time I tried to use make install from Opensips Makefile I
> > 
> > had
> > 
> > > problem with QA Issues,  so I added all the folders to FILES_${PN} and
> > > FILES_${PN} but I still having problem.
> > > 
> > > So I decided to start small, creating the folder structure and copy only
> > > the binary files and after I will copy all the files using the
> > 
> > do_install
> > 
> > > function.
> > > 
> > > But when I added the folders and I started to have problems with QA
> > 
> > again.
> > 
> > > FILES_${PN} = " \
> > > 
> > > ${sbindir}/* \
> > > ${sysconfdir}/* \
> > > ${sysconfdir}/opensips/* \
> > > ${libdir}/* \
> > > ${libdir}/opensips/* \
> > > ${libdir}/opensips/modules/* \
> > > "
> > > 
> > > Someone could help me with this problem?
> > > 
> > > 
> > > Thank you very much
> > > 
> > > Best Regards,
> > > 
> > > Caio Pereira
> > > 
> > > 
> > > ERROR: QA Issue: opensips: The compile log indicates that host include
> > > and/or library paths were used.
> > > 
> > >  Please check the log
> > 
> > '/home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-po
> > ky> 
> > > -linux-gnueabi/opensips/2.2.0-r0/temp/log.do_compile' for more
> > 
> > information.
> > 
> > > [compile-host-path]
> > > 
> > > 
> > > ERROR: QA run found fatal errors. Please consider fixing them.
> > > ERROR: Function failed: do_package_qa
> > 
> > > ERROR: Logfile of failure stored in:
> > /home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-pok
> > y-> 
> > > linux-gnueabi/opensips/2.2.0-r0/temp/log.do_package_qa.30973 ERROR: Task
> > 
> > 9
> > 
> > (/home/icchw/fsl-community-bsp/sources/icchw/meta-caio/recipes-telephony/o
> > pe> 
> > > nsips/ opensips_2.2.0.bb, do_package_qa) failed with exit code '1'
> > > 
> > > 
> > > cat
> > 
> > /home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-pok
> > y-> 
> > > linux-gnueabi/opensips/2.2.0-r0/temp/log.do_package_qa.30973
> > > 
> > > DEBUG: Python function read_subpackage_metadata finished
> > > ERROR: QA Issue: opensips: The compile log indicates that host include
> > > and/or library paths were used.
> > > 
> > >  Please check the log
> > 
> > '/home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-po
> > ky> 
> > > -linux-gnueabi/opensips/2.2.0-r0/temp/log.do_compile' for more
> > 
> > information.
> > 
> > > [compile-host-path]
> > 
> > Did you check the mentioned compile log?
> > 
> > FYI a good reference for these QA checks is:
> > 
> > 
> > http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#qa-err
> > ors-and-warnings
> > 
> > As mentioned there you should find somewhere in that log "is unsafe for
> > cross-compilation" or "CROSS COMPILE Badness".
> > 
> > Cheers,
> > Paul
> > 
> > --
> > 
> > Paul Eggleton
> > Intel Open Source Technology Centre

-- 

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

Re: [yocto] Help with Opensips Recipe - QA run found fatal errors

[Caio]

Hi Paul,

Thank you very much for your help.
I added INSANE_SKIP_${PN} += " libdir compile-host-path" because the
instalation is different from /usr/lib.

Thank you very much!

Regards,

Caio Pereira


2015-11-25 20:26 GMT-02:00 Paul Eggleton :

> Hi Caio,
>
> On Tuesday 24 November 2015 11:48:13 Caio wrote:
> > I'm writing a recipe to a Sip proxy Opensips, but I'm having problems
> with
> > QA Issues.
> > In the First time I tried to use make install from Opensips Makefile I
> had
> > problem with QA Issues,  so I added all the folders to FILES_${PN} and
> > FILES_${PN} but I still having problem.
> >
> > So I decided to start small, creating the folder structure and copy only
> > the binary files and after I will copy all the files using the
> do_install
> > function.
> >
> > But when I added the folders and I started to have problems with QA
> again.
> >
> > FILES_${PN} = " \
> > ${sbindir}/* \
> > ${sysconfdir}/* \
> > ${sysconfdir}/opensips/* \
> > ${libdir}/* \
> > ${libdir}/opensips/* \
> > ${libdir}/opensips/modules/* \
> > "
> > Someone could help me with this problem?
> >
> >
> > Thank you very much
> >
> > Best Regards,
> >
> > Caio Pereira
> >
> >
> > ERROR: QA Issue: opensips: The compile log indicates that host include
> > and/or library paths were used.
> >  Please check the log
> >
> '/home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-poky
> > -linux-gnueabi/opensips/2.2.0-r0/temp/log.do_compile' for more
> information.
> > [compile-host-path]
> >
> >
> > ERROR: QA run found fatal errors. Please consider fixing them.
> > ERROR: Function failed: do_package_qa
> > ERROR: Logfile of failure stored in:
> >
> /home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-poky-
> > linux-gnueabi/opensips/2.2.0-r0/temp/log.do_package_qa.30973 ERROR: Task
> 9
> >
> (/home/icchw/fsl-community-bsp/sources/icchw/meta-caio/recipes-telephony/ope
> > nsips/ opensips_2.2.0.bb, do_package_qa) failed with exit code '1'
> >
> >
> > cat
> >
> /home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-poky-
> > linux-gnueabi/opensips/2.2.0-r0/temp/log.do_package_qa.30973
> >
> > DEBUG: Python function read_subpackage_metadata finished
> > ERROR: QA Issue: opensips: The compile log indicates that host include
> > and/or library paths were used.
> >  Please check the log
> >
> '/home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-poky
> > -linux-gnueabi/opensips/2.2.0-r0/temp/log.do_compile' for more
> information.
> > [compile-host-path]
>
> Did you check the mentioned compile log?
>
> FYI a good reference for these QA checks is:
>
>
> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#qa-errors-and-warnings
>
> As mentioned there you should find somewhere in that log "is unsafe for
> cross-compilation" or "CROSS COMPILE Badness".
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>



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

Re: [yocto] Help with Opensips Recipe - QA run found fatal errors

[Paul Eggleton]

Hi Caio,

On Tuesday 24 November 2015 11:48:13 Caio wrote:
> I'm writing a recipe to a Sip proxy Opensips, but I'm having problems with
> QA Issues.
> In the First time I tried to use make install from Opensips Makefile I had
> problem with QA Issues,  so I added all the folders to FILES_${PN} and
> FILES_${PN} but I still having problem.
> 
> So I decided to start small, creating the folder structure and copy only
> the binary files and after I will copy all the files using the  do_install
> function.
> 
> But when I added the folders and I started to have problems with QA again.
> 
> FILES_${PN} = " \
> ${sbindir}/* \
> ${sysconfdir}/* \
> ${sysconfdir}/opensips/* \
> ${libdir}/* \
> ${libdir}/opensips/* \
> ${libdir}/opensips/modules/* \
> "
> Someone could help me with this problem?
> 
> 
> Thank you very much
> 
> Best Regards,
> 
> Caio Pereira
> 
> 
> ERROR: QA Issue: opensips: The compile log indicates that host include
> and/or library paths were used.
>  Please check the log
> '/home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-poky
> -linux-gnueabi/opensips/2.2.0-r0/temp/log.do_compile' for more information.
> [compile-host-path]
> 
> 
> ERROR: QA run found fatal errors. Please consider fixing them.
> ERROR: Function failed: do_package_qa
> ERROR: Logfile of failure stored in:
> /home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-poky-
> linux-gnueabi/opensips/2.2.0-r0/temp/log.do_package_qa.30973 ERROR: Task 9
> (/home/icchw/fsl-community-bsp/sources/icchw/meta-caio/recipes-telephony/ope
> nsips/ opensips_2.2.0.bb, do_package_qa) failed with exit code '1'
> 
> 
> cat
> /home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-poky-
> linux-gnueabi/opensips/2.2.0-r0/temp/log.do_package_qa.30973
> 
> DEBUG: Python function read_subpackage_metadata finished
> ERROR: QA Issue: opensips: The compile log indicates that host include
> and/or library paths were used.
>  Please check the log
> '/home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-poky
> -linux-gnueabi/opensips/2.2.0-r0/temp/log.do_compile' for more information.
> [compile-host-path]

Did you check the mentioned compile log?

FYI a good reference for these QA checks is:

  
http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#qa-errors-and-warnings

As mentioned there you should find somewhere in that log "is unsafe for
cross-compilation" or "CROSS COMPILE Badness".

Cheers,
Paul

-- 

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

[yocto] Help with Opensips Recipe - QA run found fatal errors

[Caio]

Hello,

I'm writing a recipe to a Sip proxy Opensips, but I'm having problems with
QA Issues.
In the First time I tried to use make install from Opensips Makefile I had
problem with QA Issues,  so I added all the folders to FILES_${PN} and
FILES_${PN} but I still having problem.

So I decided to start small, creating the folder structure and copy only
the binary files and after I will copy all the files using the  do_install
function.

But when I added the folders and I started to have problems with QA again.

FILES_${PN} = " \
${sbindir}/* \
${sysconfdir}/* \
${sysconfdir}/opensips/* \
${libdir}/* \
${libdir}/opensips/* \
${libdir}/opensips/modules/* \
"
Someone could help me with this problem?


Thank you very much

Best Regards,

Caio Pereira


ERROR: QA Issue: opensips: The compile log indicates that host include
and/or library paths were used.
 Please check the log
'/home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-poky-linux-gnueabi/opensips/2.2.0-r0/temp/log.do_compile'
for more information. [compile-host-path]


ERROR: QA run found fatal errors. Please consider fixing them.
ERROR: Function failed: do_package_qa
ERROR: Logfile of failure stored in:
/home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-poky-linux-gnueabi/opensips/2.2.0-r0/temp/log.do_package_qa.30973
ERROR: Task 9
(/home/icchw/fsl-community-bsp/sources/icchw/meta-caio/recipes-telephony/opensips/
opensips_2.2.0.bb, do_package_qa) failed with exit code '1'


cat
/home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-poky-linux-gnueabi/opensips/2.2.0-r0/temp/log.do_package_qa.30973

DEBUG: Python function read_subpackage_metadata finished
ERROR: QA Issue: opensips: The compile log indicates that host include
and/or library paths were used.
 Please check the log
'/home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-poky-linux-gnueabi/opensips/2.2.0-r0/temp/log.do_compile'
for more information. [compile-host-path]
NOTE: Checking Package: opensips-dbg
NOTE: arm-poky-linux-gnueabi-objdump -p
/home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-poky-linux-gnueabi/opensips/2.2.0-r0/packages-split/opensips-dbg/usr/sbin/.debug/opensips
NOTE: Checking Package: opensips-staticdev
NOTE: Checking Package: opensips-dev
NOTE: Checking Package: opensips-doc
NOTE: Checking Package: opensips-locale
NOTE: Checking Package: opensips
NOTE: arm-poky-linux-gnueabi-objdump -p
/home/icchw/fsl-community-bsp/small_steps/tmp/work/armv7at2hf-vfp-neon-poky-linux-gnueabi/opensips/2.2.0-r0/packages-split/opensips/usr/sbin/opensips
ERROR: QA run found fatal errors. Please consider fixing them.
DEBUG: Python function do_package_qa finished
ERROR: Function failed: do_package_qa


opensips_2.2.bb

DESCRIPTION = "SIP Proxy"
HOMEPAGE = "http://www.opensips.org";
LICENSE = "GPLv2"
DEPENDS = "sqlite3 libxml2 openssl confuse curl"
LIC_FILES_CHKSUM = "file://COPYING;md5=007e0c25afacf8e39c37f27c8212bc67"

SRC_URI = "git://github.com/OpenSIPS/opensips.git;branch=master \
   file://Makefile.conf \
   "
SRCREV = "d6660513634c8e4305e7c5b03510893efced1b68"
S = "${WORKDIR}/git"
inherit autotools pkgconfig

OPENSIPS_CPPFLAGS = "-fexpensive-optimizations -fomit-frame-pointer
-fsigned-char -Wcast-align -fPIC "

OSREL = "${LINUX_VERSION}"
OSREL .= "3.10.17"
#FIX-ME
OPENSIPS_ARCH .= "${TUNE_PKGARCH}"
OPENSIPS_MAKEFLAGS = "ARCH=${OPENSIPS_ARCH}  OS=linux OSREL=${OSREL}"
OPENSIPS_BUILD_DIR = "${S}"
OPENSIPS_INCLUDE_BASE_MODULES = "\"presence db_sqlite\""
export TLS = "1"
OPENSIPS_EXCLUDE_MODULES = "\"aaa_radius b2b_logic cachedb_cassandra
cachedb_couchbase cachedb_memcached cachedb_mongodb cachedb_redis
carrierroute compression cpl-c db_berkeley db_http db_mysql db_oracle
db_perlvdb db_postgres db_unixodbc dialplan emergency event_rabbitmq h350
regex identity jabber json ldap lua httpd mi_xmlrpc_ng mmgeoip osp perl
pi_http presence presence_dialoginfo presence_mwi presence_xml proto_sctp
proto_tls pua pua_bla pua_dialoginfo pua_mi pua_usrloc pua_xmpp python
rest_client rls sngtc snmpstats tlsops xcap xcap_client xmpp proto_wsi\""

OPENSIPS_DEBUG_MODE = ""

do_configure(){
cp ${WORKDIR}/Makefile.conf ${S}
}

do_compile() {
oe_runmake -C ${OPENSIPS_BUILD_DIR} ${OPENSIPS_MAKEFLAGS}
${OPENSIPS_DEBUG_MODE} include_modules="${OPENSIPS_INCLUDE_BASE_MODULES}"
prefix=${D}${prefix} modules app

}

#I decide to move in small steps, so this installations doesn't have all
the files
do_install() {

install -d ${D}${sbindir}/
install -d ${D}${sysconfdir}
install -d ${D}${sysconfdir}/opensips/
install -d ${D}${libdir}
install -d ${D}${libdir}/opensips
install -d ${D}${libdir}/opensips/modules
install -m 0755 ${S}/opensips ${D}${sbindir}/

#oe_runmake -C ${OPENSIPS_BUILD_DIR}
include_modules="${OPENSIPS_INCLUDE_BASE_MODULES}" prefix=${D}${prefix}
install

Re: [yocto] help to unsubscribe yocto

[Philip Balister]

On 10/11/2015 02:06 AM, chew hou ming wrote:
> Like to unsubscribe the mail from yocto.
> Don't know how. Please help.

Read the link at the bottom of every email sent by the list.

Philip

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

[yocto] help to unsubscribe yocto

[chew hou ming]

Like to unsubscribe the mail from yocto.
Don't know how. Please help.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Help for client Project needed

[Sarah Hindermann]

Hello Yocto Fans and developers,

I am looking for a Yocto / Linux developer for a Project in Germany.
I am interested in permanent employees or contractors who know Yocto well.
Concerning contractors part time support would also be an option as well as 
remote possibility after a view weeks.
The project is about developing the new product concerning datalogger in C++.
German language skills are a benefit but not a must. English is sufficient.
More information at:
https://www.xing.com/communities/posts/embedded-linux-entwickler-mit-yocto-w-strich-m-in-darmstadt-asap-remote-mgl-1010137514
I can tell you more details and information about the company at 
s.hinderm...@roc-search.de or give me a call at 0049 693 650 650 55.
If you have a friend or colleague who is not in this list but might be 
interested feel free to forward my message.
Thank you.
I wish everyone a wonderful Thursday!
Sarah


Sarah Hindermann
Recruitment Consultant for Contractors

T: +49  (0) 693 650 650 55
F: +49  (0) 693 650 650 57
M: s.hinderm...@roc-search.de
X: 
www.xing.com/profile/Sarah_Hindermann
H: www.roc-search.de

[Description: Description: Description: Description: Description: Description: 
Description: Description: Description: Description: 
C:\Users\lucy.meddings\Desktop\New logo\ROC_RGB.png]
Roc Search GmbH - Roßmarkt 10 - 60311 Frankfurt am Main

[IIP_LOGO_BLUE_CMYK] [Description: Description: 
C:\Users\lucy.meddings.ROCSEARCH\AppData\Local\Microsoft\Windows\Temporary 
Internet Files\Content.Outlook\10TW11RW\APSCo stacked JPEG for high res 
printing (2) (2).JPG]  [Description: 2012 Fast Track 100 logo (7)] 
[http://www.roc-search.com/File.ashx?path=Root/Images/2013_Fast_Track_100_logo.jpg]

Click Here to check out the 
latest News at Roc Search...

Whether you work with or for us, whether we place you or place people for you, 
at Roc Search our passion is for people and the placements we make. As clients 
and candidates you can be sure we'll take nothing for granted and take the time 
you and we need, to build mutual insight and trust. The smallest new start-ups 
and the largest corporates, the experienced professional and ambitious 
beginner: whoever you are and whatever your story, we believe you deserve a 
flexible, responsive and personal service which delivers the results you need.
At Roc Search we guarantee that's exactly what you can expect.
The information contained in this email may be privileged and is intended for 
the personal and confidential use of the recipient(s) named above. If the 
reader of this message is not the intended recipient or an agent responsible 
for delivering it to the intended recipient, you are hereby notified that you 
have received this email in error and that any review, dissemination or copying 
of this message is strictly prohibited. If you have received this email in 
error, please notify us immediately.
This message and any attachments are believed to be free of any virus or defect 
that might affect any computer system into which it is received and opened. 
However, it is the responsibility of the recipient to ensure that it is virus 
free; therefore, no responsibility is accepted for any loss or damage in any 
way arising from its use
Roc Search Limited. Registered address: The Blade, Abbey Square, Reading, 
Berkshire, RG1 3BE Company Registration number: 06044636.

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

Re: [yocto] Help using bitbake to compile a custom package.

[Paul Eggleton]

Hi Rafael,

On Tuesday 16 June 2015 19:58:06 Rafael E. Herrera wrote:
> I'm trying to port an in-house piece of software in my Yocto tree. I managed
> to create a rudimentary recipe file that grabs the tar ball from the local
> disk and attempts to compile using:
> 
> host $ bitbake -f -c compile example
> 
> From the output I infer that the tar ball got unpacked and a make executed
> in the source code tree.
> 
> However, my build fails because a number of libraries are missing.
> 
> For example, the libuuid library seems not to be found. How do I verify that
> this library is available in my Yocto tree?
> 
> If not, how to determine what recipe do I need to build to get it installed?
> 
> How do I make sure that the header files for the library are also installed?

Step one is to find out which recipe provides the library. This will usually
correspond to which upstream project actually provides the source for the
library. I usually start with "git grep"; in this case "git grep libuuid"
gives me a pointer to the util-linux recipe.

Step two is to add this recipe to the value of DEPENDS within your recipe.
This ensures that the libraries and headers that are produced by the depended
upon recipe will be in the sysroot by the time the configure step of your
recipe runs.

> I'm assuming that once a library is built using the right bitbake recipe, it
> is available to the code that calls it. If not, how is that configured?

That's correct yes, once the do_populate_sysroot task of a recipe executes,
a subset of what is installed at the do_install step is "staged" into the
sysroot, and do_populate_sysroot is always run as part of the normal build
of a recipe. You do need to be explicit about stating the build-time
dependencies in DEPENDS though in order to ensure that happens for
every other recipe your recipe depends upon though.

Just in case you haven't seen it, there is a section of our manual that
describes the process of writing a new recipe that may be helpful:

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe

Cheers,
Paul

-- 

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

[yocto] Help using bitbake to compile a custom package.

[Rafael E. Herrera]

Hello,

I'm trying to port an in-house piece of software in my Yocto tree. I managed to 
create a rudimentary recipe file that grabs the tar ball from the local disk 
and attempts to compile using:

host $ bitbake -f -c compile example

>From the output I infer that the tar ball got unpacked and a make executed in 
>the source code tree.

However, my build fails because a number of libraries are missing. 

For example, the libuuid library seems not to be found. How do I verify that 
this library is available in my Yocto tree? 

If not, how to determine what recipe do I need to build to get it installed?

How do I make sure that the header files for the library are also installed?

I'm assuming that once a library is built using the right bitbake recipe, it is 
available to the code that calls it. If not, how is that configured?

Thank you,

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

Re: [yocto] Help getting started developing.

[Alex J Lennon]

Hi Rafael,

On 26/05/2015 22:13, Rafael E. Herrera wrote:
> Hello, 
> I have purchased a TI UEVM5432 board. I have also successfully setup the 
> development environment as described on the online documentation from the TI 
> web site 
> (http://processors.wiki.ti.com/index.php/OMAP5_GLSDK_Software_Developers_Guide).
>  My developement environment is the recommended Ubuntu distribution.
>
> I have also successfully build the Yocto filesystem (as per the instructions 
> in the link above) and successfully booted the generated image in the 
> evaluation board.
>
> Where I need help is on how to port an application to the Yocto filesystem.  
> In particular, I need to build an X Window client.
>
> The instructions in the link above don't explain well how to 
> prepare/configure my environment so I can compile my application. 
>
> If it were a typical development environment, I would configure my Makefiles 
> and just compile. The method used with this development environment (bitbake) 
> is not that clear to me.

If you prepare your application build environment using autotools then
it should "just work" (tm)

This walkthrough might help -

https://wiki.yoctoproject.org/wiki/Building_your_own_recipes_from_first_principles

Also here -

http://www.codeproject.com/Articles/774826/Adding-rd-party-components-to-Yocto-OpenEmbedded-L

Regards,

Alex

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

[yocto] Help getting started developing.

[Rafael E. Herrera]

Hello, 
I have purchased a TI UEVM5432 board. I have also successfully setup the 
development environment as described on the online documentation from the TI 
web site 
(http://processors.wiki.ti.com/index.php/OMAP5_GLSDK_Software_Developers_Guide).
 My developement environment is the recommended Ubuntu distribution.

I have also successfully build the Yocto filesystem (as per the instructions in 
the link above) and successfully booted the generated image in the evaluation 
board.

Where I need help is on how to port an application to the Yocto filesystem.  In 
particular, I need to build an X Window client.

The instructions in the link above don't explain well how to prepare/configure 
my environment so I can compile my application. 

If it were a typical development environment, I would configure my Makefiles 
and just compile. The method used with this development environment (bitbake) 
is not that clear to me.

Any help would be greatly appreciated.

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

Re: [yocto] Help -- Where can I get the LSB test log

[Lei, Maohui]

Hi Yi

> There is a wiki page for it: https://wiki.yoctoproject.org/wiki/LSB_Result

Thank you. But this is too old. I want the log of yocto 1.7.1 release.

Cheers
Lei


> -Original Message-
> From: Yi Zhao [mailto:yi.z...@windriver.com]
> Sent: Thursday, January 29, 2015 11:32 AM
> To: Lei, Maohui/雷 茂慧
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Help -- Where can I get the LSB test log
> 
> Hi Maohui,
> 
> There is a wiki page for it: https://wiki.yoctoproject.org/wiki/LSB_Result
> 
> Yi
> 
> 在 2015年01月29日 11:11, Lei, Maohui 写道:
> > Hi Yi
> >
> >> The log should be in /var/opt/lsb/test/manager/results/
> >>
> > sorry，my expression is not very clear。
> >
> > >From https://wiki.yoctoproject.org/wiki/Yocto_1.7_Overall_Test_Plan , I
> knew LSB test was executed on target that made by yocto 1.7.1 release.
> >
> > So , I want to get the LSB test history of the yocto 1.7.1 release.
> >
> > Lei
> >
> >
> >> -Original Message-
> >> From: Yi Zhao [mailto:yi.z...@windriver.com]
> >> Sent: Thursday, January 29, 2015 10:34 AM
> >> To: Lei, Maohui/雷 茂慧; yocto@yoctoproject.org
> >> Subject: Re: [yocto] Help -- Where can I get the LSB test log
> >>
> >> The log should be in /var/opt/lsb/test/manager/results/
> >>
> >> Yi
> >>
> >> 在 2015年01月29日 10:04, Lei, Maohui 写道:
> >>> Hi all
> >>>
> >>> Was LSB test executed  in yocto 1.7.1 release？ Where can I get the LSB
> test
> >> log and result?
> >>> Best Regards,
> >>> Lei Maohui
> >
> >

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

Re: [yocto] Help -- Where can I get the LSB test log

[Yi Zhao]

The log should be in /var/opt/lsb/test/manager/results/

Yi

在 2015年01月29日 10:04, Lei, Maohui 写道:
> Hi all
>
> Was LSB test executed  in yocto 1.7.1 release？ Where can I get the LSB test 
> log and result?
>
> Best Regards,
> Lei Maohui

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

Re: [yocto] Help -- Where can I get the LSB test log

[Lei, Maohui]

Hi Yi

> The log should be in /var/opt/lsb/test/manager/results/
>

sorry，my expression is not very clear。

>From https://wiki.yoctoproject.org/wiki/Yocto_1.7_Overall_Test_Plan , I knew 
>LSB test was executed on target that made by yocto 1.7.1 release.

So , I want to get the LSB test history of the yocto 1.7.1 release.

Lei 


> -Original Message-
> From: Yi Zhao [mailto:yi.z...@windriver.com]
> Sent: Thursday, January 29, 2015 10:34 AM
> To: Lei, Maohui/雷 茂慧; yocto@yoctoproject.org
> Subject: Re: [yocto] Help -- Where can I get the LSB test log
> 
> The log should be in /var/opt/lsb/test/manager/results/
> 
> Yi
> 
> 在 2015年01月29日 10:04, Lei, Maohui 写道:
> > Hi all
> >
> > Was LSB test executed  in yocto 1.7.1 release？ Where can I get the LSB test
> log and result?
> >
> > Best Regards,
> > Lei Maohui

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

Re: [yocto] Help -- Where can I get the LSB test log

[Yi Zhao]

Hi Maohui,

There is a wiki page for it: https://wiki.yoctoproject.org/wiki/LSB_Result

Yi

在 2015年01月29日 11:11, Lei, Maohui 写道:
> Hi Yi
>
>> The log should be in /var/opt/lsb/test/manager/results/
>>
> sorry，my expression is not very clear。
>
> >From https://wiki.yoctoproject.org/wiki/Yocto_1.7_Overall_Test_Plan , I knew 
> >LSB test was executed on target that made by yocto 1.7.1 release.
>
> So , I want to get the LSB test history of the yocto 1.7.1 release.
>
> Lei 
>
>
>> -Original Message-
>> From: Yi Zhao [mailto:yi.z...@windriver.com]
>> Sent: Thursday, January 29, 2015 10:34 AM
>> To: Lei, Maohui/雷 茂慧; yocto@yoctoproject.org
>> Subject: Re: [yocto] Help -- Where can I get the LSB test log
>>
>> The log should be in /var/opt/lsb/test/manager/results/
>>
>> Yi
>>
>> 在 2015年01月29日 10:04, Lei, Maohui 写道:
>>> Hi all
>>>
>>> Was LSB test executed  in yocto 1.7.1 release？ Where can I get the LSB test
>> log and result?
>>> Best Regards,
>>> Lei Maohui
>
>

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

[yocto] Help -- Where can I get the LSB test log

[Lei, Maohui]

Hi all

Was LSB test executed  in yocto 1.7.1 release？ Where can I get the LSB test log 
and result?

Best Regards,
Lei Maohui
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Help me understand Openembedded variable expansion

[Matt Schuckmann]

> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Thursday, October 30, 2014 6:52 AM
> To: Matt Schuckmann
> Cc: Yocto Project
> Subject: Re: [yocto] Help me understand Openembedded variable expansion
> 
> On Tue, 2014-10-28 at 10:11 -0700, Matt Schuckmann wrote:
> > So there is something I just don't get about how variables get
> > created, expanded, interpreted, etc in Bitbake
> >
> > For example I'm trying to copy some of the techniques in the Poky
> Tiny
> > distribution to reduce my image size and build time.
> > One of the fragments is this one.
> >
> > # The mtrace script included by eglibc is a perl script. This means
> > the system # will build perl in case this package is installed. Since
> > we don't care about # this script, remove the dependency from here.
> > RDEPENDS_${PN}-mtrace_pn-eglibc = ""
> >
> > I put this in my distribution .conf file and I doesn't seem to do
> > anything perl is still getting built.
> > Of course it doesn't help that I don't understand what does,
> > especially in the context of the distribution .conf file.
> >
> > I also see hints in the code in debug output that the machine, image,
> > or distribution names can automatically get appended to paths, or
> > variables but I don't really understand how that works.
> >
> > I'm not even sure how to phrase a question around this, immediately
> > I'd like to figure out why Perl is still getting built but ultimately
> > I'd like to understand the variable rules better so I that I can
> > better take advantage of this power tool.
> 
> Perhaps have a look at "overrides" in the bitbake manual.
> 
> You can split RDEPENDS_${PN}-mtrace_pn-eglibc into components. Starting
> on the RHS, "_pn-eglibc" is an override that applies to recipes where
> PN = "eglibc". In those recipes, the variable becomes:
> 
> RDEPENDS_${PN}-mtrace = ""
> 
> and is basically overriding a dependency on perl that would other be
> there, something like:
> 
> RDEPENDS_${PN}-mtrace = "perl".
> 
> Does that help?
> 
> Cheers,
> 
> Richard

Thank you to both Peter Bergin and Richard Purdie, 

I'm "slightly" more knowledgeable now, Peter's suggestion of using bitbake -g 
-u depexp {image} and looking at the reverse depends for perl lead me to see 
that it was the external-linaro-toolchain recipe from the Arago layer that was 
bringing in perl. 
Doing some digging around I could see that 
meta-arago-extras/recipes-core/meta/external-arago-toolchain.bb is including 
recipes-core/eglibc/eglibc-package.inc which has the RDEPENDS line perl on 
mtrace. 

Richards explanation of the dependency override lead me to the following line 
in my own distribution.conf file. 
RDEPENDS_${PN}-mtrace_pn-external-linaro-toolchain = ""

Now when I run bitbake -g -u depexp {image} I no longer see perl in the list of 
packages. 

I'm still not sure why it's "pn-external-linaro-toolchain" since the recipe 
file that includes eglibc-package.inc is called external-arago-toolchain.bb. 

I also tried to take a look in the manual for a description of overrides of 
this form and I didn't immediately see anything that covered this _pn-foo-bar 
syntax. I did find this section but it is a bit light and doesn't seem to cover 
this case
http://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#conditional-syntax-overrides

Am I missing something? 

Thanks, 
Matt S. 


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

Re: [yocto] Help me understand Openembedded variable expansion

[Richard Purdie]

On Tue, 2014-10-28 at 10:11 -0700, Matt Schuckmann wrote:
> So there is something I just don't get about how variables get
> created, expanded, interpreted, etc in Bitbake
> 
> For example I'm trying to copy some of the techniques in the Poky Tiny
> distribution to reduce my image size and build time. 
> One of the fragments is this one. 
> 
> # The mtrace script included by eglibc is a perl script. This means
> the system
> # will build perl in case this package is installed. Since we don't
> care about
> # this script, remove the dependency from here.
> RDEPENDS_${PN}-mtrace_pn-eglibc = ""
> 
> I put this in my distribution .conf file and I doesn't seem to do
> anything perl is still getting built. 
> Of course it doesn't help that I don't understand what does,
> especially in the context of the distribution .conf file. 
> 
> I also see hints in the code in debug output that the machine, image,
> or distribution names can automatically get appended to paths, or
> variables but I don't really understand how that works. 
> 
> I'm not even sure how to phrase a question around this, immediately
> I'd like to figure out why Perl is still getting built but ultimately
> I'd like to understand the variable rules better so I that I can
> better take advantage of this power tool. 

Perhaps have a look at "overrides" in the bitbake manual.

You can split RDEPENDS_${PN}-mtrace_pn-eglibc into components. Starting
on the RHS, "_pn-eglibc" is an override that applies to recipes where PN
= "eglibc". In those recipes, the variable becomes:

RDEPENDS_${PN}-mtrace = ""

and is basically overriding a dependency on perl that would other be
there, something like:

RDEPENDS_${PN}-mtrace = "perl".

Does that help?

Cheers,

Richard

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

[yocto] Help me understand Openembedded variable expansion

[Matt Schuckmann]

So there is something I just don't get about how variables get created, 
expanded, interpreted, etc in Bitbake

For example I'm trying to copy some of the techniques in the Poky Tiny 
distribution to reduce my image size and build time. 
One of the fragments is this one. 

# The mtrace script included by eglibc is a perl script. This means the system
# will build perl in case this package is installed. Since we don't care about
# this script, remove the dependency from here.
RDEPENDS_${PN}-mtrace_pn-eglibc = ""

I put this in my distribution .conf file and I doesn't seem to do anything perl 
is still getting built. 
Of course it doesn't help that I don't understand what does, especially in the 
context of the distribution .conf file. 

I also see hints in the code in debug output that the machine, image, or 
distribution names can automatically get appended to paths, or variables but I 
don't really understand how that works. 

I'm not even sure how to phrase a question around this, immediately I'd like to 
figure out why Perl is still getting built but ultimately I'd like to 
understand the variable rules better so I that I can better take advantage of 
this power tool. 

Thanks,
Matt S. 

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

Re: [yocto] yocto help needed

[Gaurang Shastri]

Hi,

You can go through bunch of very good documents available at
https://www.yoctoproject.org/documentation/current

For immediate, you can start with
http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html

//Gaurang Shastri


On Fri, May 23, 2014 at 10:09 AM, Pushpa Teja  wrote:

> Good morning,
> I want to start to work on yacto please z provide
> me the guidance how to start it .
>
> Regards ,
> pushpa
>
>
>
>
> > From: yocto-requ...@yoctoproject.org
> > Subject: yocto Digest, Vol 44, Issue 103
> > To: yocto@yoctoproject.org
> > Date: Thu, 22 May 2014 06:50:28 -0700
> >
> > Send yocto mailing list submissions to
> > yocto@yoctoproject.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://lists.yoctoproject.org/listinfo/yocto
> > or, via email, send a message with subject or body 'help' to
> > yocto-requ...@yoctoproject.org
> >
> > You can reach the person managing the list at
> > yocto-ow...@yoctoproject.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of yocto digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Re: help needed (Alexandru Vaduva)
> > 2. Re: help needed (Burton, Ross)
> > 3. Re: [meta-mingw] build error (Stefan Seefeld)
> > 4. Re: help needed (Paul Eggleton)
> > 5. Re: help needed (Alexandru Vaduva)
> > 6. Re: Help with building app recipe (Diego Sueiro)
> >
> >
> > ------
> >
> > Message: 1
> > Date: Thu, 22 May 2014 06:00:02 -0700 (PDT)
> > From: Alexandru Vaduva 
> > To: Paul Eggleton 
> > Cc: "yocto@yoctoproject.org" 
> > Subject: Re: [yocto] help needed
> > Message-ID:
> > <1400763602.12423.yahoomail...@web122506.mail.ne1.yahoo.com>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > The hack will put the line: require perl-ptest.incinside a if structure.
> > The if will test if ptest is in the image-features or not.
> >
> >
> > On Thursday, May 22, 2014 3:43 PM, Paul Eggleton <
> paul.eggle...@linux.intel.com> wrote:
> >
> >
> >
> > On Thursday 22 May 2014 05:38:41 Alexandru Vaduva wrote:
> > > it appear, it shouldn`t I believe.
> > > I have a hack to include the perl-ptest module only when
> > > ptest enabled on image_featuresbut it does not look nice.
> > > I do not believe this solves the problem.
> >
> > Sorry, I'm not quite following. What is this hack?
> >
> >
> > Cheers,
> > Paul
> >
> > --
> >
> > Paul Eggleton
> > Intel Open Source Technology Centre
> > -- next part --
> > An HTML attachment was scrubbed...
> > URL: <
> http://lists.yoctoproject.org/pipermail/yocto/attachments/20140522/44f84bb2/attachment-0001.html
> >
> >
> > --
> >
> > Message: 2
> > Date: Thu, 22 May 2014 14:09:24 +0100
> > From: "Burton, Ross" 
> > To: Alexandru Vaduva 
> > Cc: Paul Eggleton ,
> > "yocto@yoctoproject.org" 
> > Subject: Re: [yocto] help needed
> > Message-ID:
> > 
> > Content-Type: text/plain; charset=UTF-8
> >
> > On 22 May 2014 13:38, Alexandru Vaduva 
> wrote:
> > > it appear, it shouldn`t I believe.
> >
> > Can you share this depends.dot file please? For what it's worth, I
> > can't replicate this with oe-core master
> >
> > Ross
> >
> >
> > --
> >
> > Message: 3
> > Date: Thu, 22 May 2014 09:10:30 -0400
> > From: Stefan Seefeld 
> > To: Richard Purdie 
> > Cc: yocto@yoctoproject.org
> > Subject: Re: [yocto] [meta-mingw] build error
> > Message-ID: <537df746.6060...@mentor.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > On 2014-05-22 02:10, Richard Purdie wrote:
> > > On Wed, 2014-05-21 at 16:45 -0400, Stefan Seefeld wrote:
> > >> Hello,
> > >>
> > >> I started experimenting with the meta-mingw layer today, using the
> > >> 'daisy' branch for both, poky as well as meta-mingw.
> > >>
> > >> Running `bitbake meta-toolchain`, the build process failed in one of
> the
> > >> last steps (1003 of 1005) with:
> > >>
> > >> ERROR: nativesdk-packagegroup-sdk-host not found in the base feeds
> &g

Re: [yocto] yocto help needed

[Pushpa Teja]

Good morning,
I want to start to work on yacto please z provide me 
the guidance how to start it .

Regards ,
pushpa




> From: yocto-requ...@yoctoproject.org
> Subject: yocto Digest, Vol 44, Issue 103
> To: yocto@yoctoproject.org
> Date: Thu, 22 May 2014 06:50:28 -0700
> 
> Send yocto mailing list submissions to
>   yocto@yoctoproject.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.yoctoproject.org/listinfo/yocto
> or, via email, send a message with subject or body 'help' to
>   yocto-requ...@yoctoproject.org
> 
> You can reach the person managing the list at
>   yocto-ow...@yoctoproject.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of yocto digest..."
> 
> 
> Today's Topics:
> 
>1. Re: help needed (Alexandru Vaduva)
>2. Re: help needed (Burton, Ross)
>3. Re: [meta-mingw] build error (Stefan Seefeld)
>4. Re: help needed (Paul Eggleton)
>5. Re: help needed (Alexandru Vaduva)
>6. Re: Help with building app recipe (Diego Sueiro)
> 
> 
> --
> 
> Message: 1
> Date: Thu, 22 May 2014 06:00:02 -0700 (PDT)
> From: Alexandru Vaduva 
> To: Paul Eggleton 
> Cc: "yocto@yoctoproject.org" 
> Subject: Re: [yocto] help needed
> Message-ID:
>   <1400763602.12423.yahoomail...@web122506.mail.ne1.yahoo.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> The hack will put the line: require perl-ptest.incinside a if structure.
> The if will test if ptest is in the image-features or not.
> 
> 
> On Thursday, May 22, 2014 3:43 PM, Paul Eggleton 
>  wrote:
>  
> 
> 
> On Thursday 22 May 2014 05:38:41 Alexandru Vaduva wrote:
> > it appear, it shouldn`t I believe.
> > I have a hack to include the perl-ptest module only when
> > ptest enabled on image_featuresbut it does not look nice.
> > I do not believe this solves the problem.
> 
> Sorry, I'm not quite following. What is this hack?
> 
> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.yoctoproject.org/pipermail/yocto/attachments/20140522/44f84bb2/attachment-0001.html>
> 
> --
> 
> Message: 2
> Date: Thu, 22 May 2014 14:09:24 +0100
> From: "Burton, Ross" 
> To: Alexandru Vaduva 
> Cc: Paul Eggleton ,
>   "yocto@yoctoproject.org" 
> Subject: Re: [yocto] help needed
> Message-ID:
>   
> Content-Type: text/plain; charset=UTF-8
> 
> On 22 May 2014 13:38, Alexandru Vaduva  wrote:
> > it appear, it shouldn`t I believe.
> 
> Can you share this depends.dot file please?  For what it's worth, I
> can't replicate this with oe-core master
> 
> Ross
> 
> 
> --
> 
> Message: 3
> Date: Thu, 22 May 2014 09:10:30 -0400
> From: Stefan Seefeld 
> To: Richard Purdie 
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] [meta-mingw] build error
> Message-ID: <537df746.6060...@mentor.com>
> Content-Type: text/plain; charset="utf-8"
> 
> On 2014-05-22 02:10, Richard Purdie wrote:
> > On Wed, 2014-05-21 at 16:45 -0400, Stefan Seefeld wrote:
> >> Hello,
> >>
> >> I started experimenting with the meta-mingw layer today, using the
> >> 'daisy' branch for both, poky as well as meta-mingw.
> >>
> >> Running `bitbake meta-toolchain`, the build process failed in one of the
> >> last steps (1003 of 1005) with:
> >>
> >> ERROR: nativesdk-packagegroup-sdk-host not found in the base feeds
> >> (x86_64-nativesdk-mingw32 noarch any all).
> >>
> >> Any idea what I may be missing ? I'm using
> >>
> >> MACHINE ??= "qemux86"
> >> SDKMACHINE ?= "x86_64-mingw32"
> > 
> > Which pacxkage backend were you using? If you didn't use ipk, I'd
> > suggest trying it. In theory others should work but its ipk I've been
> > using when working with those layers.
> 
> OK, I was using rpm (the default), but now switched to ipk. That results
> in a different error in meta/lib/oe/sdk.py:55, where do_populate() tries
> to link ld.so.cache into a non-existent directory.
> I have attempted a fix with the attached patch.
> 
> With that, things now appear to be working. (I think things should also
> work with 'rpm' as package backend, thou

Re: [yocto] help needed

[Alexandru Vaduva]

Thanks Ross, obviously I had the problem right in front of me but I did not 
understood it.
Could you please explain it to me. I do not quite get the perl-modules notion.

Thanks once again,
Alex


Thanks Hello 
On Thursday, May 22, 2014 5:30 PM, "Burton, Ross"  wrote:
 


FYI, I've just sent my fix to the oe-core mailing list.

Ross


On 22 May 2014 15:05, Burton, Ross  wrote:
> On 22 May 2014 14:24, Alexandru Vaduva  wrote:
>> I attached the depends .dot file and also a small perl-ptest.info file with
>> only the perl-ptest occurences.
>
> Right, so the dependency comes from perl-modules.  This is a meta
> package that depends on all the modules, and clearly perl-ptest
> shouldn't be in that list.
>
> (I've almost got a fix sorted)
>
> Ross-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] help needed

[Burton, Ross]

FYI, I've just sent my fix to the oe-core mailing list.

Ross

On 22 May 2014 15:05, Burton, Ross  wrote:
> On 22 May 2014 14:24, Alexandru Vaduva  wrote:
>> I attached the depends .dot file and also a small perl-ptest.info file with
>> only the perl-ptest occurences.
>
> Right, so the dependency comes from perl-modules.  This is a meta
> package that depends on all the modules, and clearly perl-ptest
> shouldn't be in that list.
>
> (I've almost got a fix sorted)
>
> Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] help needed

[Burton, Ross]

On 22 May 2014 14:24, Alexandru Vaduva  wrote:
> I attached the depends .dot file and also a small perl-ptest.info file with
> only the perl-ptest occurences.

Right, so the dependency comes from perl-modules.  This is a meta
package that depends on all the modules, and clearly perl-ptest
shouldn't be in that list.

(I've almost got a fix sorted)

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

Re: [yocto] Help with building app recipe

[Diego Sueiro]

Folks,

I'm trying to accomplish this in a 64bits host machine. But I'm getting
errors the following error on compile task:

| In file included from
//tmp/sysroots/x86_64-linux/usr/include/python3.3m/Python.h:50:0,
|  from ../../git/src/qpython_priv.h:22,
|  from moc_qpython_priv.cpp:9:
| //sysroots/x86_64-linux/usr/include/python3.3m/pyport.h:820:2:
error: #error "LONG_BIT definition appears wrong for platform (bad
gcc/glibc config?)."
|  #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc
config?)."
|   ^


Searching on Google it says that this is a known bug when trying to
cross-compile Python stuff for 32bits machines on 64bits hosts.

It seems that the guys from Buildroot could get this solved:
http://lists.busybox.net/pipermail/buildroot/2011-August/045257.html
I'm trying to find the "magical" patch to how to get this fixed.

Also found this link too:
http://blog.devork.be/2009/02/compiling-32-bit-python-on-amd64.html

But I'm not quite sure how to get this fixed on Yocto. Should it need to be
fixed on the pyotherside, or python3, or python3-native recipe?


Any directions are appreciated.



Regards,

--
*dS
Diego Sueiro

Administrador do Embarcados
www.embarcados.com.br

/*long live rock 'n roll*/


On Sat, May 17, 2014 at 2:18 AM, Khem Raj  wrote:

> On Fri, May 16, 2014 at 5:33 AM, Neuer User  wrote:
> > If I change the sed line to "#!/usr/bin/env python3", that would
> > probably work then. But would it break something else?
>
> would be fine.
> --
> ___
> 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] help needed

[Alexandru Vaduva]

I attached the depends .dot file and also a small perl-ptest.info file with 
only the perl-ptest occurences.

On Thursday, May 22, 2014 4:15 PM, Paul Eggleton 
 wrote:
 


On Thursday 22 May 2014 06:00:02 Alexandru Vaduva wrote:
> On Thursday, May 22, 2014 3:43 PM, Paul Eggleton
>  wrote:
> > On Thursday 22 May 2014 05:38:41 Alexandru Vaduva wrote:
> > > it appear, it shouldn`t I believe.
> > > I have a hack to include the perl-ptest module only when
> > > ptest enabled on image_featuresbut it does not look nice.
> > > I do not believe this solves the problem.
> > 
> > Sorry, I'm not quite following. What is this hack?
>
> The hack will put the line: require perl-ptest.incinside a if structure.
> The if will test if ptest is in the image-features or not.

There's nothing in that file that explicitly adds a dependency from perl (or 
any other package) on the perl-ptest package. So far as far as I know, nobody 
has yet reproduced the issue you're reporting. Are you building the exact same 
version of the perl recipe? Have you modified the recipe at all?


Cheers,
Paul

-- 

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

Re: [yocto] help needed

[Paul Eggleton]

On Thursday 22 May 2014 06:00:02 Alexandru Vaduva wrote:
> On Thursday, May 22, 2014 3:43 PM, Paul Eggleton
>  wrote:
> > On Thursday 22 May 2014 05:38:41 Alexandru Vaduva wrote:
> > > it appear, it shouldn`t I believe.
> > > I have a hack to include the perl-ptest module only when
> > > ptest enabled on image_featuresbut it does not look nice.
> > > I do not believe this solves the problem.
> > 
> > Sorry, I'm not quite following. What is this hack?
>
> The hack will put the line: require perl-ptest.incinside a if structure.
> The if will test if ptest is in the image-features or not.

There's nothing in that file that explicitly adds a dependency from perl (or 
any other package) on the perl-ptest package. So far as far as I know, nobody 
has yet reproduced the issue you're reporting. Are you building the exact same 
version of the perl recipe? Have you modified the recipe at all?

Cheers,
Paul

-- 

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

Re: [yocto] help needed

[Burton, Ross]

On 22 May 2014 13:38, Alexandru Vaduva  wrote:
> it appear, it shouldn`t I believe.

Can you share this depends.dot file please?  For what it's worth, I
can't replicate this with oe-core master

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

Re: [yocto] help needed

[Alexandru Vaduva]

The hack will put the line: require perl-ptest.incinside a if structure.
The if will test if ptest is in the image-features or not.


On Thursday, May 22, 2014 3:43 PM, Paul Eggleton 
 wrote:
 


On Thursday 22 May 2014 05:38:41 Alexandru Vaduva wrote:
> it appear, it shouldn`t I believe.
> I have a hack to include the perl-ptest module only when
> ptest enabled on image_featuresbut it does not look nice.
> I do not believe this solves the problem.

Sorry, I'm not quite following. What is this hack?


Cheers,
Paul

-- 

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

Re: [yocto] help needed

[Paul Eggleton]

On Thursday 22 May 2014 05:38:41 Alexandru Vaduva wrote:
> it appear, it shouldn`t I believe.
> I have a hack to include the perl-ptest module only when
> ptest enabled on image_featuresbut it does not look nice.
> I do not believe this solves the problem.

Sorry, I'm not quite following. What is this hack?

Cheers,
Paul

-- 

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

Re: [yocto] help needed

[Alexandru Vaduva]

it appear, it shouldn`t I believe.
I have a hack to include the perl-ptest module only when 

ptest enabled on image_featuresbut it does not look nice.
I do not believe this solves the problem.


On Thursday, May 22, 2014 3:34 PM, Paul Eggleton 
 wrote:
 


On Thursday 22 May 2014 05:26:12 Alexandru Vaduva wrote:
> On Thursday, May 22, 2014 3:19 PM, Paul Eggleton
>  wrote:
> > On Thursday 22 May 2014 03:31:05 Alexandru Vaduva wrote:
> > > Does anyone has any input on the next bug:
> > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=6203
> > 
> > We discussed on IRC looking at the dependency graphs from buildhistory to
> > determine how the package is being brought in - so what did you find there?
>
> I do not have a conclusion from buildhistory, but maybe I do not
> know for what to look.

I would expect somewhere "-> perl-ptest" to appear in the depends.dot file for 
the image.


Cheers,
Paul

-- 

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

Re: [yocto] help needed

[Paul Eggleton]

On Thursday 22 May 2014 05:26:12 Alexandru Vaduva wrote:
> On Thursday, May 22, 2014 3:19 PM, Paul Eggleton
>  wrote:
> > On Thursday 22 May 2014 03:31:05 Alexandru Vaduva wrote:
> > > Does anyone has any input on the next bug:
> > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=6203
> > 
> > We discussed on IRC looking at the dependency graphs from buildhistory to
> > determine how the package is being brought in - so what did you find there?
>
> I do not have a conclusion from buildhistory, but maybe I do not
> know for what to look.

I would expect somewhere "-> perl-ptest" to appear in the depends.dot file for 
the image.

Cheers,
Paul

-- 

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

Re: [yocto] help needed

[Alexandru Vaduva]

Hello Paul I do not have a conclusion from buildhistory, but maybe I do not 
know for what to look.

On Thursday, May 22, 2014 3:19 PM, Paul Eggleton 
 wrote:
 


Hi Alex,


On Thursday 22 May 2014 03:31:05 Alexandru Vaduva wrote:
> Does anyone has any input on the next bug:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=6203

We discussed on IRC looking at the dependency graphs from buildhistory to 
determine how the package is being brought in - so what did you find there?

Cheers,
Paul

-- 

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

Re: [yocto] help needed

[Paul Eggleton]

Hi Alex,

On Thursday 22 May 2014 03:31:05 Alexandru Vaduva wrote:
> Does anyone has any input on the next bug:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=6203

We discussed on IRC looking at the dependency graphs from buildhistory to 
determine how the package is being brought in - so what did you find there?

Cheers,
Paul

-- 

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

[yocto] help needed

[Alexandru Vaduva]

Does anyone has any input on the next bug: 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=6203

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

[yocto] Help with qt-gstreamer recipe?

[Neuer User]

Hi

I need qt-gstreamer in my Qt5 app (because I am having problems with the
camera element).

I found a yocto recipe from Andrey Telepin and tried to modify it for
Qt5. It looks like this:

---
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=2d5025d4aa3495befef8f17206a5b0a1"
SECTION = "multimedia"

PR = "r0"

SRC_URI =
"http://gstreamer.freedesktop.org/src/qt-gstreamer/qt-gstreamer-0.10.3.tar.gz";

SRC_URI[md5sum] = "a5f73dfa50270a23a0b07af32304e162"
SRC_URI[sha256sum] =
"bfc4406bde003d9e2e9b7fb5d19c07349c304706ec5936160d988f28dac5dd78"

DEPENDS = "boost qtmultimedia gstreamer"

inherit cmake

do_configure() {
# Ensure we get the cmake configure and not qmake
cmake_do_configure
}


export EXTRA_OECMAKE = "-DQT_QMAKE_EXECUTABLE=${OE_QMAKE_QMAKE} \
-DQT_LRELEASE_EXECUTABLE=${OE_QMAKE_LRELEASE} \
-DQT_MOC_EXECUTABLE=${OE_QMAKE_MOC} \
-DQT_UIC_EXECUTABLE=${OE_QMAKE_UIC} \
-DQT_RCC_EXECUTABLE=${OE_QMAKE_RCC} \
-DQT_LIBRARY_DIR=${OE_QMAKE_LIBDIR_QT} \
-DQT_HEADERS_DIR=${OE_QMAKE_INCDIR_QT} \

-DQT_QTCORE_INCLUDE_DIR=${OE_QMAKE_INCDIR_QT}/QtCore \
-DQT_QTGUI_INCLUDE_DIR=${OE_QMAKE_INCDIR_QT}/QtGui \
-DQTGSTREAMER_EXAMPLES=ON  \
-DQT_VERSION=5 \
-DUSE_GST_PLUGIN_DIR=ON \
-DUSE_QT_PLUGIN_DIR=ON \
"
---

I get the following error during configure:

---
| -- Using Qt5 (min: 5.0.0)
| CMake Error at
/home/ubuntu/yocto/build/tmp/sysroots/cubox-i/usr/lib/cmake/Qt5Core/Qt5CoreConfig.cmake:27
(message):
|   The imported target "Qt5::Core" references the file
|
|  "/qmake"
|
|   but this file does not exist.  Possible reasons include:
|
|   * The file was deleted, renamed, or moved to another location.
|
|   * An install or uninstall procedure did not complete successfully.
|
|   * The installation package was faulty and contained
|
|
"/home/ubuntu/yocto/build/tmp/sysroots/cubox-i/usr/lib/cmake/Qt5Core/Qt5CoreConfigExtras.cmake"
|
|   but not all the files it references.
|
| Call Stack (most recent call first):
|
/home/ubuntu/yocto/build/tmp/sysroots/cubox-i/usr/lib/cmake/Qt5Core/Qt5CoreConfigExtras.cmake:6
(_qt5_Core_check_file_exists)
|
/home/ubuntu/yocto/build/tmp/sysroots/cubox-i/usr/lib/cmake/Qt5Core/Qt5CoreConfig.cmake:140
(include)
|   cmake/modules/FindQt4or5.cmake:69 (find_package)
|   CMakeLists.txt:24 (find_package)
-

It seems that OE_QMAKE_PATH_EXTERNAL_HOST_BINS is not defined. I have no
idea, however, where and how it should be defined correctly.

There is a file recipes-devtools/cmake/cmake_2.8.12.2.bbappend in the
meta-qt5 layer, which seems to address this problem somehow:


# Ugly hack to work around undefined OE_QMAKE_PATH_EXTERNAL_HOST_BINS
variable
# and possibly missing qmake binary (qtbase-native can be removed from
sysroot
# e.g. in order to upgrade it, even when there is target qtbase)

#| -- Performing Test run_pic_test - Success
#| CMake Error at
tmp-eglibc/sysroots/qemuarm/usr/lib/cmake/Qt5Core/Qt5CoreConfig.cmake:27
(message):
#|   The imported target "Qt5::Core" references the file
#|
#|  "/qmake"
#|
#|   but this file does not exist.  Possible reasons include:

do_configure_prepend() {
sed -i 's/^find_package(Qt5Core QUIET)$/#find_package(Qt5Core
QUIET)/g' ${S}/Tests/RunCMake/CMakeLists.txt
sed -i 's/^find_package(Qt5Core REQUIRED)/#find_package(Qt5Core
REQUIRED)/g' ${S}/Tests/RunCMake/IncompatibleQt/IncompatibleQt.cmake
sed -i 's/^  find_package(Qt5Widgets REQUIRED)/#
find_package(Qt5Widgets REQUIRED)/g' ${S}/Tests/QtAutomoc/CMakeLists.txt
sed -i 's/^find_package(Qt5Core REQUIRED)/#find_package(Qt5Core
REQUIRED)/g' ${S}/Tests/Qt4And5Automoc/CMakeLists.txt
sed -i 's/^  find_package(Qt5Widgets QUIET NO_MODULE)/#
find_package(Qt5Widgets QUIET NO_MODULE)/g' ${S}/Tests/CMakeLists.txt
sed -i 's/^find_package(Qt5Widgets QUIET)/#find_package(Qt5Widgets
QUIET)/g' ${S}/Source/QtDialog/CMakeLists.txt
}
---

Still, I have no idea how to fix the problem. Can anybody hint me into
the right direction?

Thanks a lot

Michael

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

Re: [yocto] Help with building app recipe

[Khem Raj]

On Fri, May 16, 2014 at 5:33 AM, Neuer User  wrote:
> If I change the sed line to "#!/usr/bin/env python3", that would
> probably work then. But would it break something else?

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

Re: [yocto] Help with building app recipe

[Neuer User]

Am 16.05.2014 14:16, schrieb Neuer User:
> Am 16.05.2014 14:04, schrieb Anders Darander:
> 
> Great, that helped with no 1.). Still a lot to learn for me.
> 
> No 2. is still open, though. Is that a problem of my recipe or rather a
> generic problem of the python3 recipe? I could patch the python3 recipe,
> so that it changes the interpreter line to "python3".
> 

Hmm the python3-native recipe has this install function:

--
do_install() {
install -d ${D}${libdir}/pkgconfig
oe_runmake 'DESTDIR=${D}' install
if [ -e ${WORKDIR}/sitecustomize.py ]; then
install -m 0644 ${WORKDIR}/sitecustomize.py
${D}/${libdir}/python${PYTHON_MAJMIN}
fi
install -d ${D}${bindir}/${PN}
install -m 0755 Parser/pgen ${D}${bindir}/${PN}

# Make sure we use /usr/bin/env python
for PYTHSCRIPT in `grep -rIl ${bindir}/${PN}/python
${D}${bindir}/${PN}`; do
sed -i -e '1s|^#!.*|#!/usr/bin/env python|' $PYTHSCRIPT
done
}
--


If I change the sed line to "#!/usr/bin/env python3", that would
probably work then. But would it break something else?

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

Re: [yocto] Help with building app recipe

[Neuer User]

Am 16.05.2014 14:04, schrieb Anders Darander:
> * Neuer User  [140516 13:24]:
> 
>> require recipes-qt/qt5/qt5.inc
>> 
> 
> 
>> It is WIP, so e.g. the license is stil wrong.
> 
>> The package depends on Qt5 and Python3.
> 
> In that case, I would have expected to see 
> 
> inherit python3native qmake5 
> 
> in your recipe.
> 
>> I am currently experiencing two (rather small) problems:
> 
>> 1.) the configure step does not find "python3-config". It is located in
>> tmp/sysroots/i686-linux/usr/bin/python3-native
> 
> I haven't used python3 in combination with OE yet. Though, this should
> likely have been handled by
> inherit python3native
> 
> Cheers,
> Anders
> 

Great, that helped with no 1.). Still a lot to learn for me.

No 2. is still open, though. Is that a problem of my recipe or rather a
generic problem of the python3 recipe? I could patch the python3 recipe,
so that it changes the interpreter line to "python3".

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

Re: [yocto] Help with building app recipe

[Anders Darander]

* Neuer User  [140516 13:24]:

> require recipes-qt/qt5/qt5.inc
> 


> It is WIP, so e.g. the license is stil wrong.

> The package depends on Qt5 and Python3.

In that case, I would have expected to see 

inherit python3native qmake5 

in your recipe.

> I am currently experiencing two (rather small) problems:

> 1.) the configure step does not find "python3-config". It is located in
> tmp/sysroots/i686-linux/usr/bin/python3-native

I haven't used python3 in combination with OE yet. Though, this should
likely have been handled by
inherit python3native

Cheers,
Anders

-- 
Anders Darander
ChargeStorm AB / eStorm AB
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Help with building app recipe

[Neuer User]

Hello

I am trying to build a simple recipe for a package called "pyotherside".
It currently looks like this:


SUMMARY = "Python3 bindings for Qt5"
DESCRIPTION = "New framework for including pyhton interpreter into Qt5 apps"
HOMEPAGE = "http://thp.io/2011/pyotherside/";
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR\}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

PV = "1.2+git${SRCPV}"

SRCREV = "87e5eaf4707261dfcb37d7daadef018266c83d5a"

SRC_URI = "git://github.com/thp/pyotherside.git;branch=master;protocol=git \
   "
S = "${WORKDIR}/git/"

DEPENDS = "qtdeclarative python3 python3-native"
RDEPENDS_${PN} = "qtdeclarative-qmlplugins"

require recipes-qt/qt5/qt5.inc



It is WIP, so e.g. the license is stil wrong.

The package depends on Qt5 and Python3.

I am currently experiencing two (rather small) problems:

1.) the configure step does not find "python3-config". It is located in
tmp/sysroots/i686-linux/usr/bin/python3-native

If I do a devshell and edit run.do_configure, I can add this path to the
PATH env variable, and then everything works.

How can I modify my recipe, so that this path is automatically added?

2.) The "python3-config" script just uses "#!/usr/bin/env python" to
define its interpreter, so the system starts the script with python2. If
I change the script manually, it works.

What would be the correct way to change my receipt to make it work? Or
would I need to change the python3 recipe to patch this file?

Thanks for your help!

Michael

P.S.: Seems, pyotherside is working nicely...

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

Re: [yocto] Help-Gstreamer Vaapi Plugin Issue in 1080p mp4 playback

[Meenakumari Shedole]

Hi.

I hope someone can help me with my questions.


We have built following Gst packages in Ubuntu 13.04
gstreamer-1.2.3
gst-plugins-base-1.2.3
gst-plugins-good-1.2.3
gst-plugins-bad-1.2.3
gst-plugins-ugly-1.2.3
gst-libav-1.2.3
libva-1.3.0
libva-intel-driver-1.3.0
gstreamer-vaapi-0.5.8

Our objective is to build gst-1.2.3 with latest vaapi support. On the way we 
have installed all other dependencies.

We have wrote an application(App1) to create a QT video widget and hence have 
the window id.

QWidget window;
window.resize(1920, 1080);
window.show();
WId xwinid = window.winId();


And another application (app2) to create gst-video pipe (filesrc-> qtdemux-> 
vaapidecode-> vaapisink) to test video overlay, where we are using following 
videooverlay api to test the foreign window,

gst_video_overlay_set_window_handle(GST_VIDEO_OVERLAY(vaapisink), aWindowId);

And App1 is sending wid to App2 through D-Bus.


Now Vaapi able to set the foreign window however, there is some troubling 
behaviors in vaapisink side.

a. First gst_video_overlay_set_window_handle to set the foreign window.
b. Play the pipe for some time (It works with foreign window) and Stop.
c. Second time Play, vaapisink creates its own window.
d. Stop the pipe.
e. Call gst_video_overlay_set_window_handle to set the foreign window again.
f. Start the pipe (It works with foreign window).

So instead of rending to the foreign window why vaapisink is creating its own 
window in all 2nd attempts to play?

Some time we are getting the following core dump while setting the windowid

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7900b40 (LWP 24910)]
0xb6109d8f in glXMakeCurrentReadSGI ()
   from /usr/lib/i386-linux-gnu/mesa/libGL.so.1
(gdb) bt
#0  0xb6109d8f in glXMakeCurrentReadSGI ()
   from /usr/lib/i386-linux-gnu/mesa/libGL.so.1
#1  0xb6109f13 in glXMakeCurrent ()
   from /usr/lib/i386-linux-gnu/mesa/libGL.so.1
#2  0xb645c994 in gl_set_current_context (new_cs=0xb78ff64c, old_cs=0x0)
at gstvaapiutils_glx.c:450
#3  0xb645e728 in gst_vaapi_window_glx_ensure_context (window=0xb6f14800, 
foreign_context=) at gstvaapiwindow_glx.c:217
#4  gst_vaapi_window_glx_ensure_context (window=0xb6f14800, 
foreign_context=) at gstvaapiwindow_glx.c:185
#5  0xb645e986 in gst_vaapi_window_glx_new_with_xid (
display=display@entry=0xb6f0f8e8, xid=xid@entry=62914566)
at gstvaapiwindow_glx.c:413
#6  0xb648f72b in gst_vaapisink_ensure_window_xid (window_id=62914566, 
sink=0xb6319000) at gstvaapisink.c:553
#7  gst_vaapisink_video_overlay_set_window_handle (overlay=0xb6319000, 
window=62914566) at gstvaapisink.c:179
#8  0xb7cd11a7 in gst_video_overlay_set_window_handle (overlay=0xb6319000, 
handle=62914566) at videooverlay.c:357

BTW, is there any way to test this scenario (setting the foreign window) with 
gst- commands only, which will remove our application overhead?

Thanks in advance,
Meena

From: Beauchesne, Gwenole [gwenole.beauche...@intel.com]
Sent: Thursday, April 03, 2014 8:22 PM
To: Meenakumari Shedole; yocto@yoctoproject.org
Cc: Dipesh Karmakar
Subject: RE: [yocto] Help-Gstreamer Vaapi Plugin Issue in 1080p mp4 playback

Hi,

> I have checked vaapisink source, it seems its supporting overlay on foreign X
> window.
> https://gitorious.org/vaapi/gstreamer-
> vaapi/source/643d35e87a67376af9cd89cd868666368b105ac3:gst/vaapisink/gs
> tvaapisink.c
> static gboolean gst_vaapisink_implements_interface_supported();
> static gboolean gst_vaapisink_ensure_window_xid();

The version you mention looks very old. I have integrated a fix from another 
user, who has been successfully using gstreamer-vaapi with GStreamer 0.10 in a 
scenario you describe (vaapisink + foreign window). Please update your 
gstreamer-vaapi version to at least 0.5.8. Or, the current git master tree. 
Other branches are not maintained any more. The fix I have in mind was f8666e2.

Regards,
Gwenole.

> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Friday, March 28, 2014 4:42 PM
> To: Meenakumari Shedole
> Cc: yocto@yoctoproject.org; Dipesh Karmakar
> Subject: Re: [yocto] Help-Gstreamer Vaapi Plugin Issue in 1080p mp4
> playback
>
> On 28 March 2014 06:05, Meenakumari Shedole 
> wrote:
> > 1. playbin2 + avi/3gp is working properly because of xvimagesink is used
> interally.
> > 2. playbin2 + mp4 is not taking vaapi sink, we need to manually set video-
> sink=vaapisink.
> >Also we are getting arbitrary crash while setting the qml video window id
> to the vaapi sink.
> >So we are not getting any single pipe to play mp4/avi/3gp stuff.
>
> The important question is what recipe are you using to get the vaapi
> elements?
>
> What happens if you use vaapisink with AVI/3GP?  You should still get some
> acceleration.
>
> Note

Re: [yocto] Help-Gstreamer Vaapi Plugin Issue in 1080p mp4 playback

[Meenakumari Shedole]

Hi All.

We have built following Gst packages in Ubuntu 13.04
gstreamer-1.2.3
gst-plugins-base-1.2.3
gst-plugins-good-1.2.3
gst-plugins-bad-1.2.3
gst-plugins-ugly-1.2.3
gst-libav-1.2.3
libva-1.3.0
libva-intel-driver-1.3.0
gstreamer-vaapi-0.5.8

Our objective is to build gst-1.2.3 with latest vaapi support. On the way we 
have installed all other dependencies.

We have wrote an application(App1) to create a QT video widget and hence have 
the window id.

QWidget window;
window.resize(1920, 1080);
window.show();
WId xwinid = window.winId();


And another application (app2) to create gst-video pipe (filesrc-> qtdemux-> 
vaapidecode-> vaapisink) to test video overlay, where we are using following 
videooverlay api to test the foreign window,

gst_video_overlay_set_window_handle(GST_VIDEO_OVERLAY(vaapisink), aWindowId);

And App1 is sending wid to App2 through D-Bus.


Now Vaapi able to set the foreign window however, there is some troubling 
behaviors in vaapisink side.

a. First gst_video_overlay_set_window_handle to set the foreign window.
b. Play the pipe for some time (It works with foreign window) and Stop.
c. Second time Play, vaapisink creates its own window.
d. Stop the pipe.
e. Call gst_video_overlay_set_window_handle to set the foreign window again.
f. Start the pipe (It works with foreign window).

So instead of rending to the foreign window why vaapisink is creating its own 
window in all 2nd attempts to play?

Some time we are getting the following core dump while setting the windowid

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7900b40 (LWP 24910)]
0xb6109d8f in glXMakeCurrentReadSGI ()
   from /usr/lib/i386-linux-gnu/mesa/libGL.so.1
(gdb) bt
#0  0xb6109d8f in glXMakeCurrentReadSGI ()
   from /usr/lib/i386-linux-gnu/mesa/libGL.so.1
#1  0xb6109f13 in glXMakeCurrent ()
   from /usr/lib/i386-linux-gnu/mesa/libGL.so.1
#2  0xb645c994 in gl_set_current_context (new_cs=0xb78ff64c, old_cs=0x0)
at gstvaapiutils_glx.c:450
#3  0xb645e728 in gst_vaapi_window_glx_ensure_context (window=0xb6f14800, 
foreign_context=) at gstvaapiwindow_glx.c:217
#4  gst_vaapi_window_glx_ensure_context (window=0xb6f14800, 
foreign_context=) at gstvaapiwindow_glx.c:185
#5  0xb645e986 in gst_vaapi_window_glx_new_with_xid (
display=display@entry=0xb6f0f8e8, xid=xid@entry=62914566)
at gstvaapiwindow_glx.c:413
#6  0xb648f72b in gst_vaapisink_ensure_window_xid (window_id=62914566, 
sink=0xb6319000) at gstvaapisink.c:553
#7  gst_vaapisink_video_overlay_set_window_handle (overlay=0xb6319000, 
window=62914566) at gstvaapisink.c:179
#8  0xb7cd11a7 in gst_video_overlay_set_window_handle (overlay=0xb6319000, 
handle=62914566) at videooverlay.c:357

BTW, is there any way to test this scenario (setting the foreign window) with 
gst- commands only, which will remove our application overhead?

Thanks in advance,
Meena

From: Beauchesne, Gwenole [gwenole.beauche...@intel.com]
Sent: Thursday, April 03, 2014 8:22 PM
To: Meenakumari Shedole; yocto@yoctoproject.org
Cc: Dipesh Karmakar
Subject: RE: [yocto] Help-Gstreamer Vaapi Plugin Issue in 1080p mp4 playback

Hi,

> I have checked vaapisink source, it seems its supporting overlay on foreign X
> window.
> https://gitorious.org/vaapi/gstreamer-
> vaapi/source/643d35e87a67376af9cd89cd868666368b105ac3:gst/vaapisink/gs
> tvaapisink.c
> static gboolean gst_vaapisink_implements_interface_supported();
> static gboolean gst_vaapisink_ensure_window_xid();

The version you mention looks very old. I have integrated a fix from another 
user, who has been successfully using gstreamer-vaapi with GStreamer 0.10 in a 
scenario you describe (vaapisink + foreign window). Please update your 
gstreamer-vaapi version to at least 0.5.8. Or, the current git master tree. 
Other branches are not maintained any more. The fix I have in mind was f8666e2.

Regards,
Gwenole.

> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Friday, March 28, 2014 4:42 PM
> To: Meenakumari Shedole
> Cc: yocto@yoctoproject.org; Dipesh Karmakar
> Subject: Re: [yocto] Help-Gstreamer Vaapi Plugin Issue in 1080p mp4
> playback
>
> On 28 March 2014 06:05, Meenakumari Shedole 
> wrote:
> > 1. playbin2 + avi/3gp is working properly because of xvimagesink is used
> interally.
> > 2. playbin2 + mp4 is not taking vaapi sink, we need to manually set video-
> sink=vaapisink.
> >Also we are getting arbitrary crash while setting the qml video window id
> to the vaapi sink.
> >So we are not getting any single pipe to play mp4/avi/3gp stuff.
>
> The important question is what recipe are you using to get the vaapi
> elements?
>
> What happens if you use vaapisink with AVI/3GP?  You should still get some
> acceleration.
>
> Note that especially when using vaapi sink you need

Re: [yocto] Help-Gstreamer Vaapi Plugin Issue in 1080p mp4 playback

[Meenakumari Shedole]

Hi All.

By using all latest version packages, Vaapi able to set the foreign window but 
there is random changes between Application and VaapiSink in SetWindowId, Play 
and Stop state.
 
Below are few of the different behaviors.

a.  To play 1080p media, First SetWindowID, Play and Stop. ( It works with 
foreign window)
b.  To play 1080p media, Second time only Play and Stop. (It won't work) and 
crash the daemon.
c.  start the daemon and app
d.  This time again SetWindowID, Play and Stop. (It works with foreign window)
e.  Only Play and Stop.( it works and won't crash the daemon also)
f.   Next time again setWindowID, Play and Stop. (it won't works)
g.  Next again to SetWindowID, Play and Stop.(it works)

Some times when I use only Play and Stop it open it's own window and start to 
play.

Regards
Meenakumari Shedole

From: Meenakumari Shedole
Sent: Friday, April 04, 2014 4:19 PM
To: Beauchesne, Gwenole; yocto@yoctoproject.org
Cc: Dipesh Karmakar
Subject: RE: [yocto] Help-Gstreamer Vaapi Plugin Issue in 1080p mp4 playback

Thanks for your resposne Gwenole.

I downloaded updated gstreamer-vaapi-0.5.8 and GStreamer-0.10.36 with other 
dependency plaugins and va deriver but after manually install no luck to 
execute vaapisink.

can you please suggest, vaapi dependencies and their version to build.

Regards
Meena.

From: Beauchesne, Gwenole [gwenole.beauche...@intel.com]
Sent: Thursday, April 03, 2014 8:22 PM
To: Meenakumari Shedole; yocto@yoctoproject.org
Cc: Dipesh Karmakar
Subject: RE: [yocto] Help-Gstreamer Vaapi Plugin Issue in 1080p mp4 playback

Hi,

> I have checked vaapisink source, it seems its supporting overlay on foreign X
> window.
> https://gitorious.org/vaapi/gstreamer-
> vaapi/source/643d35e87a67376af9cd89cd868666368b105ac3:gst/vaapisink/gs
> tvaapisink.c
> static gboolean gst_vaapisink_implements_interface_supported();
> static gboolean gst_vaapisink_ensure_window_xid();

The version you mention looks very old. I have integrated a fix from another 
user, who has been successfully using gstreamer-vaapi with GStreamer 0.10 in a 
scenario you describe (vaapisink + foreign window). Please update your 
gstreamer-vaapi version to at least 0.5.8. Or, the current git master tree. 
Other branches are not maintained any more. The fix I have in mind was f8666e2.

Regards,
Gwenole.

> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Friday, March 28, 2014 4:42 PM
> To: Meenakumari Shedole
> Cc: yocto@yoctoproject.org; Dipesh Karmakar
> Subject: Re: [yocto] Help-Gstreamer Vaapi Plugin Issue in 1080p mp4
> playback
>
> On 28 March 2014 06:05, Meenakumari Shedole 
> wrote:
> > 1. playbin2 + avi/3gp is working properly because of xvimagesink is used
> interally.
> > 2. playbin2 + mp4 is not taking vaapi sink, we need to manually set video-
> sink=vaapisink.
> >Also we are getting arbitrary crash while setting the qml video window id
> to the vaapi sink.
> >So we are not getting any single pipe to play mp4/avi/3gp stuff.
>
> The important question is what recipe are you using to get the vaapi
> elements?
>
> What happens if you use vaapisink with AVI/3GP?  You should still get some
> acceleration.
>
> Note that especially when using vaapi sink you need to wait for the sink to
> create the window and then reparent it, you can't provide your own X
> window to vaapisink.  This is the usual cause for breakage.  Do testing with
> gst-launch before attempting to use your own application.
>
> Ross
>
>
> ::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
> p

Re: [yocto] Help with Beagleboard Black

[Georgescu, Alexandru C]

Correction, the board is BeagleBone Black*.

--
Alexandru Georgescu

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Georgescu, Alexandru C
Sent: Monday, April 07, 2014 7:21 PM
To: yocto@yoctoproject.org
Subject: [yocto] Help with Beagleboard Black

Hello,
How can I setup properly an SD card to boot the BeagleBoard Black board with a 
Yocto built image from AB (I need the exact steps for the sato-sdk image). The 
image I want to boot can be found exactly here: 
http://autobuilder.yoctoproject.org/pub/releases/yocto-1.6_M5.rc2/machines/beaglebone/

Regards,
--
Alexandru Georgescu
Yocto QA Engineer
SSG/SSD Open Source Technology Center Romania

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