[yocto] [meta-freescale][NXP] Failed to build gstreamer1.0 ith Yocto thud on NXP IMX8MQ

[Karim ATIKI]

Hi,



I'm currently trying to build gstreamer1.0 with Yocto Thud.

My host machine is a Debian 9 (stretch) Linux.

It always succeeded with previous version of Yocto rocko and sumo.



But there with thud I immediately get an Unpack Error I've never experienced 
before:



ERROR: gstreamer1.0-1.14.4.imx-r0 do_unpack: gitsm: submodule unpack failed: 
UnpackError Unpack failure for URL: 
'gitsm://anongit.freedesktop.org/git/gstreamer/common.git;protocol=https;name=common;subpath=common;bareclone=1;nobranch=1'.
 No up to date source found: clone directory not available or not up to date: 
/opt/yocto/imx8/fsl-imx8-thud-4.19.35-1.0.0/../../downloads/git2/anongit.freedesktop.org.git.gstreamer.common.git;
 shallow clone not enabled
ERROR: gstreamer1.0-1.14.4.imx-r0 do_unpack: Unpack failure for URL: 
'gitsm://anongit.freedesktop.org/git/gstreamer/common.git;protocol=https;name=common;subpath=common;bareclone=1;nobranch=1'.
 No up to date source found: clone directory not available or not up to date: 
/opt/yocto/imx8/fsl-imx8-thud-4.19.35-1.0.0/../../downloads/git2/anongit.freedesktop.org.git.gstreamer.common.git;
 shallow clone not enabled
ERROR: gstreamer1.0-1.14.4.imx-r0 do_unpack: Function failed: base_do_unpack
ERROR: Logfile of failure stored in: 
/opt/yocto/imx8/fsl-imx8-thud-4.19.35-1.0.0/build/tmp/work/aarch64-poky-linux/gstreamer1.0/1.14.4.imx-r0/temp/log.do_unpack.27700
ERROR: Task 
(/opt/yocto/imx8/fsl-imx8-thud-4.19.35-1.0.0/sources/meta-freescale/recipes-multimedia/gstreamer/gstreamer1.0_1.14.imx.bb:do_unpack)
 failed with exit code '1'



I've attached the log.do_unpack file. I tried to clean everything up, but I 
still get this annoying error and I'm stuck with it for a while now.




Any suggestion is really welcome



Thanks.



Karim



log.do_unpack.27700
Description: log.do_unpack.27700
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [bitbake] fsl-image-xwayland DISTRO -- can't get rid of dev packages.

[Karim ATIKI]

Hi all,


I've created a custom image based on core-image.

It runs for an i.MX6 and i.MX8.

I've installed only Qt, gstreamer and xwayland stuff.


I've removed dev-pkgs, dbg-pkgs and staticdev-pkgs from IMAGE_FEATURES.


Finally, in the created image, ALL the dpg, dev packages have been installed, 
with tons of .h header files. static .a files etc.

I've tried everything and just can't figure out how to get rid of them.


Any idea ?


Thanks.


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

[yocto] meta layers for freescale IMX8 ?

[Karim ATIKI]

Hi all,

We just received some evaluation boards based on Freescale IMX8 Quad.
We'll have to firstly build a custom linux image to test our products.
I'm not experienced with freescales processors.

Is there some layers managing the recent IMX8 Freescale ?

Thanks .

K

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

[yocto] [bitbake] Failed to launch bitbake image -u -g depexp on a Debian 9 host system ?

[Karim ATIKI]

Hi all,


I'm currently using Yocto Poky pyro on a Debian 9 host.

I tried to launch bitbake -u -g depexp to have the GUI window with dependencies 
but I got the following errors:


Unable to init server: Could not connect: Connection refused
Unable to init server: Could not connect: Connection refused
FATAL: Unable to import extension module "depexp" from bb.ui. Valid extension 
modules: knotty, ncurses or taskexp
DEBUG: Removed the following variables from the environment: GJS_DEBUG_TOPICS, 
SESSION_MANAGER, LS_COLORS, XDG_MENU_PREFIX, _, VTE_VERSION, XDG_SESSION_ID, 
QT_LINUX_ACCESSIBILITY_ALWAYS_ON, WINDOWPATH, GJS_DEBUG_OUTPUT, GPG_AGENT_INFO, 
XDG_VTNR, XAUTHORITY, QT_QPA_PLATFORMTHEME, XDG_RUNTIME_DIR, 
GNOME_DESKTOP_SESSION_ID, XDG_CURRENT_DESKTOP, QT_ACCESSIBILITY, 
JOURNAL_STREAM, WINDOWID, DISPLAY, XDG_DATA_DIRS, GTK_MODULES, BUILDDIR, 
XDG_SESSION_DESKTOP, DBUS_SESSION_BUS_ADDRESS, COLORTERM, OLDPWD, GDM_LANG, 
XDG_SEAT, GDMSESSION, DESKTOP_SESSION, SHLVL, LANG, XDG_SESSION_TYPE, USERNAME

Is it related to Debian 9 ?

Anyone has experienced this problem ?


Thanks.


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

[yocto] [bitbake] How to figure out that a recipe is executed during the populatye_sdk task ?

[Karim ATIKI]

I wrote a recipe for our ARM board linux that compiles a bunch of sources and 
produces some binary executables for the target board.


Everything is done properly with do_compile, do_install etc.

The binary executables that need to be deployed on the target board are 
installed in do_install handler.



Now, as we build the related SDK of our image (using bitbake -k my-image -c 
populate_sdk) we need to install more binaries  from the recipe above.


Is there a flag in Yocto that indicates us that the recipe is called during a 
populate_sdk task ?


What's the right proper way to achieve it, knowing that we are obliged by the 
board vendor to use poky Dora.


Thanks.


Best Regards,


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

[yocto] [bitbake] Conditional Linux Kernel compilation according to Yocto Variables

[Karim ATIKI]

I'm using Yocto (Poky Dora is mandatory for our project) to create a Linux 
image for an ARM base board.

Currently, we're working on an evaluation board.

We have a dedicated layer (meta-docking) with all the stuff.

We have dedicated recipes that installs a specific version of the Linux Kernel 
and some specific patch as well.

As we create the image:


bitbake -k docking-image


Now, we're moving toward the final board to be used in production. It differs 
from the evaluation board as some connectors are added (lighting etc.).

Therefore, the Linux Kernel being installed is slightly different, some source 
files need to be replaced/patched/modified consequently.


My colleague, firstly chose to create another copy of the layer (i.e. 
meta-docking-prod).

This option does not satisfy us, I'm sure Yocto provides mechanisms to apply 
taks according to the target.


My question is, for example, how to apply different patches on a Linux kernel 
(or any yocto resource file) according to user's variable ? or according to the 
target machine ?

Without having to duplicate layers.


Thanks.


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

Re: [yocto] [bitbake] Failed to patch "defconfig" for linux kernel

[Karim ATIKI]

OK.
But how then is this file "bt.cfg" included in the compilation process ?




De : Khem Raj <raj.k...@gmail.com>
Envoyé : vendredi 10 mars 2017 19:53
À : Karim ATIKI
Objet : Re: [yocto] [bitbake] Failed to patch "defconfig" for linux kernel



On Fri, Mar 10, 2017 at 10:47 AM, Karim ATIKI 
<karim_at...@hotmail.com<mailto:karim_at...@hotmail.com>> wrote:

Hi Khem,


>You can edit do_configure_prepend() in linux-rpi.inc
>kernel_configure_variable CONFIG_BT y


Ok.

But this file "linux-rpi.inc" is available only for RaspberryPi ?

I'm not working on Rpi here.


Somehow I thought you were, anyhow if you are using linux-yocto then you can 
create a .cfg file e.g.
bt.cfg with

CONFIG_BT=y
CONFIG_BT_RFCOMM=y
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_HCIBTUSB=y
CONFIG_WIRELESS=y

and add it to SRC_URI e.g.

SRC_URI += "file://bt.cfg"

that should do it.







De : Khem Raj <raj.k...@gmail.com<mailto:raj.k...@gmail.com>>
Envoyé : vendredi 10 mars 2017 19:13
À : Karim ATIKI
Cc : yocto
Objet : Re: [yocto] [bitbake] Failed to patch "defconfig" for linux kernel

On Fri, Mar 10, 2017 at 6:50 AM, Karim ATIKI 
<karim_at...@hotmail.com<mailto:karim_at...@hotmail.com>> wrote:
> Hi,
>
>
> I'm currently trying to patch the linux kernel 3.8.13-r2 of an ARM based
> board (Hachiko) in order to enable Bluetooth and RFCOMM support.
>
>
> Currently, I select these options with bitbake -c menuconfig virtual/kernel
>
> I'd like to use a patch on the defconfig in order to avoid the menuconfig
> step.
>
>
> I've created a linux_3.8.13.bbappend file to apply the path.
>
>
> Th patch file looks like:
>
>
>
> --- a defconfig
> +++ b defconfig
> @@ -107,3 +107,16 @@
>  CONFIG_CRYPTO_CBC=y
>  CONFIG_CRYPTO_MD5=y
>  CONFIG_CRYPTO_DES=y
> +#
> +# FIR device drivers
> +#
> +CONFIG_BT=y
> +CONFIG_BT_RFCOMM=y
> +CONFIG_BT_RFCOMM_TTY=y
> +
> +#
> +# Bluetooth device drivers
> +#
> +CONFIG_BT_HCIBTUSB=y
> +CONFIG_WIRELESS=y
>
>
> The working directory of the linux is:
>
>
> /home/kai/yocto/build-hachiko/tmp/work/hachiko64-poky-linux-gnueabi/linux/3.8.13-r2/linux-3.8.13
>
>
> But when the linux is fetched and unpacked, the root defconfig file is put
> in:
>
>
> /home/kai/yocto/build-hachiko/tmp/work/hachiko64-poky-linux-gnueabi/linux/3.8.13-r2
>
>
> therefore, the patch step failed.
>
>
> I tried to modify the patch with  --- a/../defconfig and b/../defconfig
>
> but it does not work better.
>
>
> Any idea how to make it work ?


You can edit do_configure_prepend() in linux-rpi.inc

kernel_configure_variable CONFIG_BT y
...



>
>
> Thanks.
>
>
> Karim
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
> https://lists.yoctoproject.org/listinfo/yocto
yocto Info Page<https://lists.yoctoproject.org/listinfo/yocto>
lists.yoctoproject.org<http://lists.yoctoproject.org>
Discussion of all things about the Yocto Project. Read our Community Guidelines 
or learn more about how to participate in other community discussions.



>

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

[yocto] [bitbake] Failed to patch "defconfig" for linux kernel

[Karim ATIKI]

Hi,


I'm currently trying to patch the linux kernel 3.8.13-r2 of an ARM based board 
(Hachiko) in order to enable Bluetooth and RFCOMM support.


Currently, I select these options with bitbake -c menuconfig virtual/kernel

I'd like to use a patch on the defconfig in order to avoid the menuconfig step.


I've created a linux_3.8.13.bbappend file to apply the path.


Th patch file looks like:


--- a defconfig
+++ b defconfig
@@ -107,3 +107,16 @@
 CONFIG_CRYPTO_CBC=y
 CONFIG_CRYPTO_MD5=y
 CONFIG_CRYPTO_DES=y
+#
+# FIR device drivers
+#
+CONFIG_BT=y
+CONFIG_BT_RFCOMM=y
+CONFIG_BT_RFCOMM_TTY=y
+
+#
+# Bluetooth device drivers
+#
+CONFIG_BT_HCIBTUSB=y
+CONFIG_WIRELESS=y



The working directory of the linux is:


/home/kai/yocto/build-hachiko/tmp/work/hachiko64-poky-linux-gnueabi/linux/3.8.13-r2/linux-3.8.13


But when the linux is fetched and unpacked, the root defconfig file is put in:


/home/kai/yocto/build-hachiko/tmp/work/hachiko64-poky-linux-gnueabi/linux/3.8.13-r2


therefore, the patch step failed.


I tried to modify the patch with  --- a/../defconfig and b/../defconfig

but it does not work better.


Any idea how to make it work ?


Thanks.


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

[yocto] [bitbake] Custom LIC_FILES_CHKSUM location

[Karim ATIKI]

I need to integrate a custom licence file in the recipes we're creating.


Basically, the layer strcutureis:



meta-mylayer

 + recipes-connectivity /

 + bootscripts /

 + bootscript_0-1.bb

 + recipes-qt

 ...

MYLICENSE.TXT




In bootscript_0-1.bb:

I've added:

LIC_FILES_CHKSUM = "file://LICENSE.PGA;md5=149a23532762ef4f5c3a1ad0d021249c"


But of course, it does not find the file.

What variable should I use so that the file points to valid location ?


Best Regards,

Z.

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

Re: [yocto] [dora] Compiling Qt 5.7 without meta-qt5

[Karim ATIKI]

Hi Burt,


I tried.

But many errors raise that impact the "meta-hachiko" layer which is not 
compatible at all with versions > Dora.





De : Burton, Ross <ross.bur...@intel.com>
Envoyé : mardi 7 février 2017 12:44
À : Karim ATIKI
Cc : yocto
Objet : Re: [yocto] [dora] Compiling Qt 5.7 without meta-qt5


On 7 February 2017 at 11:05, Karim ATIKI 
<karim_at...@hotmail.com<mailto:karim_at...@hotmail.com>> wrote:

Using meta-qt5 is excluded.

But why not port meta-qt5 to dora?

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

[yocto] [dora] Compiling Qt 5.7 without meta-qt5

[Karim ATIKI]

I'm trying to create/integrate a recipe that builds Qt5.7 on a Architech 
Hachiko  (ARM) board.


This board is uniquely compatible with Poky DORA (for technical reasons, I 
don't have the choice).


Using meta-qt5 is excluded.


Actually? I succeeded to build qt5.7 with the Poky SDK and I would like to 
create a recipe that will call the "configure" and the "make / make install".


The command line looks like:


./configure -v -prefix /usr/local/qt5 -extprefix /opt/qt5-hachiko -device 
linux-arm-hachiko-g++ -device-option 
CROSS_COMPILE=/opt/poky/hachiko64/1.5.4/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-
 -sysroot 
/opt/poky/hachiko64/1.5.4/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi 
-release -shared -no-opengl -no-gstreamer -no-sql-sqlite -no-sql-sqlite2 
-qt-zlib -no-gif -no-accessibility -qt-libpng -qt-libjpeg  -qt-xcb 
-device-option QMAKE_LFLAGS=-O1 -opensource -confirm-license -nomake examples 
-nomake tests -skip qt3d -skip qtwebengine -skip qtcanvas3d -no-icu -skip 
qtvirtualkeyboard


But in a Yocto recipe, which variable should I use for the following options:


 
CROSS_COMPILE=/opt/poky/hachiko64/1.5.4/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-


-sysroot 
/opt/poky/hachiko64/1.5.4/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi



Currently, the values points to the Poky SDK generated by Yocto.


Thanks.


Z.

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

Re: [yocto] [bitbake] OECORE_TARGET_SYSROOT and OECORE_NATIVE_SYSROOT variables not availables ?

[Karim ATIKI]

Khem,


Ok.

How are they specified using Yocto build system ?

Is there any doc link ?



K.


De : Khem Raj <raj.k...@gmail.com>
Envoyé : mardi 10 janvier 2017 20:39
À : Karim ATIKI; yocto
Objet : Re: [yocto] [bitbake] OECORE_TARGET_SYSROOT and OECORE_NATIVE_SYSROOT 
variables not availables ?

These are specified differently when using the Yocto build system you should 
not be using these variables in your makefiles
On Tue, Jan 10, 2017 at 8:11 AM Karim ATIKI 
<karim_at...@hotmail.com<mailto:karim_at...@hotmail.com>> wrote:















Hi,








I'm using generated Poky SDK to cross-compile our program source-codes, which 
works fine.








Now I wish to integrate the build of the project into Yocto recipes using our 
makefiles.








However, some custom parameters in the makefiles are using the variables 
OECORE_TARGET_SYSROOT  and OECORE_NATIVE_SYSROOT to manage paths.




But it appears that these 2 variables do not exists when the makefiles are 
called in a do_compile() function of a recipe.








Is it normal ? Did I did something wrong ?



Should my recipe inherit something specific?








Or should I "source" my 
"environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi" from the SDK into my 
recipe file ? (=> not portable)








Thanks.








Z.



























--

___

yocto mailing list

yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>

https://lists.yoctoproject.org/listinfo/yocto

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

[yocto] [bitbake] OECORE_TARGET_SYSROOT and OECORE_NATIVE_SYSROOT variables not availables ?

[Karim ATIKI]

Hi,


I'm using generated Poky SDK to cross-compile our program source-codes, which 
works fine.


Now I wish to integrate the build of the project into Yocto recipes using our 
makefiles.


However, some custom parameters in the makefiles are using the variables 
OECORE_TARGET_SYSROOT  and OECORE_NATIVE_SYSROOT to manage paths.

But it appears that these 2 variables do not exists when the makefiles are 
called in a do_compile() function of a recipe.


Is it normal ? Did I did something wrong ?

Should my recipe inherit something specific?


Or should I "source" my 
"environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi" from the SDK into my 
recipe file ? (=> not portable)


Thanks.


Z.



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

[yocto] Best way to custom recipe to build c++ sources

[Karim ATIKI]

I'm currently writing a custom recipe that builds a c++ program developped by 
our team.

It is  a huge c++ program with many contrib dependencies. It's supposed to run 
on many platforms, including Rpi.


The recipe is really simply, it fetches sources, launches makefiles and install 
binaries.


Firslty, on my linux, I have created the SDK (with populate_sdk) in order to 
test the compilation (I installed it into /opt/poky)

So in my makefiles, I have added some compilation flags for the sysroot, ld 
flags etc.

But for this purpose I was obliged to "source" the environment script provided 
by the SDK to have the variables such as SDKTARGETSYSROOT, PATH, TARGET_PREFIX 
correctly set.


My question is:

when I'm writing my final recipe myprog_1.0.bb, I'm not suposed to have a 
proper SDK installed into /opt/poky ?

When a poky environment is sourced before launching bitbake, are the 
SDKTARGETSYSROOT set with any value ?


What's the best way to achieve it ?


Thanks.


Z.




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

Re: [yocto] [meta-raspberrypi][PATCH V2] gstreamer1.0-plugins-bad_%.bbappend: Set PACKAGECONFIG_GL for RPi

[Karim ATIKI]

Khem,


It worked successfuly.


No errors, no warnings.

Cheers,

Karim


De : Khem Raj <raj.k...@gmail.com>
Envoyé : jeudi 3 novembre 2016 22:44
À : Karim ATIKI
Cc : yocto@yoctoproject.org
Objet : Re: [yocto] [meta-raspberrypi][PATCH V2] 
gstreamer1.0-plugins-bad_%.bbappend: Set PACKAGECONFIG_GL for RPi

here is reworked patch
https://github.com/kraj/meta-raspberrypi/commit/468e28084a4d41e71fc0fde53b43033cd19ef9d5.patch

try it again

On Nov 3, 2016, at 2:27 PM, Karim ATIKI 
<karim_at...@hotmail.com<mailto:karim_at...@hotmail.com>> wrote:

Hi Khem,

I just tried to rebuild gstreamer1.0-plugins-bad from a clean checkout with 
your patch.
At first glance, it's working.

"bitbake gstreamer1.0-plugins-bad" succeeded but with a QA Warning:

gstreamer1.0-plugins-bad-1.8.3-r0 do_configure: QA Issue: 
gstreamer1.0-plugins-bad: invalid PACKAGECONFIG: "dispmanx 
[invalid-packageconfig]

Karim




De : yocto-boun...@yoctoproject.org<mailto:yocto-boun...@yoctoproject.org> 
<yocto-boun...@yoctoproject.org<mailto:yocto-boun...@yoctoproject.org>> de la 
part de Khem Raj <raj.k...@gmail.com<mailto:raj.k...@gmail.com>>
Envoyé : jeudi 3 novembre 2016 21:57
À : yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
Objet : [yocto] [meta-raspberrypi][PATCH V2] 
gstreamer1.0-plugins-bad_%.bbappend: Set PACKAGECONFIG_GL for RPi

Enable dispmanx support if using bcm driver

Signed-off-by: Khem Raj <raj.k...@gmail.com<mailto:raj.k...@gmail.com>>
---
Changes from V1->V2:
- Remove spurious "
- Rearrange code
- Remove duplicate packageconfig for dispmanx

 .../gstreamer/gstreamer1.0-plugins-bad_%.bbappend  | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend 
b/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
index ab0280e..7292f90 100644
--- a/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
+++ b/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
@@ -1,2 +1,12 @@
-EXTRA_OECONF_append_rpi = " 
CPPFLAGS='-I${STAGING_DIR_TARGET}/usr/include/interface/vcos/pthreads \
-   
-I${STAGING_DIR_TARGET}/usr/include/interface/vmcs_host/linux'"
+EXTRA_OECONF_append_rpi = " 
CPPFLAGS='-I${STAGING_INCDIR}/interface/vcos/pthreads \
+   
-I${STAGING_INCDIR}/interface/vmcs_host/linux'"
+
+# if using bcm driver enable dispmanx not when using VC4 driver
+
+PACKAGECONFIG_append_rpi = "${@bb.utils.contains('MACHINE_FEATURES', 
'vc4graphics', '', ' dispmanx', d)}"
+
+PACKAGECONFIG_GL_rpi = "egl gles2"
+
+PACKAGECONFIG_append_rpi = " hls libmms faad"
+
+PACKAGECONFIG[dispmanx] = "--enable-dispmanx,--disable-dispmanx,userland"
--
2.10.2

--
___
yocto mailing list
yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto
yocto Info Page<https://lists.yoctoproject.org/listinfo/yocto>
lists.yoctoproject.org<http://lists.yoctoproject.org/>
Discussion of all things about the Yocto Project. Read our Community Guidelines 
or learn more about how to participate in other community discussions.


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

Re: [yocto] [meta-raspberrypi][PATCH V2] gstreamer1.0-plugins-bad_%.bbappend: Set PACKAGECONFIG_GL for RPi

[Karim ATIKI]

Hi Khem,


I just tried to rebuild gstreamer1.0-plugins-bad from a clean checkout with 
your patch.

At first glance, it's working.


"bitbake gstreamer1.0-plugins-bad" succeeded but with a QA Warning:


gstreamer1.0-plugins-bad-1.8.3-r0 do_configure: QA Issue: 
gstreamer1.0-plugins-bad: invalid PACKAGECONFIG: "dispmanx 
[invalid-packageconfig]


Karim




De : yocto-boun...@yoctoproject.org  de la part 
de Khem Raj 
Envoyé : jeudi 3 novembre 2016 21:57
À : yocto@yoctoproject.org
Objet : [yocto] [meta-raspberrypi][PATCH V2] 
gstreamer1.0-plugins-bad_%.bbappend: Set PACKAGECONFIG_GL for RPi

Enable dispmanx support if using bcm driver

Signed-off-by: Khem Raj 
---
Changes from V1->V2:
- Remove spurious "
- Rearrange code
- Remove duplicate packageconfig for dispmanx

 .../gstreamer/gstreamer1.0-plugins-bad_%.bbappend  | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend 
b/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
index ab0280e..7292f90 100644
--- a/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
+++ b/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
@@ -1,2 +1,12 @@
-EXTRA_OECONF_append_rpi = " 
CPPFLAGS='-I${STAGING_DIR_TARGET}/usr/include/interface/vcos/pthreads \
-   
-I${STAGING_DIR_TARGET}/usr/include/interface/vmcs_host/linux'"
+EXTRA_OECONF_append_rpi = " 
CPPFLAGS='-I${STAGING_INCDIR}/interface/vcos/pthreads \
+   
-I${STAGING_INCDIR}/interface/vmcs_host/linux'"
+
+# if using bcm driver enable dispmanx not when using VC4 driver
+
+PACKAGECONFIG_append_rpi = "${@bb.utils.contains('MACHINE_FEATURES', 
'vc4graphics', '', ' dispmanx', d)}"
+
+PACKAGECONFIG_GL_rpi = "egl gles2"
+
+PACKAGECONFIG_append_rpi = " hls libmms faad"
+
+PACKAGECONFIG[dispmanx] = "--enable-dispmanx,--disable-dispmanx,userland"
--
2.10.2

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
yocto Info Page
lists.yoctoproject.org
Discussion of all things about the Yocto Project. Read our Community Guidelines 
or learn more about how to participate in other community discussions.



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

Re: [yocto] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5

[Karim ATIKI]

Hi Ionel,


I filed a bug-report for this concern.

Thanks for your feedback, I'll try it this afternoon..


Karim.



De : Ionel Badisor <ionelbadi...@gmail.com>
Envoyé : mercredi 2 novembre 2016 12:03
À : Karim ATIKI; Paul Barker
Cc : yocto
Objet : Re: [yocto] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5

On 10/22/2016 07:21 PM, Karim ATIKI wrote:
> Hi Paul,
>
>
> the compile log file is attached with this mail.
>
>
>
>
> 
> *De :* Paul Barker <p...@paulbarker.me.uk>
> *Envoyé :* samedi 22 octobre 2016 17:26
> *À :* Karim ATIKI
> *Cc :* yocto
> *Objet :* Re: [yocto] [raspberrypi3][meta-qt5] Failed to build
> meta-toolchain-qt5
>
> On Sat, 22 Oct 2016 15:16:18 +
> Karim ATIKI <karim_at...@hotmail.com> wrote:
>
>> Actually, it looks like the issue comes from gstreamer1.0-plugins-bad
>> recipe.
>>
>>
>> This function, graphics_get_display_size, comes from libbcm_host
>> which seems to be present in sysroot.
>>
>>
>> In log.doconfigure i found:
>>
>>
>> checking for bcm_host_init in -lbcm_host... yes
>> checking bcm_host.h usability... yes
>> checking bcm_host.h presence... yes
>> checking for bcm_host.h... yes
>>
>> So it seems that it found the necessary library.
>>
>>
>> However, in the logfile of the compile error, there is no
>> "-lbcm_host" dependency at all.
>>
>>
>> Any idea to solve it ?
>>
>
> Could you post more of the compile log? It would be good to see the
> full set of arguments being used for compiling/linking.
>
> Thanks,
> Paul
>
>

I stumble upon this issue before. My solution was to add
LDFLAGS += " -lbcm_host"
In a bbappend to gstreamer1.0-plugins-bad_%.bbappend in my layer




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

Re: [yocto] [meta-raspberrypi3] Failed to build gstreamer1.0-plugins-bad with minimal configuration

[Karim ATIKI]

Hi Paul,


Thanks for your feedback.

Unfortunately I was suspecting such a problem.


Regarding the config below, is it possible to install the "dispmanx"component 
to activate EGL ?


What recipe provides dispmanx ?


Karim





De : Paul Barker <p...@paulbarker.me.uk>
Envoyé : samedi 29 octobre 2016 23:13
À : Karim ATIKI
Cc : yocto
Objet : Re: [yocto] [meta-raspberrypi3] Failed to build 
gstreamer1.0-plugins-bad with minimal configuration

On Fri, 28 Oct 2016 05:56:07 +
Karim ATIKI <karim_at...@hotmail.com> wrote:

> Hi Paul,
>
>
> Thanks a lot for your feedback and analysis.
>
> I think it sohuld compile without X11 and Wayland as it's a very
> common configuration
>
> for RaspberryPi being used with Qt5.x applications.
>
>
> Do you think it's bug related to Gstreamer1.0 configuration ?
>
>
>
> Karim
>

The do_configure log for gstreamer1.0-plugins-bad does contain:

configure: WARNING: X or Wayland is required for OpenGL support

configure.ac in gst-plugins-bad-1.8.3 contains:

dnl EGL
if test "x$HAVE_EGL" = "xno"; then
  if test "x$HAVE_GL" = "xno"; then
AC_MSG_WARN([Building requires either EGL or GLX for OpenGL support])
  fi
else
  if test "x$NEED_EGL" != "xno"; then
if test "x$HAVE_WINDOW_WAYLAND" = "xyes" -o "x$HAVE_WINDOW_X11" = 
"xyes" -o "x$HAVE_WINDOW_DISPMANX" = "xyes"; then
  GL_LIBS="$GL_LIBS -lEGL $EGL_LIBS"
  GL_CFLAGS="$GL_CFLAGS $EGL_CFLAGS"
  USE_EGL=yes
fi
  fi
fi
;;

In config.status EGL_LIBS contains "-lbcm_host -lvcos
-lvchiq_arm", however GL_LIBS only contains "-lGLESv2". So I'd say
EGL_LIBS is not being included in to GL_LIBS because
HAVE_WINDOW_WAYLAND, HAVE_WINDOW_X11 and HAVE_WINDOW_DISPMAX are all
false.

GL_LIBS is used in gst-libs/gst/gl/Makefile.am so that's the variable
the libraries should be listed in.

I'd say that's an upstream issue - it really looks like it's demanding
X or Wayland to be enabled for OpenGL to work. I'd suggest raising the
issue upsteream.

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

Re: [yocto] [meta-raspberrypi3] Failed to build gstreamer1.0-plugins-bad with minimal configuration

[Karim ATIKI]

Hi Paul,


Thanks a lot for your feedback and analysis.

I think it sohuld compile without X11 and Wayland as it's a very common 
configuration

for RaspberryPi being used with Qt5.x applications.


Do you think it's bug related to Gstreamer1.0 configuration ?



Karim




De : Paul Barker <p...@paulbarker.me.uk>
Envoyé : jeudi 27 octobre 2016 23:18
À : Karim ATIKI
Cc : yocto
Objet : Re: [yocto] [meta-raspberrypi3] Failed to build 
gstreamer1.0-plugins-bad with minimal configuration


gstreamer1.0-plugins-bad compiles if x11, wayland and opengl are all
missing from DISTRO_FEATURES. It fails if x11 and wayland are missing
but opengl is included.

Should it compile if x11 and wayland are removed from DISTRO_FEATURES
but opengl is included? I don't do much on the graphics side so I don't
know if this makes sense as a configuration.

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

[yocto] [meta-raspberrypi3] Failed to build gstreamer1.0-plugins-bad with minimal configuration

[Karim ATIKI]

Hi all,


I'm currently unable to build gstreamer1.0-plugins-bad with a clean checkout of 
poky-krogoth and also poky-master with DISTRO_FEATURES_remove = " x11 wayland"


It fails during the do_compile() task  of gstreamer1.0-plugins-bad  with the 
following error message:


undefined reference to graphics_get_display_size().


This function comes with libbcmhost which is however installed with userland in 
sysroot.


In addition, the log.do_configure of gstreamer1.0-plugins-bad detects bcm_host 
as well.


If I change DISTRO_FEATURES_remove = " x11" it will work.


I have tested with a minimal configuration & layers:


Build Configuration:
BB_VERSION= "1.32.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Debian-8.2"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "raspberrypi3"
DISTRO= "poky"
DISTRO_VERSION= "2.2"
TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4 callconvention-hard 
cortexa7"
TARGET_FPU= "hard"
meta
meta-poky
meta-yocto-bsp= "master:ef627ab364d52fe19994c94c1a78fbe21620a32c"
meta-raspberrypi  = "master:de016ceef63028f5578191785c50529695f76a1a"
meta-oe
meta-multimedia   = "master:8ba31c9ba214802b1305aabbc0be0353cba0bc3e


and simply launched:


bitbake -k  gstreamer1.0-plugins-bad


Has anyone already experienced this issue with raspberrypi3 ?



Cheers,


Karim


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

Re: [yocto] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5

[Karim ATIKI]

Hi Paul,


You did have a chance to get gstreamer1.0-plugins-bad built correctly from a 
clean checkout ?


Could you please share the exact poky branches / layers ?




Cheers.


Karim



De : yocto-boun...@yoctoproject.org <yocto-boun...@yoctoproject.org> de la part 
de Karim ATIKI <karim_at...@hotmail.com>
Envoyé : dimanche 23 octobre 2016 12:10
À : Paul Barker
Cc : yocto
Objet : Re: [yocto] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5


Hi Paul,

I just tried with a clean configuration.

I"ve cloned the layers as shown in the config below:

Build Configuration:
BB_VERSION= "1.32.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Debian-8.2"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "raspberrypi3"
DISTRO= "poky"
DISTRO_VERSION= "2.2"
TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4 callconvention-hard 
cortexa7"
TARGET_FPU= "hard"
meta
meta-poky
meta-yocto-bsp= "master:ef627ab364d52fe19994c94c1a78fbe21620a32c"
meta-raspberrypi  = "master:de016ceef63028f5578191785c50529695f76a1a"
meta-oe
meta-multimedia   = "master:8ba31c9ba214802b1305aabbc0be0353cba0bc3e"



Created a new build and just added:

MACHINE="raspberrypi3"
DISTRO_FEATURES_remove  = " x11 wayland".

Launched: bitbake -k gstreamer1.0-plugins-bad


It failed as usual during the do_compile() of gstreamer1.0-plugins-bad as 
reported yesterday.

./.libs/libgstgl-1.0.so: undefined reference to `graphics_get_display_size'


How did you get it work on your side ?


Karim




De : Paul Barker <p...@paulbarker.me.uk>
Envoyé : samedi 22 octobre 2016 23:27
À : Karim ATIKI
Cc : yocto
Objet : Re: [yocto] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5

On Sat, 22 Oct 2016 18:59:39 +
Karim ATIKI <karim_at...@hotmail.com> wrote:

> Hi ,
>
>
> I just found out something interesting.
>
> I setup a build with poky-krogoth, I didn't include any of my custom
> recipes.
>
>
> I've jsut included meta-raspberrypi in the layers.
>
> Setup a machine "raspberrypi3"
>
>
> Launched: bitbake gstreamer1.0-plugins-bad
>
>
> It worked successfully.
>
> Then, I deleted the tmp and sstate directories.
>
>
> And I added in the local.conf:
>
> DISTRO_FEATURES_remove = " x11 wayland".
>
>
> Launched: bitbake gstreamer1.0-plugins-bad
>
>
> >>>> It failed at the exact step (see below in the conversation)
>
>
> Is there a problem with this configuration ?
>
>
> Cheers,
>
>
> Karim
>

I can't reproduce this on master. gstreamer1.0-plugins-bad compiles
without error for raspberrypi3 without x11 or wayland in
DISTRO_FEATURES on my machine.

Are you using krogoth branches of all your layers? Could you retry this
on a clean checkout of master, using the minimal set of layers
(oe-core, meta-oe, meta-multimedia and meta-raspberrypi) and see if you
see the same problem?

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

Re: [yocto] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5

[Karim ATIKI]

Hi Paul,

I just tried with a clean configuration.

I"ve cloned the layers as shown in the config below:

Build Configuration:
BB_VERSION= "1.32.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Debian-8.2"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "raspberrypi3"
DISTRO= "poky"
DISTRO_VERSION= "2.2"
TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4 callconvention-hard 
cortexa7"
TARGET_FPU= "hard"
meta
meta-poky
meta-yocto-bsp= "master:ef627ab364d52fe19994c94c1a78fbe21620a32c"
meta-raspberrypi  = "master:de016ceef63028f5578191785c50529695f76a1a"
meta-oe
meta-multimedia   = "master:8ba31c9ba214802b1305aabbc0be0353cba0bc3e"



Created a new build and just added:

MACHINE="raspberrypi3"
DISTRO_FEATURES_remove  = " x11 wayland".

Launched: bitbake -k gstreamer1.0-plugins-bad


It failed as usual during the do_compile() of gstreamer1.0-plugins-bad as 
reported yesterday.

./.libs/libgstgl-1.0.so: undefined reference to `graphics_get_display_size'


How did you get it work on your side ?


Karim




De : Paul Barker <p...@paulbarker.me.uk>
Envoyé : samedi 22 octobre 2016 23:27
À : Karim ATIKI
Cc : yocto
Objet : Re: [yocto] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5

On Sat, 22 Oct 2016 18:59:39 +
Karim ATIKI <karim_at...@hotmail.com> wrote:

> Hi ,
>
>
> I just found out something interesting.
>
> I setup a build with poky-krogoth, I didn't include any of my custom
> recipes.
>
>
> I've jsut included meta-raspberrypi in the layers.
>
> Setup a machine "raspberrypi3"
>
>
> Launched: bitbake gstreamer1.0-plugins-bad
>
>
> It worked successfully.
>
> Then, I deleted the tmp and sstate directories.
>
>
> And I added in the local.conf:
>
> DISTRO_FEATURES_remove = " x11 wayland".
>
>
> Launched: bitbake gstreamer1.0-plugins-bad
>
>
> >>>> It failed at the exact step (see below in the conversation)
>
>
> Is there a problem with this configuration ?
>
>
> Cheers,
>
>
> Karim
>

I can't reproduce this on master. gstreamer1.0-plugins-bad compiles
without error for raspberrypi3 without x11 or wayland in
DISTRO_FEATURES on my machine.

Are you using krogoth branches of all your layers? Could you retry this
on a clean checkout of master, using the minimal set of layers
(oe-core, meta-oe, meta-multimedia and meta-raspberrypi) and see if you
see the same problem?

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

Re: [yocto] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5

[Karim ATIKI]

Hi ,


I just found out something interesting.

I setup a build with poky-krogoth, I didn't include any of my custom recipes.


I've jsut included meta-raspberrypi in the layers.

Setup a machine "raspberrypi3"


Launched: bitbake gstreamer1.0-plugins-bad


It worked successfully.

Then, I deleted the tmp and sstate directories.


And I added in the local.conf:

DISTRO_FEATURES_remove = " x11 wayland".


Launched: bitbake gstreamer1.0-plugins-bad


>>>> It failed at the exact step (see below in the conversation)


Is there a problem with this configuration ?


Cheers,


Karim




De : yocto-boun...@yoctoproject.org <yocto-boun...@yoctoproject.org> de la part 
de Karim ATIKI <karim_at...@hotmail.com>
Envoyé : samedi 22 octobre 2016 19:03
À : Khem Raj
Cc : yocto
Objet : Re: [yocto] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5


Hi Khem,


Furthermore, please find fattached the config.log of the 
gstreamer1.0-plugins-bad.

It looks like bcm_hoist is correctly detected thuogh.



Cheers,


Karim



De : yocto-boun...@yoctoproject.org <yocto-boun...@yoctoproject.org> de la part 
de Karim ATIKI <karim_at...@hotmail.com>
Envoyé : samedi 22 octobre 2016 18:19
À : Khem Raj
Cc : yocto
Objet : Re: [yocto] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5


Khem,


I found the follwoing pc files, and bcm_host is found.



kai@odyssey:~/yocto/build-magnolia/tmp/work$ find . -name *.pc | grep userland
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/image/usr/lib/pkgconfig/brcmvg.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/image/usr/lib/pkgconfig/glesv2.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/image/usr/lib/pkgconfig/egl.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/image/usr/lib/pkgconfig/bcm_host.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/image/usr/lib/pkgconfig/vg.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/image/usr/lib/pkgconfig/brcmegl.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/image/usr/lib/pkgconfig/brcmglesv2.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/packages-split/userland-dev/usr/lib/pkgconfig/brcmvg.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/packages-split/userland-dev/usr/lib/pkgconfig/glesv2.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/packages-split/userland-dev/usr/lib/pkgconfig/egl.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/packages-split/userland-dev/usr/lib/pkgconfig/bcm_host.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/packages-split/userland-dev/usr/lib/pkgconfig/vg.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/packages-split/userland-dev/usr/lib/pkgconfig/brcmegl.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/packages-split/userland-dev/usr/lib/pkgconfig/brcmglesv2.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/sysroot-destdir/usr/lib/pkgconfig/brcmvg.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/sysroot-destdir/usr/lib/pkgconfig/glesv2.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/sysroot-destdir/usr/lib/pkgconfig/egl.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/sysroot-destdir/usr/lib/pkgconfig/bcm_host.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/sysroot-destdir/usr/lib/pkgconfig/vg.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/sysroot-destdir/usr/lib/pkgconfig/brcmegl.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/sysroot-destdir/usr/lib/pkgconfig/brcmglesv2.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/git/.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/package/usr/lib/pkgconfig/brcmvg.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/package/usr/lib/pkgconfig/glesv2.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/package/usr/lib/pkgconfig/egl.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/package/usr/lib/pkgconfig/bcm_host.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/package/usr/lib/pkgconfig/vg.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/package/usr/lib/pkgconfig/brcmegl.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/package/usr/lib/pkgconfig/brcmglesv2.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/build/brcmvg.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/build/glesv2.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/build/egl.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/build/bcm_host.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/build/vg.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/build/brcmegl.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/build/brcmglesv2.pc





De : Khem Raj <raj.k...@gmail.com>
Envoyé : samedi 22 octobre 2016 18:13
À : Karim ATIKI
Cc : yocto
Objet : Re: [yocto] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5


On Oct 22, 2016, at 8:16 AM, Karim ATIKI 
<karim_at...@hotmail.com<mailto:karim_at...@hotmail.com

Re: [yocto] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5

[Karim ATIKI]

Hi Paul,


the compile log file is attached with this mail.




De : Paul Barker <p...@paulbarker.me.uk>
Envoyé : samedi 22 octobre 2016 17:26
À : Karim ATIKI
Cc : yocto
Objet : Re: [yocto] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5

On Sat, 22 Oct 2016 15:16:18 +
Karim ATIKI <karim_at...@hotmail.com> wrote:

> Actually, it looks like the issue comes from gstreamer1.0-plugins-bad
> recipe.
>
>
> This function, graphics_get_display_size, comes from libbcm_host
> which seems to be present in sysroot.
>
>
> In log.doconfigure i found:
>
>
> checking for bcm_host_init in -lbcm_host... yes
> checking bcm_host.h usability... yes
> checking bcm_host.h presence... yes
> checking for bcm_host.h... yes
>
> So it seems that it found the necessary library.
>
>
> However, in the logfile of the compile error, there is no
> "-lbcm_host" dependency at all.
>
>
> Any idea to solve it ?
>

Could you post more of the compile log? It would be good to see the
full set of arguments being used for compiling/linking.

Thanks,
Paul


log.do_compile.2574
Description: log.do_compile.2574
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5

[Karim ATIKI]

Khem,


I found the follwoing pc files, and bcm_host is found.



kai@odyssey:~/yocto/build-magnolia/tmp/work$ find . -name *.pc | grep userland
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/image/usr/lib/pkgconfig/brcmvg.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/image/usr/lib/pkgconfig/glesv2.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/image/usr/lib/pkgconfig/egl.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/image/usr/lib/pkgconfig/bcm_host.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/image/usr/lib/pkgconfig/vg.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/image/usr/lib/pkgconfig/brcmegl.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/image/usr/lib/pkgconfig/brcmglesv2.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/packages-split/userland-dev/usr/lib/pkgconfig/brcmvg.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/packages-split/userland-dev/usr/lib/pkgconfig/glesv2.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/packages-split/userland-dev/usr/lib/pkgconfig/egl.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/packages-split/userland-dev/usr/lib/pkgconfig/bcm_host.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/packages-split/userland-dev/usr/lib/pkgconfig/vg.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/packages-split/userland-dev/usr/lib/pkgconfig/brcmegl.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/packages-split/userland-dev/usr/lib/pkgconfig/brcmglesv2.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/sysroot-destdir/usr/lib/pkgconfig/brcmvg.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/sysroot-destdir/usr/lib/pkgconfig/glesv2.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/sysroot-destdir/usr/lib/pkgconfig/egl.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/sysroot-destdir/usr/lib/pkgconfig/bcm_host.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/sysroot-destdir/usr/lib/pkgconfig/vg.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/sysroot-destdir/usr/lib/pkgconfig/brcmegl.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/sysroot-destdir/usr/lib/pkgconfig/brcmglesv2.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/git/.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/package/usr/lib/pkgconfig/brcmvg.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/package/usr/lib/pkgconfig/glesv2.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/package/usr/lib/pkgconfig/egl.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/package/usr/lib/pkgconfig/bcm_host.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/package/usr/lib/pkgconfig/vg.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/package/usr/lib/pkgconfig/brcmegl.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/package/usr/lib/pkgconfig/brcmglesv2.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/build/brcmvg.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/build/glesv2.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/build/egl.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/build/bcm_host.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/build/vg.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/build/brcmegl.pc
./raspberrypi3-poky-linux-gnueabi/userland/git-r5/build/brcmglesv2.pc





De : Khem Raj <raj.k...@gmail.com>
Envoyé : samedi 22 octobre 2016 18:13
À : Karim ATIKI
Cc : yocto
Objet : Re: [yocto] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5


On Oct 22, 2016, at 8:16 AM, Karim ATIKI 
<karim_at...@hotmail.com<mailto:karim_at...@hotmail.com>> wrote:

Actually, it looks like the issue comes from gstreamer1.0-plugins-bad recipe.

This function, graphics_get_display_size, comes from libbcm_host which seems to 
be present in sysroot.

In log.doconfigure i found:


checking for bcm_host_init in -lbcm_host... yes
checking bcm_host.h usability... yes
checking bcm_host.h presence... yes
checking for bcm_host.h... yes

So it seems that it found the necessary library.

However, in the logfile of the compile error, there is no "-lbcm_host" 
dependency at all.

Any idea to solve it ?

Look at the packageconfig files from userland package and see if its exporting 
the right libraries in .pc files.


Karim




De : yocto-boun...@yoctoproject.org<mailto:yocto-boun...@yoctoproject.org> 
<yocto-boun...@yoctoproject.org<mailto:yocto-boun...@yoctoproject.org>> de la 
part de Karim ATIKI <karim_at...@hotmail.com<mailto:karim_at...@hotmail.com>>
Envoyé : samedi 22 octobre 2016 14:26
À : yocto
Objet : [yocto] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5

Hi all,

Tryng to build the meta-toolchain-qt5, I've a failure while bulidng 
gst-plugins-bad.

The underlying error seems to be:

| ./.libs/libgstgl-1.0.so: undefined reference to `graphics_get_display_size

This function seems to come from bcm_host library.
Isn't it related to  RaspberryPi graphic l

Re: [yocto] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5

[Karim ATIKI]

Actually, it looks like the issue comes from gstreamer1.0-plugins-bad recipe.


This function, graphics_get_display_size, comes from libbcm_host which seems to 
be present in sysroot.


In log.doconfigure i found:


checking for bcm_host_init in -lbcm_host... yes
checking bcm_host.h usability... yes
checking bcm_host.h presence... yes
checking for bcm_host.h... yes

So it seems that it found the necessary library.


However, in the logfile of the compile error, there is no "-lbcm_host" 
dependency at all.


Any idea to solve it ?


Karim




De : yocto-boun...@yoctoproject.org <yocto-boun...@yoctoproject.org> de la part 
de Karim ATIKI <karim_at...@hotmail.com>
Envoyé : samedi 22 octobre 2016 14:26
À : yocto
Objet : [yocto] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5


Hi all,


Tryng to build the meta-toolchain-qt5, I've a failure while bulidng 
gst-plugins-bad.


The underlying error seems to be:


| ./.libs/libgstgl-1.0.so: undefined reference to `graphics_get_display_size


This function seems to come from bcm_host library.

Isn't it related to  RaspberryPi graphic libs ?


Should I add a specific dependency ?


Weird.


Karim


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

[yocto] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5

[Karim ATIKI]

Hi all,


Tryng to build the meta-toolchain-qt5, I've a failure while bulidng 
gst-plugins-bad.


The underlying error seems to be:


| ./.libs/libgstgl-1.0.so: undefined reference to `graphics_get_display_size


This function seems to come from bcm_host library.

Isn't it related to  RaspberryPi graphic libs ?


Should I add a specific dependency ?


Weird.


Karim


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

Re: [yocto] [raspberrypi3] Failed to build core-image-minimal with Qt5 support (GL/gl.h not found)

[Karim ATIKI]

Hi Khem,


>it currently have some vc4 support if you want mesa to work then use
>vc4graphics in machine features.

You mean, I should add "vc4graphics" in MACHINE_FEATURES ?


Actually, I don't specially  want to have mesa. I just want to have Qt5 without 
X11 so I can build my programs with eglfs qpa.


>otherwise the headers should come from userland package. Figure out

>why mesa-gl is being pulled.

In the dependecy explorer, I see mesa-gl Runtime Depends = "mesa-gl-dev 
mesa-megadriver"
I don't have any other info [☹]


De : Khem Raj <raj.k...@gmail.com>
Envoyé : dimanche 16 octobre 2016 19:24
À : Karim ATIKI
Cc : yocto
Objet : Re: [yocto] [raspberrypi3] Failed to build core-image-minimal with Qt5 
support (GL/gl.h not found)

On Sun, Oct 16, 2016 at 8:45 AM, Karim ATIKI <karim_at...@hotmail.com> wrote:
> Hi all,
>
>
> I'm trying to a build a core-image-minimal for my RaspberryPi3 with Qt5
> support.
>
> I'm working with Poky Krogth  and master branches of meta-qt5 and
> meta-raspberrypi.
>
>
> The build failed at qtbase do_configure().
>
> It reports
>
>
> "| checking for OpenGL...
> | Cannot read
> /home/kai/yocto/build-rpi3-minimal/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/qtbase/5.7.0+gitAUTOINC+69b43e74d7-r0/git/mkspecs/oe-device-extra.pri:
> No such file or directory
> | arm-poky-linux-gnueabi-g++  -march=armv7ve -marm -mfpu=neon-vfpv4
> -mfloat-abi=hard -mcpu=cortex-a7
> --sysroot=/home/kai/yocto/build-rpi3-minimal/tmp/sysroots/raspberrypi3 -c
> -pipe  -O2 -pipe -g -feliminate-unused-debug-types
> -fdebug-prefix-map=/home/kai/yocto/build-rpi3-minimal/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/qtbase/5.7.0+gitAUTOINC+69b43e74d7-r0=/usr/src/debug/qtbase/5.7.0+gitAUTOINC+69b43e74d7-r0
> -fdebug-prefix-map=/home/kai/yocto/build-rpi3-minimal/tmp/sysroots/x86_64-linux=
> -fdebug-prefix-map=/home/kai/yocto/build-rpi3-minimal/tmp/sysroots/raspberrypi3=
> -fvisibility-inlines-hidden -O2 -Wall -W -fPIC
> -I../../../../git/config.tests/unix/opengldesktop -I.
> -I../../../../git/mkspecs/linux-oe-g++ -o opengldesktop.o
> ../../../../git/config.tests/unix/opengldesktop/opengldesktop.cpp
>
> | ../../../../git/config.tests/unix/opengldesktop/opengldesktop.cpp:43:19:
> fatal error: GL/gl.h: No such file or directory
>
> |  #include 
> "
>
> The OpenGL header files are not there.
> However, I've setup my local.conf as follow:
>
> DISTRO_FEATURES_remove = " x11 wayland"
> DISTRO_FEATURES_append = " opengl"
>
>
> IMAGE_INSTALL_append = "  qtbase \
>   kernel-modules \
>   qtdeclarative \
>   qtmultimedia \
>   qtsvg \
>   qtsensors \
>   qtimageformats \
>   qtsystems \
>   qtscript \
>   qt3d \
>   qtconnectivity \
>   qtlocation \
>   cinematicexperience \
>   qtgraphicaleffects \
>   qtquick1 \
>   qtwebkit \
>   binutils \
> "
>
> Is there something missing ?
> In addition, during the build, I saw "mesa-gl" getting installed correctly.




>
> But in the sysroot, I have only:
>
> ./tmp/sysroots/raspberrypi3/usr/include/GL/
> ./tmp/sysroots/raspberrypi3/usr/include/GL/internal/dri_interface.h
>
> But in the mesa-gl work dir, I can find:
>
> ./tmp/sysroots/raspberrypi3/usr/include/GL/
> ./tmp/sysroots/raspberrypi3/usr/include/GL/GL
> ./tmp/sysroots/raspberrypi3/usr/include/GL/GLES
> ./tmp/sysroots/raspberrypi3/usr/include/GL/GLES2
> ./tmp/sysroots/raspberrypi3/usr/include/GL/GLES3
> with all sub files...
>
>
> What's wrong with the build ?
>
>
> Cheers,
>
> Karim
>
>
>
>
>
>
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
yocto -- Discussion of all things Yocto 
Project<https://lists.yoctoproject.org/listinfo/yocto>
lists.yoctoproject.org
Discussion of all things about the Yocto Project. Read our Community Guidelines 
or learn more about how to participate in other community discussions.



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

Re: [yocto] [raspberrypi3] Failed to build core-image-minimal with Qt5 support (GL/gl.h not found)

[Karim ATIKI]

I wrote a mistake in my first post.


I meant:


In the mesa-gl work dir, I can find:

./tmp/work/xxx/mesa-gl-xxx/usr/include/GL/
./tmp/work/xxx/mesa-gl-xxx/usr/include/GL/GL
./tmp/work/xxx/mesa-gl-xxx/usr/include/GL/GLES
./tmp/work/xxx/mesa-gl-xxx/usr/include/GL/GLES2
./tmp/work/xxx/mesa-gl-xxx/usr/include/GL/GLES3
with all sub files...




De : yocto-boun...@yoctoproject.org <yocto-boun...@yoctoproject.org> de la part 
de Karim ATIKI <karim_at...@hotmail.com>
Envoyé : dimanche 16 octobre 2016 17:45
À : yocto
Objet : [yocto] [raspberrypi3] Failed to build core-image-minimal with Qt5 
support (GL/gl.h not found)


Hi all,


I'm trying to a build a core-image-minimal for my RaspberryPi3 with Qt5 support.

I'm working with Poky Krogth  and master branches of meta-qt5 and 
meta-raspberrypi.


The build failed at qtbase do_configure().

It reports


"| checking for OpenGL...
| Cannot read 
/home/kai/yocto/build-rpi3-minimal/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/qtbase/5.7.0+gitAUTOINC+69b43e74d7-r0/git/mkspecs/oe-device-extra.pri:
 No such file or directory
| arm-poky-linux-gnueabi-g++  -march=armv7ve -marm -mfpu=neon-vfpv4  
-mfloat-abi=hard -mcpu=cortex-a7 
--sysroot=/home/kai/yocto/build-rpi3-minimal/tmp/sysroots/raspberrypi3 -c -pipe 
 -O2 -pipe -g -feliminate-unused-debug-types 
-fdebug-prefix-map=/home/kai/yocto/build-rpi3-minimal/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/qtbase/5.7.0+gitAUTOINC+69b43e74d7-r0=/usr/src/debug/qtbase/5.7.0+gitAUTOINC+69b43e74d7-r0
 
-fdebug-prefix-map=/home/kai/yocto/build-rpi3-minimal/tmp/sysroots/x86_64-linux=
 
-fdebug-prefix-map=/home/kai/yocto/build-rpi3-minimal/tmp/sysroots/raspberrypi3=
  -fvisibility-inlines-hidden -O2 -Wall -W -fPIC  
-I../../../../git/config.tests/unix/opengldesktop -I. 
-I../../../../git/mkspecs/linux-oe-g++ -o opengldesktop.o 
../../../../git/config.tests/unix/opengldesktop/opengldesktop.cpp

| ../../../../git/config.tests/unix/opengldesktop/opengldesktop.cpp:43:19: 
fatal error: GL/gl.h: No such file or directory

|  #include 
"

The OpenGL header files are not there.
However, I've setup my local.conf as follow:

DISTRO_FEATURES_remove = " x11 wayland"
DISTRO_FEATURES_append = " opengl"


IMAGE_INSTALL_append = "  qtbase \
  kernel-modules \
  qtdeclarative \
  qtmultimedia \
  qtsvg \
  qtsensors \
  qtimageformats \
  qtsystems \
  qtscript \
  qt3d \
  qtconnectivity \
  qtlocation \
  cinematicexperience \
  qtgraphicaleffects \
  qtquick1 \
  qtwebkit \
  binutils \
"

Is there something missing ?
In addition, during the build, I saw "mesa-gl" getting installed correctly.

But in the sysroot, I have only:

./tmp/sysroots/raspberrypi3/usr/include/GL/
./tmp/sysroots/raspberrypi3/usr/include/GL/internal/dri_interface.h

But in the mesa-gl work dir, I can find:

./tmp/sysroots/raspberrypi3/usr/include/GL/
./tmp/sysroots/raspberrypi3/usr/include/GL/GL
./tmp/sysroots/raspberrypi3/usr/include/GL/GLES
./tmp/sysroots/raspberrypi3/usr/include/GL/GLES2
./tmp/sysroots/raspberrypi3/usr/include/GL/GLES3
with all sub files...


What's wrong with the build ?


Cheers,

Karim








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

[yocto] [raspberrypi3] Failed to build core-image-minimal with Qt5 support (GL/gl.h not found)

[Karim ATIKI]

Hi all,


I'm trying to a build a core-image-minimal for my RaspberryPi3 with Qt5 support.

I'm working with Poky Krogth  and master branches of meta-qt5 and 
meta-raspberrypi.


The build failed at qtbase do_configure().

It reports


"| checking for OpenGL...
| Cannot read 
/home/kai/yocto/build-rpi3-minimal/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/qtbase/5.7.0+gitAUTOINC+69b43e74d7-r0/git/mkspecs/oe-device-extra.pri:
 No such file or directory
| arm-poky-linux-gnueabi-g++  -march=armv7ve -marm -mfpu=neon-vfpv4  
-mfloat-abi=hard -mcpu=cortex-a7 
--sysroot=/home/kai/yocto/build-rpi3-minimal/tmp/sysroots/raspberrypi3 -c -pipe 
 -O2 -pipe -g -feliminate-unused-debug-types 
-fdebug-prefix-map=/home/kai/yocto/build-rpi3-minimal/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/qtbase/5.7.0+gitAUTOINC+69b43e74d7-r0=/usr/src/debug/qtbase/5.7.0+gitAUTOINC+69b43e74d7-r0
 
-fdebug-prefix-map=/home/kai/yocto/build-rpi3-minimal/tmp/sysroots/x86_64-linux=
 
-fdebug-prefix-map=/home/kai/yocto/build-rpi3-minimal/tmp/sysroots/raspberrypi3=
  -fvisibility-inlines-hidden -O2 -Wall -W -fPIC  
-I../../../../git/config.tests/unix/opengldesktop -I. 
-I../../../../git/mkspecs/linux-oe-g++ -o opengldesktop.o 
../../../../git/config.tests/unix/opengldesktop/opengldesktop.cpp

| ../../../../git/config.tests/unix/opengldesktop/opengldesktop.cpp:43:19: 
fatal error: GL/gl.h: No such file or directory

|  #include 
"

The OpenGL header files are not there.
However, I've setup my local.conf as follow:

DISTRO_FEATURES_remove = " x11 wayland"
DISTRO_FEATURES_append = " opengl"


IMAGE_INSTALL_append = "  qtbase \
  kernel-modules \
  qtdeclarative \
  qtmultimedia \
  qtsvg \
  qtsensors \
  qtimageformats \
  qtsystems \
  qtscript \
  qt3d \
  qtconnectivity \
  qtlocation \
  cinematicexperience \
  qtgraphicaleffects \
  qtquick1 \
  qtwebkit \
  binutils \
"

Is there something missing ?
In addition, during the build, I saw "mesa-gl" getting installed correctly.

But in the sysroot, I have only:

./tmp/sysroots/raspberrypi3/usr/include/GL/
./tmp/sysroots/raspberrypi3/usr/include/GL/internal/dri_interface.h

But in the mesa-gl work dir, I can find:

./tmp/sysroots/raspberrypi3/usr/include/GL/
./tmp/sysroots/raspberrypi3/usr/include/GL/GL
./tmp/sysroots/raspberrypi3/usr/include/GL/GLES
./tmp/sysroots/raspberrypi3/usr/include/GL/GLES2
./tmp/sysroots/raspberrypi3/usr/include/GL/GLES3
with all sub files...


What's wrong with the build ?


Cheers,

Karim








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

Re: [yocto] [bitbake] Issue with SVN fetcher options

[Karim ATIKI]

De : Mark Hatle <mark.ha...@windriver.com>
Envoyé : lundi 10 octobre 2016 15:58
À : Karim ATIKI; yocto
Objet : Re: [yocto] [bitbake] Issue with SVN fetcher options

On 10/10/16 3:47 PM, Karim ATIKI wrote:
> OK.
>
>
> I found  out the solution.
>
>
> Actually, I noticed in the log file "log.do_fetch()" that the SVN command
> finishes with the "module" name as the output directory.
>
> I took a look to bitbake sourcecode and realized that the parameter I was
> looking for in the SRC_URI was "path_spec".
>
>
> ThereforeI changed the SRC_URI with:
>
>
>
> SRC_URI =
> "svn://${PGA_SVN_USERNAME}:${PGA_SVN_PASSWORD}@our-server:22037/svn-atonce/subproject/;module=trunk;protocol=http;path_spec=subproject"
>
> And everything works fine.
> Please note that there are no mentions of "path_spec" in the the BitBake 
> manual
> nor Yocto MegaManual.
>
> I just wonder if there's a reason for that. Anyway, it solved my problem.
>
> Cheers.
>
> Karim
>
>
> --------
> *De :* yocto-boun...@yoctoproject.org <yocto-boun...@yoctoproject.org> de la
> part de Karim ATIKI <karim_at...@hotmail.com>
> *Envoyé :* lundi 10 octobre 2016 15:11
> *À :* yocto
> *Objet :* [yocto] [bitbake] Issue with SVN fetcher options
>
>
> Hi all,
>
>
> I'm writing a recipe to build a custom project for an ARM based board 
> (Colibri T20).
>
> I need to fetch the different sub-projects from SVN and launch the respective
> makefile.
>
>
> However, I'm experiencing a problem with the SVN fetcher of bitbake.
>
> Indeed, my URI looks like:
>
>
> SRC_URI =
> "svn://${PGA_SVN_USERNAME}:${PGA_SVN_PASSWORD}@our-server:22037/svn-atonce/subproject/;module=trunk;protocol=http"
>
> Basically, it works fine. But the source code is fetched into:
>
> *../downloads/svn/our-server:22037/svn-atonce/subproject/trunk*
>
>
> And I need it to be checked out into a local directory as follow:
>
>
> *../downloads/svn/our-server:22037/svn-atonce/subproject/*
>
> I haven'nt found yet an option for the SVN fetcher to specify a local 
> directory
> for the check-out.
>
> Is there an option that I haven'nt found in the BitBake manual ?
>
>If this fixes your issues, and is not anywhere in the manual.  I'd suggest
>opening a bug on the docs in the bugzilla so it can be updated.
>
>(bugzilla.yoctoproject.org -- selection documentation)
>
>--Mark

Done.

https://bugzilla.yoctoproject.org/show_bug.cgi?id=10405


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

Re: [yocto] [bitbake] Issue with SVN fetcher options

[Karim ATIKI]

OK.


I found  out the solution.


Actually, I noticed in the log file "log.do_fetch()" that the SVN command 
finishes with the "module" name as the output directory.

I took a look to bitbake sourcecode and realized that the parameter I was 
looking for in the SRC_URI was "path_spec".


ThereforeI changed the SRC_URI with:


SRC_URI = 
"svn://${PGA_SVN_USERNAME}:${PGA_SVN_PASSWORD}@our-server:22037/svn-atonce/subproject/;module=trunk;protocol=http;path_spec=subproject"

And everything works fine.
Please note that there are no mentions of "path_spec" in the the BitBake manual 
nor Yocto MegaManual.

I just wonder if there's a reason for that. Anyway, it solved my problem.

Cheers.

Karim



De : yocto-boun...@yoctoproject.org <yocto-boun...@yoctoproject.org> de la part 
de Karim ATIKI <karim_at...@hotmail.com>
Envoyé : lundi 10 octobre 2016 15:11
À : yocto
Objet : [yocto] [bitbake] Issue with SVN fetcher options


Hi all,


I'm writing a recipe to build a custom project for an ARM based board (Colibri 
T20).

I need to fetch the different sub-projects from SVN and launch the respective 
makefile.


However, I'm experiencing a problem with the SVN fetcher of bitbake.

Indeed, my URI looks like:


SRC_URI = 
"svn://${PGA_SVN_USERNAME}:${PGA_SVN_PASSWORD}@our-server:22037/svn-atonce/subproject/;module=trunk;protocol=http"

Basically, it works fine. But the source code is fetched into:

../downloads/svn/our-server:22037/svn-atonce/subproject/trunk


And I need it to be checked out into a local directory as follow:


../downloads/svn/our-server:22037/svn-atonce/subproject/

I haven'nt found yet an option for the SVN fetcher to specify a local directory 
for the check-out.

Is there an option that I haven'nt found in the BitBake manual ?

Cheers.

Karim

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

[yocto] [bitbake] Issue with SVN fetcher options

[Karim ATIKI]

Hi all,


I'm writing a recipe to build a custom project for an ARM based board (Colibri 
T20).

I need to fetch the different sub-projects from SVN and launch the respective 
makefile.


However, I'm experiencing a problem with the SVN fetcher of bitbake.

Indeed, my URI looks like:


SRC_URI = 
"svn://${PGA_SVN_USERNAME}:${PGA_SVN_PASSWORD}@our-server:22037/svn-atonce/subproject/;module=trunk;protocol=http"

Basically, it works fine. But the source code is fetched into:

../downloads/svn/our-server:22037/svn-atonce/subproject/trunk


And I need it to be checked out into a local directory as follow:


../downloads/svn/our-server:22037/svn-atonce/subproject/

I haven'nt found yet an option for the SVN fetcher to specify a local directory 
for the check-out.

Is there an option that I haven'nt found in the BitBake manual ?

Cheers.

Karim

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

Re: [yocto] [meta-raspberrypi] taskhash mismatch

[Karim ATIKI]

Hi all,


Note: I just launched the build again with bitbake -k core-image-x11and

 the error did not occur again.
Well, a bit weird. Don't really know why does this error raised though.

Karim


De : yocto-boun...@yoctoproject.org <yocto-boun...@yoctoproject.org> de la part 
de Karim ATIKI <karim_at...@hotmail.com>
Envoyé : lundi 3 octobre 2016 18:31
À : Khem Raj; yocto
Objet : Re: [yocto] [meta-raspberrypi] taskhash mismatch



Hi Khem,

I have the same issue.
Get the latest master branches of poky, meta-raspberrypi and meta-oe.
Built a core-image-x11 and get the error:

ERROR: core-image-x11-1.0-r0 do_image_rpi_sdimg: Taskhash mismatch 
d77076c1266433c3dcd51a78947f273f versus 0eb1129a3545034a516ca72e5804ac33 for 
/home/kai/yocto/poky-krogoth/meta/recipes-graphics/images/core-image-x11.bb.do_image_rpi_sdimg
ERROR: Taskhash mismatch d77076c1266433c3dcd51a78947f273f versus 
0eb1129a3545034a516ca72e5804ac33 for 
/home/kai/yocto/poky-krogoth/meta/recipes-graphics/images/core-image-x11.bb.do_image_rpi_sdimg



Karim



De : yocto-boun...@yoctoproject.org <yocto-boun...@yoctoproject.org> de la part 
de Khem Raj <raj.k...@gmail.com>
Envoyé : lundi 3 octobre 2016 01:51
À : Trevor Woerner
Cc : yocto@yoctoproject.org
Objet : Re: [yocto] [meta-raspberrypi] taskhash mismatch


> On Oct 2, 2016, at 7:34 AM, Trevor Woerner <twoer...@gmail.com> wrote:
>
> Hi,
>
> For the last week or so my raspberry pi builds have been failing with:
>
> ERROR: core-image-minimal-1.0-r0 do_image_rpi_sdimg: Taskhash mismatch 
> 2920e557ac3a011d5679a52590cb664d versus a47bfc12fdfa29c58fe72cf8e0a28e91 for 
> /z/raspi2/poky/meta/recipes-core/images/core-image-minimal.bb.do_image_rpi_sdimg
> ERROR: Taskhash mismatch 2920e557ac3a011d5679a52590cb664d versus 
> a47bfc12fdfa29c58fe72cf8e0a28e91 for 
> /z/raspi2/poky/meta/recipes-core/images/core-image-minimal.bb.do_image_rpi_sdimg
>
> This is with both poky and oe+bitbake, master branches all around, and fully
> up-to-date. Before sending this email I pulled yet again and re-tested just to
> confirm.
>

is it due to use of DATE and TIME issue ? I think there was such a patch 
proposed to meta-rpi see
http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/commit/?id=4c02c7ce07121c2f5367204445f93199d828bb10

> Poky:
>
>Build Configuration:
>BB_VERSION= "1.31.1"
>BUILD_SYS = "x86_64-linux"
>NATIVELSBSTRING   = "SUSELINUX-42.1"
>TARGET_SYS= "arm-poky-linux-gnueabi"
>MACHINE   = "raspberrypi"
>DISTRO= "poky"
>DISTRO_VERSION= "2.1+snapshot-20161002"
>TUNE_FEATURES = "arm armv6  vfp arm1176jzfs callconvention-hard"
>TARGET_FPU= "hard"
>meta
>meta-poky = "master:3a73fe0efcb7aeefcca7011bba887caad03d4d03"
>meta-raspberrypi  = "master:4817e2c087097c02755d6309304878e42cf61d3c"
>
> OE + bitbake:
>
>Build Configuration:
>BB_VERSION= "1.31.1"
>BUILD_SYS = "x86_64-linux"
>NATIVELSBSTRING   = "SUSELINUX-42.1"
>TARGET_SYS= "arm-oe-linux-gnueabi"
>MACHINE   = "raspberrypi"
>DISTRO= "nodistro"
>DISTRO_VERSION= "nodistro.0"
>TUNE_FEATURES = "arm armv6  vfp arm1176jzfs callconvention-hard"
>TARGET_FPU= "hard"
>meta  = "master:21cc2a3f63ea260dbf6b50e2fd4dd50cacdd9935"
>meta-raspberrypi  = "master:4817e2c087097c02755d6309304878e42cf61d3c"
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
yocto Info Page<https://lists.yoctoproject.org/listinfo/yocto>
lists.yoctoproject.org
Discussion of all things about the Yocto Project. Read our Community Guidelines 
or learn more about how to participate in other community discussions.




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

Re: [yocto] [meta-raspberrypi] taskhash mismatch

[Karim ATIKI]

Hi Khem,

I have the same issue.
Get the latest master branches of poky, meta-raspberrypi and meta-oe.
Built a core-image-x11 and get the error:

ERROR: core-image-x11-1.0-r0 do_image_rpi_sdimg: Taskhash mismatch 
d77076c1266433c3dcd51a78947f273f versus 0eb1129a3545034a516ca72e5804ac33 for 
/home/kai/yocto/poky-krogoth/meta/recipes-graphics/images/core-image-x11.bb.do_image_rpi_sdimg
ERROR: Taskhash mismatch d77076c1266433c3dcd51a78947f273f versus 
0eb1129a3545034a516ca72e5804ac33 for 
/home/kai/yocto/poky-krogoth/meta/recipes-graphics/images/core-image-x11.bb.do_image_rpi_sdimg



Karim



De : yocto-boun...@yoctoproject.org  de la part 
de Khem Raj 
Envoyé : lundi 3 octobre 2016 01:51
À : Trevor Woerner
Cc : yocto@yoctoproject.org
Objet : Re: [yocto] [meta-raspberrypi] taskhash mismatch


> On Oct 2, 2016, at 7:34 AM, Trevor Woerner  wrote:
>
> Hi,
>
> For the last week or so my raspberry pi builds have been failing with:
>
> ERROR: core-image-minimal-1.0-r0 do_image_rpi_sdimg: Taskhash mismatch 
> 2920e557ac3a011d5679a52590cb664d versus a47bfc12fdfa29c58fe72cf8e0a28e91 for 
> /z/raspi2/poky/meta/recipes-core/images/core-image-minimal.bb.do_image_rpi_sdimg
> ERROR: Taskhash mismatch 2920e557ac3a011d5679a52590cb664d versus 
> a47bfc12fdfa29c58fe72cf8e0a28e91 for 
> /z/raspi2/poky/meta/recipes-core/images/core-image-minimal.bb.do_image_rpi_sdimg
>
> This is with both poky and oe+bitbake, master branches all around, and fully
> up-to-date. Before sending this email I pulled yet again and re-tested just to
> confirm.
>

is it due to use of DATE and TIME issue ? I think there was such a patch 
proposed to meta-rpi see
http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/commit/?id=4c02c7ce07121c2f5367204445f93199d828bb10

> Poky:
>
>Build Configuration:
>BB_VERSION= "1.31.1"
>BUILD_SYS = "x86_64-linux"
>NATIVELSBSTRING   = "SUSELINUX-42.1"
>TARGET_SYS= "arm-poky-linux-gnueabi"
>MACHINE   = "raspberrypi"
>DISTRO= "poky"
>DISTRO_VERSION= "2.1+snapshot-20161002"
>TUNE_FEATURES = "arm armv6  vfp arm1176jzfs callconvention-hard"
>TARGET_FPU= "hard"
>meta
>meta-poky = "master:3a73fe0efcb7aeefcca7011bba887caad03d4d03"
>meta-raspberrypi  = "master:4817e2c087097c02755d6309304878e42cf61d3c"
>
> OE + bitbake:
>
>Build Configuration:
>BB_VERSION= "1.31.1"
>BUILD_SYS = "x86_64-linux"
>NATIVELSBSTRING   = "SUSELINUX-42.1"
>TARGET_SYS= "arm-oe-linux-gnueabi"
>MACHINE   = "raspberrypi"
>DISTRO= "nodistro"
>DISTRO_VERSION= "nodistro.0"
>TUNE_FEATURES = "arm armv6  vfp arm1176jzfs callconvention-hard"
>TARGET_FPU= "hard"
>meta  = "master:21cc2a3f63ea260dbf6b50e2fd4dd50cacdd9935"
>meta-raspberrypi  = "master:4817e2c087097c02755d6309304878e42cf61d3c"
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
yocto Info Page
lists.yoctoproject.org
Discussion of all things about the Yocto Project. Read our Community Guidelines 
or learn more about how to participate in other community discussions.




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

Re: [yocto] [meta-raspberrypi] failed to copy the final ***rootfs.rpi-sdimg image file

[Karim ATIKI]

Hi Gary,


>That said, you also need a recent checkout of OE-core as the meta-raspberrypi
>and OE-core layers need to be in sync. These particular variables were changed
>starting with OE core rev 6d969bacc718e21a5246d4da9bf9639dcae29b02
>
>Just use the latest master of both meta-raspberrypi and OE-core
>and you should be fine.


I've cloned meta-raspberrypi and meta-openembedded with the latest branches.

It still fails at the same step [☹]  (see below).


Karim

>>
>>
>> I'm building a custom core-image-x11 for my raspberrypi3 board, with poky 
>> krogoth.
>>
>> In the very last steps:
>>
>>
>> ERROR: core-image-x11-1.0-r0 do_image_rpi_sdimg: Function failed: 
>> do_image_rpi_sdimg (log file is located at
>> /home/kai/yocto/build-rpi3/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-x11/1.0-r0/temp/log.do_image_rpi_sdimg.16110)
>>
>>
>> ERROR: Logfile of failure stored in:
>>
>> /home/kai/yocto/build-rpi3/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-x11/1.0-r0/temp/log.do_image_rpi_sdimg.16110
>>
>>
>> Log data follows:
>> | DEBUG: Executing python function set_image_size
>> | DEBUG: Python function set_image_size finished
>> | DEBUG: Executing shell function do_image_rpi_sdimg
>> | Creating filesystem with Boot partition 40960 KiB and RootFS 430080 KiB
>>
>> | dd: failed to open 
>> '/core-image-x11-raspberrypi3-20161001194728.rootfs.rpi-sdimg': Permission 
>> denied
>>
>> | WARNING: exit code 1 from a shell command.
>> | ERROR: Function failed: do_image_rpi_sdimg (log file is located at
>> /home/kai/yocto/build-rpi3/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-x11/1.0-r0/temp/log.do_image_rpi_sdimg.16110)
>>
>> ERROR: Task 16 
>> (/home/kai/yocto/poky-krogoth/meta/recipes-graphics/images/core-image-x11.bb,
>>  do_image_rpi_sdimg) failed
>> with exit code '1'
>> NOTE: Tasks Summary: Attempted 4771 tasks of which 4770 didn't need to be 
>> rerun and 1 failed.
>> No currently running tasks (4367 of 4773)
>>
>>
>> It looks like it tries to create the image in the path:
>>   /core-image-x11-raspberrypi3-20161001194728.rootfs.rpi-sdimg': Permission 
>> denied
>>
>>
>> I looked into the bbclass, and at first glance I'd say that the respective 
>> path
>> is "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.rpi-sdimg"
>>
>>
>> So ${IMGDEPLOYDIR} seems to be empty.
>>
>>
>> I haven't found any reference to IMGDEPLOYDIR elsewhere.
>>
>
> Make sure you have the latest [master] revisions.  This should have been 
> fixed by:
>
> commit 4817e2c087097c02755d6309304878e42cf61d3c
> Author: Andreas Müller 
> Date:   Tue Sep 13 02:19:06 2016 +0200
>
> sdcard_image-rpi.bbclass: avoid corrupted images with latest oe-core
>

That said, you also need a recent checkout of OE-core as the meta-raspberrypi
and OE-core layers need to be in sync. These particular variables were changed
starting with OE core rev 6d969bacc718e21a5246d4da9bf9639dcae29b02

Just use the latest master of both meta-raspberrypi and OE-core
and you should be fine.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
yocto -- Discussion of all things Yocto 
Project
lists.yoctoproject.org
Discussion of all things about the Yocto Project. Read our Community Guidelines 
or learn more about how to participate in other community discussions.



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

[yocto] failed to copy the final ***rootfs.rpi-sdimg image file

[Karim ATIKI]

hi,


I'm building a custom core-image-x11 for my raspberrypi3 board, with poky 
krogoth.

In the very last steps:


ERROR: core-image-x11-1.0-r0 do_image_rpi_sdimg: Function failed: 
do_image_rpi_sdimg (log file is located at 
/home/kai/yocto/build-rpi3/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-x11/1.0-r0/temp/log.do_image_rpi_sdimg.16110)

ERROR: Logfile of failure stored in: 
/home/kai/yocto/build-rpi3/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-x11/1.0-r0/temp/log.do_image_rpi_sdimg.16110

Log data follows:
| DEBUG: Executing python function set_image_size
| DEBUG: Python function set_image_size finished
| DEBUG: Executing shell function do_image_rpi_sdimg
| Creating filesystem with Boot partition 40960 KiB and RootFS 430080 KiB

| dd: failed to open 
'/core-image-x11-raspberrypi3-20161001194728.rootfs.rpi-sdimg': Permission 
denied

| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_image_rpi_sdimg (log file is located at 
/home/kai/yocto/build-rpi3/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-x11/1.0-r0/temp/log.do_image_rpi_sdimg.16110)
ERROR: Task 16 
(/home/kai/yocto/poky-krogoth/meta/recipes-graphics/images/core-image-x11.bb, 
do_image_rpi_sdimg) failed with exit code '1'
NOTE: Tasks Summary: Attempted 4771 tasks of which 4770 didn't need to be rerun 
and 1 failed.
No currently running tasks (4367 of 4773)



It looks like it tries to create the image in the path: 
/core-image-x11-raspberrypi3-20161001194728.rootfs.rpi-sdimg': Permission denied


I looked into the bbclass, and at first glance I'd say that the respective path 
is "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.rpi-sdimg"


So ${IMGDEPLOYDIR} seems to be empty.


I haven't found any reference to IMGDEPLOYDIR elsewhere.


Weird.


Karim


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

[yocto] missing glxext.h header file in core-image-x11 // toolchain SDK

[Karim ATIKI]

hi,

I have generated a core-image-x11 image for a Toradex Colibri T20 board.
I aim to compile and execute our application that normally runs under X11 + 
OpenGL.

I'm not an expert of X11 and gles technologies.

Therefore, I need to have the necessary libraries in the linux image I have 
generated.
I have therefore added in my local.conf:

DISTRO_FEATURES_append = "opengl"

In order to compile our application, I have generated the respective toolchain 
with bitbake -c populate_sdk core-image-x11.
It worked fine as well.

But as I launched the makefiles, I got some
...xxx.cpp :188:25: fatal error: GL/glxext.h: No such file or directory
   #include 

Indeed, I have no glxext.h file in the generated toolchain  sdk, neither in the 
sysroots.
In my sysroot,  I have only:

./GL
??? glxint.h
??? glxmd.h
??? glxproto.h
??? glxtokens.h
??? internal
??? glcore.h
./GLES
??? egl.h
??? glext.h
??? gl.h
??? glplatform.h
./GLES2
??? gl2ext.h
??? gl2.h
??? gl2platform.h


So, I suppose that something is missing in the features of my core-image-x11 
(and subsequently in the respective toolchain).

Should I add something  in some features ?


Cheers,

Karim

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

Re: [yocto] build a toolchain compiler with ARM hard-float support

[Karim ATIKI]

Thanks for your feeback.

I've attempted to generate the sdk (populate_sdk) having only 
MACHINE=colibri-t20 in the local.conf.


Fortunately, the generated installer has all the necessary features with 
hard-float support.


Karim



De : Mark Hatle <mark.ha...@windriver.com>
Envoyé : jeudi 29 septembre 2016 15:17
À : Richard Purdie; Karim ATIKI; yocto
Objet : Re: [yocto] build a toolchain compiler with ARM hard-float support

On 9/29/16 5:31 AM, Richard Purdie wrote:
> On Thu, 2016-09-29 at 09:10 +0000, Karim ATIKI wrote:
>> Hi,
>>
>> I'm using Poky Jethro to build on Toradex Colibri-T20 (armv7).
>>
>> I want to build my own SDK Installer to have  a toolchain and a
>> sysroot.
>>
>> Currently, I realied that the toolchain installer files do not
>> provide an arm-poky-linux-gnuabi compiler with hard-float support.
>> For example, while compiling my project:
>>
>> /opt/poky/2.0.1/sysroots/armv7a-vfp-neon-poky-linux-
>> gnueabi/usr/include/gnu/stubs.h:10:29: fatal error: gnu/stubs-hard.h:
>> No such file or directory
>>
>> Therefore:
>>
>>  How to be sure that the compiler generated by "bitbake -c
>> populate_sdk" will support hard-float ? Is there a configuration file
>> ?
>
> You need to choose a MACHINE which uses hard-float.

The machine configuration file should be setting the 'DEFAULTTUNE' variable to
an appropriate ISA and ABI (hard float) for your configuration.  If it is not,
you may have to create your own variant and change the DEFAULTTUNE setting --
assuming the board supports the necessary hard float components.  (And yes,
there are some armv7a variants that people removed the VFP instructions from --
even though it's theoretically against spec.)

--Mark

> Cheers,
>
> Richard
>

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

[yocto] build a toolchain compiler with ARM hard-float support

[Karim ATIKI]

Hi,


I'm using Poky Jethro to build on Toradex Colibri-T20 (armv7).


I want to build my own SDK Installer to have  a toolchain and a sysroot.


Currently, I realied that the toolchain installer files do not provide an 
arm-poky-linux-gnuabi compiler with hard-float support.

For example, while compiling my project:


/opt/poky/2.0.1/sysroots/armv7a-vfp-neon-poky-linux-gnueabi/usr/include/gnu/stubs.h:10:29:
 fatal error: gnu/stubs-hard.h: No such file or directory


Therefore:


 How to be sure that the compiler generated by "bitbake -c populate_sdk" will 
support hard-float ? Is there a configuration file ?


Karim

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

Re: [yocto] [meta-toraxdex] unrecoverable build error

[Karim ATIKI]

Hi Khem,


>do you have x11 in DISTRO_FEATURES

No, the DISTRO_FEATURES variable was not even declared in the default local.conf

Karim


De : Khem Raj <raj.k...@gmail.com>
Envoyé : lundi 26 septembre 2016 09:28
À : Karim ATIKI
Cc : yocto
Objet : Re: [yocto] [meta-toraxdex] unrecoverable build error

On Sat, Sep 24, 2016 at 11:10 PM, Karim ATIKI <karim_at...@hotmail.com> wrote:
> hi,
>
>
> During a core-image-x11  build   (yocto krogoth, meta-toradex) , I got the
> following error I never encountered with Yocto:
>
>
> ERROR: xf86-input-evdev-2_2.10.1-r0 do_populate_sysroot: The recipe
> xf86-input-evdev is trying to install files into a shared area when those
> files already exist. Those files and their manifest location are:
>
> /home/kai/yocto/colibri-t20-kts/tmp/sysroots/colibri-t20/usr/share/X11/xorg.conf.d/10-evdev.conf
>  Matched in manifest-colibri-t20-xserver-xorg.populate_sysroot
> Please verify which recipe should provide the above files.
> The build has stopped as continuing in this scenario WILL break things, if
> not now, possibly in the future (we've seen builds fail several months
> later). If the system knew how to recover from this automatically it would
> however there are several different scenarios which can result in this and
> we don't know which one this is. It may be you have switched providers of
> something like virtual/kernel (e.g. from linux-yocto to linux-yocto-dev), in
> that case you need to execute the clean task for both recipes and it will
> resolve this error. It may be you changed DISTRO_FEATURES from systemd to
> udev or vice versa. Cleaning those recipes should again resolve this error
> however switching DISTRO_FEATURES on an existing build directory is not
> supported, you should really clean out tmp and rebuild (reusing sstate
> should be safe). It could be the overlapping files detected are harmless in
> which case adding them to SSTATE_DUPWHITELIST may be the correct solution.
> It could also be your build is including two different conflicting versions
> of things (e.g. bluez 4 and bluez 5 and the correct solution for that would
> be to resolve the conflict. If in doubt, please ask on the mailing list,
> sharing the error and filelist above.
> ERROR: xf86-input-evdev-2_2.10.1-r0 do_populate_sysroot: If the above
> message is too much, the simpler version is you're advised to wipe out tmp
> and rebuild (reusing sstate is fine). That will likely fix things in most
> (but not all) cases.
> ERROR: xf86-input-evdev-2_2.10.1-r0 do_populate_sysroot: Function failed:
> sstate_task_postfunc
> ERROR: Logfile of failure stored in:
> /home/kai/yocto/colibri-t20-kts/tmp/work/armv7ahf-vfp-poky-linux-gnueabi/xf86-input-evdev/2_2.10.1-r0/temp/log.do_populate_sysroot.639
> ERROR: Task 2181
> (/home/kai/yocto/poky-toradex/meta/recipes-graphics/xorg-driver/xf86-input-evdev_2.10.1.bb,
> do_populate_sysroot) failed with exit code '1'
>
>
> I cant' get rid of this error. I have deleted the tmp and
> sstate-cache...nothing. it always occurs again.
>
>
> Any idea?



>
>
> Z.
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
yocto -- Discussion of all things Yocto 
Project<https://lists.yoctoproject.org/listinfo/yocto>
lists.yoctoproject.org
Discussion of all things about the Yocto Project. Read our Community Guidelines 
or learn more about how to participate in other community discussions.



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

Re: [yocto] [meta-toraxdex] unrecoverable build error

[Karim ATIKI]

Hi Jussi,


>

>10-evdev.conf was moved from xserver-xorg to to the driver. If you are using 
>krogoth, xserver-xorg really should be new enough (>=1.18.0) to not install 
>the file.
>Does meta-toradex maybe provide an older xorg?

Actually, I don't know.
In which kind of file can I find this information ?




De : Jussi Kukkonen <jussi.kukko...@intel.com>
Envoyé : lundi 26 septembre 2016 10:18
À : Karim ATIKI
Cc : yocto
Objet : Re: [yocto] [meta-toraxdex] unrecoverable build error

On 25 September 2016 at 09:10, Karim ATIKI 
<karim_at...@hotmail.com<mailto:karim_at...@hotmail.com>> wrote:
>
> hi,
>
> During a core-image-x11  build   (yocto krogoth, meta-toradex) , I got the 
> following error I never encountered with Yocto:
>
> ERROR: xf86-input-evdev-2_2.10.1-r0 do_populate_sysroot: The recipe 
> xf86-input-evdev is trying to install files into a shared area when those 
> files already exist. Those files and their manifest location are:
>
> /home/kai/yocto/colibri-t20-kts/tmp/sysroots/colibri-t20/usr/share/X11/xorg.conf.d/10-evdev.conf
>  Matched in manifest-colibri-t20-xserver-xorg.populate_sysroot
> Please verify which recipe should provide the above files.


 - Jussi


> The build has stopped as continuing in this scenario WILL break things, if 
> not now, possibly in the future (we've seen builds fail several months 
> later). If the system knew how to recover from this automatically it would 
> however there are several different scenarios which can result in this and we 
> don't know which one this is. It may be you have switched providers of 
> something like virtual/kernel (e.g. from linux-yocto to linux-yocto-dev), in 
> that case you need to execute the clean task for both recipes and it will 
> resolve this error. It may be you changed DISTRO_FEATURES from systemd to 
> udev or vice versa. Cleaning those recipes should again resolve this error 
> however switching DISTRO_FEATURES on an existing build directory is not 
> supported, you should really clean out tmp and rebuild (reusing sstate should 
> be safe). It could be the overlapping files detected are harmless in which 
> case adding them to SSTATE_DUPWHITELIST may be the correct solution. It could 
> also be your build is including two different conflicting versions of things 
> (e.g. bluez 4 and bluez 5 and the correct solution for that would be to 
> resolve the conflict. If in doubt, please ask on the mailing list, sharing 
> the error and filelist above.
> ERROR: xf86-input-evdev-2_2.10.1-r0 do_populate_sysroot: If the above message 
> is too much, the simpler version is you're advised to wipe out tmp and 
> rebuild (reusing sstate is fine). That will likely fix things in most (but 
> not all) cases.
> ERROR: xf86-input-evdev-2_2.10.1-r0 do_populate_sysroot: Function failed: 
> sstate_task_postfunc
> ERROR: Logfile of failure stored in: 
> /home/kai/yocto/colibri-t20-kts/tmp/work/armv7ahf-vfp-poky-linux-gnueabi/xf86-input-evdev/2_2.10.1-r0/temp/log.do_populate_sysroot.639
> ERROR: Task 2181 
> (/home/kai/yocto/poky-toradex/meta/recipes-graphics/xorg-driver/xf86-input-evdev_2.10.1.bb<http://xf86-input-evdev_2.10.1.bb>,
>  do_populate_sysroot) failed with exit code '1'
>
>
> I cant' get rid of this error. I have deleted the tmp and 
> sstate-cache...nothing. it always occurs again.
>
>
> Any idea?
>
>
> Z.
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-toradex] failed to patch dont_start_connman_on_nfsboot.patch

[Karim ATIKI]

Hi all,


I'm building a core-image-sato based on toradex colibrit20 bsp.

Using meta-toradex.


During build, I have the follwoing error:


ERROR: connman-1.31-r0 do_patch: Command Error: 'quilt --quiltrc 
/home/kai/yocto/colibri-t20-kts/tmp/sysroots/x86_64-linux/etc/quiltrc push' 
exited with 1  Output:
Applying patch dont_start_connman_on_nfsboot.patch
patching file src/connman.service.in
Hunk #1 FAILED at 3.
1 out of 1 hunk FAILED -- rejects in file src/connman.service.in
Patch dont_start_connman_on_nfsboot.patch does not apply (enforce with -f)
ERROR: connman-1.31-r0 do_patch: Function failed: patch_do_patch
ERROR: Logfile of failure stored in: 
/home/kai/yocto/colibri-t20-kts/tmp/work/armv7ahf-vfp-poky-linux-gnueabi/connman/1.31-r0/temp/log.do_patch.8724
ERROR: Task 2836 
(/home/kai/yocto/poky-toradex/meta/recipes-connectivity/connman/connman_1.31.bb,
 do_patch) failed with exit code '1'



In the log file:


NOTE: Applying patch 
'0001-iptables-Add-missing-function-item-of-xtables-to-mat.patch' 
(../poky-toradex/meta/recipes-connectivity/connman/connman/0001-iptables-Add-missing-func
tion-item-of-xtables-to-mat.patch)
NOTE: Applying patch 'dont_start_connman_on_nfsboot.patch' 
(../poky-toradex/meta-toradex/recipes-connectivity/connman/connman/dont_start_connman_on_nfsboot.patch)
ERROR: Command Error: 'quilt --quiltrc 
/home/kai/yocto/colibri-t20-kts/tmp/sysroots/x86_64-linux/etc/quiltrc push' 
exited with 1  Output:
Applying patch dont_start_connman_on_nfsboot.patch
patching file src/connman.service.in
Hunk #1 FAILED at 3.
1 out of 1 hunk FAILED -- rejects in file src/connman.service.in
Patch dont_start_connman_on_nfsboot.patch does not apply (enforce with -f)




I just can't figure out how to get rid of this error.

I'm not particulary familiar with patching and I haven't found any relevant 
info on the internet...


Any suggestion / feedback ?


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

[yocto] How to add my own c++ project into a Yocto distro

[Karim ATIKI]

Hi all,


I have setup a Poky distribution based on a core-image-sato image for both 
RaspberryPi and Toradex Colibri T20.

I have an X11 environment working fine.


Right now, I need to compile our software we developped.

I basically need to fetch SVN repositories and finally to launch a makefile to 
get everyting work.

The makefile is however not based on autotools. It's a custom makefiles with 
regular dependencies.


I just don't know how to achieve this step in Yocto ?

Should I add a recipe ?

Is there a link that describes what I need to achieve ?


Thanks


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

[yocto] meta-toradex: How to generate uImage* files ?

[Karim ATIKI]

Hi all,


I have downloaded a sample linux image from the Toradex developers website to 
test on a Toradex Colibri T20 device. It worked fine.


Now I have generated a custom poky distribution (core-image-minimal) to deplkoy 
on the device.

However, the generated image is zImage format. Whereas it seems that uBoot is 
expecting uImage.


1) How do we inform Yocto to generate uImage instead of zImage ?


2) Therefore, I have deleted the tmp/deploy directory.

But right now, I'm unable to generate the distro again.

I tried many things:


bitbake -c clean core-image-minimal

bitbake -c cleanall core-image-minimal

bitbake core-image-minimal


Everything fails.


Is there a way to get things working again or should generate everythingh from 
scratch again ?



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

[yocto] [Yocto][Generic] Add a local binary file into a target Distro

[Karim ATIKI]

Hi all,


Please be indulgent with my noob question.

I spent a lot of time with setting up Yocto on different target boards.

It's just amazing.


But, although I've been able to add my own layer to include a project from 
github, I was just wondering how we could simply and easily add a local file / 
binary to a target distro ? (FYI: raspberrypi2) without creating tons of layers 
, bb. etc.


Thanks for your feedback.


K.

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

[linux-yocto] [raspberrypi2] How to run the image with QEMU

[Karim ATIKI]

Hi all,
Beginning with Yocto and Raspberry, I've generated a Raspberry-Pi 2 image 
following a Tutorial.
In the deploy folder, I've the following main files:
qt5-image-demo-raspberrypi2.ext3qt5-image-demo-raspberrypi2.manifestqt5-image-demo-raspberrypi2.rpi-sdimgqt5-image-demo-raspberrypi2.tar.bz2
Can I use QEMU to test the image ? What's the exact command line ?
Or should I generate a different image type ?
Thanks
Karim -- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto